- Связи или отношения в моделях
вязи (отношения) между сущностями в реляционных моделях данных, связи "один к одному", "один ко многим", "многие ко многим"
В реальных СУБД модель данных, кроме атрибутов каждой сущности определяет также связи между сущностями. Связи формально определяются как ассоциации между участниками. Например, утверждение "покупатели покупают продукты" указывает, что существует связь между сущностью "покупатели" и сущностью "продукты".
Число участников определяет размерность связи. У большей части отношений - два участника, хотя на практике их может быть и больше, например, в утверждении: "сотрудники продают товары покупателям" видна тройная связь.
Иногда сущность оказывается связана сама с собой. Обычно подобные связи характерны для иерархических структур, когда сотрудник может подчиняться менеджеру и одновременно являться менеджером для других сотрудников.
Существует несколько типов связей между сущностями: "один к одному", "один ко многим" и "многие ко многим".
Связь "один к одному" встречается редко. Например, у нас есть таблица с информацией о всех сотрудниках и таблица с информацией о всех торговых агентах, которые являются сотрудниками нашего предприятия. Записи в таких таблицах могут быть связаны отношением "один к одному".
Связь "один ко многим" - наиболее распространенный тип связей. Например, один торговый агент может выписывать много счетов и т.п.
Очень часто используется и связь "многие ко многим". Например, один покупатель может покупать товары нескольких видов, и при этом товар одного вида может "покупаться" разными покупателями. Обычно в СУБД возможности явно определить отношение "многие-ко-многим" нельзя, но это часто делается обходным способом.
Участие каждой сущности в связи может быть полным или частичным. Пример - наша связь "сотрудник - торговый агент". Со стороны торгового агента эта связь полная, потому что торговый агент не может не быть сотрудником предприятия. Со стороны сотрудника эта связь - частичная, поскольку сотрудник вполне может не быть торговым агентом.
Один из самых сложных моментов при проектировании базы данных - продумать, что будет со связями при различных изменениях в системе. Например, сотрудник может перейти из подразделения в подразделения, товары вначале могут покупаться у одного поставщика, а затем у другого и т.п.
