ОБДЗ / Лекции Access / Проектування РБД / 6_проектування_РБД

6ПРОЕКТУВАННЯ РЕЛЯЦІЙНИХ БАЗ ДАНИХ

6.1Універсальна таблиця

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

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

Отримана нами таблиця “Успішність” (табл. 5.7) може бути УТ для проектування такої БД, де буде зберігатися інформація про успішність студентів ВНЗ. Разом з тим у таблицю повинні включатися дані про кількість годин по кожній дисципліні, викладачах, датах іспитів і заліків, тощо. Така розширена таблиця і повинна використовуватися як початкова УТ при проектуванні БД.

Перед цим пояснимо ще одну рекомендацію, що витікає з практики використання РБД. Наприклад, розглянемо два варіанти подання фактичної виплати стипендії за останні роки. Варіант 1 представляє місячні дані про виплати по полях (табл. 6.1), а варіант 2 – по записах (табл. 6.2).

Таблиця 6.1 – Облік виплат (варіант №1)

Таблиця 6.2 – Облік виплат (варіант №2)

39

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

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

Сума1кв=М1+М2+М3;

. . .

Сума4кв=М10+М11+М12 (для вибраних року і студента);

Уваріанті 2 можна скласти лише один запит типу

СумаКв=Σ Кількість (для вибраних року, студента і місяців)

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

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

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

Таблиця 6.3 – Успішність студентів

Цей варіант таблиці “Успішність” можна розглядати як УТ для нашої ПО. Якби ми зробили спробу подати цю таблицю по структурі варіанту 1, то кількість полів наближалась би до безлічі. І при зміні учбового плану будь-якої спеціальності та додаванні хоча б однієї дисципліни нам би довелось кожного разу змінювати структуру таблиці та додавати нові поля.

До речі, поле Код_студента вже не може бути ключем, бо кожний студент може мати багато оцінок.

При проектуванні таблиць доцільно для полів, що зберігають досить довгі текстові значення, використовувати кодування та вводити короткі цифрові або текстові замінники (коди). Це дозволить зменшити об’єм БД. Наприклад, код

40

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

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

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

Розглянемо структуру таблиці Успішність.

Для зручності подальших пояснень розвернемо поля по вертикалі і введемо скорочення для їх імен.

Для наочності при іменуванні таблиць будемо завжди використовувати першу букву “т”. Поля, що складають ключ, будемо позначати знаком (*).

Первинний ключ (складовий):

Код_ст, Рік, Семестр, Код_дисц, Вид_контролю.

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

6.2 Принципи нормалізації

Для проектування БД використовують метод послідовних наближень, названий нормалізацією. У розвиток нормалізації зробили свій внесок Е.Кодд, Бойс, Р.Фагін, І.Хез, К.Дейт, Д.Ульман, В.Амстронг та ін.

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

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

41

до двозначності чи втрати даних;

–корегування таблиць при додаванні нових полів повинно бути мінімальним;

–час обробки даних та маніпуляцій з ними повинний бути мінімальним;

–обсяг БД повинний бути мінімальним.

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

У теорії РБД існує ціла низка НФ. Їхні відносини між собою можна сформулювати так:

–при переході до наступної НФ властивості попередніх НФ зберігаються;

–кожна наступна НФ виключає недоліки та поліпшує властивості попередньої.

Якщо одну НФ показати як круг, то наступна НФ буде показана як круг меншого діаметру, що входить до першого кругу.

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

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

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

Ще раз коротко сформулюємо вимоги до РТ, які витікають з теорії відношень та були пояснені вище:

–у позиції на перетині кожного поля та кожного запису завжди знаходиться єдине атомарне значення;

–відсутні записи, що повторюються;

–відсутні поля, що повторюються;

–записи не упорядковані;

–поля не упорядковані;

–жодне ключове поле в жодному запису не є порожнім.

Ці вимоги є базовими вимогами класичної РБД. Будь-яка таблиця, що задовольняє цим умовам, називається нормалізованою. Ненормалізовані таблиці в РБД не припустимі.

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

Оскільки вимоги 1НФ в тУспішність виконані, то можна вважати, що вона знаходиться в 1НФ.

42

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

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

–аномалія включення; наприклад, не можна вставити в розглянуту таблицю запис, який описує студента, якщо він не отримав жодної оцінки;

–аномалія вилучення; наприклад, при вилученні запису не тільки руйнується зв'язок даного студента з даною дисципліною, а також втрачається інформація про те, що він вчиться в якійсь групі;

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

Ці проблеми усуваються шляхом виконання одного кроку нормалізації та переходу таблиці з 1НФ у 2НФ.

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

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

Нехай у таблиці Т(Р1,...,Рn) є поля X,Y; тобто поля X,Y належать {Р}. Вважають, що в таблиці Т поле Y функціонально залежить від поля X в

тому і тільки тому випадку, якщо кожному значенню X відповідає в точності одне значення Y. Можна говорити також, що в цьому випадку Y функціонально залежить від X, чи X функціонально визначає Y, чи Y ідентифікується полем X. Ці визначення еквівалентні.

Поля X і Y можуть бути складовими полями, тобто реально складатися з декількох полів. При ФЗ в будь-який заданий момент часу для кожного з різних значень набору полів Х обов'язково існує тільки одне з різних значень набору полів Y.

ФЗ позначається як Т.X (r) Т.Y чи Т.X → Т.Y. Далі символ Т будемо пропускати.

Розрізняють повну і транзитивну ФЗ.

ФЗ називається повною, якщо X → Y. При цьому Y не залежить функціонально від будь-якої точної підмножини X. Нагадаємо, що точною підмножиною X називається будь-яка його підмножина, що не збігається з множиною X. Наприклад, якщо Х=(P1,P2,P3), то підмножиною може бути

(P1,P2), (P1,P3) або (P2,P3).

ФЗ називається транзитивною, якщо існує таке поле Y, для якого існує дві ФЗ X → Y, Y → Z. При цьому ФЗ Z → X повинна бути відсутньою, інакше ми отримували б “нецікаві” транзитивні залежності в будь-якій таблиці, що володіє декількома ключами.

ФЗ зручно зображати графічно. На рис. 6.1а показано дві повні ФЗ: X → Y, X → Z, а на рис. 6.1б – транзитивна ФЗ X → Y, Y → Z .

43

1)тСтуденти (*Код_ст, Ін_ст, ПІБ, Код_спец, Група) ФЗ: Код_ст → ПІБ

Код_ст → Ін_ст Код_ст → Код_спец Код_ст → Група

2)тУспішність (*Код_ст, *Рік, *Семестр, *Код_дисц, *Вид_контролю,

Оцінка)

ФЗ: *Код_ст,* Рік, * Семестр, * Код_дисц, * Вид_контролю → Оцінка В отриманих таблицях будь-яке неключове поле однозначно

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

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

Таким чином, процедуру переходу від 1НФ до 2НФ можна сформулювати

так: якщо в таблиці T(*K1,*K2, P) існує ФЗ типу К2→P, то таблиця Т поділяється на дві нові T1(*K1,*K2) та T2(*K2, P).

Додамо, що якщо значення P можна точно розрахувати за значенням К2, то Т2 можна не включати в БД. Для розрахунку значень Р можна використати запити.

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

Таким чином, зробимо важливий висновок: якщо таблиця має простий ключ, то вона автоматично перебуває в 2НФ.

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

Нехай в БД необхідно зберігати інформацію про сутність Об’єкт. Будемо мати таблицю як мінімум з двома полями тОб’єкти (*Код_об’єкту, Об’єкт), де під полем Об’єкт будемо розуміти одне поле або кілька полів для зберігання властивостей представників об’єкту. Наприклад, для зберігання інформації про людей можна створити тЛюди (*Код_людини, Людина). Але необхідно пам’ятати, що для зберігання атрибутів людини необхідно розкривати поле Людина як кілька полів (прізвище, ім'я, по-батькові, стать, дата народження, резюме, фотографія, E-mail, тощо). Розглянемо таблицю тМісця_роботи (Код_місця_роботи, Місце_роботи). Для людини місце роботи зазвичай визначається як підприємство, підрозділ, посада, оклад, ставка. Аналогічно адреса – це поштовий індекс, населений пункт, вулиця, будинок, номер квартири або офісу.

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

45

6.5 Цілісна частина РМД

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

При проектуванні РБД на етапі, коли до БД входять кілька таблиць, треба вказати обмеження цілісності.

У цілісній частині РМД фіксуються дві базових вимоги цілісності, які повинні підтримуватися в будь-який реляційній СУБД:

−цілісність сутностей;

−цілісність за посиланнями.

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

Розглянемо поняття посилання.

Студент отримує оцінки. Сутність Студент – первинна, а Успішність – вторинна. Відповідно тСтуденти – основна (батьківська) таблиця, а тУспішність – дочірня (підпорядкована, зв’язана) таблиця.

Поле Код_ст визначає студента. У тСтуденти це поле – простий ключ, а у тУспішність – частина складового ключа. Таке поле або сукупність полів у дочірній таблиці називають зовнішнім ключом (Foreign Key).

Для кожного студента значення полів Код_ст в обох таблицях однакові. Наприклад, в тСтуденти один запис, в якому Код_ст=1001 (для Андреєва А.А.), а в тУспішність – таких записів декілька. Якщо ми вирішили змінити Код_ст для Андреєва А.А. то ми повинні змінити значення цього поля як в тСтуденти, так і в тУспішність.

У тУспішність не можуть бути записи з оцінками студента, запис про якого не існує у тСтуденти.

Цілісність за посиланнями означає, що значення полів первинного ключа в записах батьківської таблиці та зовнішнього ключа в відповідних (зв’язаних) записах дочірньої таблиці завжди мають однакові значення. У дочірній таблиці не можуть бути записи-“сироти”, для яких не існує відповідних записів у батьківської таблиці.

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

1)при зміні значення ключового поля в існуючих записах батьківської таблиці автоматично змінюються значення поля зовнішнього ключа в відповідних записах дочірньої таблиці;

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

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

46

таблиці.

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

6.6 Діаграми “Таблиці - зв’язки”

Від моменту появи в РБД кількох таблиць логічну модель і схему БД рекомендується зображати у вигляді діаграм. При проектуванні РБД замість загальних ER-діаграм типу “Сутності-зв’язки” рекомендується використовувати діаграми типу “Таблиці-зв’язки”. Ці діаграми краще підходять для подальшої реєстрації проектних рішень і реалізації БД.

В діаграмах типу “Таблиці-зв’язки” таблиці зображують одним стовпцем (прямокутниками). У заголовку прямокутника записують ім’я, іноді вказують тип таблиці як сутності. Іноді назву таблиці вносять у прямокутник. Рекомендується назви таблицям давати в множині та записувати прописними буквами. Як було домовлено вище, ми будемо додавати у назві першу букву

“т”.

Ключі та поля заносять у прямокутник таблиці і записують малими літерами. При цьому поля таблиці, що складають ключ, розташовують поруч, підкреслюють, обводять рамкою або позначають знаком “*”.

Поля, що входять до можливого альтернативного ключа будемо позначати знаком “v”.

Приклад зображення окремих таблиць на діаграмі наведено на рис. 6.3.

Рисунок 6.3 – Об’єкти діаграм “Таблиці – зв’язки”

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

47

Між двома таблицями А (батьківська) та Б (дочірня) можуть існувати два основних варіанти зв’язків:

1)зв'язок один–до–одного (1:1), коли в любий момент часу кожному запису таблиці А може відповідати 1 чи 0 записів таблиці Б;

2)зв'язок один–до–багатьох (1: , або 1:М), коли одному запису таблиці А може відповідати 0, 1 чи більше записів таблиці Б.

Вобох випадках кожному запису таблиці Б відповідає тільки один запис таблиці А.

Існує ще один тип зв’язку – зв'язок багато-до-багатьох ( : , або 1:М), коли одному запису таблиці А може відповідати більше одного запису таблиці Б, а одному запису таблиці Б може відповідати більше одного запису таблиці А.

Місце "стикування" зв'язку з таблицею (кінець лінії зв’язку) позначають відповідним знаком.

Зазвичай для стикування типу “один-до -” (1: ) або “-до - одного” (:1) використовується цифра 1, а для стикування “-до - багатьох” (:М) або “багато- до-” (M:) букви М, N або знак ∞.

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

На рис. 6.4 наведено приклад діаграми БД, яка складається з двох зв’язаних таблиць.

Рисунок 6.4 – Діаграма БД (варіант 1

Розглянемо загальний приклад.

Маємо дві таблиці тТ1 і тТ2, які перебувають у 2НФ. Між ними можливі такі види зв’язків:

1)зв'язок відсутній, таблиці не зв’язані (рис. 6.5а);

2)зв'язок 1:1, таблиці рівноправні (рис. 6.5б);

3)зв'язок 1:М, тТ1 – батьківська, тТ2 – дочірня (рис. 6.5в);

4)зв'язок М:1, тТ1 – дочірня, тТ2 – батьківська (рис. 6.5в).

Використання простих ключів для таблиць спрощує встановлення зв’язків у БД і організацію підтримки цілісності даних. Рекомендую розглянути приклад з таблицями, які мають неіснуючі назви, наприклад, назви нот.

Зв'язок типу N:М буде розглянуто нижче.

48