Основные данные — это один или несколько атрибутов, которые описывают основные бизнес-объекты, такие как клиенты, поставщики, местоположения, продукты и запасы. Таким образом, основные данные — это основной бизнес-объект, обнаруженный в ходе анализа бизнес-архитектуры предприятия. Другими словами, основные данные — это базовые данные различных ИТ-систем, которые уже существуют на предприятии и задействуют основные бизнес-процессы цепочки создания стоимости.

Для систем ERP самыми основными данными должны быть клиенты, поставщики, материалы, спецификации, продукты, контракты, заказы и т. д. Для систем управления проектами информация о проекте и информация WBS являются самыми основными базовыми данными. Для CRM-системы клиенты и товары продаж являются самыми основными базовыми данными. Существует еще одно условие для того, чтобы базовые данные поднялись до уровня основных данных: данные генерируются в одной исходной ИТ-системе, но будут использоваться в нескольких других ИТ-системах.

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

Даже внутри бизнес-подразделения существует множество интерфейсных и серверных систем, которые содержат критически важные для бизнеса данные, но часто не могут поделиться этой информацией с другими системами. Именно такая ведомствализация данных в несовместимых системах, построенных на различных архитектурах, делает практически невозможным для предприятий создание и поддержание «единого» представления основных данных.

Для оригинальных решений по управлению основными данными одним из аспектов является создание центра обработки данных и хранилища данных. Хранилище данных может чрезвычайно эффективно сохранять системные данные. К сожалению, данные, содержащиеся в хранилище данных, часто очищаются для анализа и составления отчетов, поэтому хранилище данных является полезным дополнением к решению по управлению основными данными, но не само решение.

Также предлагается использовать ERP в качестве базовой системы и других периферийных систем, чтобы базовое управление данными ERP стало основным управлением данными. Но решения для планирования ресурсов предприятия (ERP) предназначены для управления конкретными прикладными процессами, и эти решения, опять же, требуют использования основных данных, а не решений по управлению основными данными. Более того, системы, не относящиеся к ERP, не могут получить доступ к данным в решении ERP.

Поэтому MDM от IBM предлагает новую идею управления основными данными, которая выходит за рамки одного представления и использует правильное представление. Доставляйте нужную информацию к нужному объекту в нужное время и в нужном виде. Это цель управления основными данными (MDM). Управление основными данными описывает набор процедур, технологий и решений, используемых для создания и поддержания согласованности бизнес-данных для всех заинтересованных сторон, таких как пользователи, приложения, хранилища данных, процессы и торговые партнеры, достоверность, полнота, актуальность и точность.

Ключом к управлению основными данными является «менеджмент». Управление основными данными не создает новых данных или новых вертикальных структур данных. Вместо этого он предоставляет предприятиям возможность эффективно управлять данными, хранящимися в распределенных системах. Управление основными данными использует существующие системы, извлекает из этих систем новейшую информацию и предоставляет передовые технологии и процессы для автоматического, точного и своевременного распределения, анализа и проверки данных по всему предприятию.

Решения по управлению основными данными имеют следующие особенности:

• Интегрировать информацию о клиентах, а также другие знания и глубокую информацию из существующих вертикальных структур на уровне предприятия.
• Обменивайтесь данными из всех систем в набор клиентоориентированных бизнес-процессов и услуг.
• Внедрить общую форму основных данных для клиентов, продуктов и поставщиков для ускорения ввода, извлечения и анализа данных. Поддержка многопользовательского управления данными, включая ограничение возможности определенных пользователей добавлять, обновлять или просматривать процессы, поддерживающие основные данные. данные
• Интегрированное управление информацией о продуктах、управление взаимоотношениями с клиентами、интеграция клиентов данных и другие решения для анализа основных данных.

Общий дизайн платформы основных данных MDM

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

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

базовый слой

существоватьбазовый Уровень в основном реализует самые базовые технические возможности. Одним из них является часть механизма ETL, которую необходимо использовать при сборе, очистке и интеграции данных. данныхспособность；с последующимMDMПлатформа должна иметь стандартный технологический компонент механизма рабочего процесса.,Реализуйте визуальное проектирование и моделирование процессов, необходимое для управления содержанием основных данных, последнее — это способность 4A и управление правами;,Конечно для организаций,пользователь,Унификация разрешений также является возможностью, необходимой для полноценного механизма рабочего процесса.

Прикладной уровень

Управление любыми основными данными будет включать два аспекта. Одно из них — это измерение динамического процесса, а другое — измерение статической модели данных.

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

Для системы MDM все возможности моделирования данных будут отражены в модуле управления метаданными, который включает определение каталога данных, определение объекта данных, определение подобъекта, определение иерархии данных и отношений ассоциации, определение объекта данных. Определение каждого подробного данных. элемент и атрибут, определение правил проверки данных, определение источников данных, определение правил сбора и распределения данных и т. д. Это содержимое будет гибко определяться настраиваемым способом при моделировании объектов основных данных.

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

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

Что касается формы, некоторые продукты MDM предоставляют полные возможности моделирования интерфейса основных данных, которые аналогичны возможностям, предоставляемым бизнес-системами BPM. Однако наша система MDM не включает эту часть возможностей. Основная причина заключается в том, что моделирование и проектирование интерфейса — это не простая генерация интерфейса, а реализация большого количества сложных бизнес-правил. Эту часть сложно разработать быстро. аналогичный Платформенный подход полностью автоматизирован и не требует написания кода.

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

общий слой

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

Текущая платформа MDM может поддерживать гибкую публикацию существующего объекта основных данных в системе в качестве интерфейса службы веб-службы. Этот интерфейс может гибко настраивать входные параметры и элементы выходных данных, а также поддерживает публикацию в виде SOAP WebService или Http WebService. Несколько режимов интерфейса службы. .

Чтобы реализовать выпуск интерфейса службы, необходимо начать с определения объекта данных метаданных службы - «определение службы», с интерфейса интеграции данных - «интерфейс службы» и сформировать полное сопоставление между объектом данных и интерфейс сервиса. Эта часть контента находится в платформе MDM. Мы выполнили полную интеграцию. Это формирует полный набор решений: от управления полным жизненным циклом услуг до быстрого открытого обмена возможностями обслуживания данных.

Создайте платформу основных данных MDM на основе драйвера метаданных.

В этом разделе в основном рассказывается об основных идеях построения платформы управления основными данными MDM, основанной на метаданных. Потому что систему MDM следует понимать скорее как платформу быстрой разработки и настройки, которая сочетает в себе управление метаданными и моделирование, а также возможности механизма обработки и обслуживания ETL.

Эта идея полностью соответствует исходной идее, когда мы говорили о построении системы управления изменениями и дефектами IBM-CQ. То есть нам довольно сложно построить платформу быстрой разработки и настройки, охватывающую все бизнес-сценарии. Однако в определенной сфере бизнеса, такой как управление изменениями, рабочий процесс на основе форм, управление основными данными и т. д. сами эти бизнес-сценарии уже есть. Объем возможных требований и правил ограничен. Если вы четко понимаете реальный бизнес-сценарий и лежащую в его основе базовую модель, вам будет проще реализовать платформу быстрой разработки и настройки.

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

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

моделирование объектов

по моделированию в полном объеме объектов. С одной стороны, он может напрямую генерировать фоновую базу таблица данных, с одной стороны, используется для последующего моделирования интерфейса и основного управления. качеством данных。

1. Объекты имеют атрибуты, то есть сначала должна быть четко определена атрибутивная информация объекта. соответствуют конкретным полям.
2. Для каждого атрибута объекта мы должны четко определить правила бизнес-целостности и ограничения данных атрибута.
3. Сам объект может иметь подобъекты, и мы должны иметь возможность дополнительно определить подобъекты объекта. Подобъект будет соответствовать связанной подчиненной таблице в основной таблице в фоновой таблице данных базы данных.
4. Между объектами существует информация об ассоциациях и сопоставлениях, и мы должны иметь возможность соответствовать ассоциациям и сопоставлениям между объектами.
5. Между атрибутами объекта и объектами существует связанная информация, и должна быть возможность определять ассоциации и сопоставления между атрибутами и объектами.

В котором вы можете увидеть моделирование Ядро объектов по-прежнему заключается в объектах и ​​подобъектах, определениях бизнес-правил атрибутов объектов, отображении связей между объектами и объектами и т. д. Конечно, мы также можем использовать базу данные представляют собой объекты обратного проектирования. В моделировании объектов Заканчиватьмоделирование Вся соответствующая информация об объектах должна храниться в соответствующих таблицах данных управления метаданными, которые являются основным содержанием. Полные метаданные могут генерироваться полностью автоматически, включая простые объектные функции CRUD.

Моделирование формы

существоватьмоделирование После завершения объектов следующее, что нужно учитывать, — это моделирование. формы,Функциональный интерфейс CRUD объекта основных данных, реализованный посредством Моделирование формы, может быть гибко настроен. Это похоже на пользовательскую форму на платформе быстрой разработки.,То есть подробно определите макет каждой формы CRUD.,Компонент пользовательского интерфейса, конкретно представленный каждым элементом атрибута в форме.

проходить Моделирование Форма может реализовать конкретный макет формы ввода основных данных, а затем реализовать ввод каждого атрибута, будь то поле ввода или выбора, или выбор из связанных подтаблиц и т. д. Моделирование Предложение по метаданным после формы должно быть с моделированием. данные объектов разделены, то есть хранятся в независимых таблицах метаданных.

моделирование процессов

существоватьполныйхозяинданныеуправлять Платформа должна быть задействованахозяинданные的内容和процессуправлять,Аналогично созданию основных данных,Изменения или отказы могут включать в себя соответствующие операции по утверждению процесса.,Оно вступит в силу только после завершения утверждения. Поэтому после реализации полной функции формы следующее, что следует рассмотреть, — это обработать ее с помощью механизма рабочего процесса.,Окончательный созданный шаблон рабочего процесса можно связать с формой. Сама машина процесса предполагает организацию,персонал,Персонажи и другой контент, связанный с 4A,Эту часть контента можно хранить в системе MDM.,Также должна быть возможна синхронизация с 4A или портальными системами.

Когда дело доходит до этого места, вы можете увидеть полную функцию управления основными данными поставщиков.,моделирование объектов путем сосредоточения вокруг бизнес-объекта базы поставщиков,После моделирования интерфейса и процессов моделирования должна появиться возможность полностью автоматически сгенерировать соответствующую функцию CRUD.,включая одобрениепроцесс Реализация。Однако любой платформе быстрой разработки сложно по-настоящему обрабатывать специальные бизнес-правила.。

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

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

После того, как предыдущие базовые возможности будут достигнуты, мы поговорим о двух ключевых моментах, а именно об основном управлении интеграцией данных и главном управлении качеством данных.

Управление интеграцией данных

Для главного управления интеграцией Данные на самом деле состоят из двух частей: одна — ETL, а другая — сервисный интерфейс SOA. Для ETL в основном реализуется инициализация. данные и чистое хранилище. Интерфейс службы SOA может предоставлять возможности службы основных данных через службу интерфейса или реализовывать распространение и уведомление о событиях основных данных в реальном времени на платформе управления основными данными MDM через механизм публикации и подписки сообщений.

Нет необходимости много говорить о функциях части ETL. Мы можем интегрировать и встроить легкий инструмент и функцию ETL. Функции сервисной части SOA включают в себя на основе предыдущего моделирования Метаданные, определенные объектами, позволяют публиковать стандартные сервисы. То есть после того, как мы определим полный объект, мы можем опубликовать основные данные как интерфейс службы WebService с помощью мастера, который может быть либо интерфейсом службы отдыха, либо интерфейсом службы мыла. интерфейс службы веб-сервиса. Какие входы и выходы необходимы для конкретного опубликованного интерфейса, следует гибко настраивать. Конечно, мы также можем поддерживать механизм публикации сообщений и подписки на основные данные на платформе MDM, то есть изменения в основных данных MDM распространяются в бизнес-систему в режиме реального времени через модель подписки на сообщения.

Управление качеством данных

Управление качеством Данные — это сложный момент в управлении основными данными, который включает в себя два аспекта. Один из них — анализ качества отдельных объектов данных. Это делается посредством моделирования. могут быть выполнены определенные временем бизнес-правила и правила честности. Конечно, мы также можем определить качество данных отдельно.,Мы можем привязать правило к конкретному бизнес-объекту или свойству бизнес-объекта. Затем выполните анализ качества данных одного объекта на основе этих правил. Второй — аудит данных между несколькими таблицами.,Мы говорили о том, что платформа управления основными данными в конечном итоге должна решить проблему противоречивых основных данных в многоотраслевых системах.,Но даже если вы используете платформу основных данных, вам все равно необходимо проверять содержимое одного и того же объекта данных в нескольких бизнес-системах.,Выявляйте несоответствия данных в режиме реального времени и заранее предупреждайте. Основные идеи аудита данных,У меня есть предыдущая статья, в которой об этом конкретно говорится.

Если вышеуказанное содержание будет реализовано, то окончательная предоставленная платформа основных данных будет базовой платформой, которая может быстро внедрять основные данные для различных предприятий. Эта платформа позволяет настраивать 80% работы по внедрению основных данных. В то же время мы также можем больше сосредоточиться на сортировке бизнес-процессов основных данных и спецификациях управления управлением, интеграции основных данных и внедрении специальных основных данных. правила бизнеса.

От разработки настройки основных данных до быстрой разработки конфигурации

Судя по обмену основными данными MDM за последние 1–2 года, многие компании надеются на полностью гибкую и настраиваемую платформу основных данных, но без возможностей консультирования по планированию основных данных и возможностей внедрения.

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

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

1. 4A и модель разрешений: реализуйте гибкую настройку организаций, пользователей, разрешений и т. д.
2. Process Engine: внедрение гибких и настраиваемых процессов утверждения
3. моделирование объектов: реализовать гибкое создание и настройку объектной модели основных данных, включая соединение и сопоставление объектов и таблиц данных.
4. Моделирование форм: реализация настройки и визуального дизайна форм, сопоставление форм и объектных моделей.
5. Моделирование правил. Внизу находится механизм правил, который может реализовать гибкую настройку или определение правил в сценарии.
6. Модель интеграции: реализует автоматический выпуск объектов в службы интерфейса и может реализовать интеграцию. Автоматизированная настройка и интеграция данных

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

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

После того, как платформа основных данных обладает ключевыми базовыми возможностями платформы быстрой разработки, она также добавляет ключевые технические базовые возможности, а именно:

1. ETLинтеграция данные: возможность добиться интеграции данные, очистка, преобразование и хранение данных
2. Интеграция SOA: возможность быстро публиковать объекты данных в виде сервисов интерфейса и стандартизировать публикацию и подписку сообщений.

С добавлением этих двух возможностей он по сути обладает возможностями стандартизированной платформы управления основными данными.

Фактически, наша текущая платформа основных данных не подходит для 4A.,процессдвигатель,моделирование объектов, интегрированное моделирование, ETL и другие ключевые технические возможности — все это доступно, но не хватает динамического моделирования. моделирование форм и правил,Хотя мы и раньше реализовали простую техническую составляющую,Однако в ходе реализации мы все же обнаружили, что для некоторых сложных сценариев управление основными данными,Трудно завершить проектирование и разработку функций просто путем настройки.

У нас уже есть дизайнер форм и пользовательские формы, но даже формы и правила по-прежнему требуют индивидуальной разработки. Другие технические компоненты и возможности позволяют достичь полной гибкости и настраиваемости. Это текущие возможности нашей платформы основных данных. У нас по-прежнему есть достаточные преимущества для компаний, которые уделяют больше внимания возможностям планирования, консультирования и внедрения.

Тенденция платформы основных данных должна быть от технологической платформы к бизнес-платформе.

Приведем простой пример: если вы работали над системой основных данных MDM для автомобильной промышленности, после ее многократного внедрения вы, естественно, будете знать, какие основные данные используются в автомобильной промышленности и что представляет собой каждый объект основных данных. Какие общие базовые поля и расширенные поля должны быть включены. Эти обобщенные модели основных данных часто применимы к другим отраслям автомобилестроения.

Затем в это время ваша платформа основных данных просто превратилась из технологической платформы в бизнес-платформу. То есть после многих лет создания и внедрения вашей платформы основных данных MDM опыт внедрения был накоплен в информационных активах. платформа мастер-данных. Этот информационный ресурс сам по себе ценен.

Моделирование системных данных MDM

Уже упоминалось ранее,MDMВсе последующие идеи конструкции платформы сосредоточены вокругмодель данных Эти ключевые метаданные управляют созданием,От моделирования данных к моделированию бизнес-правил,моделирование процессов и моделирование интерфейсов и многое другое,Наконец, это распространяется на возможности интеграции сервисов периферийных интерфейсов. Насколько сильны возможности моделирования?,Является ли он гибким и масштабируемым?,Часто напрямую влияет на простоту использования и масштабируемость платформы MDM.

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

Ключевые процессы и этапы всего моделирования основных данных должны быть следующими:

1. Создайте объекты данных, такие как поставщик, объекты данных материала. Объекты данных могут иметь несколько уровней структуры.
2. Создайте подобъект объекта данных, то есть объект данных может иметь подобъекты, а подобъект также может иметь подобъекты.
3. Создайте информацию об элементе данных для объектов данных или подобъектов, включая имя, тип и другие расширенные атрибуты элемента данных.

Вышеупомянутые три ключевых шага позволяют создать базовый объект данных. Каждый объект данных и подобъект соответствует таблице в базе данных. Этот объект данных очень похож на объект домена в нашем дизайне домена. Дочерний объект сам по себе не имеет смысла и должен существовать вместе с родительским объектом. Для каждого соответствующего элемента данных в моделировании это информация поля данных в фактической таблице данных.

Таким образом, после завершения моделирования данных можно напрямую формировать динамические операторы Sql и напрямую создавать фоновую структуру таблицы базы данных.

В моделировании данных В объектах можно рассмотреть возможность добавления функции создания папок.,Или мы можем добавить отдельную функцию для создания группировки атрибутов для объектов данных.,То есть различные атрибуты и подобъекты можно группировать и управлять ими. Одним из аспектов этой группы является то, что мы поддерживаем ее и управляем ею.,Один из них — напрямую сопоставить различные атрибуты группировки с разными вкладками во время моделирования интерфейса.

Сами типы элементов данных должны включать как минимум следующее:

1. Простые типы данных ввода: символьные, числовые, дата
2. Тип данных списка, выбор из раскрывающегося списка: поддерживает выбор из словаря данных, также поддерживает выбор из независимых других объектов таблицы данных.
3. Тип выбора окна перехода: поддерживает связь с другим объектом внешней таблицы данных.
4. Тип файла: поддерживает загрузку файлов. Обратите внимание, что один объект данных может поддерживать возможность загрузки нескольких вложенных файлов.
5. Тип таблицы: в процессе обслуживания объекта данных подобъекты должны быть сопоставлены с типом таблицы по умолчанию.

Типы данных списка часто должны поддерживать режимы многоуровневой классификации. Например, при ведении информации о материале вы можете сначала выбрать основную категорию материала, затем выбрать подкатегорию, а затем выбрать подкатегорию. Будет установлена ​​связь. между тремя небольшими раскрывающимися списками.

Выше приведены самые основные возможности обслуживания типов элементов данных, за которыми следует базовая возможность проверки целостности поля, которая включает в себя проверку нуля сцены, проверку числового типа, проверку длины, проверку размера значения и проверку пользовательского сценария (если a>0 and b>0 then c>0）ждать。Они обеспечивают основу для ввода данных.честность。

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

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

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

Полное определение модели основных данных должно фактически включать метаданные данных, метаданные бизнес-правил и метаданные интерфейса. Все, что должно отображаться в интерфейсе, правилах представления и макета и т. д., — это метаданные интерфейса. Их также можно поддерживать единообразно во время обслуживания модели данных.

Для основных данных на уровне объекта также необходимо вести дополнительную информацию об атрибутах, в том числе:

• классы данных интеграции (сбор данных,распределение данных,Интегрированный интерфейс и т. д.)
• Класс отношений ассоциации (отношения управления между этим объектом данных и другими объектами данных)
• Класс данных (соответствующий базе данные, определение источника данных или информация таблицы данных)

Одним из результатов, который должен быть достигнут после завершения определения метаданных, является создание базовой базы данных. Таблицу данных можно использовать для автоматического создания интерфейсов, а также для сбора и интеграции данных. Ее также можно использовать для размещения данных на основе бизнес-правил. качеством данных。

Управление качеством данных

Управление качеством данных（Data Quality Управление) относится к ряду управленческих действий, таких как выявление, измерение, мониторинг и раннее предупреждение о различных проблемах с качеством данных, которые могут возникнуть на каждом этапе жизненного цикла данных: при планировании, приобретении, хранении, совместном использовании, обслуживании, применении и смерть, а также дальнейшее улучшение качества данных за счет улучшения и повышения уровня управления организацией.

Аспекты оценки качества данных в основном включают в себя следующие аспекты:

1. Целостность. Полнота. Целостность — это показатель того, какие данные потеряны или недоступны.
2. Соответствие: Соответствие — это мера того, что данные не хранятся в едином формате.
3. Согласованность. Согласованность измеряет, какие значения данных конфликтуют по смыслу информации.
4. Точность Точность: Точность — это показатель того, насколько данные и информация неверны или устарели.
5. Уникальность Уникальность: Уникальность используется для определения того, какие данные являются повторяющимися данными или какие атрибуты данных дублируются.
6. Корреляционная интеграция: корреляционные меры, связанные с которыми данные отсутствуют или не индексируются.

Для вышеуказанного контента мы работаем над системой управления основными данными MDM. качеством данныхмодуль,В том числе при реализации преобразования и очистки данных в ETL-инструментах и ​​т. д.,Это все, что необходимо учитывать и поддерживать.

И для Управления качеством Данные должны охватывать полный жизненный цикл управления данными о рождении, старости, болезни и смерти. Для удобства мы сосредоточимся на двух распространенных реализациях. качеством этап данных, один из них — Этап, реализованный с помощью инструментов ETL. сбора и интеграции данных, один из них — это ежедневная проверка и аудит данных в режиме реального времени. Давайте поговорим об этих двух общих этапах отдельно.

Этап сбора и интеграции данных

Многие из сегодняшних операций ETL были преобразованы в операции ELT, то есть часть содержимого Transform, о котором мы говорим, завершается в процессе передачи ETL, а некоторая часть была преобразована в завершение преобразования данных в целевой базе данных после данные собираются в целевую базу данных.

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

Одним из ключевых моментов уникальности данных является дедупликация и сходство. Для дедупликации мы можем выполнить настройку преобразования в инструменте ETL, но для сходства нам часто приходится писать независимые коды или скрипты для анализа после завершения последующего сбора данных. данные и завершить удаление данных о сходстве или объединить данные после подтверждения вручную.

Один тип основных данных часто включает в себя несколько таблиц, например основные данные поставщика, которые включают в себя несколько подобъектов, таких как основная информация, контактная информация, информация об учетной записи и т. д. Эти подобъекты могут быть иерархическими отношениями или отношениями ассоциации. Мы определим это подробно при определении объектов и отношений основных данных. Эта корреляция приводит к ограничениям ссылочной целостности. Например, контактная информация поставщика имеется, но соответствующий заголовок поставщика не может быть обработан в ETL, но его можно найти с помощью сценариев. Ненормальные данные обрабатываются и очищаются. вручную.

Ежедневная проверка данных

Сами основные данные также постоянно увеличиваются.,Поэтому после завершения инициализации очистки данных,После того, как платформа основных данных начнет работать нормально,Нам также необходимохозяинданные内容进行日常的данные检查和管控。Это также Управление качеством Важное содержание данных.

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

1. Определите правила проверки данных, включая проверку атрибутов одной таблицы, повторную проверку перекрестных строк, проверку зависимостей ассоциаций нескольких таблиц и проверку согласованности.
2. Определить задачи проверки и контрольные списки
3. Настройте контрольный список в виде расписания, чтобы автоматически выполнять его регулярно и вовремя.
4. Просматривайте отчеты о проверке данных и выполняйте ручную или автоматизированную обработку аномальных данных.

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

Например, если данные о поставщиках собираются из двух систем, то для того, чтобы сопоставить и проверить различия и согласованность данных о поставщиках в двух системах, требуется независимая функция аудита данных. При аудите данных сначала используется уникальное ключевое слово, соответствующее объекту данных, а во-вторых, определяются поля, требующие аудита данных. Для двух таблиц данных A и B общие результаты аудита и сравнения данных в основном включают следующие аспекты.

1. Какие данные в таблицах А и Б совпадают?
2. Какие данные есть в таблице А, но нет в таблице Б, или наоборот.
3. Какие данные имеют как A, так и B, но содержание элементов данных противоречиво.

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

Наконец, позвольте мне подчеркнуть, что хотя Управление качеством данные — это весь жизненный цикл,Однако реальное улучшение качества данных не должно осуществляться постфактум путем проверки и аудита данных.,Вместо этого мы действительно начинаем с источника проблемы с данными. Например, решение проблемы многократного и многоточечного ввода источников данных.,Решите проблему, заключающуюся в том, что одни и те же данные могут быть изменены в нескольких системах.,Решить модель данных中定义的данные约束существоватьданные录入的时候没有进行честностьпроблемы с контролемждать。

Система MDM - сервисы интерфейса и передачи данных

Когда дело доходит до платформы основных данных, интерфейсы и службы данных или интегрированное управление являются обязательными возможностями для MDM. В решениях MDM для обсуждения реализации этих двух частей часто используются сервисные шины ETL и ESB.

Прежде всего, мы видим, что MDM предполагает внешнюю интеграцию, которая в основном включает в себя два аспекта: один — это процесс сбора данных, а другой — процесс распространения данных и предоставления услуг передачи данных. Поэтому процесс интеграции необходимо обсудить. эти два аспекта.

Сбор данных

Процесс сбора данных необходимо разделить на два разных сценария, чтобы объяснить:

• Сбор инициализации данных: его необходимо выполнить через ETL. Во-первых, объем данных большой, а во-вторых, его необходимо очистить в процессе ETL.
• Инкрементальный сбор данных: осуществляется посредством регистрации в режиме реального времени в сервисе интерфейса шины ESB. Обеспечьте сбор данных в режиме реального времени.

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

Конечно, если принята модель централизованного построения, то есть сами основные данные создаются в системе MDM, то в этом случае процесс сбора основных данных отсутствует.

Распределение данных

Само Распределение данных делится на две ситуации:

• Распространение данных. Для распространения используйте модель публикации и подписки сообщений или напрямую используйте распространение службы синхронизации WS в реальном времени.
• Данные не реализуются: системам MDM необходимо предоставлять только интерфейсы обслуживания запросов в реальном времени для основных данных.

В настоящее время чаще всего используется распределение данных.,Для распространения данных,Если существует относительно много бизнес-систем, которые подписаны на MDM,Лучше всего использовать модель публикации-подписки сообщений.хозяинраспределение данных,Конечно, вы по-прежнему можете использовать сервисы WS для распространения.,Однако системе MDM необходимо несколько раз вызывать сервисный интерфейс для выполнения операции Распределение данных.,Контролируйте процесс распространения с помощью аспектов.

дляраспределение данных,Если есть пакетное Распределение данных,напримерперсоналили организацияхозяинданные出现了批量变更,В этом сценарии используйте сообщение илиWSРаздачу можно сохранитьсуществовать大данные下的性能问题。Или скажитераспределение данных Интеграция между сегментами сети, когда предъявляются более высокие требования к безопасности.,Затем в это же время вы также можете экспортировать основные данные, которые необходимо распространить, в формат файла.,проходить Файл будетхозяинраспределение данныхв целевую систему。

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

Как платформа основных данных обеспечивает интерфейс данных и возможности интеграции услуг?

Говоря о статье MDM ранее, я уже упоминал, что мы надеемся, что сама система MDM интегрирует возможность интеграции интерфейсов и сервисов и максимизирует рабочую нагрузку по реализации при построении интеграции интерфейсов. Лучшая модель состоит в том, что сам MDM также имеет некоторые внутренние функции интеграции сервисов ETL и ESB, вместо того, чтобы полностью полагаться на внешние возможности.

Для модуля сбора данных мы можем интегрировать самые базовые возможности интеграции данных, то есть мы можем настроить простые операции ETL и операции планирования задач в системе MDM, а также собирать данные из внешних источников данных в платформу MDM в соответствии с определенными бизнес-правилами. .

Для модуля распределения данных возможны две ситуации.

1. Сценарий распределения данных

1.1 MDM формулирует и импортирует сервисные интерфейсы, генерирует спецификации услуг и контракты, а MDM сопоставляет модель данных со спецификациями услуг.

1.2 Для существующих внешних служб WSDL MDM напрямую выполняет сопоставление служб и распространяет конфигурацию службы без написания кода.

1.3 Публикуйте модель данных MDM непосредственно в промежуточном программном обеспечении сообщений JMS и поддерживайте внешние системы для подписки на сообщения.

2. Сценарий, в котором данные не реализуются

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

2.2 По-прежнему использовать режим «сначала контракт», сначала определить контракт интерфейса запроса данных и сопоставить модель данных MDM со спецификацией услуги.

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

Логистический ИТ-круг

Обмен ИТ-знаниями и общение в общелогистической отрасли, специалисты-практики помогают друг другу, включая экспресс-доставку/Интернет-логистическую платформу/городскую дистрибуцию/мгновенную доставку/3PL/складскую дистрибуцию/экспедирование грузов/холодовую цепь/компанию по разработке программного обеспечения для логистики/логистическое оборудование/оборудование для автоматизации логистики /логистика Робототехника и другие подотрасли.