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