Створення та обробка баз даних на ПЕОМ (стр. 13 )

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

Багатозначні залежності можуть бути наступних типів: “один до кількох” (1:М), “кілька до одного” (М:1) і “ кілька до кількох” (М:М).

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

Приведене вище відношення ВИКЛАДАЧ можна перетворити в двоє відносин ВИКЛАДАЧ і УЧЕБН_НАВАНТАЖЕННЯ, наприклад, таким чином:

ВИКЛАДАЧ (ПІБ, Посада, Оклад) і

УЧЕБН_НАВАНТАЖЕННЯ (ПІБ, Предм, Група).

Перше відношення з другим зв'язується зв'язком типу 1:М по атрибуту ПІБ.

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

Основний спосіб виявлення залежності між атрибутами – це уважний аналіз семантики (змісту) атрибутів.

Розглянемо наступний приклад. Нехай є відношення ВИКЛАДАЧ, у якому представлені такі атрибути:

* КодВикл - код викладача;

ПІБ - прізвище, ім'я і по батькові;

Каф - кафедра;

Посада - посада;

Оклад - оклад;

* Предм - предмет;

ВидЗанят - вид заняття.

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

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

У результаті зробленого аналізу виявлені функціональні залежності між атрибутами такі, що у виді схеми зображені на Рис. 4.1. Обґрунтування виявлених залежностей може бути наступне.

Прізвище, кафедра і посада завжди однозначно визначені для кожного викладача. Тому атрибути ПІБ, Каф і Посада функціонально залежать від атрибута
КодВикл.

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

 

ВидЗанят

 

Рис. 4.1. Схема залежностей між атрибутами вихідного

відношення ВИКЛАДАЧ

Отже, існує функціональна залежність атрибута Оклад від атрибута Посада.

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

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

4.3. Перетворення відношень до 1, 2 і 3 нормальних форм

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

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

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

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

У розглянутому вище прикладі відношення ВИКЛАДАЧ не задовольняє вимогам 2НФ. Неключові атрибути ПІБ, Каф і Посада знаходяться в частковій функціональній залежності від первинного ключа.

Для перетворення відношення до 2НФ виконується його декомпозиція за наступними правилами:

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

Для відношення ВИКЛАДАЧ така проекція єдина. Вона включає атрибути: КодВикл, Предм, ВидЗанят. Одержимо нове відношення, що доцільно назвати ЗАНЯТТЯ. Схема залежності між атрибутами приведена на Рис. 4.2.

 

Рис. 4.2. Схема залежності між атрибутами відносини ЗАНЯТТЯ

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

У розглянутому прикладі тільки одна така частина – атрибут
КодВикл. Одержувана проекція є відношенням, яку назвемо ВИКЛАДАЧ. Схема залежності атрибутів отриманого відношення показана на Рис. 4.3.

 

Рис. 4.3. Схема залежностей між атрибутами відношення ВИКЛАДАЧ, отриманого за правилом Б

Отже, у результаті зробленої декомпозиції вихідного відношення ми одержали два нових відношення: ЗАНЯТТЯ і ВИКЛАДАЧ. Неважко бачити, що отримані відношення задовольняють вимогам 2НФ.

Третя нормальна форма (3НФ). Відношення знаходиться в 3НФ, якщо воно знаходиться в 2НФ і кожний його неключовий атрибут нетранзитивно залежить від первинного ключа. У розглянутому прикладі відношення ЗАНЯТТЯ знаходиться в 3НФ. Відношення ВИКЛАДАЧ не задовольняє вимогам 3НФ, тому що атрибут Оклад від первинного ключа залежить транзитивно.

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

Проекція на атрибути Посада і Оклад дає відношення, що назвемо ОКЛАДИ. Схема залежності між атрибутами зображена на Рис. 4.4.

 

Рис. 4.4. Схема залежностей між атрибутами відношення ОКЛАДИ

Проекція на атрибути КодВикл, ПІБ, Каф і Посада дасть відношення ВИКЛАДАЧ. Схема залежності між його атрибутами показана на Рис. 4.5.

Рис. 4.5. Схема залежностей між атрибутами відношення ВИКЛАДАЧ, перетвореного до 3НФ

Отже, у результаті послідовної декомпозиції вихідного відношення ВИКЛАДАЧ (Рис. 4.1) ми одержали наступні три відношення:

ЗАНЯТТЯ (КодВикл, Предмет, ВидЗанят); (Рис. 4.2)

ОКЛАДИ (Посада, Оклад); (Рис. 4.4)

ВИКЛАДАЧ (КодВикл, ПІБ, Каф, Посада). (Рис. 4.5)

Кожне з цих відношень задовольняє вимогам 1, 2 і 3 НФ. У більшості практичних випадків цього досить для виключення аномалій і нормальної роботи БД.

Отримані відношення повинні бути зв'язані між собою. Схема зв'язків зображена на Рис. 4.6.

 

1

Рис. 4.6. Схема зв'язків між відношеннями, отриманими в результаті нормалізації вихідного відношення ВИКЛАДАЧ

4.4. Файлова організація даних

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

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

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

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

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

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