Проектування РБД

1)тСтуденти (*Код_ст, Ін_ст, ПІБ, Код_спец, Група) ФЗ: Код_ст → ПІБ

Код_ст → Ін_ст Код_ст → Код_спец Код_ст → Група

2)тУспішність (*Код_ст, *Рік, *Семестр, *Код_дисц, *Вид_контролю,

Оцінка)

ФЗ: *Код_ст,* Рік, * Семестр, * Код_дисц, * Вид_контролю → Оцінка В отриманих таблицях будь-яке неключове поле однозначно

ідентифікується ключем. Отже, кожна з цих двох таблиць знаходиться в 2НФ. С переходом до 2НФ ми перейшли від однієї РТ до РБД з двох таблиць. В

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

Таким чином, процедуру переходу від 1НФ до 2НФ можна сформулювати

так: якщо в таблиці T(*K1,*K2, P) існує ФЗ типу К2→P, то таблиця Т поділяється на дві нові T1(*K1,*K2) та T2(*K2, P).

Додамо, що якщо значення P можна точно розрахувати за значенням К2, то Т2 можна не включати в БД. Для розрахунку значень Р можна використати запити.

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

Таким чином, зробимо важливий висновок: якщо таблиця має простий ключ, то вона автоматично перебуває в 2НФ.

На практиці для кожного об’єкта (таблиці) визначають простий ключ. Якщо для об’єкта реально не існує такого ключа, то в кожній таблиці рекомендовано створювати для простого ключа нове штучне поле. Зазвичай для цього використовують поле, де зберігається порядковий номер запису. А набір полів, що реально однозначно ідентифікує запис, визначають як можливий ключ (унікальний складовий індекс).

Нехай в БД необхідно зберігати інформацію про сутність Об’єкт. Будемо мати таблицю як мінімум з двома полями тОб’єкти (*Код_об’єкту, Об’єкт), де під полем Об’єкт будемо розуміти одне поле або кілька полів для зберігання властивостей представників об’єкту. Наприклад, для зберігання інформації про людей можна створити тЛюди (*Код_людини, Людина). Але необхідно пам’ятати, що для зберігання атрибутів людини необхідно розкривати поле Людина як кілька полів (прізвище, ім'я, по-батькові, стать, дата народження, резюме, фотографія, E-mail, тощо). Розглянемо таблицю тМісця_роботи (Код_місця_роботи, Місце_роботи). Для людини місце роботи зазвичай визначається як підприємство, підрозділ, посада, оклад, ставка. Аналогічно адреса – це поштовий індекс, населений пункт, вулиця, будинок, номер квартири або офісу.

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

45

6.5 Цілісна частина РМД

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

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

У цілісній частині РМД фіксуються дві базових вимоги цілісності, які повинні підтримуватися в будь-який реляційній СУБД:

−цілісність сутностей;

−цілісність за посиланнями.

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

Розглянемо поняття посилання.

Студент отримує оцінки. Сутність Студент – первинна, а Успішність – вторинна. Відповідно тСтуденти – основна (батьківська) таблиця, а тУспішність – дочірня (підпорядкована, зв’язана) таблиця.

Поле Код_ст визначає студента. У тСтуденти це поле – простий ключ, а у тУспішність – частина складового ключа. Таке поле або сукупність полів у дочірній таблиці називають зовнішнім ключом (Foreign Key).

Для кожного студента значення полів Код_ст в обох таблицях однакові. Наприклад, в тСтуденти один запис, в якому Код_ст=1001 (для Андреєва А.А.), а в тУспішність – таких записів декілька. Якщо ми вирішили змінити Код_ст для Андреєва А.А. то ми повинні змінити значення цього поля як в тСтуденти, так і в тУспішність.

У тУспішність не можуть бути записи з оцінками студента, запис про якого не існує у тСтуденти.

Цілісність за посиланнями означає, що значення полів первинного ключа в записах батьківської таблиці та зовнішнього ключа в відповідних (зв’язаних) записах дочірньої таблиці завжди мають однакові значення. У дочірній таблиці не можуть бути записи-“сироти”, для яких не існує відповідних записів у батьківської таблиці.

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

1)при зміні значення ключового поля в існуючих записах батьківської таблиці автоматично змінюються значення поля зовнішнього ключа в відповідних записах дочірньої таблиці;

2)при вилученні запису з батьківської таблиці або автоматично вилучаються всі відповідні записи в дочірній таблиці, або вилучення забороняється, доки в дочірній таблиці є відповідні записи;

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

46

таблиці.

Сучасні СУБД мають розвинені засоби підтримки цілісності за посиланнями за рахунок встановлення зв’язків між таблицями.

6.6 Діаграми “Таблиці - зв’язки”

Від моменту появи в РБД кількох таблиць логічну модель і схему БД рекомендується зображати у вигляді діаграм. При проектуванні РБД замість загальних ER-діаграм типу “Сутності-зв’язки” рекомендується використовувати діаграми типу “Таблиці-зв’язки”. Ці діаграми краще підходять для подальшої реєстрації проектних рішень і реалізації БД.

В діаграмах типу “Таблиці-зв’язки” таблиці зображують одним стовпцем (прямокутниками). У заголовку прямокутника записують ім’я, іноді вказують тип таблиці як сутності. Іноді назву таблиці вносять у прямокутник. Рекомендується назви таблицям давати в множині та записувати прописними буквами. Як було домовлено вище, ми будемо додавати у назві першу букву

“т”.

Ключі та поля заносять у прямокутник таблиці і записують малими літерами. При цьому поля таблиці, що складають ключ, розташовують поруч, підкреслюють, обводять рамкою або позначають знаком “*”.

Поля, що входять до можливого альтернативного ключа будемо позначати знаком “v”.

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

		СТУДЕНТИ					тСтуденти
							Код_ст
		Позначення
		Код_студента					Ін_ст
			Студент
							ПІБ
			Адреса
							Код_спец
		......
							Група
тСтуденти				тУспішність				тУспішність
*Код_ст					*Код_ст			* Код_успішності
					*Рік			v Код_ст
Ін_ст
					*Семестр			v Рік
ПІБ
					*Код_дисц			v Семестр
Код_спец
				*Вид_контролю				v Код_дисц
Група
					Оцінка			v Вид_контролю
								Оцінка

Рисунок 6.3 – Об’єкти діаграм “Таблиці – зв’язки”

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

47

Між двома таблицями А (батьківська) та Б (дочірня) можуть існувати два основних варіанти зв’язків:

1)зв'язок один–до–одного (1:1), коли в любий момент часу кожному запису таблиці А може відповідати 1 чи 0 записів таблиці Б;

2)зв'язок один–до–багатьох (1: , або 1:М), коли одному запису таблиці А може відповідати 0, 1 чи більше записів таблиці Б.

Вобох випадках кожному запису таблиці Б відповідає тільки один запис таблиці А.

Існує ще один тип зв’язку – зв'язок багато-до-багатьох ( : , або 1:М), коли одному запису таблиці А може відповідати більше одного запису таблиці Б, а одному запису таблиці Б може відповідати більше одного запису таблиці А.

Місце "стикування" зв'язку з таблицею (кінець лінії зв’язку) позначають відповідним знаком.

Зазвичай для стикування типу “один-до -” (1: ) або “-до - одного” (:1) використовується цифра 1, а для стикування “-до - багатьох” (:М) або “багато- до-” (M:) букви М, N або знак ∞.

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

На рис. 6.4 наведено приклад діаграми БД, яка складається з двох зв’язаних таблиць.

	тСтуденти	1	M	тУспішність
	*Код_ст			*Код_ст
	Ін_ст			*Рік
	ПІБ			*Семестр
	Код_спец			*Код_дисц
	Група			*Вид_контролю
				Оцінка

Рисунок 6.4 – Діаграма БД (варіант 1

Розглянемо загальний приклад.

Маємо дві таблиці тТ1 і тТ2, які перебувають у 2НФ. Між ними можливі такі види зв’язків:

1)зв'язок відсутній, таблиці не зв’язані (рис. 6.5а);

2)зв'язок 1:1, таблиці рівноправні (рис. 6.5б);

3)зв'язок 1:М, тТ1 – батьківська, тТ2 – дочірня (рис. 6.5в);

4)зв'язок М:1, тТ1 – дочірня, тТ2 – батьківська (рис. 6.5в).

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

Зв'язок типу N:М буде розглянуто нижче.

48

тТ	1		тТ2		тТ	1		тТ2
*Код_т1			*Код_т2		*Код_т1			*Код_т2
Т1			Т2		Т1			Т2

а) зв’язок не встановлено					б) зв’язок 1:1
тТ1		тТ2		тТ1				тТ2
*Код_т1	1	*Код_т2		*Код_т1		1		*Код_т2
	M			Т1		M		Т2
Т1		Т2
		Код_т1		Код_т2
в) зв'язок 1:М(варіант 1)			г) зв'язок М:1 (варіант 2)
	Рисунок 6.5 – Варіанти зв’язків між двома таблицями

6.7 Третя нормальна форма

Проаналізуємо таблиці тСтуденти та тУспішність, що входять до складу БД. Зазначимо, що в тСтуденти ФЗ Код_ст → Код_спец є транзитивною. Вона є наслідком двох ФЗ:

Код_ст → Група Група → Код_спец.

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

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

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

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

Це аномалії можна усунути шляхом подальшої нормалізації та переходу до 3НФ.

Таблиця знаходиться в 3НФ у тому і тільки тому випадку, якщо:

−таблиця задовольняє умовам 2НФ;

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

Еквівалентним визначенням для 3НФ є наступне:

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

49

Іншими словами можна визначити:

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

Виконаємо крок нормалізації для тСтуденти. Зробимо її декомпозицію на дві таблиці:

тСтуденти (*Код_ст, Ін_ст, ПІБ, Група) ФЗ: Код_ст → ПІБ

Код_ст → Ін_ст Код_ст → Група

тГрупи (*Група, Код_спец) ФЗ: Група → Код_спец.

Кожна з цих двох таблиць знаходиться в 3НФ і вільна від відзначених аномалій.

Діаграма БД показана на рис. 6.6 Процедуру переходу до 3НФ можна сформулювати наступним чином:

якщо в таблиці T(*K, P1, P2) існують ФЗ К→ P1, P1→ P2, то таблиця Т поділяється на дві нові T1(*K, P1) та T2(*P1, P2).

	тГрупи		тСтуденти	1	тУспішність
		1
	*Група		*Код_ст		* Код_успішності
				M
	Код_спец
			Ін_ст
					v Код_ст
		M	ПІБ		v Рік
			Група		v Семестр
					v Код_дисц
					v Вид_контролю
					Оцінка

Рисунок 6.6 – Діаграма БД (варіант 2)

Додамо, що якщо значення P2 можна точно розрахувати за значенням Р1, то Т2 можна не включати в БД. Для розрахунку значень Р2 можна використати запити.

На практиці набір структур таблиць 3НФ є достатнім. І в більшості випадків процес проектування РБД звичайно закінчується приведенням всіх таблиць БД до 3НФ. Однак іноді корисно продовжити процес нормалізації.

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

Припустимо, що необхідно вести облік робіт, що виконує студент, та студентські індивідуальні завдання. До цих робіт відносяться курсові, самостійні, домашні, науково-дослідницькі роботи, курсові та дипломний проекти. Розглянемо наступний приклад структури таблиці:

тРоботи (Код_ст, Ін_ст, Код_роботи, Ст_завдання).

Якщо взяти за ключ поля Код_ст, Код_роботи, то видно, що таблиця Роботи знаходиться в 3НФ. Але відомо, що особистість студента цілком визначається як його кодом, так і ідентифікаційним номером. Тоді можна

50

записати два можливих ключа для таблиці Роботи: *Код_ст, *Код_роботи або *Ін_ст, *Код_роботи.

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

Сформулюємо ФЗ.

Для ключа Код_ст, Код_роботи ФЗ: Код_ст → Ін_ст

Код_ст → Код_роботи Код_ст, Код_роботи → Ст_завдання

Для ключа Ін_ст, Код_роботи ФЗ: Ін_ст → Код_ст Ін_ст → Група

Ін_ст → Код_роботи Ін_ст, Код_роботи → Ст_завдання

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

Треба продовжити нормалізацію та позбутися аномалій.

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

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

Легко помітити, що якщо в таблиці є тільки один можливий ключ, то він стає первинним, а це визначення стає еквівалентним визначенню 3НФ.

Для виконання вимог БКНФ проведемо декомпозицію тРоботи на тСтуденти та тРоботи (залишимо стару назву для нової таблиці):

тСтуденти (Код_ст, Ін_ст)
Можливі ключі: Код_ст	Ін_ст
ФЗ: Код_ст → Ін_ст	Ін_ст → Код_ст

тРоботи (*Код_ст, *Код_роботи, Ст_завдання) Ключ: Код_ст, Код_роботи ФЗ: Код_ст, Код_роботи → Ст_завдання

Можлива альтернативна декомпозиція, якщо вибрати за основу Ін_ст. В обох випадках тСтуденти і тРоботи будуть знаходитись в БКНФ, і їм не властиві відзначені вище аномалії.

51

6.9 Четверта нормальна форма

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

1)розробка інформаційного забезпечення (ІЗ);

2)розробка програмного забезпечення (ПЗ).

Перелік робіт наведено у табл. 6.4. Таблиця містить види (коди) робіт, для кожної роботи – список студентів, що повинні виконувати дану роботу, і список завдань, що передбачаються роботою.

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

Таблиця 6.4 – Облік робіт студентів

Робота	Студент	Завдання	Виконання
БД курсова	Андрєєв А.А.	ІЗ	Так
БД курсова	Андрєєв А.А.	ПЗ	Так
БД курсова	Іванов І.І.	ІЗ	Так
БД курсова	Іванов І.І.	ПЗ	Ні
...	...	...	…
Диплом	Андрєєв А.А.	ІЗ	Так
…	…	…	…

Структура таблиці може мати вид:

тРоботи (*Код_роб, *Код_ст, *Роб_завдання, Виконання).

Через сформульовані вище умови єдиним можливим ключем таблиці тРоботи є складовий ключ (Код_роб, Код_ст, Роб_завдання). Ніяких інших детермінантів більше немає. Отже, таблиця знаходиться в БКНФ.

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

Треба зробити черговий шаг нормалізації – перейти до 4НФ. На цій стадії розглядається багатозначна залежність (БЗ) полів.

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

Вважають, що в таблиці Т (A, B, C) існує БЗ у тому і тільки тому випадку, якщо множина значень B, що відповідає парі значень A і C, залежить тільки від A і не залежить від С.

Багатозначна залежність показується як Т.A (r)(r) Т.B або Т.A à à Т.B.

В загальному випадку в таблиці Т (A, B, C) існує БЗ Т.Aàà Т.B у тому і тільки тому випадку, коли існує БЗ Т.A àà Т.C. Тому далі можна вживати позначення A àà B | C у тому сенсі, що одночасно існують БЗ типу A àà B і A àà C.

52

В тРоботи існують дві БЗ:

Код_роб àà Код_ст, яка означає, що роботу можуть виконувати декілька студентів;

Код_роб àà Роб_завдання, яка означає, що при виконанні зазначеної роботи виконуються кілька завдань.

При цьому Студент і Завдання не зв'язані функціональною залежністю. Все це приводить до появи надмірності.

Визначення 4НФ базується на двох операціях реляційної алгебри: проекції та з'єднанні. Надамо пояснення цих операцій в термінах РТ.

Проекцією таблиці Т (А,..,X,Y,...,Z) по заданому набору її полів ,X,Y,...,Z називається таблиця Р із заголовком X,Y...,Z і тілом, що містить множину відповідних значень із всіх записів таблиці C.

Операція проекції записується так

P:=Т [Х,Y,…,Z]

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

Дамо визначення операції з'єднання таблиць.

Нехай таблиця А має поля {X1,…,Xm,Y1,…,Yn}, а таблиця В – поля {Y1,…, Yn, Z1,…, Zk}. Поля { Y1,…,Yn} є загальними для двох таблиць та відповідно визначені на однакових доменах.

З'єднанням таблиць А і В називається таблиця з полями {X1,…, Xm, Y1,…, Yn, Z1,…, Zk}, яка містить множину всіх таких записів {X:x,Y:y,Z:z}, для яких у таблиці А значення поля Х дорівнює х, а поля Y дорівнює y, а в таблиці В значення поля Y також дорівнює y, а поля Z дорівнює z.

Операція з'єднання записується так J:= A JOIN B.

При з'єднанні відбувається конкатенація полів та записів таблиць, а також виключення повторення полів та записів.

Більш докладно ці операції будуть розглянуті при вивченні операцій маніпулювання з РТ.

Подальша нормалізація таблиць, що мають БЗ, ґрунтується на теоремі Фейджина:

Таблицю Т (A, B, C) можна відобразити без втрат у таблиці Т1 (A, B) і Т2 (A, C) у тому, і тільки в тому випадку, коли існує БЗ A àà B | C.

Під проекцією без втрат розуміють такий спосіб декомпозиції таблиці, при якому таблиця Т цілком і без надмірності відновлюється шляхом з'єднання отриманих таблиць Т1 і Т2.

Таблиця Т знаходиться в 4НФ у тому і тільки тому випадку, якщо у випадку існування БЗ A àà B всі інші поля таблиці Т функціонально залежать від A.

Інакше кажучи, таблиця перебуває в 4НФ, якщо вона перебуває в НФБК і не має багатозначних залежностей.

Для усунення БЗ необхідно рознести багатозначні поля в різні таблиці. У нашому прикладі можна зробити декомпозицію тРоботи на дві нові таблиці:

53

тРоботи (*Код_роб, Код_ст) ФЗ: Код_роб → Код_ст

тЗавдання (*Код_роб, Роб_завдання) ФЗ: Код_роб →Роб_завдання.

Обидві ці таблиці знаходяться в 4НФ і вільні від зазначених вище аномалій.

6.10 П'ята нормальна форма

В усіх розглянутих до цього моменту НФ проводилася декомпозиція однієї таблиці на дві. Розглянемо випадок декомпозиції на три таблиці.

Спочатку дамо визначення залежності з'єднання.

Таблиця Т (X, Y, ..., Z) задовольняє залежності з'єднання *(X, Y, ..., Z) у тому і тільки тому випадку, коли Т відновлюється без утрат шляхом з'єднання своїх проекцій на X, Y, ..., Z. Зазначимо, що залежність з'єднання є узагальненням як БЗ, так і ФЗ.

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

тРоботи (Код_роб, Код_ст, Група, Код_роб).

Ключем цієї таблиці є повна сукупність полів, відсутні ФЗ і БЗ. Тому таблиця знаходиться в 4НФ.

Однак у таблиці можуть існувати аномалії. На прикладах можна легко показати, що при додаванні та вилученні записів можуть виникнути проблеми. Ці аномалії неможливо усунути шляхом декомпозиції таблиці на дві інші таблиці. Але можлива декомпозиція на число таблиць, більше 2. Кожна з таких таблиць повинна мати кращі властивості.

Спочатку дамо визначення залежності з'єднання. Таблиця Т (X, Y, ..., Z) задовольняє залежності з'єднання *(X, Y, ..., Z) у тому і тільки тому випадку, коли Т відновлюється без утрат шляхом з'єднання своїх проекцій на X, Y, ..., Z. Зазначимо, що залежність з'єднання є узагальненням як БЗ, так і ФЗ.

Таблиця Т знаходиться в 5НФ у тому і тільки тому випадку, коли будь-яка залежність з'єднання в Т випливає з існування деякого можливого ключа в Т.

Існує й інше визначення: таблиця знаходиться в 5НФ тоді і тільки тоді, коли в кожній її повній декомпозиції всі проекції містять можливий ключ.

Таблиця, що не має жодної повної декомпозиції, також знаходиться в 5НФ. Введемо наступні імена композиційних полів:

СГ = {Код_ст, Група} СР = {Код_ст, Код_роб} ГР = {Група, Код_роб}

Припустимо, що в тРоботи існує залежність з'єднання: * (СГ, СР, ГР). Аномалії можна усунути шляхом декомпозиції тРоботи на три нових

таблиці:

тСтуденти (Код_ст, Група)

54