Не путайте коробку с внедрением. =)
Интерфейс обычно ставится под клиента.
То что вы подразумеваете — это так называемые доменные решения.
Если ваш интегратор уже делал проект по вашему домену, то он может притащить решение с прошлого проекта, но 99,99 % он вам не подойдет полностью и начинается допиливание.
Если нужны справочники физ. лиц и юр. лиц смотрите специализированные решения (подкласс MDM — CDI), но как только потребуется разобраться с товарами или НСИ (гос классификаторами или внутренними) — нужно покупать новый продукт и интегрировать с CDI.
Аналогично со всеми специализированными решениями. RDM, PIM, и другими 3-4 буквами.
На MDM рынке 58-60 вендоров на российском рынке 20-30. Выбор большой.
Нужно идти от задачи, а не от того что предлагают.
Бизнес обычно не предоставляет выбор своевременный или однозначный. Просят сразу и то и другое.
Ввод подтверждения правильности это как? Окошко с кнопкой «Ок»? их никто не читает.
Содержательно. Спасибо.
Не соглашусь с двумя утверждениями.
Так если адрес клиента присутствует в двух базах, то он должен совпадать. В противном случае необходимо выбрать один источник достоверным и игнорировать остальные до исправления ошибок.
Выбор одного источника блокирует обновление из других.
Предсказать где появится следующее обновление не можем.
В борьбе за однозначность теряем своевременность. Своевременность важнее.
Подход «выбор лучшего источника» был популярен в MDM/DQ решениях конце девяностых и начале нулевых.
Сейчас решения учитывают «информационную ценность». Оценивается корректность данных (валидность) и актуальность. На основе этих показателей выносится решение какой из двух адресов брать, а какой нет.
При этом в зависимости от типа сравниваемых объектов выбор может склоняться то в сторону «правильный лучше чем актуальный», то «пусть не актуальный, зато правильный»
И второе
▍При возможности исключайте ручной ввод данных и предлагайте оператору или пользователю выбрать значение из выпадающего списка.
С точки зрения первичного ввода — это упрощение, но «списки» имеют тонкий момент. Ошибка в выборе значения списка неисправима. Человеческий фактор опечаток снижается (такие ошибки исправляем), но появляется новый тип ошибок, который исправить невозможно. Чтобы это предотвратить приходится встраивать проверки в интерфейс ввода на непротиворечивость, а это не всегда возможны технически и логически тоже иногда бывает. Если данные ценные то поможет только двойной ввод, а это дорого.
Ведение реестров… Слежение за актуальностью такого реестра – практически идеальная задача для BI-системы
и далее
Слой подготовки данных состоит из двух уровней: SRC, где хранятся исходные данные, и Staging, на котором мы применяем алгоритмы объединения и очистки данных.
Всё так, только поиск дублей вести лучше в связке с MDM, если данных хоть сколько нибудь ощутимое количество.
Поиск дублей сравнением «каждый с каждым» — тупиковый путь на больших объемах, особенно для хранилищ.
Merge в EDQ — работает, но жестко настроен, при тонкой работе (например клиенты) приходилось использовать внешний обработчик.
В остальном отличный инструмент, рабочий.
Всё же DWH и MDM это сильно разные классы.
ETL можно и раз в минуту запускать выгружая произведенные операции.
Отчетность без фактов бизнес сущностей (транзакций) не собрать
MDM это больше про «общий язык» для систем. Маркетинговое — интеграция на уровне данных.
Отчетность использует MDM, но это один из побочных моментов «общего языка»
ArcGIS -> ESRI — > NGIA Национальное агентство геопространственной разведки (англ. National Geospatial-Intelligence Agency).
Если отделить то что убёг человек с первым допуском остается то, что данные грузятся напрямую в облако к разведке США.
Для пользователей привязка фотоснимков не проблема. Для госов и крупного бизнеса (читай возможно подсанкционного) рисковый вариант. Пока что предпочитают stand alone решения, Яндекс тоже почему то госы не используют для своей картографии.
Софт у ArcGIS безусловно сделан хорошо, но вот эти факторы применимость сужают.
Не импортозамещающе как то =)
Да и подобные истории трехлетней давности не дают покоя.
Для частного бизнеса еще может быть, но для госов — такие штуки табу.
Да прикладной, с научным дело сложнее он ближе к философии и применимость его часто спорна.
Поищу.
были пара авторефератов в Ленинке доступных без пароля, а так дисеров на эту тему «не много».
Что странно, так как уже затасканные bigdatы и прочие нейронки без этого не живут.
Так как «мусор на входе — мусор на выходе „
Архитектурно DWH — хранилище, а MDM — «струтктурилище» =)
Один хранит всё «как есть», а второй «как должно быть в идеальном мире».
Первый без второго живет, но плохо и DWH вынужден «на коленке» делать то что должен делать MDM.
Для себя я провел водораздел по Data Quality функционалу.
DWH не должен преобразовывать данные и содержать какие то правила их изменений.
Всё что ему нужно это обращаться или в DQ или напрямую в MDM с вопросом.
«Что это и есть ли у него связи?»
На примере.
В DWH данные о клиентских транзакциях из двух источников.
Установление связи между клиентами дело MDM. DHW получает таблицу кроссID (Xref) в которой учитываются и внутрисистемные дубли (один клиент заведен 2 раза в одной системе) и межсистемные дубли (один клиент в двух системах)
На основе этой таблицы DWH отдает BI информацию в «как есть» через призму «идеального мира MDM»
Да Master и Reference у них стали управляться разными системами MDM — RDM.
Но это же маркетинг.
По факту получается что 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.
Да, что-то много 500мс. Даже на 4 подбора.
1. пробег от клиента до сервера 3-30мс (зависит от расстояния между пользователем и сервером)
2. выборка из кэша первой буквы 1-5 мс
3. пробег обратно 3-30 мс (зависит от расстояния между пользователем и сервером)
Итого 7-65 мс. в большинстве случаев.
Так 4 раза (от 7 до 65)х4 от 28 до 260мс.
Хотя проще клиентско закешировать адрес и всё=)
Чаще всего мы же 2-3 адреса вводим. Дом, работа и еще что нибудь.
Пользуюсь Iphone 2G все 10 лет (на самом деле с декабря 2007) как основным телефоном.
1,5 дня аккум держит.
Что бы не говорили, но продукт вышел крутой.
Не совсем.
Коды качества определяют качество конкретного результата, а показатели прямой и обратной ошибки определяются обычно на выборе в 10 или 100 тыс записей.
Пресловутые 99,99% из статьи, значат, что прямая ошибка (не нашли) всего 0.01%. Обратная ошибка (отравленные яблоки) не обозначаются.
Полнота базы — дом есть, его нет в базе=> база не полная.
Актуальность базы — дом снесли, а в базе он нормальный и можно доставлять => база не актуальная.
Полнота и актуальность так же определяется % от общего количества объектов.
За ссылку спасибо.
Коды качества знакомые. =) похожи на те что отдает владелец блога.
https://dadata.ru/api/clean/
https://otpravka.pochta.ru/specification#/enums-clean-address-quality
Похоже, но нет.
Не будет отдавать почта такие коды =)
А какие то показатели надежности определены?
Прямая и обратная ошибки? Полнота и актуальность базы?
Подсказки при массовом вводе — это зло, ускоряют ввод, но приводят к необратимым ошибкам (те самые отравленные яблоки). Часто оператор выбирает первый примерно подходящий suggest и если это улица — товар улетает не туда.
На больших городах часто потери такого вида идут.
Определение индекса доставки по строчке — отличная функций, очень полезная. Посмотрим как будет работать.
Можно ссылку на обещание почты?
Он уже купил подписку у вас?=)
Интерфейс обычно ставится под клиента.
То что вы подразумеваете — это так называемые доменные решения.
Если ваш интегратор уже делал проект по вашему домену, то он может притащить решение с прошлого проекта, но 99,99 % он вам не подойдет полностью и начинается допиливание.
Если нужны справочники физ. лиц и юр. лиц смотрите специализированные решения (подкласс MDM — CDI), но как только потребуется разобраться с товарами или НСИ (гос классификаторами или внутренними) — нужно покупать новый продукт и интегрировать с CDI.
Аналогично со всеми специализированными решениями. RDM, PIM, и другими 3-4 буквами.
На MDM рынке 58-60 вендоров на российском рынке 20-30. Выбор большой.
Нужно идти от задачи, а не от того что предлагают.
Ввод подтверждения правильности это как? Окошко с кнопкой «Ок»? их никто не читает.
Не соглашусь с двумя утверждениями.
Выбор одного источника блокирует обновление из других.
Предсказать где появится следующее обновление не можем.
В борьбе за однозначность теряем своевременность. Своевременность важнее.
Подход «выбор лучшего источника» был популярен в MDM/DQ решениях конце девяностых и начале нулевых.
Сейчас решения учитывают «информационную ценность». Оценивается корректность данных (валидность) и актуальность. На основе этих показателей выносится решение какой из двух адресов брать, а какой нет.
При этом в зависимости от типа сравниваемых объектов выбор может склоняться то в сторону «правильный лучше чем актуальный», то «пусть не актуальный, зато правильный»
И второе
С точки зрения первичного ввода — это упрощение, но «списки» имеют тонкий момент. Ошибка в выборе значения списка неисправима. Человеческий фактор опечаток снижается (такие ошибки исправляем), но появляется новый тип ошибок, который исправить невозможно. Чтобы это предотвратить приходится встраивать проверки в интерфейс ввода на непротиворечивость, а это не всегда возможны технически и логически тоже иногда бывает. Если данные ценные то поможет только двойной ввод, а это дорого.
и далее
Сходите к вашим коллегам по MDM
Они поправят.
BI это только третий слой. Про витрины и далее.
Поиск дублей сравнением «каждый с каждым» — тупиковый путь на больших объемах, особенно для хранилищ.
Merge в EDQ — работает, но жестко настроен, при тонкой работе (например клиенты) приходилось использовать внешний обработчик.
В остальном отличный инструмент, рабочий.
Исходя из условий https://yandex.ru/legal/maps_termsofuse/
https://yandex.ru/legal/maps_api/
https://tech.yandex.ru/maps/commercial/
Яндекс сможет всё же контролирует карту.
Госы пока практикуют чаще «всё своё»
Может команда ГосУслуг более прогрессивная.
ETL можно и раз в минуту запускать выгружая произведенные операции.
Отчетность без фактов бизнес сущностей (транзакций) не собрать
MDM это больше про «общий язык» для систем. Маркетинговое — интеграция на уровне данных.
Отчетность использует MDM, но это один из побочных моментов «общего языка»
Если отделить то что убёг человек с первым допуском остается то, что данные грузятся напрямую в облако к разведке США.
Для пользователей привязка фотоснимков не проблема. Для госов и крупного бизнеса (читай возможно подсанкционного) рисковый вариант. Пока что предпочитают stand alone решения, Яндекс тоже почему то госы не используют для своей картографии.
Софт у ArcGIS безусловно сделан хорошо, но вот эти факторы применимость сужают.
Да и подобные истории трехлетней давности не дают покоя.
Для частного бизнеса еще может быть, но для госов — такие штуки табу.
Поищу.
были пара авторефератов в Ленинке доступных без пароля, а так дисеров на эту тему «не много».
Что странно, так как уже затасканные bigdatы и прочие нейронки без этого не живут.
Так как «мусор на входе — мусор на выходе „
Один хранит всё «как есть», а второй «как должно быть в идеальном мире».
Первый без второго живет, но плохо и DWH вынужден «на коленке» делать то что должен делать MDM.
Для себя я провел водораздел по Data Quality функционалу.
DWH не должен преобразовывать данные и содержать какие то правила их изменений.
Всё что ему нужно это обращаться или в DQ или напрямую в MDM с вопросом.
«Что это и есть ли у него связи?»
На примере.
В DWH данные о клиентских транзакциях из двух источников.
Установление связи между клиентами дело MDM. DHW получает таблицу кроссID (Xref) в которой учитываются и внутрисистемные дубли (один клиент заведен 2 раза в одной системе) и межсистемные дубли (один клиент в двух системах)
На основе этой таблицы DWH отдает BI информацию в «как есть» через призму «идеального мира MDM»
Но это же маркетинг.
По факту получается что 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.
1. пробег от клиента до сервера 3-30мс (зависит от расстояния между пользователем и сервером)
2. выборка из кэша первой буквы 1-5 мс
3. пробег обратно 3-30 мс (зависит от расстояния между пользователем и сервером)
Итого 7-65 мс. в большинстве случаев.
Так 4 раза (от 7 до 65)х4 от 28 до 260мс.
Хотя проще клиентско закешировать адрес и всё=)
Чаще всего мы же 2-3 адреса вводим. Дом, работа и еще что нибудь.
1,5 дня аккум держит.
Что бы не говорили, но продукт вышел крутой.
Коды качества определяют качество конкретного результата, а показатели прямой и обратной ошибки определяются обычно на выборе в 10 или 100 тыс записей.
Пресловутые 99,99% из статьи, значат, что прямая ошибка (не нашли) всего 0.01%. Обратная ошибка (отравленные яблоки) не обозначаются.
Полнота базы — дом есть, его нет в базе=> база не полная.
Актуальность базы — дом снесли, а в базе он нормальный и можно доставлять => база не актуальная.
Полнота и актуальность так же определяется % от общего количества объектов.
За ссылку спасибо.
Коды качества знакомые. =) похожи на те что отдает владелец блога.
https://dadata.ru/api/clean/
https://otpravka.pochta.ru/specification#/enums-clean-address-quality
Похоже, но нет.
Не будет отдавать почта такие коды =)
Прямая и обратная ошибки? Полнота и актуальность базы?
Подсказки при массовом вводе — это зло, ускоряют ввод, но приводят к необратимым ошибкам (те самые отравленные яблоки). Часто оператор выбирает первый примерно подходящий suggest и если это улица — товар улетает не туда.
На больших городах часто потери такого вида идут.
Определение индекса доставки по строчке — отличная функций, очень полезная. Посмотрим как будет работать.
Можно ссылку на обещание почты?