Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Т4 Організація машинної ІБ.doc
Скачиваний:
4
Добавлен:
06.05.2019
Размер:
250.37 Кб
Скачать

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

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

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

  1. ·ієрархічна;

  2. ·сіткова;

  3. ·реляційна;

  4. ·об’єктно-орієнтована;

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

Перші три з перерахованих моделей БД показані на рис. 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 необхідно ввести нове відношення.

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

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]