Comments 35
Спасибо. Насколько велика и в каких нюнсах заключается разница между MDM и простым сервисом, выступающим единственным источником правды в рамках предприятия о тех же клиентах?
В современные MDM, кроме непосредственно сервиса хранения мастер-данных (единственного источника правды) обычно входит целый набор сервисов: ETL-сервисы, сервисы управления качеством данных (профилирование, стандартизация, обогащение, дедубликация и т.д.), сервисы управления метаданными, сервисы управления доступом, сервисы для работы датастюардов (экспертов), сервисы управления иерархиями, сервисы поиска и многие другие.
Грубо говоря, постепенно развивая простой сервис под требования бизнеса может оказаться, что нечаянно создали MDM? Причём некоторые из названных функций, в частности управление доступом и поиск входит в мало-мальски серьёзные сервисы изначально.
Хм, интересно обсудить классификацию.
Справочник валют (просто список) — это мастер-данные?
Курсы валют на каждый день — это мастер-данные?
Список стран, городов и регионов с некоторыми атрибутами — это мастер-данные?
Мэппинги наименований (например, мэппинг разных написаний SKU на сайтах магазинов с эталонным написанием) — а это?
Список рассылки получателей в привязке к регионам — а это?
Выгрузка списка сотрудников из HR (обновляемая автоматически) с некоторыми атрибутами (обновляемая вручную по этим сотрудникам) — а это?
Часто всё это запихивают в одну MDM систему, и не парятся.
Справочник валют (просто список) — это мастер-данные?
Курсы валют на каждый день — это мастер-данные?
Список стран, городов и регионов с некоторыми атрибутами — это мастер-данные?
Мэппинги наименований (например, мэппинг разных написаний SKU на сайтах магазинов с эталонным написанием) — а это?
Список рассылки получателей в привязке к регионам — а это?
Выгрузка списка сотрудников из HR (обновляемая автоматически) с некоторыми атрибутами (обновляемая вручную по этим сотрудникам) — а это?
Часто всё это запихивают в одну MDM систему, и не парятся.
Ну нагородили…
На мой взгляд, можно выделить всего 3 типа данных
1 Справочники — сущности
2 Документы — события изменения сущностей
3 Аналитические (отчеты) — вычисляемые данные для анализа
Т.е. справочники это основа, без которой ни документы ни отчеты не могут существовать.
Документы и Отчеты формируются на основе справочников и документов.
Таким образом Метаданные, Референс-данные и Мастер-данные — это справочники.
Транзакционные данные — Документы
И Исторические данные — Отчеты.
На мой взгляд, можно выделить всего 3 типа данных
1 Справочники — сущности
2 Документы — события изменения сущностей
3 Аналитические (отчеты) — вычисляемые данные для анализа
Т.е. справочники это основа, без которой ни документы ни отчеты не могут существовать.
Документы и Отчеты формируются на основе справочников и документов.
Таким образом Метаданные, Референс-данные и Мастер-данные — это справочники.
Транзакционные данные — Документы
И Исторические данные — Отчеты.
Во многом это вопрос терминологии. Ваша терминология близка к той, которую использует 1С в своей платформе 1С: Предприятие. Но там есть еще Перечисления, Регистры сведений, Регистры накопления, Регистры расчетов, Регистры бухгалтерии, Бизнес-процессы, Задачи и другие предметные сущности, которые можно отнести к тому или иному классу данных, представленных мной.
Есть еще один нюанс. Мастер-данные — это не обязательно только «справочники», на которые ссылаются «документы». В системе MDM часто хранят, например, сводные данные по оборотам по клиенту или по сделанным им заказам. А потом эти данные анализируют для выявления, например, предпочтений клиента в тех или иных продуктах или услугах.
Есть еще один нюанс. Мастер-данные — это не обязательно только «справочники», на которые ссылаются «документы». В системе MDM часто хранят, например, сводные данные по оборотам по клиенту или по сделанным им заказам. А потом эти данные анализируют для выявления, например, предпочтений клиента в тех или иных продуктах или услугах.
Во многом это вопрос терминологии
Все верно, когда появляется новый термин, то, как правило, его смысл уже давно был кем-то описан ранее. А в теории важно только определить категории, его составляющие и зависимости, но главное не переусердствовать в этом.
Все-таки мы живем в мире, где видим объекты (Справочники), фиксируем события, которые с ними происходят и будут происходить (документы) и на этом основании можем анализировать, планировать и т.д.(Отчеты). А уже из этих «трех столпов» можно выделять категории, в зависимости от поставленных задач.
Объекты — это сущности, а справочники — значения. Со значениями событий не происходит. Одно значение может замениться на другое в какой-то сущности, но это будет событие изменения сущности, а не значения.
Ну, я лично считаю, что справочник, например, стран и "справочник" клиентов — это очень разные типы данных. В конце-концов, страны могут вообще в хранилище не храниться, а быть захардкожены какой-нибудь хэш-картой в коде систем или подтягиваться для показа с какого-нибудь стороннего сервиса. Ну или заполняться/меняться миграцией базы и не иметь пользовательского интерфейса для создания/изменения/удаления.
В общем надо различать данные, которые меняются крайне редко и используются в основном только для заполнения по ссылке свойств других сущностей, и данные, создание, изменение и удаление которых являются сутью бизнес-процессов компании.
Да, абсолютно верно. Поэтому и различаются референс-данные и мастер-данные.
Ну, я лично считаю, что справочник, например, стран и «справочник» клиентов — это очень разные типы данных.
Конечно разные, также как и «резиновые сапоги» и «способность к левитации». Тут важно отталкиваться от поставленных задач и не углубляться в те процессы, которые в них не входят, а то придется писать программу взаимодействия объектов от начала сотворения Мира.
Важно понять, то, что это самостоятельные сущности (объекты), которые могут являться частью друг друга.
Вы также можете подтянуть справочник клиентов из Налоговой (гипотетически), но тут все дело в их количестве, хотя я не думаю что вы будете подтягивать населенные пункты всего Мира.
В общем надо различать данные, которые меняются крайне редко и используются в основном только для заполнения по ссылке свойств других сущностей, и данные, создание, изменение и удаление которых являются сутью бизнес-процессов компании.
Не спорю, но это уже категории базового объекта «Справочники» по жизненному циклу и их может быть сколько угодно, опять же — в зависимости от поставленных задач. Тогда как события создания, изменения и удаления сущностей будут регистрироваться Документами.
Грубо, одни и те же данные в зависимости от задачи могут быть как справочниками значений (часто вообще только для показа в UI), так и полноценными сущностями со своим жизненным циклом. Если в рамках единой системы предприятия (или даже сети систем сети предприятий) какие-то данные выступают исключительно как справочники значений (пускай иногда и пополняемые/изменяемые), то нигде в рамках этой системы или сети нет смысла приравнивать эти справочники к сущностям. Если же где-то выступают как значения, а где-то как сущности, то надо думать как лучше организовать связи и вообще.
Есть ли МДМ-системы с уже готовым интерфейсом для ручного ведения/заполнения/редактирования справочников дата-стюартом???
Конечно есть. Почти все MDM-системы это позволяют.
в смысле «почи все?» Informatica MDM не позволяет.
Дайте пример какой-нить
Дайте пример какой-нить
Не путайте коробку с внедрением. =)
Интерфейс обычно ставится под клиента.
То что вы подразумеваете — это так называемые доменные решения.
Если ваш интегратор уже делал проект по вашему домену, то он может притащить решение с прошлого проекта, но 99,99 % он вам не подойдет полностью и начинается допиливание.
Если нужны справочники физ. лиц и юр. лиц смотрите специализированные решения (подкласс MDM — CDI), но как только потребуется разобраться с товарами или НСИ (гос классификаторами или внутренними) — нужно покупать новый продукт и интегрировать с CDI.
Аналогично со всеми специализированными решениями. RDM, PIM, и другими 3-4 буквами.
На MDM рынке 58-60 вендоров на российском рынке 20-30. Выбор большой.
Нужно идти от задачи, а не от того что предлагают.
Интерфейс обычно ставится под клиента.
То что вы подразумеваете — это так называемые доменные решения.
Если ваш интегратор уже делал проект по вашему домену, то он может притащить решение с прошлого проекта, но 99,99 % он вам не подойдет полностью и начинается допиливание.
Если нужны справочники физ. лиц и юр. лиц смотрите специализированные решения (подкласс MDM — CDI), но как только потребуется разобраться с товарами или НСИ (гос классификаторами или внутренними) — нужно покупать новый продукт и интегрировать с CDI.
Аналогично со всеми специализированными решениями. RDM, PIM, и другими 3-4 буквами.
На MDM рынке 58-60 вендоров на российском рынке 20-30. Выбор большой.
Нужно идти от задачи, а не от того что предлагают.
Ниже представлены 5 ключевых типов:
откуда взята такая и почему именно такая типизация?
Это довольно устоявшаяся модель типизации MDM. Из наиболее полных книг на эту тему могу посоветовать:
https://www.amazon.com/MASTER-DATA-MANAGEMENT-GOVERNANCE/dp/0071744584/ref=sr_1_1?ie=UTF8&qid=1489757550&sr=8-1&keywords=MDM
https://www.amazon.com/Enterprise-Master-Data-Management-Information/dp/0132366258/ref=sr_1_2?s=books&ie=UTF8&qid=1489757596&sr=1-2&keywords=MASTER+DATA+MANAGEMENT
Первую из этих книг мы сейчас готовим к изданию на русском языке.
https://www.amazon.com/MASTER-DATA-MANAGEMENT-GOVERNANCE/dp/0071744584/ref=sr_1_1?ie=UTF8&qid=1489757550&sr=8-1&keywords=MDM
https://www.amazon.com/Enterprise-Master-Data-Management-Information/dp/0132366258/ref=sr_1_2?s=books&ie=UTF8&qid=1489757596&sr=1-2&keywords=MASTER+DATA+MANAGEMENT
Первую из этих книг мы сейчас готовим к изданию на русском языке.
=) это всего лишь мнение IBM который, в MDM не силен, мягко скажем.
Ну у Gartner похожая классификация.
Да Master и Reference у них стали управляться разными системами MDM — RDM.
Но это же маркетинг.
По факту получается что MDM&RDM — отраслевой стандарт.
А MDM&RDM&PDM(EDM) текущие требования рынка.
Но это же маркетинг.
По факту получается что MDM&RDM — отраслевой стандарт.
А MDM&RDM&PDM(EDM) текущие требования рынка.
Скорее всего отсюда.
http://booksite.elsevier.com/9780123743695/10steps_DataCategories.pdf
или
https://www.semarchy.com/semarchy-blog/backtobasics_data_classification/
В отрасли MDM принято такое разделение, но оно больше от потребности иметь классификацию и во многом притянуто.
Потому как
Ипотечный договор больше похож на Referencу, так как не меняется 25 лет.
Договор кредитной карты — на Master
Билет в автобусе (договор оказания транспортной услуги) — чистой воды Transactional.
http://booksite.elsevier.com/9780123743695/10steps_DataCategories.pdf
или
https://www.semarchy.com/semarchy-blog/backtobasics_data_classification/
В отрасли MDM принято такое разделение, но оно больше от потребности иметь классификацию и во многом притянуто.
Потому как
Ипотечный договор больше похож на Referencу, так как не меняется 25 лет.
Договор кредитной карты — на Master
Билет в автобусе (договор оказания транспортной услуги) — чистой воды Transactional.
спасибо за ссылки,
это не классификации/типизации а некоторые устойчивые, часто употребимые словосочетания, применяемые в области обработки оцифрованных бизнесс-данных.
напомнило — как-то в очередном приступе желания найти хорошую информацию о «информации» наткнулся на учебник по «информационным технологиям» какого-то вуза уровня губернии… открыл почитать, поскольку в других местах найти не удавалось, а вдруг этот Кулибин — Бруно что-то небанальное стоящее предложил
и… лучше б не открывал, аж стошнило от
— информация делится на цифровую и не цифровую, на важную и не важую, на срочную и не срочную… и так пол книги. надо чем-то N-часов по предмету мозги студентамзасрать наполнить. чтоб эту ахинею поконспектировали, заучили и воспроизводили при опросах
ни понятие информации не раскрыто, ни закономерности ни одной, ни научных школ которые в этой области работают… ничего кроме воды
вышеприведенной классификации конечно достаточно, чтоб разделить предлагаемое ПО по сегментам для удобной продажи и для удобного дробления функций ИТ персонала для юзания.
не научный, чисто прикладной аспект. а так хотелось чего-то возвышенного и светлого…
это не классификации/типизации а некоторые устойчивые, часто употребимые словосочетания, применяемые в области обработки оцифрованных бизнесс-данных.
напомнило — как-то в очередном приступе желания найти хорошую информацию о «информации» наткнулся на учебник по «информационным технологиям» какого-то вуза уровня губернии… открыл почитать, поскольку в других местах найти не удавалось, а вдруг этот Кулибин — Бруно что-то небанальное стоящее предложил
и… лучше б не открывал, аж стошнило от
— информация делится на цифровую и не цифровую, на важную и не важую, на срочную и не срочную… и так пол книги. надо чем-то N-часов по предмету мозги студентам
ни понятие информации не раскрыто, ни закономерности ни одной, ни научных школ которые в этой области работают… ничего кроме воды
вышеприведенной классификации конечно достаточно, чтоб разделить предлагаемое ПО по сегментам для удобной продажи и для удобного дробления функций ИТ персонала для юзания.
не научный, чисто прикладной аспект. а так хотелось чего-то возвышенного и светлого…
Да прикладной, с научным дело сложнее он ближе к философии и применимость его часто спорна.
Поищу.
были пара авторефератов в Ленинке доступных без пароля, а так дисеров на эту тему «не много».
Что странно, так как уже затасканные bigdatы и прочие нейронки без этого не живут.
Так как «мусор на входе — мусор на выходе „
Поищу.
были пара авторефератов в Ленинке доступных без пароля, а так дисеров на эту тему «не много».
Что странно, так как уже затасканные bigdatы и прочие нейронки без этого не живут.
Так как «мусор на входе — мусор на выходе „
А есть понимание, где заканчивается DWH и начинается MDM? Архитектурно, например.
Архитектурно DWH — хранилище, а MDM — «струтктурилище» =)
Один хранит всё «как есть», а второй «как должно быть в идеальном мире».
Первый без второго живет, но плохо и DWH вынужден «на коленке» делать то что должен делать MDM.
Для себя я провел водораздел по Data Quality функционалу.
DWH не должен преобразовывать данные и содержать какие то правила их изменений.
Всё что ему нужно это обращаться или в DQ или напрямую в MDM с вопросом.
«Что это и есть ли у него связи?»
На примере.
В DWH данные о клиентских транзакциях из двух источников.
Установление связи между клиентами дело MDM. DHW получает таблицу кроссID (Xref) в которой учитываются и внутрисистемные дубли (один клиент заведен 2 раза в одной системе) и межсистемные дубли (один клиент в двух системах)
На основе этой таблицы DWH отдает BI информацию в «как есть» через призму «идеального мира MDM»
Один хранит всё «как есть», а второй «как должно быть в идеальном мире».
Первый без второго живет, но плохо и DWH вынужден «на коленке» делать то что должен делать MDM.
Для себя я провел водораздел по Data Quality функционалу.
DWH не должен преобразовывать данные и содержать какие то правила их изменений.
Всё что ему нужно это обращаться или в DQ или напрямую в MDM с вопросом.
«Что это и есть ли у него связи?»
На примере.
В DWH данные о клиентских транзакциях из двух источников.
Установление связи между клиентами дело MDM. DHW получает таблицу кроссID (Xref) в которой учитываются и внутрисистемные дубли (один клиент заведен 2 раза в одной системе) и межсистемные дубли (один клиент в двух системах)
На основе этой таблицы DWH отдает BI информацию в «как есть» через призму «идеального мира MDM»
ИМХО DWH более старый стек технологий, получающий данные из операционных систем в пакетном режиме с использованием устоявшегося набора ETL технологий (Data Quality туда входит в букву Т). Предоставляет бизнес сущности и факты их бизнес-активностей в согласованном, очищенном виде на следующий день(период дней) посл изменений. Смотрят в DWH как правило системы отчетности и бизнес-аналитики.
Но скорость бизнес-процессов возрастает. И вариант получить данные на следующий день уже часто не устраивает. Что еще хуже — бизнесс-данные нужны не только на уровне отчетов, а для обеспечения логики трансакций — в операционных процессах, онлайново.
и вот ИТ-индустрия родила стек технологий MDM — почти все то же что есть в хранилище, но
+ плюс получение данных из учетных и прочих инф. систем онлайн
+ плюс предоставление удобных апи для использования этих данных учетными и прочими инф. системами онлайн
— минус ведение фактов по бизнес сущностям
Но скорость бизнес-процессов возрастает. И вариант получить данные на следующий день уже часто не устраивает. Что еще хуже — бизнесс-данные нужны не только на уровне отчетов, а для обеспечения логики трансакций — в операционных процессах, онлайново.
и вот ИТ-индустрия родила стек технологий MDM — почти все то же что есть в хранилище, но
+ плюс получение данных из учетных и прочих инф. систем онлайн
+ плюс предоставление удобных апи для использования этих данных учетными и прочими инф. системами онлайн
— минус ведение фактов по бизнес сущностям
Всё же DWH и MDM это сильно разные классы.
ETL можно и раз в минуту запускать выгружая произведенные операции.
Отчетность без фактов бизнес сущностей (транзакций) не собрать
MDM это больше про «общий язык» для систем. Маркетинговое — интеграция на уровне данных.
Отчетность использует MDM, но это один из побочных моментов «общего языка»
ETL можно и раз в минуту запускать выгружая произведенные операции.
Отчетность без фактов бизнес сущностей (транзакций) не собрать
MDM это больше про «общий язык» для систем. Маркетинговое — интеграция на уровне данных.
Отчетность использует MDM, но это один из побочных моментов «общего языка»
Sign up to leave a comment.
Что такое «система управления мастер-данными» и зачем она нужна