Значительная часть требований к информационным системам связана не только с действиями, которые должна выполнять система, но и с информацией, с которой эти действия выполняются. Клиенты оформляют заказы, сотрудники работают с документами, договоры относятся к организациям, платежи погашают обязательства. Для анализа недостаточно перечислить необходимые поля или определить набор экранных форм. Необходимо установить, какие информационные объекты существуют в предметной области, какими характеристиками они обладают и как связаны между собой.
Моделирование данных решает эту задачу путем формализованного представления значимой для бизнеса информации. В BABOK модель данных рассматривается как средство описания сущностей, классов или объектов данных, относящихся к предметной области, их атрибутов и взаимосвязей. Такая модель создает общее понимание семантики информации и становится основой для дальнейшего анализа и реализации решения.
Для бизнес-аналитика моделирование данных особенно важно там, где одинаковые слова скрывают разные понятия или, напротив, разные подразделения используют различные названия одного объекта. Модель заставляет перейти от обсуждения отдельных экранов, документов и операций к структуре информации, с которой работает предприятие.
Назначение техники
Согласно BABOK, назначение моделирования данных состоит в описании относящихся к предметной области сущностей, классов или объектов данных, используемых для их описания атрибутов и существующих между ними взаимосвязей. Цель такого описания — сформировать общее понимание терминов, то есть семантики, необходимое для дальнейшего анализа и внедрения.
Практическое значение этого назначения шире простого документирования данных. Модель позволяет участникам инициативы договориться о том, что именно они понимают под клиентом, договором, заявкой или продуктом, какие характеристики этих объектов существенны и какие отношения между ними допустимы. Поэтому моделирование данных одновременно выполняет аналитическую и коммуникационную функции.
Описание техники
В BABOK модель данных описывается как диаграмма, обычно сопровождаемая текстовым описанием. На ней представляются значимые для бизнеса элементы, например люди, места, вещи и бизнес-операции, связанные с ними атрибуты и существенные взаимосвязи. Модели данных применяются при выявлении и анализе требований, проектировании решения, а также при поддержке внедрения и непрерывного улучшения продукта.
BABOK различает три типа моделей данных.
Концептуальная модель данных не зависит от конкретного решения или технологии. Она показывает, как бизнес воспринимает собственную информацию, и может использоваться для формирования согласованного словаря терминов и описания отношений между информационными элементами. На этом уровне центральным вопросом является не устройство будущей базы данных, а смысл информации для бизнеса.
Логическая модель данных представляет собой абстракцию концептуальной модели и включает правила нормализации, применяемые для формального управления целостностью данных и взаимосвязями. BABOK связывает этот уровень с дизайном решения.
Физическая модель данных используется специалистами по разработке для описания физической организации базы данных. Здесь рассматриваются вопросы производительности, многопоточности и безопасности.
Эти три модели создаются для разных целей и могут существенно различаться даже тогда, когда описывают одну предметную область. Это принципиальное различие: концептуальная модель не является просто менее подробной физической моделью. Каждая из них отвечает на свой набор вопросов и ориентирована на соответствующую аудиторию.
На концептуальном уровне различные нотации моделирования, согласно BABOK, скорее всего приведут примерно к одинаковому результату. Логические и физические модели, напротив, содержат элементы, зависящие от выбранного решения. Поэтому их обычно разрабатывают заинтересованные стороны, имеющие опыт реализации конкретных технологий. Для реляционных баз данных могут применяться логические и физические ERD, а для объектно-ориентированной разработки — логические и физические диаграммы классов.
Отдельно BABOK упоминает диаграммы объектов. Они позволяют показать конкретные экземпляры сущностей с действительными примерами значений атрибутов. Благодаря этому абстрактная модель становится нагляднее для заинтересованных сторон.
Элементы техники
Сущности или классы
Данные в модели представлены сущностями, классами или объектами данных. Сущность может обозначать физически существующий объект, например склад; организационное понятие, например торговую зону; абстрактный объект, например продуктовую линейку; либо событие, например назначение сотрудника на должность. Сущность содержит атрибуты и связана с другими сущностями модели.
В диаграмме классов аналогичную функцию выполняют классы. Они также имеют атрибуты и отношения с другими классами, но дополнительно могут содержать операции или функции, описывающие действия, которые можно выполнять с классом, например выставление счета-фактуры.
Каждый экземпляр сущности или класса должен иметь уникальный идентификатор, позволяющий отличить его от других экземпляров. На практике выделение сущностей помогает бизнес-аналитику отделить самостоятельные информационные понятия от их характеристик. Например, «договор» может быть сущностью, а «дата заключения» — его атрибутом.
Атрибут
Атрибут определяет конкретную часть информации, связанную с сущностью. Его описание охватывает объем и тип содержащихся данных, возможные значения и характер представляемой информации.
BABOK выделяет в описании атрибута имя, значения и описание. Имя является уникальным названием атрибута, при этом используемые заинтересованными сторонами альтернативные названия могут фиксироваться как синонимы. Значения определяют допустимое содержание атрибута: это может быть перечисление разрешенных значений либо описание формата, включая ограничения по количеству символов. Для аббревиатур необходимо объяснять их значение. Описание определяет смысл атрибута в контексте решения.
Атрибуты могут дополнительно описываться в словаре данных, а допустимые значения — определяться бизнес-правилами. Тем самым модель данных связывается с другими техниками BABOK и не должна рассматриваться как изолированная диаграмма.
Взаимосвязь или ассоциация
Взаимосвязи между сущностями формируют структуру модели. Они показывают, какие сущности связаны и каким образом. Описание взаимосвязи обычно включает минимальное и максимальное количество экземпляров, допустимых с каждой стороны отношения.
BABOK называет это свойство кардинальностью. Типичными значениями являются единица, ноль или множество. Например, каждый клиент может относиться только к одной торговой зоне, тогда как торговая зона может быть связана с нулем, одним или множеством клиентов.
Отношение необходимо уметь читать в обоих направлениях. Такой подход полезен при проверке модели с представителями бизнеса: вместо обсуждения графических обозначений бизнес-аналитик формулирует содержательное утверждение о допустимом количестве связанных экземпляров.
В модели классов вместо термина «отношение» используется «ассоциация», а вместо «кардинальности» — «множественность».
Диаграммы
Модели данных и модели классов могут содержать одну или несколько диаграмм, отображающих сущности, атрибуты и взаимосвязи. Для модели данных BABOK использует диаграмму «сущность-связь» — Entity-Relationship Diagram, ERD. Для модели классов используется диаграмма классов.
Диаграмма является визуальным представлением модели, а не всей моделью как таковой. Это важно практически: графическое изображение должно сопровождаться достаточным текстовым описанием, если одного обозначения сущностей и связей недостаточно для однозначного понимания их смысла.
BABOK иллюстрирует ERD в нотации «воронья лапка», где показываются сущности, уникальные идентификаторы, атрибуты, отношения и их кардинальность, а модель классов — средствами UML с классами, атрибутами, операциями и множественностью.
Метаданные
Модель данных может содержать метаданные, объясняющие, что представляют собой объекты, когда и почему они были созданы или изменены, как их следует использовать, насколько часто, когда и кем.
Кроме описательной информации, метаданные могут фиксировать ограничения на создание и использование сущностей, требования безопасности, конфиденциальности и аудита для отдельных сущностей или их групп.
Метаданные расширяют модель от ответа на вопрос «что существует и как связано?» к правилам обращения с информацией. Для корпоративных информационных систем это особенно существенно, поскольку одинаковая структура данных может иметь совершенно разные требования к доступу, срокам хранения и контролю изменений.
Практическое применение
Работа с моделью данных обычно начинается с определения предметной области и значимых для нее информационных понятий. Источниками служат результаты выявления требований, существующая документация, интерфейсы систем, бизнес-правила и знания заинтересованных сторон. На ранних этапах целесообразно работать прежде всего с концептуальной моделью и согласовывать семантику информации, не перегружая обсуждение техническими деталями.
В работе могут участвовать бизнес-аналитик, эксперты предметной области, владельцы процессов, системные аналитики, архитекторы, разработчики и специалисты по данным. Их участие зависит от уровня модели. Чем ближе модель к физической реализации, тем больше требуется технической экспертизы.
Результатом работы могут быть концептуальная модель, ERD или диаграмма классов, описания сущностей и атрибутов, определения связей и кардинальности, а также связанные метаданные. На основании модели уточняются требования к составу информации, ограничениям значений, целостности связей и будущему дизайну решения.
Практический пример
Рассмотрим внедрение корпоративной системы электронного документооборота для согласования договоров.
Предположим, что на этапе выявления требований представители бизнеса используют понятия «контрагент», «организация», «поставщик» и «партнер», причем разные подразделения вкладывают в них различный смысл. Одновременно выясняется, что один договор может проходить несколько согласований, а сотрудники спорят, является ли согласование свойством договора или самостоятельным объектом.
Бизнес-аналитик начинает с концептуальной модели. В ней выделяются сущности Контрагент, Договор, Сотрудник, Согласование и Документ. На этом этапе задача состоит не в проектировании таблиц базы данных, а в согласовании смысла понятий.
Затем определяются атрибуты. Для договора это могут быть номер, дата заключения, сумма и статус; для контрагента — наименование и регистрационный номер; для согласования — результат и дата решения. Для каждого атрибута уточняются смысл, допустимые значения и необходимые ограничения.
После этого устанавливаются взаимосвязи. Один контрагент может иметь множество договоров, но каждый договор относится к определенному контрагенту. Один договор может иметь множество согласований. Каждое согласование относится к конкретному сотруднику. Для каждой связи определяются минимальная и максимальная кардинальность.
На этом этапе обнаруживается новое требование: история согласований должна сохраняться даже после завершения маршрута. Если бы «согласование» было представлено только текущим статусом договора, история решений отдельных сотрудников была бы потеряна. Формализованное моделирование информации тем самым выявляет требование, которое не было явно сформулировано при первоначальных интервью.
Далее модель дополняется метаданными. Для договоров устанавливаются требования к конфиденциальности и аудиту изменений, а для документов — ограничения доступа. После согласования концептуальной модели специалисты по реализации могут преобразовать ее в логическую, а затем в физическую модель с учетом выбранной технологической платформы.
Таким образом, путь от терминов предметной области до структуры реализации остается прослеживаемым: сначала определяется смысл информации, затем ее логическая организация и только после этого особенности физического хранения.
Хорошие и плохие практики
Хорошая практика состоит в выборе уровня модели в соответствии с задачей и аудиторией. Для обсуждения терминологии с владельцами процессов концептуальная модель обычно полезнее технически подробной физической схемы. Для проектирования реализации, напротив, концептуального уровня недостаточно.
Полезно проверять модель содержательными утверждениями. Связь «Контрагент — Договор» должна быть понятна не только по обозначениям кардинальности, но и как правило предметной области: сколько договоров может иметь контрагент и к скольким контрагентам может относиться конкретный договор.
Плохой практикой является превращение моделирования данных в механическое копирование существующей базы. В этом случае модель фиксирует устройство текущего решения вместо понимания информации бизнеса. Не менее проблематично преждевременно включать технические детали в концептуальную модель: обсуждение индексов, типов хранения и особенностей СУБД затрудняет согласование семантики с представителями предметной области.
Типичные ошибки
Первая ошибка — смешение сущности и атрибута. Бизнес-аналитик представляет самостоятельное бизнес-понятие как поле другого объекта или, наоборот, создает отдельную сущность для характеристики, не имеющей самостоятельного значения. Причиной обычно становится моделирование интерфейса или документа вместо предметной области.
Вторая ошибка — неполное описание связей. Сам факт существования отношения между сущностями не определяет бизнес-правило. Без минимальной и максимальной кардинальности невозможно понять, обязательна ли связь и сколько экземпляров допускается.
Третья ошибка — смешение уровней модели. Если концептуальная модель одновременно содержит бизнес-понятия и детали физического хранения, она становится трудной для обсуждения с бизнесом и при этом недостаточно точной для реализации.
Четвертая ошибка — концентрация на диаграмме при отсутствии определений. Одинаково названные сущности и атрибуты могут интерпретироваться участниками по-разному. Графическая согласованность в таком случае создает только видимость общего понимания.
Наконец, опасно игнорировать метаданные. Структурно корректная модель не отвечает на вопросы безопасности, конфиденциальности, аудита и правил использования информации, если соответствующие ограничения нигде не зафиксированы.
Практические рекомендации
Моделирование целесообразно начинать с языка бизнеса. Сначала необходимо установить, какие понятия действительно существуют в предметной области и что они означают, и только затем выбирать способ их технического представления.
Сложные модели полезно разделять на несколько диаграмм, сохраняя единую модель. Одна перегруженная схема редко помогает коммуникации лучше нескольких представлений, ориентированных на конкретные группы заинтересованных сторон.
Кардинальности следует проверять на конкретных примерах и пограничных ситуациях. Вопросы «может ли договор существовать без контрагента?» или «может ли сотрудник иметь несколько активных назначений?» обычно выявляют правила значительно эффективнее, чем абстрактное обсуждение обозначений.
Наконец, модель следует использовать как инструмент анализа, а не только как результат документирования. Если при ее построении не возникает вопросов к требованиям, терминам и правилам предметной области, полезно проверить, действительно ли модель отражает бизнес-смысл, а не механически воспроизводит уже известную структуру.
Ограничения техники
BABOK указывает два существенных ограничения моделирования данных. Во-первых, чрезмерно строгое следование стандартам моделирования способно сделать модель сложной для людей, не обладающих опытом в IT. Формальная корректность не гарантирует коммуникационной эффективности.
Во-вторых, модель может охватывать несколько функциональных областей и поэтому выходить за пределы знаний отдельных заинтересованных сторон. Это усложняет валидацию: специалист способен подтвердить свою часть модели, но не обязательно всю модель целиком.
При этом техника особенно полезна, когда необходимо сформировать единый набор терминов для специалистов предметной области и реализации, систематически проанализировать данные и их взаимосвязи, проверить соответствие логического дизайна бизнес-потребностям или представить информацию с различным уровнем детализации для разных аудиторий. Формализованное моделирование также способно выявлять новые требования через обнаружение несоответствий.
Моделирование данных не следует превращать в обязательный самостоятельный результат там, где информационная структура тривиальна и дополнительная формализация не приносит ценности. Глубина модели должна соответствовать цели анализа и информационным потребностям заинтересованных сторон.
Вместо заключения
Моделирование данных в BABOK — это техника анализа семантики и структуры информации, а не только способ проектирования базы данных. Она связывает бизнес-представление предметной области с последующим дизайном и реализацией решения через сущности или классы, атрибуты, взаимосвязи, диаграммы и метаданные.
Особая ценность этой техники заключается в возможности последовательно переходить от общего понимания информации бизнеса к более формализованному и техническому ее представлению. Концептуальная, логическая и физическая модели служат различным целям и позволяют сохранять необходимый уровень детализации для соответствующей аудитории.
В системе техник BABOK моделирование данных естественно дополняет словарь данных, анализ бизнес-правил и другие способы моделирования требований. Его результатом становится не просто схема информационных объектов, а согласованное представление того, какая информация существует в предметной области, что она означает, какими свойствами обладает и какие отношения между ее элементами являются допустимыми.