Базові поняття реляційної моделі даних, Інтеграція додатків і даних, Бази даних, статті

Загальна характеристика реляційної моделі даних

Основи реляційної моделі даних були вперше викладені у статті Е.Кодда в 1970 р. Ця робота послужила стимулом для великої кількості статей і книг, в яких реляційна модель отримала подальший розвиток. Найбільш поширена трактування реляційної моделі даних належить К.Дейту. Згідно Дейта, реляційна модель складається з трьох частин:


Структурна частина описує, які об’єкти розглядаються реляційною моделлю. Постулюється, що єдиною структурою даних, що використовується в реляційної моделі, є нормалізовані n-арні відносини.

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

Маніпуляційна частина описує два еквівалентних способи маніпулювання реляційними даними – реляційну алгебру і реляційне числення.

У цьому розділі розглядається структурна частина реляційної моделі.


Типи даних

Будь-які дані, які використовуються в програмуванні, мають свої типи даних.

Важливо! Реляційна модель вимагає, щоб типи використовуваних даних були простими.

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



Прості типи даних

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


Різні мови програмування можуть розширювати і уточнювати цей список, додаючи такі типи як:


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


Структуровані типи даних

Структуровані типи даних призначені для завдання складних структур даних. Структуровані типи даних конструюються із складових елементів, званих компонентами, які, в свою чергу, можуть мати структурою. В Як структурованих типів даних можна навести такі типи даних:


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

зване безліччю індексів. Відображення

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

Запис (або структура) є кортеж з деякого декартового твору множин. Дійсно, запис є іменований упорядкований набір елементів , Кожен з яких належить типу . Таким чином, запис є елемент безлічі . Оголошуючи нові типи записів на основі вже наявних типів, користувач може конструювати скільки завгодно складні типи даних.

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

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

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


Посилальні типи даних

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


Типи даних, що використовуються в реляційної моделі

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

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

Саме так в деяких пост-реляційних СУБД реалізована робота зі як завгодно складними типами даних, створюваних користувачами.


Домени

В реляційній моделі даних з поняттям тип даних тісно пов’язане поняття домена, яке можна вважати уточненням типу даних.

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


Наприклад, домен , Що має сенс “вік співробітника” можна описати як таке підмножина безлічі натуральних чисел:

Якщо тип даних можна вважати безліччю всіх можливих значень даного типу, то домен нагадує підмножину в цій множині.

Відмінність домена від поняття підмножини полягає саме в тому, що домен відображає семантику, визначену предметною областю. Може бути декілька доменів, співпадаючих як підмножини, але несучі різний сенс. Наприклад, домени “Вага деталі” і “Наявне кількість” можна однаково описати як безліч невід’ємних цілих чисел, але зміст цих доменів буде різним, і це будуть різні домени.

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

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

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

Зауваження. Не завжди очевидно, як задати логічне умова, що обмежує можливі значення домена. Я буду вдячний тому, хто приведе мені умову на рядковий тип даних, що задає домен “Прізвище співробітника”. Ясно, що рядки, які є прізвищами не повинні починатися з цифр, службових символів, з м’якого знака і т.д. Але ось чи є припустимою прізвище “Ггггггиииии”? Чому б ні? Очевидно, ні! А може хтось на зло так себе назве. Труднощі такого роду виникають тому, що сенс реальних явищ далеко не завжди можна формально описати. Просто ми, як усі люди, інтуїтивно розуміємо, що таке прізвище, але ніхто не може дати таке формальне визначення, яке відрізняло б прізвища від рядків, прізвищами не є. Вихід з цієї ситуації простий – покластися на розум співробітника, що вводить прізвища в комп’ютер.


Відносини, атрибути, кортежі відносини


Визначення і приклади

Фундаментальним поняттям реляційної моделі даних є поняття відносини. У визначенні поняття відносини будемо слідувати книзі К. Дейта.

Визначення 1. Атрибут відносини є пара виду <Імя_атрібута: ім'я_домену>.
Імена атрибутів повинні бути унікальні в межах відносини. Часто імена атрибутів відносини збігаються з іменами відповідних доменів.

Визначення 2. Ставлення , Визначене на безлічі доменів (Не обов’язково різних), містить дві частини: заголовок і тіло.
Заголовок відносини містить фіксовану кількість атрибутів відносини:

Тіло відносини містить безліч кортежів відносини. Кожен кортеж відносини являє собою безліч пар виду <Імя_атрібута: Значеніе_атрібута>:

таких що значення атрибута належить домену

Ставлення зазвичай записується у вигляді:

,

або коротше

,

або просто

.

Число атрибутів щодо називають ступенем (Або -Арністю ) Відносини.
Потужність безлічі кортежів відносини називають потужністю відносини.

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

Висновок 1: Заголовок відносини описує декартовій твір доменів, на якому задано відношення. Заголовок статичний, він не змінюється під час роботи з базою даних. Якщо стосовно змінені, додані або видалені атрибути, то в результаті отримаємо вже інше відношення (нехай навіть з колишнім ім’ям).

Висновок 2: Тіло відносини є набір кортежів, тобто підмножина декартового твори доменів. Таким чином, тіло відносини власне і є відношенням в математичному сенсі слова. Тіло відносини може змінюватися під час роботи з базою даних – кортежі можуть змінюватися, додаватися і віддалятися.

Приклад 1. Розглянемо відношення “Співробітники” заданий на доменах “Номер_сотрудніка”, “Прізвище”, “Зарплата”, “Номер_отдела”. Т.к. всі домени різні, то імена атрибутів відносини зручно назвати так само, як і відповідні домени. Заголовок відносини має вигляд:

Працівники (Номер_сотрудніка, Прізвище, Зарплата, Номер_отдела)

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

(1, Іванов, 1000, 1)
(2, Петров, 2000, 2)
(3, Сидоров, 3000, 1)

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























Номер_сотрудніка


Прізвище


Зарплата


Номер_отдела

1 Іванов 1000 1
2 Петров 2000 2
3 Сидоров 3000 1

Таблиця 1 Відношення “Співробітники”

Визначення 3. Реляційної базою даних називається набір відносин.

Визначення 4. Схемою реляційної бази даних називається набір заголовків відносин, що входять в базу даних.

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

Терміни, якими оперує реляційна модель даних, мають відповідні “табличні” синоніми:




































Реляційний термін


Відповідний “табличний” термін

База даних Набір таблиць
Схема бази даних Набір заголовків таблиць
Ставлення Таблиця
Заголовок відносини Заголовок таблиці
Тіло відносини Тіло таблиці
Атрибут відносини Найменування стовпця таблиці
Кортеж відносини Рядок таблиці
Ступінь (-арность) відносини Кількість стовпців таблиці
Потужність відносини Кількість рядків таблиці
Домени і типи даних Типи дані в комірках таблиці


Властивості відносин

Властивості відносин безпосередньо випливають з наведеного вище визначення ставлення. У цих властивостях в основному і складаються відмінності між відносинами і таблицями.



  1. У відношенні немає однакових кортежів. Дійсно, тіло відношення є безліч кортежів і, як будь-яке безліч, не може містити нерозрізнені елементи (див. поняття множини в гл.1.). Таблиці на відміну від відносин можуть містити однакові рядки.
  2. Кортежі не впорядковані (зверху вниз). Дійсно, незважаючи на те, що ми зобразили відношення “Співробітники” у вигляді таблиці, не можна сказати, що співробітник Іванов “передує” співробітнику Петрову. Причина та ж – тіло відношення є безліч, а безліч не впорядковано. Це друга причина, по якій не можна ототожнити відносини і таблиці – рядки в таблицях впорядковані. Одне і те ж відношення може бути зображено різними таблицями, в яких рядки йдуть в різному порядку.
  3. Атрибути не впорядковані (зліва направо). Т.к. кожен атрибут має унікальне ім’я в межах відносини, то порядок атрибутів не має значення. Це властивість дещо відрізняє відношення від математичного визначення ставлення (див. гл.1 – компоненти кортежів там впорядковані). Це також третя причина, по якій не можна ототожнити відносини і таблиці – стовпці в таблиці впорядковані. Одне і те ж відношення може бути зображено різними таблицями, в яких стовпці йдуть в різному порядку.
  4. Всі значення атрибутів атомарний. Це випливає з того, що лежать в їх основі атрибути мають атомарні значення. Це четверте відміну відносин від таблиць – в осередки таблиць можна помістити що завгодно – масиви, структури, і навіть інші таблиці.

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

Зауваження. Кожне відношення можна вважати класом еквівалентності таблиць, Для яких виконуються наступні умови:


Всі такі таблиці є різні зображення одного і того ж відносини.


Перша нормальна форма

Найважче дати визначення речей, які всім зрозумілі. Якщо давати не строге, описове визначення, то завжди залишається можливість неправильної його трактування. Якщо дати строге формальне визначення, то воно, як правило, або тривіально, або занадто громіздко. Саме така ситуація з визначенням відносини в Першою Нормальною Формі (1НФ). Зовсім не говорити про це не можна, тому що на основі 1НФ будуються більш високі нормальні форми, які розглядаються далі в гл. 6 і 7. Дати визначення 1НФ складно зважаючи на його тривіальності. Тому, дамо просто кілька пояснень.

Пояснення 1. Кажуть, що ставлення знаходиться в 1НФ, якщо воно задовольняє визначенню 2.

Це, власне, тавтологія, адже з визначення 2 слідує, що інших стосунків не буває. Дійсно, визначення 2 описує, що є відношенням, а що – ні, отже, відносин в непервой нормальній формі просто немає.

Пояснення 2. Кажуть, що ставлення знаходиться в 1НФ, якщо його атрибути містять тільки скалярні (атомарні) значення.

Знову ж таки, визначення 2 спирається на поняття домену, а домени визначені на простих типах даних.

Непервую нормальну форму можна одержати, якщо допустити, що атрибути відносини можуть бути визначені на складних типах даних – масивах, структурах, або навіть на інших відносинах. Легко собі уявити таблицю, у якій в деяких осередках містяться масиви, в інших осередках – певні користувачами складні структури, а в третіх комірках – цілі реляційні таблиці, які в свою чергу можуть містити такі ж складні об’єкти. Саме такі можливості надаються деякими сучасними пост-реляційними і об’єктними СУБД.

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

Таким чином з’являється третє пояснення Першої Нормальної Форми:

Пояснення 3. Ставлення знаходиться в 1НФ, якщо воно є плоскою таблицею.

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


Висновки

Реляційна модель даних складається з трьох частин:


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

Домени – Це типи даних, які мають певний сенс (семантику). Домени обмежують порівняння – некоректно, хоча і можливо, порівнювати значення з різних доменів.

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

Ставлення має такі властивості:


Реляційної базою даних називається набір відносин.

Схемою реляційної бази даних називається набір заголовків відносин, що входять в базу даних.

Відношення знаходиться в Першою Нормальною Формі (1НФ), Якщо воно містить тільки скалярні (атомарні) значення.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*