Ответы Mail.ru
Программирование
Android
C/C++
C#
iOS
Java
JavaScript
jQuery
SQL
Perl
PHP
Python
Веб-дизайн
Верстка, CSS, HTML, SVG
Системное администрирование
Другие языки и технологии
Лидеры категории
Лена-пена
М.И.
Y.Nine
•••
Искусственный Интеллект
Искусственный Интеллект
Искусственный Интеллект
1 ответ
Андрей
(428366)
1 неделю назад
У тебя множество лекарств в одной продаже и множество продаж одного лекарства. Обычная связь многие-ко-многим, реализуемая на уровне физической базы данных отдельной таблицей связи. Но на уровне логической модели (idef1x) никакой таблицы нет - есть только чёрные кружки на обоих концах линии, соединяющей Лекарство и Продажа.
Кирилл КашировУченик (96)
1 неделю назад
Спасибо за ответ, но не до конца понял последнее предложение. Разве на логическом уровне мы не проектируем абстрактную модель с таблицами для баз данных?
Андрей
Высший разум
(428366)
Кирилл Каширов, Нет, на логическом уровне мы описываем структуру целевых данных (бизнем-модель), но не способ хранения этих данных в БД.
На уровне бизнес-модели у нас есть только связь многие-ко-многим. А то, что для физической реализации этой связи требуется дополнительная таблица - это особенность реляционных баз данных, а не логической модели.
Похожие вопросы
Ситуация следующая, я делаю модель для информационной системы аптеки и мне нужно соединить две таблицы Лекарство и Продажа, тут я несколько запутался. Так как у меня по сути может быть несколько Лекарств в одной продаже, то казалось бы можно было бы соединить эти две таблицы идентификационной связью (одна продажа ко многим лекарствам), но тогда первичный ключ от продажи у меня попадет в таблицу лекарства, в этом нет логики. Если я соединяю наоборот, то у меня получается что множество продаж соответствует одному лекарству, что тоже некорректно в моей ситуации. Теперь вопрос. Насколько уместно будет использовать тут ассоциативную таблицу для решения сложившейся ситуации? И насколько правильно эта таблица выполнена на приложенном скрине?