Моделирование данных · Конспекты по бизнес-анализу

Что это#

Руководство BABOK® описывает модели данных (data models) на трёх уровнях:

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

Строительные блоки модели — сущности (entities; в UML — классы): реальные или абстрактные объекты, у которых есть атрибуты. Атрибуты — отдельные факты о сущности; у каждого есть название, описание, тип и допустимые значения. Подробности выносят в словарь данных, а правила для значений — в бизнес-правила. Связи (ассоциации) соединяют сущности и задают кардинальность на обоих концах: ноль или более, один или более, ровно один, диапазон. Модели могут показывать также обобщение, композицию и агрегацию, а ещё метаданные: что представляет сущность, когда и почему она меняется, кто её использует и какие для неё действуют ограничения безопасности и конфиденциальности.

ER-диаграммы в изложении книги BCS#

В книге BCS используется нотация «сущность — связь» (entity-relationship) со следующими соглашениями:

Сущность — прямоугольник, названный существительным в единственном числе. Отличайте тип сущности (Велосипед) от экземпляра (один конкретный велосипед). Ключ — атрибут или набор атрибутов, который идентифицирует один экземпляр.
Связь — линия, которая должна читаться как предложение в обоих направлениях.
«Воронья лапка» (crow’s foot) на конце линии означает «много», простой конец — «один».
Сплошная половина линии означает «должен», пунктирная — «может». Так видно, может ли каждая сторона существовать без другой.
Связь «один к одному» часто говорит о том, что две сущности стоит объединить.
Связь «многие ко многим» разрешают через связующую сущность, превращая её в две связи «один ко многим». Связующая сущность хранит факты о самой связи (даты, количества). Назовите её отглагольным существительным от исходного глагола.
Дуга исключительности показывает, что экземпляр участвует только в одной из нескольких связей.

Модели классов UML#

В нотации классов, которую использует книга BCS, прямоугольник класса делится на три секции: имя, атрибуты и операции. На ассоциациях указывают кратность (multiplicity) числами или диапазонами (1, *, 0..1). Класс-ассоциация хранит данные о самой связи. Обобщение позволяет специализированным классам наследовать общие атрибуты и операции от общего класса.

Белин добавляет взгляд бизнес-аналитика на два понятия, которые обычно считаются заботой разработчиков:

Агрегация — связь «целое — часть», при которой часть может одновременно принадлежать нескольким целым, например товар, который есть в нескольких каталогах. Смоделируйте её, а затем укажите, какие правила относятся к целому, а какие — к частям.
Полиморфизм — операцию определяют один раз в общем классе; подтип, который выполняет её иначе, получает собственную версию. Тогда в требованиях не нужно писать «если тип X, сделать одно, если тип Y — другое», а новые подтипы потом легко встраиваются в модель.

Когда применять#

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

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

Как это делать#

Найдите кандидатов в сущности среди существительных в требованиях, формах, отчётах и глоссарии.
Нарисуйте связи и запишите каждую двумя предложениями: «Каждый клиент может сделать одно или несколько бронирований. Каждое бронирование должно быть сделано ровно одним клиентом».
Задайте кардинальность и обязательность для обоих концов.
Разрешите связи «многие ко многим» с помощью связующих сущностей и дайте им атрибуты.
Добавьте ключевые атрибуты, затем остальные; определения перенесите в словарь данных.
Ищите обобщения там, где у нескольких сущностей совпадает большая часть атрибутов.
Проверьте модель, читая предложения вслух с экспертами бизнеса и прогоняя через модель реальные примеры.
Передайте логическую модель проектировщикам; продолжайте участвовать, если физические решения затрагивают бизнес-правила.

Пример#

«Мастерская» (вымышленная сеть веломастерских) моделирует данные о бронированиях и ремонтах:

Рис. 1. Логическая модель данных для бронирований и ремонтов. Сущность «Использование запчасти» разрешает связь «многие ко многим» между ремонтными заказами и запчастями. Нотация: диаграмма «сущность — связь», кардинальность в нотации «воронья лапка»

Показать текстом

Клиент           1 ---- 0..*  Бронирование     каждый клиент может сделать много бронирований
Мастерская       1 ---- 0..*  Бронирование     каждое бронирование относится ровно к одной мастерской
Бронирование     1 ---- 0..1  Ремонтный заказ  бронирование может стать одним ремонтным заказом
Механик          1 ---- 0..*  Ремонтный заказ
Ремонтный заказ  1 ---- 1..*  Использование запчасти  0..* ---- 1  Запчасть
Поставщик        1 ---- 0..*  Запчасть

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

Для велосипедов общий класс «Велосипед» (номер рамы, марка, владелец) имеет специализацию «Электровелосипед» с типом батареи. Операция оценить время ремонта определена один раз в классе «Велосипед»; у электровелосипеда своя версия, потому что проверка батареи добавляет время. Требование остаётся одним предложением, а не списком случаев.

Частые ошибки#

Слишком раннее проектирование таблиц → оставайтесь на концептуальном или логическом уровне, пока структура бизнеса не согласована.
Названия сущностей во множественном числе или расплывчатые («Данные», «Записи») → используйте существительные бизнеса в единственном числе.
Повторяющиеся группы внутри сущности (название поставщика у каждой запчасти) → выделите отдельную сущность и свяжите с ней.
Не указана обязательность → решите «должен» или «может» для каждого конца: здесь прячется много бизнес-правил.
Неразрешённые связи «многие ко многим» → добавьте связующую сущность и спросите, что нужно знать о самой связи.
Показано только текущее состояние → спросите, важна ли история (смены статуса, изменения цен).
Нет проверки со стороны бизнеса → читайте связи вслух: эксперты могут проверить предложения, даже если не умеют читать нотацию.

Чек-лист#

У сущностей есть определения и названия — существительные бизнеса в единственном числе.
Каждая связь правильно читается в обоих направлениях.
Кардинальность и обязательность заданы на обоих концах.
Связи «многие ко многим» разрешены через связующие сущности.
Ключевые атрибуты определены; подробности — в словаре данных.
Обобщения применены там, где у подтипов большая часть атрибутов общая.
Эксперты бизнеса проверили модель на реальных примерах.

Источники и что почитать#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Техника 10.15 «Моделирование данных».
D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010. Гл. 11 (ER-диаграммы и модели классов).
А. Белин. Бизнес-анализ. Этап начала проекта (тренинг «UML для IT бизнес-аналитиков»), слайды. Luxoft, 2005 (агрегация и полиморфизм с точки зрения аналитика).
Учебные материалы по бизнес-анализу (модуль «Анализ требований и определение дизайна»).