Тема Датологічне моделювання бд

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

Однак етап логічного або даталогічного проектування не закінчується проектуванням схеми відношень. У загальному випадку у результаті виконання цього етапу повинні бути отримані наступні результативні документи:

1. Опис концептуальної схеми БД у визначеннях обраної СУБД.

2. Опис зовнішніх моделей у визначеннях обраної СУБД.

3. Опис декларативних правил підтримки цілісності бази даних.

4. Розробка процедур підтримки семантичної цілісності бази даних.

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

Коректною назвемо схему БД, в якій відсутні небажані залежності між атрибутами відношень.

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

- шляхом декомпозиції (розбиття), коли первинна множина відношень, які входять у схему БД, міняється іншою множиною відношень (кількість їх при цьому збільшується), які є проекціями первинних відношень;

- шляхом синтезу, тобто шляхом компонування з заданих первинних елементарних залежностей між об’єктами предметної області схеми БД.

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

Склад атрибутів відношень БД повинен задовольняти двом основним вимогам:

- між атрибутами не повинно бути небажаних ФЗ;

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

Задоволення цих вимог досягається нормалізацією відношень БД. Нормалізація відношень – це покроковий оборотний процес декомпозиції(розкладання) вхідних відношень БД на другі, дрібніші і простіші відношення. При цьому встановлюються всі можливі функціональні залежності.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функціональні залежності. Нехай Х та У – два атрибути деякого відношення. Кажуть, що У функціонально залежить від Х, якщо у будь-який момент часу кожному значенню Х відповідає не більше ніж одне значення атрибуту У. Функціональну залежність можна позначити так: Х  У (читається: атрибут "ігрек" функціонально залежить від атрибуту "ікс").

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

1. Табельний номер функціонально залежить від ПІБ, і одночасно ПІБ функціонально залежить від табельного номеру:

ТАБЕЛЬНИЙ НОМЕР ↔ ПІБ

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

2. Номер кімнати функціонально залежить від ПІБ, якщо співробітник має робоче місце тільки у одній кімнаті:

ПІБ НОМЕР КІМНАТИ

3. Якщо в кожній кімнаті встановлений один телефон, то номер телефону функціонально залежить від номера кімнати:

НОМЕР КІМНАТИ  НОМЕР ТЕЛЕФОНУ

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

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

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

Для прикладу розглянемо відношення R. Атрибути: ПІБ - батька, ОКЛАД, КІМНАТА, ТЕЛЕФОН не знаходяться в повній функціональній залежності від ключа тому, що вони функціонально залежать від частини ключа – ТАБЕЛЬНОГО НОМЕРА.

Транзитивна залежність. Нехай X, Y, та Z – три атрибути одного відношення. При цьому X  Y та Y  Z, але зворотна залежність відсутня, тобто ZY, або Y  X. Тоді кажуть, що Z транзитивно залежить від Х. Звернемося до відношення R. В ньому можна побачити приклад транзитивної залежності: ТАБЕЛЬНИЙ НОМЕРКІМНАТАТЕЛЕФОН.

R

Табельний номер батька	Ім'я дитини	Вік	ПІБ - батька	Оклад	Кімната	Телефон
211	Олександр	10	Іванов Л. А.	150	12	616
211	Євген	7	Іванов Л. А.	150	12	616
211	Михайло	3	Іванов Л. А.	150	12	616
358	Володя	5	Тарасов М. Т.	170	12	616
360	Євген	8	Кашкін В. К.	240	5	306
360	Володя	6	Кашкін В. К.	240	5	306

Зберігання у відношенні атрибутів, які знаходяться у транзитивній залежності від ключа, викликає низку незручностей. Розглянемо це на прикладі атрибуту ТЕЛЕФОН у відношенні R.

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

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

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

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

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

Для того, щоб відношення привести до 2НФ необхідно:

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

б) побудувати одну або декілька проекцій на частини складного ключа та атрибути, функціонально від неї залежні.

Третя нормальна форма. Відношення знаходиться у третій нормальній формі (3НФ), якщо воно знаходиться у другій нормальній формі і кожен його не ключовий атрибут нетранзитивно залежить від первинного ключа.

Для переходу до 3НФ також необхідно побудувати ряд проекцій відношення.

Посилена 3НФ – нормальна форма Бойса-Кодда (НФБК). Відношення знаходиться у НФБК, якщо воно знаходиться у 3НФ та в ньому відсутні залежності ключів від не ключових атрибутів.

Четверта нормальна форма. Відношення знаходиться у 4НФ, якщо воно знаходиться у НФБК та в ньому відсутні незалежні багатозначні залежності, тобто всі незалежні багатозначні залежності виділені (рознесені) у окремі відношення з одним і тим же ключем.

Відношення з багатьма багатозначними залежностями 4НФ може і не усунути надлишковості, а разом з тим і аномалій оновлення. Тоді використовують п’яту НФ.

Приклад багатозначних залежностей:

Викладачі

Прізвище	Група	Предмет (лекції)
Дейнеко	312	СУБД
Дейнеко	312	Інформатика
Дейнеко	412	СУБД
Дейнеко	412	Інформатика
Мартиненко	512	СУБД

Багатозначна залежність: У відношенні R атрибут В багатозначно залежить від А (АВ), якщо кожному значенню А відповідає багато значень В, ніяк не зв’язаних з іншими атрибутами.

Багатозначна залежність можлива за наявності у відношенні хоча би трьох атрибутів: ключа та не менше двох незалежних друг від друга атрибутів.

Для відношення Викладачі: ключ – Прізвище; атрибути – Група та Предмет. Значення атрибутів Група та Предмет не пов’язані між собою (можливі зміни їх значень у любій стрічці відношення).

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

Між викладачем та предметами зв'язок типу (М:N), оскільки викладач може читати один та більше предметів, та навпаки, один предмет можуть читати декілька викладачів.

Прізвище Група; Прізвище Предмет

П'ята нормальна форма. Перехід відношення з 4НФ у 5НФ повинен відбуватися так, щоб результат задовольняв залежності по з'єднанню. Для цього з 4НФ отримують такі проекції, щоб кожна проекція містила в собі не менше одного можливого ключа і хоча-би один не ключовий атрибут первинного відношення. Це значить, що в 5НФ залежність по з'єднанню визначається можливими ключами. 5НФ усуває надлишковість і разом з тим аномалії оновлення.

Контрольні питання

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

2. Назвіть існуючі типи функціональних залежностей.

3. Назвіть функції, що виконує будь-яка нормальна форма.

4. Назвіть існуючі нормальні форми.

5. Назвіть етапи проектування реляційних БД.