Висновок

Таким чином, як видно з матеріалу заняття, процес проектування інфологічної моделі даних не такий простий як хотілося б. У залежності від умов сутність може бути асоціацією і навпаки. Необхідно також навчитися правильно виділяти сутності в предметній області і правильно установити зв'язки між ними. І що саме цікаве (це видно з прикладів із сутністю шлюб): спроектована база даних може працювати тільки у визначених умовах, якщо не врахувати всіх можливих ситуацій. На практиці, як правило, саме так і відбувається. В ідеалі ж необхідно, щоб ви самостійно реалізували хоча б один проект інформаційної системи, запропонували його реальним користувачам і побути адміністратором бази даних, щоб усвідомити хоча б невелику дещицю проблем, що виникають через недостатньо продуманий проект. Особистий досвід авторів показує, що будь-які теоретичні рекомендації сприймаються уважно лише після декількох безрезультатних спроб пожвавлення невдало спроектованих систем.

Запитання для перевірки

1. На чому базується моделювання предметної області ?

2. Які види зв'язків можливі між двома сутностями ?

3. Наведіть приклади множинних зв'язків між сутностями

6. Проектування реляційних баз даних з використанням нормалізації План

1. Поняття про нормалізацію відносин

2. Одержання реляційної схеми з er-схеми

З матеріалу попередніх занять ми знаємо, що на етапі інфологічного проектування необхідно визначити з яких сутностей повинна складатися база даних і які атрибути повинні бути в цих сутностях, а також установити зв'язки між сутностями. Однак, на цьому процес проектування не закінчується. Розроблена нами інфологічна модель може не забезпечити в майбутньому потрібну надійність і продуктивність всієї БД. Що може послужити тому причиною? Розглянемо наступний приклад. Наприклад, якщо в нас є таблиця РАХУНКИ, у якій ми зберігаємо інформацію з рахунків клієнтів фірми і разом з цими даними ми будемо зберігати адресу клієнта в кожнім записі таблиці РАХУНКИ, то при зміні адреси клієнта нам доведеться змінити всі записи цієї таблиці, що містять стару адресу. Якщо ж інформацію про адресу клієнта помістити в одному рядку окремої таблиці, то зміни потрібно буде внести тільки один раз. Зрозуміло, що це істотно зменшує час відновлення інформації і цілком усуває імовірність виникнення помилки, зв'язаної тим, що в якомусь рядку залишився стара адреса. Вирішити дану проблему можна за допомогою нормалізації.

1. Поняття про нормалізацію відносин

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

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

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

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

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

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

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

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

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

Перші три нормальні форми (1НФ, 2НФ, ЗНФ) були визначені Коддом.

Як показав час оригінальне визначення Кодда для ЗНФ приводить до деякої неадекватності. Перероблене і більш точне поняття 3НФ було дано Бойсом (Воусе) і Коддом.

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

Рис. 6.1. Нормальні форми.

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

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

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

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

Розглянемо сутність кожної нормальної форми.

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

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

Повторювана група — це стовпці, що повторюються в межах одного і того ж рядка для збереження кількох значень того самого атрибута. Наприклад, ми могли застосувати такий підхід для таблиці НОМЕРА ТЕЛЕФОНІВ, і використовувати її для збереження інформації про номери телефонів організацій. Однак у тому випадку, якщо організація буде мати більш одного телефону, у таблиці НОМЕРА ТЕЛЕФОНІВ довелося б створювати стільки додаткових стовпців, скільки телефонів може мати одна організація. Саме ці додаткові стовпці і називаються повторюваною групою.

Природно, що при порушенні першої нормальної форми подальша розробка реляційної бази даних неможлива. Не залежно від того, чи розробляєте ви базу даних чи додаток бази даних використання повторювальних груп є поганою практикою. З практичної точки зору, що повторюються групи спричиняють цілий букет різних ускладнень у проектуванні. По-перше, повертаючи до прикладу з таблицею НОМЕРА ТЕЛЕФОНІВ, якщо ви хочете зберігати в даній таблиці відомості про всі телефони, що є в організації, те всі рядки таблиці будуть містити повторювані поля, незалежно від того, чи використовуються вони в кожнім конкретному випадку. Це, безсумнівно, приводить до невиправданої витрати дискового простору. По-друге, групи що повторюються створюють чимало труднощів при обробці даних, що представляються ними. Зокрема, задача форматування таких даних може виявитися не з легких. Ви можете зіткнутися не тільки з послідовністю рядків, але і з послідовністю стовпців, через що одномірна задача відразу ж стає двовимірною. По-третє, якщо доведеться збільшити максимальну кількість телефонів, що може мати організація, то доведеться змінити структуру таблиці НОМЕРА ТЕЛЕФОНІВ, а також усіх додатків, що звертаються до цієї таблиці.

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

Давайте знову повернемося до прикладу таблиці РАХУНКИ. Якщо первинний ключ таблиці складається зі стовпців Адреса_номер і Рахунок_номер, то збереження адреси в стовпці Адреса цієї ж таблиці може привести до порушення другої нормальної форми. Причина цього полягає в тому що вміст стовпця Адреса для рядків, що містять ту саму адресу, не буде однозначно ідентифікуватися первинним ключем. Однозначна ідентифікація буде відбуватися тільки за значенням поля Адреса_номер, а значення Рахунок_номер ніяк не вплине на неї. Тому стовпець Адреса потрібно одержувати, при необхідності, з окремої таблиці за допомогою об'єднання а не зберігати в таблиці РАХУНКИ.

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

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

Знову розглянемо приклад таблиці РАХУНКИ. Нехай первинний ключ таблиці складається зі стовпців Адреса_номер і Рахунок_номер. Одним з неключових стовпців таблиці буде, очевидно, стовпець Клієнт_номер. Якщо крім стовпця Клієнт_номер у таблицю РАХУНКИ помістити стовпець Клієнт_ім'я, то вона не буде відповідати критерію третьої нормальної форми, тому що обоє ці стовпці можуть залежати друг від друга. При зміні значення полю Клієнт_номер може виникнути необхідність і в зміні значення полю Клієнт_ім'я, і навпаки. Таким чином, стовпець Клієнт_ім'я потрібно винести в окрему таблицю (наприклад, у таблицю КЛІЄНТ) і при необхідності звертатися до нього за допомогою об'єднання.

Удосконалена третя нормальна форма, називана, як ми вже знаємо, нормальною формою Бойса-Кодда (BCNF — Boyce-Codd Normal Form) і вимагає, щоб кожен стовпець, від якого залежить інший стовпець, сам був унікальним ключем.

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

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

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

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

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

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

Рис. 6.2. Ілюстрація функціональної залежності.

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

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

Навчання

Дисципліна	Викладач	Підручник
Інформатика	Шипілов П.А.	Форсайт Р. Паскаль для всіх
Інформатика	Шипілов П.А.	Уэйт М. і ін. Мова Сі
Інформатика	Голованевский Г.Л.	Форсайт Р. Паскаль для всіх
Інформатика	Голованевский Г.Л.	Уэйт М. і ін. Мова Сі
...	...	...

Рис. 6.3. Ілюстрації багатозначних залежностей

Для прикладу розглянемо таблицю "Навчання" (рис. 6.3). У ній є багатозначна залежність "Дисципліна-Викладач": дисципліна (у прикладі Інформатика) може читатися кількома викладачами (у прикладі Шипіловим і Голованевським). Є й інша багатозначна залежність "Дисципліна-Підручник": при вивченні Інформатики використовуються підручники "Паскаль для всіх" і "Мова Сі". При цьому Викладач і Підручник не зв’язані функціональною залежністю, що приводить до появи надмірності (для додавання ще одного підручника доведеться ввести в таблицю два нових рядки). Справа поліпшується при заміні цієї таблиці на дві: (Дисциплін-Викладачів і Дисципліна-Підручник).

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

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

Таким чином, зв'язок між іншими стовпцями таблиці ОРЕНДАР і стовпцем Роботодавець може прийняти форму багатозначної залежності — у того самого значення стовпця Орендар_номер може бути кілька значень Роботодавець. Виходячи з практичних розумінь, ви можете піти на це свідомо, тому що в орендаря дійсно може бути кілька роботодавців. Крім того, вас може цікавити, яку роботу виконує орендар у кожного роботодавця. Однак для того, щоб таблиця відповідала четвертій нормальній формі, потрібно створити окрему таблицю, призначену для зіставлення орендарів і роботодавців. В ідеальному випадку така таблиця повинна містити тільки два стовпці Орендар_номер і Роботодавець, кожний з який був би частиною складеного первинного ключа. Тоді, якщо вам потрібно було б одержати інформацію по певному орендарю, ви могли б створити об'єднання таблиці ОРЕНДАР з новою таблицею за допомогою їхнього спільного полю Орендар_номер.

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

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

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

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

Зрештою, знаючи про існування третьої нормальної форми, як можна допустити явну залежність стовпців Роботодавець і Роботодавець_Адреса Друг від друга?! Однак чи принесе вам створення такої таблиці які-небудь реальні плоди? Швидше за все, — ні. Інформація про роботодавця цікава не сама по собі — вона зв'язана з кожним конкретним орендарем. Компанії «РОГА і КОПИТА», узагалі ж, усе рівно, на кого працюють її клієнти. Тоді давайте припустимо, що компанія не буде зберігати відомості про кількох роботодавців орендаря і ніколи не буде змінювати всю структуру даних про роботодавців. У цьому випадку створення окремої таблиці буде порожньою витратою часу.

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

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

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

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