Gartner прогнозирует: "К 2023 году организации, которые продвигают обмен данными, превзойдут своих конкурентов по большинству показателей стоимости бизнеса". Программы обмена, совместного использования данных (Data Sharing) требуют качественных, надежных данных. А ранее мы говорили, что метаданные - ключик к данным, без метаданных массивы данных бесполезны. Неслучайно в фреймворке DAMA-DMBOK2 отдельный раздел посвящен управлению метаданными.
Средние и большие компании, особенно корпорации и холдинги, накопили внутри многие терабайты данных, сложные дата интеграционные процессы, в корпоративных хранилищах данные часто избыточны, прослеживаемость родословной (Data Lineage) и удержание экспертизы бизнес-логики преобразований данных часто оставляет желать лучшего. В результате растут:
- • операционные издержки;
- • сроки обеспечения принятия управленческих решений на основе данных;
- • сроки выпуска на рынок новых продуктов;
- • риски отрицательного влияния на бизнес ("проседание" бизнеса);
- • репутационные риски.
Негативных фактов из практики можно привести немало, но не будем о грустном. В ISO 25012 говорится о критерии Trackability - способности прослеживать всю историю передачи и трансформации данных. Неслучайно последние 3-4 года отечественные компании внедряют у себя системы класса Data Governance, такие как, Collibra Data Governance, Informatica Data Governance, Erwin Enterprise Data Intelligence Software, Manta и др., позволяющие:
- • классифицировать данные;
- • поддерживать политики, стандарты и процессы в области данных;
- • автоматически отслеживать и уведомлять об изменениях метаданных систем-источников;
- • проводить регулярный мониторинг качества данных;
- • осуществлять анализ происхождения и влияния данных;
- • и др.
Системы Data Governance - дорогие системы, выполняемые ими построения Data Lineage, разбор (парсинг) SQL-кода ELT-преобразований дают на выходе скорее техническую картину, чем бизнес-логику.
У нас в компании был и есть SAP PowerDesigner Edge Edition версии 16.6, посредством реверс-инжиниринга которым были созданы физические модели (Physical Data Models) слоев хранилища данных. Почему бы не сделать модель сквозных потоков данных от источников до аналитической отчетности (OLAP)? Сделали за 4 месяца (Елисеев Сергей, Салгириев Мохдан)! Нативную модель перемещения данных (Data Movement Model, DMM) не стали использовать, поскольку она громоздка, имеет много уровней вложенности в пользовательском интерфейсе и во многом повторяет визуализацию потоков в ETL-продуктах, т.е. ориентирована на технических специалистов. За основу взяли Free Model (FEM), кастомизировали модель под данную задачу, проверили её на прототипе, а затем, вручную анализируя каждый ETL-пакет (Microsoft SQL Server Integration Services), воссоздали полную панораму. Проект логически декомпозирован на отдельные диаграммы потоков, фрагмент одной из них приведён на скриншоте ниже:
Адаптированные объекты модели "Поле", "Обработчик данных", "BI-атрибут", "BI-показатель" базируются на классе Extended Object, "Таблица", "Куб", "Отчет" - на Area, а "Поток" - на Extended Link:
Напомним, что SAP PowerDesigner имеет собственную объектную модель, позволяет создавать свои элементы, обогощая их дополнительными атрибутами и методами:
...и выводить атрибуты на настраиваемые формы:
Объекты модели "Таблица", "Поле" имеют одноимённые объектные поля, ссылающиеся на таблицы и поля физической модели данных, т.е. физические модели данных привязаны к модели потоков данных. Чтобы при создании очередной диаграммы потоков данных сократить рутинную работу, на диаграмму можно поместить один раз экземпляр объекта "Поле", заполнить для него ссылку на поле физической модели (PDM), а затем в контекстном меню воспользоваться разработанной процедурой (методом) "Загрузить метаданные остальных полей соотв. таблицы из физической модели данных":
В описании каждого экземляра объекта "Обработчик данных" прописываем суть выполняемого преобразования данных на обычном (не техническом) языке в бизнес-терминах. А в отдельных свойствах можно / нужно заполнить информацию о соответствующем ETL-пакете, ETL-задаче (Task), полное имя хранимой процедуры (в случае ELT-подхода) и возможного приведения типа данных поля:
Объекты "BI-атрибут", "BI-показатель", "Куб", "Отчет" также имеют свои расширенные свойства. Так, у объекта "Отчет" есть ссылочное поле на каталог отчетов (отдельная модель в SAP PowerDesigner). Таким образом, формируется комплект взаимосвязанных моделей. И это еще не предел, поскольку можно пойти дальше (что и делали) - создавать модель бизнес-процессов в нотации BPMN, пристыковывая к существующим моделям данных, отчётов.