То что отображено в UML не обязательно должно быть в констреинтах DBMS. Другой вопрос, может ли? да может. Например, для связи 1-много (1-1) можно повесить констреинт на уникальность конкретного поля.
Понял что эти связи связаны с внешним ключем, как тогда реализуются эти связи только один, один и более и тд. или "То что отображено в UML не обязательно должно быть"
Может быть преобразовано в структур БД, в зависимости от «лапок» создаются таблицы связей многие ко многим или добавляются поля и соответствующие fk в таблицу объекта.
ага что то понял, спасибо ^^ Читаем дальше )
Связь много-ко-много, как у вас фильмы<->актёры, это обычно отдельная таблица связка. Действительно, её могут на диаграмме не обозначить как таблицу, нарисовав её как связь. Имхо, связи показывают, какие запросы являются нормальными для данной базы. Это контракт. Нарушать контракт можно с обоих сторон: можно сделать базу такую, что "нормальные" запросы нельзя выполнить или они выполняются неэффективно, а с другой стороны, можно пытаться выполнять запросы, которые диаграмма не советует делать. Например, запрос "скажите всех директоров данной компании" ненормальный, потому что на диаграмме нарисовано, что директор только один, но его можно выполнить. А если вы попросите "скажите, в каком фильме играл данный актёр", то это грубое нарушение контракта: нарисовано же, что фильмов может быть много.
Понял спасибо ))
Обсуждают сегодня