Реляційна модель даних — це унікальний підхід до управління параметрами з використанням структури і мови відповідно до предикатной логікою одиничного порядку. Вона вперше була описана в 1969 році англійським вченим Коддом. У цьому проекті всі параметри представлені у вигляді кортежів, згрупованих у певні відносини.
Мета реляційної моделі даних…
…це надавати декларативний метод для вказівки моделей і запитів.
Користувачі безпосередньо відзначають, яку інформацію містить база даних і яку теорію вони хочуть від неї. І також дозволяють програмного забезпечення системи управління базами подбати про описі структур для її зберігання. Важлива і інформаційно-пошукова процедура для відповідей на запити.
Більшість РБД використовують визначення даних SQL і мова пошуку. Ці системи реалізують те, що можна розглядати як інженерне наближення до реляційної моделі.
Таблицю в схемі бази даних SQL відповідає предикатной змінної. Ключові обмеження і запити SQL відповідають предикатам.
Однак такі бази даних в багатьох деталях відхиляються від реляційної моделі, і Кодд люто виступав проти змін, які ставлять під загрозу вихідні принципи.
Огляд
Основна ідея реляційної моделі даних — це опис всієї бази як набору предикатів для кінцевого становить змінних, що описують обмеження на можливі значення та їх комбінації. Вміст в будь-який момент часу являє собою кінцеву (логічну) модель. Тобто набір відносин, по одному на змінну предиката, так що всі компоненти задоволені. Саме це реляційна модель даних.
Альтернативи
Іншими моделями є ієрархічна і мережна системи. Деякі з них, що використовують більш старі архітектури, досі популярні в центрах обробки даних з високими вимогами до обсягу. Або в тих випадках, коли існуючі системи настільки складні і абстрактні, що перехід на них, що використовують реляційну модель, недозволено дорогим. І також слід відзначити нові об’єктно-орієнтовані бази даних.
Реалізація
Було здійснено кілька спроб отримати справжню матеріалізацію РМД, первісно визначену Коддом і пояснену іншими вченими.
Реляційна модель представлення даних була головною у своєму роді, яка була описана у формально-математичних термінах. Ієрархічні та мережеві бази існували до реляційних систем, але їх специфікації були відносно неформальними. Після того як РМД була визначена, фахівці робили багато спроб порівняти і зіставити різні моделі – і це призвело до появи більш суворих описів ранніх систем. Хоча процедурний характер інтерфейсів маніпулювання даними для ієрархічних і мережевих баз обмежував можливості для формалізації.
Теми
Фундаментальним припущенням про поняття реляційної моделі даних є те, що всі вони представлені у вигляді математичної “п” – типових відносин, “Сп” – парній зв’язку, що є підмножиною в декартовом творі з декількох доменів. В математичній моделі міркування про таких даних здійснюється у двозначній логіці предикатів, що означає, що для кожної пропозиції є дві можливі оцінки: істина або брехня (і немає третього значення, такого як невідомо чи незастосовне, кожен з яких часто асоціюється з поняттям 0). Дані обробляються за допомогою обчислення або алгебри, які еквівалентні в виразною силою.
Види моделей даних, реляційна модель даних
РМД дозволяє розробнику створювати узгоджене, логічне представлення інформації. Це все досягається шляхом включення заявлених обмежень в проект бази даних, який зазвичай називають логічною схемою. Теорія полягає в розробці процесу нормалізації моделей, за допомогою якого проект з певними бажаними властивостями може бути вибраний з набору логічно еквівалентних альтернатив. У планах доступу та інших реалізаціях і эксплуатациях деталі обробляються СУБД-двигуном і не відображені в логічній моделі. Це контрастує з звичайною практикою, в якій налаштування продуктивності часто вимагає змін в логічній функції.
Основна реляційна модель даних являє будівельний блок — це домен або тип інформації, зазвичай скорочений до мінімуму. Кортеж являє собою упорядкований набір значень атрибутів. А вони, в свою чергу, є взаємною парою імені і типу. Це може бути або скалярне значення, або більш складний варіант.
Відношення складається із заголовка і тіла
Перший — це набір атрибутів.
Тіло (з n-ним відношенням) — це комплект з кортежів.
Заголовок стосунку також є темою кожної структури.
Реляційна модель даних визначається як набір з n – кортежів. Як у математиці, так і в МРД комплект являє собою неупорядковану колекцію унікальних недублированных елементів, хоча деякі СУБД нав’язують послідовність своїх даних. В математиці кортеж має порядок і допускає дублювання. Е. Ф. Кодд спочатку встановив кортежі, використовуючи це математичне визначення.
Пізніше одна з чудових ідей Е. Ф. Кодда полягала в тому, що використання імен атрибутів замість впорядкування було б набагато більш зручним (в загальному випадку) в комп’ютерному мовою, заснованому на відносинах. Це твердження все ще корисно сьогодні. Хоча концепція змінилася, назва «кортеж» не трансформувалося. Безпосереднім і важливим наслідком цієї відмітною рисою є те, що в реляційної моделі декартів добуток стає коммутативным.
Таблиця — це загальноприйняте візуальне подання відносин. Кортеж схожий на концепцію рядка.
Relvar є іменованої змінної певного типу стосунку, до якого у всі часи деяка зв’язок цього типу присвоюється, хоча погляд може містити нуль кортежі.
Основи реляційної моделі даних: вся інформація представлена значеннями інформації у відносинах. У відповідності з цим принципом реляційна база являє собою набір relvars, і результат кожного запиту представляється у вигляді відношення.
Узгодженість реляційної бази даних забезпечується не правилами, вбудованими в додатки, які її використовують, а швидше обмеженнями, оголошеними як частина логічної схеми і впровадженими СУБД для всіх додатків. Обмеження виражаються у використанні реляційних операторів порівняння, з яких тільки один є підмножиною (⊆), теоретично достатнім. На практиці очікується, що буде доступно кілька корисних скорочень, з яких найбільш важливими є ключі-кандидати та обмеження зовнішнього джерела. Саме це все є реляційною моделлю даних.
Інтерпретація
Для того щоб повною мірою оцінити РМД, необхідно зрозуміти передбачувану інтерпретацію у вигляді відношення.
Тіло стосунку іноді називають його розширенням. Це пов’язано з тим, що його слід інтерпретувати як уявлення деякого збільшення предиката. Це набір справжніх пропозицій, які можна сформувати, замінивши кожну вільну змінну ім’ям.
Між об’єктно-реляційними моделями даних існує взаємно однозначна відповідність. Кожен кортеж тіла відносини надає значення атрибутів для створення екземпляра предиката шляхом підстановки кожної з його вільних змінних. Результатом є твердження, яке вважається вірним з-за появи кортежу в тілі відносини. Навпаки, кожен процес, заголовок якого відповідає назві відносин, але який не з’являється в тілі, вважається хибним.
Це припущення відомо як гіпотеза про замкнутому світі. Вона часто порушується в практичних базах даних, де відсутність кортежу може означати, що істинність відповідного пропозиції невідома. Наприклад, відсутність деяких понять («Джон», «іспанський») в таблиці мовних навичок необов’язково може служити доказом того, що хлопчик по імені Джон не говорить на іспанською мовою.
Застосування до баз даних, теорія нормалізації
Суб’єкт інформації, що використовується в типовій реляційної РМД, може бути набором цілих чисел, комплектом символьних рядків, складовим дат або двома логічними значеннями true і false і так далі. Відповідними іменами суб’єктів для цих фігур можуть бути рядки з найменуваннями “Індекс”, “Виконати необхідну роботу”, “Час”, “Логічне значення” і так далі і тому подібне.
Однак важливо розуміти, що теорія відносин не визначає, які типи повинні підтримуватися. І це дійсно правда, в даний час очікується, що положення будуть доступні для користувача суб’єктів на додаток до вбудованих, що надаються системою.
Атрибут
Це термін, що використовується в теорії для того, що ,як правило, називають стовпцем. Точно так само таблиця зазвичай використовується замість теоретичного терміна стосунку (хоча в SQL він аж ніяк не є синонімом відносини). Структура даних таблиці вказується у вигляді списку визначень стовпців, в кожному з яких пишеться унікальне ім’я колонки і тип значень, дозволених для нього.
Атрибут значення є записом у визначеному місці, наприклад, John Doe і 35.
Кортеж в основному те ж саме, що й ряд, за винятком того, що в СУБД SQL, де смисли стовпців у рядку упорядковані, кортежі не розділені. Замість цього кожне значення визначення ідентифікується виключно по його назві, а не за його порядкової позиції в кортежі. Ім’я атрибута може бути Name або Age.
Ставлення
Воно являє собою таблицю визначення структури поряд з появою даних у цій будові. Дефініція — це заголовок, а дані в ньому — це тіло, набір рядків. Змінна відносин зазвичай називається основною таблицею. Заголовок йому присвоюється значення в будь-який час відповідає вказаному в заданій клітці, а його тіло відповідає тому, яке було йому присвоєно останнім, викликаючи певний оператор оновлення (зазвичай INSERT, UPDATE або DELETE).
Теоретико-множинна формулювання
Основні поняття реляційної моделі відносин – імена і назви атрибутів. Їх необхідно представляти як рядки, такі як “Персона” і “Найменування”, і зазвичай потрібно буде використовувати змінні, щоб охопити їх. Інше базове поняття — набір атомарних значень, який містить необхідні і важливі смисли, такі як числа і рядки.
