Добрый день!

Ищу наиболее удобную нотацию и программу для моделирования схем (диаграмм) баз данных.
Нужно задокументировать существующие БД, и спроектировать новые БД.
Подскажите пожалуйста: кто чем пользуется?

1) Какая графическая нотация (язык графического моделирования) является наиболее информативным (наглядным, понятным, удобочитаемым) для представления схемы базы данных?
Желательно, чтобы эта нотация поддерживала категоризацию дочерних таблиц.
Некоторые нотации схемы БД не поддерживают категоризацию. Хотя, мне кажется, что отображение категоризации на схеме значительно улучшает ее восприятие и понимание.

2) Какой инструмент (средство, программное обеспечение) моделирования и проектирования схем базы данных является наиболее удобным?
Чтобы этот инструмент поддерживал нужную нотацию.
Желательно, чтобы этот инструмент "умел" автоматически строить связи между таблицами, первичные и внешние ключи.
Да и чтобы в нем просто было удобно работать.

Знаю, что есть много разных инструментов. Можно рисовать схему и на бумаге карандашом.
Можно использовать что-то простое: Visio, yEd, даже Paint.
Есть "профессиональные" инструменты типа PowerDesigner, EnterpriseArchitect, ERWin. И много других.
Какой из них вы считаете самым удобным?
Какую нотацию схемы БД вы считаете самой наглядной?

[Вероятно, имеются в виду реляционные БД.]
[Далее следует порция трындежа, который худо-бедно связан с заданными вопросами, но не даёт на них ответа.]
Инструмент (программу) можно подбирать под задачу. Например, чтобы она из имеющихся DDLей сама рисовала что-то удобоваримое, а после перерисовывания генерила новые версии DDL, и чем, чёрт не шутит, помогала рефакторить содержимое БД. Как следствие, такие полезные свойства инструмента могут помочь смириться с несовершенством поддерживаемой нотации.
Можно ставить в вершину угла выразительные возможности нотации (и, как следствие, мириться с несовершенством инструмента, который её поддерживает).
У нотации полно других свойств, которые могут быть важны (и даже быть важнее выразительных возможностей). Например, если нотация привычна Вашим коллегам, то они с бОльшим энтузиазмом воспримут Ваши диаграммы.
[Тут трындёж как бы заканчивается.]
Мне привычен UML. К нему есть профиль, предложенный на сайте Скотта Амблера. С помощью этого профиля можно приспособить стандартную UML-диаграмму классов к моделированию схемы реляционной БД. Амблер не приводит пример с категоризацией, но в актуальной версии UML есть такие штуки как Generalization Set с Power Type-ами. Это позволяет наUMLылить что-то похожее на IDEF1X-ные categorization-отношения.
Недостатков такого решения прорва:
- инструмент для перевода с/в DDL в/с UML почти наверняка не существует;
- приспособленные UML-диаграммы классов не привычны разработчикам БД, они откажутся их читать;
- пляски с Generalization Set и Power Type-ами лишь отдалённо напоминают то, что было в IDFE1X.

[Вероятно, имеются в виду реляционные БД.]

Да, конечно.

Можно ставить в вершину угла выразительные возможности нотации

Именно это для меня важнее. По крайней мере пока.

Мне привычен UML. К нему есть профиль, предложенный на сайте Скотта Амблера. С помощью этого профиля можно приспособить стандартную UML-диаграмму классов к моделированию схемы реляционной БД. Амблер не приводит пример с категоризацией, но в актуальной версии UML есть такие штуки как Generalization Set с Power Type-ами. Это позволяет наUMLылить что-то похожее на IDEF1X-ные categorization-отношения.
Недостатков такого решения прорва:
- инструмент для перевода с/в DDL в/с UML почти наверняка не существует;
- приспособленные UML-диаграммы классов не привычны разработчикам БД, они откажутся их читать;
- пляски с Generalization Set и Power Type-ами лишь отдалённо напоминают то, что было в IDFE1X.

Интересное решение. Но я вижу в нем еще один минус.
Здесь в отношениях нету информации о ключах и полях, с помощью которых "реализуется" эта связь.

Нашел программу Aqua Data Studio.
Вроде бы все в ней есть, судя по описанию. Но работает как-то криво.

Здесь в отношениях нету информации о ключах и полях, с помощью которых "реализуется" эта связь.

[в продолжение трындежа]
У Амблера для этого предусмотрены метасвойства/tagged values у столбцов, помеченных как внешние ключи (<<FK>>).

У Амблера для этого предусмотрены метасвойства/tagged values у столбцов, помеченных как внешние ключи (<<FK>>).

Это я понял. Но это свойства _столбцов_.
А я имел ввиду, что у самой связи (то есть у линии, связывающей две сущности) нету информации о ключах (столбцах), по которым осуществляется эта связь.
Ну в общем, как-то мне не очень эта идея.

Что-то еще можете порекомендовать?

А я имел ввиду, что у самой связи (то есть у линии, связывающей две сущности) нету информации о ключах (столбцах), по которым осуществляется эта связь.
Ну в общем, как-то мне не очень эта идея.

После уточнения прояснилось, в чём именно видится дефект. Чтобы отразить эти сведения, можно допилить профиль и переложить эти tagged values в стереотипы для связей.

В копилку "не очень идей": рисовать в Visual Paradigm и моделировать категоризацию тем способом, который предложен разрабами VP. Красивые картинки a la IDEF1X получать экспортируя диаграммы в "рисовалки" вроде Visio, где явно пририсовывать категоризацию. Не думаю, что стоит так мучиться, но ничего другого не могу предложить.

Нотаций моделирования есть множество. Но под реляционные БД наиболее заточена IDEF1x. Исходя из этого, нужно просто подбирать инструмент, который полно реализует эту нотацию. Среди таких мне нравится Erwin. Но есть и другие аналоги, В том числе и Visiual Pradigm и другие. Вопрос что нужно от инструмента? Автогенерация кода, прямой и обратный инжиниринг. В конце концов у каждой СУБД есть средства представления схемы БД.

Вопрос что нужно от инструмента? Автогенерация кода, прямой и обратный инжиниринг.

Нет, ничего этого не нужно.
Нужны только максимальная наглядность схемы и максимальное удобство "рисования" схемы.

В конце концов у каждой СУБД есть средства представления схемы БД.

СУБД нету никакой. Пока нужно создать логическую схему БД.
Логическая схема не привязана к физической структуре и к конкретной СУБД.

Нотаций моделирования есть множество. Но под реляционные БД наиболее заточена IDEF1x. Исходя из этого, нужно просто подбирать инструмент, который полно реализует эту нотацию.

Да, наверно вы правы.
Тогда вопрос так и переформулируем: какой инструмент удобен для создания схем IDEF1X?

...Среди таких мне нравится Erwin. Но есть и другие аналоги, В том числе и Visiual Pradigm и другие.

Спасибо, попробую поискать триальные версии этих продуктов и посмотреть.
Но насчет Erwin... Читал не очень хорошие отзывы про последние версии Erwin.

Но насчет Erwin... Читал не очень хорошие отзывы про последние версии Erwin.

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

Если нуждаетесь в только концептуальном, логическом моделирование, может подойдет просто расширенная модель сущность-связь?

Я ERwin использую (использовал) при обучении студентов на протяжении пары десятилетий (почти). Всегда по циклу:
1 логическая модель
  - представление сущность/связь
  - представление основанное на ключах
  - полноатрибутивное представление (тут надо описание доменов включать)
2 физическая модель
  - суррогатные ключи
  - альтернативные ключи
  - инверсные входы
  - домены (хотя их стоит определить уже на уровне логической модели)
  - представления, триггеры и хранимки
3 прямая генерация схемы (при построении ФМ уже определяешь какая будет СУБД) - мы в учебных целях использовали Access

Товарищ из Нижнего Новгорода полагает, что лучше заходит простая Сущность-связь.

Кто-то утверждал, что идеален Power Designer - не берусь комментировать.

Мы экспериментировали с Visual paradigm (при понимании нотации - инструмент почти не важен).

Erwin вполне доступен по академической версии. Да, но интерфейсно изменился, но простите нотация как была, так и осталась.
Я ERwin использую (использовал) при обучении студентов на протяжении пары десятилетий (почти). Всегда по циклу:
1 логическая модель
  - представление сущность/связь
  - представление основанное на ключах
  - полноатрибутивное представление (тут надо описание доменов включать)
2 физическая модель
  - суррогатные ключи
  - альтернативные ключи
  - инверсные входы
  - домены (хотя их стоит определить уже на уровне логической модели)
  - представления, триггеры и хранимки
3 прямая генерация схемы (при построении ФМ уже определяешь какая будет СУБД) - мы в учебных целях использовали Access

Спасибо, буду изучать.

Если нуждаетесь в только концептуальном, логическом моделирование, может подойдет просто расширенная модель сущность-связь?

Не сталкивался с такой нотацией. Надо посмотреть.
Какие инструменты ее поддерживают?

Не сталкивался с такой нотацией. Надо посмотреть.
Какие инструменты ее поддерживают?

Ну, это родоначальник всех нотаций. Нотация Питера Чена. Инструментальной поддержки особо не встречал. Но особо и не искал. По-моему есть в draw.io, Visio, может еще где.
Сама нотация довольно проста:
1 есть два типа сущностей - сильная (независимая), слабая. Слабая может делиться на идентификационно-зависимая и просто слабая (т.е. нет полной зависимости от первичного ключа родительской сущности.
2 связи есть - просто линии обычно бинарные, но могут быть и большей арности. Связь имеет в центре ромб. В ромбе пишется максимальная кардинальность участвующих в связи сущностей.
Если связь идентификационно-зависимая - ромб с скругленными углами. Минимальная кардинальность изображается на стороне сущности - это или нолик или палочка перпендикулярная - т.е. обязательность или необязательность экземпляра сущности в связи.
3 атрибуты - это овалы, которые прикрепляются к сущности
4 есть еще связь тип подтип - типа наследования

Как-то так