Модель сутність-зв’язок

Модель вперше запропонована Ченом (1976). Потім піддавалась змінам. Для скорочення будемо використовувати термін ER – моделювання (Entity-Relation в перекладі з англійської означає Сутність-Зв’язок).

ER – модель складається з трьох основних елементів:

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

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

Атрибути. Вони описують сутність. Зображуються овалами з назвами атрибутів всередині. Атрибути можуть бути однозначними і багатозначними (наприклад, коли клієнт має кілька адрес). Багатозначні атрибути обводяться подвійним овалом.

Ключовий атрибут – та частина сутності, яка унікальним чином ідентифікує її. Це атрибут, який однозначно вказує на конкретний примірник сутності. Ключові атрибути виділяються підкресленням. Ключі не обов’язково повинні бути простими (складатись з одного атрибута). Іноді доводиться утворювати складний ключ, комбінуючи кілька простих атрибутів. Складний ключ може складатись з усіх атрибутів сутності (у цьому випадку його називають суперключем).

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

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

Однак етап логічного або даталогічного проектування не закінчується проектуванням схеми відношень. У загальному випадку у результаті виконання цього етапу повинні бути отримані наступні результативні документи:

1. Опис концептуальної схеми БД у визначеннях обраної СУБД.

2. Опис зовнішніх моделей у визначеннях обраної СУБД.

3. Опис декларативних правил підтримки цілісності бази даних.

4. Розробка процедур підтримки семантичної цілісності бази даних.

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

Коректною назвемо схему БД, в якій відсутні небажані залежності між атрибутами відношень.

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

- шляхом декомпозиції (розбиття), коли первинна множина відношень, які входять у схему БД, міняється іншою множиною відношень (кількість їх при цьому збільшується), які є проекціями первинних відношень;

- шляхом синтезу, тобто шляхом компонування з заданих первинних елементарних залежностей між об’єктами предметної області схеми БД.

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

Склад атрибутів відношень БД повинен задовольняти двом основним вимогам:

- між атрибутами не повинно бути небажаних ФЗ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функціональні залежності. Нехай Х та У – два атрибути деякого відношення. Кажуть, що У функціонально залежить від Х, якщо у будь-який момент часу кожному значенню Х відповідає не більше ніж одне значення атрибуту У. Функціональну залежність можна позначити так: Х ® У (читається: атрибут "ігрек" функціонально залежить від атрибуту "ікс").

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

1. Табельний номер функціонально залежить від ПІБ, і одночасно ПІБ функціонально залежить від табельного номеру:

ТАБЕЛЬНИЙ НОМЕР ↔ ПІБ

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

2. Номер кімнати функціонально залежить від ПІБ, якщо співробітник має робоче місце тільки у одній кімнаті:

ПІБ ®НОМЕР КІМНАТИ

3. Якщо в кожній кімнаті встановлений один телефон, то номер телефону функціонально залежить від номера кімнати:

НОМЕР КІМНАТИ ® НОМЕР ТЕЛЕФОНУ

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

Нагадаємо, що ключ відношення називається складним, якщо складається з кількох атрибутів.

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

Для прикладу розглянемо відношення R. Атрибути: ПІБ - батька, ОКЛАД, КІМНАТА, ТЕЛЕФОН не знаходяться в повній функціональній залежності від ключа тому, що вони функціонально залежать від частини ключа – ТАБЕЛЬНОГО НОМЕРА.

Транзитивна залежність. Нехай X, Y, та Z – три атрибути одного відношення. При цьому X Õ Y та Y Õ Z, але зворотна залежність відсутня, тобто Z®Y, або Y ® X. Тоді кажуть, що Z транзитивно залежить від Х. Звернемося до відношення R. В ньому можна побачити приклад транзитивної залежності: ТАБЕЛЬНИЙ НОМЕР®КІМНАТА®ТЕЛЕФОН.

R

Табельний номер батька	Ім'я дитини	Вік	ПІБ - батька	Оклад	Кімната	Телефон
	Олександр		Іванов Л. А.
	Євген		Іванов Л. А.
	Михайло		Іванов Л. А.
	Володя		Тарасов М. Т.
	Євген		Кашкін В. К.
	Володя		Кашкін В. К.

Зберігання у відношенні атрибутів, які знаходяться у транзитивній залежності від ключа, викликає низку незручностей. Розглянемо це на прикладі атрибуту ТЕЛЕФОН у відношенні R.

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

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

Зупинимося на атрибуті ОКЛАД. Чи раціонально зберігати цю інформацію у відношенні R, кожен кортеж якого відповідає дитині працівника? По-перше, тут є дублювання інформації, оскільки у працівника може бути багато дітей і для кожної дитини буде зберігатись інформація про оклад батька. Звідси слідує, що при змінах у окладі необхідно буде редагувати не один, а декілька кортежів відношення. По-друге, виникає проблема з працівниками, у яких немає дітей. Їм не відповідає жоден з кортежів, а значить, БД не може містити даних про таких працівників.

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

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

Для того, щоб відношення привести до 2НФ необхідно:

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

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

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

Для переходу до 3НФ також необхідно побудувати ряд проекцій відношення.

Посилена 3НФ – нормальна форма Бойса-Кодда (НФБК). Відношення знаходиться у НФБК, якщо воно знаходиться у 3НФ та в ньому відсутні залежності ключів від не ключових атрибутів.

Четверта нормальна форма. Відношення знаходиться у 4НФ, якщо воно знаходиться у НФБК та в ньому відсутні незалежні багатозначні залежності, тобто всі незалежні багатозначні залежності виділені (рознесені) у окремі відношення з одним і тим же ключем.

Відношення з багатьма багатозначними залежностями 4НФ може і не усунути надлишковості, а разом з тим і аномалій оновлення. Тоді використовують п’яту НФ.

Приклад багатозначних залежностей:

Дата добавления: 2014-01-07