Приветствую, коллеги.

Стоит вопрос о выборе средства проектирования структур и форматов данных.
Расскажу примерно как я вижу процесс проектирования.
1. Аналитики изучают предметную область, рисуют логическую модель: сущности, их атрибуты и связи.
2. Проектировщики БД добавляют сущностям дополнительные свойства и, используя логическую модель, в автоматическом режиме формируют физическую модель (структуру БД с учетом выбранной СУБД).
3. Разработчики, используя логическую модель, формируют интерфейсы сущностей на языке программирования (например, java).
4. Проектировщики внутренней интеграции формируют каноническую модель на XML.
5. Проектировщики внешней интеграции формируют свою модель данных в XML и мапят её на каноническую модель XML.

По отдельности это всё можно сделать хоть на коленке. Но когда количество сущностей доходит до 100 и все они имеют свойство периодически изменяться - нужно постоянно синхронизировать все перечисленные документы, что превращает жизнь в ад.
А теперь вопрос. Существуют ли реальная практика выполнения этих задач с помощью единого инструмента или какого-то фреймворка инструментов?

пыщ-пыщ-пыщpomoev.u,

powerdesigner

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

Leonid KudryavtsevОписанная Вами цепочка маппинга из одного в другое, лично мне напоминает детскую загадку из журнала Мурзилка: "Туда, сюда, обратно - тебе и мне приятно"
Очень интересно, расскажите еще что-нибудь.

prog123Leonid KudryavtsevОписанная Вами цепочка маппинга из одного в другое, лично мне напоминает детскую загадку из журнала Мурзилка: "Туда, сюда, обратно - тебе и мне приятно"

"Опытному" проектировщику настрогать пару тысяч таблиц - раз плюнуть:)
А что делают опытные проектировщики, когда аналитики меняют логическую модель?

prog123pomoev.uпропущено...

А что делают опытные проектировщики, когда аналитики меняют логическую модель?

Как вариант:
https://www.google.com/patents/US20060225029?dq=US2006225029&hl=ru&sa=X&ei=E5WgU5qMNqWGywPu5YDoDQ&ved=0CB0Q6AEwAA

Я спрашивал про реальную практику.

prog123Leonid KudryavtsevДебильную ситуацию когда один АНАЛитик, что-то поменял, потом 4-5 (ПЯТЬ !) человек, должны следом что-то другое менять - никакое средство разработки исправить не сможет. Это лечится другими методами.

Я уже не говорю, что "проектировщик интеграции" - мне возможно еще понятен (хотя с очень большим трудом, но выпив качественного алкоголя, я его себе еще представить могу). А вот "Проектировщики ВНУТРЕННЕЙ интеграции" и соответственно "наружной".... я даже представлять себе не пытаюсь... у меня и так психика поломанная... потом неделю нейролептики пить придется, что бы успокоится

У Вас как-то ну очень много различных "проектировщиков". А реализует это в результате кто?
пропущено...

А нафига они ее меняют?

Уволить, оторвать конечности, выключить(обрезать) электричество и так далее - менять будет некому

IMHO & AFAIK

Просто нужен Вождь!

Давайте я введу вас в немного в контекст. Предположим разрабатывается сложное отраслевое решение. В команде больше 10 аналитиков, которые изучают предметную область, общаются с персоналом заказчика, разбираются с законодательством и т.д. Они порождают требования. Под эти требования разрабатывается система.
Внутренняя интеграция - шина, позволяющая взаимодействовать подсистемам решения.
Внешняя интеграция - шина для взаимодействия с внешними потребителями и поставщиками сервисов, часто содержит специфический функционал затачиваемый под конкретную внешнюю ИС, повышенные требования к безопасности и т.д.

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

Еще есть вопросы типа "а зачем он меняет требования"?

Кот Матроскинpomoev.uАналитик - это человек наиболее близкий к бизнесу. В процессе разработки требования бизнеса могут изменяться, уточняться и т.д. Поэтому именно аналитик вносит изменения в логическую модель, никого не спрашивая, т.к. его требования первичны. А все остальные должны быстро привести свои данные в соответствие.

Нормальный аналитик при изменении требований не изменяет,а дополняет модель - т.е. обратная совместимость сохраняется.
Шина обмена же вообще не должна зависеть от изменений в предметной области - зачем, собсно? Ну нельзя (или, наоборот, можно) теперь с неким обьектом совершить некое действие - шине-то зачем об этом знать? Ее дело передать запрос на дейстие и аккуратно вернуть результат, а будет ли этот результат "OK" или "ПНХ" - совершенно не ее забота.

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

R7Умение разбивать систему на подсистемы - совсем важное умение. Вплоть до полной автономности, не нарушая всех требований.
Любой дурак может понарисовать квадратики так, что 10 мудрецов на 10 шинах не разгребут.
Да-да, а Волга, между прочим, впадает в Каспийское море!