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

Стоит вопрос о выборе средства проектирования структур и форматов данных.
Расскажу примерно как я вижу процесс проектирования.
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 шинах не разгребут.
Да-да, а Волга, между прочим, впадает в Каспийское море!

BagaBagaХм, как-то неправильно заквотилось.
Я извиняюсь, вы мне говорили про waterfall подход или тем, кто не понимает почему аналитики вносят изменения?

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


Ваше описание - водопад. Ещё хуже - серия водопадов, каждый из которых начинается (наплевав на все предыдущие) тогда, когда "аналитик вносит изменения ... никого не спрашивая". При этом все остальные поставлены в позу дурачка, который возьмёт под козырёк на любую прихоть и выбросит предыдущие наработки... или является штатным ясновидящим, который сделает "как надо" ещё до полученной модели и заранее "предусмотрит невероятное".

Обратной связи, чтобы дать вовремя по рукам аналитеГу, в вашем описании не предусмотрено. В результате его модель может "не уложиться" в используемый стек технологий. Желающих переписывать всё на каждый чих нет, поэтому на практике имеющийся код будет обрастать костылями, а при добавлении нового разработчики будут просто применять избыточно "гибкие" схемы, не налагающие практически никаких ограничений (а следовательно создающие проблему обеспечения согласованности данных и выполнения бизнес-регламентов) и далеко не идеальные по производительности (за "гибкость" надо платить). Вас же не удивляет, что внедрение покупных продуктов сопровождается не только "допилом под себя коробки", ни и перестройкой части бизнес-процессов под требования системы?
Аналитики в достаточно мере представляют себе используемые технологии, чтобы вносить изменения более менее осмысленно. Изменения это например добавление атрибута к сущности или уточнение допустимого диапазона значений, переименование и т.д.
Откуда вы придумываете эти сценарии про "наплевать на все предыдущие" и "переписывать всё на каждый чих" и прочее?
По теме есть что добавить, или тут одни Капитаны собрались?

Если быть честным, то тема создавалась, чтобы послушать людей, имеющих опыт автоматизации указанных процессов с помощью соответствующих инструментов, а большинство присутствующих почему-то пытаются перевести тему в разряд флуда о том, что такого не бывает и рассказать, как важно делить систему на подсистемы и как организовать общение между архитекторами и аналитиками. Все эти проблемы уже решены: всё поделено, аналитики даже с тимлидами разработки общаются постоянно, а с архитекторами они вообще не разлей вода. Но это всё не о том.
Вопрос: кто на практике выполнял все изложенные в первом сообщении задачи с помощью PowerDesigner? Или может быть с помощью IBM Data Architect? Какие впечатления? Удалось ли всё выполнить в автоматическом режиме или всё равно в конце всё пришлось переделывать руками?

BagaBagapomoev.u,
ARIS вас устроит?

Если у вас есть опыт решения задач, описанных в топике, с помощью ARIS - расскажите, пожалуйста, очень интересно.
BagaBagaНа самом деле, лучший инструментарий - тот, которым владеет ваша команда. Иначе вы будете не проект делать, а обучаться использованию конкретного CASE-средства за счёт заказчика.
Я вас прошу, давайте без банальностей, я уже не знаю как еще намекнуть.

prog123BagaBagapomoev.u,
ARIS вас устроит?

На самом деле, лучший инструментарий - тот, которым владеет ваша команда. Иначе вы будете не проект делать, а обучаться использованию конкретного CASE-средства за счёт заказчика.

Эти программы предназначены для выкачки бабла из ламерских структур которые при деньгахZ:)
Для настоящего решения настоящих проблем, весь этот шлак абсолютно не нужен.
Вы абсолютно правы, я даже больше скажу: вообще все коробочные продукты предназначены для выкачки бабла из ламерских структур, которые при бабле.

prog123Пора по так называемым IT-конторам и IT-проектам пройтись железной метлой и сократить их всех десятами тысячь, а на полпроцента сэкономленных денег нанять нужное количество учётчиков, которые с Экселем и планшетами, а еще лучше - с обычными бумажными журналами будут спокойно фиксировать ход происходящего, например, - производство, а по их скрупулезным записям можно будет сосчитать НАСТОЯЩУЮ себестоимость изделий, и настоящую структуру этой самой себестоимости. На сегодняшний момент, ни 1С, Ни SAP/3(это даже не программа в обычном смысле, а это троянское коррупционное оружие), ни прочие поделки, - ничего не решают, кроме поглощения денег.

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

Меры возможны и другие, но смысл тот же, - против жульничества на ниве "автоматизации".

Прочитал вашу речь и прям представил себя на сисопке. Обязательно вечером накачу 50 грамм за крестьянский здравый смысл и занюхаю пыльной книжкой Питера Абеля.

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


Из опыта. То что выбором инструмента задались это правильно. Без него будет большая свалка документов и схем. Важно чтобы грань между Аналитики и Проектировщики была как можно тоньше, т.к.
первые - рисуют логическую модель: сущности, их атрибуты и связи.
вторые - добавляют сущностям дополнительные свойства и, используя логическую модель
Т.е. лучший вариант когда они используют один инструмент. Иначе схем будет в двойном количестве.
Важно чтобы инструмент какой бы Вы не выбрали умел рисовать Диаграммы связей таблиц - например - master-detail - они все равно будут даже если Foreign Keys в базе нет (к примеру у меня такое встречалось в DWH на Exadata), но если рассматривать OLTP и к примеру банковское ПО или процессинг, или SaaS Cloud то скорее всего FK будут.
Важно чтобы ИНструмент мог рисовать стрелки между таблицами - сущностями. Еще круче если инструмент может привязывать к сущностям операции над ними - тоже графически.
И потом все выгружать это все в XML, JSON, CSV и т.п.
Еще лучше если инструмент может создавать сам таблицы в базе.
У нас был именно последний вариант. Т.е. полноценный - еще и многопользовательский, со своей БД о мета-инфо.
Повторюсь что он был самописный - поэтому вам рекламироваать не могу.
Но чем меньше прослоек между разными типами людей тем лучше.
И лучше забыть про проектирование и аналитику в Ворде и Эксель - этот уже прошлый век.
Так что либо создавайте инструмент под себя или выберите платный или бесплатный - а таких превеликое множество

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

Кот Матроскинguest_20040621 ТС говорит о ста таблицах, - совершенно искренне не понимаю, какие задачи он решает.

Да, 10 аналитиков на 100 таблиц - это что-то крутое, не иначе :)
У нас в проекте есть, например, агрегирующая бизнес-сущность, содержащая около 700 реквизитов, поставляемых от разных источников, и над ней работают несколько аналитиков.

Если вы не понимаете чего-то - это означает только то, что вы этого не понимаете. И вы раз за разом возвращаетесь, чтобы продемонстрировать непонимание. Зачем это?

Кот Матроскинpomoev.uпропущено...

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

Это типа круто? Надо завидовать?

pomoev.uЕсли вы не понимаете чего-то - это означает только то, что вы этого не понимаете. И вы раз за разом возвращаетесь, чтобы продемонстрировать непонимание. Зачем это?
Ну вот Вы, например, не понимаете, зачем я это делаю, и это непонимание демонстрируете Задайте себе этот вопрос

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

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

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

Если вы не понимаете чего-то - это означает только то, что вы этого не понимаете. И вы раз за разом возвращаетесь, чтобы продемонстрировать непонимание. Зачем это?

700 столбцов в таблице Или у вас еще наследование таблиц?
DWH ELT ? или такой экспорт во внеш систему?
Как это будет реализовано на уровне БД пока не знаю (возможно это будет noSQL-решение), сейчас только аналитика готовится.

Дело ясное что дело темное. Внедрить PowerDesigner можно, но судя по всему никто этим плотно не занимался, поэтому на деле может выйти так, что потратим кучу денег и времени, а в итоге окажется, что PD одни проблемы решает, а другие создает. В общем надо самому изучать. Спасибо всем.

prog123Кстати, про шину:



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

Для автора какая-никакая а все таки наука...когда то же надо начинать:)
Ваши советы раз за разом не в бровь а в глаз. Премного благодарен.