Введення в СУБД: ЧАСТИНА 4

1. Глава 6. Проектування реляційних БД на основі принципів нормалізації і семантичне моделювання баз даних
2. 6.1 Проектування реляційних баз даних з використанням принципів нормалізації
3. 6.1.1. Друга нормальна форма
4. СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ
5. СПІВРОБІТНИКИ-ВІДДІЛИ
6. СПІВРОБІТНИКИ-ПРОЕКТИ
7. 6.1.2. Третя нормальна форма
8. 6.1.3. Нормальна форма Бойса-Кодда
9. 6.1.4. Четверта нормальна форма
10. теорема Фейджин
11. 6.1.5. П'ята нормальна форма
12. 6.2 Семантичне моделювання даних, ER-діаграми
13. 6.2.1. Семантичні моделі даних
14. 6.2.3. Семантична модель Entity-Relationship (Сутність-Зв'язок)
15. Основні Поняття і визначення

С.Д. Кузнецов

Інститут системного програмування РАН, Асоціація користувачів ОС UNIX (SUUG), Московська секція ACM SIGMOD, [email protected]

Глава 6. Проектування реляційних БД на основі принципів нормалізації і семантичне моделювання баз даних Початком будь-якого великого справи є проект

Глава 6. Проектування реляційних БД на основі принципів нормалізації і семантичне моделювання баз даних

Початком будь-якого великого справи є проект

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

• Відображення об'єктів предметної області в абстрактні об'єкти моделі даних таким чином, щоб це відображення не суперечило семантиці предметної області і було по можливості найкращим (ефективним, зручним і т.д.). Часто цю проблему називають проблемою логічного проектування баз даних.
• Забезпечення ефективного виконання запитів до бази даних, тобто раціональне розташування даних у зовнішній пам'яті, створення корисних додаткових структур (наприклад, індексів) з урахуванням особливостей конкретної СУБД. Цю проблему називають проблемою фізичного проектування баз даних.

У разі реляційних баз даних важко уявити будь-які загальні рецепти по частині фізичного проектування. Тут дуже багато залежить від використовуваної СУБД. Наприклад, при роботі з СУБД Ingres можна вибирати один із запропонованих способів фізичної організації відносин, при роботі з System R слід було б насамперед подумати про кластеризації відносин і необхідному наборі індексів і т.д. Тому ми обмежимося питаннями логічного проектування реляційних баз даних, які істотні при використанні будь-якої реляційної СУБД.

Більш того, ми не будемо торкатися дуже важливого аспекту проектування - визначення обмежень цілісності (за винятком обмеження первинного ключа). Справа в тому, що при використанні СУБД з розвиненими механізмами обмежень цілісності (наприклад, SQL-орієнтованих систем) важко запропонувати який-небудь загальний підхід до визначення обмежень цілісності. Ці обмеження можуть мати дуже загальний вигляд, і їх формулювання поки відноситься скоріше до області мистецтва, ніж інженерного майстерності. Найбільше, що пропонується з цього приводу в літературі, - це автоматична перевірка несуперечності набору обмежень цілісності.

Тому будемо вважати, що проблема проектування реляційної бази даних складається в обґрунтованому прийнятті рішень про те, з яких відносин повинна складатися БД і які атрибути повинні бути у цих відносин.

Зауважимо, що ми навмисно спрощуємо проблему логічного проектування, щоб мати можливість представити найбільш загальні ідеї. Більш конкретні методи і алгоритми можна знайти в різних статтях цього журналу.

6.1 Проектування реляційних баз даних з використанням принципів нормалізації

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

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

В теорії реляційних баз даних звичайно виділяється наступна послідовність нормальних форм:

• перша нормальна форма (1NF);
• друга нормальна форма (2NF);
• третя нормальна форма (3NF);
• нормальна форма Бойса-Кодда (BCNF) (правильніше було б вважати цю нормальну форму третьої, проте з історичних причин третій ступінь виявилася зайнятою до моменту винаходу BCNF, через що вона і отримала нестандартну назву);
• четверта нормальна форма (4NF);
• п'ята нормальна форма, або нормальна форма проекції-з'єднання (5NF або PJ / NF).

Основні властивості нормальних форм:

• кожна наступна нормальна форма в деякому сенсі покращує властивості попередньої;
• при переході до наступної нормальній формі властивості попередніх нормальних форм зберігаються.

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

Найбільш важливі на практиці нормальні форми відносин грунтуються на фундаментальному в теорії реляційних баз даних понятті функціональної залежності. Для подальшого викладу нам будуть потрібні кілька визначень.

Визначення 1: Функціональна залежність (functional dependence - FD). Відносно R атрибут Y функціонально залежить від атрибута X (X і Y можуть бути складовими атрибутами, тобто реально складатися з декількох атомарних атрибутів) в тому і тільки в тому випадку, якщо кожному значенню X відповідає в точності одне значення Y:

RX -> RY

Зауваження: Термін "функціональна залежність" не випадковий, оскільки в точності відповідає математичному поняттю функції.

Визначення 2: Повна функціональна залежність. Функціональна залежність RX -> RY називається повною, якщо атрибут Y не залежить функціонально від будь-якого точного підмножини X (точним підмножиною множини X називається будь-який його підмножина, що не співпадає з X).

Визначення 3: Транзитивная функціональна залежність. Функціональна залежність RX -> RY називається транзитивної, якщо існує такий атрибут Z, що є функціональні залежності RX -> RZ і RZ -> RY

Визначення 4: Можливий ключ (alternative key). Можливим ключем відносини називається його атомарний або складовою атрибут, значення якого повністю функціонально визначають значення всіх інших атрибутів відносини.

Визначення 5: неключових атрибут. Неключових атрибутом називається будь-який атрибут відносини, що не входить до складу первинного ключа.

Визначення 6: Взаємно незалежні атрибути. Два або більше атрибута називаються взаємно незалежними, якщо жоден з цих атрибутів не є функціонально залежним від інших атрибутів.

6.1.1. Друга нормальна форма

Розглянемо наступний приклад схеми відносини:

СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ

(СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)

Первинний ключ:

СОТР_НОМЕР, ПРО_НОМЕР

Функціональні залежності:

СОТР_НОМЕР -> СОТР_ЗАРП СОТР_НОМЕР -> ОТД_НОМЕР ОТД_НОМЕР -> СОТР_ЗАРП СОТР_НОМЕР, ПРО_НОМЕР -> СОТР_ЗАДАН

Як видно, хоча первинним ключем є складовою атрибут СОТР_НОМЕР, ПРО_НОМЕР, атрибути СОТР_ЗАРП і ОТД_НОМЕР функціонально залежать від частини первинного ключа, тобто атрибута СОТР_НОМЕР. В результаті, ми не зможемо вставити у відношення СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ кортеж, що описує співробітника, який ще не виконує жодного проекту (первинний ключ не може містити невизначене значення). При видаленні кортежу ми не тільки руйнуємо зв'язок даного співробітника з даним проектом, але втрачаємо інформацію про те, що він працює в деякому відділі. При перекладі співробітника в інший відділ ми будемо змушені модифікувати всі кортежі, що описують цього співробітника, або отримаємо неузгоджений результат. Такі неприємні явища називаються аномаліями схеми відносини. Вони усуваються шляхом нормалізації.

Визначення 7. Друга нормальна форма. Відношення R знаходиться в другій нормальній формі (2NF) в тому і тільки в тому випадку, коли знаходиться в 1NF і кожен неключових атрибут повністю залежить від первинного ключа.

Можна зробити наступну декомпозицію відношення СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ в два відношення СПІВРОБІТНИКИ-ВІДДІЛИ і СПІВРОБІТНИКИ-ПРОЕКТИ:

СПІВРОБІТНИКИ-ВІДДІЛИ

(СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР)

Первинний ключ:

СОТР_НОМЕР

Функціональні залежності:

СОТР_НОМЕР -> СОТР_ЗАРП СОТР_НОМЕР -> ОТД_НОМЕР ОТД_НОМЕР -> СОТР_ЗАРП

СПІВРОБІТНИКИ-ПРОЕКТИ

(СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)

Первинний ключ:

СОТР_НОМЕР, ПРО_НОМЕР

Функціональна залежність:

СОТР_НОМЕР, ПРО_НОМЕР -> СОТР_ЗАДАН

Кожне з цих двох відносин знаходиться в 2NF, і в них усунені зазначені вище аномалії (легко перевірити, що всі згадані вище операції виконуються без проблем).

6.1.2. Третя нормальна форма

Розглянемо ще раз ставлення СПІВРОБІТНИКИ-ВІДДІЛИ, що знаходиться в 2NF. Зауважимо, що функціональна залежність СОТР_НОМЕР СОТР_ЗАРП є транзитивною; вона є наслідком (в сенсі математичної логіки) функціональних залежностей СОТР_НОМЕР ОТД_НОМЕР і ОТД_НОМЕР СОТР_ЗАРП. Іншими словами, заробітна плата співробітника насправді є характеристикою не співробітник, а відділу, в якому він працює (це не дуже природне припущення, але достатня для прикладу).

В результаті, ми не зможемо занести в базу даних інформацію, що характеризує заробітну плату відділу, до тих пір, поки в цьому відділі чи не з'явиться хоча б один співробітник (первинний ключ не може містити невизначене значення). При видаленні кортежу, що описує останнього співробітника даного відділу, ми втратимо інформації про заробітну плату відділу. Щоб узгодженим чином змінити заробітну плату відділу, ми будемо змушені попередньо знайти всі кортежі, що описують співробітників цього відділу. Тобто щодо СПІВРОБІТНИКИ-ВІДДІЛИ і раніше існують аномалії. Їх можна усунути шляхом подальшої нормалізації.

Визначення 8. Третя нормальна форма. Відношення R знаходиться в третій нормальній формі (3NF) в тому і тільки в тому випадку, якщо знаходиться в 2NF і кожен неключових атрибут нетранзитивно залежить від первинного ключа.

Еквівалентним визначенням (доказ еквівалентності ми залишаємо читачеві) є наступне:

Визначення 9. Третя нормальна форма (альтернативне визначення). Відношення R знаходиться в третій нормальній формі (3NF) в тому і тільки в тому випадку, якщо всі неключових атрибути R взаємно незалежні і повністю залежать від первинного ключа.

Можна зробити декомпозицію відношення СПІВРОБІТНИКИ-ВІДДІЛИ в два відношення СПІВРОБІТНИКИ і ВІДДІЛИ:

СПІВРОБІТНИКИ (СОТР_НОМЕР, ОТД_НОМЕР)

Первинний ключ:

СОТР_НОМЕР

Функціональна залежність:

СОТР_НОМЕР -> ТД_НОМЕР

ВІДДІЛИ (ОТД_НОМЕР, СОТР_ЗАРП)

Первинний ключ:

ОТД_НОМЕР

Функціональна залежність:

ОТД_НОМЕР -> СОТР_ЗАРП

Кожне з цих двох відносин знаходиться в 3NF і вільно від зазначених аномалій.

На практиці третя нормальна форма схем відносин є достатньою в більшості випадків і приведенням до третьої нормальної формі процес проектування реляційної бази даних зазвичай закінчується. Однак іноді корисно продовжити процес нормалізації.

6.1.3. Нормальна форма Бойса-Кодда

Розглянемо наступний приклад схеми відносини:

СПІВРОБІТНИКИ-ПРОЕКТИ (СОТР_НОМЕР, СОТР_ИМЯ, ПРО_НОМЕР, СОТР_ЗАДАН)

Можливі ключі (зверніть увагу, що на цій стадії нормалізації до уваги приймаються існування можливих ключів):

СОТР_НОМЕР, ПРО_НОМЕР СОТР_ИМЯ, ПРО_НОМЕР

Функціональні залежності:

СОТР_НОМЕР -> СОТР_ИМЯ СОТР_НОМЕР -> ПРО_НОМЕР СОТР_ИМЯ -> СОТР_НОМЕР СОТР_ИМЯ -> ПРО_НОМЕР СОТР_НОМЕР, ПРО_НОМЕР -> СОТР_ЗАДАН СОТР_ИМЯ, ПРО_НОМЕР -> СОТР_ЗАДАН

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

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

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

Визначення 11. Нормальна форма Бойса-Кодда. Відношення R знаходиться в нормальній формі Бойса-Кодда (BCNF) в тому і тільки в тому випадку, якщо кожен детермінант є можливим ключем.

Зауваження: Легко помітити, що якщо в плані є тільки один можливий ключ (який є первинним ключем), то це визначення стає еквівалентним визначенням третьої нормальної форми.

Очевидно, що ця вимога не виконана для відношення СПІВРОБІТНИКИ-ПРОЕКТИ. Можна зробити його декомпозицію до відносин СПІВРОБІТНИКИ і СПІВРОБІТНИКИ-ПРОЕКТИ:

СПІВРОБІТНИКИ (СОТР_НОМЕР, СОТР_ИМЯ)

Можливі ключі:

СОТР_НОМЕР СОТР_ИМЯ

Функціональні залежності:

СОТР_НОМЕР -> СОТР_ИМЯ СОТР_ИМЯ -> СОТР_НОМЕР СПІВРОБІТНИКИ-ПРОЕКТИ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)

Можливий ключ:

СОТР_НОМЕР, ПРО_НОМЕР

Функціональні залежності:

СОТР_НОМЕР, ПРО_НОМЕР -> СОТР_ЗАДАН

Можлива альтернативна декомпозиція, якщо вибрати за основу СОТР_ИМЯ. В обох випадках одержувані відносини СПІВРОБІТНИКИ і СПІВРОБІТНИКИ-ПРОЕКТИ знаходяться в BCNF, і їм не властиві відмічені аномалії.

6.1.4. Четверта нормальна форма

Розглянемо приклад такої схеми відносини:

ПРОЕКТИ (ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН)

Ставлення ПРОЕКТИ кімнаті конференцій проектів, для кожного проекту - список співробітників, які можуть виконувати проект, і список завдань, передбачених проектом. Співробітники можуть брати участь в декількох проектах, і різні проекти можуть включати однакові завдання.

Кожен кортеж відносини пов'язує певний проект зі співробітником, які беруть участь в цьому проекті, і завданням, який співробітник виконує в рамках даного проекту (ми припускаємо, що будь-який співробітник, що бере участь в проекті, виконує всі завдання, передбачені цим проектом). Унаслідок сформульованих вище умов єдиним можливим ключем відношення є складовою атрибут ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН, і немає ніяких інших детермінантів. Отже, ставлення ПРОЕКТИ знаходиться в BCNF. Але при цьому воно має недоліки: якщо, наприклад, деякий співробітник приєднується до даного проекту, необхідно вставити в відношення ПРОЕКТИ стільки кортежів, скільки завдань в ньому передбачено.

Визначення 12. Багатозначна залежність. Відносно R (A, B, C) існує багатозначна залежність (multi-valued dependence - MVD) RA -> -> RB в тому і тільки в тому випадку, якщо безліч значень B, відповідне парі значень A і C, залежить тільки від A і не залежить від С.

Відносно ПРОЕКТИ існують наступні дві багатозначні залежності:

ПРО_НОМЕР -> -> ПРО_СОТР ПРО_НОМЕР -> -> ПРО_ЗАДАН

Неважко показати, що в загальному випадку у відношенні R (A, B, C) існує багатозначна залежність RA -> -> RB в тому і тільки в тому випадку, коли існує багатозначна залежність RA -> -> RC Тому далі ми вживаємо позначення A -> -> B | C в тому сенсі, що одночасно існують MVD A -> -> B і A -> -> C.

Подальша нормалізація відносин, подібних відношенню ПРОЕКТИ, грунтується на наступній теоремі:

теорема Фейджин

Відношення R (A, B, C) можна спроектувати без втрат у відносини R1 (A, B) і R2 (A, C) в тому і тільки в тому випадку, коли існує MVD A -> -> B | C.

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

Визначення 13. Четверта нормальна форма. Відношення R знаходиться в четвертій нормальній формі (4NF) в тому і тільки в тому випадку, якщо в разі існування багатозначної залежності A "" B всі інші атрибути R функціонально залежать від A.

У нашому прикладі можна зробити декомпозицію відносини ПРОЕКТИ в два відношення ПРОЕКТИ-СПІВРОБІТНИКИ і ПРОЕКТИ-ЗАВДАННЯ:

ПРОЕКТИ-СПІВРОБІТНИКИ (ПРО_НОМЕР, ПРО_СОТР) ПРОЕКТИ-ЗАВДАННЯ (ПРО_НОМЕР, ПРО_ЗАДАН).

Обидва ці відносини перебувають у 4NF і вільні від зазначених аномалій.

6.1.5. П'ята нормальна форма

У всіх розглянутих до цього моменту нормалізації проводилася декомпозиція одного відношення в два. Іноді це зробити не вдається, але можлива декомпозиція в більше число відносин, кожна з яких має кращі властивості.

Розглянемо, наприклад, ставлення

СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ (СОТР_НОМЕР, ОТД_НОМЕР, ПРО_НОМЕР)

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

Тому Ставлення знаходиться в 4NF. Однак в ньому можуть існувати аномалії, які можна усунути шляхом декомпозиції в три відносини.

Визначення 14. Залежність з'єднання. Відношення R (X, Y, ..., Z) задовольняє залежності з'єднання * (X, Y, ..., Z) в тому і тільки в тому випадку, коли R відновлюється без втрат шляхом з'єднання своїх проекцій на X, Y, ..., Z.

Визначення 15. П'ята нормальна форма. Відношення R знаходиться в п'ятій нормальній формі (нормальній формі проекції-з'єднання - PJ / NF) в тому і тільки в тому випадку, коли будь-яка залежність з'єднання в R випливає з існування деякого можливого ключа в R.

Введемо наступні імена складових атрибутів:

СО = {СОТР_НОМЕР, ОТД_НОМЕР} СП = {СОТР_НОМЕР, ПРО_НОМЕР} ОП = {ОТД_НОМЕР, ПРО_НОМЕР}

Припустимо, що в відношенні СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ існує залежність з'єднання:

(СО, СП, ОП)

На прикладах можна легко показати, що при вставках і удалениях кортежів можуть виникнути проблеми. Їх можна усунути шляхом декомпозіі вихідного відносини в три нових відносини:

СПІВРОБІТНИКИ-ВІДДІЛИ (СОТР_НОМЕР, ОТД_НОМЕР) СПІВРОБІТНИКИ-ПРОЕКТИ (СОТР_НОМЕР, ПРО_НОМЕР) ВІДДІЛИ-ПРОЕКТИ (ОТД_НОМЕР, ПРО_НОМЕР)

П'ята нормальна форма - це остання нормальна форма, яку можна отримати шляхом декомпозиції. Її умови досить нетривіальні, і на практиці 5NF не використовується. Зауважимо, що залежність з'єднання є узагальненням як багатозначної залежності, так і функціональної залежності.

6.2 Семантичне моделювання даних, ER-діаграми

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

При цьому проявляється обмеженість реляційної моделі даних в таких аспектах:

• Модель не надає достатніх коштів для подання сенсу даних. Сематіка реальної предметної області повинна незалежним від моделі способом представлятися в голові проектувальника. Зокрема, це відноситься до згадуваної нами проблеми уявлення обмежень цілісності.
• Для багатьох додатків важко моделювати предметну область на основі плоских таблиць. У ряді випадків на самій початковій стадії проектування проектувальнику доводиться виробляти насильство над собою, щоб описати предметну область у вигляді однієї (можливо навіть ненормалізованих) таблиці.
• Хоча весь процес проектування відбувається на основі врахування залежностей, реляційна модель не надає будь-яких засобів для подання цих залежностей.
• Незважаючи на те, що процес проектування починається з виділення деяких істотних для додатка об'єктів предметної області ( "сутностей") і виявлення зв'язків між цими сутностями, реляційна модель даних не пропонує будь-якого апарату для поділу сутностей і зв'язків.

6.2.1. Семантичні моделі даних

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

Перш, ніж ми коротко розглянемо особливості однієї з поширених семантичних моделей, зупинимося на їх можливі застосування.

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

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

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

6.2.3. Семантична модель Entity-Relationship (Сутність-Зв'язок)

Далі ми коротко розглянемо деякі риси однієї з найбільш популярних семантичних моделей даних - модель "Сутність-Зв'язок" (часто її називають коротко ER-моделлю).

На використанні різновидів ER-моделі засновано більшість сучасних підходів до проектування баз даних (головним чином, реляційних). Модель була запропонована Ченом (Chen) в 1976 р (оригінальна стаття Чена опублікована в третьому номері нашого журналу). Моделювання предметної області базується на використанні графічних діаграм, що включають невелике число різнорідних компонентів. У зв'язку з наочністю подання концептуальних схем баз даних ER-моделі отримали широке поширення в системах CASE, що підтримують автоматизоване проектування реляційних баз даних. Серед безлічі різновидів ER-моделей одна з найбільш розвинених застосовується в системі CASE фірми ORACLE. Її ми і розглянемо.

Точніше кажучи, ми зосередимося на структурній частині цієї моделі.

Основні Поняття і визначення

Основними поняттями ER-моделі є сутність, зв'язок і атрибут.

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

Нижче зображена сутність (точніше, тип сутності) АЕРОПОРТ з зразковими об'єктами Шереметьєво і Хітроу:

Кожен екземпляр суті повинен бути відрізнити від будь-якого іншого примірника тієї ж сутності (це вимога до певної міри аналогічно вимогу відсутності кортежів-дублікатів в реляційних таблицях або вимозі ідентифікованих об'єктів (object identity) в об'єктно-орієнтованих системах).

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

Зв'язок представляється у вигляді лінії, що зв'язує дві сутності або веде від суті до неї ж самої. При цьому в місці "стикування" зв'язку з сутністю використовуються триточковий вхід в прямокутник суті, якщо для цієї сутності в зв'язку можуть використовуватися багато (many) примірників суті, і одноточковий вхід, якщо в зв'язку може брати участь тільки один екземпляр сутності. Обов'язковий кінець зв'язку зображається суцільною лінією, а необов'язковий - переривчастою лінією.

Як і сутність, зв'язок - це типове поняття, всі екземпляри обох пар пов'язують сутностей підкоряються правилам зв'язування.

У зображеному нижче прикладі зв'язок між сутностями КВИТОК і ПАСАЖИР пов'язує квитки і пасажирів. При тому кінець сутності з ім'ям "для" дозволяє пов'язувати з одним пасажиром більше одного квитка, причому кожен квиток повинен бути пов'язаний з будь-яким пасажиром. Кінець сутності з ім'ям "має" означає, що кожен квиток може належати тільки одному пасажиру, причому пасажир не зобов'язаний мати хоча б один квиток.

Лаконічній усній трактуванням зображеної діаграми є наступна:

• Кожен КВИТОК призначений для одного і тільки одного ПАСАЖИРА;
• Кожен ПАСАЖИР може мати один або більше КВИТКІВ.

На наступному прикладі зображена рекурсивна зв'язок, що зв'язує сутність ЛЮДИНА з нею ж самою. Кінець зв'язку з ім'ям "син" визначає той факт, що у одного батька може бути більш ніж один син. Кінець зв'язку з ім'ям "батько" означає, що не у кожної людини можуть бути сини.

Лаконічній усній трактуванням зображеної діаграми є наступна:

• Кожен ЛЮДИНА є сином одного і тільки одного ЛЮДИНИ;
• Кожен ЛЮДИНА може бути батьком для одного або більше ЛЮДЕЙ ( "людина").

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

приклад:

Унікальним ідентифікатором суті є атрибут, комбінація атрибутів, комбінація зв'язків або комбінація зв'язків та атрибутів, унікально відрізняє будь-який екземпляр сужності від інших екземплярів сутності того ж типу.

Як і в реляційних схемах баз даних, в ER-схемах вводиться поняття нормальних форм, причому їх зміст дуже близько відповідає змісту реляційних нормальних форм. Зауважимо, що формулювання нормальних форм ER-схем роблять більш зрозумілим сенс нормалізації реляційних схем. Ми наведемо лише дуже короткі і неформальні визначення трьох перших нормальних форм.

У першій нормальній формі ER-схеми усуваються повторювані атрибути або групи атрибутів, тобто проводиться виявлення неявних сутностей, "замаскованих" під атрибути.

У другій нормальній формі устаняются атрибути, що залежать тільки від частини унікального ідентифікатора. Ця частина унікального ідентифікатора визначає окрему сутність.

У третій нормальній формі усуваються атрибути, які залежать від атрибутів, що не входять в унікальний ідентифікатор. Ці атрибути є основою окремої сутності.

Ми зупинилися лише на самих основних і найбільш очевидних поняттях ER-моделі даних. До числа найбільш складних елементів моделі відносяться наступні:

• Підтипи і супертіпи сутностей. Як в мовах програмування з розвиненими типовими системами (наприклад, в мовах об'єктно-орієнтованого програмування), вводиться можливість наслідування типу сутності, виходячи з одного або декількох супертіпа. Цікаві нюанси пов'язані з необходмости графічного зображення цього механізму.
• Зв'язки "many-to-many". Іноді буває необхідно зв'язувати суті таким чином, що з обох кінців зв'язку можуть бути присутні кілька екземплярів сутності (наприклад, всі члени кооперативу спільно володіють майном кооперативу). Для цього вводиться різновид зв'язку "багато-до-багатьох".
• Уточнюємо ступеня зв'язку. Іноді буває корисно визначити можливу кількість примірників суті, беруть участь в даній зв'язку (наприклад, службовцю дозволяється брати участь не більше, ніж в трьох проектах одночасно). Для вираження цього семантичного обмеження дозволяється вказувати на кінці зв'язку її максимальну або обов'язкову ступінь.
• Каскадні видалення екземплярів сутностей. Деякі зв'язку бувають настільки сильними (звичайно, в разі зв'язку "один-ко-многим"), що при видаленні опорного екземпляра сутності (відповідного кінця зв'язку "один") потрібно видалити і всі екземпляри сутності, відповідні кінця зв'язку "багато". Відповідну вимогу "каскадного видалення" можна сформулювати при визначенні сутності.
• Домени. Як і в випадку реляційної моделі даних, буває корисна можливість визначення потенційно допустимого безлічі значень атрибута сутності (домену).

Ці та інші більш складні елементи моделі даних "Сутність-Зв'язок" роблять її істотно більш потужною, але одночасно кілька ускладнюють її використання. Звичайно, при реальному використанні ER-діаграм для проектування баз даних необхідно ознайомитися з усіма можливостями.

Продовження в наступному номері

*) Продовження. Початок див. СУБД # 1 , 2 , 3