Базисните връзки са гръбнакът на всички релационни бази данни
Съществува връзка между две таблици на база данни, когато една таблица има чужд ключ, който препраща към основния ключ на друга таблица. Това е основното понятие зад терминологичната релационна база данни.
Как работи чужд ключ за установяване на връзка
Нека разгледаме основите на основните и чужди ключове. Първичният ключ уникално идентифицира всеки запис в таблицата. Това е тип ключ за кандидат, който обикновено е първата колона в таблицата и може автоматично да се генерира от базата данни, за да се гарантира, че тя е уникална.
Чуждият ключ е друг кандидатски ключ (а не първичният ключ), използван за свързване на запис с данни в друга таблица.
Например, разгледайте тези две таблици, които определят кой учител учи кой курс.
Тук основният ключ на таблицата "Курсове" е Course_ID. Неговият чужд ключ е Teacher_ID:
Course_ID | COURSE_NAME | Teacher_ID |
---|---|---|
Course_001 | Биология | Teacher_001 |
Course_002 | Math | Teacher_001 |
Course_003 | Английски | Teacher_003 |
Можете да видите, че чуждестранният ключ в курсовете съвпада с първичен ключ в Учители:
Teacher_ID | TEACHER_NAME |
---|---|
Teacher_001 | Кармен |
Teacher_002 | вероника |
Teacher_003 | Хорхе |
Можем да кажем, че чужд ключът Teacher_ID помогна да се установи връзка между таблиците "Курсове" и "Учители".
Видове бази данни
Чрез чужди ключове или други кандидатски ключове можете да приложите три вида взаимоотношения между таблици:
Един към един : Този тип взаимоотношения позволява само един запис от всяка страна на връзката.
Първичният ключ се отнася само до един запис - или не - в друга таблица. Например, при брак всеки съпруг има само един друг съпруг. Този вид взаимоотношения може да се приложи в една таблица и следователно не използва чужд ключ.
Еднозначни : Отношението "един към много" позволява един запис в една таблица да бъде свързан с множество записи в друга таблица.
Обмислете бизнес с база данни, която има таблици за клиенти и поръчки.
Един клиент може да закупи няколко поръчки, но една поръчка не може да бъде свързана с няколко клиента. Поради това таблицата Поръчки ще съдържа чужд ключ, който съответства на основния ключ на таблицата "Клиенти", докато таблицата "Клиенти" няма да има чужд ключ, посочващ таблицата "Поръчки".
Много от много : Това е сложна връзка, в която много записи в таблица могат да се свързват с много записи в друга таблица. Например, бизнесът ни вероятно не се нуждае само от таблици за клиенти и поръчки, но вероятно също така се нуждае от таблица Продукти.
Отново връзката между таблицата "Клиенти и поръчки" е една към много, но разгледайте връзката между таблицата "Поръчки и продукти". Поръчката може да съдържа няколко продукта и даден продукт може да бъде свързан с няколко поръчки: няколко клиенти могат да подадат поръчка, която съдържа някои от същите продукти. Този тип взаимоотношения изисква най-малко три маси.
Какво представляват връзките с базата данни?
Създаването на последователни взаимоотношения между таблиците на базата данни спомага за гарантирането на целостта на данните, допринасяйки за нормализирането на базата данни. Например, ако не свържехме таблици с чужд ключ и вместо това просто събрахме данните в таблиците "Курсове и учители", както е така:
Teacher_ID | TEACHER_NAME | курс |
---|---|---|
Teacher_001 | Кармен | Биология, Математика |
Teacher_002 | вероника | Math |
Teacher_003 | Хорхе | Английски |
Този дизайн е нееластичен и нарушава първия принцип на нормализирането на базата данни, First Normal Form (1NF), който гласи, че всяка клетка на таблицата трябва да съдържа единична, отделна част от данните.
Или може би решихме просто да добавим втори рекорд за Кармен, за да наложим 1NF:
Teacher_ID | TEACHER_NAME | курс |
---|---|---|
Teacher_001 | Кармен | Биология |
Teacher_001 | Кармен | Math |
Teacher_002 | вероника | Math |
Teacher_003 | Хорхе | Английски |
Това все още е слаб дизайн, който въвежда ненужно дублиране и това, което се нарича аномалия за вмъкване на данни , което просто означава, че може да допринесе за непоследователни данни.
Например, ако учителят има няколко записа, какво ще стане, ако някои данни трябва да бъдат редактирани, но лицето, което извършва редактирането на данни, не осъзнава, че съществуват множество записи? Таблицата ще съдържа различни данни за едно и също лице, без да има ясен начин да го идентифицира или да го избегне.
Прекъсването на тази таблица в две таблици, учителите и курсовете (както е визуализирано по-горе), създава правилната връзка между данните и по този начин помага да се осигури последователност и точност на данните.