[0:00]В цьому відео ми розберемось, що таке первинний ключ, англійською primary key і зовнішній ключ, англійською foreign key у реляційних базах даних. Ми вже частково розбирались, що таке первинний ключ, коли створювали таблиці. В цьому відео ми детально розглянемо, в чому полягає справжня сила і користь первинного ключа в реляційних базах даних. Крім того, ви дізнаєтесь, що таке зовнішній ключ, який зв'язок є між первинним і зовнішнім ключем і ще багато цікавого. Отож, скажімо, у нас є база даних ось тут, яка називається Cool Company. Ми її створили в одному з попередніх відео, але ви, в принципі, можете використовувати будь-яку іншу базу даних. І, скажімо, ми тут хочемо додати таблицю, у якій буде міститись інформація про усіх робітників у нашій компанії. Так ось, давайте цього разу ми скористаємось інструментами програми MySQL Workbench для створення цієї таблиці. Хоча ви, за бажанням, можете написати код для створення таблиці вручну також. Я натисну на ось цю кнопку на панелі меню, яка дозволить нам створити нову таблицю. У нас з'явиться ось таке віконечко, де є ціла купа інструментів для створення нової таблиці. Давайте спочатку назвемо якось нашу таблицю. В нашому випадку вона буде називатись Employee, що з англійською означає робітник, або ж працівник. І тепер нам потрібно буде додати в цю таблицю стовпці. Так, ось тут у нас є секція зі стовпцями, але вона трішки стиснута. Давайте ми ось це закриємо, і ось ця секція, де ми можемо додати стовпці, трішки розгорнулась. Тепер, кожного разу, коли ми створюємо нову таблицю в базі даних MySQL, ми вказуємо назву стовпців ось тут, звичайно ж, якщо ми використовуємо цей інструмент. І ось тут правіше, де написано Data Type, ми вказуємо тип даних. Про це ми теж уже знаємо з попередніх відео. І далі ось тут у нас є ціла купа коробочок, куди можна поставити пташечку. Тут згори є позначки, що кожна з цих коробочок, або ж секція означає, і якщо ви наведете сюди курсор, то спливаюча підказка підкаже вам, що кожне з цих налаштувань означає. Маленькі такі позначки, але мають дуже важливу функцію. За рахунок них таблиці і дані, які містяться в цих таблицях, легше структурувати, контролювати дані і навіть логічно пов'язувати таблиці між собою. Так ось, перший стовпець у нас буде первинним ключем і матиме ім'я, згідно нашого стандарту, яке складатиметься із назви таблиці із закінченням підкреслення і ID. Тобто це буде ідентифікатор, або ж первинний ключ для цієї нашої таблиці. Я напишу тут employee, нижнє підкреслення, і тепер ID. Про те, що таке первинний ключ і яка його місія, ми вже говорили у відео, коли обговорювали створення таблиці. До речі, в програмі MySQL Workbench, коли ви виділяєте стовпець у режимі дизайну, то ось тут знизу з'являється ціла секція з деталями про цей стовпець. Тобто, як ви бачите, після того, як я ввів ім'я стовпця і тип його даних, і тепер клацнув на ньому, ось ця вся секція показує нам деталі про цей стовпець у трішки більш спрощеному, або ж, якщо можна так сказати, читабельному вигляді. Так ось, кожного разу, коли у редакторі таблиці у програмі MySQL Workbench ви виділяєте стовпець у режимі дизайну, то нижче з'являється ціла секція з деталями про цей стовпець. Тобто ви можете змінювати ті самі налаштування для цього стовпця і ось тут, і ось тут. Тепер, давайте додамо сюди ще декілька стовпців. Другий стовпець у нас буде називатись, наприклад, first_name, тобто це буде ім'я нашого робітника. А наступний стовпець у нас буде last_name, тобто прізвище, і ще один стовпець, напишемо age, тобто вік. І тип у нас буде тут теж integer, тобто ціле число. Окей. Тип даних для імені і прізвища у нас дизайнер додав автоматично, тому що дизайнер автоматично встановлює тип VARCHAR. Для кожного типу даних ви, звичайно, можете його пізніше змінити, клацнувши ось тут двічі, і потім вибравши інший тип у спадному меню. Тепер, ось тут, у стовпці employee_id, як ви можете помітити, у нас є дві пташечки у цій секції. Перша - це PK. Як ви бачите, тут написано belongs to primary key. Або нижче ви можете помітити, що у нас є пташечка Primary Key. Ось тут, і ось тут - це той самий параметр. Дивіться, якщо я забираю пташечку тут нижче, то вона також зникла ось тут згори. Якщо я поставлю пташечку ось тут згори, то вона з'явилась ось тут знизу також. І так само з елементом Not Null, або ж ось тут він називається NN у стовпці. Так ось, стовпець, який називається employee_id, у нас є первинним ключем. Як можна помітити з ось цієї пташечки, яка в мене тут стоїть, і також у нас тут намальований такий жовтий ключик. Звичайно, якщо я заберу звідси цю пташечку, то жовтий ключик зникне, але нам він потрібен, тому що в таблиці employee стовпець employee_id повинен бути первинним ключем. Швиденько нагадаю, що первинний ключ, англійською primary key, - це у нас ось цей стовпець, і це є унікальний ідентифікатор запису в цій таблиці. Це, так би мовити, ідентифікаційний код кожного запису, тому що в кожного запису повинен бути свій неповторний, унікальний ідентифікатор. У попередньому відео, коли ми створювали таблиці, я вже казав, що іноді, хоч і не часто, програмісти, створюючи таблиці в базах даних, використовують натуральний первинний ключ. Тобто якусь одиницю інформації, яка є дійсно інформацією про цей об'єкт, як, наприклад, імейл-адреса чи номер паспорта. Єдина умова, щоб те саме значення не повторювалось двічі у цьому стовпці. Ми розглядаємо приклад таблиці User, або ж Користувач, де первинним ключем був імейл користувача. Тут імейл - це натуральний первинний ключ. Ще один приклад натурального первинного ключа - це ваш номер паспорта. Він теж унікальний, тому що в Україні немає двох паспортів з однаковими серією і номером паспорта. Наступний можливий приклад - це номер телефона. Якщо включити міжнародний код, то в світі не знайдеться двох однакових номерів телефонів. Повний номер телефона теж може бути натуральним первинним ключем у якійсь таблиці. Але з попереднього відео ви також знаєте, що насправді набагато кориснішим, зручнішим і ефективнішим у великих системах є використання сурогатного первинного ключа, де використовується звичайне ціле число. Як те, що ви бачите на екрані. Отже, з первинним ключем розібрались. Я вам лише дам декілька корисних рекомендацій щодо первинних ключів. Перша з них - це те, що для імені стовпця, для первинного ключа, рекомендовано використовувати власне назву таблиці і закінчення ID. Наприклад, для таблиці, яка називається Product, стовпець, який буде первинним ключем, рекомендовано називати Product ID. В такому випадку вам просто буде набагато легше зрозуміти, що є первинним ключем в якій таблиці. Наступна рекомендація, що тип даних для первинного ключа повинен бути цілим числом. Значення в полі з первинним ключем не може бути порожнім. І останнє, що це значення в стовпці з первинним ключем не може повторюватись. Тобто ви не можете мати два записи, де первинним ключем є, наприклад, число п'ять. Окей, повернемося до дизайнера нашої таблиці в програмі Workbench і натиснемо ось тут справа знизу кнопку Apply, тобто застосувати введені нами зміни і створити власне таблицю. Так, я натискаю кнопку Apply, і що в нас тут з'явилось? З'явилось повідомлення, що selected name conflicts with existing table employee. А, значить, Workbench каже нам, що у цій базі даних у нас вже є таблиця Employee, це я практикувався. Давайте я її видалю. Звичайно, Workbench каже, що не можна мати дві таблиці з однаковим іменем. Тут у нас є опція, яка називається Drop Table, тобто видалити. Drop Now. Готово. І тепер я натисну кнопку Apply ще раз, щоб створити нову таблицю Employee, згідно ось цих параметрів, які ми щойно ввели. Apply. Ось у нас SQL-код для створення цієї таблиці. Ми, в принципі, могли би просто скопіювати цей SQL-код, вставити його і виконати вручну, але щоб не тратити час, я просто зараз натисну ще раз Apply. І Finish. Тепер ось це можна закрити. І у нас є таблиця Employee, яку ми щойно створили. І ось у нас є всі стовпці, які ми туди додали. Тепер, давайте додамо в нашу таблицю декілька записів. У мене є декілька наперед створених записів, і я просто їх сюди вставлю. Ось тут у мене перший працівник, employee, тобто, буде мати первинний ключ один, ім'я Іван, прізвище Котигорошко, вік 25. Далі у нас буде цікава ситуація. У нас буде два робітника з однаковими іменами, обидва Івасики Телесики, але у першого буде вік 60, у другого вік 40. І єдиний спосіб, єдиний надійний спосіб, в якій ми можемо розрізнити цих двох працівників - це первинний ключ. У першого буде первинний ключ три, у другого буде первинний ключ чотири. Це одна з дуже важливих переваг первинного ключа. Це унікальний ідентифікатор кожного з цих записів. Я знаю, що в одному з попередніх відео ми про це вже говорили, але оскільки це дуже важливо, деякі речі я повторюю, щоб вам було простіше зрозуміти, що тут до чого, ну і, звичайно ж, запам'ятати. Тепер, давайте усе ось це виділимо і натиснемо кнопку виконати команду. Так, треба увімкнути нижню панель. Як ви бачите, ось у нас чотири успішно виконаних команди, і у нас є тепер чотири записи в нашій базі даних. Тепер ось це можна витерти.
[8:53]І давайте перевіримо, чи дійсно ці записи є у нашій таблиці. Давайте напишемо select зірочка from employee. І тепер виконаємо цю команду. Окей. І наша команда показала, що в нашій таблиці дійсно є чотири наших записи, які нам потрібні. Чудово. Давайте поки що сховаю нижню панель. Ви також можете помітити, що ось тут, коли ми виділяємо таблицю Employee, нижче, там де у нас написано Information, тобто інформація про виділену таблицю, у нас елемент, який є первинним ключем, тобто стовпець, який є первинним ключем, Employee ID, є підкресленим і написаним жирним текстом. І також ось тут справа у нас є позначка PK, тобто Primary Key, або ж первинний ключ. Так ось, одне з основних завдань первинного ключа - це розрізняти записи між собою. Використання первинного ключа, наприклад, дасть нам можливість редагувати, або видалити лише один запис, який має конкретний первинний ключ. Усі інші записи залишаться без змін. Але це ще не все. До найголовнішої ролі первинного ключа ми зараз доберемось. Скажімо, у нашій фірмі, яка має робітників, тих, що в таблиці Employee, звичайно, також є декілька відділів, або ж департаментів: Маркетинг, Продажі, IT і відділ Кадрів. І кожен з робітників, звичайно ж, працює в одному з цих відділів. Тепер питання до вас: як би ми могли зберегти інформацію про відділи для усіх робітників, тобто хто з робітників працює в якому відділі? Ну, скажете ви, мабуть, найпростіший варіант - це створити ще один стовпець типу VARCHAR і записати туди назви відділів для кожного робітника. І ця таблиця виглядала би приблизно ось так. Ну, все прекрасно. Первинний ключ є, і так виглядає, що зовнішнього ключа, про який ми мали б тут говорити, нам, в принципі, не потрібно. Хоча ні, зачекайте. У нас тут в компанії, скажімо, відбулись деякі зміни. Уявіть собі, що менеджмент компанії попросив змінити назви відділів і додати до кожного в дужках англійську назву. Які у нас варіанти швидко це зробити в цій таблиці? Ми могли б вручну змінити назви в усіх цих комірках. Давайте я зайду в режим редагування цієї таблиці, клацнувши на ній правою кнопкою мишки, вибравши опцію Alter Table. І тепер додам сюди новий стовпець, який буде називатись Department. І він у нас буде VARCHAR (45). Все окей. Давайте збережемо. Apply. І готово. Finish. І давайте ще раз запустимо цю команду. І давайте я прямо тут, у режимі перегляд таблиці, додам сюди якісь значення. Наприклад, це у нас буде Маркетинг, це у нас буде Продажі, це IT, і це Відділ Кадрів. Я вніс дані напряму в таблицю в режимі редагування. Добре, що у нас лише чотири записи, тому що я б дуже багато часу потратив, якби у нас їх тут було хоча б 500. Тепер, щоб зберегти внесені мною зміни, потрібно натиснути на кнопку Apply ось тут. Apply. І готово. Зміни збережено. Тепер, якщо я ще раз виконаю ось цю команду, як ви бачите, наші зміни тут залишились. Ну, все, прекрасно. Первинний ключ у нас є. Employee ID, і так виглядає, що зовнішнього ключа, про який ми мали б тут говорити, нам, в принципі, не потрібно. Хоча ні, зачекайте. У нас тут в компанії, скажімо, відбулись деякі зміни.
[12:10]Уявіть собі, що менеджмент компанії попросив змінити назви відділів і додати до кожного в дужках англійську назву. Які варіанти швидко це зробити в цій таблиці? Ми могли б, наприклад, змінити вручну назви в усіх цих комірках. Тобто я тут клацнув би двічі і в дужках написав би англійською Marketing. Тепер тут написав би Sales. І так далі, і так далі. Давайте я натисну застосувати. Окей. Щоб зберегти ці зміни. Але це, звичайно ж, не дуже розумний варіант, якщо у нас в цій таблиці тисячу записів. А якщо дві тисячі, або, можливо, мільйон. Тут, крім того, що я потрачу величезну купу часу, у мене з'являється ризик помилкових введень. Другий варіант - ми можемо написати SQL-команду, щоб система управління базами даних зробила це за нас. Така команда називається Update, і ми її розглянемо в одному з наступних уроків. Але це теж не дуже хороший варіант, оскільки процес оновлення купи записів в таблиці досить серйозно завантажить нашу базу даних і займе цінні ресурси сервера. Я маю на увазі процесор і оперативну пам'ять. Чому тут майже ніяка ідея оновлення даних не прийнятна? А тому, що це, в принципі, поганий дизайн таблиці у реляційній базі даних. І якщо ми залишимо дизайн цієї таблиці так, як є, це нам потенційно спричинить ще багато проблем у майбутньому. Зараз я вам поясню це на одному хорошому прикладі. Давайте сюди додам ще один запис. І сюди ще напишу ще одного пана Коцького. Скажімо, йому 15 років, і він у нас працює у відділі IT. Тепер у нас є два записи з однаковими значеннями. Ось тут, бачите, IT ось тут і IT ось тут. Так ось, якщо в таблиці, в базі даних, одні і ті ж значення в стовпчику повторюються більше ніж один раз, або ж багато разів, і вони не є числом, то це хороший кандидат для створення ще однієї окремої таблиці. І, як наслідок, це кандидат для використання зовнішнього ключа. Це дуже просто зробити. І я думаю, в процесі ви краще зрозумієте, як все це працює, ніж коли я буду просто пояснювати теорію. Ось це зліва - це існуючий вигляд нашої таблиці. Справа - це вдосконалений, точніше, більш правильний дизайн. Подивіться, в чому різниця. Перша, найбільш очевидна різниця - це те, що зліва одна таблиця, а справа їх у нас дві. І будь-який досвідчений програміст, або ж адміністратор баз даних скаже, що варіант справа зрозуміліший, легший, правильніший і логічніший, ніж той, що зліва. Я знаю, для вас це, можливо, поки що так не виглядає, але поки що повірте мені на слово. Хоча це навіть не обов'язково, зараз ви все самі побачите. Спочатку, що це таке, а потім для чого все це потрібно. У кожній з двох таблиць перший стовпець зліва із закінченням ID є первинним ключем, тобто унікальним ідентифікатором для кожного рядка, або ж для кожного запису в цій таблиці. Employee ID є первинним ключем для таблиці Employee, а Department ID є первинним ключем для таблиці Department. Але ось тут стовпець Department ID є зовнішнім ключем для таблиці Employee, тому що він вказує на первинний ключ у іншій таблиці.
[15:23]Ще раз. Зовнішній ключ - це значення в стовпці однієї таблиці, яке в якійсь іншій таблиці є первинним ключем. Тепер, щоб знайти, в якому відділі працює, наприклад, Іван Котигорошко, ми беремо значення стовпця Department ID в цій таблиці, тобто одиницю, звичайно ж, для Івана Котигорошка. Тепер, йдемо в таблицю Department, шукаємо запис з цим первинним ключем. Ось тут. І отримуємо інформацію, в якому департаменті, або ж в якому відділі працює Іван Котигорошко. Так само, наприклад, для ось цього Івасика Телесика. Ми йдемо у його Department ID, тобто три, потім йдемо в таблицю Department, знаходимо первинний ключ три, і дізнаємось, що він працює у відділі IT. Таким чином ми створили логічний зв'язок між двома таблицями. Англійською це називається Relation. Саме тому бази даних SQL називають реляційними базами даних, англійською relational databases, тому що в них між таблицями є зв'язок, або ж relation. Взагалі, айтішники могли б назвати ці бази даних в українському перекладі якось цікавіше. Замість реляційних, наприклад, бази даних зі стосунками, або бази даних із відносинами. Хоча це якось по-божевільницьки звучить. У вас може з'явитись логічне запитання: а хіба не легше було б все рівно тримати все в одній таблиці і не морочити собі одне місце, створюючи додаткову таблицю, а потім зв'язки між цими таблицями? Відповідь - ні. Ось така структура, яку ви бачите на екрані, насправді ефективніша, правильніша і зручніша. І чим більше ви працюватимете з базами даних, і чим більше даних міститимуть ваші таблиці, тим очевиднішим це для вас ставатиме. Я вам тут показав найпримітивніший приклад зв'язку між таблицями з використанням зовнішнього ключа. Це лише маленька вершина айсберга. Давайте зробимо це в дизайнері таблиць в програмі Workbench. Таблиця Employee у нас уже є. Тепер давайте створимо нову таблицю, яка у нас буде називатись Department. Я не буду використовувати інструменти програми Workbench. У мене вже є наперед заготовлений скрипт, або ж код для створення таблиці. Я просто його скопіюю, вставлю сюди. Ця таблиця в мене теж існує, тому що я попередньо тестував код для цього відео. Давайте я її видалю. І виконаю цю команду ще раз. Тепер таблиця Department у нас створена. Тепер давайте оновимо всі таблиці, щоб наша таблиця Department з'явилась тут. У нас є первинний ключ Department ID. У нас є ім'я Департаменту, і у нас є короткий опис Департаменту. Цей стовпець description, або ж опис, в принципі, не обов'язковий. Я його сюди додав, щоб наша таблиця просто виглядала трішки більш формальною. Давайте тепер запишемо в цю таблицю назви відділів, звичайно ж, використовуючи первинний ключ, тобто стовпець, який у нас називається Department ID, з типом Integer. І сюди ми вставимо наступні значення. Я теж наперед уже заготовив ці значення, які ми сюди додамо. Елемент з первинним ключем один буде називатись Маркетинг. Первинний ключ два буде відповідальний за Sales, тобто відділ продажів, третій - це IT, і четвертий - це HR, тобто Human Resources, або ж відділ кадрів. Давайте ми все оце виділимо і виконаємо цю команду. Тепер у нас в таблиці Department є чотири відділи. Давайте я вам покажу, що вони дійсно у нас тут є. Select Rows. Наступний крок - у першій таблиці, у таблиці, яка називається Employee, зайдемо в режим редагування. Натиснемо ось тут Alter Table, тобто змінити таблицю. Так, закриємо нижню панель. Додамо сюди новий стовпець, який буде називатись Department ID. Я думаю, вже зрозуміли. І він буде у нас типом Integer, тобто ціле число. Якщо ви пам'ятаєте, у нас є такий же стовпець з таким же іменем в стовпці, який називається Department. І нам треба, щоб їх типи даних в обох таблицях співпадали. Зараз ви зрозумієте, чому. Тобто, чому ми вказали тут тип Integer. Тепер нам стовпець, який називається Department, вже не потрібен. Давайте ми його просто видалимо. Delete Selected. І натиснемо кнопку Apply. Ще раз Apply, щоб зберегти зміни, і натиснемо Finish. Те, що я щойно виконав, тобто додав новий стовпець, ми, звичайно ж, могли би виконати за допомогою коду. Тобто ми могли би написати наступний рядок коду. Я вам просто покажу, як би він виглядав. Але ми це зробили за допомогою візуальних, або ж графічних інструментів програми Workbench, тому ця команда нам поки що не потрібна. Ви, звичайно ж, можете використовувати або перший, або другий спосіб. Тепер нам потрібно прив'язати ці стовпці один до одного. Що я маю на увазі? Нам потрібно сказати, що у таблиці Employee стовпець, який називається Department ID, буде прив'язаний логічно до ось цього стовпця в таблиці Department. Я знаю, може виглядати спочатку трішки заплутано, але, якщо ви подивитесь уважно і прочитаєте коментарі, які я тут додав.
[21:13]Ці коментарі я додав спеціально, щоб вам було легше зрозуміти цей процес. Так, давайте ми ось цю команду зараз виконаємо. Натиснемо сюди. Готово. Тепер ось це я поки що видалю. Тепер я клацну ось тут правою кнопкою мишки і виберу опцію Select Rows, щоб отримати всі записи із таблиці Employee. Як ви бачите, стовпець Department ID у нас має порожні записи. Давайте ми сюди додамо якісь значення для потрібних нам відділів. Давайте ми сюди так додамо: один, тепер два, тепер три, чотири, і ще раз три. І натиснемо ось тут Apply, тобто застосувати наші зміни. Apply і Finish. Тепер у нас є повноцінна реляційна база даних з двома таблицями, які мають між собою логічний зв'язок і використовують первинний і зовнішній ключі. І в таблиці Employee, тобто ось тут, стовпець Department ID є зовнішнім ключем. Далі ви можете запитати, як тепер нам в запиті отримати не значення первинного ключа, тобто не числа ось тут, а власне ім'я відділу, коли ми напишемо запит, наприклад, Select. Це робиться дуже і дуже просто за допомогою ключового слова Join, яке означає об'єднати, і дає нам можливість в одному записі Select отримувати дані з двох або більше пов'язаних таблиць. І такий запит виглядав би наступним чином. Я теж скопіюю, щоб не тратити наш час. Команда Select. Потім ми вказуємо, які саме стовпці ми хочемо отримати. Далі з якої таблиці. І потім ми використовуємо такий елемент, який називається Inner Join. Тобто ми кажемо, що з таблиці Employee ми хочемо отримати ось ці стовпці, і з таблиці Department ми хочемо отримати стовпець, який називається Name. У таблиці Department у нас є стовпець, який називається Name, де записано ім'я, або ж назва цього відділу. Спеціальна команда Inner Join в SQL дозволяє нам об'єднати записи з двох таблиць. Але про цю команду ми детально поговоримо в одному з наступних відео. Я вам в деталях покажу і поясню, як писати такі запити. Тепер, якщо я поставлю курсор тут і виконаю ось цю команду. У нас з'являться ось тут всі записи з цієї таблиці і також у нас буде ім'я відділу, в якому працює кожен із робітників. Не ID, не первинний ключ, а власне ім'я. Давайте це поки що закриємо. Останнє, що я вам хочу показати - це ще один цікавий момент із зовнішнім ключем. Цей стовпець, який називається Department ID в таблиці Employee, ми можемо записати лише ті значення, які існують в прив'язаному стовпці Department ID в таблиці Department. Тобто в таблиці Department, в стовпці, який називається Department ID, у нас є лише значення від одного до чотирьох. І лише ці значення ми можемо записати у стовпець Department ID в таблиці Employee. Якщо, наприклад, в таблиці Employee у стовпець Department ID я спробую записати значення 101, а такого первинного ключа в таблиці Department не існує, то база даних закономірно не дозволить мені цього зробити. Давайте я вам покажу. Наприклад, я спробую додати нового робітника, наприклад, з первинним ключем шість, його буде звати Іван Барабан, 45 років, і зовнішній ключ Department ID, який буде відсилатись на ось цю таблицю, буде 101.
[24:26]Тобто неіснуючий первинний ключ з таблиці Department ID. Тепер, якщо я спробую запустити ось цю команду, натиснувши ось тут, програма MySQL Workbench видає мені помилку. Cannot add or update a child row, a foreign key constraint fails. Тобто, це означає, що constraint, або обмеження, зовнішнього ключа, яке ми додали попередньо, забороняє нам додавати запис із первинним ключем, якого не існує у таблиці Department. Тобто ми спробували додати зовнішній ключ із значенням 101, але такого первинного ключа у таблиці Department ID не існує. Цей принцип у базах даних називається Referential Integrity, що можна перекласти десь приблизно, як достовірність посилання. Оскільки таблиця Employee у стовпці Department ID посилається, або ж відсилається на таблицю на ім'я Department, а точніше, на її первинний ключ, то було б якось дивно, якби ми посилались на неіснуюче значення. Саме тому, щоб уникнути ситуації, коли зовнішній ключ не існує, кожного разу, коли ви додаєте зовнішній ключ в таблицю, база даних автоматично перевіряє, чи первинний ключ, прив'язаний до цього зовнішнього ключа, існує у прив'язаній таблиці.
[25:37]Як у ось цьому випадку. Коли ми додавали запис в таблиці Employee із зовнішнім ключем один для Department ID, база даних ішла у таблицю Department ID автоматично, звичайно ж, невидимо для нас, і перевіряла, чи таке значення існує дійсно у таблиці, яка називається Department. А щойно, коли ми спробували додати запис із значенням 101, база даних також пішла у таблицю, яка називається Department, і подивилась, що значення 101 там немає, і заборонила нам додавати весь ось цей запис. Це ще один автоматичний механізм контролю за якістю даних у базі даних, про який я говорив на початку цього курсу, коли розповідав про переваги баз даних над текстовими файлами або таблицями Excel. Окей. Первинний ключ і зовнішній ключ - це те, що робить реляційні бази даних реляційними. Тобто це відео - одне з ключових в цьому курсі. Якщо ви його добре зрозумієте і засвоїте, то можна буде сказати, що ви знаєте, як працюють реляційні бази даних. Звичайно ж, попрактикуйтесь зі створенням зовнішнього ключа і зв'язків між таблицями. Наприклад, створіть таблицю автомобіль, де буде інформація про автомобілі, якими володіє ваша компанія. І зробіть так, щоб колір автомобіля, наприклад, або його модель, був зовнішнім ключем. Якщо матимете запитання чи відгуки, додавайте в коментарі. Також, якщо ви ще не підписались, підписуйтесь до нашого каналу, і ми будемо дуже вдячні вам за поширення наших відео і інформації про канал серед ваших друзів та знайомих. Почуємось.
