Нормальні форми схем відносин

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

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

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

В теорії реляційних баз даних звичайно виділяється наступна послідовність нормальних форм:

1) перша нормальна форма (1 NF);

2) друга нормальна форма (2 NF);

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

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

5) четверта нормальна форма (4 NF);

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

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

Основні властивості нормальних форм полягають у наступному:

1) кожна наступна нормальна форма в деякому сенсі кращою за попередню нормальної форми;

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

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

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

2) процедурно, т. Е. Написанням програмного коду (використанням згаданих вище так званих тригерів).

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

Для того щоб наочно в порівнянні продемонструвати роботу ненормалізованих і нормалізованої бази даних, розглянемо наступний приклад.

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

Отже, варіант 1 схеми бази даних.

Сесія (№ залікової книжки. Прізвище, Ім'я, По батькові, Предмет. Оцінка)

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

Primary key (№ залікової книжки, Предмет);

Також в цьому відношенні задана система функціональних залежностей:

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

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

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

Варіант 2 схеми бази даних.

Студенти (№ залікової книжки. Прізвище, Ім'я, По батькові),

Primary key (№ залікової книжки).

Primary key (№ залікової книжки, Предмет),

Foreign key (№ залікової книжки) references Студенти (№ номер залікової книжки).

Що ми маємо тепер? Відносно «Студенти» первинний ключ «№ залікової книжки» функціонально визначає інші три атрибути: «Прізвище», «Ім'я» і «батькові». А щодо «Сесія» складовою первинний ключ «№ залікової книжки, Предмет» також однозначно, т. Е. Буквально функціонально визначає останній атрибут цієї схеми відносини - «Оцінка». І зв'язок між цими двома відносинами налагоджена: вона здійснюється за допомогою зовнішнього ключа відносини «Сесія» «№ залікової книжки», який посилається на однойменний атрибут відносини «Студенти» та при відповідному запиті представляє всю необхідну інформацію.

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