Сдам Сам

ПОЛЕЗНОЕ


КАТЕГОРИИ







Поняття форми відношення. Перша нормальна форма.





Не кожна таблиця даних є відношенням. Лише та таблиця, яка знаходиться в першій нормальній формі є відношенням. Тобто відношення обов’язково повинне знаходитися в першій нормальній формі (1НФ).

Ця таблиця не є відношенням. Значення перших 3-х атрибутів є атомарними, значення решти 3-х атрибутів є множинними, тобто не кожний рядок є кортежем. Наприклад, одержувачу 1010 відповідає по одному значенню атрибутів <Назва_одержувача> та <Код_станції> і відразу по три значення атрибутів <Код_вантажу>, <Найм_вантажу> та <Маса_вантажу>. Тобто значення перших трьох атрибутів є атомарними, а решти – множинними.

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

Можна перетворити таблицю у відношення шляхом введення штучного (надлишкового) дублювання даних, тобто продублювати відомі нам значення перших 3 атрибутів (додані значення атрибутів показані курсивом в табл. 14).

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

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

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

Таблиця 9 – ВідношенняНАВАНТАЖЕННЯ:

Код одержувача Назва одержувача Код станції Код вантажу Найм. вантажу Маса вантажу
Мех. з-д Метізи
Мех. з-д Рейки
Мех. з-д Дріт
Ф-ка Метізи
Ф-ка Дріт
Мех. з-д Рейки
Мех. з-д Дріт
ЗБК Прокат
Будтрест - - -

Проблеми, що можуть виникнути при роботі з РБД



Проблеми зв’язані головним чином з недостатньою кількістю відношень в РБД. Розглянемо їх на прикладі попереднього універсального відношення:

1. Проблема вставки даних. Потрібно залучити до РБД нового одержувача 1572, котрому ще не відправляли в дану добу вантажі. Але порожні поля, як правило, не допускаються, тому що можуть виникнути проблема при складанні довідок на основі цих даних. (Наприклад, потрібна довідка про одержувачів, які отримають відправи масою до 100 тон. В довідку може бути залучений одержувач 1572, який такі вантажі не одержував).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 5. Схема функціональних залежностей

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

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









Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:


©2015- 2019 zdamsam.ru Размещенные материалы защищены законодательством РФ.