Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
лекц_информ_07.doc
Скачиваний:
19
Добавлен:
21.02.2016
Размер:
1.81 Mб
Скачать

Лекція 6

4.3. Нормалізація відношення

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

Перед нормалізацією відношення повинно знаходитися в першій нормальній формі.

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

Запитання: Чи можна, не аналізуючи проблем, що можуть виникнути при роботі з відношенням, визначити, чи потребує це відношення нормалізації?

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

Відношення знаходиться в НФБК, якщо і тільки якщо кожний детермінант відношення є можливим ключем відношення.

Що стосується можливих ключів універсального відношення НАВАНТАЖЕННЯ, то їх два й обидва вони складові:

<Код_одержувача, Код_вантажу>;

<Код_одержувача, Найм_вантажу>.

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

Детермінант. Нехай дані 2 атрибути: А та В, то говорять, що атрибут В функціонально залежить від атрибуту А, якщо для кожного значення атрибуту А існує рівно одне пов'язане з ним значення атрибуту В (у будь-які моменти часу). Або навпаки, атрибут А є детермінантом атрибуту В. А й В можуть бути складовими, тобто кожний з них може бути складений з декількох атрибутів.

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

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

Візьмемо два атрибути <Назва_одержувача> та <Код_одержувача>.

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

Тепер перевіримо за змістом це припущення. А чи може одержувач з певним кодом мати іншу назву?

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

З іншого боку, чи може той самий одержувач мати кілька різних назв? Очевидно, що ні, якщо інше не обговорено окремо чи спеціально. Якщо такого застереження нема, то можна зробити остаточний висновок про те, що між атрибутами <Код_одержувача> і <Назва_одержувача> дійсно існує функціональна залежність, причому атрибут <Код_одержувача> є детермінантом атрибута <Назва_одержувача>.

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

У представленому екземплярі відношення зустрічається значення атрибута <Назва_одержувача>, якому відповідають два значення атрибута <Код_одержувача>. Два одержувачі 1010 і 1425 мають однакові назви. Отже, зворотна функціональна залежність між цими атрибутами відсутня. Атрибут <Назва_одержувача> не є детермінантом атрибута <Код_одержувача>.

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

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

Наприклад: атрибут <Маса_вантажу> функціонально не залежить від жодного атрибута відношення НАВАНТАЖЕННЯ. Пара атрибутів <Код_одержувача, Код_вантажу> є детермінантом для атрибута <Маса_вантажу>. Кожний з атрибутів пари є детермінантом: <Код_одержувача> для атрибутів <Назва_одержувача> і <Код_ЄСР>, <Код_вантажу> для атрибута <Найм_вантажу>.

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

В лівому нижньому куті схеми функціональних залежностей приводиться список можливих ключів.

Схема функціональних залежностей між атрибутами відношення НАВАНТАЖЕННЯ(Код_одержувача, Назва_одержувача, Код_ЄСР, Код_вантажу, Найменування_вантажу, Маса_вантажу) представлена на рисунку 7.

Висновок: не кожний детермінант є можливим ключем, а тільки 4-й та 5-й. Тому відношення НАВАНТАЖЕННЯ не знаходиться в НФБК, отже потрібна його декомпозиція.

На цьому закінчується другий етап проектування РБД.