Проектування реляційної БД

При проектуванні бази даних вирішуються дві основних проблеми:
Яким чином відобразити об'єкти предметної області в абстрактні об'єкти моделі даних, щоб це відображення не суперечило семантиці предметної області і було по можливості кращим (ефективним, зручним і т.д.)? Часто цю проблему називають проблемою логічного проектування баз даних.
Як забезпечити ефективність виконання запитів до бази даних, тобто яким чином, маючи на увазі особливості конкретної СУБД, розташувати дані у зовнішній пам'яті, створення яких додаткових структур (наприклад, індексів) зажадати і т.д.? Цю проблему називають проблемою фізичного проектування баз даних.
У разі реляційних баз даних важко представити які-небудь загальні рецепти по частині фізичного проектування. Тут дуже багато залежить від СУБД, що використовується. Наприклад, при роботі з СУБД Ingres можна вибирати один з способів фізичної організації відносин, що пропонуються, при роботі з System R слід би передусім подумати об кластеризації відносин і необхідному наборі індексів і т.д. Тому ми обмежимося питаннями логічного проектування реляційних баз даних, які істотні при використанні будь-якої реляційної СУБД.
Більш того ми не будемо торкатися дуже важливого аспекту проектування - визначення обмежень цілісності (за винятком обмеження первинного ключа). Справа в тому, що при використанні СУБД з розвиненими механізмами обмежень цілісності (наприклад, SQL-орієнтованих систем) важко запропонувати який-небудь загальний підхід до визначення обмежень цілісності. Ці обмеження можуть мати дуже загальний вигляд, і їх формулювання поки відноситься швидше до області мистецтва, чим інженерної майстерності. Саме більше, що пропонується з цього приводу в літературі, це автоматична перевірка несуперечності набору обмежень цілісності.
Так що будемо вважати, що проблема проектування реляційної бази даних складається в обґрунтованому прийнятті рішень про те,
з яких відносин повинна перебувати БД і
які атрибути повинні бути у цих відносин.
6.1. Проектування реляційних баз даних з використанням нормалізації
Спочатку буде розглянутий класичний підхід, при якому весь процес проектування виготовляється в термінах реляційної моделі даних методом послідовних наближень до задовільного набору схем відносин. Початковою точкою є представлення предметної області у вигляді одного або декількох відносин, і на кожному кроці проектування проводиться деякий набір схем відносин, що володіють кращими властивостями. Процес проектування являє собою процес нормалізації схем відносин, причому кожна наступна нормальна форма володіє властивостями кращими, ніж попередня.
Кожній нормальній формі відповідає деякий певний набір обмежень, і відношення знаходиться в деякій нормальній формі, якщо задовольняє властивому їй набору обмежень. Прикладом набору обмежень є обмеження першої нормальної форми - значення всіх атрибутів відношення атомарні. Оскільки вимога першої нормальної форми є базовою вимогою класичної реляційної моделі даних, ми будемо вважати, що початковий набір відносин вже відповідає цій вимозі.
У теорії реляційних баз даних звичайно виділяється наступна послідовність нормальних форм:
перша нормальна форма (1NF);
друга нормальна форма (2NF);
третя нормальна форма (3NF);
нормальна форма Бойса-Кодда (BCNF);
четверта нормальна форма (4NF);
п'ята нормальна форма, або нормальна форма проекції-з'єднання (5NF або PJ/NF).
Основні властивості нормальних форм:
кожна наступна нормальна форма в деякому розумінні краще попередньої;
при переході до наступної нормальної форми властивості попередніх нормальних властивостей зберігаються.
У основі процесу проектування лежить метод нормалізації, декомпозиція відношення, що знаходиться в попередній нормальній формі, в два або більше за відношення, що задовольняють вимогам наступної нормальної форми.
Найбільш важливі на практикові нормальні форми відносин засновуються на фундаментальному в теорії реляційних баз даних понятті функціональної залежності. Для подальшого викладу нам будуть потрібні декілька визначень.
Визначення 1. Функціональна залежність
У відношенні R атрибут Y функціонально залежить від атрибута X (X і Y можуть бути складовими) в тому і тільки в тому випадку, якщо кожному значенню X відповідає в точності одне значення Y:
Визначення 2. Повна функціональна залежність
Функціональна залежність
Визначення 3. Транзитивна функціональна залежність
Функціональна залежність > R.X. (При відсутності останньої вимоги ми мали б "нецікаву" транзитивну залежність в будь-якому відношенні, що володіє декількома ключами.)
Визначення 4. Неключовий атрибут
Неключовим атрибутом називається будь-який атрибут відношення, що не входить до складу первинного ключа (зокрема, первинного).
Визначення 5. Взаємно незалежні атрибути
Два або більше за атрибут взаємно незалежні, якщо жоден з цих атрибутів не є функціонально залежним від інших.
6.1.1. Друга нормальна форма
Розглянемо наступний приклад схеми відношення:
СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ
(СПІВР_НОМЕР, СПІВР_ЗАРП, ВІД_НОМЕР, ПРО_НОМЕР, СПІВР_ЗАВДАН)
Первинний ключ:
СПІВР_НОМЕР, ПРО_НОМЕР
Функціональна залежність:
СПІВР_НОМЕР -> СПІВР_ЗАРП
СПІВР_НОМЕР -> ВІД_НОМЕР
ВІД_НОМЕР -> СПІВР_ЗАРП
СПІВР_НОМЕР, ПРО_НОМЕР -> СПІВР_ЗАВДАН
Як видно, хоч первинним ключем є складовою атрибут СПІВР_НОМЕР, ПРО_НОМЕР, атрибути СПІВР_ЗАРП і ВІД_НОМЕР функціонально залежать від частини первинного ключа, атрибута СПІВР_НОМЕР. У результаті ми не зможемо вставити у відношення СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ кортеж, що описує співробітника, який ще не виконує ніякого проекту (первинний ключ не може містити невизначене значення). При видаленні кортежу ми не тільки руйнуємо зв'язок даного співробітника з даним проектом, але втрачаємо інформацію про те, що він працює в деякому відділі. При перекладі співробітника в інший відділ ми будемо вимушені модифікувати всі кортежі, що описують цього співробітника, або отримаємо неузгоджений результат. Такі неприємні явища називаються аномаліями схеми відношення. Вони усуваються шляхом нормалізації.
Визначення 6. Друга нормальна форма (в цьому визначенні передбачається, що єдиним ключем відношення є первинний ключ)
Відношення R знаходиться у другій нормальній формі (2NF) в тому і тільки в тому випадку, коли знаходиться в 1NF, і кожний неключовий атрибут повністю залежить від первинного ключа.
Можна зробити наступну декомпозицію відношення СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ в два відношення СПІВРОБІТНИКИ-ВІДДІЛИ і СПІВРОБІТНИКИ-ПРОЕКТИ:
СПІВРОБІТНИКИ-ВІДДІЛИ (СПІВР_НОМЕР, СПІВР_ЗАРП, ВІД_НОМЕР)
Первинний ключ:
СПІВР_НОМЕР
Функціональна залежність:
СПІВР_НОМЕР -> СПІВР_ЗАРП
СПІВР_НОМЕР -> ВІД_НОМЕР
ВІД_НОМЕР -> СПІВР_ЗАРП
СПІВРОБІТНИКИ-ПРОЕКТИ (СПІВР_НОМЕР, ПРО_НОМЕР, СПІВР_ЗАВДАН)
Первинний ключ:
СПІВР_НОМЕР, ПРО_НОМЕР
Функціональна залежність:
СПІВР_НОМЕР, ПРО_НОМЕР -> CПІВР_ЗАВДАН
Кожне з цих двох відносин знаходиться в 2NF, і в них усунені відмічені вище аномалії (легко перевірити, що всі вказані операції виконуються без проблем).
Якщо допустити наявність декількох ключів, то визначення 6 прийме наступний вигляд:
Визначення 6~
Відношення R знаходиться у другій нормальній формі (2NF) в тому і тільки в тому випадку, коли воно знаходиться в 1NF, і кожний неключовий атрибут повністю залежить від кожного ключа R.
Тут і далі ми не будемо приводити приклади для відносин з декількома ключами. Вони дуже громіздкі і відносяться до ситуацій, що рідко зустрічається на практиці.
6.1.2. Третя нормальна форма
Розглянемо ще раз відношення СПІВРОБІТНИКИ-ВІДДІЛИ, що знаходиться в 2NF. Помітимо, що функціональна залежність СПІВР_НОМЕР -> СПІВР_ЗАРП є транзитивною; вона є наслідком функціональної залежності СПІВР_НОМЕР -> ВІД_НОМЕР і ВІД_НОМЕР -> СПІВР_ЗАРП. Іншими словами, заробітна плата співробітника насправді є характеристикою не співробітника, а відділу, в якому він працює (це не дуже природне припущення, але достатнє для прикладу).
У результаті ми не зможемо занести в базу даних інформацію, що характеризує заробітну плату відділу, доти, поки в цьому відділі не з'явиться хоч би один співробітник (первинний ключ не може містити невизначене значення). При видаленні кортежу, що описує останнього співробітника даного відділу, ми позбавимося інформації про заробітну плату відділу. Щоб узгоджено змінити заробітну плату відділу, ми будемо вимушені заздалегідь знайти всі кортежі, що описують співробітників цього відділу. Тобто у відношенні СПІВРОБІТНИКИ-ВІДДІЛИ як і раніше існують аномалії. Їх можна усунути шляхом подальшої нормалізації.
Визначення 7. Третя нормальна форма. (Знов визначення дається в припущенні існування єдиного ключа.)
Відношення R знаходиться в третій нормальній формі (3NF) в тому і тільки в тому випадку, якщо знаходиться в 2NF і кожний неключовий атрибут нетранзитивно залежить від первинного ключа.
Можна зробити декомпозицію відношення СПІВРОБІТНИКИ-ВІДДІЛИ в два відношення СПІВРОБІТНИКИ і ВІДДІЛИ:
СПІВРОБІТНИКИ (СПІВР_НОМЕР, ВІД_НОМЕР)
Первинний ключ:
СПІВР_НОМЕР
Функціональна залежність:
СПІВР_НОМЕР -> ВІД_НОМЕР
ВІДДІЛИ (ВІД_НОМЕР, СПІВР_ЗАРП)
Первинний ключ:
ВІД_НОМЕР
Функціональна залежність:
ВІД_НОМЕР -> СПІВР_ЗАРП
Кожне з цих двох відносин знаходиться в 3NF і вільно від відмічених аномалій.
Якщо відмовитися від того обмеження, що відношення володіє єдиним ключем, то визначення 3NF прийме наступну форму:
Визначення 7~
Відношення R знаходиться в третій нормальній формі (3NF) в тому і тільки в тому випадку, якщо знаходиться в 1NF, і кожний неключовий атрибут не є транзитивно залежним від якого-небудь ключа R.
На практиці третя нормальна форма схем відносин достатня в більшості випадків, і приведенням до третьої нормальної форми процес проектування реляційної бази даних звичайно закінчується. Однак іноді корисно продовжити процес нормалізації.
6.1.3. Нормальна форма Бойса-Кодда
Розглянемо наступний приклад схеми відношення:
СПІВРОБІТНИКИ-ПРОЕКТИ (СПІВР_НОМЕР, СПІВР_ІМ’Я, ПРО_НОМЕР, СПІВР_ЗАВДАН)
Можливі ключі:
СПІВР_НОМЕР, ПРО_НОМЕР
СПІВР_ІМ’Я, ПРО_НОМЕР
Функціональна залежність:
СПІВР_НОМЕР -> СПІВР_ІМ’Я
СПІВР_НОМЕР -> ПРО_НОМЕР
СПІВР_ІМ’Я -> CПІВР_НОМЕР
СПІВР_ІМ’Я -> ПРО_НОМЕР
СПІВР_НОМЕР, ПРО_НОМЕР -> CПІВР_ЗАВДАН
СПІВР_ІМ’Я, ПРО_НОМЕР -> CПІВР_ЗАВДАН
У цьому прикладі ми передбачаємо, що особистість співробітника повністю визначається як його номером, так і ім'ям (це знов не дуже життєве припущення, але достатнє для прикладу).
Відповідно до визначення 7~ відношення СПІВРОБІТНИКИ-ПРОЕКТИ знаходиться в 3NF. Однак той факт, що є функціональна залежність атрибутів відношення від атрибута, що є частиною первинного ключа, приводить до аномалій. Наприклад, для того, щоб змінити ім'я співробітника з даним номером узгодженим образом, нам зажадається модифікувати всі кортежі, що включають його номер.
Визначення 8. Детермінант
Детермінант - будь-який атрибут, від якого повністю функціонально залежить деякий інший атрибут.
Визначення 9. Нормальна форма Бойса-Кодда
Відношення R знаходиться в нормальній формі Бойса-Кодда (BCNF) в тому і тільки в тому випадку, якщо кожний детермінант є можливим ключем.
Очевидно, що ця вимога не виконана для відношення СПІВРОБІТНИКИ-ПРОЕКТИ. Можна зробити його декомпозицію до відносин СПІВРОБІТНИКИ і СПІВРОБІТНИКИ-ПРОЕКТИ:
СПІВРОБІТНИКИ (СПІВР_НОМЕР, СПІВР_ІМ’Я)
Можливі ключі:
СПІВР_НОМЕР
СПІВР_ІМ’Я
Функціональна залежність:
СПІВР_НОМЕР -> СПІВР_ІМ’Я
СПІВР_ІМ’Я -> СПІВР_НОМЕР
СПІВРОБІТНИКИ-ПРОЕКТИ (СПІВР_НОМЕР, ПРО_НОМЕР, СПІВР_ЗАВДАН)
Можливий ключ:
СПІВР_НОМЕР, ПРО_НОМЕР
Функціональна залежність:
СПІВР_НОМЕР, ПРО_НОМЕР -> CПІВР_ЗАВДАН
Можлива альтернативна декомпозиція, якщо вибрати за основу СПІВР_ІМ’Я. У обох випадках відносини, що отримуються СПІВРОБІТНИКИ і СПІВРОБІТНИКИ-ПРОЕКТИ знаходяться в BCNF, і ним не властиві відмічені аномалії.
6.1.4. Четверта нормальна форма
Розглянемо приклад наступної схеми відношення:
ПРОЕКТИ (ПРО_НОМЕР, ПРО_СПІВР, ПРО_ЗАВДАН)
Відношення ПРОЕКТИ містить номери проектів, для кожного проекту список співробітників, які можуть виконувати проект, і список завдань, що передбачаються проектом. Співробітники можуть брати участь в декількох проектах, і різні проекти можуть включати однакові завдання.
Кожний кортеж відношення зв'язує деякий проект з співробітником, що бере участь в цьому проекті, і завданням, який співробітник виконує в рамках даного проекту (ми передбачаємо, що будь-який співробітник, що бере участь в проекті, виконує всі завдання, передбачені цим проектом). Внаслідок сформульованих вище умов єдиним можливим ключем відношення є складовою атрибут ПРО_НОМЕР, ПРО_СПІВР, ПРО_ЗАВДАН, і немає ніяких інших детермінантів. Отже, відношення ПРОЕКТИ знаходиться в BCNF. Але при цьому воно володіє недоліками: якщо, наприклад, деякий співробітник приєднується до даного проекту, необхідно вставити у відношення ПРОЕКТИ стільки кортежів, скільки завдань в ньому передбачено.
Визначення 10. Багатозначна залежність
У відношенні R (А, В, С) існує багатозначна залежність R.A -> -> R.B в тому і тільки в тому випадку, якщо безліч значень В, відповідне парі значень А і С, залежить тільки від А і не залежить від С.
У відношенні ПРОЕКТИ існують наступні дві багатозначна залежність:
ПРО_НОМЕР -> -> ПРО_СПІВР
ПРО_НОМЕР -> -> ПРО_ЗАВДАН
Легко показати, що в загальному випадку у відношенні R (А, В, С) існує багатозначна залежність R.A -> -> R.B в тому і тільки в тому випадку, коли існує багатозначна залежність R.A -> -> R.С.
Подальша нормалізація відносин, подібних відношенню ПРОЕКТИ, засновується на наступній теоремі:
Теорема Фейджіна
Відношення R (А, В, С) можна відобразити без втрат у відносини R1 (А, В) і R2 (А, С) в тому і тільки в тому випадку, коли існує MVD А -> -> В ¦ С.
Під відображенням без втрат розуміється такий спосіб декомпозиції відношення, при якому початкове відношення повністю і без надмірності відновлюється шляхом природного з'єднання отриманих відносин.
Визначення 11. Четверта нормальна форма
Відношення R знаходиться в четвертій нормальній формі (4NF) в тому і тільки в тому випадку, якщо у разі існування багатозначної залежності А -> -> В всі інші атрибути R функціонально залежать від А.
У нашому прикладі можна зробити декомпозицію відношення ПРОЕКТИ в два відношення ПРОЕКТИ-СПІВРОБІТНИКИ і ПРОЕКТИ-ЗАВДАННЯ:
ПРОЕКТИ-СПІВРОБІТНИКИ (ПРО_НОМЕР, ПРО_СПІВР)
ПРОЕКТИ-ЗАВДАННЯ (ПРО_НОМЕР, ПРО_ЗАВДАН)
Обидва ці відносини знаходяться в 4NF і вільні від відмічених аномалій.
6.1.5. П’ята нормальна форма
У всіх розглянутих до цього моменту нормалізаціях проводилася декомпозиція одного відношення в два. Іноді це зробити не вдається, але можлива декомпозиція в більше число відносин, кожне з яких володіє кращими властивостями.
Розглянемо, наприклад, відношення
СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ (СПІВР_НОМЕР, ВІД_НОМЕР, ПРО_НОМЕР)
Передбачимо, що один і той же співробітник може працювати в декількох відділах і працювати в кожному відділі над декількома проектами. Первинним ключем цього відношення є повна сукупність його атрибутів, відсутня функціональна і багатозначна залежність.
Тому відношення знаходиться в 4NF. Однак в ньому можуть існувати аномалії, які можна усунути шляхом декомпозиції в три відношення.
Визначення 12. Залежність з'єднання
Відношення R (X, Y,. .., Z) задовольняє залежність з'єднання * (X, Y,. .., Z) в тому і тільки в тому випадку, коли R відновлюється без втрат шляхом з'єднання своїх проекцій на X, Y,. .., Z.
Визначення 13. П'ята нормальна форма
Відношення R знаходиться в п'ятій нормальній формі (нормальній формі проекції-з'єднання - PJ/NF) в тому і тільки в тому випадку, коли будь-яка залежність з'єднання в R виходить з існування деякого можливого ключа в R.
Введемо наступні імена складових атрибутів:
СВ = {СПІВР_НОМЕР, ВІД_НОМЕР}
СП = {СПІВР_НОМЕР, ПРО_НОМЕР}
ВП = {ВІД_НОМЕР, ПРО_НОМЕР}
Передбачимо, що у відношенні СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ існує залежність з'єднання:
* (СВ, СП, ВП)
На прикладах легко показати, що при вставках і видаленнях кортежів можуть виникнути проблеми. Їх можна усунути шляхом декомпозиції початкового відношення в три нових відношення:
СПІВРОБІТНИКИ-ВІДДІЛИ (СПІВР_НОМЕР, ВІД_НОМЕР)
СПІВРОБІТНИКИ-ПРОЕКТИ (СПІВР_НОМЕР, ПРО_НОМЕР)
ВІДДІЛИ-ПРОЕКТИ (ВІД_НОМЕР, ПРО_НОМЕР)
П'ята нормальна форма - це остання нормальна форма, яку можна отримати шляхом декомпозиції. Її умови досить нетривіальні, і на практиці 5NF не використовується. Помітимо, що залежність з'єднання є узагальненням як багатозначної залежності, так і функціональної залежності.
6.2. Семантичне моделювання даних, ER-діаграми
Широке поширення реляційної СУБД і їх використання в самих різноманітних додатках показує, що реляційна модель даних достатня для моделювання предметних областей. Однак проектування реляційної бази даних в термінах відносин на основі стисло розглянутого нами механізму нормалізації часто являє собою дуже складний і незручний для проектувальника процес.
При цьому виявляється обмеженість реляційної моделі даних в наступних аспектах:
Модель не надає достатніх коштів для представлення значення даних. Семантика реальної предметної області повинна незалежним від моделі способом представлятися в голові проектувальника. Зокрема, це відноситься до згадуваної нами проблеми представлення обмежень цілісності.
Для багатьох додатків важко моделювати предметну область на основі плоских таблиць. У ряді випадків на самої початковій стадії проектування проектувальнику доводиться проводити насильство над собою, щоб описати предметну область у вигляді однієї (можливо, навіть ненормалізованої) таблиці.
Хоч весь процес проектування відбувається на основі обліку залежності, реляційна модель не надає яких-небудь коштів для представлення цієї залежності.
Незважаючи на те, що процес проектування починається з виділення деяких істотних для додатку об'єктів предметної області ("сутностей") і виявлення зв'язків між цими сутностями, реляційна модель даних не пропонує якого-небудь апарату для розділення сутностей і зв'язків.
6.2.1. Семантичні моделі даних
Потреби проектувальників баз даних в більш зручних і могутніх коштах моделювання предметної області спричинили до життя напрям семантичних моделей даних. При тому, що будь-яка розвинена семантична модель даних, як і реляційна модель, включає структурну, маніпуляційну і цілісну частини, головним призначенням семантичних моделей є забезпечення можливості вираження семантики даних.
Раніше, ніж ми коротко розглянемо особливості одній з поширених семантичних моделей, зупинимося на їх можливих застосуваннях.
Найчастіше на практиці семантичне моделювання використовується на першій стадії проектування бази даних. При цьому в термінах семантичної моделі проводиться концептуальна схема бази даних, яка потім вручну перетворюється до реляційної (або який-небудь інший) схеми. Цей процес виконується під управлінням методик, в яких досить чітко обумовлені всі етапи такого перетворення.
Менш часто реалізовується автоматизована компіляція концептуальної схеми в реляційну. При цьому відомі два підходи: на основі явного представлення концептуальної схеми як початкової інформації для компілятора і побудови інтегрованих систем проектування з автоматизованим створенням концептуальної схеми на основі інтерв'ю з експертами предметної області. І в тому, і в іншому випадку в результаті проводиться реляційна схема бази даних в третій нормальній формі (більш точно слід би сказати, що автору невідомі системи, що забезпечують більш високий рівень нормалізації).
Нарешті, третя можливість, яка ще не вийшла (або тільки виходить) за межі дослідницьких і експериментальних проектів, - це робота з базою даних в семантичній моделі, тобто СУБД, заснована на семантичних моделях даних. При цьому знов розглядаються два варіанти: забезпечення призначеного для користувача інтерфейсу на основі семантичної моделі даних з автоматичним відображенням конструкцій в реляційну модель даних (це задача приблизно такого ж рівня складності, як автоматична компіляція концептуальної схеми бази даних в реляційну схему) і пряма реалізація СУБД, заснована на якій-небудь семантичній моделі даних. Найбільш близько до другого підходу знаходиться сучасна об'єктно-орієнтована СУБД, моделі даних яких по багатьох параметрах близькі до семантичних моделей (хоч в деяких аспектах вони більш могутні, а в деяких - більш слабі).
6.2.2. Основні поняття моделі Entity-Relationship (Суть-Зв’язки)
Далі ми стисло розглянемо деякі межі однієї з найбільш популярних семантичних моделей даних - модель "Суті-Зв'язку" (часто її називають стисло ER-моделлю).
На використанні різновидів ER-моделі заснована більшість сучасних підходів до проектування баз даних (головним чином, реляційних). Модель була запропонована Ченом (Chen) в 1976 р. Моделювання предметної області базується на використанні графічних діаграм, що включають невелике число різнорідних компонентів. У зв'язку з наглядністю представлення концептуальних схем баз даних ER-моделі набули широкого поширення в системах CASE, підтримуючих автоматизоване проектування реляційних баз даних. Серед безлічі різновидів ER-моделей одна з найбільш розвинених застосовується в системі CASE фірми ORACLE. Її ми і розглянемо. Більш точно, ми зосередимося на структурній частині цієї моделі.
Основними поняттями ER-моделі є суть, зв'язок і атрибут.
Суть - це реальний або об'єкт, що представляється, інформація про яке повинна зберігатися і бути доступна. У діаграмах ER-моделі суть представляється у вигляді прямокутника, що містить ім'я суті. При цьому ім'я суті - це ім'я типу, а не деякого конкретного примірника цього типу. Для більшої виразності і кращого розуміння ім'я суті може супроводитися прикладами конкретних об'єктів цього типу.
Нижче зображена суть АЕРОПОРТ із зразковими об'єктами Шереметьево і Хитроу:
Кожний примірник суті повинен бути відмітний від будь-якого іншого примірника тієї ж суті (ця вимога в деякому роді аналогічна вимозі відсутності кортежів-дублікатів в реляційних таблицях).
Зв'язок - це асоціація, що графічно зображається, що встановлюється між двома сутностями. Ця асоціація завжди є бінарною і може існувати між двома різними сутностями або між суттю і їй же самій (рекурсивний зв'язок). У будь-якому зв'язку виділяються два кінці (відповідно до існуючої пари сутностей, що зв'язуються ), на кожному з яких вказується ім'я кінця зв'язку, міра кінця зв'язку (скільки примірників даної суті зв'язується), обов'язковість зв'язку (тобто чи будь-який примірник даної суті повинен брати участь в даному зв'язку).
Зв'язок представляється у вигляді лінії, що зв'язує дві суті або ведучої від суті до неї ж самої. При це в місці "стиковки" зв'язку з суттю використовуються триточковий вхід в прямокутник суті, якщо для цієї суті в зв'язку можуть використовуватися багато (many) примірників суті, і одноточковий вхід, якщо в зв'язку може брати участь тільки один примірник суті. Обов'язковий кінець зв'язку зображається суцільною лінією, а необов'язковий - переривистою лінією.
Як і суть, зв'язок - це типове поняття, всі примірники обох пар сутностей, що зв'язуються підкоряються правилам скріплення.
У зображеному нижче прикладі зв'язок між сутностями КВИТОК і ПАСАЖИР зв'язує квитки і пасажирів. При тому кінець суті з ім'ям "для" дозволяє зв'язувати з одним пасажиром більше за один квиток, причому кожний квиток повинен бути пов'язаний з яким-небудь пасажиром. Кінець суті з ім'ям "має" означає, що кожний квиток може належати тільки одному пасажиру, причому пасажир не зобов'язаний мати хоч би один квиток.
Лаконічним усним трактуванням зображеної діаграми є наступна:
Кожний КВИТОК призначений для одного і тільки одного ПАСАЖИРА;
Кожний ПАСАЖИР може мати один або більше КВИТКІВ.
На наступному прикладі зображений рекурсивний зв'язок, що зв'язує суть ЛЮДИНА з нею ж самою. Кінець зв'язку з ім'ям "син" визначає той факт, що у одного батька може бути більш ніж один син. Кінець зв'язку з ім'ям "батько" означає, що не у кожної людини можуть бути сини.
Лаконічним усним трактуванням зображеної діаграми є наступна:
Кожна ЛЮДИНА є сином однієї і тільки однієї ЛЮДИНИ;
Кожна ЛЮДИНА може бути батьком для одної або більше ЛЮДЕЙ.
Атрибутом суті є будь-яка деталь, яка служить для уточнення, ідентифікації, класифікації, числової характеристики або вираження стану суті. Імена атрибутів заносяться в прямокутник, що зображає суть, під ім'ям суті і зображаються малими буквами, можливо, з прикладами.
Приклад:
Унікальним ідентифікатором суті є атрибут, комбінація атрибутів, комбінація зв'язків або комбінація зв'язків і атрибутів, що унікально відрізняє будь-який примірник суті від інших примірників суті того ж типу.
6.2.3. Нормальні форми ER-схем
Як і в реляційних схемах баз даних, в ER-схемах вводиться поняття нормальних форм, причому їх значення дуже близько відповідає значенню реляційних нормальних форм. Помітимо, що формулювання нормальних форм ER-схем роблять більш зрозумілими значення нормалізації реляційних схем. Ми приведемо тільки дуже короткі і неформальні визначення трьох перших нормальних форм.
У першій нормальній формі ER-схеми усуваються атрибути, що повторюються або групи атрибутів, тобто проводиться виявлення неявних сутностей, "замаскованих" під атрибути.
У другій нормальній формі усуваються атрибути, що залежать тільки від частини унікального ідентифікатора. Ця частина унікального ідентифікатора визначає окрему суть.
У третій нормальній формі усуваються атрибути, що залежать від атрибутів, що не входять в унікальний ідентифікатор. Ці атрибути є основою окремої суті.
6.2.4. Більш складні елементи ER-моделі
Ми зупинилися тільки на самих основних і найбільш очевидних поняттях ER-моделі даних. До числа більш складних елементів моделі відносяться наступні:
Підтипи і супертипи сутностей. Як в мовах програмування з розвиненими типовими системами (наприклад, в мовах об'єктно-орієнтованого програмування), вводиться можливість успадкування типу суті, виходячи з одного або декількох супертипів. Цікавий нюанс пов'язаний з необхідністю графічного зображення цього механізму.
Зв'язки "many-to-many". Іноді буває необхідно зв'язувати сутності таким чином, що з обох кінців зв'язку можуть бути присутнім декілька примірників суті (наприклад, всі члени кооперативу спільно володіють майном кооперативу). Для цього вводиться різновид зв'язку "багато-до-багатьох".
Міри зв'язку, що уточнюються. Іноді буває корисно визначити можливу кількість примірників суті, що беруть участь в даному зв'язку (наприклад, службовцеві дозволяється брати участь не більш, ніж в трьох проектах одночасно). Для вираження цього семантичного обмеження дозволяється вказувати на кінці зв'язку її максимальну або обов'язкову міру.
Каскадні видалення примірників сутностей. Деякі зв'язки бувають настільки сильними (звичайно, у разі зв'язку "один-до-багатьох"), що при видаленні опорного примірника суті (відповідного кінцю зв'язку "один") треба видалити і всі примірники суті, відповідні кінцю зв'язки "багато". Відповідну вимогу "каскадного видалення" можна сформулювати при визначенні суті.
Домени. Як і у разі реляційної моделі даних буває корисна можливість визначення потенційно допустимої безлічі значень атрибута суті (домену).
Ці і інші більш складні елементи моделі даних "Суті-Зв'язку" роблять її істотно більш могутньої, але одночасно дещо ускладнюють її використання. Звичайно, при реальному використанні ER-діаграм для проектування баз даних необхідно ознайомитися з всіма можливостями.
У нашій лекції ми трохи детальніше розберемо тільки один із згаданих елементів - підтип суті.
Суть може бути розщепленням на два або більш взаємно що виключають підтипу, кожний з яких включає загальні атрибути і/або зв'язки. Ці загальні атрибути і/або зв'язки явно визначаються один раз на більш високому рівні. У підтипах можуть визначатися власні атрибути і/або зв'язки. У принципі підтипізації може продовжуватися на більш низьких рівнях, але досвід показує, що в більшості випадків виявляється досить двох-трьох рівнів.
Суть, на основі якої визначаються підтипи, називається супертипом. Підтипи повинні утворювати повну безліч, тобто будь-який примірник супертипа повинен відноситися до деякого підтипу. Іноді для повноти доводиться визначати додаткову підтип ІНШІ.
Приклад: Супертип ЛІТАЛЬНИЙ АПАРАТ
Як належить це читати? Від супертипа: ЛІТАЛЬНИЙ АПАРАТ, який повинен бути АЕРОПЛАНОМ, ВЕРТОЛЬОТОМ, ПТАХОЛЬОТОМ або ІНШИМ ЛІТАЛЬНИМ АПАРАТОМ. Від підтипу: ВЕРТОЛІТ, який відноситься до типу ЛІТАЛЬНОГО АПАРАТУ. Від підтипу, який є одночасно супертипа: АЕРОПЛАН, який відноситься до типу ЛІТАЛЬНОГО АПАРАТУ і повинен бути ПЛАНЕРОМ або МОТОРНИМ ЛІТАКОМ.
Іноді зручно мати два або більш різних розбиття суті на підтипи. Наприклад, суть ЛЮДИНА може бути розбита на підтипи по професійній ознаці (ПРОГРАМІСТ, ДОЯРКА і т.д.), а може - по статевій ознаці (ЧОЛОВІК, ЖІНКА).
6.2.5. Отримання реляційної схеми з ER-схеми
Крок 1. Кожна проста суть перетворюється в таблицю. Проста суть - суть, що не є підтипом і що не має підтипів. Ім'я суті стає ім'ям таблиці.
Крок 2. Кожний атрибут стає можливим стовпцем з тим же ім'ям; може вибиратися більш точний формат. Стовпці, відповідні необов'язковим атрибутам, можуть містити невизначені значення; стовпці, відповідні обов'язковим атрибутам, - не можуть.
Крок 3. Компоненти унікального ідентифікатора суті перетворюються в первинний ключ таблиці. Якщо є декілька можливих унікальних ідентифікатора, вибирається той, що найбільш використовується. Якщо до складу унікального ідентифікатора входять зв'язки, до числа стовпців первинного ключа додається копія унікального ідентифікатора суті, що знаходиться на далекому кінці зв'язку (цей процес може продовжуватися рекурсивно). Для іменування цих стовпців використовуються імена кінців зв'язків і/або імена сутностей.
Крок 4. Зв'язки багато-до-одного (і один-до-одного) стають зовнішніми ключами. Тобто робиться копія унікального ідентифікатора з кінця зв'язку "один", і відповідні стовпці складають зовнішній ключ. Необов'язкові зв'язки відповідають стовпцям, що допускають невизначені значення; обов'язкові зв'язки - стовпцям, що не допускають невизначені значення.
Крок 5. Індекси створюються для первинного ключа (унікальний індекс), зовнішніх ключів і тих атрибутів, на яких мається намір в основному базувати запити.
Крок 6. Якщо в концептуальній схемі були присутні підтипи, то можливі два способи:
всі підтипи в одній таблиці (а)
для кожного підтипу - окрема таблиця (б)
При застосуванні способу (а) таблиця створюється для найбільш зовнішнього супертипа, а для підтипів можуть створюватися уявлення. У таблицю додається принаймні один стовпець, що містить код ТИПУ; він стає частиною первинного ключа.
При використанні методу (б) для кожного підтипу першого рівня (для більш нижніх - уявлення) супертип відтворюється за допомогою уявлення UNION (з всіх таблиць підтипів вибираються загальні стовпці - стовпці супертипа).
Все в одній таблиці | Таблиця —на підтип
Переваги
Все зберігається разом
Легкий доступ до супертип і підтипу
Потрібно менше таблиць | Більш ясні правила підтипів
Програми працюють тільки з потрібними таблицями
Недоліки
Дуже загальне рішення
Потрібна додаткова логіка роботи з різними наборами стовпців і різними обмеженнями
Потенційне вузьке місце (в зв’язку з блокуванням)
Стовпці підтипів повинні бути необов’язковими
В деякій СУБД для зберігання невизначених значень потрібна додаткова пам’ять | Дуже багато таблиць
Збентежуючи стовпці в уявленні UNION
Потенційна втрата продуктивності при роботі через UNION
Над супертипом неможливі модифікації
Крок 7. Є два способи роботи при наявності виключаючих зв'язків:
загальний домен (а)
явні зовнішні ключі (б)
Якщо зовнішні ключі, що залишаються всі в одному домені, тобто мають загальний формат (спосіб (а)), то створюються два стовпці: ідентифікатор зв'язку і ідентифікатор суті. Стовпець ідентифікатора зв'язку використовується для розрізнення зв'язків, що покриваються дугою виключення. Стовпець ідентифікатора суті використовується для зберігання значень унікального ідентифікатора суті на далекому кінці відповідного зв'язку.
Якщо результуючі зовнішні ключі не відносяться до одного домену, то для кожного зв'язку, що покривається дугою виключення, створюються явні стовпці зовнішніх ключів; всі ці стовпці можуть містити невизначені значення.
Загальний домен | Явні зовнішні ключі
Переваги
Потрібно тільки два стовпці | Умови з’єднання — явні
Недоліки
Обидва додаткових атрибута повинні використовуватися в з’єднаннях | Дуже багато стовпців
Альтернативні моделі сутностей:
Варіант 1 (поганий)
Варіант 2 (істотно краще, якщо підтипи дійсно існують)
Варіант 3 (годиться при наявності осмисленого супертипа D).

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать