Лекція 4. Реляційна модель даних. Означення реляційної структури даних

1.   Історія реляційної моделі даних.

2.   Реляційна структура даних.

 

1. Історія реляційної моделі даних

 

Реляційна  модель  даних  була  запропонована  співробітником IBM  Едгаром  Коддом  у 1970  році  та  побудована  на  понятті відношення (relation). При створенні реляційної моделі висувалися такі завдання:

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

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

–  Розширення  мов  керування  даними  за  рахунок  включення операцій над множинами.

 

Першим з розроблюваних корпорацією IBM у кінці1970-х був проект «System R». Цей проект мав на меті отримати реальні докази практичного  застосування  реляційної  моделі,  шляхом  реалізації передбаченою  нею  структур  даних  та  операцій.  Плодами  проекту стали  висунуті  на  загал  важливі  проблеми  реалізації  реляційної моделі,  такі  як:  керування  транзакціями,  керування  паралельною роботою,  технологія  відновлення,  оптимізація  запитів,  забезпечення безпеки  та  цілісності  даних,  врахування  людського  фактору  та розроблення користувацького інтерфейсу. Робота над проектом стала поштовхом для наступних важливих розробок:

-       Створення мови структурованих запитів SQL (назва читається або по буквах«S-Q-L», або (рідше) за мнемонічним іменем «SeeQuel»). SQL отримала статус формального стандарту ISO та є фактично стандартом мови реляційних СКБД.

-       Створення  різних  комерційних  реляційних  СКБД,  які  вперше з’явилися на ринку в кінці 1970-х – на початку 1980-х років, таких  як DB2 та SQL/DS корпорації IBM,  а  також Oracle корпорації Oracle Corporation.

 

Реляційна  модель  побудована  на  математичному  понятті «відношення», фізичним представленням якої є таблиця.

Рис. 1. Таблиця як основний елемент реляційної бази даних

 

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

 

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

Недоліки: складний опис для ієрархічних та мережевих зв’язків.

Приклади: MySQL, Firebird, InterBase, MS SQL Server, SQLite, DB2, Oracle, Informix, Paradox, FoxPro, MS Access.

 

2.  Реляційна стуктура даних

 

Представлення моделі

Рис. 2. Структура відношень Group та Student

 

Рис. 3. Еквівалентна термінологія реляційної моделі

 

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

Атрибут – це поіменований стовпець відношення (таблиці).

Кортеж – це стрічка відношення(таблиці).

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

 

Рис. 4. Приклад опису доменів

 

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

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

Тіло відношення складається з набору стрічок таблиці.

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

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

Реляційна база даних – це набір нормалізованих відношень, які розрізняються за іменами.

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

 

1.  Потенційні (Candidate Key) – CK:

     а) Первинні (Primary Key) – PK;

     б) Альтернативні (Alternate Key) –  AK  або  Вторинні (Secondary Key) – SK, або Унікальні (Unique Key) – UK.

 

2.  Зовнішні (Foreign Key) – FK.

 

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

Первинний ключ – це особлива форма потенційного ключа. У таблиці може існувати лише один первинний ключ. На відміну від простих (альтернативних) потенційних  ключів,  первинний  ключ  не може  містити null-значення (це  фактично  відсутність  будь-якого значення,  і його не  варто  його  путати  зі  значенням  нуль,  пробілом  чи нульовою стрічкою“”).

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

 

Цілісність значень

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

Приклад:  клієнту  може  бути  не  призначений (ще) торговий агент, однак не можливо призначити клієнту неіснуючого агента.

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

Рис. 5. Структура цілісності посилання

 

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

1. ЗАБОРОНА. Згідно цієї стратегії накладається заборона на усі зміни  потенційного  ключа,  якщо  існують  зовнішні  ключі,  що посилаються на нього. Тобто, видаляти стрічки чи змінювати значення у стовпці ID таблиці 1 (рис. 5) можна лише для тих значень ID, для яких не існує відповідних їм елементів у таблиці 2.

Рис. 6. Ілюстрація стратегії заборони

 

2.  КАСКАДНІ  ЗМІНИ.  Виконання  операцій  над  вихідною стрічкою базової таблиці з потенційним ключем «каскадним» чином розповсюджується на усі стрічки інших таблиць, зовнішні ключі яких посилаються на базову стрічку. Тобто, видалення стрічки з базової таблиці 1 спонукає  видаленню  усіх  стрічок  з  таблиці 2, для  яких значення  зовнішнього  ключа  співпадає  зі  значеннями  потенційного ключа таблиці 1. Зміна ж значення поля ID таблиці 1 генерує зміну відповідного значення поля ID таблиці 2.

Рис. 7. Ілюстрація стратегії виконання каскадних операцій

Рис. 8. Ілюстрація виконання множинного каскадного видалення

 

3. ПРИСВОЄННЯ NULL-ЗНАЧЕНЬ.  У  цьому  випадку,  при видаленні  стрічок  базової  таблиці  чи  зміні  значень  потенційного ключа, відповідні значення зовнішніх ключів замінюються значеннями NULL.

Рис. 9. Ілюстрація стратегії встановлення NULL-значень

 

Модифікацією цієї стратегії є варіант встановлення не NULL-значень, а значень за замовчуванням, які визначені для стовпців зі зовнішнім  ключем.  При  невідповідності  значень  за  замовчуванням потенційному ключу встановлюється NULL-значення.

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

 

Питання для самоперевірки:

 

1. Створення реляційної моделі даних.

2. Таблиця як основний елемент реляційної бази даних.

3. Представлення реляційної моделі даних. Основні поняття.

4. Ключі в реляційній моделі.

5. Опишіть стратегію цілісності посилань.