Концепція реляційної моделі належить американському вченому Е. Кодда [14,18,24].
Реляційні моделі даних (РМД), на відміну від розглянутих вище мережевих і ієрархічних, характеризуються більшою стандартизацією і простотою структур даних, зручним для користувача табличним поданням і доступом до даних.
Операції обробки даних реляційної моделі засновані на використання формального реляційної алгебри. Це забезпечує використання типових простих засобів обробки в різних СУБД. До таких засобів відноситься, наприклад, реляційний мову структурованих запитів SQL. На відміну від ієрархічних і мережевих реляційні бази даних не вимагають опису схеми даних і його генерації, тобто не потрібно налаштування СУБД на конкретну структуру БД.
Структури даних реляційної моделі
Реляційна таблиця є основним типом структури даних (об'єктом) реляційної моделі. Структура цієї таблиці визначається сукупністю стовпців (атрибутів).
Стовпець відповідає деякому елементу даних - простому атрибуту, який є найпростішою структурою даних. У таблиці не можуть бути визначені множинні елементи, група чи актуальна група, як в розглянутих вище ієрархічних або мережевих моделях. Таким чином, таблиця має чисто лінійну структуру.
Основний логічною одиницею обробки (пошук, вибірка, сортування, обчислення) в реляційної БД є рядок таблиці.
Найважливішими властивостями реляційної таблиці є:
· Не може бути двох однакових рядків.
· В кожному рядку міститься по одному значенню кожного атрибута.
Ім'я кожного стовпця (атрибута) має бути унікальним в структурі таблиці, тобто імена не можуть повторюватися в одній таблиці.
Визначення та основні поняття реляційного підходу
У реляционном підході до побудови баз даних використовується термінологія теорії відносин. Реляційна таблиця називається відношенням. Стовпець таблиці зі значеннями відповідного атрибута називається домен. а рядки зі значеннями різних атрибутів - кортеж.
Реляційна таблиця-відношення. На рис.2.4 дана в загальному вигляді іллюст-рація реляційної таблиці-отношеніяR.
Формальне визначення ставлення R (реляційної таблиці) спирається на уявлення про її доменахDi (шпальтах) і кортежахKj (рядках).
Ставленням R, визначеним на множинах доменів í D i ý . називається підмножина декартова твори доменів D1 * D2 *. * DN.
Рис.2.4 Ілюстрація реляційної таблиці-відносини R розмірності n = 6.
Таблиця -отношеніеR (рис.2.4) містить стовпці з іменами атрибутів (A1, A2.). Значення атрибутів d знаходяться в змістовній частині таблиці і утворюють рядки і стовпці. Безліч значень атрибутів в одному рядку утворюють один кортеж До j. Безліч значень атрибутів в одному стовпці утворюють один домен Di.
Відношення R утворюється безліччю впорядкованих кортежів
j - номер кортежу; m - загальне число кортежів щодо, зване координатним числом відносини.
Розмірність - параметр структури даних, координатне число-параметр масиву даних
Ключ таблиці-відносини. Кортежі не повинні повторяться всередині табліци- відносини і відповідно повинні мати унікальний ідентифікатор - первинний ключ. У загальному випадку ключі бувають двох видів: первинний (унікальний) ключ (ПК) і вторинний ключ (ВК)
Первинний ключ (ПК) - це один або декілька атрибутів, однозначно ідентифікують рядок. Якщо первинний ключ складається з одного атрибута, він називається простим. якщо з декількох - складовим первинним ключем. За значенням первинного ключа може бути знайдений єдиний екземпляр рядка-кортежу.
Вторинний ключ (ВК). на відміну від первинного, - це такий атрибут, значення якого може повторюватися в декількох рядках таблиці, тобто він не є унікальним. За значенням вторинного ключа відшукується кілька рядків з однаковим значенням цього ключа. Атрибути, що входять до складу первинного ключа, є вторинними ключами.
Індексування. Засобом ефективного доступу по ключу до даних є індексування. При індексуванні створюється додатковий індексний набір, який містить у впорядкованому вигляді все значення ключа таблиці. Для кожного значення ключа в індексному наборі міститься покажчик на відповідний рядок. При наявності індексного набору, розміри якого менше таблиці даних, швидко відшукується заданий ключ. За допомогою покажчика здійснюється прямий доступ до шуканої рядку. Індексування може проводитися не тільки з первинного, а й по вторинному ключу.
Нормалізація даних реляційної моделі
Важливою вимогою, що пред'являються до відносин (таблиць) реляційної моделі, є нормалізація даних, представлених таблицею. Будь-яка реляційна таблиця повинна відповідати як мінімум вимогу первинної нормалізації.
Первинно нормалізована таблиця містить рядки, в яких для кожного атрибута може бути тільки одне значення. Це відповідає обов'язковій вимозі неприпустимість множинних і повторюваних структур даних в реляційної таблиці.
Існує кілька нормальних форм реляційної моделі, які вводять обмеження і дозволяють мінімізувати дублювання даних, забезпечити підтримку цілісності, однократность введення даних:
· При першій нормальній формі всі атрибути відносини повинні бути простими;
· При другій нормальній формі всі атрибути відносини є простими і кожен неключових атрибут функціонально-повно зависитот ключа.
Повна функціональна залежність неключових атрибута означає, що ключ однозначно визначає неключових атрибут. Тобто одному значенню ключа відповідає одне значення неключевого атрибута. Якщо ключ складовою, то подібна залежність повинна виконуватися на рівні всього ключа, а не який-небудь його частини.
· При третій нормальній формі всі атрибути відносини є простими і кожен неключових атрибут функціонально-повно залежить від ключа, причому не транзитивній.
Якщо реляційні таблиці знаходяться в першій нормальній формі, при цьому, як правило, має місце значне дублювання даних.
Нижче показаний приклад первинно нормализованной реляційної таблиці таблиці (рис.2.5) ..
Існують і більш високі форми нормалізації, які не мають великого практичного значення [18].
Якщо прийняти в якості ключа для планової поставки прийняти - ідентифікатор договору + ідентифікатор вироби, то очевидно не виконається требованіевторой нормальної форми, так як атрибут Замовник ф-повнісінько залежить від ід. Договору, тобто від частини ключа.
Якщо прийняти в якості ключа - ідентифікатор договору ......
Якщо прийняти в якості ключа - ідентифікатор вироби .......
Ненормалізованих таблиці, наведеної на рис.2.5, будуть відповідати дві реляційних таблиці (відносини) R1 і R2 (рис.2.6) Піддругій нормальній формі
Ставлення R1 - Договір
Ідентифікатор договору (ключ)
Рис.2.6. Дві реляційних таблиці - результат нормалізації даних
Логічні зв'язки в реляційної моделі, реляційна БД
Логічні зв'язки нормалізованих таблиць. Однаково певні атрибути в різних відносинах є засобом логічного зв'язку між кортежами різних відносин і грають роль ключа зв'язку
Для організації групових відносин рядків двох нормалізованих таблиць визначається логічний зв'язок нормализованной таблиці-відносини R1 з підлеглою нормализованной таблицею-ставленням R2. Остання повинна містити зовнішній ключ - ключ головної таблиці-відносини R1.
Зовнішнім ключем підпорядкованої таблиці-відносини (в зв'язку) часто є вторинний ключ цього відношення або не ключовий атрибут.
Реляційна база даних. Сукупність реалізацій нормалізованих відносин (реляційних таблиць), логічно взаємопов'язаних і відображають деяку предметну область, утворює реляційну базу даних.
В результаті проектування реляційної БД повинен бути визначений склад логічно взаємопов'язаних реляційних таблиць і визначено склад атрибутів кожного відносини.
Цілісність бази даних. Реляційна база нормалізованих даних може бути наділена властивостями підтримки цілісності.
Цілісність - це набір певних правил, які встановлюють допустимість типів, значень даних, відсутність дублювання і обов'язковість значень атрибутів в різних об'єктах бази, а також коректність зв'язків між таблицями.
Посилальної цілісністю вважається вимога обов'язкової наявності пов'язаної рядки головної таблиці для кожного рядка підпорядкованої таблиці. Таким чином, зовнішнім значенням ключа зв'язку підпорядкованої таблиці завжди повинна знайтися запис з таким же значенням первинного ключа [17]. Посилальна цілісність може підтримуватися автоматично за умови нормалізації таблиць БД. Нормалізація таблиць може бути забезпечена на етапі проектування БД.
Опис логічної організації реляційної БД має визначати її структуру. Воно включає визначення переліку таблиць і опис структури кожної таблиці. Опис структури кожного відносини (реляційної таблиці) має містити унікальне в БД ім'я таблиці; склад і послідовність атрибутів таблиці; завдання унікальних (всередині таблиці) імен атрибутів; визначення типу і розміру даного для кожного атрибута. Крім того, для кожного відносини повинен бути вказаний первинний (унікальний) ключ (простий або складової). Для таблиць, між якими встановлюються логічні зв'язки, повинні бути визначені ключі зв'язку, тобто зовнішні ключі в підлеглих таблицях.
Приклад структури реляційної бази даних. На рис.2.7 наведено приклад структури бази даних, що містить інформацію про договори при використанні реляційної моделі. Така ж інформація представлена на рис.2.1, але при використанні ієрархічної записи.
Як видно із зіставлення цих прикладів, при ієрархічної організації даних можна говорити про дублювання даних про одних і тих же замовників і про однакові виробах в різних договорах.
Рис.2.7. Приклад структури реляційної бази даних, що містить інформацію про договори.