Бази даних �та інформаційні системи

Нормалізація

Лекції 10, 11, 12

Лекція 9,10

План лекції

Вступ.

1. Мета та варіанти застосування нормалізації в проектуванні РБД
2. Проблем, пов'язаних із надмірністю даних
3. Способи оцінювання застосовності або якості спроєктованих відношень
4. Концепція функціональної залежності
5. Використання функціональної залежності для групування атрибутів у відношення,
6. Способи проведення процесу нормалізації
7. Нормальні форми: 1НФ, 2НФ, 3НФ, НФБК, 4НФ, 5НФ
8. Приклади приведення даних до 3НФ

Висновок

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

2

Вступ

Класична нормалізація

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

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

Нормалізація - процес перетворення відносин бази даних (БД) до вигляду, що відповідає нормальним формам.

Тип підходу до проектування БД:

ВИСХІДНИЙ

​

Базова методологія:

ПОБУДОВА ВІДНОШЕНЬ НА ОСНОВІ АНАЛІЗУ

ФУКНЦІОНАЛЬНИХ ЗАЛЕЖНОСТЕЙ

​

Підхід запропонований Е.Ф. Коддом у 1972 р.

1НФ, 2НФ, 3НФ - 1972р.;

НФБК - 1974р;

4НФ - 1977р.;

5НФ - 1979р.�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

3

Мета та варіанти застосування нормалізації

Варіанти застосування нормалізації до проєктування РМД:

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

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

Зауваження!

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

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

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

4

Логічне проектування

Цей етап включає такі кроки

1. Створення та перевірка локальної логічної моделі даних для окремих користувачів
1. Виключення особливостей, несумісних із РМ:
1. Перетворення двосторонніх зв'язків типу M:N
2. Перетворення зв'язків з атрибутами
3. Перетворення складних зв'язків
4. Перетворення багатозначних атрибутів
5. Перетворення рекурсивних зв'язків M:N

Додатковий аналіз:

• Повторна перевірка зв'язків типу 1:1
• Аналіз рекурсивних зв'язків 1:1
• Видалення надлишкових зв'язків
• Аналіз зв'язків супер клас/підклас
• Формування відношень на основі логічної моделі (розкриття схеми)
• Перевірка відношень з використанням засобів нормалізації
• Перевірка придатності відношень для виконання користувацький транзакцій
• Визначення обмежень цілісності
• Узгодження локальної логічної моделі даних із користувачем
3. Створення та перевірка глобальної логічної моделі даних

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

5

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

Приклад1

БП:

1. Співробітник обіймає тільки одну посаду і працює тільки в одному відділенні.
2. Зарплата співробітника не залежить від посади, яку він обіймає.
3. Відділення розташоване тільки за однією адресою

Таблиця 1.1 - Відношення Співробітник

​

​

​

​

Таблиця 1.2 - Відношення Відділення

​

​

Таблиця 2 - Відношення Співробітник_Відділення

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

6

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

Схема 1

Співробітник_ Відділення (СпіврІН, СпіврПІБ, Посада, Зарплата, ВіддІН, ВіддАдреса)

​

Схема 2

Співробітник (СпіврІН, СпіврПІБ, Посада, Зарплата, ВіддІН)

Відділення (ВіддІН, ВіддАдреса)

​

Порівняння схем:

Співробітник_Відділення - містить надлишкові дані:

відомості про адресу відділення повторюються для кожного співробітника

Надмірність даних призводить до аномалій оновлення:

• аномалії вставки,
• аномалії видалення,
• аномалії модифікації

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

7

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

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

8

Схема 1

Співробітник_ Відділення (СпіврІН, СпіврПІБ, Посада, Зарплата, ВіддІН, ВіддАдреса)

Схема 2

Співробітник (СпіврІН, СпіврПІБ, Посада, Зарплата, ВіддІН)

Відділення (ВіддІН, ВіддАдрес)

Аномалії вставки

Ситуація 1. Необхідно вставити інформацію про нового співробітника

Схема 1: Під час вставки відомостей про нового співробітника у відношення Співробітник_Відділення необхідно вказати і відомості про відділення компанії (ВіддАдреса), в якому ці співробітники працюють.

Схема 2: Проблем не виникне, оскільки для кожного співробітника необхідно ввести тільки номер відділення компанії.

Ситуація 2. Необхідно вставити інформацію про нове відділення

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

Схема 2: Проблем не виникне, оскільки відомості про відділення вводяться незалежно від співробітників.

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

Ситуація. Видалення останнього співробітника відділення

Схема 1: Видалиться інформація про відділення.

Схема 2: Проблем не виникне, оскільки відомості про відділення зберігаються окремо від співробітників

Аномалії модифікації

Ситуація. Зміна атрибутів для деякого відділення, наприклад, інформації про адресу.

Схема 1: Необхідно оновити поле ВіддАдрес значення в рядках для всіх співробітників відділення.

Схема 2: Проблем не виникне, оскільки відомості про відділення зберігаються окремо від співробітників

Перевага схеми 2:

• немає потенційних проблем невідповідності даних;
• зменшення обсягу збереженої інформації.

​

Властивості з'єднання без втрат і збереження залежності

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

9

Процес декомпозиції має 2 властивості:

​

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

​

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

​

Функціональні залежності

В основу нормалізації покладено концепцію функціональної залежності (functional dependency).

​

Функціональною залежністю (ФЗ) атрибута b від атрибута а у відношенні R - називається такий зв'язок між атрибутами, коли кожне значення атрибута а однозначно визначає значення атрибута b (визначає тільки одне значення атрибута b), причому під атрибутом а може також розумітися і група атрибутів

​

Позначення:

Атрибут b функціонально залежить від атрибута а:

а → b

​

ФЗ визначається на основі обмежень ПрО (бізнес-правилами)

​

Детермінант ФЗ - атрибут або група атрибутів, від якого розглядається залежність

​

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

10

Функціональні залежності

Приклади:

БП: Співробітник обіймає тільки одну посаду

Кожну посаду може займати багато співробітників

​

СпівробІН → Посада (1:1) ФЗ

​

2 → Асистент

​

СпівробІН - детермінант ФЗ

---------------------------------------------------------------------

​

Посада → СпівробІН (1:М)

​

→ 2

Асистент → 4

→ 6

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

11

×

×

×

Функціональні залежності

Зауваження!

1. Нехай а → b, тоді якщо два рядки мають одне й те саме значення атрибута а,

то вони обов'язково мають одне й те саме значення атрибута b.

Однак для заданого значення атрибута b може існувати кілька значень атрибута а.

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

Приклад.

У будь-який момент часу:

СпівробІН → Співроб_ПІБ (1:1) ФЗ

У певний момент часу:

Співроб_ПІБ → СпівробІН (1:1),

але може змінитися на (1:М), отже, не є ФЗ.

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

Приклади тривіальних залежностей:

СпівробІН, Співроб_ПІБ → Співроб_ПІБ

СпівробІН, Співроб_ПІБ → СпівробІН

​

​

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

12

Функціональні залежності

Приклад 1 Функціональні залежності відношення СпівробітникВідділення

БП:

1. Співробітник обіймає тільки одну посаду, працює тільки в одному відділенні.
2. Зарплата співробітника залежить від посади, яку він обіймає, і від відділення, в якому він працює.
3. За однією адресою розташоване тільки одне відділення, відділення розташоване тільки за однією адресою

​

​

​

Функціональні залежності:

ФЗ1: СпіврІН → СпівПІБ, Посада, Зарплата, ВіддІН, ВіддАдреса

ФЗ2: ВіддІН → ВіддАдреса

ФЗ3: ВіддАдреса → ВіддІН

ФЗ4: ВіддІН, Посада → Зарплата

ФЗ5: ВіддАдреса, Посада → Зарплата

​

​

​

​

​

​

​

​

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

13

Функціональні залежності

Виявлення первинного ключа відношення

з використанням функціональних залежностей

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

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

​

Приклад 1. Відношення Співробітник_Відділення

Єдиним потенційним ключем відношення Співробітник_Відділення, а отже, і його первинним ключем, є атрибут СотрІН

​

​

​

​

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

14

Функціональні залежності

Висновки:

У процесі нормалізації потрібно враховувати такі основні характеристики залежностей між атрибутами:

• зв'язок типу 1:1;
• справедливість за будь-яких умов;
• нетривіальність.

​

​

​

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

15

Нормалізація

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

Опис.

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

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

Для РМД обов'язковим є задоволення вимогам 1НФ.

​

Усі інші НФ використовуються за бажанням проєктувальників.

Рекомендується виконувати нормалізацію до 3НФ.

​

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

​

​

​

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

16

Нормалізація

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

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

Приклад 2

Відомості про об'єкти нерухомості, орендовані клієнтом Іванов І.І.

​

​

​

​

​

​

​

Рисунок 1.1 - Вихідні дані

Таблиця 0 - Ненормалізована таблиця Клієнт_Оренда_Об'єкт_Власник

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

17

Ненормалізована форма (ННФ)

Приклад 2 (продовження)

БП:

1. Клієнт може орендувати конкретний об'єкт тільки 1 раз
2. Клієнт може починати орендувати в одну дату тільки один об'єкт
3. Об'єкт нерухомості в одну дату може орендуватися тільки 1 раз
4. Об'єкт нерухомості належить тільки одному власнику
5. Дата закінчення оренди може бути не відома або змінена
6. Оплата залежить від об'єкта нерухомості

​

Таблиця 0 - Ненормалізована таблиця Клієнт_Оренда_Об'єкт_Власник

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

18

Приклад 2 (продовження)

Проектування на основі побудови ER - моделі

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

19

Перша нормальна форма (1НФ)

Визначення:

Перша нормальна форма (1НФ) - відношення, у якому на перетині кожного рядка і кожного стовпчика міститься тільки одне атомарне значення.

Вимога 1НФ:

1. Відсутність повторюваних груп.

2. Наявність первинного ключа.

Дії для приведення до 1НФ:

1. Вибір ключового атрибута ненормалізованої таблиці.
2. Пошук повторюваних груп.
3. Усунення повторюваних груп.

Для усунення повторюваних груп існує 2 підходи:

а) групи, що повторюються, усуваються шляхом введення в порожні рядки даних, що повторюються;

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

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

Аналіз: - дані мають меншу надмірність

- складнощі пов'язані з виділенням повторюваних груп

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

​

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

20

Перша нормальна форма (1НФ)

Приклад 2 (продовження)

Таблиця 0 - Ненормалізована таблиця Клієнт_Оренда_Об'єкт_Власник

​

​

​

​

​

​

​

Дії для приведення до 1НФ (приклад):

​

1.Вибір ключового атрибута ненормалізованої таблиці.

​

ПК: НомерК

​

2. Пошук груп, що повторюються.

​

Структура групи, що повторюється:

(НомерО, АдресаО, ДатаН, ДатаО, Плата, НомерВ, НазваВ)

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

21

Перша нормальна форма (1НФ)

Приклад 2 (продовження)

3. Усунення повторюваних груп.

Підхід а:

- група, що повторюється, усувається за допомогою введення в кожен рядок з описом Об'єкта нерухомості відповідних відомостей про Клієнта

Отримуємо відношення:

​

Клієнт_Оренда_Об'єкт_Власник(НомерК, НомерО, ПІБ_К, АдресаО, ДатаН, ДатаО, Плата, НомерВ, НазваВ)

Таблиця 1 - Відношення Клієнт_Оренда_Об'єкт_Власник (1НФ)

​

​

​

​

​

​

​

Потенційні ключі:

НомерК, НомерО

НомерК, ДатаН

НомерО, ДатаН

Первинний ключ:

НомерК, НомерО

Висновок: Відношення Клієнт_Оренда_Об'єкт_Власник перебуває в 1НФ.� Аналіз: Відношення схильне до аномалій оновлення

​

​

​

​

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

22

Перша нормальна форма (1НФ)

Приклад 2 (продовження)

3. Усунення повторюваних груп.

Підхід б:

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

​

Отримуємо відношення:

​

Клієнт (НомерК, ПІБ_К)

Оренда_Об'єкт_Власник (НомерК, НомерО, АдресаО, ДатаН, ДатаО, Плата, НомерВ, НазваВ )

​

Висновок: Відношення

Клієнт,

Оренда_Об'єкт_Власник

перебувають в 1НФ.

​

Аналіз: Відношення Оренда_Об'єкт_Власник також має надмірність, отже, схильне до аномалій оновлень

� Увага!!! Далі використовуємо результат підходу а

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

23

Друга нормальна форма (2НФ)

2НФ - застосовується до відносин зі складовим ПК

Якщо відношення в 1НФ і має простий ПК, то воно вже в 2НФ і треба відразу перевіряти вимоги до 3НФ.

Заснована на вимозі повної функціональної залежності від ПК

​

Повна функціональна залежність

Повна ФЗ а → b - ФЗ, за якої b функціонально залежить від повного значення атрибута а і не залежить від жодної підмножини повного значення атрибута а.

​

Приклад повної залежності

ФЗ: НомерК, НомерО → ДатаН

​

Приклад часткової залежності

​

ФЗ: НомерК, НомерО → Плата,

оскільки за БП 4:Оплата залежить від об'єкта нерухомості

​

За часткової залежності виникають аномалії оновлення.

​

Наприклад, при зміні значення Плата для об'єкта Кв4

необхідно оновити 2 рядки.

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

24

Друга нормальна форма (2НФ)

Визначення:

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

​

Вимога 2НФ:

1 Відношення перебуває в 1НФ.

2. Відсутність ЧФЗ від складеного ключа.

​

Дії для приведення до 2НФ:

1. Виявлення ФЗ (повної, часткової).
2. Усунення ЧФЗ.

​

Для усунення ЧФЗ:

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

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

25

Друга нормальна форма (2НФ)

Приклад 2 (продовження)

​

Дії для приведення до 2НФ (приклад):

​

1. Виписуємо ФЗ відношень

Клієнт_Оренда_Об'єкт_Власник

(повну ФЗ від ПК, часткові, транзитивні).

ФЗ0: НомерК, НомерО → ПІБ_К, АдресаО, ДатаН, ДатаО, Плата, НомерВ, НазваВ

- ФЗ від ПК

ФЗ1: НомерК, НомерО → ДатаН, ДатаО; - Повна ФЗ від ПК (ПФЗ)

ФЗ2: НомерК → ПІБ_К; - Часткова ФЗ від ПК (ЧФЗ)

ФЗ3: НомерО → АдресаО, Плата, НомерВ, НазваВ; - Часткова ФЗ від ПК (ЧФЗ)

ФЗ4: НомерВ → НазваВ; - Транзитивна залежність (ТФЗ)

​

2. Усунення ЧФЗ.

​

Оренда (НомерК(FК), НомерО(FК),ДатаН, ДатаО)

Клієнт (НомерК, ПІБ_К)

Об'єкт_Власник (НомерО, АдресаО, Плата, НомерВ, НазваВ)

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

26

2НФ

Друга нормальна форма (2НФ)

Приклад 2 (продовження)

Таблиця 2.1 - Відношення Клієнт (2НФ)

​

​

​

�Таблиця 2.2 - Відношення Об'єкт_Власник (2НФ)

​

​

​

​

​

​

Таблиця 2.3 - Відношення Оренда (2НФ)

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

27

Третя нормальна форма (3НФ)

Транзитивна залежність:

Якщо для атрибутів а, b, c деякого відношення існують залежності

а → b, b → c,

то кажуть, що атрибут c транзитивно залежить від атрибута а через атрибут b

(за умови, що атрибут а функціонально не залежить ні від атрибута b,

ні від атрибута с)

Наявність транзитивних ФЗ призводить до аномалій оновлення

Визначення 3НФ:

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

Вимога 3НФ:

1) Відношення перебуває у 2НФ.

2) Відсутність ТФЗ від ПК.

Дії для приведення до 3НФ:

1. Виявлення ТФЗ.
2. Усунення ТФЗ.

Для усунення ЧФЗ:

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

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

28

Третя нормальна форма (3НФ)

Приклад 2 (продовження)

​

Дії для приведення до 3НФ (приклад):

1. Виписуємо ФЗ відношень

​

Оренда (НомерК(ВК), НомерО(ВК),ДатаН, ДатаО)

ФЗ1: НомерК, НомерО → ДатаН, ДатаО; - Повна ФЗ від ПК

​

Клієнт (НомерК, ПІБ_К)

ФЗ2: НомерК → ПІБ_К; - Повна ФЗ від ПК

​

Об'єкт_Власник (НомерО, АдресаО, Плата, НомерВ, НазваВ)

ФЗ3: НомерО → АдресаО, Плата, НомерВ, НазваВ; - Повна ФЗ від ПК

ФЗ4: НомерВ → НазваВ; - Транзитивна залежність

​

2. Усунення ТФЗ.

Оренда (НомерК(FК), НомерО(FК),ДатаН, ДатаО)

Клієнт (НомерК, ПІБ_К)

Об'єкт (НомерО, АдресаО, Плата, НомерВ(FК))

Власник (НомерВ, НазваВ)

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

29

3НФ

Третя нормальна форма (3НФ)

Приклад 2 (продовження)

Таблиця 2.1 - Відношення Клієнт (3НФ)

​

​

​

�Таблиця 2.2.1 - Відношення Об'єкт (3НФ)

​

​

​

​

Таблиця 2.2.2.2 - Відношення Власник (3НФ)

​

​

​

​

Таблиця 2.3 - Відношення Оренда (3НФ)

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

30

Третя нормальна форма (3НФ)

Приклад 2 (продовження)

Схема декомпозиції

відношення Клієнт_Оренда_Об'єкт_Власник (в 1НФ)

на 4 відношення Клієнт, Оренда, Об'єкт, Власник у 3НФ

​

Клієнт_Оренда_Об'єкт_Власник (1НФ)

​

​

Клієнт Оренда Об'єкт_Власник (2НФ)

​

​

Клієнт Оренда Об'єкт Власник (3НФ)

​

Зауваження!!!

1) процес нормалізації полягає в декомпозиції первинного відношення за допомогою послідовного виконання кількох операцій ПРОЕКЦІЇ реляційної алгебри;

2) отримані в результаті декомпозиції відношення забезпечують формування вихідного відношення без втрат, шляхом використання операції ПРИРОДНОГО З'ЄДНАННЯ

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

31

Приклад 1. Закріплення матеріалу. ПО"Чемпіонат з автоперегонів Формула-1"

​

​

​

​

​

Рисунок - Фрагмент документа "Чемпіонат з автоперегонів Формула-1"

БП: 1. У команді м.б. тільки кілька Гонщиків, Гонщик може бути тільки в одній команді та з одної Країні.

2. Кількість кіл залежить від перегонів

3. В одну дату на трасі проходить тільки 1 змагання

​

​

​

​

​

​

​

​

​

Крок1. Перетворення до 1НФ:

Чемпіонат (ІН_Ком, НазваКом, ІН_Траса, НазваТраса, Протяж, Кiльк_кiл, МiсцеГонщ, ДатаПерегонів, ІН_Гонщ, ПІБ_Гонщ, Краї́наГонщ)

Крок 2!!!!. Первинний ключ 1НФ: ІН_Траса, ДатаПерегонів, ІН_Гонщ

ХНУРЕ кафедра Інформатики доц. Яковлева О.В. http://infdbis.blogspot.com/

32

Приклад1.Закріплення матеріалу. "Чемпіонат з автоперегонів Формула-1"

​

Крок3. Виписуємо ФЗ (ПФЗ, ЧФЗ, ТФЗ)

ФЗ0: ІН_Траса, ДатаПерегонів, ІН_Гонщ → ІН_Ком, НазваКом, НазваТраса, Протяж, Кiльк_кiл, МiсцеГонщ, ПІБ_Гонщ, Краї́наГонщ - ФЗ від ПК 1НФ

ФЗ1: ІН_Траса, ДатаПерегонів, ІН_Гонщ → МiсцеГонщ - Повна ФЗ від ПК 1НФ

ФЗ2: ІН_Траса → НазваТраса, Протяж - Часткова ФЗ від ПК 1НФ

ФЗ3: ІН_Гонщ → ПІБ_Гонщ, Краї́наГонщ, ІН_Ком, НазваКом - Часткова ФЗ від ПК 1НФ

ФЗ4: ІН_Траса, ДатаПерегонів → Кiльк_кiл - Часткова ФЗ від ПК 1НФ

ФЗ5: ІН_Ком → НазваКом - Транзитивна залежність 1НФ

​

Крок4. Перетворення до 2НФ (прибираємо часткову ФЗ, залишаються тільки повні ФЗ від ПК)

Траса (ІН_Траса, НазваТраса, Протяж ) (ФЗ2)

ГонщикКоманда (ІН_Гонщ, ПІБ_Гонщ, Краї́наГонщ, ІН_Ком, НазваКом )(ФЗ3) залишилася транзитивна ФЗ Перегони (ІН_Траса(FK), ДатаПерегонів, Кiльк_кiл) (ФЗ4)

РезультатПерегонів (ІН_Траса, ДатаПерегонів(FK), ІН_Гонщ(FK), МiсцеГонщ) (ФЗ1)

​

Крок5. Перетворення до 3НФ (прибираємо транзитивні ФЗ від ПК)

Траса (ІН_Траса, НазваТраса, Протяж ) (ФЗ2)

Гонщик (ІН_Гонщ, ПІБ_Гонщ, Краї́наГонщ, ІН_Ком (FK)) (ФЗ3)

Команда (ИН_Ком, НазваКом) (ФЗ5)

Перегони (ІН_Траса(FK), ДатаПерегонів, Кiльк_кiл) (ФЗ4)

РезультатПерегонів (ІН_Траса, ДатаПерегонів(FK), ІН_Гонщ(FK), МiсцеГонщ) (ФЗ1)

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В. http://infdbis.blogspot.com/

33

Приклад 1. Закріплення матеріалу

Схема БД ПЗ "Чемпіонат з автоперегонів Формула-1"

​

​

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

34

�В-05 ПО "Навчальний процес на 2022/2023"

БП:

1. Навчальний план охоплює всі групи та складається на 2022/2023 навч рік
2. Викладач може нічого не викладати у 2022/2023 році
3. Дисципліна може не читатися у 2022/2023 році
4. Кожна група закріплюється за факультетом, на факультеті багато груп. Шифр групи не змінюється за 5и років навчання.
5. На вивчення однієї і тієї самої дисципліни різним групам може виділятися різна кількість годин. Дисципліни, що мають однакову назву, але різну кількість годин, вважаються різними дисциплінами.
6. Кожен викладач закріплений за кафедрою
7. Навантаження викладача залежить від групи та дисципліни

​

​

​

​

​

​

Дод. ПЗ "План дипломного проектування на 2022/2023"

БП: 8. Студенти 4,5 курсів крім вивчення планових дисциплін займаються написанням дипломної роботи одного з типів: бакалаврська робота, робота магістра

9. За кожним студентом 4,5 курсу (бакалавром, магістром) закріплюють керівника (викладача), а також тему дипломної роботи і призначають підприємство (Базу практики) для проходження переддипломної практики, студент може проходити практику на будь-якій Базі практики.

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

35

�В-05 ПО "Навчальний процес на 2011/2012"

БП:

1. Навчальний план охоплює всі групи
2. Викладач може нічого не викладати у 2011/2012 році
3. Дисципліна може не читатися у 2011/2012 році
4. Кожна група закріплюється за факультетом, на факультеті багато груп.
5. На вивчення однієї і тієї самої дисципліни різним групам може виділятися різна кількість годин. Дисципліни, що мають однакову назву, але різну кількість годин, вважаються різними дисциплінами.
6. Кожен викладач закріплений за кафедрою
7. Навантаження викладача залежить від групи та дисципліни

​

​

​

​

�Рисунок

Дод. ПЗ "План дипломного проектування на 2011/2012"

8. Студенти 4,5 курсів:

• крім вивчення планових дисциплін займаються написанням дипломної роботи одного з типів: бакалаврська робота, дипломна робота спеціаліста, робота магістра;
• за кожним студентом закріплюють керівника (викладача), тему дипломної роботи, а також статус теми (затверджена / не затверджена)

9. Студенти 3-5 курсів:

• проходять практику на одній із Баз практики;
• практика характеризується, Змістом роботи, Оцінкою;
• студент може проходити практику на будь-якій Базі практики.

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

36

Приклад3.Закріплення матеріалу "Відомості про проєкти 1"

​

​

​

​

​

​

​

​

​

​

Рисунок - Дан фрагмент документа "Відомості про проекти"

​

БП: 1. На проєкті має працювати хоча б 1 виконавець

2. Виконавець бере участь у кількох проєктах, але тимчасово може не брати участі в проєктах

3. Замовник може замовляти більше 1 проєкту, у проєкту тільки 1 замовник

4. У виконавця тільки 1 посада, яка не залежить від проєкту

5.Оклад залежить від посади

6. Бюджет проєкту призначається замовником і не залежить від кількості та кваліфікації виконавців

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

37

Приклад4.Закріплення матеріалу "Лікування в санаторіях України"

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

Рисунок - Дан фрагмент документа "Лікування в санаторіях України"

БП:1. Тривалість процедури залежить від тільки самої процедури

2. Кількість сеансів процедури залежить від процедури і клієнта, в його конкретний заїзд

3. Клієнт в одну дату може заїжджати тільки в один санаторій

​

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

38

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

39

Приклад5. Дано фрагмент документа "Історико-культурні цінності"

БП:

1.Номер історико-культурної цінності унікальний, отже, цінність може бути встановлена тільки в одному місці.

2 Історико-культурна цінність обов'язково має автора, яких може бути більше одного автора.

3. Період роботи авторів над однією історико-культурною цінністю може відрізнятися (наприклад, проєкт розробив один автор, другий автор його реалізував). Один і той самий автор може працювати над цінністю кілька разів (наприклад, розробляв проєкт, у виготовленні участі не брав, потім брав участь в установці)

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

40

Дано фрагмент документа "Книга рецептів"

БП: 1.У страви тільки може бути тільки один автор, автор придумує багато страв

2 Енергетична цінність продукту залежить тільки від самого продукту

3. Код страви унікальний, тобто страва з такою самою назвою, але іншого автора матиме інший код.

4. Код продукту унікальний

5. Спосіб приготування залежить від страви, тобто страва характеризується одним способом приготування

6. Вага продукту в різних стравах відрізняється

�

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

41

Дано фрагмент документа "Відомості про проекти 2"

БП:1 Наше підприємство може виконувати одночасно кілька проектів

2 Співробітники можуть одночасно працювати на декількох проектах.

3.Оплата залежить від конкретної роботи

4.У проекту може бути тільки один замовник, замовник може замовляти багато проектів

5. У проєкту зазвичай кілька етапів (як мінімум 1). Номер етапу унікальний тільки в рамках проєкту

6. Співробітник обіймає одну посаду

Питання

ХНУРЕ кафедра Інформатики доц. Яковлева О.В.

42