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

Модель даних - це система позначень для опису даних та операції щодо обробки даних.

Як вже зазначалося, існують такі типи моделей баз даних:

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

• сіткова;

• реляційна;

• об'єктно-орієнтована;

• напівструктурована.

Перші три з перерахованих моделей БД показані на рис. 4.4.

Ієрархічна модель (рис. 4.4, а) визначається двома типами відношень: 1:1 і 1:N і подається у вигляді деревоподібних структур. Перевагою цієї моделі є простота моделювання предметних областей. Але не всі зв'язки можна враху­вати за допомогою ієрархічної моделі, що створює певні труднощі при прог­рамній реалізації. Наприклад, така модель спричиняє складності за наявності так званих симетричних запитів (наприклад, визначення товарів, що постачаються деякими постачальниками, і визначення постачальників деякого товару); при виключенні з дерева вузла, що має підпорядковані вузли і введення нових вузлів у модель; за необхідності відображення відношень "багато - однозначне" і "багато - багатозначне".

Використання сіткової моделі даних дає змогу представлення зв'язків між реальними об'єктами, складніших порівняно з ієрархічною моделлю (рис. 4.4, б). За її допомогою можна моделювати відношення 1:1, 1:N, N:1, N:N. За допомогою сіткової моделі можна подолати ті труднощі, які вини­кають при використанні ієрархічної моделі. Однак, оскільки зв'язки між даними в сітковій моделі вказуються у явному вигляді, то користувач надто близький до фізичного рівня подання даних. Цей недолік утруднює засто­сування сіткових моделей.

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

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

Визначимо поняття реляційної моделі. Нехай є такі дані (див. табл. 4.1).

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

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

Відношення — обмежена підмножина декартового добутку одного або більше доменів (множина об'єктів, таблиця).

Відношення подають у вигляді двовимірної таблиці (в нашому прикладі це вся табл. 4.1).

Схема - реляційна назва та (обмежена) сукупність назв атрибутів у відношенні (формально відповідність назв атрибутів доменам).

Приклад схеми. Для табл. 4.1 схема Постачальники (код постачальника, назва постачальника, назва групи матеріалів...).

Кортеж - компонента залежності "рядок". Кортежі у відношенні "Постачальники": (1, АТ "Фаркомп", фарби, Полтавська обл., 60000.00)

(2.3АТ "Україна", сталь, Донецька обл., 180000.00) тощо.

У реляційній моделі:

• кожен результат є сукупністю значень (один рядок);

• кожен рядок єдиний в своєму роді (дійсно для моделі даних, щодо реалізації-ні);

• немає незаповнених клітинок (дійсно для моделі даних, щодо реалізації-ні);

• стовпці єдині в своєму роді;

• кожен стовпець відповідає конкретному домену;

• дат кожного стовпця належать до одного типу (формату);

• послідовність стовпців несуттєва;

• послідовність рядків несуттєва. Схема в реляційної моделі подається:

• графічно

Постачальники

Код постачальника

Назва постачальника

Назва групи матеріалів

Місцезнаходження постачальника (область України)

Сума поставки матеріалів, грн

• в текстовому вигляді

ПОСТАЧАЛЬНИКИ (код постачальника, назва постачальника,...)

Ключ - атрибут(и), що визначає величину іншого / інших атрибута (тів) в

межах об'єкта.

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

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

Таблиця 4.2 Приклад функціональної залежності

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

У табл. 4.1 суперключем буде "код постачальника".

Потенційний ключ, якщо один або кілька доменів однозначно визначають будь-який кортеж у відношенні.

Потенційним ключем може бути "Назва постачальника", або "Код поста­чальника, назва постачальника".

Первинний ключ — потенційний ключ, який однозначно ідентифікує окремий об'єкт (нульові величини не дозволяються).

Первинним ключем у відношенні "Постачальники" е "Код постачальника" (він же є і суперключем).

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

Зовнішній ключ допускає більше ніж одну залежність у базі даних.

Розглянемо, наприклад, ще одне відношення БАНК (код банку, назва банку, адреса банку). Зв'язкове відношення БАНК - ПОСТАЧАЛЬНИКИ (код банку, код постачальника) буде сполучним між двома відношеннями БАНК і ПОСТАЧАЛЬНИКИ. Ключ "код банку" є первинним у відношенні БАНК, а ключ "Код постачальника" - первинним у відношенні ПОСТАЧАЛЬНИКИ.

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

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

Ключі в реляційній моделі подаються:

• графічно

• у текстовому вигляді

ПОСТАЧАЛЬНИКИ (Код. назва постачальника, місцезнаходження постачальника)

ПОСТАВКА ТОВАРІВ (Код товару, назва товару, код постачальника, сума поставки)

ПОСТАВКА ТОВАРІВ (Код товару, назва товару, код постачальника, сума поставки).

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

У реляційній БД накладається ще одне обмеження - відношення мають бути нормалізовані.

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

Відношення є нормалізованим, якщо всі його елементи скалярні.