Курс «Организация баз данных» (стр. 4 )

Аномалії відновлення

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

Аномалії видалення

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

Аномалії уведення

Аномалії уведення виникають при додаванні в таблицю записів і звичайно виникають, коли для деяких полів таблиці задані обмеження not null (не порожнє поле), наприклад, поле «Оцінка» не може бути not null, тому що спочатку оцінка не відома.

Теорія нормалізації заснована на концепції нормальних форм. У теорії БД звичайно ведеться наступна послідовність нормальних форм:

-  Перша нормальна форма (1NF)

-  Друга нормальна форма (2NF)

-  Третя нормальна форма (3NF)

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

-  Четверта нормальна форма (4NF)

-  П'ята нормальна форма або нормальна форма проекції-з'єднання (5NF або PI/NF).

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

1.  Кожна наступна NF у деякому змісті краще попередньої.

2.  При переході до наступної NF властивості попередніх нормальних форм зберігаються.

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

Перша NF - значення всіх атрибутів відносини повинні бути атомарними. По визначенню таблиця «Оцінки» уже перебуває в 1NF.

Друга NF - відносини перебувають в 2NF, їли відношення перебуває в 1NF і кожний не ключовий атрибут повністю залежить від первинного ключа.

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

Щоб перейти від 1NF до 2NF, потрібно виконати наступні кроки:

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

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

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

Приклад

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

Код абітурієнта

Прізвище

Ім'я

По батькові

Номер атестату

Дата видачі

Схема 3.2 «Абітурієнти»

Код оцінки

Код абітурієнта

Предмет

Дата іспиту

Тип іспиту

Факультет

Оцінка

Схема 3.3 «Оцінки»

Дві таблиці зв'язані між собою по полю «Код абітурієнта», що є первинним ключем для таблиці «Абітурієнти» і зовнішнім для таблиці «Оцінки». Дане поле додане при нормалізації.

Третя NF - відношення R перебуває в третьої NF у випадку, якщо воно перебуває в 2NF і кожний не ключовий атрибут не транзитивно залежить від первинного ключа.

Функціональна залежність атрибутів Х и Y відносини R називається транзитивної, якщо існує такий атрибут Z, що є функціональні залежності X->Z і Z->Y, але відсутня функціональна залежність Z->X.

Замечание:

Процесс нормализации основан на понятии функциональной зависи­мости атрибутов. Говорят, что атрибут В функционально зависит от атрибута А (обозначается А->В), если в любой момент времени каждому значению атрибута А соответствует не более одного значения атрибута В. Если неключевой атрибут зави­сит от всего составного ключа и не зависит от его частей, то говорят о полной функциональной зависимости атрибута от составного ключа. Если атрибут А зависит от атрибута В, а В зависит от атрибута С, но обратная зависимость отсутствует, то говорят, что атрибут С зависит от А транзитивно.

Приклад

Між атрибутами «Код оцінки» і «Факультет» транзитивний зв'язок. Факультет залежить не від коду оцінки, а від предмету. Ми не можемо занести в БД факультет з певними даними про іспит, поки не буде оцінки, яку отримав абітурієнт за іспит.

Або

Між атрибутами «Код оцінки» і «Предмет» транзитивний зв'язок. Предмет залежить не від коду оцінки, а від факультету. Ми не можемо занести в БД предмет, який здається на факультет, поки не буде оцінки, яку отримав абітурієнт на даному факультеті.

Щоб перейти від 2NF до 3NF, потрібно виконати наступні кроки:

1.  Визначити всі поля (або групи полів), від яких залежать інші поля.

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

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

Таблиця «Оцінки» ділиться на дві - «Оцінки» і «Іспити»:

Код оцінки

Код абітурієнта

Код іспиту

Оцінка

Схема 3.4 «Оцінки»

Код іспиту

Предмет

Дата іспиту

Тип іспиту

Факультет

Схема 3.5 «Іспити»

На практиці 3NF у більшості випадків досить.

Код абітурієнта

Прізвище

Ім'я

По батькові

Номер атестату

Дата видачі

Код оцінки

Код абітурієнта

Код іспиту

Оцінка

Код іспиту

Предмет

Дата іспиту

Тип іспиту

Факультет

Схема 3.6. Таблиці «Абітурієнти», «Оцінки», «Іспити»

Лекция 3-4

1.  Цілісність реляційних БД. Аналіз обмежень цілісності в БД, розробка методів їхньої підтримки

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

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

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

Внутрішні обмеження цілісності бази даних – це обмеження, пов'язані з обмеженнями, накладеними на структуру даних.

Обмеження цілісності можна специфікувати для елементів, груп і групових відносин.

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

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

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

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

Найважливішими обмеженнями є:

1. Категорична цілісність: рядок не може бути занесена в БД доти, поки не будуть визначені всі атрибути її первинного ключа. Первинний ключ не може бути порожнім.