Капстоун: бизнес-кейс и conceptual model

Вы прошли весь курс: ER-моделирование, реляционную модель, ключи, нормализацию, OLTP, размерное моделирование, SCD, Data Vault, современные подходы, NoSQL. Каждый модуль давал отдельный инструмент. Капстоун соединяет их в одно: мы пройдём сквозной проект — от текста требований заказчика до готового хранилища с витринами. Один и тот же бизнес-кейс будет с нами все пять уроков модуля.

Этот первый урок — про самое начало, которое новички склонны проскакивать: разбор бизнес-кейса, сбор требований и conceptual model. Соблазн сразу писать CREATE TABLE велик. Но модель, начатая с DDL, почти всегда оказывается моделью «как удобно СУБД», а не «как устроен бизнес». Правильный путь начинается с понимания предметной области.

Бизнес-кейс: городской прокат велосипедов

Вот текст, который мы условно получили от заказчика. Читайте внимательно — это сырьё для всей работы.

Городская сеть проката велосипедов. У сети несколько станций по городу. На каждой станции есть велосипеды; велосипед закреплён за «домашней» станцией, но может быть возвращён на любую. Клиент регистрируется один раз, указывает имя, email и телефон. Клиент берёт велосипед на станции (старт аренды) и возвращает на станции (конец аренды) — это одна аренда. За каждую аренду клиент платит; оплата может пройти сразу или позже, бывают и неоплаченные аренды. Тариф зависит от типа велосипеда (обычный или электро). Нам важно знать историю всех аренд и платежей; нужны отчёты по выручке, загрузке станций и поведению клиентов.

Текст короткий, но в нём спрятана вся модель. Задача аналитика-моделировщика — извлечь из прозы структуру. Делается это в три приёма: найти сущности, найти связи, найти атрибуты и правила.

Шаг 1: находим сущности

Сущность (из модуля про ER-моделирование) — объект, о котором бизнес хранит данные. Простой приём извлечения: выписать существительные из текста и отобрать те, что обозначают «вещи, о которых нужны данные».

Существительные в тексте: сеть, станция, велосипед, клиент, имя, email, телефон, аренда, оплата, тариф, тип велосипеда, отчёт, выручка.

Не каждое существительное — сущность. Отсеиваем:

Имя, email, телефон — это не сущности, а атрибуты клиента (свойства, а не самостоятельные объекты).
Отчёт, выручка — это то, что мы хотим получить НА ВЫХОДЕ, а не то, что моделируем как сущность.
Сеть — она одна, моделировать её как сущность с одной строкой смысла нет (это контекст, а не данные).
Тариф, тип велосипеда — пограничный случай; пока пометим как кандидатов, решим позже.

Остаются твёрдые сущности: Станция (Station), Велосипед (Bike), Клиент (Customer), Аренда (Rental), Платёж (Payment).

TIP

Различение «сущность или атрибут» — частая трудность. Ориентир: если у объекта есть собственные свойства и собственная жизнь (его создают, меняют, удаляют независимо) — это сущность. Если объект — просто характеристика другого объекта — это атрибут. Email сам по себе ничего не «делает», он принадлежит клиенту -> атрибут. Аренда имеет дату, статус, сумму, происходит независимо -> сущность.

От ER-диаграммы к SQL — как conceptual model проката превращается в DDL

Шаг 2: находим связи

Связь — отношение между сущностями. Приём извлечения: искать в тексте глаголы, соединяющие сущности.

Перечитываем кейс с этим фокусом:

«на станции есть велосипеды» -> Станция содержит Велосипеды.
«велосипед закреплён за домашней станцией» -> Велосипед имеет домашнюю Станцию.
«клиент берёт велосипед» и «возвращает на станции» -> Клиент совершает Аренду; Аренда связана со Станцией старта и Станцией конца.
«за каждую аренду клиент платит» -> Аренда оплачивается Платежом.

Для каждой связи определяем кардинальность (из модуля про связи). Это критический шаг — кардинальность задаётся текстом, и её надо вычитать точно:

Станция и Велосипед (домашняя): одна станция — много велосипедов, велосипед закреплён за одной. Это 1:N.
Клиент и Аренда: один клиент — много аренд, аренда у одного клиента. 1:N.
Велосипед и Аренда: один велосипед участвует во многих арендах (в разное время), аренда — это один велосипед. 1:N.
Аренда и Платёж: «оплата может пройти сразу или позже, бывают неоплаченные». Значит, у аренды 0 или 1 платёж. 1:1 (точнее, 1:0..1 — связь опциональная).
Аренда и Станция: у аренды две связи со станцией — старт и конец. Это role-playing: одна сущность Станция в двух ролях.

Шаг 3: строим conceptual model

Теперь собираем найденное в conceptual model — концептуальную модель. Вспомните из первого модуля: конкретно эта модель показывает бизнес-сущности и связи между ними без атрибутов, без типов данных, без ключей. Её аудитория — бизнес; её задача — проверить, что мы правильно поняли предметную область, до того как тратить силы на детали.

Почему именно так, без деталей? Потому что conceptual model — это точка согласования с заказчиком. Заказчик не станет читать DDL, но взглянув на схему «Клиент — Аренда — Велосипед — Станция», он скажет «да, всё так» или «нет, велосипед может быть в нескольких арендах одновременно — это шеринг». Ошибку понимания дёшево исправить здесь, на схеме из пяти прямоугольников, и очень дорого — в готовом хранилище.

Conceptual model: проката велосипедов

Клиент

совершает (1:N)

Аренда

оплачивается (1:0..1)

Платёж

аренда использует велосипед (1:N)

Велосипед

закреплён за / стартует и финиширует на

Станция

Обратите внимание: на conceptual model нет ни одного типа данных, ни одного ключа. Только пять сущностей и связи с кардинальностью. Это намеренно — детали добавятся на следующих шагах.

Шаг 4: фиксируем требования и бизнес-правила

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

Бизнес-правила (ограничения предметной области):

Правило	Откуда в тексте
Велосипед закреплён ровно за одной домашней станцией	«закреплён за домашней станцией»
Аренда возвращается на любую станцию, не обязательно домашнюю	«может быть возвращён на любую»
У аренды может не быть платежа	«бывают и неоплаченные аренды»
Тариф зависит от типа велосипеда	«тариф зависит от типа велосипеда»
Клиент регистрируется один раз	«регистрируется один раз»

Аналитические требования (что должно отвечать хранилище):

Выручка: по периодам, по типам велосипедов, по станциям.
Загрузка станций: сколько аренд стартует и финиширует на станции.
Поведение клиентов: частота аренд, средний чек, средняя длительность.
Полная история всех аренд и платежей.

Эти два списка — не бюрократия. Бизнес-правила определят constraints в OLTP-схеме (урок 2). Аналитические требования определят, какие будут fact- и dimension-таблицы (урок 3) — вспомните четырёхшаговый процесс Kimball: он начинается с бизнес-процесса, а бизнес-процессы здесь прямо в требованиях.

Путь от требований к хранилищу: план капстоуна

Урок 1: требования и conceptual model

Урок 2: OLTP-схема (3NF/BCNF)

Урок 3: star schema

Урок 4: SCD2 и date dimension

Урок 5: анти-паттерны, документация, защита

Почему нельзя пропускать этот этап

Соблазн начать с CREATE TABLE мы упомянули в начале — теперь объясним цену пропуска conceptual-этапа конкретно.

Если начать с DDL, вы примете десятки решений (типы, ключи, нормализация) до того, как поняли предметную область. И если понимание окажется неверным — например, вы не заметили, что велосипед бывает в нескольких арендах сразу, или что аренда может быть без платежа, — переделывать придётся уже наполненное хранилище: миграции, переписанный ETL, потерянные данные. На conceptual model та же ошибка — это исправленная стрелка на схеме.

Conceptual model дёшева в создании и в исправлении именно потому, что в ней нет деталей. Это её роль в процессе: быстро и наглядно зафиксировать понимание бизнеса и согласовать его с заказчиком, прежде чем детали сделают модель дорогой для изменений. Следующий урок берёт эту conceptual model и превращает её в полноценную OLTP-схему с ключами, типами и нормализацией до 3NF/BCNF.

Попробуй сам

Возьмите соседний бизнес-кейс — онлайн-библиотека: «Библиотека выдаёт книги читателям. У книги есть автор и жанр. Один экземпляр книги выдаётся одному читателю на срок; читатель может держать несколько книг. За просрочку начисляется штраф. Нужны отчёты по популярности книг и должникам».

Выпишите все существительные и отберите сущности. Отделите атрибуты и «то, что на выходе».
Найдите глаголы-связи между сущностями и для каждой связи определите кардинальность по тексту.
Нарисуйте conceptual model: только сущности и связи с кардинальностью, без атрибутов и ключей.
Составьте два списка: бизнес-правила и аналитические требования. Отметьте, какое правило откуда в тексте.

В следующем уроке мы вернёмся к прокату велосипедов и спроектируем для него нормализованную OLTP-схему.

Проверка знанийKnowledge check

Зачем начинать проектирование с разбора требований и conceptual model, а не с CREATE TABLE, и как извлечь сущности и связи из текста бизнес-кейса?

ОтветAnswer

Начинать с conceptual model нужно потому, что модель, начатая с DDL, оказывается моделью "как удобно СУБД", а не "как устроен бизнес": писать CREATE TABLE значит принять десятки решений (типы, ключи, нормализация) до того, как понята предметная область. Если понимание окажется неверным, переделывать придётся уже наполненное хранилище — миграции, переписанный ETL, потерянные данные. Conceptual model дёшева в создании и исправлении, потому что в ней нет деталей: только бизнес-сущности и связи с кардинальностью, без атрибутов, типов и ключей. Её роль — точка согласования с заказчиком: взглянув на схему из нескольких прямоугольников, бизнес подтвердит или поправит понимание, и ошибку дёшево исправить здесь, а не в готовой системе. Сущности из текста извлекают так: выписать существительные и отобрать те, что обозначают объекты с собственными свойствами и собственной жизнью (их создают, меняют, удаляют независимо); отсеять атрибуты (характеристики других объектов, как email клиента), то, что нужно на выходе (отчёты, выручка), и контекст. Связи извлекают через глаголы, соединяющие сущности, и для каждой связи определяют кардинальность (1:1, 1:N, M:N), вычитывая её точно из текста. Параллельно фиксируют два списка требований: бизнес-правила (они станут constraints в OLTP-схеме) и аналитические требования (они определят fact- и dimension-таблицы DWH). Эти артефакты — контракт, по которому потом проверяют готовое хранилище.