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