Хочу предложить вниманию участников форума статью, представляющую нотацию для ORM диаграмм. Она основана на Hibernate и ActiveRecord подходах к ORM, а так же UML диаграмме классов и Data Structure Diagram для RDB таблиц.
Статья на английском языке.

Это вводная статья, состоит из описания базовых конструкций и трех views.

Секции:
- Problem
- Solution - основные элементы нотации и views
- Tools
- Conclusion

Хочу обратить внимание, что статья посвящена непосредственно нотации, а не инструментам ее реализующим. Хотелось бы сначала услышать критику этой нотации, внести поправки, а потом уже заниматься реализацией инструментов.
Поэтому буду благодарен за комментарии.

Немного из нашей переписки: вопросы с моей стороны, ответы - Максим.

> Прочитал статью, впринципе идея интересная, но т.к. я плохо знаком с ORM, в частности с Hibernate и пр., мне трудно судить вашу статью.
> Первые впечатлении такие:
> 1. Не увидел как это все генериться в код и генериться ли вообще.

Видимо есть недопонимание, того что предлагается:
предлагается нотация, которая допускает генерацию как модели по
структуре БД (ER) и ORM диаграммы так и генерации ER на основе модели
и ORM диаграммы.
Естественно из полученной диаграммы можно прогенерировать сам код как
таблиц так и классов так и mapping.

> 2. Мне, например, более ближе идея тогда уж MDA, в частности, BOLD & ECO. Уж слишком много у вас надо построить - ДК, ЕР диаграмму и еще ORM диаграмму.

На мой взгляд в процессе проектирования, сейчас тем или иным методом
создаются ДК, ЕР диаграмму, однако ORM генерируется, чот приводит либо
к не идеальной БД либо к не идеальной модели и трудно контролировать,
когда нужно как сам ORM так модель или структуру БД.

> 3. Почему ваш мапинг нельзя сделать обычными средствами диаграмы ЕР или ДК? Просто показать некий связующий мапинг класс в середине, и к нему с одной стороны идут таблицы, с другой классы, а в себе он аккомулирует поля для мапинга.

Можно отрисовать, как я в приципе и сделал на Dia и ArgoUML, но нельзя
полноценно управлять сущностями проектирования: например генерировать
одно из другого, и генерировать как таблицы так и классы так и ORM
mapping.

Видимо есть недопонимание, того что предлагается: предлагается нотация, которая допускает генерацию как модели по структуре БД (ER) и ORM диаграммы так и генерации ER на основе модели и ORM диаграммы. Естественно из полученной диаграммы можно прогенерировать сам код как таблиц так и классов так и mapping.

Да есть не допонимаение. Нигде я не нашел в вашей статье (м.б. не внимательно читал), что предполагается именно это, т.е. генерация модели из ER+ORM или генерация ER из модели+ORM. Тогда идея неплохая.

Вы справедливо заметили, что нет упоминания о генерации модели из ER+ORM или генерации ER из модели+ORM. Это связанно с тем, что я хотел бы сначала вынести на обсуждение саму нотацию, а потом механизмы которые могут быть заложены в инструмент реализующий нотацию.

Большое спасибо за то, что дополнили перепиской статью.

ну я могу лишь ещё раз кратко повторить свои замечания, высказанные ранее в письме.

В введении плохо очерчен контекст задачи. Применение ORM-технологий - не единственный подход, особенно в дата-центричных приложениях, о которых похоже в основном идёт речь.

Не описана проблема, на решение которой направлена данная нотация. "Я пришёл к администратору БД, а он мне - ..., а я ему - ..., а он мне ... и пошёл я с понурой головой" - это не проблема. Как из этой дискуссии вытекает мысль "нам нужен инструмент для ORM-моделирования", мне не понятно.

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

Нотация плохо объяснена с точки зрения назначения. Зачем нужны View?

Зачем вообще нужна нотация, визуализировать очевидное? Не понятно.

Про стилистику, грамматику и орфографию уже не пишу.

ну я могу лишь ещё раз кратко повторить свои замечания, высказанные ранее в письме.

В введении плохо очерчен контекст задачи. Применение ORM-технологий - не единственный подход, особенно в дата-центричных приложениях, о которых похоже в основном идёт речь.

Не описана проблема, на решение которой направлена данная нотация. "Я пришёл к администратору БД, а он мне - ..., а я ему - ..., а он мне ... и пошёл я с понурой головой" - это не проблема. Как из этой дискуссии вытекает мысль "нам нужен инструмент для ORM-моделирования", мне не понятно.

Не могу согласиться с вами, ибо по моему, как раз наоборот я пытался доступно на примере показать зачем это нужно. Генерация ORM не только не решает проблем, а наоборот создает их.
Отсюда речь идет о том, что бы строить ORM как часть архитектуры, а не как часть реализации. Таким образом, полноценно контролировать процесс, не полагаясь лишь на генерацию мето-описания.

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

Совершенно справедливо, может, но не решает проблемы, не идеальной ORM и не дает нормального контроля над описанием ORM на стадии разработки архитектуры.

Нотация плохо объяснена с точки зрения назначения. Зачем нужны View?

View - это больше мои предположения как можно удобнее организовать представление. Я сам склоняюсь к тому, что наиболее существенный это Class centric view.

Зачем вообще нужна нотация, визуализировать очевидное? Не понятно.

Нет, для того чтобы изменить производственный процесс и на стадии разработки архитектуры, настраивать, генерировать, отрисовывать, и так далее ORM.
Получить контроль над ORM в той мере в которой требуется.

Про стилистику, грамматику и орфографию уже не пишу.

Отдавал на проверку и корректуру профессиональному журналисту.

Не описана проблема, на решение которой направлена данная нотация. "Я пришёл к администратору БД, а он мне - ..., а я ему - ..., а он мне ... и пошёл я с понурой головой" - это не проблема. Как из этой дискуссии вытекает мысль "нам нужен инструмент для ORM-моделирования", мне не понятно.

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

Зачем вообще нужна нотация, визуализировать очевидное? Не понятно.

Ну вроде Максим ответил мне на этот вопрос в процессе переписки:

Видимо есть недопонимание, того что предлагается: предлагается нотация, которая допускает генерацию как модели по структуре БД (ER) и ORM диаграммы так и генерации ER на основе модели и ORM диаграммы. Естественно из полученной диаграммы можно прогенерировать сам код как таблиц так и классов так и mapping.

Да есть не допонимаение. Нигде я не нашел в вашей статье (м.б. не внимательно читал), что предполагается именно это, т.е. генерация модели из ER+ORM или генерация ER из модели+ORM. Тогда идея неплохая.

Про стилистику, грамматику и орфографию уже не пишу.

Да, лучше бы на русском ....

View - это больше мои предположения как можно удобнее организовать представление. Я сам склоняюсь к тому, что наиболее существенный это Class centric view.

Что же получается на основе ДК и ORM мы генерируем БД?? А Вы уверены, что в этом случае получиться адекватная БД?? Я бы шел наоборот.

Что же получается на основе ДК и ORM мы генерируем БД?? А Вы уверены, что в этом случае получиться адекватная БД?? Я бы шел наоборот.

Нет, нет, это только view, а не подход.
Я опять повторюсь, мы можем генерировать как диаграмму БД, так и диаграмму классов, это зависит от специфики задачи, но у нас всегда есть средство просто и наглядно регулировать то что получилось в результате генерации.
В принципе мы можем и не генерировать вообще ничего, просто нарисовать, что нам нужно.
Самое главное, что теперь, это задача архитектора, а не разработчика, точнее не MiddleGen.

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

Я просто описал случай "из жизни", как вступление для иллюстрации проблемы.

Да, лучше бы на русском ....

Работаю 8-)

Возможно такие ORM диаграмы могут помочь на уровне Сервера Приложения, но никак не для клиент-серверного подхода. Тогда в эти мапинг классы можно засунуть бизнес-логику ИМХО.

Возможно такие ORM диаграмы могут помочь на уровне Сервера Приложения, но никак не для клиент-серверного подхода. Тогда в эти мапинг классы можно засунуть бизнес-логику ИМХО.

Помогут в случае, использования ORM типа Hibenate или ActiveRecord, обычно на уровне Сервера Приложений, но никто не запрещает использовать в клиент-серверных приложениях.

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

Я вот не до конца понял, а чем плох подход сделать ДК и схему БД и на их основе сгенрить мапинг? Что Вы улучшаете по сравнению с этим подходом?

Я вот не до конца понял, а чем плох подход сделать ДК и схему БД и на их основе сгенрить мапинг? Что Вы улучшаете по сравнению с этим подходом?

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