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

Реляційна модель даних (РМД) покладена в основу більшості сучасних СУБД. Достоїнствами моделі є простота розміщення даних та зручність їх інтерпретації.

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

Кожна таблиця реляційної бази даних має ім'я і рядок заголовків. Розглянемо таблицю бази даних торговельного підприємства, в якій зберігаються відомості про постачальників товарів (табл. 1.1):

Таблица 1.1 Поставщики

Код	Название	Город
345	Волна	Хабаровск
412	Парус	Владивосток
123	Звезда	Хабаровск
215	Парус	Иркутск

Таблиця має ім'я Постачальники, назви стовпців таблиці Код, Назва, Місто являють собою рядок заголовків.

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

У термінології реляційної моделі даних кожен стовпець таблиці називається полем (атрибутом), кожен рядок таблиці - записом (кортежем).

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

До таблиць РМД висуваються такі вимоги: 1. Значення даних, розташовані на перетині будь-яких рядка і стовпця, повинні бути неподільними (атомарними, елементарними). Ця вимога означає, що в кожній клітинці таблиці може знаходитися тільки одне значення. 2. У таблиці не повинно бути полів з однаковими назвами, порядок розташування полів є довільним. Наявність цієї вимоги визначається тим, що пошук інформації в таблиці реалізується в полях, імена яких зазначені в запиті. 3. Порядок проходження записів може бути довільним. 4. У таблиці не повинно бути однакових записів.

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

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

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

Таблица 1.2 Поставки товаров

Название товара	Артикул	Количество	Дата поставки	Шифр поставщика
Костюм	500	100	10.12.05	345
Сапоги	200	75	10.12.05	123
Туфли	100	120	11.12.05	123
Костюм	500	100	11.12.05	345
Костюм	300	50	12.12.05	345
Костюм	400	50	12.12.05	215
Туфли	100	100	12.12.05	215

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

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

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

Таблица 1.3 Дополнительные сведения

Поставщик	Директор	Телефон	Адрес	№ договора
345	Иванов П. Л.	64-12-83	Мира, 4	75
412	Сеидов О. А.	22-17-12	Победы, 18	19
123	Цой О. М.	39-18-34	Блюхера, 1	79
215	Лодис С. С.	46-19-23	Пушкина, 1	35

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

Зв'яжемо таблиці Постачальники і Додаткові відомості за допомогою полів Код та Постачальник. Порівнюючи значення даних у цих полях і вибираючи поєднання записів, для яких вони збігаються, можна отримати відповіді, наприклад, на такі запити: «Хто є директором організації« Парус »з Владивостока?» (Сеїд О.А.); «Яка адреса у організації «Хвиля»? »(Миру, 4).

Наведений приклад демонструє зв'язок між таблицями «один до одного» - одного запису в таблиці Постачальники відповідає один запис у таблиці Додаткові відомості.

Зв'яжемо тепер таблиці Постачальники і Поставки товарів за допомогою полів Код та Шифр ​​постачальника. Виникає питання про правомірність виконаних дій. Так як значення даних у полі Шифр ​​постачальника повторюються, це поле не може бути первинним ключем таблиці Поставки товарів.

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

За допомогою зв'язування таблиць Постачальники і Поставки товарів по ключових полях, можна отримати відповіді на запити: «Яка організація поставила костюми 10 грудня 2005?» (Хвиля); «З яких міст були привезені туфлі?» (Хабаровськ, Іркутськ).

Пов'язуючи таблиці Поставки товарів та Додаткові відомості, можна отримати відповіді на запити: «Який номер телефону у організації, яка поставила костюми з артикулом 500?» (64-12-83); «Відповідно до якого договором поставлялися костюми з артикулом 400?» ( № 35).

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

Для зв'язування таблиць, дані в зв'язуючих полях обов'язково повинні бути отримані з одного домену. Імена зв'язуючих полів можуть відрізнятися один від одного (Код, Шифр ​​постачальника, Постачальник), розташування сполучних полів в таблицях може бути довільним (див. табл. 1.1 - 1.3).