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

У другій частині реляційної моделі даних визначаються два обмеження, які повинні виконуватися в будь-якій реляційній базі даних. Це:
Цілісність сутностей
Цілісність зовнішніх ключів.
Перш, ніж говорити про цілісність сутностей, опишемо використовування null-значень в реляційних базах даних.
Null-значення
Основне призначення баз даних полягає в тому, щоб зберігати і надавати інформацію про реальний світ. Для представлення цієї інформації в базі даних використовуються звичні для програмістів типи даних - рядкові, чисельні, логічні і т.п. Проте в реальному світі часто зустрічається ситуація, коли дані невідомі або не повні. Наприклад, місце проживання або дата народження людини можуть бути невідомі (база даних розшукуваних злочинців). Якщо замість невідомої адреси доречно б був вводити порожній рядок, то що вводити замість невідомої дати? Відповідь - порожню дату - не цілком задовільний, оскільки найпростіший запит "видати список людей в порядку зростання дат народження" дасть явно неправильних відповідь.
Для того, щоб обійти проблему неповних або невідомих даних, в базах даних можуть використовуватися типи даних, поповнені так званим null-значенням. Null-значення - це, власне, не значення, а якийсь маркер, що показує, що значення невідоме.
Таким чином, за ситуації, коли можлива поява невідомих або неповних даних, розробник має на вибір два варіанти.
Перший варіант полягає в тому, щоб обмежитися використовуванням звичних типів даних і не використати null-значення, а замість невідомих даних вводити або нульові значення, або значення спеціального вигляду - наприклад, домовитися, що рядок "АДРЕСА НЕВІДОМА" і є ті дані, які потрібно вводити замість невідомої адреси. У будь-якому випадку на користувача (або на розробника) лягає відповідальність на правильне трактування таких даних. Зокрема, може бути потрібно написання спеціального програмного коду, який в потрібних випадках "виловлював" би такі дані. Проблеми, що виникають при цьому очевидні - не всі дані стають рівноправні, потрібен додатковий програмний код, що "відстежує" цю нерівноправність, внаслідок чого ускладнюється розробка і супровід додатків.
Другий варіант полягає у використовуванні null-значень замість невідомих даних. За уявною природністю такого підходу ховаються менш очевидні і більш глибокі проблеми. Самою впадаючою в очі проблемою є необхідність використовування тризначної логіки при операції з даними, які можуть містити null-значення. В цьому випадку при неакуратному формулюванні запитів, навіть найприродніші запити можуть давати неправильні відповіді. Є більш фундаментальні проблеми, пов'язані з теоретичним обгрунтовуванням коректності введення null-значень, наприклад, незрозуміло взагалі, чи входять null-значення в домени чи ні.
Докладне обговорення проблем використовування null-значень виходить за межі даної роботи. Можна тільки сказати про те, що це питання в теорії реляційних баз даних остаточно не вирішено. Основоположник реляційного підходу Кодд рахував null-значення невід'ємною частиною реляційної моделі. К.Дейт, один з найбільших теоретиків реляційної моделі виступає категорично проти null-значень (докладне обговорення проблем, що виникають при використовуванні null-значень приведено в книзі [11].
Практично всі реалізації сучасних реляційних СУБД дозволяють використовувати 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 | Іванов | 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. Хай дано відношення . Підмножина атрибутів відносини називатимемо зовнішнім ключем, якщо:
Існує відношення ( і не обов'язково різні) з потенційним ключем .
Кожне значення у відношенні завжди співпадає із значенням для деякого кортежу з , або є null-значенням.
Відношення називається батьківським відношенням, відношення називається дочірнім відношенням.
Зауваження. Зовнішній ключ, також як і потенційний, може бути простим і складовим.
Зауваження. Зовнішній ключ повинен бути визначений на тих же доменах, що і відповідний первинний ключ батьківського відношення.
Зауваження. Зовнішній ключ, як правило, не володіє властивістю унікальності. Так і повинно бути, оскільки в дочірньому відношенні може бути декілька кортежів, що посилаються на один і той же кортеж батьківського відношення. Це, власне, і дає тип відношення "один-до-багатьох".
Зауваження. Якщо зовнішній ключ все-таки володіє властивістю унікальності, то зв'язок між відносинами має тип "один-до-одного". Частіше за все такі відносини об'єднуються в одне відношення, хоча це і не обов'язково.
Зауваження. Хоча кожне значення зовнішнього ключа зобов'язано співпадати із значеннями потенційного ключа в деякому кортежі батьківського відношення, те зворотне, взагалі кажучи, невірне. Наприклад, можуть існувати постачальники, що не поставляють ніяких деталей.
Зауваження. Для зовнішнього ключа не вимагається, щоб він був компонентом деякого потенційного ключа (як вийшло в прикладі з постачальниками і деталями).
Зауваження. Null-значення для атрибутів зовнішнього ключа допустимі тільки у тому випадку, коли атрибути зовнішнього ключа не входять до складу ніякого потенційного ключа
Цілісність зовнішніх ключів
Оскільки зовнішні ключі фактично служать посиланнями на кортежі в іншому (або в тому ж самому) відношенні, то ці посилання не повинні указувати на неіснуючі об'єкти. Це визначає наступне правило цілісності зовнішніх ключів:
Правило цілісності зовнішніх ключів. Зовнішні ключі не повинні бути неузгоджено, тобто для кожного значення зовнішнього ключа повинне існувати відповідне значення первинного ключа в батьківському відношенні.
Зауваження до правил цілісності сутностей і зовнішніх ключів
Насправді приведені правила цілісності сутностей і зовнішніх ключів прямо виходять з визначень понять "потенційний ключ" і "зовнішній ключ".
Дійсно, у визначенні потенційного ключа вимагається, щоб потенційний ключ володів властивістю унікальності. Це фактично означає, що ми повинні уміти розрізняти значення потенційних ключів, тобто при порівнянні двох значень потенційного ключа ми завжди повинні набувати значення або ІСТИНА, або БРЕХНЯ. Але будь-яке порівняння, в яке входить 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 (ІГНОРУВАТИ) - виконувати операції, не звертаючи уваги на порушення посилальної цілісності.
Користувач може розробити свою унікальну стратегію підтримки посилальної цілісності.

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать