Як називається ключ підлеглої таблиці. Ключі та індекси


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

У цьому розділі, ви досліджуватимете довідкову цілісність більш докладно і з'ясуємо все щодо обмежень, які ви можете використовувати для її підтримування. Ви також побачите, як наказує- це обмеження коли ви використовуєте команди модифікації DML. Оскільки довідкова цілісність включає зв'язок полів або груп полів, часто в різних таблицях, ця дія може бути дещо складнішою за інші обмеження. З цієї причини добре мати з нею повне знайомство, навіть якщо ви не плануєте створювати таблиці. Ваші команди модифікації можуть стати ефективнішими за допомогою обмеження довідкової цілісності (як і за допомогою інших обмежень, але обмеження довідкової цілісності може впливати на інші таблиці крім тих, у яких воно визначено), а певні функції запиту, такі як об'єднання, багаторазово структуровані в термінах зв'язків довідкової цілісності (як наголошувалося на Главі 8).

ЗОВНІШНІЙ КЛЮЧ І БАТЬКІВСЬКИЙ КЛЮЧ

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

Коли одне поле таблиці посилається інше, воно називається - зовнішнім ключем; а поле на яке воно посилається, називається – батьківським ключем. Отже, поле snum таблиці Замовників - це зовнішній ключ, а поле snum на яке воно посилається в таблиці Продавців - це батьківський ключ.

Аналогічно, підлога cnum та snum таблиці Порядків - це зовнішні ключі, які посилаються до їхніх батьківських ключів з іменами в таблиці Замовників та таблиці Продавців. Імена зовнішнього ключа і батьківського ключа не обов'язково повинні бути однаковими, це - лише угода, яку ми слідуємо щоб робити з'єднання більш зрозумілим.

БАГАТО-Стовпцеві ЗОВНІШНІ КЛЮЧІ

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

ДУМКА ЗОВНІШНЬОГО І БАТЬКІВСЬКОГО КЛЮЧІВ

Коли поле є зовнішнім ключем, воно певним чином пов'язане з таблицею на яку він посилається. Ви, фактично, кажете - " кожне значення в цьому полі (зовнішньому ключі) безпосередньо прив'язане до значення в іншому полі (батьківському ключі)." Кожне значення (кожний рядок) зовнішнього ключа має недвозначно посилатися до одного і лише цього значення (рядку) батьківського ключа. Якщо це так, то фактично ваша система, як то кажуть, буде у стані довідкової цілісності. Ви можете побачити це на прикладі. Зовнішній ключ snum у таблиці Замовників має значення 1001 для рядків Hoffman та Clemens. Припустимо що ми мали два рядки в таблиці Продавців зі значенням у полі snum = 1001. Як ми дізнаємося, якого з двох продавців були призначені замовники Hoffman і Clemens ? Аналогічно, якщо немає жодних таких рядків у таблиці Продавців, ми отримаємо Hoffman та Clemens призначеними до продавця якого не існує!

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

Фактично, дане значення зовнішнього ключа може посилатися тільки до одного значення батьківського ключа без зворотної можливості: тобто. Будь-яке число зовнішніх ключів може посилати до єдиного значення батьківського ключа. Ви можете побачити це у типових таблицях наших прикладів. І Hoffman і Clemens призначені до Peel, так що обидва їхні значення зовнішнього ключа збігаються з тим самим батьківським ключем, що дуже добре. Значення зовнішнього ключа має посилатися лише до одного значення батьківського ключа, зате значення батьківського ключа може посилатися за допомогою будь-якої кількості значень зовнішнього ключа. В якості ілюстрації значення зовнішнього ключа з таблиці Замовників, що збіглися з їх батьківським ключем у Продавців таблиці, показуються в Рисунку 19.1. Для зручності ми не враховували підлогу, що не відноситься до цього прикладу.

ОБМЕЖЕННЯ FOREIGN KEY

SQL підтримує довідкову цілісність із обмеженням FOREIGN KEY. Хоча обмеження FOREIGN KEY - це нова особливість SQL, воно ще не забезпечує його універсальності. Крім того, деякі його реалізації більш складні ніж інші. Ця функція повинна обмежувати значення, які ви можете ввести у вашу базу даних, щоб змусити зовнішній ключ і батьківський ключ відповідати принципу довідкової цілісності. Одна з дій обмеження Зовнішнього Ключа – це відкидання значень для полів обмежених як зовнішній ключ, який ще не представлений у батьківському ключі. Це обмеження також впливає на вашу здатність змінювати або видаляти значення батьківського ключа (ми обговорюватимемо це пізніше в цьому розділі).

ЯК МОЖНА ПОЛЯ ПРЕДСТАВИТИ ЯКІСТЬ ЗОВНІШНІХ КЛЮЧІВ

Ви використовуєте обмеження FOREIGN KEY у команді CREATE TABLE (або ALTER TABLE), яка містить поле, яке ви хочете оголосити зовнішнім ключем. Ви даєте їм батьківський ключ, на який ви будете посилатися всередині обмеження FOREIGN KEY. Поміщення цього обмеження в команду - таке саме, що для інших обмежень обговорених у попередньому розділі. Рисунок 19.1: Зовнішній Ключ таблиці Замовників із батьківським ключем

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

ЗОВНІШНІЙ КЛЮЧ ЯК ОБМЕЖЕННЯ ТАБЛИЦІ

Синтаксис обмеження таблиці FOREIGN KEY: FOREIGN KEY REFERENCES [ ] Перший список стовпців - це список з одного або більше стовпців таблиці, які відокремлені комами і будуть створені або змінені цією командою. Pktable - це таблиця, що містить батьківський ключ. Вона може бути таблицею, яка створюється чи змінюється поточною командою. Другий список стовпців - це список стовпців, які будуть складати батьківський ключ. Списки двох стовпців мають бути сумісні, тобто:

* Вони повинні мати однакову кількість стовпців.

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

Створимо таблицю Замовників з полем snum визначеним в якості зовнішнього ключа, що посилається на таблицю Продавців: CREATE TABLE Customers (cnum integer Майте на увазі, що при використанні ALTER TABLE замість CREATE TABLE, для застосування обмеження FOREIGN KEY, значення які Ви вказуєте у зовнішньому ключі та батьківському ключі, повинні бути в стані довідкової цілісності.Інакше команда буде відхилена.Хоча ALTER TABLE дуже корисна -за її зручності, ви повинні будете у вашій системі, по можливості щоразу, спочатку формувати структурні принципи, типу довідкової цілісності.

ЗОВНІШНІЙ КЛЮЧ ЯК ОБМЕЖЕННЯ СТОЛБЦІВ

Варіант обмеження стовпця обмеженням FOREIGN KEY - інакше називається - посилання обмеження (REFERENCES), так як він фактично не містить у собі слів FOREIGN KEY, а просто використовує слово REFERENCES, і далі їм батьківського ключа, подібно до цього: CREATE TABLE cnum integer NOT NULL PRIMARY KEY, name char(10), city char(10), snum integer REFERENCES Salespeople (snum)); Вищезгадане визначає Customers.snum як зовнішній ключ, у якого батьківський ключ - це Salespeople.snum. Це еквівалентно такому обмеженню таблиці: FOREIGN KEY (snum) REGERENCES Salespeople (snum)

НЕ ВКАЗУВАТИ СПИСОК СТОЛБЦІВ ПЕРВИННИХ КЛЮЧІВ

Використовуючи обмеження FOREIGN KEY таблиці або стовпця, ви можете не вказувати список стовпців батьківського ключа, якщо батьківський ключ має обмеження PRIMARY KEY. Звичайно, у випадку ключів з багатьма полями порядок стовпців у зовнішніх і первинних ключах повинен збігатися, і, в будь-якому випадку, принцип сумісності між двома ключами все ще застосовується. Наприклад, якщо ми помістили обмеження PRIMARY KEY у полі snum таблиці Продавців, ми могли б використовувати його як зовнішній ключ у таблиці Замовників (подібно до попереднього прикладу) у цій команді: CREATE TABLE Customers (cnum integer NOT NULL PRIMARY KEY, cname char(10) , city char(10), snum integer REFERENCES Salespeople); Цей засіб вбудовувався в мову, щоб заохочувати вас використовувати первинні ключі як батьківські ключі.

Як довідкова цілісність обмежує значення батьківського ключа

Підтримка довідкової цілісності потребує певних обмежень на значення, які можуть бути представлені в полях, оголошених як зовнішній ключ та батьківський ключ. Батьківський ключ повинен бути структурним, щоб гарантувати, що кожне значення зовнішнього ключа буде відповідати одному вказаному рядку. Це означає, що він (ключ) має бути унікальним і не містити жодних порожніх значень (NULL). Цього мало для батьківського ключа у разі виконання такої вимоги як із оголошенні зовнішнього ключа. SQL повинен бути впевнений, що подвійні значення або порожні значення (NULL) не були введені в батьківський ключ. Отже, ви повинні переконатися, що всі підлоги, які використовуються як батьківські ключі, мають або обмеження PRIMARY KEY або обмеження UNIQUE, на зразок обмеження NOT NULL.

ПЕРВИННИЙ КЛЮЧ ЯК УНІКАЛЬНИЙ ЗОВНІШНІЙ КЛЮЧ

Посилання ваших зовнішніх ключів тільки на первинні ключі, як ми це робили в типових таблицях, – хороша стратегія. Коли ви використовуєте зовнішні ключі, ви пов'язуєте їх не просто з батьківськими ключами, на які вони посилаються; ви пов'язуєте їх з певним рядком таблиці, де цей батьківський ключ буде знайдено. Сам собою батьківський ключ не забезпечує жодної інформації, яка б не була вже представлена ​​у зовнішньому ключі. Сенс, наприклад, підлога snum як зовнішнього ключа в таблиці Замовників - це зв'язок який він забезпечує, не до значення підлога snum на яке він посилається, а до іншої інформації в таблиці Продавців, такий наприклад, як імена продавців, їх місцезнаходження, і так далі . Зовнішній ключ – це не просто зв'язок між двома ідентичними значеннями; це - зв'язок, за допомогою цих двох значень, між двома рядками таблиці, зазначеної в запиті. Це поле snum може використовуватися щоб пов'язувати будь-яку інформацію в рядку з таблиці Замовників з рядком з таблиці Продавців - наприклад, щоб дізнатися - чи живуть вони в тому самому місті, хто має довше ім'я, чи має продавець крім даного замовника якихось інших замовників, і таке інше. Так як мета первинного ключа полягає в тому, щоб ідентифікувати унікальність рядка, це логічніший і менш неоднозначний вибір для зовнішнього ключа. Для будь-якого зовнішнього ключа який використовує унікальний ключ як батьківський ключ, ви повинні створити зовнішній ключ який би використовував первинний ключ тієї ж таблиці для того ж самого дії. Зовнішній ключ який не має жодної іншої мети крім зв'язування рядків, нагадує первинний ключ, що використовується виключно для ідентифікації рядків, і є хорошим засобом зберегти структуру вашої бази даних ясною та простою, і - отже створює менше труднощів.

ОБМЕЖЕННЯ ЗОВНІШНЬОГО КЛЮЧУ

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

ЩО ВИПАДАЄТЬСЯ, ЯКЩО ВИ ВИКОНАЄТЕ КОМАНДУ МОДИФІКАЦІЇ

Давайте домовимося, що всі зовнішні ключі створені в наших таблицях прикладів, оголошені та наказані з обмеженнями зовнішнього ключа, таким чином: CREATE TABLE Salespeople (snum integer , comm decimal); CREATE TABLE Customers (cnum integer NOT NULL PRIMARY KEY, name char(10) NOT NULL, city char(10), rating integer, snum integer, FOREIGN KEY (snum) REFERENCES Salespeople, UNIQUE (Cnum, snum cnum integer NOT NULL PRIMARY KEY, amt decimal, odate date NOT NULL, cnum integer NOT NULL snum integer NOT NULL FOREIGN KEY (cnum, snum) REFERENCES CUSTOMERS (cnum, snum);

ВКЛЮЧЕННЯ ОПИСІВ ТАБЛИЦІ

Є кілька атрибутів таких визначень, про які треба поговорити. Причина, за якою ми вирішили зробити підлогу cnum і snum в таблиці Порядків, єдиним зовнішнім ключем - це гарантія того, що для кожного замовника, що міститься в порядках, продавець, що кредитує цей порядок, - той самий, що й зазначений у таблиці Замовників. Щоб створити такий зовнішній ключ, ми повинні були б помістити обмеження таблиці UNIQUE у дві підлоги таблиці Замовників, навіть якщо воно необов'язкове для самої цієї таблиці. Поки поле cnum у цій таблиці має обмеження PRIMARY KEY, воно буде унікальне в будь-якому випадку, і тому неможливо отримати ще одну комбінацію підлогу cnum з якимось іншим полем. Створення зовнішнього ключа в такий спосіб підтримує цілісність бази даних, навіть якщо при цьому вам буде заборонено внутрішнє переривання помилково і кредитувати будь-якого продавця, іншого, ніж той, який призначений саме цьому замовнику.

З погляду підтримки цілісності бази даних, внутрішні переривання (чи винятки) звісно ж небажані. Якщо ви їх допускаєте і в той же час хочете підтримувати цілісність вашої бази даних, ви можете оголосити підлогу snum і cnum у таблиці Порядків незалежними зовнішніми ключами цих полів у таблиці Продавців та таблиці Замовників відповідно. Фактично, використання підлоги snum у таблиці Порядків, як ми це робили, необов'язково, хоча це корисно було зробити для різноманітності. Поле cnum пов'язуючи кожен порядок замовників у таблиці Замовників, таблиці Порядків та таблиці Замовників, має завжди бути спільним щоб знаходити правильне поле snum для даного порядку (не дозволяючи жодних винятків). Це означає, що ми записуємо фрагмент інформації - який замовник призначений до якогось продавця - двічі, і потрібно буде виконувати додаткову роботу щоб переконатися, що обидві версії узгоджуються. Якщо ми не маємо обмеження зовнішнього ключа, як сказано вище, ця ситуація буде особливо проблематична, тому що кожен порядок потрібно буде перевіряти вручну (разом із запитом), щоб переконатися, що саме відповідний продавець кредитував кожний відповідний продаж. Наявність такого типу інформаційної надмірності у вашій базі даних називається деморалізація (denormalization), що небажано в ідеальній реляційній базі даних, хоча практично і може бути дозволена. Деморалізація може змусити деякі запити виконуватися швидше, оскільки запит однієї таблиці виконується завжди значно швидше, ніж у об'єднанні.

ДІЯ ОБМЕЖЕНЬ

Як такі обмеження впливають на можливість та неможливість використання команд модифікації DML? Для полів, визначених як зовнішні ключі, відповідь досить проста: будь-які значення, які ви поміщаєте в ці підлоги з командою INSERT або UPDATE, повинні вже бути представлені в їхніх батьківських ключах. Ви можете поміщати порожні (NULL) значення в ці підлоги, незважаючи на те, що значення NULL не дозволені в батьківських ключах, якщо вони мають обмеження NOT NULL. Ви можете видаляти (DELETE) будь-які рядки із зовнішніми ключами, не використовуючи батьківські ключі взагалі.

Оскільки порушено питання про зміну значень батьківського ключа, відповідь, за визначенням ANSI, ще простіше, але можливо дещо більш обмежений: будь-яке значення батьківського ключа, що посилається за допомогою значення зовнішнього ключа, не може бути видалено або змінено. Це означає, наприклад, що ви не можете видалити замовника з таблиці Замовників, поки він ще має порядки в таблиці Порядків. Залежно від того, як ви використовуєте ці таблиці, це може бути бажано або клопітко. Однак це звичайно краще, ніж мати систему, яка дозволить вам видалити замовника з поточними порядками і залишити таблицю Порядків, що посилається на неіснуючих замовників. Сенс цієї системи обмеження в тому, що творець таблиці Порядків, використовуючи таблицю Замовників та таблицю Продавців як батьківські ключі, може накласти значні обмеження на дії в цих таблицях. З цієї причини, ви не зможете використовувати таблицю якої ви не розпоряджуєтеся (тобто не ви її створювали і не ви є її власником), поки власник (творець) цієї таблиці спеціально не передасть вам на це право (що пояснюється в Розділ 22). Є деякі інші можливі дії зміни батьківського ключа, які не є частиною ANSI, але можуть бути знайдені в деяких комерційних програмах. Якщо ви бажаєте змінити або видалити поточне посилання для батьківського ключа, є по суті три можливості:

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

    Навіть у межах цих трьох категорій, ви можете не захотіти обробляти всі команди модифікації у такий спосіб. INSERT, звичайно, до справи не належить. Він містить нові значення батьківського ключа в таблицю, так що жодне з цих значень не може бути викликане в даний момент. Однак, ви можете захотіти дозволити модифікаціям бути каскадними, але без вилучень і навпаки. Найкращою може бути ситуація, яка дозволить вам визначати будь-яку з трьох категорій, незалежно від команд UPDATE та DELETE. Ми будемо посилатися на ефект модифікації (update effects) та ефект видалення (delete effects), які визначають, що трапиться, якщо ви виконаєте команди UPDATE або DELETE у батьківському ключі. Ці ефекти, про які ми говорили, називаються: Обмежені (RESTRICTED) зміни, Каскадовані (CASCADES) зміни та Порожні (NULL) зміни. Фактичні можливості вашої системи повинні бути в строгому стандарті ANSI - це ефекти модифікації та видалення, обидва автоматично обмежені - для більш ідеальної ситуації описаної вище. Як ілюстрація, ми покажемо кілька прикладів того, що ви можете робити з повним набором ефектів модифікації та видалення. Звичайно, ефекти модифікації та видалення, що є нестандартними засобами, відчувають нестачу у стандартному держінтаксисі. Синтаксис, який ми використовуємо тут, простий у написанні і буде служити надалі для ілюстрації функцій цих ефектів.

    Для повноти експерименту, дозволимо собі уявити, що ви маєте причину змінити поле snum таблиці Продавців у випадку, коли наша таблиця Продавців змінює розділи. (Зазвичай зміна первинних ключів це не те, що ми рекомендуємо робити практично. Просто це ще один з доводів для наявних первинних ключів які не вміють робити нічого іншого крім як, діяти як первинні ключі: вони не повинні змінюватися.) Коли ви змінюєте номер продавця, ви хочете, щоб були збережені всі його замовники. Однак, якщо цей продавець залишає свою фірму або компанію, ви можете не захотіти видалити його замовників, при видаленні самого з бази даних. Натомість, ви захочете переконатися, що замовники призначені комусь ще. Щоб зробити це ви повинні вказати UPDATE з ефектом Каскаду, і DELETE з Обмеженим ефектом. CREATE TABLE Customers (cnum integer NOT NULL PRIMARY KEY, name char(10) NOT NULL, city char(10), rating integer, snum integer REFERENCES Salespeople, UPDATE OF Salespeople CASCADES, DELETE OF Salespe Якщо ви спробуєте видалити Peel з таблиці Продавців, команда буде не допустима, поки ви не зміните значення підлогу snum замовників Hoffman і Clemens для іншого призначеного продавця. З іншого боку, ви можете змінити значення підлогу snum для Peel на 1009, і Hoffman та Clemens будуть також автоматично змінені.

    Третій ефект - порожні (NULL) зміни. Буває, коли продавці залишають компанію, їх поточні порядки не передаються іншому продавцю. З іншого боку, ви хочете скасувати всі порядки автоматично для замовників, чиї рахунки ви видалите. Змінивши номери продавця чи замовника, можна просто передати їх йому. Приклад нижче показує, як можна створити таблицю Порядків за допомогою цих ефектів. CREATE TABLE Ордери (одна частина NULL NULL PRIMARY KEY, на 10 днів, відсутня NULL NULL NUMER REFERENCES Customers snum integer REFERENCES Salespeople, UPDATE OF Customers Звичайно, у команді DELETE з ефектом Пустої зміни в таблиці Продавців, обмеження NOT NULL має бути видалене з підлоги snum.

    ЗОВНІШНІ КЛЮЧІ, ЯКІ ПОСИЛАЮТЬСЯ ЗВОРОТНО ДО ЇХ ПІДПОЧИННИХ ТАБЛИЦЬ

    Як згадувалося раніше, обмеження FOREIGN KEY може уявити їм цієї приватної таблиці, як таблиці батьківського ключа. Далеко не простий, ця особливість може стати в нагоді. Припустимо, що маємо таблицю Employees з полем manager(адміністратор). Це поле містить номери кожного із службовців, деякі з яких є ще й адміністраторами. Але оскільки кожен адміністратор - водночас залишається службовцем, він природно будуть також представлений у цій таблиці. Давайте створимо таблицю, де номер службовця (стовпець з ім'ям empno), оголошується як первинний ключ, а адміністратор, як зовнішній ключ, посилатиметься на неї: CREATE TABLE Employees (empno integer , manager integer (REFERENCES Employees); (Оскільки зовнішній ключ це посилається первинний ключ таблиці, список стовпців може бути виключений.) Є зміст цієї таблиці: EMPNO NAME MANAGER _____ ________ _______ 1003 Terrence 2007 2007 Atali NULL 1688 але не Atali) , посилається на іншого службовця у таблиці як на свого адміністратора. Atali, що має найвищий номер у таблиці, повинен мати значення, встановлене в NULL. Це дає інший принцип довідкової цілісності. Зовнішній ключ, який посилається до приватної таблиці, повинен дозволяти значення = NULL. Якщо це не так, як ви могли б вставити перший рядок? Навіть якщо цей перший рядок посилається на себе саму, значення батьківського ключа вже має бути встановлено, коли вводиться значення зовнішнього ключа. Цей принцип буде вірний, навіть якщо зовнішній ключ посилається назад до приватної таблиці не безпосередньо, а за допомогою посилання на іншу таблицю, яка потім посилається назад до таблиці зовнішнього ключа. Наприклад, припустимо, що наша таблиця Продавців має додаткове поле, яке посилається на таблицю Замовників, так, що кожна таблиця посилається на іншу, як показано в наступному операторі CREATE TABLE: CREATE TABLE Salespeople NOT NULL, city char(10), comm declmal, cnum integer REFERENCES Customers); CREATE TABLE Customers (cnum integer NOT NULL PRIMARY KEY, name char(10) NOT NULL, city char(10), rating integer, snum integer REFERENCES Salespeople); Це називається – перехресним посиланням. SQL підтримує це теоретично, але це може скласти проблему. Будь-яка таблиця з цих двох, створена першою є таблицею посилань, яка ще не існує для іншої. В інтересах забезпечення перехресного посилання, SQL фактично дозволяє це, але ніяка таблиця не буде придатна для використання, поки вони обидва знаходяться в процесі створення. З іншого боку, якщо ці дві таблиці створюються різними користувачами, проблема стає ще складнішою. Перехресне посилання може стати корисним інструментом, але воно не без неоднозначності та небезпек. Попередній приклад, наприклад, не зовсім придатний для використання: тому що він обмежує продавця одиничним замовником і, крім того, зовсім необов'язково використовувати перехресне посилання для цього. Ми рекомендуємо, щоб ви були обережні у його використанні та аналізували, як ваші програми керу- ють ефектами модифікації та видалення, а також процесами привілеїв та діалогової обробки запитів перед тим, як ви створюєте перехресну систему довідкової цілісності. (Привілеї та діалогове опрацювання запитів будуть обговорюватися, відповідно, у Главах 22 І .)

    РЕЗЮМЕ

    Тепер ви маєте досить добре управління довідковою цілісністю. Основна ідея в тому, що всі значення зовнішнього ключа посилаються на вказаний рядок батьківського ключа. Це означає, що кожне значення зовнішнього ключа має бути представлене один раз, і лише один раз у батьківському ключі. Щоразу, коли значення міститься у зовнішній ключ, батьківський ключ перевіряється, щоб переконатися, що його значення представлено; інакше команда буде відхилена. Батьківський ключ повинен мати Первинний Ключ (PRIMARY KEY) або Унікальне (UNIQUE) обмеження, що гарантує, що значення не буде представлено більш ніж один раз. Спроба змінити значення батьківського ключа, яке нині представлено в зовнішньому ключі, буде взагалі відхилена. Ваша система може, проте, запропонувати вам вибір, щоб отримати значення зовнішнього ключа встановленого в NULL або для отримання нового значення батьківського ключа, і вказівки якого з них може бути отриманий незалежно для команд UPDATE та DELETE. Цим завершується наше обговорення команди CREATE TABLE. Далі ми представимо вас іншому типу команди – CREATE. У розділі 20 ви навчитеся представленню об'єктів даних які виглядають і діють подібно до таблиці, але насправді є результатами запитів. Деякі функції обмежень можуть також виконуватися уявленнями, так що ви зможете краще оцінити вашу потребу до обмежень після того, як ви прочитаєте наступні три розділи.

    РОБОТА З SQL

    1. Створіть таблицю під назвою Cityorders. Вона повинна містити такі ж підлоги onum, amt, і snum що і таблиця Порядків, і такі ж підлога cnum і city як таблиця Замовників, так що порядок кожного замовника буде вводитися в цю таблицю разом з його містом. Поле оnum буде первинним ключем Cityorders. Всі підлоги в Cityorders повинні мати обмеження порівняно з таблицями Замовників та Порядків. Допускається, що батьківські ключі у цих таблицях мають відповідні обмеження.

    2. Ускладнимо проблему. Перевизначте таблицю Порядків так: додайте новий стовпець з ім'ям prev, який буде ідентифікований для кожного порядку, поле onum попереднього порядку для цього поточного замовника. Виконайте це за допомогою зовнішнього ключа, який посилається на саму таблицю Порядків. Зовнішній ключ повинен посилатися також на поле cnum замовника, що забезпечує певний припис зв'язок між поточним порядком і посиланням.

    (Див. Додаток A для відповідей.)

    • F oreign Key (зовнішній ключ) є ключем, який використовується для з'єднання двох таблиць. Його іноді також називають ключем, що посилається.

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

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

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

    Приклад

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

    Таблиця CUSTOMERS

    CREATE TABLE CUSTOMERS(ID INT NOT NULL, NAME VARCHAR (20) NOT NULL, AGE INT NOT NULL, ADDRESS CHAR (25) , SALARY DECIMAL (18, 2), PRIMARY KEY (ID));

    Таблиця ORDERS

    CREATE TABLE ORDERS (ID INT NOT NULL, DATE DATETIME, CUSTOMER_ID INT references CUSTOMERS(ID), AMOUNT double, PRIMARY KEY (ID));

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

    ALTER TABLE ORDERS ADD FOREIGN KEY (Customer_ID) REFERENCES CUSTOMERS (ID);

    Видалення обмеження зовнішнього ключа

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

    ALTER TABLE ORDERS DROP FOREIGN KEY;

    У цій темі, на прикладі двох таблиць, визначаються основні поняття реляційних баз даних, а саме:

    • первинний ключ;
    • зовнішній ключ;
    • простий та складовий ключ;
    • відношення, типи стосунків;
    • штучний та природний ключі;
    • головна (master) та підлегла (detail) таблиці.

    Вхідні дані

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

    Таблиці мають таку структуру.

    «Робітник». Містить дані про працівника «Зарплата». Містить відомості про заробітну плату працівників.

    Питання відповідь

    1. Що таке первинний ключ у таблиці бази даних? Навіщо використовуються первинні ключі?

    При роботі з таблицями в реляційних базах даних бажано (необхідно), щоб кожна таблиця мала так званий первинний ключ.

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

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

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

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

    2. Що таке відношення (зв'язок) між таблицями (relationship)? Приклад

    Таблиці реляційної моделі даних можуть мати зв'язки між собою. Такі зв'язки називаються стосунками. Для таблиць «Працівник» та «Зарплата» можна встановити зв'язок по полю «Табельний номер».

    приклад.Проаналізуємо таблиці «Працівник» та «Зарплата». У цих таблицях можна встановити відношення між таблицями на основі поля "Табельний номер". Тобто зв'язок між таблицями відбувається на основі поля (атрибуту) «Табельний номер».

    Це означає таке. Якщо потрібно знайти нараховану заробітну плату в таблиці «Зарплата» для працівника Іванов І.І., потрібно виконати такі дії:

    • знайти табельний номер працівника Іванов І.І. у таблиці «Робітник». Значення табельного номера дорівнює 7585;
    • у таблиці «Зарплата» знайти всі значення, які дорівнюють 7585 (табельний номер);
    • вибрати із таблиці «Зарплата» всі значення поля «Нараховано», які відповідають табельному номеру 7585.

    Рис. 1. Ілюстрація зв'язку між таблицями. Табельний номер 2145 таблиці «Працівник» відображається у таблиці «Зарплата»

    Рис. 2. Зв'язок (ставлення) між полями таблиць

    3. Що таке зовнішній ключ (foreign key)? Приклад

    Поняття "зовнішній ключ" є важливим при розгляді пов'язаних таблиць.

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

    приклад.Нехай між таблицями «Працівник» та «Зарплата» існує взаємозв'язок по полю «Табельний номер». У цьому випадку поле «Табельний номер» таблиці «Працівник» може бути первинним ключем, а поле «Табельний номер» таблиці «Зарплата» — зовнішнім ключем. Це означає, що значення поля "Табельний номер" таблиці "Зарплата" замінюються значеннями поля "Табельний номер" таблиці "Працівник".

    4. Що таке зовнішній ключ рекурсивний?

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

    5. Чи можуть первинні та зовнішні ключі бути простими або складовими (складними)?

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

    6. Яка відмінність між штучним та природним ключем? Приклад

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

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

    приклад.У таблиці "Працівник" природним ключем є поле (атрибут) "Табельний номер". Поле «Табельний номер» є унікальним, оскільки не може бути двох працівників з однаковим табельним номером.

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

    де поле «Номер» є штучним ключем, що забезпечує унікальність.

    7. Які існують методи вибору первинного ключа?

    Існує 3 способи вибору первинного ключа:

    • використовувати поле-інкремент (поле-лічильник) як штучний ключ;
    • вибрати із даних одне поле, яке може забезпечити унікальність;
    • вибрати з даних кілька полів, які можуть забезпечувати унікальність. У цьому випадку ключ ще називатиметься складним (складеним).
    8. Що означають терміни «головна таблиця» (master) та «підпорядкована таблиця» (detail)?

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

    приклад.Якщо розглянути таблиці «Працівник» та «Зарплата», то таблиця «Працівник» є головною, а таблиця «Зарплата» є підлеглою.

    9. Які типи відносин (зв'язків) між таблицями?

    Існує 4 основних типи відносин між таблицями:

    • "один до одного". У цьому випадку кожному запису однієї таблиці відповідає лише один запис іншої таблиці;
    • «один до багатьох». Це коли одному запису головної таблиці (master) відповідає кілька записів підпорядкованої таблиці (detail). Тобто, кожному запису, який є первинним ключем однієї таблиці, відповідає кілька записів пов'язаної таблиці;
    • «багато до одного». Це коли кільком записам головної таблиці відповідає один запис підпорядкованої таблиці;
    • «багато до багатьох». Це коли у обох таблицях існує кілька взаємозалежних записів.

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

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

    СУБД – це програмні засоби для створення, наповнення, оновлення та видалення БД.

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

    У термінах БД стовпці таблиці називаються полями, та її рядки – записами.

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

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

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

    Сутність - Відображення об'єкта в пам'яті людини або комп'ютера.

    Атрибут - Конкретне значення будь-якої з властивостей сутності.

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

    Поле зв'язку – це поле, яким дві таблиці пов'язані.

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

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

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

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

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

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

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

    Реляційні відносини між таблицями

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

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

    Подібно до зв'язку одним, зв'язок один до одного може бути жорстким і нежорстким.

    застосовується до: SQL Server (починаючи з 2016) База даних SQL AzureСховище даних SQL AzureParallel Data Warehouse

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

    Ця тема описана у наступних розділах.

    Обмеження первинного ключа

    Обмеження зовнішнього ключа

    Пов'язані завдання

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

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

    Як показано на наступному малюнку, стовпці ProductIDі VendorIDу таблиці Purchasing.ProductVendorформують складове обмеження первинного ключа даної таблиці. При цьому гарантується, що кожен рядок у таблиці ProductVendorмає унікальне поєднання значень ProductIDі VendorID. Це запобігає вставці рядків, що повторюються.

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

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

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

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

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

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

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

    Наприклад, таблиця Sales.SalesOrderHeaderпов'язана з таблицею Sales.SalesPersonза допомогою зовнішнього ключа, тому що існує логічний зв'язок між замовленнями на продаж та менеджерами з продажу. Стовпець SalesPersonIDу таблиці Sales.SalesOrderHeaderвідповідає первинному ключовому стовпцю в таблиці SalesPerson. Стовпець SalesPersonIDу таблиці Sales.SalesOrderHeaderє зовнішнім ключем для таблиці SalesPerson. За допомогою встановлення даного зв'язку за зовнішнім ключем значення для SalesPersonIDне може бути вставлено до таблиці SalesOrderHeader, якщо вона зараз не міститься в таблиці SalesPerson.

    Максимальна кількість таблиць і стовпців, на які може посилатися таблиця як зовнішні ключі (вихідні посилання), дорівнює 253. SQL Server 2016 збільшує обмеження на кількість інших таблиць і стовпців, які можуть посилатися на стовпці в одній таблиці (вхідні посилання), з 253 до 10 000. (Потрібно рівень сумісності не менше 130.) Збільшення має такі обмеження:

      Перевищення 253 посилань на зовнішні ключі підтримується лише для операцій DML DELETE. Операції UPDATE та MERGE не підтримуються.

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

    Індекси в обмеженнях зовнішнього ключа

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

      Стовпчики зовнішнього ключа часто використовуються в умовах з'єднання при спільному застосуванні у запитах даних із пов'язаних таблиць. Це реалізується шляхом зіставлення стовпця або стовпців обмеження зовнішнього ключа в одній таблиці з одним або декількома стовпцями первинного або унікального ключа в іншій таблиці. Індекс дозволяє компоненту Компонент Database Engine швидко знаходити пов'язані дані у таблиці зовнішніх ключів. Втім, створення індексу не є обов'язковим. Дані з двох пов'язаних таблиць можна комбінувати, навіть якщо між таблицями не визначено обмеження первинного ключа або зовнішнього ключа, але зв'язок із зовнішнім ключем між двома таблицями показує, що ці дві таблиці оптимізовані для спільного застосування у запиті, де ключі використовуються як критерії.

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

    Посилальна цілісність

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

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

    Каскадна посилальна цілісність

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

    NO ACTION
    Компонент Компонент Database Engine формує помилку, після чого виконується відкат операції видалення або оновлення рядка батьківської таблиці.

    CASCADE
    Відповідні рядки оновлюються або видаляються з таблиці, що посилається, якщо цей рядок оновлюється або видаляється з батьківської таблиці. Значення CASCADE не може бути вказано, якщо стовпець типу timestampє частиною зовнішнього чи посилального ключа. Дія ON DELETE CASCADE не може бути зазначена у таблиці, для якої визначено тригер INSTEAD OF DELETE. Пропозиція ON UPDATE CASCADE не може бути задана стосовно таблиць, для яких визначені тригери INSTEAD OF UPDATE.

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

    SET DEFAULT
    Усі значення, що становлять зовнішній ключ, при видаленні або оновленні відповідного рядка батьківської таблиці встановлюються за замовчуванням. Для виконання цього обмеження всі ключові стовпці повинні мати визначення за замовчуванням. Якщо стовпець допускає значення NULL і значення за замовчуванням явно не визначено, значення стовпця за замовчуванням стає NULL. Не можна задати стосовно таблиць, для яких визначено тригери INSTEAD OF UPDATE.

    Ключові слова CASCADE, SET NULL, SET DEFAULT та NO ACTION можна поєднувати у таблицях, що мають взаємні посилання. Якщо компонент Компонент Database Engine виявляє ключове слово NO ACTION, воно зупинить та здійснить відкат пов'язаних операцій CASCADE, SET NULL та SET DEFAULT. Якщо інструкція DELETE містить поєднання ключових слів CASCADE, SET NULL, SET DEFAULT і NO ACTION, всі операції CASCADE, SET NULL і SET DEFAULT виконуються перед пошуком компонентом Компонент Database Engine операції NO ACTION.

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

    Каскадні дії посилань запускають тригери AFTER UPDATE або AFTER DELETE наступним чином:

      Всі каскадні дії посилань, прямо викликані вихідними інструкціями DELETE або UPDATE, виконуються першими.

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

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

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

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

      Виконання операцій CREATE, ALTER, DELETE або інших операцій мови DDL усередині тригерів може призвести до запуску тригерів DDL. Це може призвести до подальших операцій DELETE або UPDATE, які почнуть додаткові послідовності каскадних дій та запустять свої тригери.

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

      У таблиці, на яку визначено тригер INSTEAD OF, може бути пропозиція REFERENCES, показує конкретне каскадне дію. Проте цігер AFTER цільової таблиці каскадної дії може виконати інструкцію INSERT, UPDATE або DELETE для іншої таблиці або уявлення, яке запустить тригер INSTEAD OF для цього об'єкта.

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

    2022 gtavrl.ru.