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

11.2. Моделирование и проектирование данных

Моделирование данных – критически важный компонент управления данными. Оно требует от организации выяснения и документирования того, как данные соотносятся друг с другом в рамках общей картины. В то же время моделирование само по себе заключается в разработке решений в отношении компоновки данных и их связи. Модели данных отражают и одновременно улучшают понимание организацией информационных активов, которыми она располагает и оперирует[397],[398].

11.2.1. Определение области знаний «Моделирование и проектирование данных»

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

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

Модели данных – важная форма метаданных. Они содержат полезные для потребителей данных сведения. Значительная часть этих сведений, выявленных в процессе моделирования, необходима другим

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

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

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

11.2.2. Цели и бизнес-драйверы

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

Модели данных имеют критическое значение для эффективного управления данными, поскольку они:

●определяют единую общую терминологию во всем, что касается данных;

●собирают и документируют точные знания (метаданные) о данных и информационных системах организации;

●служат основным средством коммуникации в процессе реализации проектов;

●являются отправной точкой при настройке, интеграции или

замене приложений[399].

11.2.3. Разновидности моделей данных

Существует множество различных типов моделей данных. Наиболее распространенные из них: реляционная, многомерная, объектно-ориентированная, на основе фактов, хронологическая и NoSQL[400]. Разработчики информационных систем используют модели в зависимости от потребностей, а также особенностей моделируемых данных и систем организации, для которой разрабатывается модель. Различные типы моделей данных визуально представляют данные с помощью различных соглашений.

Модели также различаются в зависимости от уровня абстракции объектов, которые они отображают: концептуальная с высоким уровнем абстракции; логическая со средним уровнем абстракции и физическая, которая отображает конкретную систему или экземпляр данных. При разработке информационных систем концептуальное и логическое моделирование данных относят к категории работ по планированию и анализу требований, а физическое моделирование данных – к проектным работам[401][402].

11.2.4. Строительные блоки моделей данных

Вне зависимости от типа моделей, в большинстве из них выделяются одни и те же компоненты – «строительные блоки»: сущности, связи, атрибуты и области значений атрибута. Приведенные здесь определения и примеры помогут составить представление о том, как работают модели данных[403],[404].

Сущность

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

вопросов (кто, что, где, когда, почему и как) или сочетание таких ответов. В таблице 11.3 приведены определения и примеры общеупотребительных категорий сущностей[405].

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

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

Мощность отображается специальными символами («вилками») на обоих концах линии связи. Допустимые значения мощности – ноль, один или много («много» означает «больше чем один»). Возможны произвольные сочетания трех этих значений на противоположных концах связи.

На рисунке 11.6 показаны различные соотношения значений мощности связи на примере реляционной модели данных[406]. В организации работает один или несколько сотрудников. Сотрудник может содержать ноль, одного или нескольких иждивенцев. Но сотрудник занимает одну и только одну должность в течение определенного периода времени. Мощность связи – это способ фиксации правил и предположений, связанных с данными. Если данные показывают, что сотрудник выполняет более одной работы в течение установленного периода времени, то в них имеется ошибка или в организации допускаются отклонения от правила.

(расположенными на диаграмме над ними) добавлены так называемые внешние ключи. Атрибут (или набор атрибутов) сущности, который является внешним ключом, предназначен для хранения значения первичного ключа другой сущности. У каждого экземпляра сущностей «Сотрудник» и «Иждивенец» значение внешнего ключа должно совпадать со значением первичного ключа одного из экземпляров соответствующих связанных сущностей.

Домен

Отметим, что в моделировании данных доменом обычно называется исчерпывающим образом описанный набор, диапазон или множество значений, которые могут быть присвоены атрибуту. В свою очередь, определение домена – одно из средств стандартизации характеристик атрибутов. Например, домен «Дата», включающий все допустимые значения календарных дат, может задаваться для любого атрибута датировки в логической модели и для любых столбцов/полей дат в физической модели данных, таких как:

●дата_приема_на_работу;

●дата_поступления_заказа;

●дата_рекламации;

●дата_начала_занятий.

Домены важны для понимания качества данных. Все значения, входящие в домен, являются допустимыми значениями. Те, которые выходят за его границы, – недопустимы. Домен для атрибута «дата_приема_на_работу» может быть определен просто как действительные даты. Согласно этому правилу, он, например, не включает 30 февраля любого года.

* DAMA. DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition. Technics Publications, 2017. (Русский перевод: DAMADMBOK: Свод знаний по управлению данными. Второе издание / Dama International. – М.: Олимп-Бизнес, 2020.)

11.2.5. Контекстная диаграмма области знаний и уровни зрелости функции «Моделирование и проектирование данных»

Контекстная диаграмма области знаний «Моделирование и проектирование данных» представлена на рисунке 11.8.

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

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

На рисунке 11.9 представлены обобщенные характеристики уровней зрелости функции «Моделирование и проектирование данных».