КЛЮЧІ в реляційної моделі

Як було відзначено в розділі 91, в реляційної моделі завжди надавалося велике значення поняттю ключів, хоча, як було показано вище, ключі фактично являють собою лише окремий випадок більш загального феномена (нехай навіть і важливий з точки зору практики) У цьому розділі розглядаються саме ключі

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

Припустимо, що R – мінлива відносини За визначенням, безліч всіх атрибутів R має властивість унікальності це означає, що в будь-який конкретний момент часу ніякі два кортежу у значенні R не є дублікатами один одного На практиці часто зустрічається ситуація, в якій певне власне підмножина множини всіх атрибутів R також має властивість унікальності, наприклад, у випадку змінної відносини постачальників S такою властивістю володіє підмножина, що містить тільки атрибут s # На підставі цих міркувань може бути сформульовано наведене нижче неформальне визначення, продиктоване інтуіціей3

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

а)Унікальність Жодне допустиме значення R ніколи не містить два різних кортежу з одним і тим же значенням к

б)Нескоротних Ніяке суворе підмножина до не має властивість унікальності

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

13 Слід зазначити, що це визначення стосується саме змінних відносини аналогічне поняття може бути також визначено для значень відносини [33], але змінні відносини – найбільш важливий випадок Заслуговує також на увагу те, що і в цьому випадку ми виходимо з поняття рівності кортежів (точніше, це поняття застосовується у визначенні властивості унікальності)

ключа для постачальників визначена комбінація атрибутів {S #, CITY} замість одного тільки атрибута {S #} У такому випадку система не могла б стежити за дотриманням обмеження, згідно з яким номера постачальників є глобально унікальними, а володіла б здатністю контролювати тільки слабшу обмеження, яке у тому, що номери постачальників є унікальними локально, в межах одного міста Крім усього іншого, з цієї причини в наведеному вище визначенні потрібно, щоб потенційні ключі не містили жодних атрибутів, які не забезпечують вирішення завдання унікальною ідентіфікаціі14

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

У мові Tutorial D для визначення потенційного ключа розглянутої змінної відносини в оголошенні змінної відносини використовується наступний синтаксис

KEY  {  &ltattribute name commalist&gt  }

Нижче наведено ще кілька прикладів

VAR S BASE RELATION

{ S#    S#, SNAME

NAME, STATUS INTEGER, CITY

CHAR } KEY { S# }

;

Примітка У попередніх розділах це визначення було приведено з конструкцією PRIMARY KEY, а не з неуточненої конструкцією KEY Додаткові описи та пояснення дано у підрозділі Первинні та альтернативні ключі даного розділу

VAR SP BASE RELATION { S# S#, P#  P#, QTY QTY }

KEY { S#, P# } ..

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

VAR ELEMENT BASE RELATION { NAME    NAME, SYMBOL  CHAR, ATOMIC# INTEGER } KEY { NAME } KEY { SYMBOL } KEY { ATOMIC# }

14 Ще одна суттєва причина, по якій потенційні ключі повинні бути нескоротних, полягає в наступному: будь-який зовнішній ключ, який посилається на скоротних потенційний ключ (Якби це було можливо), також був би скоротних, і тому містить його мінлива відносини майже напевно порушувала б принципи подальшої нормалізації, як буде описано в главі 12

У цьому прикладі показана змінна відносини з кількома різними потенційними ключами, причому всі вони є простими

VAR MARRIAGE BASE RELATION { HUSBAND                                                                                                                          NAME, WIFE                                                                                                                                                                 NAME, DATE / * Дата реєстрації шлюбу * / DATE

}

/ * Передбачається, що у всіх розглянутих шлюбах відсутні такі * /

/ * Ситуації, як многомужіе, багатоженство і повторна реєстрація шлюбу * /

/ * Одних і тих же подружжя після їхнього розлучення .. * / KEY {HUSBAND, DATE}

KEY { DATE, WIFE } KEY

{ WIFE, HUSBAND }

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

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

S  WHERE   S#   =   S#    (S3)

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

S  WHERE  CITY   =    Paris,

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

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

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

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

питань, як оновлення уявлень і оптимізація (ці теми розглядаються,

відповідно, в главах 10 і 18)

На завершення цього розділу наведемо кілька зауважень

■ Потенційні ключі повинні мати не тільки базові змінні стосунки

Ця вимога поширюється на всі змінні відносини, включаючи, в приватно сті, уявлення Але що стосується, наприклад, уявлень, питання про те, чи можуть або повинні бути оголошені такі ключі, почасти залежить від того, предусмот рена чи в системі можливість іспользоватьссилкі на потенційний ключ [33]

■ Надмножество потенційного ключа називається суперключом (Наприклад, супер ключем для змінної відносини S є безліч атрибутів {S #, CITY}) Суперключ має властивість унікальності, але не обовязково володіє свойст вом нескоротних Безумовно, потенційний ключ – це окремий випадок су перключа

■ Якщо SK – суперключ для змінної відношення R, а А – атрибут R, то в R зобовязань тельно існує функціональна залежність SK А Насправді, ми можемо визначити суперключ як підмножина SK атрибутів R, таке що функ нальних залежність SK А має місце для всіх атрибутів А в R

Примітка Важливе поняття функціональної залежності докладно розглядається в розділі 11

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

Первинні та альтернативні ключі

Як вже було сказано вище, в будь-якої змінної відносини можлива наявність двох або більшої кількості потенційних ключів У такому випадку в реляційної моделі традиційно предявлялося така вимога (Щонайменше, до базових змінним відносини), щоб точно один з цих ключів був обраний як первинного ключа з тих пір інші ключі називалися альтернативними Наприклад, у разі визначення таблиці елементів Менделєєва, ELEMENT, МОЖНА вибрати {SYMBOL} як первинного ключа, після чого застосовувати {NAME} і {АТОМ1С #} як альтернативні ключі При наявності навіть одного потенційного ключа в реляційної моделі за традицією предявлялося вимога, щоб цей потенційний ключ розглядався як первинний ключ для даної базової змінної відносини Тому вважалося, що кожна базова змінна відносини завжди має первинний ключ

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

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

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

Неформально висловлюючись, зовнішній ключ являє собою безліч атрибутів деякої змінної відносини R2, значення яких повинні збігатися зі значеннями деякого потенційного ключа деякої змінної відносини R1 Наприклад, розглянемо безліч атрибутів {S #} змінної відносини SP Повинно бути ясно, що задане значення {S #} може бути присутнім у змінній відносини SP, тільки якщо таке ж значення присутній і в змінної відносини S як значення єдиного потенційного ключа {S #} (оскільки поставка не може бути виконана неіснуючим постачальником) Аналогічним чином, будь-яке конкретне значення для безлічі атрибутів {Р #} може бути присутнім у змінній відносини SP, тільки якщо таке ж значення присутній у змінній відносини Р як значення єдиного потенційного ключа {Р #} (Оскільки не може бути також виконана поставка неіснуючої деталі) На підставі цих прикладів може бути сформульовано наведене нижче определеніе15

■ Припустимо, що R2 – мінлива відносини У такому випадку зовнішнім ключем в R2 є безліч атрибутів R2, скажімо, FK, таке що виконуються такі вимоги:

а) існує змінна відносини Rl (R1 і R2 не обовязково повинні бути різними) з потенційним ключем ск

б) існує можливість перейменування деякогопідмножини атрибутів FK, таке що FK перетвориться (скажімо) в FK ■, a FK і ск відносяться до одного і того ж типу (кортежу)

в) в будь-який час кожне значення FK в поточному значенні R2 призводить до отри нию значення для FK , ідентичним до значенням СК в деякому кортежі в поточному значенні R1

З цього випливають наведені далі висновки

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

2 Слід зазначити, що кожне значення FK має бути присутнім в якості зна чення CK, але зворотне вимога не предявляється це означає, що R1 може

15 Зверніть увагу на те, що це визначення також базується на понятті рівності кортежів

Глава 9 Цілісність даних361

містити значення ск, яке в даний час не присутній в R2 як значення FK Наприклад, а разі постачальників і деталей (приклади значень в цій базі даних наведено на рис 38 на стор 119) номер постачальника S5 присутній у змінній відносини S, але не в змінної відносини SP, оскільки постачальник S5 в даний час не постачає будь-яких деталей

3 Зовнішній ключ FK є простим або складовим залежно від того, являють ся чи простим або складеним потенційний ключ CK

4 Будь-яке значення FK являє собою посилання на кортеж, що містить відпо вующее значення СК (він називається кортежем, згаданим у засланні) Обмеження, згідно з яким значення FK повинні відповідати значенням СК, називає ся обмеженням посилальної цілісності Мінлива відносини R2 називається посилається змінної відносини, а змінна відносини R1 – змінної відносини, зазначеної в посиланням Завдання забезпечення того, щоб база даних не включала яких-небудь недопустимих значень зовнішнього ключа, називається заду чий підтримки посилальної цілісності (Див п 12)

5 Розглянемо ще раз базу даних постачальників і деталей Обмеження посилальної цілісності в цій базі даних можна представити за допомогою наступної посилальної діаграми

S ← SP Р

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

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

s # Р # S ← SPР

Але в даній книзі подібні мітки показані тільки в тих випадках, якщо їх відсутність може призвести до плутанини або до неоднозначності

6 Будь конкретна змінна відносини може бути одночасно і зазначеної на засланні, й посилається, як у випадку змінної відносини R2, показаної нижче

R3  R2   →  R1

Взагалі кажучи, припустимо, що існують змінні відносини Rn, R (n-1),

…, R2, R1, такі що є обмеження посилальної цілісності, що звязує Rn з R (nl), обмеження посилальної цілісності, що звязує R (nl) з R (n-2), .., і обмеження посилальної цілісності, що звязує R2 з R1 таким чином

Rn→   R(n-l)    →  R(n-2)    →  .. → R2  →  R1

16 Інший спосіб (який, можливо, є кращим) передбачає присвоювання імен зовнішнім ключам, а потім використання цих імен для позначення стрілок

У такому випадку ланцюжок стрілок, що проходить від Rn до R1, являє собою контрольний шлях від Rn до R1

7 Слід зазначити, що змінні відносини R1 і R2, зазначені у визначенні зовнішнього ключа, не обовязково повинні бути різними Це означає, що будь-яка змінна відносини може мати зовнішній ключ, значення якого повинні збігатися зі значеннями деякого потенційного ключа в тієї ж змінної відносини Як приклад розглянемо наступне визначення змінної відносини (його синтаксис буде описаний трохи пізніше, але в будь-якому випадку він повинен бути досить очевидним)

VAR EMP BASE RELATION

{ОМР # ОМР #, .., MGR_EMP # EMP #, ..}

KEY {ОМР #} FOREIGN KEY {RENAME MGR_EMP # AS EMP #}

REFERENCES EMP

Тут атрибут MGR_EMP # позначає табельний номер керівника того службовця, який позначений атрибутом ОМР # наприклад, кортеж ОМР для службовця Е4 може включати значення MGR_EMP # ЕЗ, рівне ЕЗ, яке являє собою посилання на кортеж ОМР для службовця ЕЗ (Як було обіцяно в п 1, тут показаний приклад, в якому потрібен якийсь явне перейменування атрибута) Змінні відносини, подібні ОМР, іноді називають посилаються самі на себе (Або самоссилающіміся)

Вправа Підготуйте дані, які могли б використовуватися як приклад значення змінної відносини ОМР

8 Самоссилающіеся змінні відносини фактично представляють окремий випадок більш загальної ситуації, а саме, вони показують, що можуть існувати посилальні цикли Змінні відносини Rn, R (nl), R (n-2), .., R2, Rl утворюють такий цикл, якщо Rn містить зовнішній ключ, що посилається на R (nl), a R (nl) містить зовнішній ключ, що посилається на R (n-2), .., і тд, нако нец, R1 містить зовнішній ключ, знову посилається на Rn Коротко можна сформулювати це визначення таким чином, що контрольний цикл існує, якщо є контрольний шлях від деякої змінної відносини Rn до неї са мій, як показано нижче

Rn R(n-l)  R(n-2)  →  .. R2 → Rl Rn

9 Іноді зустрічається таке небезпідставні твердження, що узгодженість зовнішніх і потенційних ключів являє собою свого роду клей, кото рий скріплює воєдино всю базу даних Ще один спосіб формулювання тієї ж ідеї полягає в тому, що подібні узгодження являють собою певні звязки Але необхідно враховувати важливе зауваження, що не всі такі звязки визна лени лише ключами, які застосовуються зазначеним способом Наприклад, мо же існувати певний звязок між постачальниками і деталями (знаходження в одному місті), для представлення якої застосовуються атрибути CITY пере сних відносини S і Р деякий постачальник і деяка деталь вважаються на ходячи в одному місті, якщо даний постачальник знаходиться в тому ж місті, де зберігається дана деталь Але цей звязок не визначена за допомогою ключів

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

11 У визначенні реляційної моделі спочатку предявлялося вимога, щоб зовнішні ключі посилалися саме лише на первинні ключі, а не просто на будь-які потенційні ключі (наприклад, ще раз рекомендуємо ознайомитися з [99]) Автор в цілому відкидає це обмеження як непотрібне і взагалі небажану тельное, хоча на практиці воно може часто служити гарною рекомендацією [914]

12 Поряд з поняттям зовнішнього ключа в реляційної моделі визначено наведено ве нижче правило (правило посилальної цілісності)

Посилальна цілісність База даних не повинна містити будь-яких неузгоджених значень зовнішнього ключа17

У цьому визначенні термін неузгоджене значення зовнішнього ключа позначає значення зовнішнього ключа в деякій посилається змінної відносини, для якого не існує узгодженого значення відповідного потенційного ключа в відповідної змінної відносини, зазначеної на засланні Іншими словами, це обмеження можна сформулювати просто як таку вимогу: Якщо значення в посилається на А, то А має існувати .

Нижче показаний синтаксис визначення зовнішнього ключа

FOREIGN KEY   {   &ltitem  commalist&gt   }   REFERENCES  &ltrelvar name&gt

Ця конструкція присутній у визначенні посилається змінної відносини тут &ltrelvar name&gt позначає змінну відносини, зазначену на засланні, а кожен елемент em&gt являє собою або імя атрибута &ltattribute name&gt в посилається змінної відносини, або вираз в наступній формі

RENAME  &ltattribute name&gt  AS  &ltattribute name&gt

(Приклад застосування варіанту з використанням ключового слова RENAME приведений у визначенні самоссилающейся змінної відносини ОМР в п 7) Приклади оголошень зовнішнього ключа були приведені вище в багатьох розділах даної книги (зокрема, див рис 39 в розділі 3) Безумовно, як було зазначено в розділі 92, визначення зовнішнього ключа фактично являє собою просто скорочення для деякого обмеження бази даних (або для деякого обмеження змінної відносини, в

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

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

Посилальні дії

Розглянемо наступний оператор на мові Tutorial D

DELETE S WHERE S# = S# (S1)

Припустимо, що операція DELETE виконує саме те, що в ній зазначено, тобто видаляє кортеж постачальника si, не більше і не менше Припустимо також, що дотримуються ще дві умови: по-перше, база даних включає відомості про постачання, виконаних постачальником S1, по-друге, програма не видаляє ці відомості про постачання Але після того як система перевіряє обмеження посилальної цілісності, яке повязує дані про поставку з даними про постачальників, вона виявляє порушення і активізує виняток

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

VAR SP BASE RELATION { .. } ..

FOREIGN KEY { S# } REFERENCES S

ON DELETE CASCADE

Специфікація ON DELETE CASCADE визначає правило видалення для даного конкретного зовнішнього ключа, а специфікація CASCADE є посилальним дією для цього правила видалення Сенс даних специфікацій полягає в тому, що виконання операції DELETE на змінної відносини постачальників каскадно призводить до видалення також відповідних кортежів (Якщо вони є) у змінній відносини поставок

Ще одним широко застосовуваним варіантом посилального дії є RESTRICT (воно не має нічого спільного з операцією скорочення реляційної алгебри) У цьому випадку використання ключового слова RESTRICT означає, що операції DELETE повинні обмежуватися тими ситуаціями, в яких відсутні узгоджені поставки (в іншому випадку вони будуть відкинуті) Якщо ж у визначенні конкретного зовнішнього ключа посилальне дія не вказано, це еквівалентно застосуванню ключового слова NO ACTION, яке означає саме те, що в ньому сказано: операція DELETE виконується точно так само, як в ній зазначено, не більше і не менше (Якщо в ситуації, що розглядається задано ключове слово NO ACTION, а з видаляються даними про постачальника повязані узгоджені дані про постачання, то надалі виникає порушення обмеження посилальної цілісності, тому кінцевий результат

стає аналогічним такому, як при використанні ключового слова RESTRICT)

З цього випливають наведені нижче висновки

1 Операція DELETE не є єдиною операцією, для якої має сенс визначати посилальні дії Наприклад, що відбудеться при спробі обно вити номер такого постачальника, для якого існує щонайменше одна узгоджена поставка Очевидно, що потрібно не тільки правило видалення, але і правило оновлення Загалом існують такі ж варіанти посилальних дейст вий для операції UPDATE, як і для операції DELETE, які описані нижче

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

■ RESTRICT Дія операції UPDATE обмежується тим випадком, коли від сутствуют такі узгоджені поставки (в іншому випадку ця операція від Вергал)

■ NO ACTION Операція UPDATE виконується в точній відповідності з зазначенням ем (але в подальшому може відбутися порушення посилальної цілісності)

2 Безумовно, CASCADE, RESTRICT і NO ACTION не є єдиними віз можна посилальними діями вони просто відносяться до таких типів, які часто потрібні на практиці А в принципі може існувати довільне до лічество допустимих відповідей (наприклад) на спробу видалити дані про деяке постачальника Нижче наведено кілька прикладів

■ Така спроба може бути з певної причини відразу ж відкинута

■ Інформація може бути записана в деяку архівну базу даних

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

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

3 Припустимо, що R2 і R1, відповідно, – посилається змінна отноше ня і повязана з нею змінна відносини, зазначена в засланні, як показано нижче

R2  R1

Припустимо, що в застосовуваному правилі видалення задано дію CASCADE У такому випадку виконання операції DELETE над зазначеним кортежем R1 тягне за собою (в загальному) виконання операції DELETE над деякими кортежами змінної відносини R2 Якщо ж тепер припустити, що на змінну відносини R2, в

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

R3   →  R2   →   R1

Це означає, що результати виконання останньої операції залежать від того, яке правило видалення визначено для обмеження посилальної цілісності, спрямованого від R3 до R2 Якщо ця подразумеваемая операція DELETE завершується невдачею (згідно з правилом видалення, яке повязує R3 з R2, або по какойлибо іншої причини), то закінчиться невдачею вся операція і база даних залишається незмінною Подібна процедура поширюється рекурсивно на будь-яку кількість рівнів

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

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

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

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


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

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

Ваш отзыв

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

*

*