Лекція 6
Проектування реляційної БД
При проектуванні бази даних вирішуються дві основних проблеми:
Яким чином відобразити об'єкти предметної області в абстрактні об'єкти моделі даних, щоб це відображення не суперечило семантиці предметної області і було по можливості кращим (ефективним, зручним і т.д.)? Часто цю проблему називають проблемою логічного проектування баз даних.
Як забезпечити ефективність виконання запитів до бази даних, тобто яким чином, маючи на увазі особливості конкретної СУБД, розташувати дані у зовнішній пам'яті, створення яких додаткових структур (наприклад, індексів) зажадати і т.д.? Цю проблему називають проблемою фізичного проектування баз даних.
У разі реляційних баз даних важко представити які-небудь загальні рецепти по частині фізичного проектування. Тут дуже багато залежить від СУБД, що використовується. Наприклад, при роботі з СУБД Ingres можна вибирати один з способів фізичної організації відносин, що пропонуються, при роботі з System R слід би передусім подумати об кластеризації відносин і необхідному наборі індексів і т.д. Тому ми обмежимося питаннями логічного проектування реляційних баз даних, які істотні при використанні будь-якої реляційної СУБД.
Більш того ми не будемо торкатися дуже важливого аспекту проектування - визначення обмежень цілісності (за винятком обмеження первинного ключа). Справа в тому, що при використанні СУБД з розвиненими механізмами обмежень цілісності (наприклад, SQL-орієнтованих систем) важко запропонувати який-небудь загальний підхід до визначення обмежень цілісності. Ці обмеження можуть мати дуже загальний вигляд, і їх формулювання поки відноситься швидше до області мистецтва, чим інженерної майстерності. Саме більше, що пропонується з цього приводу в літературі, це автоматична перевірка несуперечності набору обмежень цілісності.
Так що будемо вважати, що проблема проектування реляційної бази даних складається в обґрунтованому прийнятті рішень про те,
з яких відносин повинна перебувати БД і
які атрибути повинні бути у цих відносин.
6.1. Проектування реляційних баз даних з використанням нормалізації
Спочатку буде розглянутий класичний підхід, при якому весь процес проектування виготовляється в термінах реляційної моделі даних методом послідовних наближень до задовільного набору схем відносин. Початковою точкою є представлення предметної області у вигляді одного або декількох відносин, і на кожному кроці проектування проводиться деякий набір схем відносин, що володіють кращими властивостями. Процес проектування являє собою процес нормалізації схем відносин, причому кожна наступна нормальна форма володіє властивостями кращими, ніж попередня.
Кожній нормальній формі відповідає деякий певний набір обмежень, і відношення знаходиться в деякій нормальній формі, якщо задовольняє властивому їй набору обмежень. Прикладом набору обмежень є обмеження першої нормальної форми - значення всіх атрибутів відношення атомарні. Оскільки вимога першої нормальної форми є базовою вимогою класичної реляційної моделі даних, ми будемо вважати, що початковий набір відносин вже відповідає цій вимозі.
У теорії реляційних баз даних звичайно виділяється наступна послідовність нормальних форм:
перша нормальна форма (1NF);
друга нормальна форма (2NF);
третя нормальна форма (3NF);
нормальна форма Бойса-Кодда (BCNF);
четверта нормальна форма (4NF);
п'ята нормальна форма, або нормальна форма проекції-з'єднання (5NF або PJ/NF).
Основні властивості нормальних форм:
кожна наступна нормальна форма в деякому розумінні краще попередньої;
при переході до наступної нормальної форми властивості попередніх нормальних властивостей зберігаються.
У основі процесу проектування лежить метод нормалізації, декомпозиція відношення, що знаходиться в попередній нормальній формі, в два або більше за відношення, що задовольняють вимогам наступної нормальної форми.
Найбільш важливі на практикові нормальні форми відносин засновуються на фундаментальному в теорії реляційних баз даних понятті функціональної залежності. Для подальшого викладу нам будуть потрібні декілька визначень.
Визначення 1. Функціональна залежність
У відношенні R атрибут Y функціонально залежить від атрибута X (X і Y можуть бути складовими) в тому і тільки в тому випадку, якщо кожному значенню X відповідає в точності одне значення Y:
Визначення 2. Повна функціональна залежність
Функціональна залежність
Визначення 3. Транзитивна функціональна залежність
Функціональна залежність > R.X. (При відсутності останньої вимоги ми мали б "нецікаву" транзитивну залежність в будь-якому відношенні, що володіє декількома ключами.)
Визначення 4. Неключовий атрибут
Неключовим атрибутом називається будь-який атрибут відношення, що не входить до складу первинного ключа (зокрема, первинного).
Визначення 5. Взаємно незалежні атрибути
Два або більше за атрибут взаємно незалежні, якщо жоден з цих атрибутів не є функціонально залежним від інших.
6.1.1. Друга нормальна форма
Розглянемо наступний приклад схеми відношення:
СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ
(СПІВР_НОМЕР, СПІВР_ЗАРП, ВІД_НОМЕР, ПРО_НОМЕР, СПІВР_ЗАВДАН)
Первинний ключ:
СПІВР_НОМЕР, ПРО_НОМЕР
Функціональна залежність:
СПІВР_НОМЕР -> СПІВР_ЗАРП
СПІВР_НОМЕР -> ВІД_НОМЕР
ВІД_НОМЕР -> СПІВР_ЗАРП
СПІВР_НОМЕР, ПРО_НОМЕР -> СПІВР_ЗАВДАН
Як видно, хоч первинним ключем є складовою атрибут СПІВР_НОМЕР, ПРО_НОМЕР, атрибути СПІВР_ЗАРП і ВІД_НОМЕР функціонально залежать від частини первинного ключа, атрибута СПІВР_НОМЕР. У результаті ми не зможемо вставити у відношення СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ кортеж, що описує співробітника, який ще не виконує ніякого проекту (первинний ключ не може містити невизначене значення). При видаленні кортежу ми не тільки руйнуємо зв'язок даного співробітника з даним проектом, але втрачаємо інформацію про те, що він працює в деякому відділі. При перекладі співробітника в інший відділ ми будемо вимушені модифікувати всі кортежі, що описують цього співробітника, або отримаємо неузгоджений результат. Такі неприємні явища називаються аномаліями схеми відношення. Вони усуваються шляхом нормалізації.
Визначення 6. Друга нормальна форма (в цьому визначенні передбачається, що єдиним ключем відношення є первинний ключ)
Відношення R знаходиться у другій нормальній формі (2NF) в тому і тільки в тому випадку, коли знаходиться в 1NF, і кожний неключовий атрибут повністю залежить від первинного ключа.
Можна зробити наступну декомпозицію відношення СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ в два відношення СПІВРОБІТНИКИ-ВІДДІЛИ і СПІВРОБІТНИКИ-ПРОЕКТИ:
СПІВРОБІТНИКИ-ВІДДІЛИ (СПІВР_НОМЕР, СПІВР_ЗАРП, ВІД_НОМЕР)
Первинний ключ:
СПІВР_НОМЕР
Функціональна залежність:
СПІВР_НОМЕР -> СПІВР_ЗАРП
СПІВР_НОМЕР -> ВІД_НОМЕР
ВІД_НОМЕР -> СПІВР_ЗАРП
СПІВРОБІТНИКИ-ПРОЕКТИ (СПІВР_НОМЕР, ПРО_НОМЕР, СПІВР_ЗАВДАН)
Первинний ключ:
СПІВР_НОМЕР, ПРО_НОМЕР
Функціональна залежність:
СПІВР_НОМЕР, ПРО_НОМЕР -> CПІВР_ЗАВДАН
Кожне з цих двох відносин знаходиться
