Привет всем.
Все такие как то тяжело перейти от теории к практике и начать использовать UML.
Возьмем задачу.
Есть базы данных, под управлением различных СУБД.
Цель смоделировать миграцию в единую базу под управлением одной СУБД.
То есть отобразить динамически последовательность импорта/эспорта данных в промежуточные форматы и в конечном счете в базу приемник.
Решил использовать диаграмму последовательности..
Но она не оперирует такими сущностями как база данных..
Подскажите, в каком направлении надо двигаться, чтобы решать подобные задачи?
Заранее спасибо.

Для начала вопрос:
1. Базы данных под управлением разных СУБД чем-то отличаются или имеют общую структуру?
2. Если все БД имеют разную структуру, то предполагается ли их объединение и создание единого инфорационного пространства с единой совокупоснтью связей, или это будет простое множество таблиц?

Пожелания:
1. Может для начал все БД привести к общему знаменателю, т.е. перевести их на единую СУБД, пусть они будут разрознены.
2. Если существуют уже данные и следует сохранить их ссылочную целостность, то следует начать с одной БД и отработать приемы перевода. Хотя кажется такие инструменты уже есть

1. Базы данных под управлением разных СУБД чем-то отличаются или имеют общую структуру?

Да структура БД различная. Задача диаграммы все же не отобразить структуру каждой из БД.
Хотя Ваш вопрос возможно предполагает дальнейшее развитие ситуации... потом действительно речь пойдет о том как структура и логика каждой БД "ляжет" в БД приемник.

2. Если все БД имеют разную структуру, то предполагается ли их объединение и создание единого инфорационного пространства с единой совокупоснтью связей, или это будет простое множество таблиц?

В качестве единого множества выступит промежуточный формат. Каждая БД "обязана" создать представление экспортируемых данных согласно правилам этого формата.

2. Если существуют уже данные и следует сохранить их ссылочную целостность, то следует начать с одной БД и отработать приемы перевода. Хотя, кажется, такие инструменты уже есть

На первоначальном этапе нам важно описать последовательность миграции.
Если попытать детализировать диаграмму до уровня таблиц и их связей, она получиться грамозкой.
То есть я делаю так:
1. Написал общую архитектуру, что было к чему стремимся.
2. Стал описывать миграции и тут же споткнулся. Пока оперируем понятиям DataSource.
Потом хочу детализировать описание уже на уровне состава импортируемых сущностей.
Причем остановиться хочу только на не понятных моментах.
То есть предполагается, что клиенты, например экспортируются в БД приемник «как есть» (понятно, что существует не один справочник который используется сущностью "клиенты" и не одна таблица где эти данные хранятся), но здесь мы опускаем детали.
А вот, например что документы должны иметь технический статус при импорте в приемник, чтобы не нарушить баланс БД приемника тут да.. надо показать, что документ как есть, однако помимо прочего (опять же основные атрибуты опускаем) указать, что должен быть признак "технический".
Вот такая солянка. Не знаю насколько правильно получилось описать задачу.
Но опять же сейчас основной вопрос. На какой диаграмме отобразить миграцию? Уровень сущностей при этом: БД и промежуточные файлы.
Вопрос даже не, потому что задача стоит остро, хочу делать именно в UML. Учусь.
Спасибо.

Ничего не понял.

Давайте по порядку.
UML в первую очередь заточен на создание OO приложений. Т.е. Основу составляет диаграмма классов с атрибутами, операциями и связями.
При этом различают два вида диаграмм классов: диаграмму предметной области - где обычно указываются сущностные классы (они обычно эквивалентны таблицам или сущностям ER) и диаграмму классов приложения, а здесь уже мы указываем классы управляющие процессом, классы интерфейсы и классы сущности тоже.

Диаграммы ВИ, последовательности и деятельности -  определяют модель взаимодействия(взаимодействия внешних сил с системой, внутренних компонентов между собой)

Диаграмма состояний - дает нам возможность понять как меняется состояние объекта (одно заметьте, хотя это может быть и система в целом и ваша БД, но в целом, а не как ее отдельные частички).

В вашей задаче не понятно что вы хотите сделать? Описать алгоритм? Создать приложение конвертирующее из разных БД, что в одну? Если да то начните с того, а что ваше конвертрующее приложение будет делать:
соединятся к СУБД
соединятся к БД
извлекать метаинформацию
строить алгоритм перехода по этой информации
проверять данные разрешать конфликты

Пока не очень понятно что вы хотите. Есть лишь задача: перместить все разные БД на одну платформу без потери целостности.

Но может сначал надо построить желаемую БД? а помтом подумать как ее заполнить данным из всех других?

Получается я не могу определить БД например как объект?
Создать стереотип и сответсвующую для него пиктаграму отличную от стандарной пиктаграммы объекта?
Потом сказать про этот объект что он реализует метод create и создает xml поток?
Потом сказать, что у него так же есть метод export и он выгружает данные в поток?
Далее сказать что приемник это тоже объект, и он релизует вызвов внешнего приложения bcp.exe для импорта данных?
Честно сказать я задумался на правильном ли я вообще пути..
Жду Ваших коментариев.

Если задача разовая, то зачем столько усилий прилагать? ... и нужно ли для этого городить отдельную утилиту, когда можно сделать штатными средствами СУБД?
Да еще, что за оконечная СУБД планируется? Если Oracle, то тем более не нужно отдельной утилиты ... выгрузил все в CSV и загрузил Oracle loader-ом в аналогичные схемы ... потом оттуда скриптами разложил по целевой структуре (если она отличается от исходной) ... и не нужно никакого ООП ...

Получается я не могу определить БД например как объект?

Вероятно можно, почему нет, если в качестве атрибутов хранить всю метоинформацию (например в текстовом виде? или в виде запросов?) операций будут хранить методы конвертации

Создать стереотип и сответсвующую для него пиктаграму отличную от стандарной пиктаграммы объекта?

Никто не мешает, лишь бы ваш case умел их трансформировать в код.

Потом сказать про этот объект что он реализует метод create и создает xml поток?
Потом сказать, что у него так же есть метод export и он выгружает данные в поток?
Далее сказать что приемник это тоже объект, и он релизует вызвов внешнего приложения bcp.exe для импорта данных?

Да заради бога. Только это ведь вы тут описываете совсем другое, чо раньше говорили.

Честно сказать я задумался на правильном ли я вообще пути..

Вообще все зависит от цели. Задачу нужно решать всегда с наименьшими усилиями
Вот Юра верно говорит - если задача разовая, то это одно и есть множесвто иных средств. Если задача актуальна настолько, что требует чего-то этого, то можно и ее решить

Жду Ваших коментариев.

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

Jem, тут всё очень просто.

С какой-то точки зрения, системы бывают более трансформационными (трансформирующими) или более реактивными (интерактвными).

Первые были известны раньше и для их моделирования использовались нотации, основанные на парадигме преобразования потока и смены состояний - IDEF0, IDEF1, DFD, Finite Automata (функциональная парадигма).

Вторые появились и стали популярны по мере повышения мощности и удешевления оборудования, они основаны на парадигме взаимодействия агентов, для их моделирования появились диаграммы взаимодействия, последовательности, варианты использования (объектная парадигма).

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

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

В качестве лакмусовой бумажки - почему если UML существует с 1997 года, такие монстры как Oracle, SQL Server и Sybase не используют его в своих средствах моделирования и выполнения миграции данных (Oracle Warehouse Builder, MS SQL Data Transformation/Integration Services, Sybase Power Designer Information Liquidity Model)? Да просто потому, что UML плохо подходит для этой задачи.

Ну т.е. можно конечно попытаться поискать UML Profile для данного класса задач, но я не думаю, что овчинка будет стоить выделки, если речь идёт об обучении.

Если так уж хочется моделировать - используйте нотации DFD, BPMN. Если целевая БД - Oracle, Sybase, SQL Server - то лучше сразу упомянутые мной инструменты.

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

Мда ... тут действительно берем какой-нибудь ERWin и там все делаем быстро и почеловечески. А сам процесс миграции это должно быть просто, если мы конечно говорим именно о миграции, а не репликации ...

Причем тут две операции всего: (1) вылить данные из БД источника в скрипт (2) залить данные в БД приемник. Чтобы это было просто, нужно создать подобные структуры в БД источнике - аналогичные приемнику. Чтобы выгрузка была простой insert into ... думаю процедуры для миграции не нужны, разве что данные продублированы ... Короче нужно разобраться с данными и найти наиболее простую процедуру миграции. На UML ничего писать не нужно.

Далее идеи сумашедшие ... если касаться UML то есть еще такой потенциальный ход, как ... Берем например Hibernate. Создаем по схеме БД источника слой бизнес-логики в объектах. Затем создаем по объектной схеме схему БД. Затем создаем код переливки конкретных источников в приемники ... потом выбрасываем все что наделали и переходим к первому варианту ...

Полностью согласен с Николем Войновым.  Если БД обозримого размера (до неск. гигабайт) и одного типа (реляционные) - ничего не то что проектировать, но и разрабатывать и не нужно, если не считать "разработкой" написание SQL-запросов. Обычная задача администрирования БД.
Всего-то и нужны 2 физические ERD, нарисованные на одной "простыне": одна для БД-источника, другая - для БД-приёмника. И стрелки, нарисованные между столбцами таблиц этих диаграмм, показывающие, что куда переносится . А дальше начинаются "танцы с бубном" вокруг средств администрирования и SQL-запросов.
Моделирование ради моделирования никому не нужно. Навык стрельбы из пушки по воробьям скорее вреден, чем полезен.

<...> Все такие как то тяжело перейти от теории к практике и начать использовать UML. Возьмем задачу. <...>Решил использовать диаграмму последовательности..<...>

IMHO рано переходить. Лучше почитать теорию. Вдумчиво, не по диагонали. Лучше иностранных авторов. Знаю, нудно, но без этого никак.