Практичне заняття №3
Тема: Нормальні форми відношень. Нормалізація БД до НФ Бойса-Кодда.
Мета: Закріплення теоретичних відомостей та обговорення основних проблем та помилок при нормалізації бази даних. Групова нормалізація бази даних до нормальної форми Бойса-Кодда
Теоретичні відомості:
Перша нормальна форма. Можливі недоліки відношення в 1нф
Для простоти викладу передбачається, що кожне відношення має в точності один потенційний ключ, який є первинним ключем. Це допущення підтверджують пропоновані тут докази. Далі в цій главі буде розглянутий випадок, коли відношення має два або більш потенційних ключа.
Відношення знаходиться в першій нормальній формі тоді і тільки тоді, коли усі використовувані домени містять тільки скалярні значення.
У цьому визначенні усього лише стверджується, що будь-які нормалізовані відносини знаходяться в 1НФ. Проте відношення, яке знаходиться тільки в 1 НФ (тобто не знаходиться ні в другій, ні в третій нормальній формі) має структуру, з деяких причин не зовсім бажаної. Для ілюстрації цього факту допустимо, що інформація про студентів і оцінки міститься не в 2-х стосунках Students і Marks а в одному, назвемо його SM.
SM{StNo, CityNo, GrNo, SubjNo, DocNo, Mark}
PRIMARY KEY (StNo, GrNo, SubjNo, DocNo).
Діаграма функціональних залежностей цього відношення виглядатиме як показано на Рисунок 3.1.
Рисунок 3.1 Діаграма функціональних залежностей відношення SM
Зверніть увагу, що діаграми ФЗ відношення SM "складніші", ніж діаграми ФЗ стосунків Students і Marks, з яких воно утворене. У діаграмах ФЗ стосунків Students і Marks усі стрілки починаються тільки від первинних ключів, тоді як в діаграмі ФЗ відношення SM з'являються додаткові стрілки. Нижче приведена таблиця даних для відношення SM (Рисунок 3.2).
SM |
||||||
StNo |
StName |
GrNo |
CityNo |
SubjNo |
DocNo |
Mark |
1 |
Іванов |
1 |
1 |
1 |
127 |
5 |
1 |
Іванов |
1 |
1 |
5 |
128 |
4 |
2 |
Петров |
1 |
3 |
1 |
127 |
3 |
Рисунок 3.2 Цих стосунків SM.
Не дивлячись на те, що відношення SM, як і Students і Marks знаходиться в 1й НФ, воно очевидно має надмірність, оскільки, наприклад, в кожному кортежі для студента Іванова вказаний його номер "1", код його групи - "1" і код міста, в якому він проживає, - "1". Аналогічна ситуація з іншими студентами.
Надмірність відносно SM призводить до різних аномалій оновлення, що дістали таку назву з історичних причин, тобто до труднощів при виконанні операцій оновлення типу INSERT (вставка), DELETE (видалення) і UPDATE (оновлення). Спершу розглянемо надмірність типу студент-код міста студента, відповідну функціональній залежності StNo (CityNo, і перераховані нижче проблеми з операціями оновлення.
Операція вставки (INSERT). Не можна вставити дані про студента, що проживає в деякому місті, не вказуючи хоч би одну, отриману цим студентом, оцінку. Дійсно, в таблиці SM не показаний студент Сидоров з р. Пятихатки тому, що до тих пір, поки цей студент не отримає оцінку по якому або предмету, для нього не задано значення первинного ключа.
Операція видалення (DELETE). Якщо видалити єдиний кортеж відношення SM для деякого студента, буде видалена не лише інформація про відповідну оцінку, але і інформація про студента і місто, в якому він проживає. Наприклад, якщо відносно SM видалити кортеж зі значенням Петров атрибуту StName, буде втрачена уся інформація про цього студента.
Зауваження. Насправді проблема полягає в тому, що відносно SM міститься дуже багато спільній інформації, тому при видаленні деякого кортежу доводиться видаляти занадто іншого іншій інформації. А точніше, відношення SM містить інформацію про студентів і про оцінки. Таким чином, видалення інформації про оцінку викликає також видалення інформації про студента. Для вирішення цієї проблеми треба розділити інформацію на декілька частин, тобто розмістити інформацію про студентів в одному відношенні, а про оцінки - в іншому. Таким чином, неформально процедуру нормалізації можна охарактеризувати як процедуру розбиття логічно незв'язаної інформації по окремих стосунках.
Операція модифікації (UPDATE). Прізвище студента і код міста, в якому він проживає повторюється відносно SM безліч разів, і це призводить до виникнення проблем при оновленні. Якщо студент міняє прізвище або переїжджає в інше місто, то виникає проблема, пов'язана або з пошуком відносно SM усіх кортежів, в яких присутня інформація про цього студента, або з отриманням несумісного результату (у одному кортежі містом проживання студента буде одне місто, а в іншому кортежі, містом проживання цього студента, буде інше місто).
Для вирішення проблеми надмірності, яка характерна для відношення SM досить замінити його двома іншими, :
Students{StNo, GrNo, StName, CityNo}
і
Marks{StNo, SubjNo, DocNo, Mark}
Важливо відмітити, що перероблена таким чином структура дозволяє здолати усі перераховані раніше проблеми, пов'язані з операціями оновлення.
Операція вставки (INSERT). Тепер за допомогою вставки відповідного кортежу у відношення Students можна включити інформацію про студента і місто, в якому він проживає, навіть якщо він зараз не отримав не однієї оцінки.
Операція видалення (DELETE). Тепер можна виключити інформацію про оцінку, видаляючи відповідний кортеж з відношення Marks, при цьому інформація про студента і місто, в якому він проживає, не втрачається.
Операція модифікації (UPDATE). У переробленій структурі прізвище студента і інформація про місто, в якому він проживає, з'являється усього один раз, оскільки існує тільки один кортеж для цього студента відносно Students (атрибут StNo є первинним ключем для такого відношення). Інакше кажучи, надмірність даних StNo - StName - StCity усунена. Завдяки цьому тепер можна один раз змінити у відповідному кортежі відношення Students назву міста для якого-небудь студента.