7.7 Моделирование данных и семантический слой

Обзор и мотивация

Модель данных это решение о том, что значат ваши данные, принятое до решения о том, где они живут. Она называет вещи, о которых заботится ваш бизнес, атрибуты, их описывающие, и связи между ними. Хранилище, индексы, форматы файлов и движки запросов приходят позже. Этот порядок важен, потому что смысл ваших данных переживает каждую технологию, которой вы их держите. Хранилища заменяют, форматы таблиц меняются, а движки запросов приходят и уходят, но «клиент», «заказ» и «активный пользователь» должны значить одно и то же во всех них, годами.

Для малой команды моделирование нередко неявно. Один инженер держит всю схему в голове, а общее понимание «выручки» выживает, потому что спорить некому, кроме троих. В масштабе больших организаций разработки, корпораций и государственных ведомств эта неформальность рушится именно так, как описано в главе 7.1 (стратегия данных и управление данными). Десятки команд строят сотни таблиц, у каждой своё представление о том, что такое «сеанс» или когда пользователь считается «активным». Две панели показывают два разных числа за одну неделю, а совещание руководства превращается в спор о том, чей запрос верен, вместо вопроса, что делать дальше. Плохое моделирование о себе не объявляет. Оно проявляется месяцы спустя в работе по сверке, проваленных аудитах и решениях, принятых по цифрам, которые никто не может защитить.

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

См. также: глава 3.4 (архитектура данных и хранилища), глава 7.3 (аналитика и бизнес-аналитика) и глава 11.5 (ключевые показатели эффективности).

Ключевые принципы

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

Рекомендации

Моделируйте на трёх уровнях, по порядку

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

Нормализуйте транзакционные системы, денормализуйте аналитические намеренно

Для систем, записывающих транзакции, отдавайте предпочтение нормализации баз данных. Нормальные формы убирают избыточность, так что каждый факт хранится один раз, что предотвращает аномалии обновления и сохраняет записи корректными, когда много пользователей меняют данные одновременно. Это правильное значение по умолчанию для оперативной обработки транзакций (OLTP), где корректность при параллельных записях важнее скорости любого отдельного аналитического запроса. У аналитических систем противоположные приоритеты. Они в основном читают, сканируют и агрегируют огромные диапазоны, а соединение десятков нормализованных таблиц во время запроса медленно и трудно для осмысления. Там вы денормализуете намеренно, сворачивая связанные атрибуты вместе, чтобы запросы были проще и быстрее. Дисциплина в том, чтобы денормализовать намеренно, с документированной причиной, а не давать избыточности вползти случайно. Глава 3.4 (архитектура данных и хранилища) охватывает движки, заставляющие работать каждый шаблон.

Используйте размерностное моделирование для аналитики

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

Зафиксируйте зерно и обращайтесь с изменяющимися измерениями явно

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

Стройте один семантический слой как единое определение каждой метрики

Это рекомендация, окупающая всю главу. Семантический слой стоит между вашими физическими таблицами и каждым потребляющим их инструментом и хранит единое управляемое определение каждой бизнес-метрики. «Активный пользователь» определён один раз, как код, с точной логикой: какие события считаются, за какое окно, с исключением каких внутренних учётных записей. «Выручка» определена один раз, включая обращение с возвратами, скидками и пересчётом валют. Каждая панель, блокнот, отчёт и задание обратного ETL читают это определение вместо повторной реализации в заказном запросе. Когда определение меняется, оно меняется в одном месте, и все потребители обновляются вместе. Это механизм, делающий управляемые определения метрик реальными, а не желаемыми, и это прямая реализация того, чего просит глава 11.5 (ключевые показатели эффективности). Воспринимайте определения метрик как версионируемый код с владельцами, рецензией и тестами, точно как глава 7.1 просит воспринимать данные как продукт.

Установите соглашения, именование и документацию

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

Держите модели эволюционируемыми

Ваша модель изменится, поэтому проектируйте для изменений. Добавляйте столбцы, а не перепрофилируйте существующие. Используйте суррогатные ключи, чтобы изменение естественного ключа системы-источника не прокатывалось по всему вашему хранилищу. Версионируйте определения метрик и выводите их из употребления с уведомлением, а не молча изменяйте под работающими панелями. Держите преобразования под контролем версий, протестированными и рецензируемыми, так что изменение смысла «активного пользователя» это запрос на слияние с диффом и утверждающим, а не тихая правка в инструменте BI. Модель, которую нельзя безопасно эволюционировать, становится моделью, которую люди обходят, а теневые определения то, как умирает единый источник истины.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы	Лучше всего подходит
Нормализованная (3NF)	Корректные записи, нет избыточности, гибко	Медленные аналитические соединения, сложные запросы	OLTP и операционные системы
Схема «звезда» (Кимбалл)	Быстро, интуитивно, дружественно аналитикам	Некоторая избыточность, нужно сопровождать ETL	Большая часть аналитики и BI
Схема «снежинка»	Меньше хранилища, чище измерения	Больше соединений, больше сложности	Большие строго управляемые измерения
Data vault	Полная история, проверяемо, гибкие загрузки	Много таблиц, крутая кривая обучения	Строго регулируемые, с упором на аудит
Семантический слой поверх моделей	Одно определение повсюду, независимо от инструмента	Построение заранее, нужно владение	Многокомандные, многоинструментальные организации

Центральное напряжение между скоростью отдельного запроса и корректностью и гибкостью по всему хозяйству. Нормализация защищает корректность и платит за это сложностью запросов; размерностные модели покупают скорость запросов и ясность и платят за это ETL и некоторой управляемой избыточностью. Универсального победителя нет, поэтому вы подбираете модель под нагрузку, а не выбираете любимца. Семантический слой разрешает второе напряжение, между многими командами и многими инструментами, делая определение метрики независимым от любого из них. Ошибка воспринимать это как идеологические лагеря. Здоровая организация ведёт нормализованные системы OLTP, размерностные аналитические модели, питаемые из них, и один семантический слой сверху, каждый занимается тем, что умеет.

Вопросы для обсуждения с командой

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

Взгляд по секторам

Стартап. Моделирование может подождать, а определения нет. С двумя инженерами и без запаса на построение хранилища поместите один небольшой семантический слой в ваш инструмент преобразований и определите две-три метрики, за которыми действительно следит ваш совет директоров, «активный пользователь» и «выручка», один раз как протестированный код. Пропустите data vault и сложные размерностные схемы; тонкая звезда и горстка управляемых определений покупают согласованные числа, не замедляя поставку. Выигрыш в том, что подготовка к совету директоров перестаёт быть спором о том, чей запрос верен.

Малый бизнес. У вас нет моделировщика данных и бюджета на платформу метрик, поэтому опирайтесь на определения, встроенные в уже используемые инструменты, и запишите немногие важные в один общий документ, который читают все. Предпочитайте покупку аналитики, встроенной в существующее ПО, подъёму хранилища, которое вы не можете обслужить. Где вы всё же моделируете, держите просто и называйте вещи последовательно, потому что человек, сопровождающий это в следующем году, может оказаться тем, кто не помнит, почему «клиент» значил две вещи. Согласованность дешевле сверки.

Крупная организация. Проблема многие команды и многие инструменты, дрейфующие в частные определения, поэтому вкладывайтесь в согласованные измерения, один управляемый семантический слой и определения метрик в виде версионируемого кода с владельцами и рецензией. Стандартизируйте именование, объявления зерна и стратегии медленно меняющихся измерений по хозяйству, чтобы число в одном инструменте совпадало с тем же числом в другом. Воспринимайте семантический слой как продукт с дорожной картой и владеющей командой и измеряйте, сколько времени сверки он убирает. Отдача в заслуживающих доверия числах по бизнесу и аудитах, чисто прослеживающих от презентации для совета директоров обратно до источника.

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

Примеры

Стартап. У компании серии A было три определения «активного пользователя», живших в трёх местах: инструменте продуктовой аналитики, таблице финансов и презентации для инвесторов. Числа никогда не совпадали, и каждая подготовка к совету директоров превращалась в суету. Два инженера ввели небольшой семантический слой в своём инструменте преобразований, определив «активного пользователя» и «ежемесячную повторяющуюся выручку» один раз как протестированный код, с точными окнами и исключениями. Теперь каждая панель читает эти определения. Спор при подготовке к совету исчез, а введение нового аналитика превратилось из недели племенного знания в чтение одной документированной модели. Это напрямую связано с дисциплиной, описанной в главе 7.4 (продуктовая аналитика и эксперименты), где стабильное определение «активного» делает результаты экспериментов сопоставимыми.

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

Государственный сектор. Национальному правительству требовалась сопоставимая отчётность по ведомствам здравоохранения, труда и образования, каждое из которых исторически определяло «домохозяйство», «регион» и «занятость» по-своему. Межведомственный орган установил общие справочные данные и стандартные определения: канонические таблицы измерений для географии и демографии и управляемые определения основных индикаторов, опубликованные с методологией и версионируемыми выпусками. Отдельные ведомства моделируют свои операционные данные, но соблюдают общие измерения и определения для всего, что сообщается на национальном уровне. В результате цифру одного ведомства можно честно сравнивать с другим, а общество может проследить любой опубликованный индикатор до документированного определения, что поддерживает обязательства прозрачности, охваченные в главе 7.1.

Бизнес-обоснование: мотивы, ROI и TCO

Отдача от хорошего моделирования и семантического слоя в основном возвращённое время и избегнутые ошибки. Во многих организациях аналитики тратят большую часть времени на поиск данных, сверку конфликтующих чисел и перестройку определений, которые другие уже написали. Единое управляемое определение каждой метрики превращает эту повторяющуюся работу в разовое вложение. Оно также убирает целую категорию дорогих отказов: неверное число в презентации для совета директоров, неверно сообщённую цифру, вызывающую замечание аудита, квартальный проект сверки, существующий лишь потому, что две команды определили «выручку» по-разному. Когда определение живёт в одном рецензируемом месте, эти отказы в основном прекращаются.

Цена реальна и стоит названия. Вы вкладываетесь заранее в концептуальное и логическое моделирование, в построение и наполнение семантического слоя и в постоянное владение, поддерживающее определения актуальными. Совокупная стоимость владения (TCO) включает инструменты, время моделирования и инженерии аналитики и управление, не дающее модели дрейфовать. Взвесьте это против цены неделания, которая больше, но скрыта: она проявляется как дублированные конвейеры, аналитики в роли человеческих движков сверки и руководители, принимающие уверенные решения по цифрам, которые никто не может защитить. Обосновывайте перед руководством в его терминах. Одно заслуживающее доверия определение каждой метрики позволяет им сравнивать по бизнесу, доверять панелям и отвечать регуляторам без аврала. Начинайте там, где боль сверки сильнее всего, определите те немногие метрики один раз и пусть возвращённое время финансирует остальное.

Антипаттерны и ловушки

Прыжок сразу к физическим таблицам, впекающий сегодняшнюю технологию в решения, которые должны её пережить.
Определение одной и той же метрики независимо в каждой панели, так что никакие два числа не совпадают.
Оставление зерна невысказанным с последующим обнаружением дважды сосчитанных мер в отчёте о выручке.
Денормализация аналитических таблиц случайно, а не по документированному решению.
Нормализация аналитического хранилища до тех пор, пока каждый запрос не станет соединением двенадцати таблиц, которого никто не понимает.
Обработка медленно меняющихся измерений перезаписью, так что исторические отчёты молча переписывают прошлое.
Использование естественных ключей повсюду, так что изменение ключа источника прокатывается по всему хранилищу.
Построение семантического слоя без владельца, так что определения дрейфуют, а доверие слабеет.
Воспринимание модели как законченной при запуске вместо живого актива, который должен оставаться эволюционируемым.

Модель зрелости

Уровень 1, Начальный: Моделирование неявно и реактивно. Таблицы проектируются сначала физически тем, кому они нужны. Метрики переопределяются в каждом отчёте, и числа регулярно конфликтуют. Зерно не документировано, и определениями никто не владеет.
Уровень 2, Развитие: Некоторые аналитические таблицы следуют размерностному шаблону, и у нескольких ключевых метрик есть письменные определения, но они живут в вики и не принуждаются. Соглашения об именовании существуют на бумаге. Практика различается от команды к команде, а сверка по-прежнему частая и ручная.
Уровень 3, Стандартизация: Концептуальная, логическая и физическая модели различны и рецензируются. Семантический слой определяет основные метрики один раз, как версионируемый код с владельцами. Согласованные измерения позволяют командам безопасно соединять данные. Зерно и стратегии медленно меняющихся измерений документированы и принуждаются на рецензии по организации.
Уровень 4, Управление: Хозяйство моделей измеряется относительно базовых значений. Вы отслеживаете покрытие определений метрик (долю сообщаемых метрик, обслуживаемых семантическим слоем), число всё ещё используемых дублирующих или теневых определений, часы сверки в квартал и долю дефектов зерна и происхождения, пойманных на рецензии, а не в производстве. Изменения определений идут через рецензируемые запросы на слияние с тестами, а свежесть, доли прохождения тестов и дрейф отслеживаются на панелях. Когда метрика расходится или измерение перестаёт соответствовать, измерение выявляет это раньше совещания совета директоров.
Уровень 5, Оркестрация: У каждой важной метрики одно управляемое определение, потребляемое всеми инструментами и командами, а семантический слой интегрирован с аналитикой, экспериментами и регулируемой отчётностью. Модели эволюционируемы по замыслу и непрерывно уточняются; определениям доверяют по всей организации; работа по сверке в основном исчезла. Организация регулярно выводит, пересматривает и согласует новые измерения по мере изменения бизнеса, перебалансируя хозяйство моделей как адаптивный актив.

Идеи для обсуждения

Выберите три важнейшие метрики. Сколько различных определений каждой существует сегодня в ваших инструментах и что потребовалось бы, чтобы свести их к одному?
Где невысказанное зерно вызвало настоящую ошибку отчётности и сколько времени ушло на то, чтобы её заметить?
Какие из ваших измерений следует согласовать между командами в первую очередь и кто ими владеет?
Хранятся ли ваши определения метрик под контролем версий с рецензией или правятся молча внутри инструмента BI?
Когда медленно меняющееся измерение в последний раз переписало вашу историю, и никто не заметил, и как вы поймаете это в следующий раз?
Если бы вы заменили движок хранилища завтра, сколько смысла вашей модели пережило бы переезд?

Главные выводы

Моделирование данных это решение о том, что значат данные, и этот смысл переживает каждую технологию хранения, которую вы выбираете.
Моделируйте на трёх уровнях по порядку: концептуальном, затем логическом, затем физическом.
Нормализуйте транзакционные системы ради корректности; денормализуйте аналитические намеренно ради скорости.
Используйте размерностное моделирование с фактами, измерениями и заявленным зерном для аналитики.
Стройте один семантический слой, чтобы у каждой бизнес-метрики было единое управляемое определение повсюду.
Согласованные измерения позволяют независимым командам соединять и сравнивать данные с уверенностью.
Называйте хорошо, документируйте, используйте суррогатные ключи и версионируйте определения, чтобы модель оставалась эволюционируемой.

Источники и дополнительное чтение

Ralph Kimball and Margy Ross, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modelling.
Bill Inmon, Building the Data Warehouse.
Dan Linstedt and Michael Olschimke, Building a Scalable Data Warehouse with Data Vault 2.0.
Peter Chen, “The Entity-Relationship Model: Toward a Unified View of Data,” ACM Transactions on Database Systems.
E. F. Codd, “A Relational Model of Data for Large Shared Data Banks,” Communications of the ACM.
C. J. Date, An Introduction to Database Systems.
Lars Rönnbäck and colleagues, writings on anchor modelling.
DAMA International, DAMA-DMBOK: Data Management Body of Knowledge.