1. Системи управління базами даних

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

Історія

Першим поколінням СКБД прийнято вважати ієрархічні й мережеві системи. Ці системи отримали широке поширення в 1970-х роках, а першою комерційною системою цього типу була система IMS компанії IBM.

У 1980-х роках ці системи були витіснені системами другого покоління — повсюдно використовуваними і донині реляційними СКБД. У цих системах використовувалися непроцедурні мови управління даними (SQL) і передбачався значний ступінь незалежності даних. Реляційні системи внесли значні удосконалення в управління даними: графічний користувацький інтерфейс (GUI), клієнт-серверні застосунки, розподілені бази даних, паралельний пошук даних та інтелектуальний аналіз даних.

Але вже до кінця 1980-х років існуюча тоді реляційна модель перестала задовольняти розробників в силу низки обмежень. Відповіддю на зростаючу складність програм баз даних стали два нових напрямки розвитку СКБД: об'єктно-орієнтовані СКБД і об'єктно-реляційні СКБД.

У 1991 був утворений консорціум ODMG (en:Object Data Management Group), основною метою якого стало вироблення промислового стандарту об'єктно-орієнтованих баз даних. Між 1993 та 2001 роками ODMG опублікувала п'ять ревізій своїх специфікацій. Остання версія стандарту має індекс 3.0, після чого група розпустилася. До кінця 1990-х існувало близько десяти компаній, що виробляли комерційні продукти, що позиціонуються на ринку як ООСКБД. Найбільш відомими системами даного класу стали Objectivity, Versant виробництва однойменних компаній, а також СКБД Jasmine, випущена компанією CA. Незважаючи на переваги, що дозволяють ефективніше вирішувати певний ряд завдань, об'єктно-орієнтовані системи так і не змогли завоювати значущу частку ринку СКБД, залишившись «нішевим» продуктом.

Постачальниками традиційних реляційних СКБД також була проведена значна робота з об'єднання об'єктно-орієнтованих і реляційних систем. Розробники постаралися розширити мову SQL, щоб включити в неї концепції об'єктно-орієнтованого підходу, зберігаючи переваги реляційної моделі (об'єктні розширення мови SQL були зафіксовані в стандарті SQL:1999). Основний принцип — це еволюційний розвиток можливостей СКБД без корінний ломки попередніх підходів та зі збереженням наступності з системами попереднього покоління.

Поняття СКБД третього покоління, якими, власне кажучи, і є об'єктно-реляційні СКБД, з'явилося після опублікування групою відомих фахівців в області баз даних «Маніфесту систем баз даних третього покоління». Основні принципи СКБД третього покоління, позначені в маніфесті:

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

2. СКБД третього покоління повинні включити в себе СКБД другого покоління. Системи другого покоління внесли вирішальний вклад у двох областях — непроцедурний доступ за допомогою мови запитів SQL і незалежність даних. Ці досягнення обов'язково повинні враховуватися в системах третього покоління.

3. СКБД третього покоління повинні бути відкриті для інших підсистем. Це включає оснащення різноманітними інструментами підтримки прийняття рішень, доступом з багатьох мов програмування, інтерфейсами до існуючих популярних систем і бізнес-застосунків, можливістю запуску програм з бази даних на іншій машині і розподілені СКБД. Весь набір інструментів і СКБД має ефективно функціонувати на різноманітних апаратних платформах з різними операційними системами. Крім того, СКБД, що розраховує на широку сферу застосування, повинна бути оснащена мовою четвертого покоління (4GL).

У середині 1990 років було лише кілька дослідних прототипів СКБД, які поєднали найкращі риси реляційних і об'єктно-орієнтованих СКБД. Першим комерційним продуктом, якому були властиві об'єктно-реляційні риси, став Universal Server компанії Informix (згодом була поглинена IBM). В даний час більшість цих ідей вже втілено в реальних комерційних рішеннях, в тому числі і в продуктах основних постачальників СКБД (Oracle Database і IBM DB2).

Розвиток індустрії систем керування базами даних базується на значних фундаментальних наукових дослідженнях. Найчастіше, між самими дослідженнями та їхньою конкретною реалізацією в прикладних рішеннях минають роки, а іноді й десятиліття. Роботу в області управління даними проводять як університетські дослідницькі групи (MIT, Berkeley), так і центри розробок основних постачальників СКБД (Oracle, IBM, Microsoft). Інвестування в управління даними — це довгострокове, і разом з тим, вигідне вкладення коштів. В даний час дослідники мають у своєму розпорядженні засоби, що дозволяють ефективно реалізувати найскладніші запити, що маніпулюють терабайтами й петабайтами різних даних.

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

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

2. Значне ускладнення структур використовуваних даних. Прості види даних у вигляді чисел і символьних рядків стали доповняться численною мультимедійною інформацією, просторовими, процедурними даними та великою кількістю інших складних форматів.

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

4. Активний розвиток засобів комунікації та «всесвітньої павутини» World Wide Web. WWW стає єдином інформаційним середовищем, що пронизує весь світ і об'єднує величезне число користувачів та електронних пристроїв.

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

Основні характеристики СКБД

• Контроль за надлишковістю даних

• Несуперечливість даних

• Підтримка цілісності бази даних (коректність та несуперечливість)

• Цілісність описується за допомогою обмежень

• Незалежність прикладних програм від даних

• Спільне використання даних

• Підвищений рівень безпеки

Можливості СКБД

• Дозволяється створювати БД (здійснюється за допомогою мови визначення даних DDL (Data Definition Language))

• Дозволяється додавання, оновлення, видалення та читання інформації з БД (за допомогою мови маніпулювання даними DML, яку часто називають мовою запитів)

• Можна надавати контрольований доступ до БД за допомогою:

1. Системи забезпечення захисту, яка запобігає несанкціонованому доступу до БД;

2. Системи керування паралельною роботою прикладних програм, яка контролює процеси спільного доступу до БД;

3. Система відновлення — дозволяє відновлювати БД до попереднього несуперечливого стану, що був порушений в результаті збою апаратного або програмного забезпечення

Основні компоненти середовища СКБД

1. апаратне забезпечення

2. програмне забезпечення

3. дані

4. процедури — інструкції та правила, які повинні враховуватись при проектуванні та використанні БД

5. користувачі

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

   2. розробники БД

   3. прикладні програмісти

   4. кінцеві користувачі

Архітектура СКБД

Існує трирівнева система організації СКБД ANSI-SPARC, при якій існує незалежний рівень для ізоляції програми від особливостей представлення даних на нижчому рівні.

Рівні:

1. Зовнішній — представлення БД з точки зору користувача.

2. Концептуальний — узагальнене представлення БД, описує які дані зберігаються в БД і зв'язки між ними. Підтримує зовнішні представлення, підтримується внутрішнім рівнем.

3. Внутрішній — фізичне представлення БД в комп'ютері.

Логічна незалежність — повна захищеність зовнішніх моделей від змін, що вносяться в концептуальну модель.

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

2. Моделі даних СУБД

Моделі та типи даних

Дані, які зберігаються в БД мають визначену логічну структуру, тобто описуються деякою

моделлю

представлення даних

(моделлю даних), яку підтримує СКБД. До числа класичних відносяться

наступні моделі даних:

Ієрархічна;

Мережева

Реляційна.

Крім того, в останні роки з’явились та стали більш активно впроваджуватись на практиці наступні

моделі даних:

Постреляційна,

Багатовимірна

Об’єктно-орієнтована

Ієрархічна модель

В ієрархічній моделі зв’язки між даними можна описати за допомогою дерева. Для опису структури

ієрархічної БД в деяких мовах програмування використову

ють тип даних «дерево», подібний до

типу даних «структура» мови С. Тип «дерево» є складеним. Він включає в себе піддерева, кожне з

яких має тип «дерево», яке складається з кореневого типу та впорядкованого набору, (можливо

порожнього) підлеглих типів. Кожний з елементарних типів, включених в тип «дерево» є простим

або складеним типу «запис». Простий запис складається з одного типу, наприклад числового, а

складений «запис» об’єднує деяку сукупність типів, наприклад, цілий, рядок символів та дату.

Кореневим

називається тип, який має підлеглі типи, та сам не є підтипом.

Підлеглий

тип (підтип) є

нащадком

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

одного й того ж дерева є

близнюками

по відношенню один до одного.

У

цілому тип «дерево» є упорядкованою сукупністю екземплярів даних типу дерево, які містять

екземпляри типу «запис». Часто відношення споріднення між типами переносять на відношення

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

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

вниз та зліва направо.

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

•

Пошук вказаного екземпляра БД (наприклад дерева із значенням 10 в полі Відділ_номер);

•

Перехід від одного дерева до іншого;

•

Перехід від одного запису всередині дерева до іншого (наприклад, до наступного запису

типу Співробітники);

•

Вставка нового запису у вказану позицію;

•

Видалення поточного запису;

Основне правило контролю цілісності даних формулюється наступним чином: нащадок не може

існувати без батька, а в деяких батьків може не бути нащадків.

До

переваг

ієрархічної моделі даних відносяться ефективне використання пам’яті ЕОМ та непогані

показники часу виконання основних операцій над даними. Ієрархічна модель даних зручна для

роботи з ієрархічно упорядкованою інформацією.

Недоліки

— громіздкість обробки інформації із складними логічними зв’язками, а також складність

для розуміння звичайними користувачами (IMS, PC/Focus, Ока, ИНЭС, МИРИС).

Мережева

модель

Мережева

БД складається з набору записів та набору відповідних зв’язків. Якщо в ієрархічних

структурах запис-нащадок міг мати тільки один запис-попередник, то у мережевій моделі даних він

може мати довільне число записів-попередників.

Найважливішими операціями маніпулювання даними баз мережевого типу є такі:

•

Пошук запису в БД;

•

Перехід від попередника до першого нащадка;

•

Перехід від нащадка до попередника;

•

Створення нового запису;

•

Видалення поточного запису;

•

Модифікація поточного запису;

•

Включення запису в зв’язок;

•

Виключення запису із зв’язку;

•

Зміна зв’язків.

Перевагами

мережевої моделі є можливість ефективної реалізації за показниками затрат пам’яті

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

створенні довільних зв’язків.

Недоліками

мережевої

моделі є велика складність схеми БД, а також складність обробки

інформації для звичайного користувача.(IDMS, СЕТЬ, КОМПАС).

Реляційна модель

Реляційна модель даних запропонована співробітником фірми IBM Коддо

м та базується на понятті

відношення (relation).

Відношення

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

представлення відношення є звичайна таблиця, яка має рядки (записи) та стовпчики (колонки).

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

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

студентів, про кожного з яких відомі наступні характеристики: ПІБ, стать, вік, домашня адреса. Для

опису складних логічних структур застосовують зв’язування таблиць.

Перевагою

реляційної моделі є простота, наочність та зручність реалізації на ЕОМ. Це є основною

причиною їх широкого використання.

Недоліки

—

складність опису ієрархічних та мережевих зв’язків. Приклади реляційних СКБД (dBase

IV, FoxBase, Paradox, Visual Foxpro, Access, Oracle).

Гіперпосилання (hyperlinks), призначені для зберігання посилань на різні ресурси (файли,

документи), що знаходяться за межами БД, наприклад в мережі Інтернет.

Елементи реляційної моделі

Елемент реляційної моделі

Форма представлення

Відношення

Таблиця

Схема відношення

Заголовок таблиці

Кортеж

Рядок

таблиці

Сутність

Опис властивостей об’єкта

Атрибут

Заголовок стовпця таблиці

Домен

Множина допустимих значень

атрибута

Значення атрибута

Значення поля в запису

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

Один чи кілька атрибутів

Тип даних

Тип значень елементів таблиці

Первинним

ключем (ключовим атрибутом)

називається атрибут відношення, який однозначно

ідентифікує кожний запис, наприклад, у відношенні СПІВРОБІТНИК (ПІБ, Відділ, Дата_Народження)

ключовим є атрибут ПІБ. Ключ може бути

складним,

тобто складатись з декількох атрибутів. Кожне

відношення обов’язково має комбінацію атрибутів, яка може слугувати ключем. Ключі звичайно

використовують для досягнення наступних цілей:

1.

Виключення дублювання значень у ключових атрибутах;

2.

Упорядкування кортежів (за зростанням, або спаданням);

3.

Прискорення роботи з кортежами;

4.

Організації зв’язування таблиць.

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

СТУДЕНТ (ПІБ, Група, Спеціальність) та ПРЕДМЕТ( Назва_пр, Години), які зв’язані відношенням

СТУДЕНТ_ПРЕДМЕТ(ПІБ, Назва_пр, Оцінка). У цьому відношенні атрибути ПІБ та Назва_пр.

утворюють складений ключ.

Таблицю можна вважати відношенням за виконання наступних умов:

1.

Всі рядки таблиці повинні бути унікальні, тобто не може бути рядків з однаковими

первинними ключами.

2.

Імена стовпчиків таблиці повинні бути різними, а значення їх простими, тобто неприпустимі

група значень в одному стовпчику одного рядка

3.

Всі рядки однієї таблиці повинні мати однакову структуру, яка відповідає іменам та типам

стовпчиків.

4.

Порядок розміщення рядків в таблиці може бути довільним.

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

таблиця вважається БД. В інших СКБД БД може містити декілька таблиць, поєднаних за змістом, а

також процедури контролю інформації. Так при використанні MS Access в файлі БД поряд з

таблицями зберігаються інші об’єкти бази: звіти, макроси, форми, макроси, модулі.

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

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

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

Якщо задане таблицею відношення має ключ, то вважається, що таблиця також має ключ і її

називають

ключовою

чи

таблицею з ключовими полями

.

У більшості СКБД файл таблиці включає керуючу частину (опис типів полів, імена полів та інша

інформація), і область розміщення записів.

3. Проектування СУБД

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

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

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

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

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

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

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

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

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

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

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

5. На наступному етапі визначають зв'язки між таблицями (схему даних). Зв'язки між таблицями організуються на основі спільного поля, причому в одній із таблиць воно обов'язково має бути ключовим. Тобто на стороні "один" має бути ключове поле, яке не повторюється, значення на стороні "багато" можуть повторюватися. 6. "Паперовий" етап роботи над технічними пропозиціями закінчується розробкою схеми даних. Цю схему слід узгодити із замовником, після чого розпочати безпосереднє створення бази даних. Слід пам'ятати, що в ході розробки проекту замовникові неодмінно будуть надходити нові ідеї. Можливість гнучкого використання його побажань суттєво залежить від кваліфікації розробника бази даних. Якщо схема даних складена правильно, підключити до бази нові таблиці неважко. Якщо структура бази нераціональна, розробник може наштовхнутись на суттєві труднощі і дійти суперечності із замовником. Суперечка виконавця із замовником завжди свідчить про недостатню кваліфікацію виконавця. На цьому етапі завершується попереднє проектування бази даних, і на наступному етапі починається її безпосередня розробка (впровадження).

4. Нормалізація реляційної моделі даних

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

Нормалізація – це процес, у результаті якого можна позбавитися дефектів проектування

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

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

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

структура.

Щоб виконати нормалізацію, структура бази даних послідовно приводиться до різних

форм. Взагалі кажучи, кожна наступна форма стосується і попередньої. Наприклад, щоб

схема бази даних відповідала другій нормальній формі, вона повинна також відповідати і

першій нормальній формі. Щоб схема відповідала третій нормальній формі, вона повинна

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

правил, яким повинна відповідати схема.

Перша нормальна форма

Згідно першої нормальної форми, скорочена назва

1НФ

, кожне значення атрибуту або

стовпця повинно бути атомарним. Це означає, що кожен атрибут повинен містити єдине

значення, а не багато значень або інший рядок бази даних.

Розглянемо таблицю, показану на Рис.

1.4.

Це – ненормалізована таблиця книг, яку ми розглядали раніше. Як бачите, тут доданий ще

один стовпець, що називається

avtory

(

автори

), в якому наведені дані про авторів кожної

книги.

Кожне значення у цьому стовпці є списком значень – замість того, щоб містити атомарне

значення (наприклад,

Г.

Домарецька

), стовпець містить списки значень (типу

Г.

Домарецька, Р.

Матуш, Р.

Орищин

). Це є порушенням правил першої нормальної форми.

Щоб привести схему до першої нормальної форми, необхідно в стовпці

автори

розмістити

атомарні значення. Це можна зробити різними способами. Перша, напевно, найочевидніша

можливість, показана на Рис.

1.5.

Ми виділили один рядок на кожного автора. Тепер схема знаходиться у першій нормальній

формі.

Такий розв’язок далекий від ідеального, оскільки він породжує очевидну надлишковість

даних: для кожної комбінації

книга – автор

доводиться зберігати усі характеристики книги.

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

Кращий і найправильніший варіант приведення даних до першої нормальної форми

показаний на Рис.

1.6. У цьому випадку ми виділили дані про авторів в окрему таблицю,

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

надмірності даних.

Друга нормальна форма

Після приведення схеми до першої нормальної форми можна перейти до форм вищих

порядків.

Схема знаходиться у другій нормальній формі (скорочено −

2НФ

), якщо всі атрибути, що

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

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

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

якщо первинний ключ складений з кількох стовпців, то будь-який інший атрибут у таблиці

повинен залежати від комбінації всіх цих стовпців.

Розглянемо приклад, щоб пояснення стало зрозумілішим.

Погляньте на Рис.

1.5. У схемі таблиця

knygy

має один рядок на кожного автора книжки.

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

формі. Чому це так?

Що є первинним ключем цієї таблиці? Ми знаємо, що первинний ключ повинен унікально

ідентифікувати кожен рядок у таблиці. У цьому випадку єдиним варіантом для такої

ідентифікації є використання комбінації

knygaID

і

avtor

. У вказаному представленні

авторів для ідентифікації рядків одного стовпця

knygaID

буде не достатньо: наприклад,

значення

knygaID

, рівне 9008, відповідає відразу трьом рядкам. Проте комбінація

knygaID

і

avtor

вже ідентифікує один рядок, тому можна використовувати цю пару як первинний

ключ. Це породжує таку схему:

). Це означає, що вказані

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

первинного ключа. Таким чином, можна визначити ці атрибути за частиною первинного

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

знаходиться у другій нормальній формі.

Але тоді виникає запитання: «Як привести цю схему до другої нормальної форми?»

Необхідно розбити таблицю на такі таблиці, в яких усі неключові атрибути повністю

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

початкову таблицю на дві:

1.6.

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

Але вона також знаходиться і в другій нормальній формі, оскільки кожен атрибут, що не є

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

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

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

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

Формально, щоб схема знаходилася в третій нормальній формі (

3НФ

), слід виключити усі

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

Але що таке транзитивна залежність?

Звернемося до Рис. 1.3. Маємо таку схему:

Первинним ключем є

knygaID

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

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

Але зауважуємо також, що:

knygaID

→

grupID

knygaID

→

nazvaGrupy

і

grupID

→

nazvaGrupy

А також звертаємо увагу і на те, що

grupID

не є ключем.

Вказане відношення означає, що функціональна залежність

транзитивною. Насправді вона містить проміжний крок (залежність

grupID

→

nazvaGrupy

).

Щоб перейти до третьої нормальної форми, необхідно виключити цю транзитивну

залежність.

Як і з попередніми нормальними формами, щоб перейти до третьої нормальної форми,

необхідно розбити таблицю на кілька таблиць. Перетворюємо схему на пару таблиць:

)

Це знову приводить до схеми для книг, яку ми бачили на Рис.

1.2 і з якої починали наше

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

Іншим способом визначення третьої нормальної форми є такий опис. Формально кажучи,

якщо схема знаходиться у третій нормальній формі, то для будь-якої функціональної

залежності будь-якої таблиці або



у лівій частині функціональної залежності вказаний потенційний ключ;

або



у правій частині функціональної залежності вказана якась частина ключа

цієї таблиці.

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

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

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

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

Boyce

-

Codd

) іноді називають

БКНФ

. Вона є варіацією

третьої нормальної форми. Щоб відношення задовольняло

БКНФ

, воно повинно

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

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

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

зусиль. Але якщо з'являється залежність, що порушує перше правило, доведеться знову

пройти шлях розділення таблиць, аналогічний пройденому вище для

1НФ

,

2НФ

і

3НФ

.

Нормальні форми вищих порядків

Існують нормальні форми вищих (четвертого, п'ятого) порядків, але вони представляють

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

Форми

3НФ

або

БКНФ

буде цілком достатньо, щоб уникнути тих проблем надмірності

даних, з якими вам доведеться мати справу.

Поняття



Об'єкти – це сутності, а відношення – це зв'язки між ними.



Відношення або таблиці містять набори даних у табличній формі.



Стовпці таблиці – це атрибути, що характеризують елементи даних.



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

в стовпцях таблиці.



Ключі використовують для ідентифікації рядків.



Функціональні залежності вказують, від яких атрибутів залежать значення

інших атрибутів.



Схеми іноді ще називають шаблонами бази даних.

Принципи проектування



Мінімізація надлишковості без втрати даних.



Аномалії вставки, видалення і оновлення є проблемами, що виникають при

вставці, видаленні або оновленні даних «дефектних» або неправильно

спроектованих таблиць.



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

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



Нормалізація – формальний процес удосконалення структури бази даних.



Для першої нормальної форми (

1НФ

) необхідно, щоб значення стовпців або

атрибутів були атомарними.



Для другої нормальної форма (

2НФ

) необхідно, щоб неключові атрибути,

залежали від усього ключа.



Для третьої нормальної форма (

3НФ

) необхідно позбавитися транзитивних

залежностей.



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

БКНФ

) вимагає, щоб усі атрибути

функціонально визначалися потенційними ключами.

Вправи

1. Нормалізуйте таку схему до третьої нормальної форми:

zakazy(clientІD, NazvaClienta, AddresaClienta, zakazІD,

zakazData, knygaID, NazvaKnygy, kilkistKnyg)

2.

Спробуйте

привести приклад схеми, що задовольняє правилам 3НФ, але не БКНФ.