1876
Проектирование / Re: Базы данных
« : 19 Июля 2007, 22:29:55 »
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 - то лучше сразу упомянутые мной инструменты.
Кстати, следует переименовать тему в что-то типа "Моделирование системы одноразовой миграции и консолидации данных".
С какой-то точки зрения, системы бывают более трансформационными (трансформирующими) или более реактивными (интерактвными).
Первые были известны раньше и для их моделирования использовались нотации, основанные на парадигме преобразования потока и смены состояний - 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 - то лучше сразу упомянутые мной инструменты.
Кстати, следует переименовать тему в что-то типа "Моделирование системы одноразовой миграции и консолидации данных".