В этой заметке — пара артефактов одного семантического контура: словарь данных (Data Dictionary) и бизнес-глоссарий (Business Glossary). Если ER-диаграмма (03.03.01 ER-диаграммы (сущность-связь)) показывает что существует, а 03.03.02 Логическая и физическая модель данных формализует структуру и нормализацию, то словарь отвечает на вопрос «что означает каждый элемент и по каким правилам он живёт». Глоссарий фиксирует бизнес-термины, на которых говорят заказчик и команда. Вместе они закрывают семантический разрыв между требованиями и реализацией — без дублирования ER или LDM.

Словарь данных — реестр метаданных об элементах данных: смысл, формат, допустимые значения, происхождение и правила использования. Глоссарий — согласованный набор бизнес-терминов с определениями, обеспечивающий единое понимание предметной области.

1. Суть темы

Словарь и глоссарий — два артефакта одного семантического контура, но с разной гранулярностью:

АртефактЧто описываетТипичный владелец на проекте
ГлоссарийБизнес-термины («Постоянный клиент», «Расчётный период») — могут не совпадать с одним столбцомбизнес-эксперт / product owner
Словарь данныхЭлементы данных (атрибуты LDM, столбцы PDM, поля API)системный аналитик; физический уровень — DBA / разработчик

Граница с 03.03.02 Логическая и физическая модель данных: там — структура (сущности, ключи, нормализация, LDM → PDM); здесь — семантика, правила и метаданные каждого элемента. Трёхуровневая цепочка CDM → LDM → PDM описана в соседней статье; словарь детализирует атрибуты на каждом уровне, не подменяя диаграммы:

Уровень моделиЧто даёт 03.03.02Что добавляет словарь
Концептуальный (ER)сущности, связи, ключевые атрибутытермины глоссария, маппинг «термин → элемент»
Логический (LDM)таблицы, домены, PK/FK, ограниченияопределения, допустимые значения, источник, владелец, бизнес-правила
Физический (PDM)типы СУБД, индексы, DDLфизические имена, NOT NULL, FK, поля контрактов API
graph LR
    subgraph "Бизнес-контекст"
        A[Бизнес-требования] --> B[Бизнес-глоссарий]
    end

    subgraph "Моделирование данных"
        C[ER-диаграмма / LDM] --> D[Логический словарь данных]
        B -->|маппинг термин → элемент| D
        D --> E[Физический словарь данных]
        E --> F[Схема БД / контракт API]
    end

Граница с BA: выявление терминов начинается на этапе elicitation (02.02.01 Интервьюирование и анкетирование, 02.02.02 Воркшопы, фасилитация и совместные сессии) и фиксируется в спецификациях (02.03.03 Спецификация требований (SRS, Use Case, User Story)); ведение словаря как технического артефакта — зона системного анализа в связке с 03.03.02 Логическая и физическая модель данных. Изменения после baseline — через 02.05.02 Управление изменениями (Change Control Board).

Project vs enterprise glossary: на одном продукте достаточно проектного глоссария в Confluence (02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence)) или 10.01.14 Шаблон глоссария и словаря данных. В мультипродуктовой среде термины из корпоративного глоссария могут конфликтовать с локальными определениями — явно помечайте scope («enterprise term» vs «project term») и фиксируйте отступления. Словарь данных на проекте всегда привязан к конкретной системе или сервису.

Изменение термина в глоссарии каскадирует через логический словарь и модель к физической реализации — не напрямую «термин → DDL». При ревью проверяйте цепочку: глоссарий → элемент словаря → атрибут LDM → столбец или поле контракта.

Цели ведения словаря на проекте:

Источник истины при автогенерации: утверждённый словарь и глоссарий — baseline; черновики описаний (в том числе с помощью LLM) — только draft до ревью (08.04 Рецензирование и инспекции (техники Фейгана)). Автогенерация валидации, OpenAPI или DDL допустима из утверждённого словаря, но не наоборот: сгенерированный текст не становится определением без подписи владельца данных.

2. Ключевые понятия

2.1 Логический и физический словарь

Разделение уровней LDM/PDM — в 03.03.02 Логическая и физическая модель данных; в словаре это два набора карточек:

СловарьСодержитКто ведёт
Логическийэлементы без привязки к СУБД: домены, бизнес-правила, ссылки на справочникисистемный аналитик
Физическийстолбцы с типами СУБД, индексы, FK, поля контрактовDBA / разработчик на основе логического

Формы — в 10.01.14 Шаблон глоссария и словаря данных и 10.01.03 Шаблон спецификации БД сервиса.

2.2 Структура карточки элемента

Набор полей зависит от уровня. Не смешивайте логические и физические атрибуты в одной строке без пометки.

Общие для обоих уровней:

  • наименование (логическое и физическое имя);
  • определение;
  • синонимы / альтернативные имена;
  • допустимые значения (перечисление, справочник, диапазон);
  • источник данных;
  • владелец данных;
  • бизнес-правила;
  • связи с другими элементами;
  • ID требования (для трассировки);
  • классификация и чувствительность — уровень данных (public / internal / confidential / PII), признак персональных данных, требования к маскированию и срок хранения; детали compliance — в 08.06 Юридические и регуляторные требования РФ (PCI-DSS) и 08.07 Основы кибербезопасности для системного аналитика, здесь достаточно метки для интеграций и API;
  • примечания и версия.

Только логический уровень:

  • логический домен и формат («Дата ISO 8601», «Деньги, 2 знака»);
  • обязательность в бизнес-смысле, в том числе условная («обязателен после оплаты» — правило, а не NOT NULL).

Только физический уровень:

  • тип СУБД, длина/точность;
  • NOT NULL, FK, CHECK, значение по умолчанию;
  • индексы, триггеры пересчёта.

Минимальное соответствие ISO/IEC 11179-3 (полезно как чеклист, даже без корпоративного Metadata Registry):

Атрибут 11179-3Поле карточки §2.2
definitionопределение
representation (datatype, format)логический домен / тип СУБД, формат
registration statusпримечания и версия (draft / approved / deprecated)
identificationнаименование, ID требования

2.3 Пример логической записи

ПолеЗначение
НаименованиеОбщая сумма заказа
ОпределениеПолная стоимость товаров с учётом скидок, без доставки. Фиксируется при переходе в «Оплачен».
Логический доменДеньги
ФорматДесятичное число, ≥ 0, два знака после запятой
ОбязательностьУсловная: обязательна после оплаты (бизнес-правило; на PDM — отдельно NOT NULL или nullable + проверка статуса)
ИсточникРасчёт: Σ(цена × количество) по позициям
ВладелецФинансовый отдел
КлассификацияInternal
Связанные элементыORDER_ITEM.unit_price, ORDER_ITEM.quantity

2.4 Глоссарная статья

  • Термин — утверждённое название.
  • Определение — однозначное для бизнеса.
  • Синонимы / устаревшие названия.
  • Контекст использования — процессы, модули.
  • Владелец термина — кто уточняет определение.
  • Связанные термины и элементы словаря, на которых термин опирается.

Пример. Термин «Постоянный клиент» — «клиент с ≥ 3 заказами за 12 месяцев». Это не столбец БД, а правило над атрибутами customer_id, датами заказов. Глоссарий хранит определение; словарь — поля, участвующие в расчёте.

2.5 Словарь данных vs каталог данных

КритерийДостаточно таблицы / ConfluenceНужен data catalog
Масштабодин продукт, одна командадесятки систем, enterprise lineage
Задачасогласовать поля фичи и APIсквозной поиск, stewardship, compliance
Интеграцияручные wiki-ссылкиавтоматический harvest метаданных из БД

На типичном проекте SA достаточно 10.01.14 Шаблон глоссария и словаря данных в 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence) или YAML в Git (07.05 Системы контроля версий (Git) для документации). Корпоративные каталоги (Collibra, Alation, Atlan, DataHub) — надстройка над множеством систем; выбор и governance enterprise-инструментов — зона data stewardship, не проектного словаря.

2.6 Элемент словаря vs справочник (reference data)

Элемент словаря описывает поле (status — строка, допустимые значения NEW, PAID, SHIPPED). Справочник — набор записей (countries, order_statuses). В словаре укажите ссылку на справочник и правило: enum в коде, FK на таблицу или внешний MDM. Не дублируйте все строки справочника в карточке поля — достаточно ссылки и владельца справочника.

2.7 Словарь вне таблиц СУБД

В интеграционных проектах «физический словарь» включает не только столбцы, но и поля контрактов: JSON Schema, OpenAPI, Avro/Protobuf в 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf), payload событий (10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ), 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ)). Имена и типы в контракте должны согласовываться с LDM, но view-модели и транспортные поля допустимы — как в 03.03.02 Логическая и физическая модель данных.

3. Как применяется в работе аналитика

3.1 Процесс создания и поддержки

  1. Извлечь термины и атрибуты на встречах (02.02.01 Интервьюирование и анкетирование, 02.02.02 Воркшопы, фасилитация и совместные сессии), из ER, LDM, user stories и спецификаций требований.
  2. Унифицировать имена — договориться о стиле (snake_case для физики, PascalCase для логики — зафиксировать в шаблоне).
  3. Заполнить карточки, привлекая бизнес для допустимых значений и правил.
  4. Ревью с архитектором, разработкой, QA, владельцами данных (08.04 Рецензирование и инспекции (техники Фейгана)).
  5. Утвердить baseline и вести изменения через CCB (02.05.02 Управление изменениями (Change Control Board)).

RACI на gate требований: глоссарий утверждает business owner; логический словарь — аналитик + архитектор; физический — DBA/tech lead. Критерий готовности к разработке — согласованный словарь core-конcepts, не полное покрытие всех служебных полей.

Связь с приёмкой: для каждого критичного элемента словаря зафиксируйте ожидаемое поведение в 02.04.02 Критерии приёмки (Acceptance Criteria) (допустимые значения, граничные случаи, условная обязательность) и набор тестовых данных для статической проверки требований.

3.2 Синхронизация: кто ведёт при изменениях

Словарь производный от модели при проектировании «с нуля» (требования → ER/LDM → словарь), но источник при изменении семантики. Регламент зависит от типа изменения:

СценарийLeading (источник)Following (следует)Порядок
(а) Семантика / правила — меняется определение термина, допустимые значения, бизнес-правилоглоссарий / карточка словаряLDM, затем PDM и контрактыCCB → карточки → модель
(б) Структура — новая сущность, атрибут, связь, ключER / LDMлогический словарь → физическийCCB → модель → карточки затронутых элементов
(в) Физика — тип СУБД, индекс, nullable на PDM без смены смыслафизический словарь / DDL—логическое определение не меняется без причины
(г) Расхождение имён на DFD и в словаресловарь как канон имёнDFD (03.04.02 Диаграмма потоков данных (DFD))привести store и потоки к одному канону

Хранилища на DFD соответствуют сущностям LDM; имена потоков и store сверяйте со словарём на ревью моделей, не подменяя диаграмму таблицей атрибутов.

3.3 Reconciliation при drift (legacy и быстрая разработка)

На legacy-проектах схема БД, OpenAPI или миграции часто обгоняют словарь. Регламент сверки:

  1. Inventory — выгрузить актуальную схему (DDL, OpenAPI spec, catalog harvest) и сравнить со словарём: новые поля, переименования, исчезнувшие элементы.
  2. Классификация расхождений — (i) поле есть в коде, нет в словаре; (ii) определение разошлось; (iii) словарь опережает нереализованную фичу.
  3. Leading при конфликте: если поле уже в prod и используется — физика leading: сначала зафиксировать факт в физическом словаре (harvest или ручной аудит), затем согласовать логическое определение с владельцем данных; если фича ещё не релизнута — логический словарь leading, код догоняет baseline.
  4. Закрытие drift — PR/тикет на обновление словаря + модели; без «тихого» принятия DDL как определения.

Harvest из БД и LLM-черновики по sample data ускоряют шаг 1, но не заменяют утверждение владельца (11.07 Практические кейсы применения LLM в анализе).

3.4 Инструменты на проекте

3.5 Практические рекомендации

3.6 Пример: карточки к модели магазина

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

Клиент.идентификатор — Заказ.ссылка_на_клиентаЗаказ.идентификатор — ПозицияЗаказа.ссылка_на_заказТовар.идентификатор — ПозицияЗаказа.ссылка_на_товар
Клиент
  • идентификаторvarcharPK
  • emailvarcharUK NN
  • полное_имяvarcharNN
Товар
  • идентификаторvarcharPK
  • наименованиеvarcharNN
  • текущая_ценаdecimalNN
Заказ
  • идентификаторvarcharPK
  • ссылка_на_клиентаvarcharNN
  • статусvarcharNN
  • сумма_заказаdecimalNN
ПозицияЗаказа
  • идентификаторvarcharPK
  • ссылка_на_заказvarcharNN
  • ссылка_на_товарvarcharNN
  • количествоintNN
  • цена_единицыdecimalNN
Логическое имяФизическоеОпределениеДопустимые значенияПравило
Клиент.emailcustomers.emailАдрес, по которому клиент входит и получает чекиформат email, уникаленодин адрес на клиента; PII, маскировать в выгрузках
Заказ.статусorders.statusЭтап жизненного цикла заказаNEW, PAID, SHIPPED, CANCELLEDпереход только по диаграмме состояний, не произвольная строка
Заказ.ссылка_на_клиентаorders.customer_idКлиент, оформивший заказсуществующий customers.customer_idобязательна; гостевой заказ — отдельное решение, тогда поле может быть пустым
ПозицияЗаказа.цена_единицыorder_items.unit_priceЦена товара в момент оформлениячисло ≥ 0, два знакаснимок; отчёты не берут Товар.текущая_цена

сумма_заказа в карточке помечается как снимок суммы позиций, а не как поле, которое пользователь вводит. Связь «заказ содержит позиции» на диаграмме уже есть; в словаре остаётся правило, можно ли сохранить заказ без единой позиции.

4. Типовые ошибки и ограничения

  • Смешение логики и физики — NOT NULL и VARCHAR в логической карточке без пометки «только PDM».
  • Словарь = DDL — определения подменяются скриптами миграций; baseline теряется.
  • Drift без reconciliation — схема и контракты живут своей жизнью, словарь устаревает; команда не знает, что leading при конфликте.
  • Путаница leading/following — структурное изменение LDM оформляют через карточку словаря, минуя модель, или наоборот.
  • Глоссарий без связи с данными — термины не маппятся на элементы словаря; отчёты и API трактуют метрики по-разному.
  • Игнорирование классификации — PII-поля без метки маскирования и срока хранения; интеграции передают чувствительные данные «по умолчанию».
  • Полный охват с первого дня — паралич документирования; начинайте с критичных доменов.
  • Игнорирование API/событий — словарь только по таблицам, контракты живут отдельно и расходятся с LDM.
  • Конфликт project vs enterprise терминов — без явного scope команды используют разные определения «клиента» или «выручки».
  • Автогенерация как истина — AI-описание или harvest попали в prod без ревью владельца данных.
  • Условная обязательность как NOT NULL — «обязателен после оплаты» требует бизнес-правила или CHECK, а не слепого nullable=false.
  • Дублирование справочника в карточке — перечисление 500 кодов стран вместо ссылки на ref_country.

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

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

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

Статьи и онлайн-ресурсы:

Инструменты: