Перегляд вихідного коду сторінки Реляційна модель даних. Основна термінологія. Види ключів. Цілісність реляційних даних.

Глущенко Дар'я МІ14Б

'''Реляційна модель даних'''&nbsp;— [[Математична логіка|логічна]] [[Моделі баз даних|модель даних]]. Вперше була запропонована британським ученим співробітником компанії [[IBM]] [[Едгар Кодд|Едгаром Франком Коддом]] (E. F. Codd) в 1970 році в статті «A Relational Model of Data for Large Shared Data Banks». В даний час ця модель є фактичним стандартом, на який орієнтуються практично всі сучасні комерційні [[Система керування базами даних|системи керування базами даних (СКБД)]].

У реляційній моделі досягається більш високий рівень абстракції даних, ніж в ієрархічній або мережевій. У згаданій статті Е.&nbsp;Ф.&nbsp;Кодда стверджується, що «реляційна модель надає засоби опису даних на основі тільки їх природної структури, тобто без потреби введення якоїсь додаткової структури для цілей машинного представлення». Іншими словами, подання даних не залежить від способу їх фізичної організації. Це забезпечується за рахунок використання математичного поняття [[відношення]] (сама назва «реляційна» походить від англійського relation&nbsp;— «відношення»).

==Склад реляційної моделі==
До складу реляційної моделі даних зазвичай включають теорію нормалізації.
Крістофер Дейт визначив три складові частини реляційної моделі даних:
* структурна
* маніпуляційна
* цілісна

'''Структурна частина''' моделі визначає, що єдиною структурою даних є нормалізоване n-арне відношення. Відношення зручно представляти у формі таблиць, де кожен рядок є [[кортеж]], а кожен стовпець&nbsp;— атрибут, визначений на деякому домені. Даний неформальний підхід до поняття відношення дає більш звичну для розробників і користувачів форму представлення, де реляційна база даних являє собою кінцевий набір таблиць.

'''Маніпуляційна частина''' моделі визначає два фундаментальних механізми маніпулювання даними&nbsp;— реляційну алгебру і реляційне числення. Основною функцією маніпуляційної частини реляційної моделі є забезпечення заходів реляційності будь-якої конкретної мови реляційних БД: мова називається реляційною, якщо вона має не меншу виразність і потужність, ніж реляційна алгебра або реляційне числення.

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

Можна провести аналогію між елементами реляційної моделі даних і елементами моделі «сутність-зв'язок». Реляційні відносини відповідають наборам сутностей, а кортежі&nbsp;— сутностям. Тому, як і в моделі «сутність-зв'язок», стовпці в таблиці, що представляє реляційне відношення, називають атрибутами.

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

Іменована множина пар «ім'я атрибута&nbsp;— ім'я домену» називається схемою відношення. Потужність цієї множини&nbsp;— називають ступенем чи «арністю» відносини. Набір іменованих схем відносин являє собою [[Схема бази даних|схему бази даних]].

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

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

==Переваги реляційної моделі==
Переваги реляційної моделі:
* простота і доступність для розуміння користувачем. Єдиною використовуваною інформаційною конструкцією є «таблиця»;
* суворі правила проектування, які базуються на математичному апараті;
* повна незалежність даних. Зміни в прикладній програмі при зміні реляційної БД мінімальні;
* для організації запитів і написання прикладного ПЗ немає необхідності знати конкретну організацію БД у зовнішній пам'яті.

==Недоліки реляційної моделі==
Недоліки реляційної моделі:
* далеко не завжди предметна область може бути представлена у вигляді «таблиць»;
* в результаті логічного проектування з'являється множина «таблиць». Це призводить до труднощів розуміння структури даних;
* БД займає відносно багато зовнішньої пам'яті;
* відносно низька швидкість доступу до даних.

==Модель вкладених множин==
'''Модель вкладених множин''' ({{lang-en|Nested Set Model}}) - техніка для представлення [[Дерево (структура даних) | дерев]] в [[Реляційна база даних | реляційних базах даних]].

=== Мотивація ===

Техніка є відповіддю на проблему того, що стандартна [[реляційна алгебра]] та побудовані на ній [[SQL]] операції не можуть бути застосовані для всіх потрібних маніпуляцій з деревами (ієрархіями). Якщо дерево має довільну глибину, це не дозволяє використовувати [[SQL]] вирази для таких операцій, як порівняння місця в ієрархії для двох елементів або визначення належності елемента до певного під-дерева.

Існує декілька підходів для вирішення проблеми і деякі є доступними в [[Система керування базами даних | системах керування базами даних]]:

* підтримка ієрархічних типів даних;
* розширення [[SQL]] для маніпуляцій з деревами;
* [[SQL]] запити можуть бути виражені мовою програмування, яка підтримує ітерації та дозволяє виконувати реляційні операції, як от [[PL/SQL]], [[T-SQL]], або майже будь-якою сучасною мовою програмування;

=== Техніка ===

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

=== Приклад ===

У каталозі одяг може бути категоризовано відповідно до ієрархії:

[[Файл:юбд.png]]
{| class="wikitable"
| Вузол|| Ліве || Праве
|-
| Одяг || 1 || 22
|-
| Чол. || 2 || 9
|-
| Жін. || 10	|| 21
|-
| Костюми || 3 || 8
|-
| Штани || 4 || 5
|-
| Жакети || 6 || 7
|-
| Сукні || 11 || 16
|-
| Спідниці || 17 || 18
|-
| Блузи || 19 || 20
|-
| Вечірні || 12 || 13
|-
| Сонячні літні || 14 || 15
|+ Атрибути
|}

Категорія "Одяг", яка має найвищу позицію в ієрархії, включає в себе всі підкатегорії. Атрибути мають значення 1 та 22, останнє значення дорівнює числу вузлів помноженому на 2. Наступний рівень ієрархії включає категорії "Чол." та "Жін.", обидва включають піддерева. На кожному рівні вузлу призначено "праве" та "ліве" значення відповідно до кількості вкладених вузлів. 
Таким чином, щоб вирахувати чи належить, наприклад, категорія "Блузи" до жіночого одягу треба порівняти відповідні атрибути "Ліве" та "Праве".

==Реляційна база даних==
'''Реляційна база даних'''&nbsp;— [[база даних]], заснована на [[Реляційна модель даних|реляційній моделі даних]]. Слово «реляційний» походить від {{lang-en|relation}}. Для роботи з реляційними БД застосовують [[реляційна СКБД|реляційні СКБД]]. Інакше кажучи, реляційна база даних&nbsp;— це база даних, яка сприймається користувачем як набір нормалізованих відношень різного ступеня.

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

Використання реляційних БД було запропоноване [[Едгар Кодд|Едгаром Коддом]] в 1970 році.

== Нормалізація ==

Метою нормалізації є усунення недоліків структури БД, які призводять до шкідливої надмірності в даних, яка в свою чергу потенційно призводить до різних аномалій і порушень цілісності даних.

Теоретики реляційних баз даних у процесі розвитку теорії виявили та описали типові приклади надмірності і способи їхнього усунення.

=== Нормальні форми ===

{{main|Нормальна форма}}

Нормальна форма&nbsp;— формальна властивість відношення, яка характеризує ступінь надмірності збережуваних даних і можливі проблеми. Кожна наступна нормальна форма в нижченаведеному списку (крім ДКНФ) в деякому сенсі є досконалішою, ніж попередня, з точки зору усунення надмірності.

* [[Перша нормальна форма]] (1НФ, 1NF)
* [[Друга нормальна форма]] (2НФ, 2NF)
* [[Третя нормальна форма]] (3НФ, 3NF)
* [[Нормальна форма Бойса — Кодда]] (НФБК, BCNF)
* [[Четверта нормальна форма]] (4НФ, 4NF)
* [[П'ята нормальна форма]] (5НФ, 5NF)
* [[Доменно-ключова нормальна форма]] (ДКНФ, DKNF).

=== Нормалізація баз даних===
'''Нормалізація схеми бази даних'''&nbsp;— покроковий процес розбиття одного відношення (на практиці: таблиці) відповідно до алгоритму нормалізації на декілька відношень на базі [[Функціональна залежність|функціональних залежностей]].

'''Нормальна форма'''&nbsp;— властивість [[відношення (реляційна модель)|відношення]] в [[реляційна модель даних|реляційній моделі даних]], що характеризує його з точки зору надмірності, яка потенційно може призвести до логічно помилкових результатів вибірки або зміни даних. Нормальна форма визначається як сукупність вимог, яким має задовольняти відношення.

Таким чином, схема [[Реляційна база даних|реляційної бази даних]] переходить у першу, другу, третю і так далі нормальні форми. Якщо відношення відповідає критеріям нормальної форми ''n'' та всіх попередніх нормальних форм, тоді вважається, що це відношення знаходиться у нормальній формі рівня ''n''.

== Нормальні форми ==

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

[[Перша нормальна форма]] (1НФ, 1NF) утворює ґрунт для структурованої схеми бази даних:
* Кожна таблиця повинна мати основний ключ: мінімальний набір колонок, які ідентифікують запис.
* Уникнення повторень груп (категорії даних, що можуть зустрічатись різну кількість разів в різних записах) правильно визначаючи неключові атрибути.
* Атомарність: кожен атрибут повинен мати лише одне значення, а не множину значень.

=== Друга нормальна форма ===

[[Друга нормальна форма]] (2НФ, 2NF) вимагає, аби дані, що зберігаються в таблицях із композитним ключем, не залежали лише від частини ключа:
* [[Схема бази даних]] повинна відповідати вимогам першої нормальної форми.
* Дані, що повторно з'являються в декількох рядках, виносяться в окремі таблиці.

=== Третя нормальна форма ===

[[Третя нормальна форма]] (3НФ, 3NF) вимагає, аби дані в таблиці залежали винятково від основного ключа:
* [[Схема бази даних]] повинна відповідати всім вимогам другої нормальної форми.
* Будь-яке поле, що залежить від основного ключа та від будь-якого іншого поля, має виноситись в окрему таблицю.

=== Нормальна форма Бойса&nbsp;— Кодда ===

Відношення знаходиться в [[Нормальна форма Бойса — Кодда|НФБК]] тоді і лише тоді, коли детермінант кожної функціональної залежності є потенційним ключем. Якщо це правило не виконується, то, щоб привести вказане відношення до НФБК, його слід розділити на два відношення шляхом двох операцій проекції на кожну функціональну залежність, детермінант якої не є потенційним ключем:
# Проекція без атрибутів залежної частини такої функціональної залежності;
# Проекція на всі атрибути цієї функціональної залежності.

Визначення НФБК не потребує жодних умов попередніх нормальних форм. Якщо проводити нормалізацію послідовно, то в переважній більшості випадків при досягненні 3НФ автоматично будуть задовольнятися вимоги НФБК. 3НФ не збігається з НФБК лише тоді, коли одночасно виконуються такі 3 умови:{{fact}}
# Відношення має 2 або більше потенційних ключів.
# Ці потенційні ключі складені (містять більш ніж один атрибут)
# Ці потенційні ключі перекриваються, тобто мають щонайменше один спільний атрибут.

=== Четверта нормальна форма ===

[[Четверта нормальна форма]] (4НФ, 4NF) потребує, аби в схемі баз даних не було нетривіальних багатозначних залежностей множин атрибутів від будь чого, окрім надмножини ключа-кандидата. Вважається, що таблиця знаходиться у 4НФ тоді і лише тоді, коли вона знаходиться в НФБК та багатозначні залежності є функціональними залежностями. Четверта нормальна форма усуває небажані структури даних&nbsp;— багатозначні залежності.

=== П'ята нормальна форма ===

[[П'ята нормальна форма]] (5НФ, 5NF, PJ/NF) вимагає, аби не було нетривіальних залежностей об'єднання, котрі б не витікали із обмежень ключів. Вважається, що таблиця в п'ятій нормальній формі тоді і лише тоді, коли вона знаходиться в 4НФ та кожна залежність об'єднання зумовлена її ключами-кандидатами.

=== Нормальна форма домен/ключ ===

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

=== Шоста нормальна форма ===

Таблиця знаходиться у 6NF, якщо вона знаходиться у 5NF та задовольняє вимозі відсутності нетривіальних залежностей. Зазвичай 6NF ототожнюють з DKNF.
==Види ключів==
===Первинний ключ===
Первинний ключ — атрибут, або набір атрибутів, що однозначно ідентифікує кортеж даного відношення. Первинний ключ обов'язково унікальний, він єдиний і найголовніший із унікальних ключів.

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

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

З двох логічно пов’язаних таблиць одну називають таблицею первинного ключа або головною таблицею, а іншу таблицею вторинного (зовнішнього) ключа або підпорядкованою таблицею. СУБД дозволяють зіставити споріднені записи з обох таблиць і спільно вивести їх у формі, звіті або запиті.

Існує три типи первинних ключів: ключові поля лічильника (лічильник), простий ключ і складовий ключ.

Поле лічильника (Тип даних «Счетчик»). Для кожного запису цього поля таблиці автоматично заноситься унікальне числове значення.

Простий ключ. Якщо поле містить унікальні значення, такі як коди чи інвентарні номери, то це поле можна визначити як первинний ключ. В якості ключа можна визначити всі поля, що містить дані, якщо це поле не містить повторювані значення або значення Null.

Складові ключі. У випадках, коли неможливо гарантувати унікальність значень кожного поля, існує можливість створити ключ, що складається з декількох полів. Найчастіше така ситуація виникає для таблиці, використовуваної для зв’язування двох таблиць відношенням «багато — до — багатьох».

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

Якщо виникають труднощі з вибором потрібного типу первинного ключа, то в якості ключа доцільно вибрати поле лічильника.
== Посилання ==
* [http://www.headfirstlabs.com/books/hfsql/ Head First SQL]
* [http://pidruchniki.com/13560615/bankivska_sprava/relyatsiyna_model_danih]