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