Велика бібліотека української літератури
Популярные материалы
» » Базові поняття реляційної моделі даних

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

Загальна характеристика реляційної моделі даних
Основи реляційної моделі даних були вперше викладені у статті Е.Кодда в 1970 р. Ця робота послужила стимулом для великої кількості статі і книг, в яких реляційна модель одержала подальший розвиток. Найпоширеніше трактування реляційної моделі даних належить К.Дейту. Згідно Дейту, реляційна модель складається з трьох частин:
Структурної частини.
Цілісної частини.
Маніпуляційної частини.
Структурна частина описує, які об'єкти розглядаються реляційною моделлю. Постуліруєтся, що єдиною структурою даних, що використовується в реляційній моделі, немає нормалізовані n-арные відносини.
Цілісна частина описує обмеження спеціального вигляду, які повинні виконуватися для будь-яких відносин в будь-яких реляційних базах даних. Це цілісність єств і цілісність зовнішніх ключів.
Маніпуляційна частина описує два еквівалентні способи маніпулювання реляційними даними - реляційну алгебру і реляційне числення.
У даному розділі розглядається структурна частина реляційної моделі.
Типи даних
Будь-які дані, що використовуються в програмуванні, мають свої типи даних.
Важливо! Реляційна модель вимагає, щоб типи даних, що використовуються, були простими.
Для уточнення цього твердження розглянемо, які взагалі типи даних звичайно розглядаються в програмуванні. Як правило, типи даних діляться на три групи:
Прості типи даних.
Структуровані типи даних.
Посилальні типи даних.
Прості типи даних
Прості, або атомарні, типи даних не володіють внутрішньою структурою. Дані такого типу називають скалярами. До простих типів даних відносяться наступні типи:
Логічний.
Рядковий.
Чисельний.
Різні мови програмування можуть розширювати і уточнювати цей список, додаючи такі типи як:
Цілий.
Речовинний.
Дата.
Час.
Грошовий.
Що перераховує.
Інтервальний.
І т.д..
Звичайно, поняття атомарності досить відносне. Так, рядковий тип даних можна розглядати як одновимірний масив символів, а цілий тип даних - як набір бітів. Важливе лише те, що при переході на такий низький рівень втрачається семантика (значення) даних. Якщо рядок, що виражає, наприклад, прізвище співробітника, розкласти в масив символів, то при цьому втрачається значення такого рядка як єдиного цілого.
Структуровані типи даних
Структуровані типи даних призначені для завдання складних структур даних. Структуровані типи даних конструюються із становлячих елементів, званих компонентами, які, у свою чергу, можуть володіти структурою. Як структуровані типи даних можна привести наступні типи даних:
Масиви
Записи (Структури)
З математичної точки зору масив є функцією з кінцевою областю визначення. Наприклад, розглянемо кінцеву безліч натуральних чисел
зване множиною індексів. Відображення
з множини у безліч дійсних чисел задає одновимірний речовинний масив. Значення цієї функції для деякого значення індексу називається елементом масиву, відповідним . Аналогічно можна задавати багатовимірні масиви.
Запис (або структура) є кортежем з деякого декартового твору множин. Дійсно, запис є іменованим впорядкованим набором елементів , кожний з яких належить типу . Таким чином, запис є елемент множини . Оголошуючи нові типи записів на основі вже наявних типів, користувач може конструювати скільки завгодно складні типи даних.
Загальним для структурованих типів даних є те, що вони мають внутрішню структуру, що використовується на тому ж рівні абстракції, що і самі типи даних.
Пояснимо це таким чином. При роботі з масивами або записами можна маніпулювати масивом або записом і як з єдиним цілим (створювати, видаляти, копіювати цілі масиви або записи), так і поелементно. Для структурованих типів даних є спеціальні функції - конструктори типів, що дозволяють створювати масиви або записи з елементів більш простих типів.
Працюючи ж з простими типами даних, наприклад з числовими, ми маніпулюємо ними як неподільними цілими об'єктами. Щоб "побачити", що числовий тип даних насправді складний (є набором бітів), потрібно перейти на більш низький рівень абстракції. На рівні програмного коду це виглядатиме як асемблерні вставки в код на мові високого рівня або використовування спеціальних побітних операцій.
Посилальні типи даних
Посилальний тип даних (покажчики) призначений для забезпечення можливості вказівки на інші дані. Покажчики характерні для мов процедурного типу, в яких є поняття області пам'яті для зберігання даних. Посилальний тип даних призначений для обробки складних структур, наприклад дерев, графів, рекурсивних структур, що змінюються.
Типи даних, що використовуються в реляційній моделі
Власне, для реляційної моделі даних тип даних, що використовуються, не важливий. Вимогу, щоб тип даних був простим, потрібно розуміти так, що в реляційних операціях не повинна враховуватися внутрішня структура даних. Звичайно, повинні бути описані дії, які можна проводити з даними як з єдиним цілим, наприклад, дані числового типу можна складати, для рядків можлива операція конкатенації і т.д.
З цієї точки зору, якщо розглядати масив, наприклад, як єдине ціле і не використовувати поелементних операцій, то масив можна вважати простим типом даних. Більш того, можна створити свій, скільки завгодно складних тип даних, описати можливі дії з цим типом даних, і, якщо в операціях не потрібне знання внутрішньої структури даних, то такий тип даних також буде простим з погляду реляційної теорії. Наприклад, можна створити новий тип - комплексні числа як запис вигляду , де . Можна описати функції складання, множення, віднімання і розподіли, і всі дії з компонентами і виконувати тільки усередині цих операцій. Тоді, якщо в діях з цим типом використовувати тільки описані операції, то внутрішня структура не грає ролі, і тип даних ззовні виглядає як атомарний.
Саме так в деяких пост-реляційних СУБД реалізована робота з скільки завгодно складними типами даних, створюваних користувачами.
Домени
У реляційній моделі даних з поняттям тип даних тісно зв'язано поняття домена, яке можна вважати уточненням типу даних.
Домен - це семантичне поняття. Домен можна розглядати як підмножину значень деякого типу даних мають певний сенс. Домен характеризується наступними властивостями:
Домен має унікальне ім'я (в межах бази даних).
Домен визначений на деякому простому типі даних або на іншому домені.
Домен може мати деяку логічну умову, що дозволяє описати підмножину даних, допустимих для даного домена.
Домен несе певне смислове навантаження.
Наприклад, домен , має сенс "вік співробітника" можна описати як наступну підмножину безлічі натуральних чисел:
Якщо тип даних можна рахувати множиною всіх можливих значень даного типу, то домен нагадує підмножину в цій множині.
Відмінність домена від поняття підмножини полягає саме в тому, що домен відображає семантику, визначену наочною областю. Може бути декілька доменів, співпадаючих як підмножини, але несучі різне значення. Наприклад, домени "Вес деталі" і "Наявну кількість" можна однаково описати як безліч ненегативних цілих чисел, але значення цих доменів буде різним, і це будуть різні домени.
Основне значення доменів полягає в тому, що домени обмежують порівняння. Некоректно, з логічної точки зору, порівнювати значення з різних доменів, навіть якщо вони мають однаковий тип. В цьому виявляється смислове обмеження доменів. Синтаксично правильний запит "видати список всіх деталей, біля яких вага деталі більше наявної кількості" не відповідає значенню понять "кількість" і "вага".
Зауваження. Поняття домена допомагає правильно моделювати наочну область. При роботі з реальною системою у принципі можлива ситуація коли вимагається відповісти на запит, приведений вище. Система дасть відповідь, але, ймовірно, він буде безглуздим.
Зауваження. Не всі домени володіють логічною умовою, що обмежує можливі значення домена. У такому разі безліч можливих значень домена співпадає з безліччю можливих значень типу даних.
Зауваження. Не завжди очевидно, як задати логічну умову, що обмежує можливі значення домена. Я буду вдячний тому, хто приведе мені умову на рядковий тип даних, задаючий домен "Прізвище співробітника". Ясно, що рядки, що є прізвищами не повинні починатися з цифр, службових символів, з м'якого знаку і т.д. Але чи є допустимим прізвище "Ггггггиииии"? Чом би ні? Очевидно, ні! А може хтось на зло так себе назве. Труднощі такого роду виникають тому, що значення реальних явищ далеко не завжди можна формально описати. Просто ми, як всі люди, інтуїтивно розуміємо, що таке прізвище, але ніхто не може дати таке формальне визначення, яке відрізняло б прізвища від рядків, прізвищами не є. Вихід з цієї ситуації простій - покластися на розум співробітника, що вводить прізвища в комп'ютер.
Відносини, атрибути, кортежі відношення
Визначення і приклади.
Фундаментальним поняттям реляційної моделі даних є поняття відношення. У визначенні поняття відношення слідуватимемо книзі К. Дейта [11].
Визначення 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 - компоненти кортежів там впорядковані). Це також третя причина, по якій не можна ототожнити відносини і таблиці, - стовпці в таблиці впорядковані. Одне і те ж відношення може бути зображено різними таблицями, в яких стовпці йдуть в різному порядку.
Всі значення атрибутів атомарні. Це витікає з того, що лежачі в їх основі атрибути мають атомарні значення. Це четверта відмінність відносин від таблиць - в осередки таблиць можна помістити що завгодно - масиви, структури, і навіть інші таблиці.
Зауваження. З властивостей відношення виходить, що не кожна таблиця може задавати відношення. Для того, щоб деяка таблиця задавала відношення, необхідно, щоб таблиця мала просту структуру (містила б тільки рядки і стовпці, причому, в кожному рядку була б однакова кількість полів), в таблиці не повинно бути однакових рядків, будь-який стовпець таблиці повинен містити дані тільки одного типу, всі типи даних, що використовуються, повинні бути простими.
Зауваження. Кожне відношення можна вважати класом еквівалентності таблиць, для яких виконуються наступні умови:
Таблиці мають однакову кількість стовпців.
Таблиці містять стовпці з однаковими найменуваннями.
Стовпці з однаковими найменуваннями містять дані з одних і тих же доменів.
Таблиці мають однакові рядки з урахуванням того, що порядок стовпців може розрізнятися.
Всі такі таблиці є різні зображення одного і того ж відношення.
Перша нормальна форма
Важче всього дати визначення речей, які всім зрозумілі. Якщо давати не строге, описове визначення, то завжди залишається можливість неправильного його трактування. Якщо дати строге формальне визначення, то воно, як правило, або тривіальне, або дуже громіздке. Саме така ситуація з визначенням відношення в Першій Нормальній Формі (1НФ). Зовсім не говорити про це не можна, оскільки на основі 1НФ будуються більш високі нормальні форми, які розглядаються далі в гл. 6 і 7. Дати визначення 1НФ складно зважаючи на його тривіальність. Тому, дамо просто декілька пояснень.
Пояснення 1. Говорять, що відношення знаходиться в 1НФ, якщо воно задовольняє визначенню 2.
Це, власне, тавтологія, адже з визначення 2 виходить, що інших відносин не буває. Дійсно, визначення 2 описує, що є відношенням, а що - ні, отже, відносин в непершій нормальній формі просто немає.
Пояснення 2. Говорять, що відношення знаходиться в 1НФ, якщо його атрибути містять тільки скалярні (атомарні) значення.
Знову ж таки, визначення 2 спирається на поняття домена, а домени визначені на простих типах даних.
Непершу нормальну форму можна одержати, якщо допустити, що атрибути відношення можуть бути визначені на складних типах даних - масивах, структурах, або навіть на інших відносинах. Легко собі представити таблицю, біля якої в деяких осередках містяться масиви, в інших осередках - певні користувачами складні структури, а в третіх осередках - цілі реляційні таблиці, які у свою чергу можуть містити такі ж складні об'єкти. Саме такі можливості надаються деякими сучасними пост-реляцийними і об'єктними СУБД.
Вимога, що відносини повинні містити тільки дані простих типів, пояснює, чому відносини іноді називають плоскими таблицями (plain table). Дійсно, таблиці, задаючі відносини двовимірні. Одне вимірювання задається списком стовпців, друге вимірювання задається списком рядків. Пара координат (Номер рядка, Номер стовпця) однозначно ідентифікує елемент таблиці і значення, що міститься в ній. Якщо ж допустити, що в елементі таблиці можуть міститися дані складних типів (масиви, структури, інші таблиці), то така таблиця буде вже не плоскою. Наприклад, якщо в елементі таблиці міститься масив, то для звернення до елементу масиву потрібно знати три параметри (Номер рядка, Номер стовпця, номер елементу в масиві).
Таким чином з'являється третє пояснення Першої Нормальної Форми:
Пояснення 3. Відношення знаходиться в 1НФ, якщо воно є плоскою таблицею.
Ми свідомо обмежуємося розглядом тільки класичної реляційної теорії, в якій всі відносини мають тільки атомарні атрибути і явно знаходяться в 1НФ.
Висновки
Реляційна модель даних складається з трьох частин:
Структурної частини.
Цілісної частини.
Маніпуляційної частини.
У класичній реляційній моделі використовуються тільки прості (атомарні) типи даних. Прості типи даних не володіють внутрішньою структурою.
Домени - це типи даних, що мають деякий сенс (семантику). Домени обмежують порівняння - некоректно, хоча і можливо, порівнювати значення з різних доменів.
Відношення складається з двох частин - заголовка відношення і тіла відношення. Заголовок відношення - це аналог заголовка таблиці. Заголовок відношення складається з атрибутів. Кількість атрибутів називається ступенем відношення. Тіло відношення - це аналог тіла таблиці. Тіло відношення складається з кортежів. Кортеж відношення є аналогом рядка таблиці. Кількість кортежів відношення називається потужністю відношення.
Відношення володіє наступними властивостями:
У відношенні немає однакових кортежів.
Кортежі не впорядковані (зверху вниз).
Атрибути не впорядковані (зліва направо).
Всі значення атрибутів атомарні.
Реляційною базою даних називається набір відносин.
Схемою реляційної бази даних називається набір заголовків відносин, що входять в базу даних.
Відношення знаходиться в Першій Нормальній Формі (1НФ), якщо воно містить тільки скалярні (атомарні) значення.
© 2014 - 2019 BigLib.info — это сокращение от Big Library (большая библиотека).
Целью создания этого сайта было сделать украинскую литературу доступной для всех, кто желает ее читать.
Использование любых материалов сайта без согласования с администрацией запрещено.
Обратная связь