Форум Сообщества Аналитиков

Дисциплины => Системный Анализ и Требования => Тема начата: kirka от 26 Июля 2016, 13:23:03

Название: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))
Отправлено: kirka от 26 Июля 2016, 13:23:03
Приветствую!

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

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

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

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


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



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

Название: Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))
Отправлено: Humbert от 26 Июля 2016, 13:38:59
По сути эти правила сопоставления - обычные бизнес-правила.

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

https://help.salesforce.com/apex/HTViewHelpDoc?id=workflow_examples.htm&language=ru#ContractExpire
Название: ...
Отправлено: Леонид от 26 Июля 2016, 14:38:18
Нужно образец описания как вообще сопоставлять эти данные..

Огласите полный список... атрибутный состав объектов, пожалуйста.
Название: Re: ...
Отправлено: Humbert от 26 Июля 2016, 15:12:08
Огласите полный список... атрибутный состав объектов, пожалуйста.

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

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

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

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

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

 

Название: ...
Отправлено: Леонид от 26 Июля 2016, 15:37:57
Не-не-не... Автор попросил просто правила сопоставления данных. Весь остальной "обвес" пока за рамками.
Название: Re: ...
Отправлено: Humbert от 26 Июля 2016, 15:50:42
Не-не-не... Автор попросил просто правила сопоставления данных. Весь остальной "обвес" пока за рамками.

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

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

Поскольку вся интеграция идет черех xml или rest, то интеграционщики захотят в итоге именно такой формат. А обработка всех исключений, более сложные преобразования и т.д. должны быть описаны ранее в "обвесе". Если это интеграция, то это опять же оправдано, поскольку интеграционщики будут брать описания триггеров из одного места, а не выцеплять их из всего проекта.
Название: Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))
Отправлено: kirka от 26 Июля 2016, 17:56:42
Да вроде это и нужно. Можете дать какой либюо образец подобного описания?
Как описываются сопоставления, "сведение" на примере?

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

На сервере №2

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

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

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












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

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

Поскольку вся интеграция идет черех xml или rest, то интеграционщики захотят в итоге именно такой формат. А обработка всех исключений, более сложные преобразования и т.д. должны быть описаны ранее в "обвесе". Если это интеграция, то это опять же оправдано, поскольку интеграционщики будут брать описания триггеров из одного места, а не выцеплять их из всего проекта.
Название: Re: ...
Отправлено: Леонид от 26 Июля 2016, 18:36:15
Само сопоставление данных должно сводится к mapping (Сущность исходная, Атрибут исходный, Сущность целевая. Атрибут целевой, Правило преобразования)

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

Вот я и интересуюсь, что у нас есть в активах (атрибуты объекта), по чему можно пытаться сравнить объект А с объектом Б. В том числе, с применением волшебных палочек вроде запросов в места наподобие такого: https://egrul.nalog.ru/
Название: Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))
Отправлено: Humbert от 26 Июля 2016, 22:09:38
Да вроде это и нужно. Можете дать какой либюо образец подобного описания?
Как описываются сопоставления, "сведение" на примере?

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

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

Название: Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))
Отправлено: kirka от 27 Июля 2016, 08:39:52
Иерархия многоуровневая и многокорневая.
Состав атрибутов один и тот же.
Название: Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))
Отправлено: Humbert от 27 Июля 2016, 09:09:31
Иерархия многоуровневая и многокорневая.
Состав атрибутов один и тот же.

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

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

Если таки выложите er того, как ваша многоуровневая и многокорневая иерархия реализована, можно будет подсказать, какие исключения могут быть.
Название: Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))
Отправлено: Humbert от 27 Июля 2016, 15:10:42
Есть кстати довольно удобный сервис для быстрого рисования простейших диаграмм последовательности

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

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/cgi-bin/cdraw?lz=dGl0bGUg0KHQuNC90YXRgNC-0L3QuNC30LDRhtC40Y8g0LTQsNC90L3Ri9GFINCyINC00LLRg9GFINGB0LXRgNCyAAEFsNGFCgrQn9C7ACgFuABDBbLRidC40LotPiDQoQAhCiAxOiDQktGL0LPRgNGD0LbQsNC5AFoL0LUKACAOIC0-ADINMjog0J_QsNC60LXRgiAAgSYFvNC10L3QtQCBNAW5ICAAMw4yIC0tPiAAgQUWACsg0L_QvtC70YPRh9C40LsAgUkXIACBURAyOiDQndCwADAFvQCBWQa-0LHRgNCw0LHQvtGC0LrRgwoKbG9vcCDQn9C-INC60LDQttC00L7QuQCBRQy90L0ADgXRhACCTAW8AIILEDIAZRWS0LfRj9GC0Ywg0YHQu9C10LTRg9GJ0YPRjgBACdGDAIIzBSDQvwCCQAjQsABHFJHQsNC30LAAg3YNOiDQldGBAFoGAIEQCLAg0YEg0YIAgxAFuNC8IElEPwoAKBUAgwUGAIMQDjog0JTQsCAvINCd0LXRggphbHQg0KQAgSIHiyDQvQARBSAgIAApEC0-AB8J0LA6INCh0L7Qt9C00LDRgtGMACsGABYJAGIXndC-0LLQsNGPAIE-DgBBCNC90LAKZWxzZQA-DNC1AIF5BgBvJJ7QsQCDPwWy0LgAayoAKwq7AIVTBb4KZW5kCmVuZAoAhS8qIACFOSEAhQQOsNC9&s=napkin)

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

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

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

Так что для боевого применения надо осваивать более серьезный инструментарий
Название: ...
Отправлено: Леонид от 27 Июля 2016, 15:50:57
Удобнее всего это делать на диаграмме последовательсти или кооперации.

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

Название: Re: ...
Отправлено: Humbert от 27 Июля 2016, 16:01:09
К слову. Не знаю, кому как, а для меня диаграмма последовательности с условными действиями (альтами и лупами) теряет читабельность от слова совсем. Уж лучше блок-схемы.

А я так наоборот в основном ей и пользуюсь. Читабельность легко регулируется путем выносов фрагментов на отдельные диаграммы. При этом никто не мешает на фрагментах отражать дополнительные объекты по сравнению с верхним уровнем. Все как в idef0
Название: Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))
Отправлено: Denis Beskov от 28 Июля 2016, 03:33:55
Нет там никакого 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
Название: Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))
Отправлено: SALar от 02 Августа 2016, 10:53:30

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

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

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

Но если понял, то она решена и описана много-много лет назад. К сожалению, об этой книге почти никто не знает. Книга: "Developing Time-Oriented Database Applications in SQL" от дремучего 2000 года. На хабре утверждают, что сейчас она раздается бесплатно. https://habrahabr.ru/post/191312/

Смысл в том, что объект не может быть ни закрыт, ни изменен. Но может быть закрыта текущая версия объекта и выпущена новая. Это не только решает вашу проблему на уровне элементарных правил, но и позволяет делать много фокусов, вроде ввода нового значения классификатора будущим периодом (актуально для тарифов, изменяющихся в будущем).
Название: Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))
Отправлено: kirka от 02 Августа 2016, 15:54:01
Кстати, хорошая идея реализации. А есть ли эта книга на русском языке?

Книга: "Developing Time-Oriented Database Applications in SQL" от дремучего 2000 года. На хабре утверждают, что сейчас она раздается бесплатно. https://habrahabr.ru/post/191312/

Смысл в том, что объект не может быть ни закрыт, ни изменен. Но может быть закрыта текущая версия объекта и выпущена новая. Это не только решает вашу проблему на уровне элементарных правил, но и позволяет делать много фокусов, вроде ввода нового значения классификатора будущим периодом (актуально для тарифов, изменяющихся в будущем).
Название: Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))
Отправлено: kirka от 03 Августа 2016, 09:50:02
Новая версия да нужно создавать, как вариант. Новая версия - это результат сопоставлений должна быть наверное. Т.к. поступает разного (и неполного) объема информация с разных объектов. Пример:

С сервера №2 поступает  на сервер №1 сведения:
ООО Маяк
Количество сотрудников: 690
Дата получения информации: 10.10.2016

С сервера №3 поступает на сервер №1 сведения:
ООО Маяк
Месторасположение: Россия
Дата получения информации: 11.10.2016

С сервера №4 поступает на сервер №1 сведения:
ООО Муяк
Месторасположение: Россия
Координаты: 45 45 545, 5454
Сотрудников: 1000 человек
Дата получения информации: 10.10.2016

В итоге на сервере должно быть запись (результат сопоставлений и т.д.):
ООО Маяк
Месторасположение: Россия
Координаты: 45 45 545, 5454
Сотрудников: 1000 человек



Смысл в том, что объект не может быть ни закрыт, ни изменен. Но может быть закрыта текущая версия объекта и выпущена новая. Это не только решает вашу проблему на уровне элементарных правил, но и позволяет делать много фокусов, вроде ввода нового значения классификатора будущим периодом (актуально для тарифов, изменяющихся в будущем).
Название: Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))
Отправлено: Humbert от 03 Августа 2016, 11:09:09
Новая версия да нужно создавать, как вариант. Новая версия - это результат сопоставлений должна быть наверное. Т.к. поступает разного (и неполного) объема информация с разных объектов :

При таких условиях я бы задумался, а зачем вообще что-то о сопоставлять в момент обмена? Может имеет смысл всю информацию накопить, а потом отдельно запустить процедуру, которая проанализирует полноту и противоречивость параметров с учетом доверенности и достоверности каждого источника? Причем если полнота или противоречивость будут критичными, то этот обьект можно передать человеку для устранения противоречий вручную

Накапливать изменения можно примерно в такую базу:

ID обьекта
ID атрибута обьекта
Значение атрибута
ID источника (Номер сервера)
DateStamp (время изменения)

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

Похожий подход применяют при работе ETL процедур при построении BI систем

Название: Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))
Отправлено: SALar от 03 Августа 2016, 13:47:56
Новая версия да нужно создавать, как вариант. Новая версия - это результат сопоставлений должна быть наверное. Т.к. поступает разного (и неполного) объема информация с разных объектов. Пример:

С сервера №2 поступает  на сервер №1 сведения:
ООО Маяк
Количество сотрудников: 690
Дата получения информации: 10.10.2016

С сервера №3 поступает на сервер №1 сведения:
ООО Маяк
Месторасположение: Россия
Дата получения информации: 11.10.2016

С сервера №4 поступает на сервер №1 сведения:
ООО Муяк
Месторасположение: Россия
Координаты: 45 45 545, 5454
Сотрудников: 1000 человек
Дата получения информации: 10.10.2016

В итоге на сервере должно быть запись (результат сопоставлений и т.д.):
ООО Маяк
Месторасположение: Россия
Координаты: 45 45 545, 5454
Сотрудников: 1000 человек

Накапливать изменения можно примерно в такую базу:

ID обьекта
ID атрибута обьекта
Значение атрибута
ID источника (Номер сервера)
DateStamp (время изменения)
Нет, нет и нет. Коллеги, не изобретайте велосипед. Просто делайте, как написано в книге.

В итоге на сервере должно быть не менее трех записей. Примерно так:
ЧисленностьместоположениеКоординатыStartDateEndDate
69010.10.2016 11:12:4311.10.2016 05:17:55
690Россия11.10.2016 05:17:5612.10.2016 08:19:55
12.10.2016 08:19:56
01.01.2200 00:00:00

Таблицы на форуме глючат, смотрите книгу.
Есть ли она на русском - мне про то ничего неизвестно.
Название: Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))
Отправлено: Humbert от 03 Августа 2016, 14:01:51
Нет, нет и нет. Коллеги, не изобретайте велосипед. Просто делайте, как написано в книге.

Если уж брать что-то за основу, так DDS

https://en.wikipedia.org/wiki/Data_Distribution_Service