Отношение «один ко многим» в базе данных происходит, когда каждая запись в таблице A может иметь много связанных записей в таблице B, но каждая запись в таблице B может иметь только одну соответствующую запись в таблице A. Отношение «один ко многим» в база данных является наиболее распространенной реляционной базой данных и лежит в основе хорошего дизайна.
Рассмотрите связь между преподавателем и курсами, которые они учат. Учитель может преподавать несколько курсов, но курс не будет иметь те же отношения с учителем.
Поэтому для каждой записи в таблице «Учителя» в таблице «Курсы» может быть много записей. Это отношение «один ко многим»: один учитель на нескольких курсах.
Почему важно установить отношение «один ко многим»
Чтобы представить отношения «один ко многим», вам нужно как минимум две таблицы. Давайте посмотрим, почему.
Возможно, мы создали таблицу, в которой мы хотели записать имя и курсы. Мы могли бы спроектировать его так:
| Teacher_ID | Имя учителя | Курс |
|---|---|---|
| Teacher_001 | Кармен | Биология |
| Teacher_002 | вероника | математический |
| Teacher_003 | Jorge | английский |
Что, если Кармен преподает два или более курсов? У нас есть два варианта с этим дизайном. Мы могли бы просто добавить его к существующей записи Кармен, например:
| Teacher_ID | учитель_Название | Курс |
|---|---|---|
| Teacher_001 | Кармен | Биология, математика |
| Teacher_002 | вероника | математический |
| Teacher_003 | Jorge | английский |
Однако вышеприведенная конструкция негибкая и может привести к проблемам позже при попытке вставить, отредактировать или удалить данные.
Это затрудняет поиск данных. Эта конструкция нарушает первый принцип нормализации базы данных, First Normal Form (1NF), который гласит, что каждая ячейка таблицы должна содержать единую дискретную часть данных.
Другой альтернативой дизайна может быть просто добавление второй записи для Carmen:
| учитель_Я БЫ | учитель_Название | Курс |
|---|---|---|
| Teacher_001 | Кармен | Биология |
| Teacher_001 | Кармен | математический |
| Teacher_002 | вероника | математический |
| Teacher_003 | Jorge | английский |
Это соответствует 1NF, но все еще плохой дизайн базы данных, поскольку он вводит избыточность и может раздувать очень большую базу данных без необходимости. Что еще более важно, данные могут стать непоследовательными. Например, что, если имя Кармен изменилось? Кто-то, кто работает с данными, может обновить свое имя в одной записи и не обновить его во второй записи. Эта конструкция нарушает вторую нормальную форму (2NF), которая придерживается 1NF и также должна избегать избыточности нескольких записей, разделяя подмножества данных на несколько таблиц и создавая отношения между ними.
Как создать базу данных с отношениями «один-ко-многим»
Чтобы внедрить отношения «один ко многим» в таблице «Учителя и курсы», мы разбиваем таблицы на две части и связываем их с помощью внешнего ключа.
Здесь мы удалили столбец «Курс» в таблице «Учителя»:
| учитель_Я БЫ | учитель_Название |
|---|---|
| Teacher_001 | Кармен |
| Teacher_002 | вероника |
| Teacher_003 | Jorge |
И вот таблица «Курсы». Обратите внимание, что его внешний ключ, Teacher_ID, связывает курс с учителем в таблице Учителей:
| Course_ID | Название курса | Teacher_ID |
|---|---|---|
| Course_001 | Биология | Teacher_001 |
| Course_002 | математический | Teacher_001 |
| Course_003 | английский | Teacher_003 |
Мы разработали связь между таблицей Учителей и Курсов с использованием внешнего ключа.
Это говорит нам о том, что и биология, и математика преподаются Кармен и что Хорхе преподает английский.
Мы можем видеть, как эта конструкция позволяет избежать любых возможных увольнений, позволяет отдельным преподавателям преподавать несколько курсов и реализует отношения «один ко многим».
Базы данных также могут реализовывать отношения «один к одному» и отношения «многие ко многим».
