Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

Перехід до фізичної моделі бази даних

Побудова фізичної моделі бази даних повністю засноване на принципах організації даних, реалізованих в логічної моделі бази даних. Саме тому зазвичай розробники, проектуючи базу даних, будують одночасно логічну і фізичну моделі бази даних. Однак, особливо в великих проектах, створити паралельно логічну і фізичну моделі досить проблематично зважаючи на великий обсяг структурних елементів і необхідності часто узгоджувати виходять моделі. У зв'язку з цим проектується спочатку логічна модель бази даних, а потім на її основі створюється проект фізичної моделі бази даних, яку доводять до прийнятного рівня, розглядаючи додавання уявлень, правил посилальної цілісності, процедурних програмних модулів, розподіл таблиць з табличних просторів, організовуючи фізичне розміщення бази даних.

Щоб перейти від логічної моделі бази даних до фізичної, немає необхідності повністю переписувати модель. В інструментальних засобах реалізується механізм трансформації логічної моделі у фізичну зі збереженням всіх заздалегідь визначених правил структурування і зв'язування сутностей, а також застосуванням деяких правил технічної нормалізації, що передбачають ліквідацію зв'язків багато - до - багатьох, зважаючи на неможливість її фізичної реалізації в базі даних, і категоризації, яка також не передбачена в базах даних, по є ідентичною зв'язку один - до - одному.

Для реалізації процесу трансформації, використовуючи IBM InfoSphere Data Architect, в контекстному меню логічної моделі бази даних передбачено пункт "Transform to Physical Data Model" (Трансформація в фізичну модель даних). Аналогічну дію може бути виконано при виборі пункту меню "Data / Transform / Physical Data Model" (Дані / Трансформація / Фізична модель даних).

Вибір пункту меню трансформації моделі па першому кроці в діалоговому вікні визначення параметрів вимагає від розробника вказати варіант створення фізичної моделі бази даних (рис. 4.87):

  • • Create new model (Створити нову модель) - вибір цього варіанту призведе до створення нової моделі бази даних з описом таблиць, що відносяться тільки до створюваної моделі;
  • • Update existing model (Оновлення існуючої моделі) - вибір цього варіанту призводить до зміни існуючої і зазначеної в полі "Target model" (Модель призначення) моделі бази даних, замінюючи існуючі в ній сутності, зв'язку, ключі та інші елементи.

image297

Мал. 4.87. Визначення варіанту створення фізичної моделі бази даних


На другому етапі визначення параметрів трансформації розробник вказує СУБД (рис. 4.88), правила якої необхідно використовувати при описі таблиць і програмних модулів. Для цього в поле "Database" (База даних) необхідно вибрати необхідну СУБД із зазначеного переліку, який від версії до версії інструментального кошти регулярно поповнюється і містить чималу кількість застосовуваних на ринку засобів управління базами даних. У нулі "Version" (Версія) важливо вказати, для якої версії СУБД буде проектуватися фізична модель бази даних, оскільки часто в різних версіях бувають відмінними синтаксис і набір стандартних функціональних програмних модулів. У розглянутому прикладі, з метою дотримання наступності виробника використовуваних програмних засобів, вибираємо СУБД "IBM DB2 for Linux, UNIX and Windows" і останню наявну в списку версію "V 10.1".

image298


Puc. 4.88. Вказівка використовуваної для моделі СУБД

Третій крок визначення параметрів трансформації вказує на правила іменування атрибутів, сутностей і використання типів даних. Тут варто зробити деякий відступ від процесу настройки трансформації (рис. 4.89). Важливим є прийняття в розробці правил іменування елементів бази даних, аналогічно тому, як це робиться в програмуванні, де обов'язково існує угода імен, які застосовуються в програмних кодах. Угода імен для бази даних враховує принципи і правила, які застосовуються для правильного використання імен таблиць, полів (колонок), процедур, функцій, обмежень, замовчувань і т.д. Ця угода буде застосовуватися не тільки в рамках трансформації, а й після первинного формування фізичної моделі даних для приведення до вигляду, зручного для написання програмного коду обробки даних і звернення до об'єктів бази даних. Щоб модель була коректно представлена, розробником визначаються наступні параметри угоди імен:

правило злиття слів в найменуванні таблиці, оскільки, за замовчуванням, передбачається, що СУБД не повинна обробляти будь-які найменування, що містять спеціальні символи і прогалини;

  • - Правило застосування регістра символів для іменування об'єктів бази даних;
  • - Правило опису сурогатного ключа в частині застосування методу арифметичної прогресії для обчислення його значення;
  • - Необхідність створення індексів для первинних ключів і унікальних атрибутів (альтернативні ключі);
  • - Правила іменування окремих екземплярів об'єктів бази даних.

На третьому кроці, враховуючи угоді імен, розробник визначає

властивості перетворення назв таблиць, атрибутів і інших елементів бази даних:

  • • Name Case (Подання імен) - властивість дає можливість вказати, що всі найменування атрибутів і таблиць повинні представлятися малими (маленькими), великими (великими) символами або в існуючому в логічної моделі бази даних варіанті;
  • • Data Type Defaults (тип даних no замовчуванням) - властивість визначає тип даних з базовими параметрами розмірності, який повинен бути встановлений для атрибута, якщо в СУБД не представлені вказаний в логічної моделі бази даних тип;
  • • Physical Options / Surrogate key (сурогатний ключ) - властивість визначає правило уявлення сурогатного ключа в базі даних одним з двох варіантів: ідентифікує колонка (поле) або лічильник (sequence);
  • • Physical Options / Index (індекс) - це властивість визначає необхідність створення опису індексів для первинних ключів і атрибутів з обмеженням унікальності значення;
  • • Join table separator (роздільник слів імені таблиці) - це властивість визначає комбінацію символів, яка повинна застосовуватися для прогалин і спеціальних символів при трансформації імен сутностей в імена таблиць.

image299

Мал. 4.89. Налаштування перетворення об'єктів моделі


В результаті виконання операції виходить модель бази даних (рис. 4.90), де, відповідно до вимог СУБД, описані об'єкти бази даних: таблиці, нуля (колонки), індекси, обмеження, умовчання і т.д.

image300

Мал. 4.90. Результат трансформації моделі


При використанні СЛ ERWin Data Modeler, щоб створити фізичну модель з логічної, досить виконати експорт створеної фізичної моделі, вказавши в якості моделі призначення фізичну модель. В результаті буде створений файл з фізичною моделлю або, якщо обрана комбінована модель, логіко-фізична модель з перетворенням імен об'єктів моделі до відповідних елементів фізичної моделі.

 
<<   ЗМІСТ   >>