При проектировании базы данных разработчики долго спорили, какой подход выбрать. В итоге они применили предметный подход, т.к. в их случае решение задачи
«от проблемы» выглядело наиболее подходящим решением. Что разработчики должны были сделать со связями «многие ко многим»? Откуда они были вынуждены брать таблицы? На каком этапе проектирования баз данных применим такой подход? Что еще необходимо сделать на том же этапе проектирования?

• В данном случае связи «многие ко многим» будут заменены промежуточными таблицами, в которые включаются первичные атрибуты соединяемых таблиц. Сами по себе таблицы представляют собой результат замены сущностей, созданных на предыдущих этапах проектирования. Данные преобразования осуществляются на этапе синтеза. Кроме описанных мероприятий, на этапе синтеза необходимо выполнить определение первичных ключей в таблицах.
• В данном случае связи «многие ко многим» будут заменены промежуточными таблицами, в которые включаются первичные атрибуты соединяемых таблиц. Сами по себе таблицы представляют собой результат переноса сгруппированных атрибутов в соответствующую таблицу. Данные преобразования осуществляются на этапе декомпозиции. Кроме описанных мероприятий, на этапе декомпозиции необходимо выполнить определение всех ключей в таблицах.
• В данном случае заменить связи «многие ко многим» не представляется возможным. Сами по себе таблицы представляют собой результат переноса сгруппированных атрибутов в соответствующую таблицу. Данные преобразования осуществляются на этапе декомпозиции. На данном этапе больше никаких действий не предусмотрено.

Другие предметы Колледж Проектирование баз данных проектирование систем обработки данных большие данные подходы к проектированию связи многие ко многим промежуточные таблицы первичные ключи этапы проектирования баз данных синтез данных декомпозиция таблиц атрибуты таблиц Новый