Приветствую!

Кто нибудь может поделиться ссылками или файлами с образцами описания требований к работе с данными MDM?
Как сопоставляться будут, как сравниваться объекты.

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

Сервер №1
-Азербайджан
-Грузия
-Германия
-.... и т.д.
-Россия:
1. ООО "Маяк" (Россия)
 1.1. ООО "Филиал 1 маяка"
 1.2. ООО "Филиал 2 маяка"

На сервере №2
-Азербайджан
-Грузия
-Германия
-.... и т.д.
-Россия:
1. ООО "Маяк"


Нужно образец описания как вообще сопоставлять эти данные..



Начало темы:
http://www.uml2.ru/forum/index.php?topic=6592.0

По сути эти правила сопоставления - обычные бизнес-правила.

На мой взгляд неплохой формат вот такой:

https://help.salesforce.com/apex/HTViewHelpDoc?id=workflow_examples.htm&language=ru#ContractExpire

Нужно образец описания как вообще сопоставлять эти данные..

Огласите полный список... атрибутный состав объектов, пожалуйста.

Огласите полный список... атрибутный состав объектов, пожалуйста.

Непонятен контекст. Кроме того, что два сервера между собой как-то обмениваются данными непонятно ничего.

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

Применение МДМ системы - это жест отчаянья. Это когда с компанией поработало пара десятков консалтинговых компаний под эгидой трех-пяти системных интеграторов, в итоге получился зоопарк систем, которые надо как-то сопрячь. Причем часть из этих систем не работает, часть уже не работает, а отчетность как-то получать нужно. IMHO если кто то образцом такого ТЗ и поделится, то разбираться в нем вы будете не один месяц

Совершенно другой поток моделирования при интеграции. Там все проще - если концепция интеграции прозрачна для понимания, то как правило проект интеграции имеет примерно следующую структуру :
- ER или диаграмма классов сопрягаемых систем (полная или в части взаимодействия)
- Описание взаимодействия (раньше применяли DFD, теперь диаграмма кооперации или диаграмма последовательности)
- mapping - таблица соответствия куда во что и какие правила преобразования
- Ну и потом собственно проектируете ваше интеграционное приложение , детализация этого проекта определяется тем, что вы будет для интеграции использовать

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

 

Не-не-не... Автор попросил просто правила сопоставления данных. Весь остальной "обвес" пока за рамками.

Не-не-не... Автор попросил просто правила сопоставления данных. Весь остальной "обвес" пока за рамками.

Само сопоставление данных должно сводится к mapping (Сущность исходная, Атрибут исходный, Сущность целевая. Атрибут целевой, Правило преобразования)

При этом правило преобразования - это что-то простое (типа функции строка в дату), а не некоторая волшебная палочка

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

Да вроде это и нужно. Можете дать какой либюо образец подобного описания?
Как описываются сопоставления, "сведение" на примере?

На серваке №1 имеются следующие данные:
1. ООО "Маяк" (Россия)
 1.1. ООО "Филиал 1 маяка"
 1.2. ООО "Филиал 2 маяка"

На сервере №2

1. ООО "Маяк" (Россия)
1.1. ООО "Филиал 2 маяка"

Проблема: При получении из другого сервера данные по умолчанию сливаются в БД (т.е. происходит замена существующих данных на поступившую). Но если сервер не найдет присланные данные об объекте в текущем сервере создаст новый объект (возможно будет дубль данных)

Нужно: чтобы система при получении из другого сервера данные
а) находила аналогичный объект в базе данных текущего сервера
б) если найдет, не стирала текущие данные, а с помощью сопоставления заменяла/дополняла данные.












Само сопоставление данных должно сводится к mapping (Сущность исходная, Атрибут исходный, Сущность целевая. Атрибут целевой, Правило преобразования)

При этом правило преобразования - это что-то простое (типа функции строка в дату), а не некоторая волшебная палочка

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

Само сопоставление данных должно сводится к mapping (Сущность исходная, Атрибут исходный, Сущность целевая. Атрибут целевой, Правило преобразования)

Для начала надо сопоставить. Идентифицировать, по большому счету. Преобразовывать или нет, будем думать потом. А идентификация без уникальных ключей, как у нас сказано в начальных условиях, задача весьма увлекательная.

Вот я и интересуюсь, что у нас есть в активах (атрибуты объекта), по чему можно пытаться сравнить объект А с объектом Б. В том числе, с применением волшебных палочек вроде запросов в места наподобие такого: https://egrul.nalog.ru/

Да вроде это и нужно. Можете дать какой либюо образец подобного описания?
Как описываются сопоставления, "сведение" на примере?

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

Судя по примеру справочник у вас с двухуровневой иерархией. Есть два очевидных способа для реализации такого справочника и 100500 неочевидных. Какой у Вас? Как осуществляется идентификацией каждого уровня?
Возможно ли удаление объектов? На обоих серверах состав атрибутов один и тот же?

Иерархия многоуровневая и многокорневая.
Состав атрибутов один и тот же.

Иерархия многоуровневая и многокорневая.
Состав атрибутов один и тот же.

Если состав атрибутов один и тот же, значит mapping не нужен. Соответственно Вам нужно описать кто и как будет инициировать обмен и как будут обрабатыватьсч исключения.

Удобнее всего это делать на диаграмме последовательсти или кооперации.

Если таки выложите er того, как ваша многоуровневая и многокорневая иерархия реализована, можно будет подсказать, какие исключения могут быть.

Есть кстати довольно удобный сервис для быстрого рисования простейших диаграмм последовательности

Пишешь текст такого вида

itle Синхронизация данных в двух серверах

Планировщик-> Сервер 1: Выгружай данные
Сервер 1 ->Сервер 2: Пакет изменений 
Сервер 2 --> Планировщик: Пакет изменений получил
Планировщик -> Сервер 2: Начинай обработку

loop По каждой изменнной фирме
Сервер 2 -> Сервер 2: Взять следущую фирму из пакета
Сервер 2 -> База данных: Есть фирма с таким ID?
База данных --> Сервер 2 : Да / Нет
alt Фирмы нет
    Сервер 2 -> Фирма: Создать
    Фирма --> Сервер 2 : Новая фирма создана
else Фирма есть
    Сервер 2 -> Фирма: Обновить
    Фирма --> Сервер 2 : Обновлено
end
end

Сервер 2 --> Планировщик : Пакет изменений обработан

И сервис автоматом строит рисунок



Можно по этой ссылке продолжить редактирование

https://www.websequencediagrams.com/?lz=dGl0bGUg0KHQuNC90YXRgNC-0L3QuNC30LDRhtC40Y8g0LTQsNC90L3Ri9GFINCyINC00LLRg9GFINGB0LXRgNCyAAEFsNGFCgrQn9C7ACgFuABDBbLRidC40LotPiDQoQAhCiAxOiDQktGL0LPRgNGD0LbQsNC5AFoL0LUKACAOIC0-ADINMjog0J_QsNC60LXRgiAAgSYFvNC10L3QtQCBNAW5ICAAMw4yIC0tPiAAgQUWACsg0L_QvtC70YPRh9C40LsAgUkXIACBURAyOiDQndCwADAFvQCBWQa-0LHRgNCw0LHQvtGC0LrRgwoKbG9vcCDQn9C-INC60LDQttC00L7QuQCBRQy90L0ADgXRhACCTAW8AIILEDIAZRWS0LfRj9GC0Ywg0YHQu9C10LTRg9GJ0YPRjgBACdGDAIIzBSDQvwCCQAjQsABHFJHQsNC30LAAg3YNOiDQldGBAFoGAIEQCLAg0YEg0YIAgxAFuNC8IElEPwoAKBUAgwUGAIMQDjog0JTQsCAvINCd0LXRggphbHQg0KQAgSIHiyDQvQARBSAgIAApEC0-AB8J0LA6INCh0L7Qt9C00LDRgtGMACsGABYJAGIXndC-0LLQsNGPAIE-DgBBCNC90LAKZWxzZQA-DNC1AIF5BgBvJJ7QsQCDPwWy0LgAayoAKwq7AIVTBb4KZW5kCmVuZAoAhS8qIACFOSEAhQQOsNC9&s=napkin

Но в этом ДП нельзя задавать стереотипы обьектов , нельзя  использовать вложенность фрагментов и ссылку одного фрагмента на другой.

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

Удобнее всего это делать на диаграмме последовательсти или кооперации.

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

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

А я так наоборот в основном ей и пользуюсь. Читабельность легко регулируется путем выносов фрагментов на отдельные диаграммы. При этом никто не мешает на фрагментах отражать дополнительные объекты по сравнению с верхним уровнем. Все как в idef0

Нет там никакого rocket science, нужны 2 части:
1. Описание алгоритма
2. Таблицы соответствия (деревья решений)

Алгоритм можно описать юскейсом, можно activity diagram, можно sequence diagram, можно flow chart.

По поиску в гугле data matching requirements можно найти всякие примеры типа: https://www.ag.gov.au/RightsAndProtections/IdentitySecurity/Documents/Data%20matching%20better%20practice%20guidelines%20%5BPDF%20775KB%5D.pdf