Мобільне

Даний опис є первинним ключем. Реляційні бази даних

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

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

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

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

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

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

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

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

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

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

Наприклад, зв'язок між відносинами ВІДДІЛ і СПІВРОБІТНИК створюється шляхом копіювання первинного ключа "Номер_відділу" з першого відношення до другого. Таким чином, для того щоб отримати список працівників даного підрозділу, необхідно: 1) З таблиці ВІДДІЛ встановити значення атрибуту "Номер_відділу" , що відповідає даному "Найменуванню_відділу". 2) вибрати з таблиці СПІВРОБІТНИК всі записи, значення атрибута "Номер_відділу"яких дорівнює отриманому на попередньому етапі. Для того, щоб дізнатись у якому відділі працює співробітник, потрібно виконати зворотну операцію: 1) Визначаємо "Номер_відділу"з таблиці СПІВРОБІТНИК. 2) За отриманим значенням знаходимо запис у таблиці ВІДДІЛ.

18. Нормалізація в реляційних БД, поняття нормальної формипід час проектування баз даних.

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

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

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

Функціональні залежності.

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

19. 1НФ: Основні визначення та правила перетворення.

Для обговорення першої нормальної форми необхідно дати два визначення:

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

Складний атрибут - виходить з'єднанням декількох атомарних атрибутів, які можуть бути визначені на одному або різних доменах (його називають вектор або агрегат даних).

Визначення першої нормальної форми:

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

Розглянемо приклад:

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

СЛУЖАЧИЙ (НОМЕР_СЛУЖБОВОГО, ІМ'Я, ДАТА_НАРОДЖЕННЯ, ІСТОРІЯ_РОБОТИ, ДІТИ).

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

 ІСТОРІЯ_РОБОТИ (ДАТА_ПРИЙОМУ, НАЗВА, ІСТОРІЯ_ЗАРПЛАТИ),

 ІСТОРІЯ_ЗАРПЛАТИ (ДАТА_ПРИЗНАЧЕННЯ, ЗАРПЛАТА),

 ДІТИ (ІМ'Я_ДИТИНИ, РІК_НАРОДЖЕННЯ).

Їхній зв'язок представлений на рис. 3.3.

Рис.3.3. Початкове ставлення.

Для приведення вихідного відношення СЛУЖАЮЧИЙ до першої нормальної форми необхідно декомпозувати його на чотири відношення, так як це показано на наступному малюнку:

3.4. Нормалізована безліч відносин.

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

Алгоритм нормалізації описаний Е.Ф.Коддом так:

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

20. 2НФ: Основні визначеннята правила перетворення.

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

Визначення:

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

Приклад:

Нехай є відношення ПОСТАВКИ (N_ПОСТАЧАЛЬНИКА, ТОВАР, ЦІНА).
Постачальник може постачати різні товари, а той самий товар може поставлятися різними постачальниками. Тоді ключ відношення - "N_постачальника + товар". Нехай всі постачальники поставляють товар за тією ж ціною. Тоді маємо такі функціональні залежності:

N_постачальника, товар -> ціна
товар -> ціна

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

ПОСТАВКИ (N_ПОСТАЧАЛЬНИКА, ТОВАР)
ЦІНА_ТОВАРА (ТОВАР, ЦІНА)

Таким чином, можна дати

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

21. 3НФ: Основні визначеннята правила перетворення.

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

Визначення:

Нехай X, Y, Z – три атрибути деякого відношення. У цьому X --> Y і Y --> Z, але зворотне відповідність відсутня, тобто. Z -/-> Y та Y -/-> X. Тоді Z транзитивно залежить від X.
Нехай є відношення ЗБЕРІГАННЯ ( ФІРМА, СКЛАД, ОБСЯГ), яке містить інформацію про фірми, що отримують товари зі складів, та обсяги цих складів. Ключовий атрибут - "фірма". Якщо кожна фірма може отримувати товар тільки з одного складу, то в цьому відношенні є такі функціональні залежності:

фірма -> склад
склад -> Об `єм

При цьому виникають аномалії:

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

Для усунення цих аномалій необхідно декомпозувати вихідне відношення на два:

ЗБЕРІГАННЯ ( ФІРМА, СКЛАД)
ОБ'ЄМ_СКЛАДУ ( СКЛАД, ОБ `ЄМ)

Визначення третьої нормальної форми:

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

Раніше в цій книзі ми вказували на певні зв'язки, які існують між деякими полями типових таблиць. Поле 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 (snum integer NOT NULL PRIMARY KEY, sname char(10) 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 для відповідей.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Що таке первинний ключ?

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

Що таке ключ?

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

Різниця між основним ключем та зовнішнім ключем

Основи первинного ключа та зовнішнього ключа

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

Відношення первинного ключа та зовнішнього ключа

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

Дублюючі значення первинного ключа та зовнішнього ключа

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

NULL первинного ключа та зовнішнього ключа

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

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

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

Видалення основного ключа та зовнішнього ключа

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

Первинний або зовнішній ключ: порівняльна таблиця

Резюме основних ключів

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

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

План на сьогодні такий:

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

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

Первинний ключ

Стовпець, який у базі даних повинен бути унікальним позначають первинним ключем. Первинний ключ або primary key означає, що у таблиці значення колонки primary key неспроможна повторюватися. Таким чином, цей ключ дозволяє однозначно ідентифікувати запис у таблиці не боячись при цьому, що значення стовпця повторитися. Відразу приклад: припустимо, у Вас є таблиця користувачів. У цій таблиці є поля: ПІБ, рік народження, телефон. Як ідентифікувати користувача? Таким параметрам як ПІБ та телефон довіряти не можна. Адже у нас може бути кілька користувачів не лише з однаковим прізвищем, але й з ім'ям. Телефон може змінюватися з часом і користувач з номером телефону може виявитися не тим, хто у нас у базі даних.

Ось для цього і вигадали первинний ключ. Один раз надали унікальний ідентифікатор і все. В mySqlна прикладі якої ми виконуємо всі приклади з поля AUTO_INCREMENTне можна задати, якщо не вказати, що це первинний ключ.

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

Зовнішній ключ ( foreign key)

Є ще зовнішній ключ (foreign key). Його ще називають посилальним. Він необхідний зв'язування таблиць між собою.

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

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

Створення зовнішнього ключа

create table shoes(shoes_id int auto_increment primary key, title text, size int, price float, count int, type varchar(30), supplier int, foreign key (supplier) references supplier (supplier_id));

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

Складовий ключ (composite key)

Щодо складеного ключа — це кілька первинних ключів у таблиці. Таким чином, створивши composite key, унікальність запису буде перевірятись по полях, які об'єднані в цей ключ.

Бувають ситуації, коли при вставці таблицю потрібно перевіряти запис на унікальність відразу по кількох полях. Ось для цього і вигадано складовий ключ. Для прикладу я створю просту таблицю з composite key , щоб показати синтаксис:

Create table test(field_1 int, field_2 text, field_3 bigint, primary key (field_1, field_3));

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

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