03 - Організація баз даних та знань

Тема 5 - Реляційна модель даних

Конспект лекції


Ключові терміни:

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

 Поняття відношення

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

  1. Однорідність подання даних у моделі, що обумовлює простоту сприйняття її конструкцій користувачами БД;
  2. Наявність розвиненої математичної теорії реляційних БД, що обумовлює коректність її застосування.

В основі реляційної моделі даних лежить поняття відношення, яке задається переліком своїх елементів і перерахуванням їх значень. Розглянемо приклад на рис.5.1 На ньому наведений розклад руху автобусів по маршруту "Москва - Черноголовка - Москва". Бачимо певну структуру. Кожен включений у розклад рейс має свій номер, час відправлення й час у дорозі. Розклад може бути представлено таблицею. Заголовки колонок таблиці звуться атрибутами. Перелік їх імен носить назви схеми відношення. Кожен атрибут визначає тип даних, що разом з областю його значень називається доменом. Вся таблиця цілком називається відношенням, а кожен рядок таблиці зветься кортежем відношення. Таким чином, відношення можна представити у вигляді двовимірної таблиці.

 

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

Рисунок 5.1 Розклад руху автобусів як відношення

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

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

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

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

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

Прийнято розрізняти первинні ключі й часткові ключі. Математично первинним ключем відношення є підмножина звуження декартового добутку, що дозволяє однозначно ідентифікувати кортеж. Якщо первинний ключ містить кілька атрибутів, то він називається складеним ключем, у протилежному випадку - атомарним. Частковим ключем називається атрибут складеного ключа, якщо він однозначно визначає сукупність неключових атрибутів відношення. Атрибут кортежу, що є первинним ключем іншого відношення, називається зовнішнім (іноді стороннім) ключем. З визначення відношення випливає наступна важлива властивість реляційної моделі даних: кожне відношення повинне мати первинний ключ. Зазначимо, що ключ у контексті моделі ПО БД завжди відображає той або інший ступінь зв'язку між атрибутами сутностей ПО, тобто семантично ключ є засіб моделювання зв'язків у моделі.

ПрикладСховати

Розглянемо речення "Громадянин Іванов проживав у місті Москві 10 років". Можливими атрибутами у відношенні Місце_проживання є прізвище громадянина, назва міста проживання й час проживання. Прізвище громадянина може виступати як первинний ключ цього відношення, тому що особистість однозначно визначає час її проживання в конкретному місті. Таким чином, щодо цього моделюється зв'язок "проживав" між атрибутами "прізвище" й "місто".

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

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

Обмежуючі умови підтримки цілісності.

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

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

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

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

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

 Форма подання відношення

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

ІМ'Я_ВІДНОШЕННЯ (Атрибути первинного ключа, неключові атрибути).

ПрикладСховати

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

ПРОЖИВАЄ (Кл. особистість, Кл. населений_пункт, час)

Опис особистості:

ОСОБИСТІСТЬ (Кл. особистість, ФІО, вік, стать)

Опис населеного пункту:

НАСЕЛЕНИЙ_ПУНКТ (Кл.населений_пункт, географія, населення)

Однак найбільшого поширення одержало подання відношень у вигляді графічних діаграм, наприклад ER-діаграм, про які ми говорили раніш. Перевагами такого подання є наочність діаграм і можливість їх побудови у ряді CASE-засобів проектування БД.

 Операції над реляційними даними

Множина операцій над реляційними даними становлять реляційну алгебру. Кожна операція задіює одну або дві таблиці. Основних операцій вісім, розбитих на дві групи. Розглянемо їх детальніше.

Традиційні операції.

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

Рисунок 5.2 Операція об’єднання відношень

Перетин двох відношень – це відношення, яке містить множину рядків, приналежних одночасно і першому і другому відношенням (рис. 5.3).

Рисунок 5.3 Операція перетину відношень

Різниця двох відношень – це відношення, що містить множину рядків, приналежних першому відношенню (рис. 5.4).

Рисунок 5.4 Операція різниці відношень

Декартовий добуток зображений на рис. 5.5.

Рисунок 5.5 Операція декартового добутку відношень

Спеціальні операції.

Селекція – вибірка по критеріям, що виконується по рядкам.

Проекція – вибірка по колонкам.

Природнє поєднання зображене на рис. 5.6.

Рисунок 5.6 Операція природнього поєднання відношень

Ділення зображене на рис. 5.7.

Рисунок 5.7 Операція ділення відношень

Результатом виконання операції є подання.

 Функціональна залежність в даних

На стадії логічного проектування реляційної БД розробник визначає й вибудовує схеми відношення у рамках деякої ПО, а саме - представляє сутності, групує їх атрибути, виявляє основні зв'язки між сутностями. Так, у самому загальному змісті проектування реляційної БД полягає в обґрунтованому виборі конкретних схем відношення з безлічі різних альтернативних варіантів схем.

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

Тому будь-яке апріорне знання про обмеження ПО, що накладають на взаємозв'язки між даними й значення даних, і знання про їх властивості і взаємини між ними може зіграти певну роль у дотриманні зазначених вище вимог. Формалізація таких апріорних знань про властивості даних ПО БД знайшла своє відображення у концепції функціональної залежності даних, тобто обмежень на можливі взаємозв'язки між даними, які можуть бути поточними значеннями схеми відношень.

Кортежі відношення можуть представляти екземпляри сутності ПО або фіксувати їх взаємозв'язок. Але навіть якщо ці кортежі відповідають схемі відношень й обрані з припустимих доменів, не кожен з них може бути поточним значенням деякого відношення. Наприклад, вік людини рідко буває більше 120 років, або той самий пілот не може одночасно виконувати два різних рейси. Такі обмеження семантики домену практично не впливають на вибір тієї або іншої схеми відношень. Вони являють собою обмеження на типи даних.

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

Приклад. Визначення функціональних залежностейСховати

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

ГРАФІК_ПОЛЬОТІВ (Пілот,      Рейс, Дата_вильоту, Час_вильоту)

                                  Іванов         100            8.07                 10:20

                                  Іванов         102            9.07                 13:30

                                  Ісаєв           90              7.07                 6:00

                                  Ісаєв          103           10.07                 19:30

                                 Петров      100           12.07                 10:20

                                 Фролов       90              8.07                   6:00

                                 Фролов       90             12.07                  6:00

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

Отже: "Час_вильоту" функціонально залежить від {"Рейс"}; "Рейс" функціонально залежить від {"Пілот", "Дата_вильоту", "Час_вильоту"}; "Пілот" функціонально залежний від {"Рейс", "Дата_вильоту"}.

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


© 2015 СумГУ
created with Lectur'EDbeta