asyan.org
добавить свой файл
1


Лекція
Тема: Вступ в реляційну модель даних
Прийнято вважати, що реляційний підхід до організації баз даних був закладений в кінці 1960-х рр. Едгаром Коддом. Переваги реляційного підходу привели до того, що до кінця 80-х років реляційні системи зайняли на світовому ринку СУБД домінуюче положення. В останні десятиліття цей підхід є найбільш поширеним.

Перевагами реляційного підходу прийнято рахувати наступні властивості:

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

  • ці абстракції можуть бути точно та формально визначені;

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

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

Визначати поняття будемо на прикладі відношення СЛУЖБОВЦІ, що містить інформацію про службовців певного підприємства


Мал. 2.1. Співвідношення основних понять реляційного підходу

Тип даних


Значення даних, що зберігаються в реляційній базі даних, є такими, що типізуються, тобто відомий тип кожного значення, що зберігається. Поняття типу даних в реляційній моделі даних повністю відповідає поняттю типу даних в мовах програмування. В сучасних реляційних БД допускається зберігання символьних, числових даних (точних і приблизних), спеціалізованих числових даних (таких, як «гроші»), а також спеціальних «темпоральних» даних (дата, час, часовий інтервал).

У прикладі на мал. 2.1 присутні дані трьох типів: рядки символів, цілі числа і «гроші».

Домен


Поняття домена більш специфічно для баз даних, хоч і є аналогії з підтипами в деяких мовах програмування. У загальному вигляді домен визначається шляхом завдання деякого базового типа даних, до якого відносяться елементи домена. З кожним доменом зв'язується ім'я, унікальне серед імен всіх доменів відповідної бази даних.
Найбільш правильним інтуїтивним трактуванням поняття домена є його сприйняття як допустимої потенційної, обмеженої підмножини значень даного типа. Наприклад, домен ІМЕНА в прикладі визначений на базовому типі символьних рядків, але до числа його значень можуть входити тільки ті рядки, які можуть представляти імена (зокрема, для можливості представлення російських імен такі рядки не можуть починатися з м'якого або твердого знаку і не можуть бути довше, наприклад, 20 символів).

Якщо деякий атрибут відношення визначається на деякому домені (як, наприклад, на мал. 2.1 атрибут СЛУ_ИМЯ визначається на домені ІМЕНА), то надалі обмеження домена грає роль обмеження цілісності, що накладається на значення цього атрибуту.
Слід зазначити також семантичне навантаження поняття домена: дані вважаються порівнянними тільки у тому випадку, коли вони відносяться до одного домена. У нашому прикладі значення доменів НОМЕРА ПРОПУСКІВ і НОМЕРА ВІДДІЛІВ відносяться до типу цілих чисел, але не є порівнянними (допускати їх порівняння було б безглуздо).

Заголовок відношення, кортеж, тіло відношення, значення відношення, змінна відношення


Поняття відношення є найбільш фундаментальним в реляційному підході до організації баз даних. Це відбито і в загальній назві підходу – термін реляційний (relational) походить від relation (відношення). Для уточнення терміну відношення виділяються поняття заголовка відношення, значення відношення і змінної відношення. Крім того, для пояснення потрібно допоміжне поняття кортежу.
Отже, заголовком (або схемою) відношення r (Hr) називається кінцева безліч впорядкованих пар виду , де A називається ім'ям атрибуту, а T позначає ім'я деякого базового типа або раніше певного домена. За визначенням потрібно, щоб всі імена атрибутів в заголовку відношення були різні. У прикладі на мал. 2.1 заголовком відношення СЛУЖБОВЦІ є безліч пар {<слу_номер, номера_пропусков> <слу_имя, имена> <слу_зарп, размеры_выплат> <слу_отд_номер, номера_отделов>}.
Кортежем tr, відповідним заголовку Hr, називається безліч впорядкованих триплетів вигляду . Третій елемент триплета повинен бути допустимим значенням типу даних або домена T. Заголовку відношення СЛУЖБОВЦІ відповідають, наприклад, наступні кортежі: (<слу_номер, номера_пропусков, 2934> <слу_имя, імена, Иванов> <слу_зарп, размеры_выплат, 22.000> і т.д.).
Тілом Br відношення r називається довільна безліч кортежів tr. Одне з можливих тіл відношення СЛУЖБОВЦІ показане на мал. 2.1. Відмітимо, що в загальному випадку, як це демонструють, зокрема, мал. 2.1, можуть існувати такі кортежі tr, які відповідають Hr, але не входять в Br.
Значенням Vr відношення r називається пара безлічі Hr і Br. Одне з допустимих значень відношення СЛУЖБОВЦІ показане на мал. 2.1.
У мінливій реляційній базі даних зберігаються відношеньи, значення яких змінюються в часі. Змінною VARr називається іменований контейнер, який може містити будь-яке допустиме значення Vr. Природно, що при визначенні будь-якої VARr потрібно указувати відповідний заголовок відношення Hr.
Тут варто підкреслити, що будь-яка прийнята на практиці операція оновлення бази даних – INSERT (вставка кортежу в змінну відношення), DELETE (видалення кортежу із значення-відношення змінної відношення) і UPDATE (модифікація кортежу, значення-відношення, змінної відношення) – з модельної точки зору є операцією привласнення змінної відношення деякого нового значення-відношення.

Відмітимо, що надалі в тих випадках, коли точний сенс терміну зрозумілий з контексту, можна використовувати термін відношення як в сенсі значення відношення, так і в сенсі змінна відношення.
За визначенням, ступенем, або «арностью» є потужність заголовка відношення. Наприклад, ступінь відношення СЛУЖБОВЦІ рівний чотирьом, тобто воно є 4-арным (кватернарним).

Інтуїтивна інтерпретація реляційних понять


Звичайним життєвим представленням відношення є таблиця, заголовком якої є схема відношення, а рядками – кортежі відношення-екземпляра; в цьому випадку імена атрибутів відповідають іменам стовпців даної таблиці. Тому іноді говорять про «стовпці таблиці», маючи на увазі «атрибути відношення».

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

Фундаментальні властивості відношень


Зупинимося тепер на деяких важливих властивостях відношень:

1) Відсутність кортежів-дублікатів, первинний і можливі ключі відношень

Та властивість, що тіло будь-якого відношення ніколи не містить кортежів-дублікатів, виходить з визначення тіла відношення як безліч кортежів. У класичній теорії множин за визначенням будь-яка множина складається з різних елементів.

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

Поняття первинного ключа є виключно важливим у зв'язку з поняттям цілісності баз даних. На практиці первинні (і можливі) ключі змінних відношень з'являються в результаті явних вказівок проектувальника відношення. Визначаючи змінну відношення, проектувальник моделює частину наочної області, дані з якої міститиме база даних. І звичайно, проектувальник повинен знати природу цих даних. Наприклад, йому повинно бути відомо, що ніякі два службовців ні в який момент часу не можуть мати посвідчення з одним і тим же номером. Тому він може (і навіть повинен) явно оголосити {СЛУ_НОМЕР} можливим ключем. Якщо на підприємстві встановлено, що у всіх службовців повинні бути різні повні імена, то проектувальник може (і знову ж таки повинен) оголосити можливим ключем і {СЛУ_ИМЯ}. Потім проектувальник повинен оцінити, який з можливих ключів є надійнішим (властивість його унікальності ніколи не буде скасовано) і вибрати найбільш надійний можливий ключ як первинного (у нашому випадку природним вибором був би ключ {СЛУ_НОМЕР}, тому що рішення про унікальність повних імен службовців виглядає штучним і може бути легко скасовано керівництвом підприємства).
Тепер пояснимо, чому проектувальнику слід явно оголошувати первинний і можливі ключі змінних відношень. Річ у тому, що в результаті цього оголошення СУБД одержує інформацію, яка надалі використовуватиметься як обмеження цілісності. СУБД ніколи не допустить появи в змінній відношення значення-відношення, що містить два кортежі з однаковим значенням атрибуту. Тим самим оголошення первинного і можливих ключів дають СУБД можливість підтримувати цілісність бази даних навіть у разі спроб занесення в неї некоректних даних.
Нарешті, повернемося до властивості мінімальності первинного і можливих ключів. Як наголошувалося вище, ця властивість є критично важливою, і важливість виявляється саме при трактуванні первинного і можливих ключів як обмежень цілісності. У нашому прикладі з відношенням СЛУЖБОВЦІ властивістю унікальності володітиме не тільки безліч атрибутів { СЛУ_НОМЕР}, але і, наприклад, множина { СЛУ_НОМЕР, СЛУ_ОТД_НОМЕР}. Але якби ми виставили як обмеження цілісності вимогу унікальності { СЛУ_НОМЕР, СЛУ_ОТД_НОМЕР}, то СУБД гарантувала б відсутність кортежів з однаковим значенням атрибуту СЛУ_НОМЕР не у всьому значенні відношення СЛУЖБОВЦІ, а тільки в групах кортежів з одним і тим же значенням атрибуту СЛУ_ОТД_НОМЕР. Зрозуміло, що це не відповідає сенсу модельованої наочної області.

2) Відсутність впорядкованості кортежів


Звичайно, формально властивість відсутності впорядкованості кортежів в значенні відношення також є слідством визначення тіла відношення як безліч кортежів. Проте на цю властивість можна поглянути і з іншого боку. Достатньо часто у користувачів реляційних СУБД і розробників інформаційних систем викликає роздратування той факт, що вони не можуть зберігати кортежі відношення на фізичному рівні в потрібному їм порядку. Можна було б розробити іншу теорію, в якій допускалися б впорядковані «відношеньи». Проте зберігати впорядковані списки кортежів в умовах інтенсивно оновлюваної бази даних набагато складніше технічно, а підтримка впорядкованості спричиняє за собою істотні накладні витрати.

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

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

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

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

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

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


Хоча поняття реляційної моделі даних першим ввів основоположник реляційного підходу Едгар Кодд, найбільш поширене трактування реляційної моделі даних, мабуть, належить відомому популяризатору ідей Кодда Крістоферу Дейту, який відтворює її (з різними уточненнями) практично у всіх своїх книгах. Згідно трактуванню Дейта, реляційна модель складається з трьох частин, що описують різні аспекти реляційного підходу: структурної частини, маніпуляційної частини і цілісної частини.
У структурній частині моделі фіксується, що єдиною родовою структурою даних, використовуваної в реляційних БД, є нормалізовані n-арное відношеньи. Визначаються поняття доменів, атрибутів, кортежів, заголовка, тіла і змінної відношення.
У маніпуляційній частині моделі визначаються два фундаментальні механізми маніпулювання реляційними БД – реляційна алгебра і реляційне числення. Основною функцією маніпуляційної частини реляційної моделі є забезпечення міри реляційності будь-якої конкретної мови реляційних БД: мова називається реляційною, якщо він володіє не меншою виразністю і потужністю, чим реляційна алгебра або реляційне числення.
Цілісність сутності і посилань

Нарешті, в цілісній частині реляційної моделі даних фіксуються дві базові вимоги цілісності, які повинні підтримуватися в будь-якій реляційній СУБД. Перша вимога називається вимогою цілісності сутності (entity integrity). Об'єкту або сутності реального світу в реляційних БД відповідають кортежі відношень. Вимога цілісності сутності повністю звучить таким чином: у будь-якої змінної відношення повинен існувати первинний ключ, і ніяке значення первинного ключа в кортежах значення-відношення змінної відношення не повинне містити невизначених значень. Щоб це формулювання було повністю зрозуміле, потрібно обговорити поняття невизначеного значення (NULL).
Звичайно, теоретично будь-який кортеж, що заноситься у відношення, що зберігається, повинен містити всі характеристики модельованої їм сутності реального світу, які потрібно зберегти в базі даних. Проте на практиці не всі ці характеристики можуть бути відомі до того моменту, коли потрібно зафіксувати сутність в базі даних. Простим прикладом може бути процедура ухвалення на роботу людини, розмір заробітної платні якого ще не визначений.

Едгар Кодд запропонував використовувати в таких випадках невизначені значення. Невизначене значення не належить ніякому типу даних і може бути присутнім серед значень будь-якого атрибуту, визначеного на будь-якому типі даних (якщо це явно не заборонено при визначенні атрибуту). Якщо а – це значення деякого типу даних або NULL, op – будь-яка двомісна «арифметична» операція цього типу даних (наприклад +), а lop – операція порівняння значень цього типа (наприклад =), то за визначенням:
а op NULL = NULL

NULL op а = NULL

а lop NULL = unknown

NULL lop а = unknown

Тут unknown – це третє значення логічного, або булевого, типу, що володіє наступними властивостями:

NOT unknown = unknown

true AND unknown = unknown

true OR unknown = true

false AND unknown = false

false OR unknown = unknown
Друга вимога, яка називається вимогою цілісності по посиланнях (referential integrity), є складнішою. Очевидно, що при дотриманні нормалізованості відношень складна сутність реального світу представляється в реляційній БД у вигляді декількох кортежів декількох відношень. Вимога цілісності по посиланнях, або вимога цілісності зовнішнього ключа, полягає в тому, що для кожного значення зовнішнього ключа, що з'являється в кортежі значення-відношення змінної відношення, що посилається, або в значенні-відношенні змінної відношення, на яку указує посилання, повинен знайтися кортеж з таким же значенням первинного ключа, або значення зовнішнього ключа повинне бути повністю невизначеним (тобто ні на що не указувати).
Обмеження цілісності сутності і по посиланнях повинні підтримуватися СУБД.

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

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