Доброго времени суток, читатели, зрители моего канала programmer's notes. Не забывайте подписываться и писать свои комментарии к моим статьям и видео.
Приложение к видео
Проектирование реляционных баз данных. Атрибуты становятся таблицами
Мы продолжаем рассматривать тему проектирования реляционных баз данных. И это вторая статья (см. первую здесь), в которой мы рассматриваем то, как атрибут сущности (таблицы) может стать сущностью (таблицей).
В прошлой статье мы выявили две причины, по которым атрибут становится таблицей:
- Когда атрибут состоит из производного количества компонентов.
- Когда атрибут изменяется (может изменяться) во времени.
При этом каждый раз мы должны соотнести выше представленные признаки с тем, какую задачу мы решаем. Если нам не важна история адресов объектов или субъектов, то нет смысла делать адрес сущностью.
Сегодня ещё рассмотрим некоторые признаки того, что атрибут должен стать сущность. Смотрим рисунок 1
Нас интересует атрибут группа.
Первый вариант рассуждений.
Да, группа это как бы такая метка для студента. Но группа связана с учебным процессом вообще. Например с расписанием занятий, нагрузкой преподавателей. факультетом, специальностью. Если во всех указанных случаях рассматривать группу, как простой атритбут, то мы получим одно и то же значение атрибута в разных таблицах. Такое дублирование может просто привести к путанице. Такая проблема разрешается только тем, что такой атрибут должен стать сущностью (таблицей). Получаем (см. рисунок 2)
Второй вариант рассуждений.
Рассмотрим таблицу Студенты. Как известно группы состоят из многих студентов. Следовательно, в таблице будет много строк, где значение атрибута группа будет одинаковым. Это опять же дублирование, но в пределах одной таблицы. Получается, что строки таблицы группируются. Такое дублирование всегда предполагает появление ошибок, которые приводят к перепутыванию значений атрибутов. Всегда удобнее брать данные из готового проверенного списка. В этом смысле список групп более первичен, чем список студентов, и следовательно группа самостоятельная сущность. Так что есть смысл поместить группы в отдельную таблицу.
Третий вариант рассуждений.
Это рассуждение я не приводил в видеоуроке. Оно относится в большей степени к следующему видеоуроку. Всё дело в том, что если мы хотим сохранить историю учёбы студентов, расписаний, нагрузки преподавателей и соответственно участие во всём этом групп студентов, мы должны иметь группы, как самостоятельную таблицу. В этом случае сущность Студенты и сущность Группы будут связаны друг с другом по принципу многие ко многим. У нас тогда появляется возможность сохранить историю того, как студент переходил из одной группы в другую. Но, одновременно, мы же можем и хранить историю того, как менялась сама система групп в вузе. Но об этом будет следующий видеоурок и, естественно, текстовое к нему приложение. Мне могут возразить, что об этом уже говорил, так как речь идёт о сохранении истории изменений. Да, но есть определённая специфика. О ней в следующий раз.
Ну, пока всё!
Пишите свои предложения и замечания и занимайтесь программированием, а также проектированием баз данных, хотя бы для поддержания уровня интеллекта.