Если диаграмма классов содержит только прикладные обьекты она практически совпадает с  ER. На вашей ER используется нотация Чена. На нотациях Чена и Мартина атрибуты выносятся в отдельные графические элементы (это бывает удобно, когда при проектировании велика вероятность выделения атрибута в отдельную сущность) . Нотации crow foot notation и IDEF1X позволяют описывать атрибуты внутри элементов сущностей.

Сделаете ER -без труда сможете преобразовать в диаграмму классов. По крайней мере мере это преобразование несопоставимо по своей трудоемкости с разработкой качественной ER

IDEF1X это не физическая модель БД ?

В последней моей модели ведь есть и сущности и связи и идентификаторы сущностей, атрибуты, операции.
Единственное не уверен в связи "зависимость" между сущностями Товар и Заказ.

Учитывая Ваши ограничения по срокам могу дать наводку - поищите про реализацию связи многие ко многим в реляционных БД

Учитывая Ваши ограничения по срокам могу дать наводку - поищите про реализацию связи многие ко многим в реляционных БД

Примерно так:
Группа и Сотрудник - многие ко многим.
Тренинг и Сотрудник - многие ко многим

IDEF1X это не физическая модель БД ?

Нет. В любой нотации можно разрабатывать ER модель разного уровня абстракции

IDEF1X это не физическая модель БД ?

По ранее представленной ссылке Вы можете найти ответ. IDEF1X - этот система моделирования максимально адаптирована для создания реляционных моделей данных. Реляционная модель данных - это не физическая модель БД.

По ранее представленной ссылке Вы можете найти ответ. IDEF1X - этот система моделирования максимально адаптирована для создания реляционных моделей данных. Реляционная модель данных - это не физическая модель БД.

Спасибо за ссылку, уже начал читать статью.
Я просто уже запутался в этих моделях, мне нужно сделать и концептуальную модель и физическую модель и логическую.
Во всех примерах, что у меня есть от других студентов эти модели крайне похожи, ровно те же таблицы, те же атрибуты, те же связи.
Единственное различие - в концептуальной атрибуты написаны русским текстом, а в физической английским.

Еще один вопрос: должны ли в концептуальной модели быть все таблицы как в БД? Или все же я в чем то прав и в ней используются основные сущности?
Т.е. в ней не надо указывать, например, сущность "производитель товара".

Нет. В любой нотации можно разрабатывать ER модель разного уровня абстракции

Спасибо, а то я путаюсь уже (

Спасибо за ссылку, уже начал читать статью.
Я просто уже запутался в этих моделях, мне нужно сделать и концептуальную модель и физическую модель и логическую.
Во всех примерах, что у меня есть от других студентов эти модели крайне похожи, ровно те же таблицы, те же атрибуты, те же связи.
Единственное различие - в концептуальной атрибуты написаны русским текстом, а в физической английским.

Это издержки учебных примеров. В реальных системах отличия видны сразу.

Еще один вопрос: должны ли в концептуальной модели быть все таблицы как в БД? Или все же я в чем то прав и в ней используются основные сущности?
Т.е. в ней не надо указывать, например, сущность "производитель товара".

Концептуальная модель должна отвечать требованиям постановки - в ней должны присутствовать все необходимые  сущности, отражены их отношения, присутвовать атрибуты, упоминаемые в постановке. Концептуальная модель - ЭТО НЕ ЧЕРНОВИК, не модель сделанная спустя рукава.

Концептуальная модель подвергается т.н. интерпретации - она должна отражать все понятия, встречающиеся в постановке

Вы не сможете сослаться в use case или любой другой диаграмме на сущность или атрибут, отсутсвующий в концептуальной модели. Физическая модель как правило дополняется большим количеством технических таблиц, которые не связаны с бизнес-обьектами. Но бизнес-обьекты в концептуальной модели должны быть все

Концептуальная модель должна отвечать требованиям постановки - в ней должны присутствовать все необходимые  сущности, отражены их отношения, присутвовать атрибуты, упоминаемые в постановке. Концептуальная модель - ЭТО НЕ ЧЕРНОВИК, не модель сделанная спустя рукава.

Концептуальная модель подвергается т.н. интерпретации - она должна отражать все понятия, встречающиеся в постановке

Вы не сможете сослаться в use case или любой другой диаграмме на сущность или атрибут, отсутсвующий в концептуальной модели. Физическая модель как правило дополняется большим количеством технических таблиц, которые не связаны с бизнес-обьектами. Но бизнес-обьекты в концептуальной модели должны быть все

Получается, что достаточно трех сущностей, которые я уже пробовал использовать.
Т.к. остальные таблицы в БД это лишь справочники.

Получается, что достаточно трех сущностей, которые я уже пробовал использовать.

Возьмите исходную постановку и все ваши другие диаграммы и проверьте , достаточно или нет. И разберитесь с хранением количества и цены в заказе

Т.к. остальные таблицы в БД это лишь справочники.

В ER нет такого понятия - справочник. Есть сущности и отношения между ними.

На этом я самоустраняюсь. Информации Вам предоставлено более чем достаточно

Возьмите исходную постановку и все ваши другие диаграммы и проверьте , достаточно или нет. И разберитесь с хранением количества и цены в заказе

В ER нет такого понятия - справочник. Есть сущности и отношения между ними.

На этом я самоустраняюсь. Информации Вам предоставлено более чем достаточно

Большое Вам спасибо за разъяснения и потраченное на меня время.

IDEF1X это не физическая модель БД ?

И еще пара слов про различие.

Логические модели (или концептуальные, или какие угодно "бумажные") отражают информационные сущности (объекты) и связи между ними, которыми оперирует информационная система.

Физическая модель - это то, как информационные сущности были интерпретированы и реализованы в конкретной БД.

Разница может быть очень существенной.

Например, есть у вас 3 очень разных логических сущности: мимопроходимец, покупатель и администратор. Например, характеризуются они следующими атрибутами:

Мимопроходимец:
1. IP последнего посещения
2. Время последнего посещения
3. Количество посещенных страниц

Покупатель:
1. IP последнего посещения
2. Время последнего посещения
3. ФИО
4. Контактные данные
5. Заказы
6. История покупок

Администратор:
1. IP последнего посещения
2. Время последнего посещения
3. ФИО
4. Контактные данные
5. Полномочия

Так вот администратору БД ничего не стоит закатать их всех в одну таблицу БД со следующими полями:

1. IP последнего посещения
2. Время последнего посещения
3. Количество посещенных страниц
4. ФИО
5. Контактные данные
6. Заказы
7. История покупок
8. Полномочия

И в зависимости от того, какую из трех сущностей нужно сохранить, будет заполняться тот или иной набор полей в таблице.

В результате в логической модели будет три сущности и какие-то связи между ними (и другими сущностями), а в физической - только одна.

(приведенный пример ни в коем случае не является руководством к действию)

И еще пара слов про различие.

Логические модели (или концептуальные, или какие угодно "бумажные") отражают информационные сущности (объекты) и связи между ними, которыми оперирует информационная система.

Физическая модель - это то, как информационные сущности были интерпретированы и реализованы в конкретной БД.

Разница может быть очень существенной.

Небольшая ремарка - в ER предполагается третья нормальная форма, а разработчики для обеспечения гибкости,  настраиваемости и т.д. идут на довольно грубую денормализацию

Небольшая ремарка - в ER предполагается третья нормальная форма,

Ну... Никогда не заморачивался, на самом деле. Вот то, под реляционную ли базу рисуется ER, или наоборот (под xml-свалку, например) - это да, это на модели сказывается. Хотя это уже, конечно, не ортодоксальная ER-каллиграфия.

а разработчики для обеспечения гибкости,  настраиваемости и т.д. идут на довольно грубую денормализацию

Медом не корми - дай испортить идеальную модель своими грубыми лапами.

Медом не корми - дай испортить идеальную модель своими грубыми лапами.

Медом не медом, а жизнь себе хотят упростить созданием сущностей типа "всякая хрень, о которой мне лениво думать,  пока проблема себя не обозначила". Всякие там "универсальные справочники", "универсальные классификаторы" - топикстартер норовит в эту помойку аж поставщиков засунуть.

А когда начинаются проблемы с ссылочной целостностью, интерпретационными свойствами,  производительностью поиска оказываются почему -то виноваты аналитики