3.7. Поняття "ключ бази даних"

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

Зв'язок між первинними і зовнішніми ключами сутностей ілюструється на рис. 9 та рис. 10, де для позначення довільної асоційованої сутності (стрижнів, характеристик, позначень або навіть асоціацій) використовується новий термін ціль або цільова сутність.

Рис. 9. Структура асоціації

Рис. 10. Структура позначення (характеристики)

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

4. Даталогічні моделі даних

Основа для створення будь-якої БД — інфологічна модель даних, що є множиною структур даних, обмежень цілісності й операцій маніпулювання даними. Така модель відображає реальний світ у деякій зрозумілій людині концепції, цілком незалежній від параметрів середовища збереження даних. Інфологічна модель повинна бути відображена в комп'ютерно-орієнтовану даталогічну модель, "зрозумілу" СУБД. У процесі розвитку теорії і практичного використання баз даних, а також засобів обчислювальної техніки, створювалися СУБД, що підтримують різноманітні даталогічні моделі. На сучасному етапі розвитку найбільше застосовують такі даталогічні моделі даних:

• ієрархічна;

• мережева;

• реляційна.

4.1. Ієрархічна модель

Часто об'єкти перебувають у відношеннях, що прийнято називати ієрархічними, наприклад:

• відношення "частина — ціле" (наприклад, автомобіль складається з кузова, двигуна, коліс і т. д.);

• відношення роду або виду (наприклад, автомобілі бувають вантажні, легкові тощо);

• відношення підпорядкованості (наприклад, ректор — декан та багато інших).

Об'єкти, пов'язані ієрархічними відношеннями, утворюють дерево — орієнтований граф, у якого є тільки одна вершина, не підпорядкована ніякій іншій вершині (цю вершину прийнято називати коренем дерева); будь-яка інша вершина графа підпорядкована тільки одній іншій вершині.

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

Приклад ієрархічної концептуальної схеми приведений на рис. 11. Прямокутниками на цій схемі зображені типи записів (ФАКУЛЬТЕТ, КАФЕДРА, ГРУПА, ІСПИТ). Атрибути записані всередині відповідних прямокутників, ключові атрибути підкреслені.

У ієрархічній моделі ключ для нижніх рівнів ієрархії завжди складений. Він складається з ключа цього запису і ключів записів, що за ієрархією стоять вище за цей ключ. Наприклад, повний ключ запису типу ІСПИТ складається з атрибутів ШИФР ФАКУЛЬТЕТУ, НОМЕР ГРУПИ і НАЙМЕНУВАННЯ ПРЕДМЕТА.

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

Рис. 11. Ієрархічна схема інформаційної моделі університету

4.2. Мережева модель

У мережевій моделі даних поняття головного і підпорядкованих об'єктів дещо розширені. Будь-який об'єкт може бути і головним, і підпорядкованим (у мережевій моделі головний об'єкт позначається терміном власник набору, а підпорядкований — терміном член набору). Один і той самий об'єкт може одночасно виступати й у ролі власника, і в ролі члена набору. Це означає, що кожний об'єкт може брати участь у будь-якому числі взаємозв'язків. Схема мережевої моделі наведена на рис. 12.

Рис. 12. Схема мережевої моделі даних

4.3. Реляційна модель

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

Рис. 13. Схема реляційної моделі даних

Наприкінці 1960-х років з'явилися праці, у яких обговорювалися можливості застосування різноманітних табличних даталогічних моделей даних, тобто можливості використання звичних і природних засобів представлення даних. Найбільш значною з них була стаття співробітника фірми IBM Е. Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13:6, June 1970), у якій, мабуть, уперше був застосований термін "реляційна модель даних". Як математик за освітою, Е. Кодд запропонував використовувати для обробки даних апарат теорії множин (об'єднання, перетин, різниця, декартів добуток). Він показав, що будь-яке представлення даних зводиться до сукупності двовимірних таблиць особливого вигляду, відомого в математиці як відношення — relation (англ.).

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

Створено мови маніпулювання даними, що дозволяють реалізувати всі операції реляційної алгебри і практично будь-які їх сполучення. Серед таких мов найпоширенішими є SQL (Structured Query Language — структурована мова запитів) і QBE (Querye-By-Example — запити за зразком). Обидві належать до мов високого рівня, за допомогою яких користувач вказує, які дані необхідно одержати, не уточнюючи процедуру їх одержання. За допомогою одного запиту на будь-якій з цих мов можна з'єднати декілька таблиць у тимчасову таблицю і вирізати з неї необхідні рядки та стовпці (селекція і проекція).

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

1. Кожна таблиця складається з однотипних рядків і має унікальне ім'я.

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

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

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

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

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

Завдяки своїй простоті й природності подання реляційна модель набула найбільшого поширення в СУБД для персональних комп'ютерів.

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

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

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

• хоча весь процес проектування відбувається на основі врахування залежностей, реляційна модель не надає будь-яких засобів для представлення цих залежностей;

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

4.4. Алгоритм одержання реляційної схеми з ER-схеми

1. Представити кожний стрижень (незалежну сутність) таблицею бази даних (базовою таблицею) і специфікувати первинний ключ цієї базової таблиці.

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

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

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

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

6. Для виключення ненавмисних порушень виконується процедура нормалізації, яка ґрунтується на тому, що єдиними функціональними залежностями в будь-якій таблиці мають бути залежності вигляду KF, де К — первинний ключ, a F — деяке інше поле. Зауважимо, що це випливає з визначення первинного ключа таблиці, відповідно до якого KF завжди має місце для всіх полів такої таблиці. "Один факт в однім місці" говорить про те, що не мають сили ніякі інші функціональні залежності. Мета нормалізації полягає саме в тому, щоб позбутися всіх "інших" функціональних залежностей, тобто таких, що мають інший вигляд, ніж KF.

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

8. Вказати умови цілісності бази даних і дати (якщо це необхідно), стислий опис отриманих таблиць і їхніх полів.