Цілісність реляційних даних

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

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


Null-значення

Основне призначення баз даних полягає в тому, щоб зберігати і надавати інформацію про реальний світ. Для представлення цієї інформації в базі даних використовуються звичні для програмістів типи даних – Рядкові, чисельні, логічні і т.п. Однак у реальному світі часто зустрічається ситуація, коли дані невідомі або не повні. Наприклад, місце проживання або дата народження людини можуть бути невідомі (База даних розшукуваних злочинців). Якщо замість невідомої адреси доречно було б вводити порожній рядок, то що вводити замість невідомої дати? Відповідь – порожню дату – не цілком задовільний, тому що найпростіший запит "видати список людей у порядку зростання дат народження" дасть явно неправильних відповідь.

Для того щоб обійти проблему неповних або невідомих даних, в базах даних можуть використовуватися типи даних, поповнені так званим null-значенням. Null-значення – це, власне, не значення, а якийсь маркер, який показує, що значення невідоме.

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

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

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

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

Практично всі реалізації сучасних реляційних СУБД дозволяють використовувати null-значення, незважаючи на їх недостатню теоретичну обгрунтованість. Таку ситуацію можна порівняти з ситуацією, що склалася на початку століття з теорією множин. Майже відразу після створення Кантором теорії множин, в ній були виявлені внутрішні суперечності (антиномії). Були розроблені більш суворі теорії, що дозволяють уникнути цих протиріч (конструктивна теорія множин). Однак у реальній роботі більшість математиків користується класичною теорією множин, тому що більш суворі теорії більш обмежені і негнучкий в застосуванні саме в силу своєї більшої строгості.

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


Тризначна логіка (3VL)

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

При порівнянні виразів, що містять null-значення, результат також може бути невідомий, наприклад, значення істинності для виразу є null, якщо один або обидва аргументи є null. Таким чином, визначення істинності логічних виразів базується на тризначної логіці (three-valued logic , 3VL), В якій крім значень T – ІСТИНА і F – БРЕХНЯ, введено значення U – НЕВІДОМО. Логічне значення U – це те ж саме, що і null-значення. Тризначна логіка базується на наступних таблицях істинності:






















AND F T U
F F F F
T F T U
U F U U

Таблиця 1 Таблиця істинності AND






















OR F T U
F F T U
T T T T
U U T U

Таблиця 2 Таблиця істинності OR














NOT  
F T
T F
U U

Таблиця 3 Таблиця істинності NOT

Є декілька парадоксальних наслідків застосування тризначної логіки.

Парадокс 1. Null-значення не рівне самому собі. Дійсно, вираз null = null дає значення не ІСТИНА, а НЕВІДОМО. Значить вираз не обов'язково ІСТИНА!

Парадокс 2. Невірно також, що null-значення не рівне самому собі! Дійсно, вираз nullnull також приймає значення не ІСТИНА, а НЕВІДОМО! Означає також, що і термін теж не обов'язково БРЕХНЯ!

Парадокс 3. не обов'язково ІСТИНА. Значить, в тризначній логіці не працює принцип виключеного третього (будь-яке висловлювання або істинно, або неправильно).

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


Потенційні ключі

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

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


  1. Властивістю унікальності – У відношенні не може бути двох різних кортежів, з однаковим значенням .
  2. Властивістю ненадлишковим – Ніяке підмножина в не володіє властивістю унікальності.

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

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

Ставлення може мати кілька потенційних ключів. Традиційно, один з потенційних ключів оголошується первинним, А решта – альтернативними. Відмінності між первинним і альтернативними ключами можуть бути важливі в конкретній реалізації реляційної СУБД, але з точки зору реляційної моделі даних, немає підстав виділяти таким чином один з потенційних ключів.

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


















Табельний номер Прізвище Зарплата
1 Іванов 1000
2 Петров 2000
3 Сидоров 3000

Таблиця 4 Відношення "Співробітники"

При першому погляді на таблицю, що зображає це відношення, може здатися, що в таблиці є три потенційних ключа – в кожній колонці таблиці містяться унікальні дані. Однак серед співробітників можуть бути однофамільці і співробітники з однаковою зарплатою. Табельний же номер по суті свій унікальний для кожного співробітника. Які ж міркування привели нас до розуміння того, що в даному відношенні тільки один потенційний ключ – "Табельний номер"? Саме розуміння змісту даних, що містяться у відношенні.

Спробуємо уявити це відношення в іншому вигляді, змінивши найменування атрибутів:


















A B C
1 Іванов 1000
2 Петров 2000
3 Сидоров 3000

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

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

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


Цілісність сутностей

Оскільки потенційні ключі фактично служать ідентифікаторами об'єктів предметної області (тобто призначені для розрізнення об'єктів), то значення цих ідентифікаторів не можуть містити невідомі значення. Дійсно, якщо б ідентифікатори могли містити null-значення, то ми не могли б дати відповідь "так" або "ні" на питання, збігаються чи ні два ідентифікатора.

Це визначає наступне правило цілісності сутностей:

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


Зовнішні ключі

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

Розглянемо приклад з постачальниками і постачаннями деталей. Припустимо, що нам потрібно зберігати інформацію про найменування постачальників, найменування та кількості поставляються ними деталей, причому кожен постачальник може постачати кілька деталей і кожна деталь може поставлятися декількома постачальниками. Можна запропонувати зберігати дані в такому відношенні:













































Номер постачальника


Найменування постачальника


Номер деталі


Найменування деталі


Поставляється, кількість

1   Іванов 1   Болт 100
1   Іванов 2   Гайка 200
1   Іванов 3   Гвинт 300
2   Петров 1   Болт 150
2   Петров 2   Гайка 250
3   Сидоров 3   Гвинт 1000

Таблиця 5 Відношення "Постачальники і поставляються деталі"

Потенційним ключем цього відношення може виступати пара атрибутів {"Номер постачальника", "Номер деталі"} – у таблиці вони виділені курсивом.

Наведений спосіб зберігання даних має низку недоліків.

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

Далі, як відобразити факт, що деякий постачальник, наприклад Петров, тимчасово припинив постачання деталей? Якщо ми видалимо всі кортежі, у яких зберігається інформація про поставки цього постачальника, то ми втратимо дані про самому Петрові як потенційного постачальника. Вийти з цього положення, залишивши у відношенні кортеж типу (2, Петров, NULL, NULL, NULL) ми не можемо, тому що атрибут "Номер деталі" входить до складу потенційного ключа і не може містити null-значень. Те ж саме станеться, якщо деяка деталь тимчасово не постачається жодним постачальником. Виходить, що ми не можемо зберігати інформацію про те, що є якийсь постачальник, якщо він не постачає хоча б одну деталь, і не можемо зберігати інформацію про те, що є деяка деталь, якщо вона ніким не поставляється.

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

Про те, як правильно нормалізувати відносини, буде сказано в наступних розділах, зараз же запропонуємо рознести дані по трьох відносинам – "Постачальники", "Деталі", "Поставки". Для нас важливо з'ясувати, яким чином дані, що зберігаються в цих відносинах взаємозалежні один з одним. Цей зв'язок визначається семантикою предметної області і описується фразами: "Постачальники виконують Поставки", "Деталі поставляються через Поставки ". Ці дві взаємозв'язку опосередковано визначають новий взаємозв'язок між" Постачальниками "і" Деталями ":" Деталі поставляються Постачальниками ".

Ці фрази відображають різні типи взаємозв'язків. Щоб більш точно відобразити предметну область, можна інакше переформулювати фрази: "Один Постачальник може виконувати кілька Постачань", "Одна Деталь може поставлятися декількома Поставками ". Це приклад взаємозв'язку типу"один-до-багатьох“.

Взаємозв'язок між "Постачальниками" і "Деталями" можна переформулювати так: "Кілька Деталей може поставлятися декількома Постачальниками". Це приклад взаємозв'язку типу "багато-до-багатьох“.

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

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

Таким чином, наш приклад з постачальниками і поставляються деталями повинен виглядати наступним чином:















Номер постачальника


Найменування постачальника

1   Іванов
2   Петров
3   Сидоров

Таблиця 6 Відношення "Постачальники"















Номер деталі


Найменування деталі

1   Болт
2   Гайка
3   Гвинт

Таблиця 7 Відношення "Деталі"































Номер постачальника


Номер деталі


Поставляється, кількість

1   1   100
1   2   200
1   3   300
2   1   150
2   2   250
3   3   1000

Таблиця 8 Відношення "Поставки"

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

Дамо точне визначення.

Визначення 2. Нехай дано ставлення . Підмножина атрибутів відносини будемо називати зовнішнім ключем, Якщо:


  1. Існує ставлення ( і не обов'язково різні) з потенційним ключем .
  2. Кожне значення у відношенні завжди збігається зі значенням для деякого кортежу з , Або є null-значенням.

Ставлення називається батьківським ставленням , Ставлення називається дочірнім ставленням .

Зауваження. Зовнішній ключ, також як і потенційний, може бути простим і складеним.

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

Зауваження. Зовнішній ключ, як правило, не володіє властивістю унікальності. Так і повинно бути, тому що в дочірньому відношенні може бути кілька кортежів, які посилаються на один і той же кортеж батьківського ставлення. Це, власне, і дає тип ставлення "один-до-багатьох".

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

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

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

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


Цілісність зовнішніх ключів

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

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


Зауваження до правил цілісності сутностей і зовнішніх ключів

Насправді наведені правила цілісності сутностей і зовнішніх ключів прямо випливають з визначень понять "потенційний ключ" і "зовнішній ключ".

Дійсно, у визначенні потенційного ключа потрібно, щоб потенційний ключ володів властивістю унікальності. Це фактично означає, що ми повинні вміти розрізняти значення потенційних ключів, тобто при порівнянні двох значень потенційного ключа ми завжди повинні отримувати значення або TRUE, або FALSE. Але будь-яке порівняння, в яке входить null-значення, приймає значення U – НЕВІДОМО, звідки випливає, що атрибути потенційного ключа не можуть містити null-значень.

Для зовнішніх ключів правило цілісності фактично входить у визначення (п. 2 визначення 2).

Таким чином, з точки зору реляційної теорії, явна формулювання правил цілісності є зайвою – вони автоматично випливають з визначень понять ключа та зовнішнього ключа.

Тим не менш, явна формулювання правил цілісності має певний практичний сенс. У більшості серйозних СУБД за виконанням цих обмежень стежить сама СУБД, якщо, звичайно, користувач явно оголосив потенційні і зовнішні ключі. Але, по-перше, для деяких систем можна допустити, щоб ці обмеження не виконувалися, а по-друге, деякі системи просто не підтримують поняття цілісності, наприклад, деякі "настільні" СУБД типу FoxPro 2.5. У цих випадках за цілісністю даних повинен стежити сам користувач, або програміст, який розробляє додаток для користувача.

Явна формулювання правил цілісності допомагає чітко зрозуміти, які небезпеки несе в собі зневага цими правилами.


Операції, що можуть порушити посилальну цілісність

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


Для батьківського ставлення



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



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



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


    Для дочірнього відносини



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



      • Оновлення кортежу в дочірньому відношенні
        При оновленні кортежу в дочірньому відношенні можна спробувати некоректно змінити значення зовнішнього ключа. Оновлення кортежу в дочірньому відношенні може привести до порушення посилальної цілісності.



      • Видалення кортежу в дочірньому відношенні
        При видаленні кортежу в дочірньому відношенні посилальна цілісність не порушується.

      Таким чином, посилальна цілісність у принципі може бути порушена при виконанні однієї з чотирьох операцій:


      • Оновлення кортежу в батьківському відношенні.
      • Видалення кортежу в батьківському відношенні.
      • Вставка кортежу в дочірнє відношення.
      • Оновлення кортежу в дочірньому відношенні.

      Стратегії підтримки посилальної цілісності

      Існують дві основні стратегії підтримки посилальної цілісності :


      • RESTRICT (ОБМЕЖИТИ) – Не дозволяти виконання операції, що призводить до порушення посилальної цілісності. Це сама проста стратегія, що вимагає тільки перевірки, чи є кортежі в дочірньому відношенні, пов'язані з деякими кортежем в батьківському відношенні.
      • CASCADE (каскадувати) – Дозволити виконання необхідної операції, але внести при цьому необхідні поправки в інших відносинах так, щоб не допустити порушення посилальної цілісності і зберегти всі наявні зв'язки. Зміна починається в батьківському відношенні і каскадно виконується в дочірньому відношенні. У реалізації цієї стратегії є одна тонкість, яка полягає в тому, що дочірнє ставлення саме може бути батьківським для деякого третій відносини. При цьому може додатково знадобитися виконання будь-якої стратегії і для цього зв'язку і т.д. Якщо при цьому будь-яка з каскадних операцій (будь-якого рівня) не може бути виконана, то необхідно відмовитися від первинної операції і повернути базу даних у вихідний стан. Це найскладніша стратегія, але вона хороша тим, що при цьому не порушується зв'язок між кортежами батьківського і дочірнього відносин.

      Ці стратегії є стандартними і присутні у всіх СУБД, в яких є підтримка посилальної цілісності.

      Можна розглянути додаткові стратегії підтримки посилальної цілісності :


      • SET NULL (ВСТАНОВИТИ В NULL) – Дозволити виконання необхідної операції, але всі виникаючі некоректні значення зовнішніх ключів змінювати на null-значення. Ця стратегія має два недоліки. По-перше, для неї потрібно допустити використання null-значень. По-друге, кортежі дочірнього відносини втрачають будь-який зв'язок з кортежами батьківського відношення. Встановити, з яким кортежем батьківського відносин були пов'язані змінені кортежі дочірнього відносини, після виконання операції вже не можна.
      • SET DEFAULT (ВСТАНОВИТИ за умовчанням) – Дозволити виконання необхідної операції, але всі виникаючі некоректні значення зовнішніх ключів змінювати на деяке значення, прийняте за умовчанням. Гідність цієї стратегії в порівнянні з попередньою в тому, що вона дозволяє не користуватися null-значеннями. Недоліки полягають в наступному. По-перше, в батьківському відношенні має бути якийсь кортеж, потенційний ключ якого прийнятий як значення за замовчуванням для зовнішніх ключів. В якості такого "кортежу за замовчуванням" зазвичай беруть спеціальний кортеж, заповнений нульовими значеннями (не null-значеннями!). Цей кортеж не можна видаляти з батьківського відносини, і в цьому кортежі не можна змінювати значення потенційного ключа. Таким чином, не всі кортежі батьківського відношення стають рівнозначними, тому доводиться докладати додаткових зусиль для відстеження цієї нерівнозначності. Це плата за відмову від використання null-значень. По-друге, як і в попередньому випадку, кортежі дочірнього відносини втрачають будь-який зв'язок з кортежами батьківського відносини. Встановити, з яким кортежем батьківського відносин були пов'язані змінені кортежі дочірнього відношення, після виконання операції вже не можна.

      У деяких реалізація СУБД розглядається ще одна стратегія підтримки посилальної цілісності :


      • IGNORE (ігнорувати) – Виконувати операції, не звертаючи уваги на порушення посилальної цілісності.

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

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


      Застосування стратегій підтримки посилальної цілісності

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


      При оновленні кортежу в батьківському відношенні

      Допустимі стратегії:

      RESTRICT (ОБМЕЖИТИ) – Не дозволяти оновлення, якщо є хоча б один кортеж в дочірньому відношенні, що посилається на оновлюваний кортеж.

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

      SET NULL (ВСТАНОВИТИ В NULL) – Виконати оновлення і у всіх кортежі дочірнього відношення, що посилаються на оновлюваний кортеж, змінити значення зовнішніх ключів на null-значення.

      SET DEFAULT (ВСТАНОВИТИ за умовчанням) – Виконати оновлення і у всіх кортежі дочірнього відношення, що посилаються на оновлюваний кортеж, змінити значення зовнішніх ключів на деяке значення, прийняте за умовчанням.

      IGNORE (ігнорувати) – Виконати оновлення, не звертаючи уваги на порушення посилальної цілісності.


      При видаленні кортежу в батьківському відношенні

      Допустимі стратегії:

      RESTRICT (ОБМЕЖИТИ) – Не дозволяти видалення, якщо є хоча б один кортеж в дочірньому відношенні, що посилається на видаляється кортеж.

      CASCADE (каскадувати) – Виконати видалення і каскадно видалити кортежі в дочірньому відношенні, що посилаються на видаляється кортеж.

      SET NULL (ВСТАНОВИТИ В NULL) – Виконати видалення і у всіх кортежі дочірнього відношення, що посилаються на видаляється кортеж, змінити значення зовнішніх ключів на null-значення.

      SET DEFAULT (ВСТАНОВИТИ за умовчанням) – Виконати видалення і у всіх кортежі дочірнього відношення, що посилаються на видаляється кортеж, змінити значення зовнішніх ключів на деяке значення, прийняте за умовчанням.

      IGNORE (ігнорувати) – Виконати видалення, не звертаючи уваги на порушення посилальної цілісності.


      При вставці кортежу в дочірнє відношення

      Допустимі стратегії:

      RESTRICT (ОБМЕЖИТИ) – Не дозволяти вставку, якщо зовнішній ключ у вставляється кортежі не відповідає жодному значенню потенційного ключа батьківського ставлення.

      SET NULL (ВСТАНОВИТИ В NULL) – Вставити кортеж, але як значення зовнішнього ключа занести не пропоноване користувачем некоректне значення, а null-значення.

      SET DEFAULT (ВСТАНОВИТИ за умовчанням) – Вставити кортеж, але як значення зовнішнього ключа занести не пропоноване користувачем некоректне значення, а деяке значення, прийняте за умовчанням.

      IGNORE (ігнорувати) – Вставити кортеж, не звертаючи уваги на порушення посилальної цілісності.


      При оновленні кортежу в дочірньому відношенні

      Допустимі стратегії:

      RESTRICT (ОБМЕЖИТИ) – Не дозволяти оновлення, якщо зовнішній ключ в оновлюваному кортежі стає не відповідним жодному значенню потенційного ключа батьківського ставлення.

      SET NULL (ВСТАНОВИТИ В NULL) – Оновити кортеж, але як значення зовнішнього ключа занести не пропоноване користувачем некоректне значення, а null-значення.

      SET DEFAULT (ВСТАНОВИТИ за умовчанням) – Оновити кортеж, але як значення зовнішнього ключа занести не пропоноване користувачем некоректне значення, а деяке значення, прийняте за умовчанням.

      IGNORE (ігнорувати) – Оновити кортеж, не звертаючи уваги на порушення посилальної цілісності.


      Висновки

      Сучасні СУБД допускають використання null-значень, Тому що дані часто бувають неповними або невідомими. Спори про допустимість використання null-значень ведуться до цих пір. Використання null-значення пов'язане із застосуванням тризначної логіки ( three-valued logic , 3VL ).

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

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

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

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

      Відносини зв'язуються один з одним за допомогою зовнішніх ключів.

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

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

      Зв'язки типу "багато-до-багатьох"Реалізуються використанням декількох відносин типу" один-до-багатьох ".

      У будь-якої реляційної бази даних повинні виконуватися два обмеження:


      • Цілісність сутностей
      • Цілісність зовнішніх ключів

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

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

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

      Для підтримки посилальної цілісності зазвичай використовуються дві основні стратегії:


      • RESTRICT (ОБМЕЖИТИ) – Не дозволяти виконання операції, що призводить до порушення посилальної цілісності.
      • CASCADE (каскадувати) – Дозволити виконання необхідної операції, але внести каскадні зміни в інші відносини так, щоб не допустити порушення посилальної цілісності.

      Додатковими стратегіями підтримки посилальної цілісності є:


      • SET NULL (ВСТАНОВИТИ В NULL) – Всі некоректні значення зовнішніх ключів змінювати на null-значення.
      • SET DEFAULT (ВСТАНОВИТИ за умовчанням) – Всі некоректні значення зовнішніх ключів змінювати на деяке значення, прийняте за умовчанням.

      У реальних СУБД можна також відмовитися від використання будь-якої стратегії підтримки посилальної цілісності:


      • IGNORE (ігнорувати) – Виконувати операції, не звертаючи уваги на порушення посилальної цілісності.

      Користувач може розробити свою унікальну стратегію підтримки посилальної цілісності.

      Схожі статті:


      Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

      Коментарів поки що немає.

      Ваш отзыв

      Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

      *

      *