ОБДЗ / Лекции Access / Проектування РБД / 6_проектування_РБД

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

Проаналізуємо таблиці тСтуденти та тУспішність, що входять до складу БД. Зазначимо, що в тСтуденти ФЗ Код_ст → Код_спец є транзитивною. Вона є наслідком двох ФЗ:

Код_ст → Група Група → Код_спец.

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

−аномалія включення, бо не можна внести в БД інформацію, що характеризує спеціальність доти, поки на неї не буде зарахований хоча б один студент;

−аномалія вилучення, бо при вилученні запису, що описує останнього випускника груп будь-якої спеціальності, буде втрачена інформація про всю спеціальність;

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

Це аномалії можна усунути шляхом подальшої нормалізації та переходу до 3НФ.

Таблиця знаходиться в 3НФ у тому і тільки тому випадку, якщо:

−таблиця задовольняє умовам 2НФ;

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

Еквівалентним визначенням для 3НФ є наступне:

таблиця знаходиться в 3НФ, якщо всі неключові поля взаємно незалежні і кожне неключове поле нетранзитивно залежить тільки від ключа.

49

Іншими словами можна визначити:

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

Виконаємо крок нормалізації для тСтуденти. Зробимо її декомпозицію на дві таблиці:

тСтуденти (*Код_ст, Ін_ст, ПІБ, Група) ФЗ: Код_ст → ПІБ

Код_ст → Ін_ст Код_ст → Група

тГрупи (*Група, Код_спец) ФЗ: Група → Код_спец.

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

Діаграма БД показана на рис. 6.6 Процедуру переходу до 3НФ можна сформулювати наступним чином:

якщо в таблиці T(*K, P1, P2) існують ФЗ К→ P1, P1→ P2, то таблиця Т поділяється на дві нові T1(*K, P1) та T2(*P1, P2).

Рисунок 6.6 – Діаграма БД (варіант 2)

Додамо, що якщо значення P2 можна точно розрахувати за значенням Р1, то Т2 можна не включати в БД. Для розрахунку значень Р2 можна використати запити.

На практиці набір структур таблиць 3НФ є достатнім. І в більшості випадків процес проектування РБД звичайно закінчується приведенням всіх таблиць БД до 3НФ. Однак іноді корисно продовжити процес нормалізації.

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

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

тРоботи (Код_ст, Ін_ст, Код_роботи, Ст_завдання).

Якщо взяти за ключ поля Код_ст, Код_роботи, то видно, що таблиця Роботи знаходиться в 3НФ. Але відомо, що особистість студента цілком визначається як його кодом, так і ідентифікаційним номером. Тоді можна

50

записати два можливих ключа для таблиці Роботи: *Код_ст, *Код_роботи або *Ін_ст, *Код_роботи.

Визначення 3НФ не зовсім підходить до такого випадку, коли таблиця має два складових можливих ключа, які мають хоч одне загальне поле.

Сформулюємо ФЗ.

Для ключа Код_ст, Код_роботи ФЗ: Код_ст → Ін_ст

Код_ст → Код_роботи Код_ст, Код_роботи → Ст_завдання

Для ключа Ін_ст, Код_роботи ФЗ: Ін_ст → Код_ст Ін_ст → Група

Ін_ст → Код_роботи Ін_ст, Код_роботи → Ст_завдання

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

Треба продовжити нормалізацію та позбутися аномалій.

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

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

Легко помітити, що якщо в таблиці є тільки один можливий ключ, то він стає первинним, а це визначення стає еквівалентним визначенню 3НФ.

Для виконання вимог БКНФ проведемо декомпозицію тРоботи на тСтуденти та тРоботи (залишимо стару назву для нової таблиці):

тРоботи (*Код_ст, *Код_роботи, Ст_завдання) Ключ: Код_ст, Код_роботи ФЗ: Код_ст, Код_роботи → Ст_завдання

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

51

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

Продовжимо приклад обліку виконання робіт та завдань студентами. В загальному випадку студенти можуть брати участь у декількох роботах, а різні роботи можуть включати однакові завдання. Для спрощення розглянемо два види завдань:

1)розробка інформаційного забезпечення (ІЗ);

2)розробка програмного забезпечення (ПЗ).

Перелік робіт наведено у табл. 6.4. Таблиця містить види (коди) робіт, для кожної роботи – список студентів, що повинні виконувати дану роботу, і список завдань, що передбачаються роботою.

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

Таблиця 6.4 – Облік робіт студентів

Структура таблиці може мати вид:

тРоботи (*Код_роб, *Код_ст, *Роб_завдання, Виконання).

Через сформульовані вище умови єдиним можливим ключем таблиці тРоботи є складовий ключ (Код_роб, Код_ст, Роб_завдання). Ніяких інших детермінантів більше немає. Отже, таблиця знаходиться в БКНФ.

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

Треба зробити черговий шаг нормалізації – перейти до 4НФ. На цій стадії розглядається багатозначна залежність (БЗ) полів.

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

Вважають, що в таблиці Т (A, B, C) існує БЗ у тому і тільки тому випадку, якщо множина значень B, що відповідає парі значень A і C, залежить тільки від A і не залежить від С.

Багатозначна залежність показується як Т.A (r)(r) Т.B або Т.A à à Т.B.

В загальному випадку в таблиці Т (A, B, C) існує БЗ Т.Aàà Т.B у тому і тільки тому випадку, коли існує БЗ Т.A àà Т.C. Тому далі можна вживати позначення A àà B | C у тому сенсі, що одночасно існують БЗ типу A àà B і A àà C.

52

В тРоботи існують дві БЗ:

Код_роб àà Код_ст, яка означає, що роботу можуть виконувати декілька студентів;

Код_роб àà Роб_завдання, яка означає, що при виконанні зазначеної роботи виконуються кілька завдань.

При цьому Студент і Завдання не зв'язані функціональною залежністю. Все це приводить до появи надмірності.

Визначення 4НФ базується на двох операціях реляційної алгебри: проекції та з'єднанні. Надамо пояснення цих операцій в термінах РТ.

Проекцією таблиці Т (А,..,X,Y,...,Z) по заданому набору її полів ,X,Y,...,Z називається таблиця Р із заголовком X,Y...,Z і тілом, що містить множину відповідних значень із всіх записів таблиці C.

Операція проекції записується так

P:=Т [Х,Y,…,Z]

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

Дамо визначення операції з'єднання таблиць.

Нехай таблиця А має поля {X1,…,Xm,Y1,…,Yn}, а таблиця В – поля {Y1,…, Yn, Z1,…, Zk}. Поля { Y1,…,Yn} є загальними для двох таблиць та відповідно визначені на однакових доменах.

З'єднанням таблиць А і В називається таблиця з полями {X1,…, Xm, Y1,…, Yn, Z1,…, Zk}, яка містить множину всіх таких записів {X:x,Y:y,Z:z}, для яких у таблиці А значення поля Х дорівнює х, а поля Y дорівнює y, а в таблиці В значення поля Y також дорівнює y, а поля Z дорівнює z.

Операція з'єднання записується так J:= A JOIN B.

При з'єднанні відбувається конкатенація полів та записів таблиць, а також виключення повторення полів та записів.

Більш докладно ці операції будуть розглянуті при вивченні операцій маніпулювання з РТ.

Подальша нормалізація таблиць, що мають БЗ, ґрунтується на теоремі Фейджина:

Таблицю Т (A, B, C) можна відобразити без втрат у таблиці Т1 (A, B) і Т2 (A, C) у тому, і тільки в тому випадку, коли існує БЗ A àà B | C.

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

Таблиця Т знаходиться в 4НФ у тому і тільки тому випадку, якщо у випадку існування БЗ A àà B всі інші поля таблиці Т функціонально залежать від A.

Інакше кажучи, таблиця перебуває в 4НФ, якщо вона перебуває в НФБК і не має багатозначних залежностей.

Для усунення БЗ необхідно рознести багатозначні поля в різні таблиці. У нашому прикладі можна зробити декомпозицію тРоботи на дві нові таблиці:

53

тРоботи (*Код_роб, Код_ст) ФЗ: Код_роб → Код_ст

тЗавдання (*Код_роб, Роб_завдання) ФЗ: Код_роб →Роб_завдання.

Обидві ці таблиці знаходяться в 4НФ і вільні від зазначених вище аномалій.

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

В усіх розглянутих до цього моменту НФ проводилася декомпозиція однієї таблиці на дві. Розглянемо випадок декомпозиції на три таблиці.

Спочатку дамо визначення залежності з'єднання.

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

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

тРоботи (Код_роб, Код_ст, Група, Код_роб).

Ключем цієї таблиці є повна сукупність полів, відсутні ФЗ і БЗ. Тому таблиця знаходиться в 4НФ.

Однак у таблиці можуть існувати аномалії. На прикладах можна легко показати, що при додаванні та вилученні записів можуть виникнути проблеми. Ці аномалії неможливо усунути шляхом декомпозиції таблиці на дві інші таблиці. Але можлива декомпозиція на число таблиць, більше 2. Кожна з таких таблиць повинна мати кращі властивості.

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

Таблиця Т знаходиться в 5НФ у тому і тільки тому випадку, коли будь-яка залежність з'єднання в Т випливає з існування деякого можливого ключа в Т.

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

Таблиця, що не має жодної повної декомпозиції, також знаходиться в 5НФ. Введемо наступні імена композиційних полів:

СГ = {Код_ст, Група} СР = {Код_ст, Код_роб} ГР = {Група, Код_роб}

Припустимо, що в тРоботи існує залежність з'єднання: * (СГ, СР, ГР). Аномалії можна усунути шляхом декомпозиції тРоботи на три нових

таблиці:

тСтуденти (Код_ст, Група)

54

тСтудентиРоботи (Код_ст, Код_роб) тРоботи (Група, Код_роб)

Вважають, що 5НФ – це остання НФ, яку можна отримати шляхом декомпозиції.

4НФ є частковим випадком 5НФ, коли повна декомпозиція повинна бути з'єднанням рівно двох проекцій. Дуже непросто підібрати реальну таблицю, що знаходилася б у 4НФ, але не була б у 5НФ.

Загалом умови 5НФ досить нетривіальні, поки що не існує ефективного та формалізованого алгоритму перевірки на існування або відсутність БЗ. Тому на практиці 5НФ майже не використовують. Часто з великою гарантією вважають, що якщо таблиці перебувають в БКНФ, то вони перебувають в 4НФ та в 5НФ.

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

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

Одна людина може навчатися на 0, 1 або кількох спеціальностях, а на кожній із спеціальностей може навчатися 0,1 або кілька людей. Видно, що між тЛюди та тСпеціальності існує зв’язок типу N:M.

Уточнимо, що студент навчається у групі, яка відноситься до спеціальності. Таким чином, якщо студент може навчатися на декількох спеціальностях, то він може навчатися в декількох групах. Таким чином, у БД має бути реалізовано зв’язок типу N:M між тГрупи та тЛюди. Зв’язок такого типу у РБД на використовується. Тому дві таблиці зі зв’язком типу N:M замінюються на три таблиці зі зв’язками 1:М.

На рис. 6.7 наведені частка діаграми БД для задачі обліку студентів

Рисунок 6.7 – Діаграма БД (варіант 3)

На рис. 6.8 наведено приклад діаграми, який наочно ілюструє розв’язання БЗ у загальному виді.

Рисунок 6.8 – Зв’язки між трьома таблицями

55

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

6.11 Домено-ключова нормальна форма

Була зроблена спроба розробити НФ, що буде вільною від аномалій будьякого типу.

Р.Фагін у 1981 р. визначив домено-ключову нормальну форму (ДКНФ). Він показав, що таблиця в ДКНФ не має аномалій модифікації, а будь-яка таблиця, що не має аномалій модифікації, повинна перебувати в цій НФ.

Визначення ДКНФ стосується тільки поняття ключів та доменів, які безпосередньо можуть підтримуватися існуючими СУБД. Доказ стосується обох частин доменів. Але у контексті ДКНФ під доменом мають на увазі тільки фізичний опис.

Розглянемо термін обмеження. Обмеження – це будь-яке правило, що регулює можливі статичні значення полів і досить точне для того, щоб можна було встановити, виконується воно чи ні. Прикладами таких обмежень можуть бути правила редагування, обмеження взаємин і структури таблиць, ФЗ і БЗ. Звідси виключаються обмеження, що ставляться до змін значень даних, або обмеження, що залежать від часу.

Таблиця перебуває в ДКНФ, якщо кожне обмеження, що накладається на цю таблицю, є логічним наслідком визначення доменів і ключів.

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

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

Розглянемо приклад, що ілюструє ДКНФ.

Треба вести облік інформації про викладачів, про дисципліни, які вони ведуть, та студентів, якими вони керують під час НДРС та дипломування. Кожен викладач може вести кілька дисциплін та бути керівником у кількох студентів. Але кожним студентом може керувати тільки один викладач. Можна створити таблицю тВикладачі (*Код_викл, Ін_викл, ПІБ_викл…., *Код_дисц, Назва_дисц,

Годин,…, *Код_ст, Ін_ст, ПІБ_ст,…). В цій таблиці існують залежності:

56

Код_викл → Ін_викл Ін_викл → Код_викл

Код_викл →→ Код_дисц | Код_ст Ін_викл →→ Код_дисц | Код_ст Код_ст → Код_викл

При цьому мають виконуватися додаткові обмеження:

–Код_викл повинен належати до домену табельних номерів співробітників;

–Код_ст повинен належати до домену номерів залікових книжок студентів;

–Код_дисц повинен належати до домену кодів дисциплін усіх учбових

планів.

На жаль, відсутні чіткі алгоритми перетворення таблиці до ДКНФ. Корисно розглянути ДКНФ у більш інтуїтивному світлі. Неформально основна суть нормалізації полягає в тім, що кожна таблиця повинна мати тільки одну тему.

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

−інформація про викладачів;

−інформація про дисципліни;

−інформація про дисципліни, які веде викладач;

−інформація про студентів.

При цьому до атрибутів студента можна віднести і відомості про його керівника.

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

Визначення доменів

Визначення таблиць та ключів тВикладачі (*Код_викл, Ін_викл, ПІБ_викл….)

тДисципліни (*Код_дисц, Назва_дисц, Годин,…,) тВикладання (*Код_викл, *Код_дисц) тСтуденти (*Код_ст, Ін_ст, ПІБ_ст,…,Код_викл)

Таблиця тВикладачі виражає еквівалентність полів Код_викл і Ін_викл. Поле Код_викл – це ключ, а поле Ін_викл – це альтернативний ключ, що означає, що обидва поля унікальні для цієї таблиці. Оскільки обидва вони є ключовими, ФЗ Код_викл → Ін_викл та Ін_викл → Код_викл являють собою

57

логічні наслідки ключів.

Таблиця тВикладання відбиває відповідність між викладачами та дисциплінами. В ній зазначені дисципліни, які може викладати кожен із викладачів. Комбінація обох полів становить ключ. Обидва поля є необхідними для ключа, тому що один викладач може вести кілька предметів, а той самий предмет може вестися декількома викладачами. Розділення тем усуває БЗ.

Отримані таблиці БД виражають всі задані обмеження у вигляді логічних наслідків визначень доменів і ключів. Тому дані таблиці перебувають у ДКНФ.

На сучасному етапі проектування БД вважається, що таблиці у ДКНФ точно не будуть мати ніяких аномалій.

Таким чином, введення ДКНФ поклало кінець розробці інших НФ більш високого порядку. ДКНФ наближує ЛМД до ФМД.

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

Процес проектування БД проводиться за таким алгоритмом:

Опис постановки задачі àРозробка КМД à Розробка ЛМД àРозробка ФМДàРеєстрація проектних рішень.

Розглянемо цей процес поетапно.

Процес проектування БД може починатися з ідентифікації сутностей та побудови ІМД за допомогою МІМ або у вигляді діаграми типу “Сутностізв’язки”.

Далі треба перейти до проектування даталогічної реляційної МД та представити ІМД у вигляді діаграми типу “Таблиці – зв’язки”.

Для переходу від ER-діаграми типу “Сутності-зв’язки” до діаграми типу “Таблиці-зв’язки” необхідно виконати наступні кроки:

1.Представити кожен стрижень базовою таблицею (БТ) і специфікувати її первинний ключ.

2.Представити кожну асоціацію як БТ. Визначити в цій таблиці зовнішні ключі для ідентифікації учасників асоціації і специфікувати обмеження, зв'язані

зкожним з цих зовнішніх ключів.

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

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

5.Представити кожну властивість як поле в БТ, що представляє сутність, яку безпосередньо описує ця властивість.

Таким чином, для переходу від ER-діаграми “Сутності-зв’язки” до діаграми типу “Таблиці-зв’язки” необхідно сутності всіх типів замінити таблицями. Тому на практиці АБД об’єднує два підходи (ІМД у вигляді діаграм двох типів “Сутності-зв’язки” і “Таблиці – зв’язки”) і при проектуванні РБД використовує в основному діаграми типу “Таблиці – зв’язки”.

58