Спецификация БД сервиса — артефакт системного аналитика, который фиксирует как сервис хранит и интерпретирует данные: логическую и физическую модель, ограничения, жизненный цикл записей, объёмы, политики доступа и миграции. Документ не заменяет BRD/SRS — он детализирует persistence в объёме, достаточном для реализации, ревью и согласования с API, NFR и ADR. Теория моделирования данных — в 03.03.01 ER-диаграммы (сущность-связь) и 03.03.02 Логическая и физическая модель данных.

1. Назначение

Спецификацию БД пишет системный аналитик (или аналитик с поддержкой DBA/архитектора); её читают разработка backend, DBA, QA, security и интеграционные команды. Для QA в спеке фиксируются сущности, статусы и идентификаторы, которые должны попасть в test data (§3.14) — иначе сценарии из stories не воспроизводятся на стенде.

Шаблон закрывает четыре задачи:

  • Контракт persistence — сущности, атрибуты, связи, ограничения и индексы конкретного сервиса; одна спека = одна граница владения данными (bounded context), а не «единая БД на всё».
  • Семантика полей — словарь данных (data dictionary) с типом, обязательностью, PII и бизнес-смыслом; без него dev, QA и интеграции интерпретируют колонки по-разному.
  • Мост к контрактам — явный mapping API ↔ БД (канон — §3.6) и event payload ↔ таблицы/outbox; расхождения именования и nullable не остаются «на усмотрение разработчика».
  • Точка трассировки — идентификатор спеки DB-SPEC-{контекст}-v{N} → FR/SRS → user story → API spec → migration → test data; схема имён — 10.01.15 Шаблон матрицы трассировки. Изменения схемы проходят через change control (02.05.02 Управление изменениями (Change Control Board)) вместе с downstream-артефактами.

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

2. Когда использовать

Подходит, если:

  • проектируете или меняете persistence нового или существующего сервиса (CRUD, workflow, event sourcing, outbox);
  • в том же релизе меняются API (10.01.04 Шаблон спецификации REST API), события (10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ)) или экраны — и нужна согласованная модель данных;
  • требуется ревью с DBA (индексы, партиции, блокировки) или security (PII, шифрование, retention);
  • домен регламентирован: аудит, soft delete, версионирование записей, compliance;
  • миграция legacy или декомпозиция монолита — нужно явно описать границу «эта БД / не эта БД».

Не подходит или требует дополнения, если:

  • нужна enterprise data architecture целиком (master data, DWH, enterprise bus) — спека покрывает только persistence данного сервиса;
  • схема полностью генерируется из ORM без бизнес-семантики — добавьте data dictionary и правила жизненного цикла, иначе спека бесполезна на ревью;
  • NoSQL/document store — используйте подраздел §3.5.1 (коллекция, ключ документа, JSON-schema, индексы, версия схемы); «схемы нет» не освобождает от контракта;
  • event sourcing — используйте §3.5.2 (write model, event store, snapshots); классическая PDM одной таблицы на агрегат недостаточна;
  • выбор СУБД, sharding, CQRS, read replicas — решение в 10.01.13 Шаблон архитектурного решения (ADR); в спеке — следствия для write-side и read-side (§3.2, §3.5);
  • latency, backup, GDPR, классификация данных — полный текст в 10.01.12 Шаблон нефункциональных требований (NFR); в спеке — ссылки и поля, которых это касается.

Входные условия: границы сервиса согласованы (03.01.03 Декомпозиция системы на подсистемы и модули), сущности домена названы единообразно (10.01.14 Шаблон глоссария и словаря данных), функциональные требования и сценарии (UC/story) описывают операции чтения/записи.

3. Структура документа

Скопируйте блок в Confluence, Git (DDL + markdown) или RM-инструмент. Поля с пометкой обяз. нужны для sign-off; да* — обязательно при выполнении условия в скобках; остальные — по контексту. Логическая модель (LDM) и физическая (PDM) могут быть в одном документе или в связанных файлах с общим ID.

Минимальный срез (MVP) — для простого CRUD без PII, событий и сложного lifecycle достаточно §3.1, §3.2, §3.4, §3.5 (базовые строки), §3.6, §3.11, §3.15. Остальные разделы — «не применимо» или по мере появления требований. Не заполняйте все 15 подразделов «для галочки».

УровеньРазделыТипичный контекст
MVP3.1, 3.2, 3.4, 3.5, 3.6, 3.11, 3.15CRUD, нет PII, нет async
StandardMVP + 3.7, 3.8, 3.9, 3.10Workflow, PII, индексы под нагрузку
Fullвсе, включая 3.12 и 3.5.2 при event sourcingEvents, integrations, compliance

3.1. Метаданные

ПолеОбяз.Что писать
IDдаУникальный идентификатор по схеме DB-SPEC-{контекст}-v{N}, напр. DB-SPEC-LEAVE-v2. Тот же ID — в матрице трассировки, migration scripts и test data — 10.01.15 Шаблон матрицы трассировки.
Сервис / bounded contextдаИмя сервиса, владелец (data owner), команда.
Schema / database nameда*Имя схемы или БД в целевой СУБД. *Если СУБД ещё не выбрана — «TBD» + ссылка на ADR; статус Approved допустим только с открытым action в ADR на выбор СУБД. Пока schema = TBD, поля PDM с типами конкретной СУБД остаются в Draft/Review — не маскируйте неопределённость статусом Approved.
Версия, статус, датадаDraft → Review → Approved; автор последнего изменения.
СУБД и окружениядаPostgreSQL 15, dev/stage/prod; отличия между окружениями, если есть.
Upstream: BRD / SRS / ADRдаSRS-REQ-xxx, ADR-042 (выбор СУБД, outbox, idempotency).
Связанные спекидаREST/SOAP API ID, Producer/Consumer ID, NFR ID — ссылки, не дублирование.

3.2. Scope и контекст

ПолеОбяз.Что писать
Scope (внутри)даКакие сущности и операции persistence покрывает этот сервис; при CQRS — write-side и read-side (проекции, materialized views) внутри этого сервиса или явно «read models — см. ADR-xxx».
Excluded scopeдаЧто не в этой БД: данные других сервисов, справочники-референсы, DWH. Read-БД другого сервиса или BI-реплика — excluded: контракт через API/events, не «наша schema». При legacy shared DB — anti-pattern: «мы читаем чужие таблицы» → excluded + план миграции на контракты.
Зависимости от внешних данныхнетСправочники, read-only реплики, cache; откуда берётся, как обновляется, что при устаревшем значении.
Service DB boundaryдаПравило: «другие сервисы не имеют FK/direct SQL к нашим таблицам»; доступ только через API/events.

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

ПолеОбяз.Что писать
ER-диаграмма / UMLдаКлючевые сущности и связи; достаточно для обсуждения с бизнесом.
Глоссарий терминовдаСсылка на 10.01.14 Шаблон глоссария и словаря данных или встроенная таблица: термин → сущность/атрибут.

3.4. Логическая модель (LDM)

ПолеОбяз.Что писать
СущностидаИмя, описание, бизнес-идентификатор (natural key) vs surrogate key.
АтрибутыдаИмя, тип на уровне домена (строка, деньги, enum), обязательность, семантика.
Связи и кардинальностьда1:1, 1:N, M:N; для M:N — промежуточная сущность.
Бизнес-правила на уровне LDMдаИнварианты без привязки к СУБД: «у сотрудника не более одной активной заявки того же типа на пересекающийся период».
Temporal / effective datingнетЕсли домен требует версионность по времени — valid_from / valid_to, правило перекрытия периодов.

Пример логической схемы сервиса отпусков. Сотрудник ссылается на руководителя той же таблицей. Заявка обязана иметь тип и автора. Согласование — отдельная запись: одну заявку могут вернуть и согласовать повторно. Остаток дней — на пару «сотрудник, тип, год», а не поле в заявке.

employee.id — employee.manager_idemployee.id — leave_balance.employee_idleave_type.id — leave_balance.leave_type_idemployee.id — leave_request.employee_idleave_type.id — leave_request.leave_type_idleave_request.id — approval.leave_request_idemployee.id — approval.approver_id
employee
  • iduuidPK
  • emailvarcharUK NN
  • full_namevarcharNN
  • manager_iduuid
leave_type
  • iduuidPK
  • codevarcharUK NN
  • titlevarcharNN
leave_balance
  • iduuidPK
  • employee_iduuidNN
  • leave_type_iduuidNN
  • yearintNN
  • days_remainingdecimalNN
leave_request
  • iduuidPK
  • employee_iduuidNN
  • leave_type_iduuidNN
  • start_datedateNN
  • end_datedateNN
  • statusvarcharNN
approval
  • iduuidPK
  • leave_request_iduuidNN
  • approver_iduuidNN
  • decisionvarcharNN
  • decided_atdatetime

Правило «не больше одной активной заявки того же типа на пересекающиеся даты» на линиях не рисуется: это ограничение в тексте LDM и в CHECK или в сервисе, не кардинальность 1:1.

3.5. Физическая модель (PDM)

ПолеОбяз.Что писать
ОбъектыдаТаблица/коллекция, колонки, типы СУБД, PK, FK, UNIQUE, CHECK.
Naming conventionдаsnake_case в БД ↔ camelCase в API; enum в БД — UPPER_SNAKE, в API — camelCase. Полная таблица mapping — §3.6.
PK и стратегия IDдаUUID v7 / serial / snowflake; обоснование для интеграций и sharding.
FK и delete/update behaviorдаRESTRICT / CASCADE / SET NULL для каждой связи внутри сервиса.
External references (без FK)да*ID из внешнего домена (IAM, MDM): тип, допустимые значения, валидация при записи, поведение при «битой» ссылке. *Если есть поля-ссылки на чужие bounded context.
ИндексыдаСостав, тип; обоснование под сценарии из API/use case (фильтр, сортировка, join), не «на всякий случай».
Read models / projectionsнетТаблицы read-side при CQRS этого сервиса: источник, частота обновления, допустимый lag; детали архитектуры — в ADR.
Партиционирование / shardingнетКритерий партиции, если объёмы или NFR это требуют.
Multi-tenancyнетtenant_id, RLS-политика, изоляция данных — для B2B SaaS.

3.5.1. Document store (NoSQL) — альтернатива табличной PDM

Заполняйте вместо строк таблицы §3.5, если СУБД — document/key-value store:

ПолеОбяз.Что писать
Коллекция / bucketдаИмя, назначение, владелец.
Ключ документада_id, составной ключ, shard key.
JSON-schema / обязательные полядаВерсия схемы, required, типы, вложенность, max depth.
ИндексыдаПоля индекса, partial/filtered — с привязкой к API-сценариям.
Эволюция документовдаBackward-compatible изменения, миграция старых документов, default для отсутствующих полей.

3.5.2. Event sourcing — альтернатива классической PDM

Заполняйте вместе с базовыми строками §3.5 или вместо «одна таблица = агрегат», если persistence построена на event store:

ПолеОбяз.Что писать
Write modelдаТаблицы command-side: текущее состояние агрегата, версия, optimistic lock; что не дублируется из event log.
Event storeдаТаблица/топик событий: aggregate_id, sequence, event_type, payload schema version, timestamp; append-only, уникальность (aggregate_id, sequence).
SnapshotsнетПериодичность, формат, когда пересчитывать aggregate без replay всей истории.
Projections / read modelsнетТаблицы, строящиеся из event stream: источник, lag, идempotency при replay.
Upcasting / schema migrationнетКак мигрировать старые версии payload в event log.

3.6. Data dictionary (обязательный блок)

Теория метаданных и словаря данных — 03.03.03 Словарь данных (описание); канон имён и enterprise-глоссарий — 10.01.14 Шаблон глоссария и словаря данных. В DB-spec — service-level projection: поля, которые реально есть в схеме этого сервиса, с PII и канонической таблицей mapping API ↔ БД. Не дублируйте второй enterprise glossary и не заводите вторую mapping-таблицу в §3.12.

ПолеОбяз.Что писать
Таблица полейдаНа каждое поле: имя (LDM + PDM), описание, тип, длина/precision, nullable, default, enum/справочник, PII/чувствительность, data owner, пример значения.
Источник данныхнетПоле заполняется пользователем, приходит из API, из события, вычисляется, snapshot из MDM.
Справочник / MDM-копиянетДля кодов из внешнего справочника: храним только ID или denormalized snapshot; политика refresh — детали в §3.2; здесь — только impact на поля.
Маппинг API ↔ БД (канон)да*Единственная полная таблица: колонка PDM ↔ JSON-поле REST/SOAP; расхождения nullable, enum casing и имён — явно. §3.12 ссылается сюда, не дублирует. *Если API в том же релизе.

3.7. Ограничения и бизнес-правила

ПолеОбяз.Что писать
Integrity constraintsдаUNIQUE, CHECK, FK; cross-field rules.
Conditional uniquenessда*Инварианты с условием (partial unique): формулировка на LDM, где enforce — partial index в БД vs проверка в коде. *Если natural key или dedup с фильтром по статусу.
Enforcement levelдаЧто enforced в БД vs в коде приложения — с обоснованием (производительность, гибкость, legacy).
Idempotency storageнетТаблица/ключ для идempotent POST (связь с 10.01.04 Шаблон спецификации REST API): TTL, unique constraint, cleanup.
Ссылки на BRнетBR-047 из SRS/UC; правило не дублировать текстом SRS целиком.

3.8. Жизненный цикл и аудит

ПолеОбяз.Что писать
Состояния записида*Enum статусов и граф допустимых переходов (таблица from → to или state diagram); CHECK на enum не заменяет контроль переходов. *Обязательно, если у сущности есть поле status/state; иначе «не применимо». При ≥3 статусах и ветвлении — state machine обязателен (03.02.04 Диаграмма состояний (State Machine Diagram)).
Создание / изменение / удалениедаHard vs soft delete; правила выборок («по умолчанию deleted_at IS NULL»); erasure vs retention для PII.
Аудитдаcreated_at, updated_at, updated_by, version; что пишется в audit log vs в основную таблицу.
ВерсионированиенетOptimistic locking, history table — если требуется.

3.9. Объёмы и нагрузка

ПолеОбяз.Что писать
Начальный объём и ростдаСтрок на сущность, прогноз на 12–24 мес.
Hot pathsдаЧастые операции чтения/записи из API/UC; основа для индексов и партиций.
SLA на запросынетСсылка на NFR (p95 latency); не дублировать полный NFR-документ.

3.10. Безопасность и compliance

ПолеОбяз.Что писать
Классификация данныхдаPublic / internal / confidential / PII; пометка в data dictionary.
ШифрованиенетAt rest / in transit; маскирование в логах и репликах.
Retention и purgeда*Срок хранения, job архивации/удаления; право на erasure vs retention. *Если есть PII или регуляторика — см. также 08.06 Юридические и регуляторные требования РФ (PCI-DSS).
Row-level securityнетЕсли применимо — правило, tenant_id и роли (10.01.11 Шаблон ролевой модели).

3.11. Миграции и версионирование схемы

ПолеОбяз.Что писать
ИнструментдаFlyway / Liquibase / ручные скрипты; каталог миграций в репозитории (07.05 Системы контроля версий (Git) для документации).
Стратегия rolloutдаПорядок деплоя: expand → migrate data → contract; breaking vs non-breaking; связка с CI/CD (07.06 CICD и конвейеры — влияние на требования). Изменения breaking-схемы — через change control (02.05.02 Управление изменениями (Change Control Board)).
Обратная совместимостьдаСовместимость с текущими версиями API и consumers на период rolling deploy.
RollbackдаЧто откатывается автоматически, что требует runbook.

3.12. Интеграционные точки

Summary-раздел: детали mapping API — только в §3.6; детали refresh внешних данных — в §3.2.

ПолеОбяз.Что писать
Mapping API ↔ БДда*Ссылка на таблицу §3.6 + при необходимости: aggregate root ↔ endpoint group, nested DTO vs flat table. *Если API в том же релизе.
Event ↔ таблицы / outboxнетPayload события, outbox table, idempotency keys; полный контракт producer — 10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ).
Consumer ↔ таблицы (inbox/dedup)нетInbox, processed, dedup keys при записи из событий; idempotency и порядок обработки — 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ).
Batch / ETLнетЕсли сервис отдаёт или принимает bulk — ссылка на 10.01.10 Шаблон описания Airflow-триггеров и автоматических процессов.
Источник истиныда*Summary: БД vs event log при event-driven; eventual consistency. Детали refresh MDM/справочников — §3.2. *Если есть асинхронные интеграции или реплики MDM.

3.13. Открытые вопросы, допущения, история

ПолеОбяз.Что писать
Assumptionsнет«Справочник отделов реплицируется nightly из MDM».
Открытые вопросынетНерешённое до Approved (напр. «нужен ли partial index по status»).
История измененийдаВерсия, дата, автор, impact на API/migrations.

3.14. Приложения

ПолеОбяз.Что писать
DDL-черновикнетSQL или dbdiagram; не заменяет data dictionary.
Sample queriesнет2–5 запросов под ключевые use case / API endpoints.
Ожидания для test data (QA)нетКакие сущности, статусы и ID обязаны быть в fixtures для сценариев из stories; ссылки TD-* в 10.01.15 Шаблон матрицы трассировки.
Диаграмманетdbdiagram, Mermaid ER, экспорт из 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io).

3.15. Чеклист качества перед sign-off

Рецензирование артефакта — 08.04 Рецензирование и инспекции (техники Фейгана). Перед передачей в разработку сверьтесь также с 10.04 Чеклист аналитика перед стартом разработки.

  • У каждой сущности есть PK, стратегия ID и natural key (если есть).
  • Data dictionary заполнен для всех колонок, PII помечены; канон имён согласован с 10.01.14 Шаблон глоссария и словаря данных.
  • Индексы привязаны к сценариям из API/UC, а не «на всякий случай».
  • Nullable обоснован; нет «nullable на всякий случай» без правила агрегации в API.
  • External references без FK задокументированы: валидация и поведение при нарушении ссылочности.
  • Conditional uniqueness: условие на LDM и место enforce (partial index vs код) согласованы.
  • Lifecycle: граф переходов статусов зафиксирован; enum-only без state machine — осознанное решение.
  • Soft delete с правилами выборок задокументирован.
  • FK не выходят за границу сервиса (нет coupling между микросервисами через БД).
  • Mapping API ↔ БД — одна таблица в §3.6, согласована с 10.01.04 Шаблон спецификации REST API в том же релизе.
  • Retention, purge и erasure для персональных данных указаны или явно «не применимо».
  • Миграции: breaking/non-breaking, rollback, совместимость с API.
  • Трассировка DB-SPEC-* → SRS/stories → migration → test data заполнена.

4. Пример заполнения

Сокращённый фрагмент для сервиса leave-service (HR Portal, данные условны).

Метаданные: DB-SPEC-LEAVE-v2 · leave-service · schema leave · PostgreSQL 15 · Approved · v2.1, 2026-03-15 · Upstream: SRS-REQ-038, SRS-REQ-039, ADR-042 (outbox) · API: API-LEAVE-001, API-LEAVE-003 · Producer: PROD-LEAVE-001 · NFR: NFR-AUDIT-003, NFR-DATA-007

Scope. Хранение заявок на отпуск, истории статусов, outbox для событий. Excluded: баланс отпусков (сервис balance-service), полный справочник типов отпуска (MDM), read-replica для BI. Boundary: прямой доступ к schema leave только у leave-service.

LDM (фрагмент). Сущность Заявка на отпуск (LeaveRequest): идентификатор, сотрудник (employee_id, external ref IAM), руководитель согласования (manager_id, external ref IAM), тип отпуска (код из MDM), период, статус, комментарий. Связь 1:N с Историей статуса (LeaveRequestStatusHistory). Natural key для dedup: (employee_id, leave_type_code, start_date, end_date) где status ∉ {CANCELLED, REJECTED} — conditional uniqueness.

PDM (фрагмент).

ТаблицаНазначение
leave_requestОсновная заявка
leave_request_status_historyАудит переходов статусов
outbox_eventTransactional outbox (ADR-042)

PK: leave_request.id — UUID v7. FK: status_history.request_id → leave_request.id ON DELETE RESTRICT. External ref (без FK): employee_id, manager_id → IAM; валидация через IAM API при submit; при 404 — отклонение заявки.

Conditional uniqueness: partial unique index uq_leave_request_active ON (employee_id, leave_type_code, start_date, end_date) WHERE status NOT IN ('CANCELLED', 'REJECTED') AND deleted_at IS NULL.

Индексы:

  • idx_leave_request_employee_status ON (employee_id, status) WHERE deleted_at IS NULL — список заявок сотрудника (GET /leave-requests, API-LEAVE-001).
  • idx_leave_request_manager_queue ON (manager_id, status) WHERE status = 'PENDING_APPROVAL' — очередь руководителя (API-LEAVE-003).

Data dictionary (фрагмент, канон mapping — §3.6):

Поле (PDM)API (camelCase)ТипNullablePIIОписание
employee_idemployeeIdUUIDнетдаExternal ref IAM; без FK
manager_idmanagerIdUUIDнетдаРуководитель на момент submit; из IAM org-tree
leave_type_codeleaveTypeCodevarchar(32)нетнетSnapshot кода из MDM; refresh при submit
statusstatusenumнетнетБД: DRAFT, PENDING_APPROVAL, APPROVED, REJECTED, CANCELLED; API: draft, pendingApproval, …
deleted_at—timestamptzданетSoft delete; не отдаётся в API

Жизненный цикл. Soft delete: deleted_at + deleted_by. Все SELECT по умолчанию с deleted_at IS NULL. CHECK — только допустимые значения enum; переходы — в доменном сервисе.

Граф переходов (leave_request.status):

FromToУсловие / действие
—DRAFTсоздание заявки
DRAFTPENDING_APPROVALsubmit сотрудником
DRAFTCANCELLEDотмена автором
PENDING_APPROVALAPPROVEDapprove руководителем
PENDING_APPROVALREJECTEDreject руководителем
PENDING_APPROVALCANCELLEDотмена до решения

Объёмы. ~50 000 заявок/год, рост 10%/год; hot path — выборка очереди руководителя и списка по employee_id.

Retention. PII в leave_request — 5 лет после увольнения (NFR-DATA-007); purge job ежемесячно; erasure по запросу — anonymize employee_id/manager_id.

Миграции. V2_1__add_manager_id_index.sql — non-breaking, expand-only; деплой до API v1.3.

Event mapping (§3.12 summary). После INSERT/UPDATE статуса → запись в outbox_event (event_type=leave.request.submitted, payload JSON по PROD-LEAVE-001); idempotency key = request_id + status + updated_at. Mapping API ↔ БД — таблица выше, §3.12 не дублирует.

Test data (§3.14). TD-LEAVE-001: заявка в PENDING_APPROVAL для сценария approve; TD-LEAVE-002: две заявки одного сотрудника для проверки conditional uniqueness.

Трассировка: US-0238, US-0247 → DB-SPEC-LEAVE-v2 → test data TD-LEAVE-* → migration V2_1.

5. Связанные артефакты

На входе (upstream)

АртефактСвязь
Vision & Scope, BRD, SRSЧто хранить и зачем — сущности домена, отчётность, регуляторика — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)
10.01.01 Шаблон User Story / 10.01.02 Шаблон Use CaseОперации чтения/записи, postconditions, статусы
10.01.14 Шаблон глоссария и словаря данныхКанонические имена сущностей и атрибутов
10.01.13 Шаблон архитектурного решения (ADR)Выбор СУБД, outbox, CQRS, sharding, event sourcing
10.01.11 Шаблон ролевой моделиRow-level доступ, audit updated_by
ER-диаграмма / LDM (черновик)03.03.01 ER-диаграммы (сущность-связь)

На выходе (downstream)

АртефактКогда создавать
10.01.04 Шаблон спецификации REST API / 10.01.05 Шаблон спецификации SOAP APIDTO и поля согласованы с data dictionary; mapping — §3.6
10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ) / 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ)Outbox, payload, idempotency keys; inbox/dedup tables у consumer
10.01.12 Шаблон нефункциональных требований (NFR)Retention, backup, RPO/RTO, latency — по ссылке из спеки
DDL и migration scriptsРеализация PDM; версии синхронны со спекой
Test data / fixturesQA по сценариям из stories и API; поле §3.14 + матрица
10.01.15 Шаблон матрицы трассировкиFR/story → DB-SPEC-* → migration → test

Типичный порядок работы аналитика

  1. Выделить сущности из SRS/UC и глоссария → концептуальная ER.
  2. Согласовать LDM с бизнесом (правила, lifecycle, natural keys, conditional uniqueness).
  3. Детализировать PDM с DBA: типы, индексы под API-сценарии, FK внутри сервиса, external ref без FK; при event sourcing — §3.5.2.
  4. Заполнить data dictionary и mapping API ↔ БД в §3.6 параллельно с API-спекой (или reverse impact, если API уже зафиксирован раньше).
  5. Review с dev, DBA, security (08.04 Рецензирование и инспекции (техники Фейгана)); зафиксировать миграции и трассировку.
  6. При изменении API или BR — impact analysis на схему (02.05.02 Управление изменениями (Change Control Board) при формальном CCB; не путать с 02.05.02 Управление приоритетами в условиях изменчивости — другая заметка).

6. Связи с другими разделами базы

7. Источники и дополнительные материалы

Ссылки приведены на момент публикации; при переносе в рабочий контур перепроверьте актуальность.

Книги и стандарты

Статьи и практики

Спецификации и инструменты