НОУ ІНТУЇТ | лекція | нормалізація

1. 5.1 Зв'язки і зовнішні ключі
2. 5.2 Типи зв'язку. Ідентифікують і неідентіфіцірующей, обов'язкові і необов'язкові зв'язку

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

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

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

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

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

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

Давайте ще раз згадаємо про зв'язки між відносинами, про з'єднання відносин і про зовнішні ключі.

5.1 Зв'язки і зовнішні ключі

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

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

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

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

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

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

В обох варіантах схеми кожен співробітник зараховується до одного з відділів. маємо зв'язок ( "Ко-многим" на стороні відносини "Співробітник"). Відносно "Співробітник" не можна вибрати номер відділу deptno, неіснуючий в списку відділів (сутність "Відділ"). В одному відділі може бути жодного, один, два і більше співробітників.

Ми відзначили з приводу схожого прикладу (розділ 2.2.7), що утворюється парадоксальна ситуація. Директор зарахований до якогось відділу, а начальник цього відділу і підпорядкований директору та одночасно буде його ж начальником. Але може бути відділи - це центри витрат, і зарплату директора вирішили відносити на витрати одного з відділів. У наших навчальних прикладах не варто займатися такими деталями, якщо, звичайно, не визначено інше. Ви повинні з самого початку звикати в числі іншого думати про стороні бізнесу, але при вирішенні навчальних завдань не слід розширювати завдання до аналізу можливих варіантів.

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

5.2 Типи зв'язку. Ідентифікують і неідентіфіцірующей, обов'язкові і необов'язкові зв'язку

Типи зв'язку ідентифікує і неідентіфіцірующей (див. малюнок 5.1 ) Відноситься не до теорії реляційних баз даних, а до стандарту моделювання IDEF1X, на якому заснований ERwin (він же AllFusion Data Modeller).

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

Неідентіфіцірующей зв'язок використовується для з'єднання двох сильних сутностей. Вона передає ключ в область неключових атрибутів.

Для неидентифицирующей зв'язку можна вказати обов'язковість (всієї зв'язку, а не її кінця). Якщо зв'язок є обов'язковою умовою (в ERwin це завдання ознаки No Nulls), то атрибути зовнішнього ключа отримають ознака NOT NULL, що означає неприпустимість невизначених значень. Для необов'язковою зв'язку (ознака Nulls Allowed) зовнішній ключ може приймати значення NULL.

Після того, як в "Мова SQL" ми познайомимося з мовою SQL, використовуючи прямий інжиніринг, можна буде генерувати скрипт SQL створює фрагмент схеми бази. Але і зараз, якщо ви вже хоча б трохи знайомі з SQL, то, пройшовши шлях Tools> Forward Engineer / Schema Generation, а потім натиснувши кнопку Preview, перегляньте згенерований текст.

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

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