Что такое Data Dictionary и причем тут Data Governance?

Самый быстрый и краткий ответ на первую часть вопроса, а именно что такое Data Dictionary, можно получить из статьи Understanding the Data Dictionary на сайте ISO20022. Сразу оговорюсь, я придерживаюсь и развиваю другую архитектурную концепцию, основанную на стандартах и правилах, заложенных Захманом. С моей точки зрения, модель Захмана более унифицированная и подходит для любой области знаний - будь то касса, магазин или нефтеколонка ))

Но наша задача сегодня понять зачем нам нужен этот инструмент в системе управления данными Data Governance. Для начала немного истории.

Потребность в словарях данных появилась при создании первых систем управления базами данных (СУБД) в 1960-х годах. Организации создавали их, чтобы структурировать свои данные.

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

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

Если вы уже слазили на сайт ISO и сломали там себе немного голову - не беда, я всё же поясню основное назначение Data Dictionary и здесь.

1. Стандартизация технических имен, а именно метаданных, что позволяет навести порядок в распределенной среде разработки.

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

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

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

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

Такой Data Dictionary превращается в полноценный инструмент управления архитектурой данных, позволяющий параллельно хранить различные модели данных и давать визуальное представление о них в виде схем и диаграмм.

1. Ведение единого репозитория объектов данных.

2. Хранение нескольких слоёв моделирования: концептуальный, логический, физический.

3. Визуализация архитектуры данных в виде различных схем и диаграмм.

4. Встроенные механизмы ML/AI для распознавания, структурирования и описания данных из внешних источников.

Такой функционал очень редко можно увидеть встроенным в обычный Датакаталог. Скорее, тут надо говорить уже об экосистеме, так как сама по себе функциональность проектирования и поддержания в актуальном состоянии нескольких моделей данных - сложная история. А если увязывать её в единый процесс Data Governance, то она становится ещё сложнее. Ищущим наилучший вариант, я бы первым делом предложила посмотреть на существующие в мире инструменты проектирования баз данных и моделей данных, таких как Sparx и Visual Paradigm. А дальше рассмотреть возможность встроить эти инструменты в единую цепочку поставки ценностей Data Gov.

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

Так что будем смиренно ждать, когда кто-нибудь из наших дозреет до их уровня. ))