А почему сразу не рисовать диаграмму в родной СУБД?
Зачем этот промежуточный шаг?

неубедительно.
нарисую в erwin
потом при при переходе к конкретной субд получу кучу неточностей
и буду их править уже в рамках субд

Не нужна мне ни концептуальная ни логическая.
Достаточно, например, такой картинки.

авторв ней ни сути не характера ни воплощения не видно
вы из филологии или искусствоведения?

именно так
без характера и воплощения

спасибо за напутствие в дорогу.
вы меня позабавили

Разберём комментарии alexeyvg:
авторА вы за ошибки проектирования сами платите или фирма? :-)

Ответа не заслуживает.
авторЭто картинка (Database Diagrams) из средства проектирования, встроенного в комплект микрософтовского софта для работы с сервером. Так что картиночка-то тоже из средства проектирования БД.

Совершенно верно, я всего лишь утверждал,что почти все СУБД имеют такой собственный инструмент. Им и надо пользоваться. В противном случае Вас ждёт конверсия из CASE средства типа erwin в native базу данных, которая будет выполнена нечисто. И доработка в среде СУБД всё равно вас ждёт.
авторКроме этого софта, есть и другие средства проектирования, в т.ч. и у микрософта.
Ломимся в открытую дверь.
авторЕсли вы выбрали именно это средство, незачем кричать всем, что оно самое удобное, производительное, полное, лучьше всего позволяет организовать работу компании.
Неподходящий глагол "кричать". Я не утверждал, что "оно самое удобное, производительное, полное, лучьше всего позволяет организовать работу компании". Я утверждал, что применение не родных (не заточенных) на конкретную БД средств приведёт к лишней работе по доработке БД средствами родной СУБД. В 2000-2002 гг.группа из 3 человек (я в том числе) создали АСУ нашего ВУЗа. 185 таблиц. Сильная связность. 13 клиентов. ~500 процедур и функций. В общем задача не самая сложная, бывает хуже, но и не простая. Первоначальный проект БД делали в ERWIN 3.5, после чего дали зарок не подходить к ней близко, т.к. всё пришлось дорабатывать, и довольно долго.
Моё утверждение звучит так: целесообразнее пользоваться построителем диаграмм, входящим в целевую БД. Могут быть исключения - гетерогенные и/или нереляционные БД.
авторВсё таки выбранная вами программа совсем убога.
это утверждение совсем вас дискредитирует, видимо вы не знакомы с ms sql server, это ещё не грех, но и не повод для гордости.

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

наконец то - первый разумный комментарий.
авторДругие верят, что в течении разработки ПО выясняется куча новой информации, о которой сам заказчик не подозревал, или забыл, или передумал.
- да, я никогда не видел БД, которая не изменялась бы в течение жизни.
Конечно, для оч. больших коллективов нужны team средства.
Я лично с такой ситуацией дела не имел. БД всегда разрабатывалась силами 1-3 человек. И рады бы были увеличить число разработчиков, но это не поддавалось распараллеливанию. Как говорил доктор Хасс в МЕРТВОМ СЕЗОНЕ - если 9 беременных женщин собрать вместе, то ребёнок не родится через месяц.
Кроме того, то о чём вы говорите скорее средство коллективного доступа к результатам разработки, а не само средство разработки. Это бесспорно очень нужно в первую очередь кодерам.
Можете ли предложить ещё какие то ситуации в которых было бы целесообразно применение CASE средств именно разработки.

я понял так что Вы более или менее подтверждаете мою точку зрения.
Надо придумать такую провокацию, чтобы на меня набросились оппоненты.
Меня тут как то поклевали за мою ересь. Однако ничего кроме эмоций не предложили.
Я начал думать что я чего то недопонимаю.
Может быть.
Начиная с 70-х я читал слова "концептуальная модель" "инфологическая" "даталогическая". В те времена какой то смысл в этом был. Сейчас я его не вижу. Разве что как средство изложить свои ещё очень сырые соображения.