Одержання реляційної схеми з er-схеми у висновку процесу проектування розглянемо етапи перетворення інфологічної моделі в реляційну схему бази даних.
Крок 1. Кожна проста сутність перетворюється в таблицю. Ім'я сутності стає ім'ям таблиці.
Крок 2. Кожен атрибут стає можливим стовпцем з тим же ім'ям; може вибиратися більш точний формат. Стовпці, що відповідають необов'язковим атрибутам, можуть містити невизначені значення; стовпці, що відповідають обов'язковим атрибутам, - не можуть.
Крок 3. Компоненти унікального ідентифікатора сутності перетворюються в первинний ключ таблиці. Якщо є кілька можливих унікальних ідентифікатора, вибирається найбільш використовуваний. Якщо до складу унікального ідентифікатора входять зв'язки, до числа стовпців первинного ключа додається копія унікального ідентифікатора сутності, що знаходиться на дальньому кінці зв'язку (цей процес може продовжуватися рекурсивно). Для іменування цих стовпців використовуються імена кінців зв'язків і/або імена сутностей.
Крок 4. Зв'язки багато-до-одного (і один-до-одного) стають зовнішніми ключами. Тобто, робиться копія унікального ідентифікатора з кінця зв'язку "один", і відповідні стовпці складають зовнішній ключ. Необов'язкові зв'язки відповідають стовпцям, що допускають невизначені значення; обов'язкові зв'язки - стовпцям, що не допускають невизначені значення.
Крок 5. Індекси створюються для первинного ключа (унікальний індекс), зовнішніх ключів і тих атрибутів, на яких передбачається в основному базувати запити.
Крок 6. Якщо в концептуальній схемі були присутні підтипи, то можливі два способи:
усі підтипи в одній таблиці (таблиця 5);
для кожного підтипу - окрема таблиця (таблиця 6);
При застосуванні способу (а) таблиця створюється для найбільш зовнішнього супертипу, а для підтипів можуть створюватися представлення. У таблицю додається принаймні один стовпець, що містить код ТИПУ; він стає частиною первинного ключа.
При використанні методу (б) для кожного підтипу першого рівня (для більш нижніх - представлень) супертип відтворюється за допомогою представлення UNION (із усіх таблиць підтипів вибираються загальні стовпці - стовпці супертипу).
Таблиця 5.
Усі в одній таблиці |
Таблиця - на підтип |
Переваги |
|
усе зберігається разом; легкий доступ до супертипу і підтипів; потрібно менше таблиць |
більш ясні правила підтипів; програми працюють тільки з потрібними таблицями |
Недоліки |
|
Занадто загальне рішення Потрібно додаткова логіка роботи з різними наборами стовпців і різних обмежень; потенційне вузьке місце (у зв'язку з блокуваннями); стовпці підтипів повинні бути необов'язковими; в деяких СУБД для збереження невизначених значень потрібно додаткова пам'ять |
занадто багато стовпців, що бентежать, у представленні UNION; потенційна втрата продуктивності при роботі через UNION; над супертипом неможливі модифікації |
Крок 7. Є два способи роботи при наявності зв'язків, що виключають:
загальний домен (а)
явні зовнішні ключі (б)
Якщо зовнішні ключі, що залишаються, усі в одному домені, тобто мають загальний формат (спосіб (а)), то створюються два стовпці: ідентифікатор зв'язку й ідентифікатор сутності. Стовпець ідентифікатора зв'язку використовується для розрізнення зв'язків, що покриваються дугою виключення. Стовпець ідентифікатора сутності використовується для збереження значень унікального ідентифікатора сутності на дальньому кінці відповідної зв'язку.
Якщо результуючі зовнішні ключі не відносяться до одного домену, то для кожного зв'язку, що покривається дугою виключення, створюються явні стовпці зовнішніх ключів; усі ці стовпці можуть містити невизначені значення.
Таблиця 6.
Загальний домен |
Явні зовнішні ключі |
Переваги |
|
Потрібно тільки два стовпці |
Умови з'єднання - явні |
Недоліки |
|
Обидва додаткових атрибута повинні використовуватися в з'єднаннях |
Занадто багато стовпців |
Альтернативні моделі сутностей:
Варіант 1 (поганий)
Варіант
2 (істотно краще, якщо підтипи дійсно
існують)
Варіант 3 (годиться при наявності осмисленого супертипу D).
