Отношение «один ко многим» в базе данных возникает, когда каждая запись в таблице A может иметь много связанных записей в таблице B, но каждая запись в таблице B может иметь только одну соответствующую запись в таблице A.
Отношение «один ко многим» в базе данных является наиболее распространенным проектом реляционной базы данных и лежит в основе хорошего проектирования.
Базы данных также могут реализовывать отношения «один к одному» и «многие ко многим».
Пример отношения «один ко многим»
Рассмотрите отношения между учителем и курсами, которые он преподает. Учитель может вести несколько классов, но курс не будет иметь одинаковых отношений с учителем.
Поэтому для каждой записи в таблице «Учителя» может быть много записей в таблице «Курсы». Этот пример иллюстрирует связь «один ко многим»: один преподаватель - несколько курсов.
Почему важно установить связь «один ко многим»
Для представления отношения «один ко многим» вам потребуется как минимум две таблицы. Давайте посмотрим, почему.
Соблюдение дизайна первой нормальной формы
Возможно, мы создали таблицу, в которую хотим записать название и преподаваемые курсы. Мы могли бы создать таблицу «Учителя и курсы» следующим образом:
| Teacher_ID | Teacher_Name | Курс |
|---|---|---|
| Учитель_001 | Кармен | Биология |
| Учитель_002 | Вероника | Математика |
| Учитель_003 | Хорхе | Английский |
Что, если Кармен ведет два или более курсов? У нас есть два варианта с этим дизайном. Мы могли бы добавить его к существующей записи Кармен, например:
| Teacher_ID | Учитель_Имя | Курс |
|---|---|---|
| Учитель_001 | Кармен | Биология, Математика |
| Учитель_002 | Вероника | Математика |
| Учитель_003 | Хорхе | Английский |
Однако приведенный выше дизайн негибок и может привести к проблемам позже при вставке, редактировании или удалении данных. Это затрудняет поиск данных.
Этот дизайн также нарушает первый принцип нормализации базы данных, первую нормальную форму (1NF), которая гласит, что каждая ячейка таблицы должна содержать один дискретный фрагмент данных.
Второе правило нормальной формы
Другим вариантом дизайна может быть добавление второй записи для Кармен:
| Учитель_ID | Учитель_Имя | Курс |
|---|---|---|
| Учитель_001 | Кармен | Биология |
| Учитель_001 | Кармен | Математика |
| Учитель_002 | Вероника | Математика |
| Учитель_003 | Хорхе | Английский |
Этот подход соответствует 1NF, но по-прежнему является плохой структурой базы данных, поскольку он вводит избыточность и может излишне раздувать большую базу данных. Что еще более важно, данные могут стать несогласованными.
Например, что, если имя Кармен изменилось? Кто-то, работающий с данными, может обновить свое имя в одной записи и не обновить его во второй записи.
Этот дизайн нарушает стандарт второй нормальной формы (2NF), который придерживается 1NF и также должен избегать избыточности нескольких записей. Правило 2NF достигает этого, разделяя подмножества данных на несколько таблиц и создавая связь между ними.
Как спроектировать базу данных с отношениями «один ко многим»
Чтобы реализовать связь «один ко многим» в таблице «Учителя и курсы», разбейте таблицы на две и свяжите их с помощью внешнего ключа.
Здесь мы удалили столбец «Курс» в таблице «Учителя»:
| Учитель_ID | Учитель_Имя |
|---|---|
| Учитель_001 | Кармен |
| Учитель_002 | Вероника |
| Учитель_003 | Хорхе |
А вот и таблица курсов. Обратите внимание, что его внешний ключ, Teacher_ID, связывает курс с учителем в таблице «Учителя»:
| Course_ID | Название_курса | Teacher_ID |
|---|---|---|
| Курс_001 | Биология | Учитель_001 |
| Курс_002 | Математика | Учитель_001 |
| Курс_003 | Английский | Учитель_003 |
Мы установили связь между таблицами «Учителя» и «Курсы» с помощью внешнего ключа. Такое расположение говорит нам о том, что Кармен преподает и биологию, и математику, а Хорхе преподает английский язык.
Мы видим, как этот дизайн позволяет избежать любой возможной избыточности, позволяет отдельным учителям преподавать несколько курсов и реализует отношения «один ко многим».
