2.5 Реляційна модель бази даних

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

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

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

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

Реляційна база даних – це реалізація реляційної моделі на фізичному рівні.

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

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

Кожна таблиця має свою структуру, яка складається з таких елементів:

1. Опис полів;

2. Ключі;

3. Індекси;

4. Обмеження на значення полів;

5. Обмеження посилочної цілісності між таблицями;

6. Права доступу.

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

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

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

Кожне відношення можна розділити на дві частини – заголовок і тіло. Тіло відношення складається з кортежів.

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

В функціональні залежності можуть входити групи атрибутів.

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

Ключ забезпечує:

1. Однозначну ідентифікацію записів таблиці;

2. Зпобігає повторенню значень ключа;

3. Прискорення виконання записів до БД;

4. Встановлення зв’язків між окремими таблицями БД;

5. Використання обмежень посилочної цілісності.

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

Використання індексу забезпечує:

1. Збільшення швидкості доступу (пошуку) до даних;

2. Сортування записів;

3. Встановлення обмежень посилочної цілісності.

Модель даних – найабстрактніший рівень проектування баз даних. Елементами описання моделі даних є сутності, атрибути, домени та відношення.

У Кренке Дано таке визначення поняття “сутність”: “Сутність– це деякий об'єкт системи, що ідентифікується в робочому середовищі користувача, який має певний набір атрибутів. Атрибутом називають пойменовану характеристику сутності”

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

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

Існує декілька типів зв’язків між сутностями – один до одного, один до багатьох, багато до багатьох.

Зв’язки один до одного зустрічаються досить рідко, в основному, між сутностями надтипів та підтипів.

Зв’язки один до багатьох зустрічаються більш частіше.

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

Участь кожної сутності в певному зв’язку може бути частковою або повною. Якщо існування даної сутності повністю визначається її участю у зв’язку, то така участь буде повною, в іншому випадку – частковою.

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