- •1.Поняття машинної інформаційної бази.
- •2.Основи організації автоматизованого банку даних.
- •3.Реляційна модель даних.
- •4.Машинна інформаційна база обліку. Особливості розміщення інформації на машинних носіях.
- •5.Організація баз і банків даних автоматизованої інформаційної системи. Ресурси баз даних
- •Контрольні запитання
3.Реляційна модель даних.
Модель даних – це система позначень для опису даних та операції щодо обробки даних.
Як вже зазначалося, існують такі типи моделей баз даних:
·ієрархічна;
·сіткова;
·реляційна;
·об’єктно-орієнтована;
·напівструктурована.
Перші три з перерахованих моделей БД показані на рис. 4.
Ієрархічна модель (рис. 4, а) визначається двома типами відношень: 1:1 і 1:N і подається у вигляді деревоподібних структур. Перевагою цієї моделі є простота моделювання предметних областей. Але не всі зв’язки можна врахувати за допомогою ієрархічної моделі, що створює певні труднощі при програмній реалізації. Наприклад, така модель спричиняє складності за наявності так званих симетричних запитів (наприклад, визначення товарів, що постачаються деякими постачальниками, і визначення постачальників деякого товару); при виключенні з дерева вузла, що має підпорядковані вузли і введення нових вузлів у модель; за необхідності відображення відношень “багато – однозначне” і “багато – багатозначне”.
Використання сіткової моделі даних дає змогу представлення зв’язків між реальними об’єктами, складніших порівняно з ієрархічною моделлю (рис. 4, б). За її допомогою можна моделювати відношення 1:1, 1:N, N:1, N:N. За допомогою сіткової моделі можна подолати ті труднощі, які виникають при використанні ієрархічної моделі. Однак, оскільки зв’язки між даними в сітковій моделі вказуються у явному вигляді, то користувач надто близький до фізичного рівня подання даних. Цей недолік утруднює застосування сіткових моделей.
Реляційні моделі (рис. 4, в) є спробою уникнути складності реальних ієрархічних і сіткових БД на основі теоретико-множинної інтерпретації структури даних. Поняття суті і відношення в моделі не розділяються, а розглядаються разом.
На сучасному ринку програмних продуктів найпоширенішими є реляційні СКБД. Тому розглянемо їх детальніше.
Визначимо поняття реляційної моделі. Нехай є такі дані (див. табл. 1).
Доменами табл.1 є код постачальника, назва постачальника, назва групи матеріалів, місцезнаходження постачальника, сума поставки матеріалів.
Відношення – обмежена підмножина декартового добутку одного або більше доменів (множина об’єктів, таблиця).
Відношення подають у вигляді двовимірної таблиці (в нашому прикладі це вся табл.1).
Схема – реляційна назва та (обмежена) сукупність назв атрибутів у відношенні (формально відповідність назв атрибутів доменам).
Приклад схеми. Для табл. 4.1 схема Постачальники (код постачальника, назва постачальника, назва групи матеріалів…).
Кортеж – компоненти залежності “рядок”. Кортежі у відношенні “Постачальники”: (1, АТ “Фаркомп”, фарби, Полтавська обл., 60000.00) (2,ЗАТ “Україна”, сталь, Донецька обл., 180000.00) тощо.
Рис. 4. Моделі бази даних: а) – ієрархічна; б) – сіткова; в) – реляційна.
Таблиця 4.1Дані для формування БД “Постачальники”
Код постач. |
Назва постачальника |
Назва групи матеріалів |
Місцезнах. постачальника (область України) |
Сума поставки матеріалів,грн |
1 |
АТ “Фаркомп” |
Фарби |
Полтавська обл. |
60000.00 |
2 |
ЗАТ “Україна” |
Сталь |
Донецька обл. |
18000.00 |
3 |
АТ “Львівфарба” |
Фарби |
Львівська обл. |
120000.00 |
4 |
ЗАТ “Комерсант” |
Ліс-кругляк |
Івано-Франківська обл. |
400000.00 |
5 |
АТ “Хімреактив” |
Фарби |
Черкаська обл. |
30000.00 |
6 |
ЗАТ “Карпатліс” |
Дошки обрізні |
Закарпатська обл. |
250000.00 |
Домен – набір дозволених значень для певного атрибуту (наприклад, тип даних, “стовпець”).
У реляційній моделі:
· кожен результат є сукупністю значень (один рядок);
· кожен рядок єдиний в своєму роді (дійсно для моделі даних, щодо реалізації – ні);
· немає незаповнених клітинок (дійсно для моделі даних, щодо реалізації – ні);
· стовпці єдині в своєму роді;
· кожен стовпець відповідає конкретному домену;
· дані кожного стовпця належать до одного типу (формату);
· послідовність стовпців несуттєва;
· послідовність рядків несуттєва.
Схема в реляційній моделі подається:
· графічно
Постачальники
Код постачальника |
Назва постачальника |
Назва групи матеріалів |
Місцезнаходження постачальника (область України) |
Сума поставки матеріалів, грн |
· в текстовому вигляді ПОСТАЧАЛЬНИКИ(код постачальника, назва постачальника,…) Ключ – атрибут(и), що визначає величину іншого / інших атрибута (тів) в межах об’єкта.
Ключ з багатьма атрибутами відомий як складний ключ.
Атрибут А визначає атрибут В, якщо кортежі, які відповідають за величиною А, також відповідають В.
Атрибут В функціонально залежний від А, якщо А визначає В.
Атрибут, що є частиною ключа, відомий як ключовий атрибут.
Приклад функціональної залежності наведений в табл. 2.
Таблиця 2
Приклад функціональної залежності
Прізвище, ім’я, по батькові |
Дата народження |
Астролог |
Китайський зодіак |
||
день |
місяць |
рік |
|||
Міловська Тетяна Іванівна |
22 |
травня |
1969 |
Близнюки |
Півень |
Міловський Ігор Іванович |
10 |
жовтня |
1976 |
Терези |
Дракон |
Суперключ – атрибут (або сукупність атрибутів), що визначає лише рядок в таблиці.
У табл. 1 суперключем буде “код постачальника”.
Потенційний ключ, якщо один або кілька доменів однозначно визначають будь-який кортеж у відношенні.
Потенційним ключем може бути “Назва постачальника”, або “Код постачальника, назва постачальника”.
Первинний ключ – потенційний ключ, який однозначно ідентифікує окремий об’єкт (нульові величини не дозволяються).
Первинним ключем у відношенні “Постачальники” є “Код постачальника” (він же є і суперключем).
Зовнішній (вторинний) ключ – атрибут (або сукупність атрибутів), який має відповідати первинному ключу в деякій іншій таблиці або дорівнює нулю (цілісність на рівні посилань).
Зовнішній ключ допускає більше ніж одну залежність у базі даних.
Розглянемо, наприклад, ще одне відношення БАНК (код банку, назва банку, адреса банку). Зв’язкове відношення БАНК – ПОСТАЧАЛЬНИКИ (код банку, код постачальника) буде сполучним між двома відношеннями БАНК і ПОСТАЧАЛЬНИКИ. Ключ “код банку” є первинним у відношенні БАНК, а ключ “Код постачальника” – первинним у відношенні ПОСТАЧАЛЬНИКИ. Тому у зв’язковому відношенні БАНК – ПОСТАЧАЛЬНИКИ вони є вторинними або зовнішніми. Крім ключів, за якими встановлюють зв’язок у зв’язковому відношенні, можуть бути ще й інші атрибути, які функціонально залежать від цього складового ключа.
Реляційна модель накладає на зовнішні ключі обмеження – посилкову цінність. Остання є відповідністю між об’єктними та зв’язковими відношеннями, яка полягає в тому, що кожному зовнішньому ключеві зв’язкового відношення має відповідати рядок якогось об’єктного відношення. Інакше може статися так, що зовнішній ключ посилається на невідомий для СКБД об’єкт.
Ключі в реляційній моделі подаються:
· графічно
· у текстовому вигляді
РЕЙСИ (Номер, З, ДО, Відправлення, Прибуття)
РЕЙСИ (Номер, З, ДО, Відправлення, Прибуття)
АЕРОПОРТИ (Cкорочення, назва, місто).
До переваг реляційної моделі можна зарахувати простоту у розроблянні мови маніпулювання даних, оскільки пошук даних зводиться до застосування різних операцій над множинами. Недоліком реляційної моделі є те, що вона не охоплює весь діапазон відомих структур даних. Наприклад, в ній відсутній еквівалент ієрархічної організації записів, оскільки при заміні відношення вигляду 1:N на N:N необхідно ввести нове відношення.
У реляційній БД накладається ще одне обмеження – відношення мають бути нормалізовані.
Нормалізація – це процедура, внаслідок якої ліквідуються складні домени (містять інші домени), зв’язані ієрархічним відношенням.
Відношення є нормалізованим, якщо всі його елементи скалярні.