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

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

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

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

Если процессы показывают движение информации, то данные показывают то, что остается после выполнения процесса.

Что такое модель данных

Модель данных (Data Model) представляет собой формализованное описание данных предметной области, их структуры, свойств и взаимосвязей.

Проще говоря, модель данных отвечает на три фундаментальных вопроса:

• Какие объекты существуют в системе?
• Какие характеристики есть у этих объектов?
• Как объекты связаны между собой?

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

Например, интернет-магазин может содержать следующие объекты:

• Пользователь
• Заказ
• Товар
• Платеж
• Доставка

Каждый из этих объектов существует в реальном бизнесе независимо от конкретной информационной системы. Модель данных лишь фиксирует это знание в структурированной форме.

По своей сути Data Model является одним из наиболее важных инструментов анализа предметной области.

Почему модель данных так важна

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

Способ оформления заказа может измениться несколько раз за год. Маркетинговые кампании могут меняться ежемесячно. Интерфейсы могут полностью перерабатываться каждые несколько лет. Но сущности «Клиент», «Заказ», «Товар» или «Договор» обычно существуют десятилетиями.

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

Она позволяет:

• понять структуру предметной области
• выявить скрытые бизнес-объекты
• избежать противоречий в системе
• обеспечить единое понимание между участниками проекта
• повысить качество интеграций
• снизить риск ошибок проектирования
• создать основу для дальнейшего развития системы

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

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

Модель данных как язык бизнеса

Существует распространенное заблуждение, что Data Model нужна только архитекторам или разработчикам баз данных. На практике качественная модель данных является языком коммуникации между бизнесом и IT.

Бизнес говорит:

«Клиент может иметь несколько договоров».

Бизнес-аналитик отражает это в модели данных как связь между сущностями.

Разработчик реализует эту связь в системе.

Тестировщик проверяет ее корректность.

Все участники проекта используют один и тот же смысловой каркас.

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

Основные элементы модели данных

Несмотря на разнообразие нотаций и инструментов, большинство моделей данных строится вокруг трех базовых элементов:

• сущностей
• атрибутов
• связей

Именно они позволяют описать практически любую предметную область.

Сущности (Entities)

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

Примеры сущностей:

• User
• Customer
• Order
• Product
• Invoice
• Employee

Хорошая сущность обычно обладает следующими признаками:

• имеет собственный жизненный цикл
• имеет уникальный идентификатор
• обладает набором характеристик
• существует независимо от отдельных операций

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

Атрибуты (Attributes)

Атрибуты описывают свойства сущности.

Для сущности Customer атрибутами, например, могут быть:

• Customer ID
• Name
• Email
• Phone
• Registration Date

Для сущности Product:

• Product ID
• Product Name
• Price
• Category
• Status

Атрибуты позволяют определить, какую именно информацию необходимо хранить о конкретном объекте.

Важно помнить, что атрибуты не должны содержать данные других сущностей.

Например, в карточке заказа не следует хранить полное описание клиента, если существует отдельная сущность Customer.

Связи (Relationships)

Связи показывают, как сущности взаимодействуют друг с другом.

Наиболее распространены три типа связей.

Один к одному (1:1)

Каждому объекту первой сущности соответствует только один объект второй сущности.

Пример:

Пользователь ↔ Паспорт

Один ко многим (1:N)

Одному объекту соответствует множество связанных объектов.

Пример:

Клиент → Заказы

Один клиент может иметь много заказов.

Многие ко многим (N:M)

Каждый объект может быть связан со множеством объектов другой сущности.

Пример:

Заказ ↔ Товар

Один заказ содержит много товаров.

Один товар может присутствовать во многих заказах.

Подобные связи обычно требуют введения промежуточной сущности.

Например:

• Order
• Product
• Order Item

Уровни модели данных

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

Концептуальная модель

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

Логическая модель

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

Физическая модель

Эта модель описывает структуру конкретной базы данных.

Она обычно содержит:

• таблицы
• индексы
• типы данных
• ограничения
• особенности СУБД

Этот уровень обычно относится к области ответственности архитекторов и разработчиков.

Как сформировать модель данных

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

Шаг 1. Изучение бизнес-процессов

Первым источником информации обычно становятся процессы.

Бизнес-аналитик изучает:

• регламенты
• инструкции
• пользовательские сценарии
• интервью с экспертами

На этом этапе выявляются потенциальные сущности.

Шаг 2. Поиск существительных

Существует простой, но эффективный прием: во время анализа документов выделяются существительные.

Например:

«Клиент оформляет заказ на товар.»

В этой фразе уже содержатся три потенциальные сущности:

• Клиент
• Заказ
• Товар

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

Шаг 3. Определение жизненного цикла

Для каждой сущности необходимо понять:

• как она создается
• как изменяется
• как удаляется
• кто является владельцем данных

Если объект не имеет собственного жизненного цикла, возможно, это вовсе не сущность, а атрибут другой сущности.

Шаг 4. Определение связей

После выявления сущностей необходимо установить отношения между ними.

Именно на этом этапе часто обнаруживаются скрытые бизнес-правила.

Например:

• может ли заказ существовать без клиента
• может ли товар находиться одновременно в нескольких категориях
• может ли один договор иметь нескольких владельцев

Ответы на подобные вопросы формируют структуру модели.

Шаг 5. Валидация с экспертами

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

Очень часто именно на этапе согласования выявляются:

• отсутствующие сущности
• неверные связи
• неоднозначные определения

Типичные ошибки при построении модели данных

Неявные сущности

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

Например, система активно работает с согласованиями, однако сущность Approval отсутствует.

В результате согласование начинает существовать в виде набора технических полей и бизнес-логика становится трудноуправляемой.

Дублирование данных

Еще одна классическая проблема.

Один и тот же объект начинает храниться в нескольких местах.

Например:

• CRM хранит клиента
• ERP хранит клиента
• портал хранит клиента

При этом отсутствует единый источник правильных данных.

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

Отсутствие связей

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

Это приводит к ошибкам проектирования и различным трактовкам требований.

Смешение бизнес-объектов и технических структур

Нередко бизнес-аналитики начинают моделировать таблицы вместо самой предметной области.

Например, появляются сущности:

• TEMP_DATA
• IMPORT_TABLE
• CACHE_RECORD

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

Модель данных должна отражать бизнес-реальность, а не особенности конкретной реализации.

Избыточная детализация

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

Хорошая модель данных должна оставаться инструментом для понимания, а не превращаться в архив технических деталей.

Data Dictionary как продолжение модели данных

Даже идеальная модель данных не отвечает на один важный вопрос:

Что именно означает каждое поле?

Для решения этой задачи используется Data Dictionary.

Что такое Data Dictionary

Data Dictionary представляет собой структурированное описание данных системы.

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

Что содержит словарь данных

Обычно словарь данных включает в себя:

• название поля
• описание
• тип данных
• формат хранения
• допустимые значения
• источник данных
• правила заполнения
• правила валидации
• владельца данных

Например, поле Customer Status может иметь следующее описание:

«Текущий статус клиента в системе обслуживания. Допустимые значения: Active, Blocked, Archived.»

Без подобного описания разные подразделения могут интерпретировать статус по-разному.

Зачем нужен словарь данных

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

Например, поле «Дата клиента» может означать:

• дату регистрации
• дату первого заказа
• дату последнего обращения

Пока определение не зафиксировано, каждый участник проекта понимает его по-своему.

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

Data Model и Data Dictionary: в чем разница

Модель данных и словарь данных решают разные задачи.

На практике эти артефакты дополняют друг друга и редко используются по отдельности.

Связь модели данных с другими артефактами бизнес-анализа

Модель данных не существует изолированно. Она тесно связана с другими аналитическими артефактами.

Так, например, SRS описывает поведение системы и функциональные требования. Модель данных описывает информацию, которой оперирует система.

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

Тестовые сценарии проверяют корректность хранения, обработки и передачи данных.

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

Практическая ценность модели данных для бизнес-аналитика

Для бизнес-аналитика модель данных является не просто техническим документом. Это инструмент исследования предметной области.

Качественная модель данных позволяет:

• быстрее выявлять требования
• обнаруживать скрытые бизнес-правила
• снижать количество противоречий
• улучшать качество коммуникации
• упрощать проектирование интеграций
• обеспечивать трассируемость требований

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

Вместо заключения

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

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