Материал опубликован с разрешения компании
Автор оригинала: Warren Thornthwaite (все
статьи)
Перевод на русский язык: Татьяна Лякишева
Оригинальный документ располагается здесь.
Проблема именования полей возникает всякий раз, когда приходится
строить многомерную модель. Именование действительно непростое дело:
разные люди понимают под одними и теми же словами разные вещи, как,
например, «доход» (revenue), или наоборот – используют разные наименования
для одного и того же объекта или понятия, например «продажи» (sales).
Это в природе человека: большинство из нас не хочет отказываться
от того, что понятно и привычно, и переучиваться на нечто новое.
Задачу определения имен в модели решает, как правило, «стюард данных»
(data steward). Если именно Вам выпало разбираться с этим политическим
кошмаром, может оказаться полезным изложенный далее подход из трех
шагов. Первые два обычно делаем до того, как знакомить с моделью
бизнес-пользователей. Третий – после того, как бизнес-пользователи
уже увидели и осознали модель.
Шаг 1 – Подготовка
Начните с развития в себе умения находить точные, емкие и уникальные
наименования для элементов данных. Изучите соглашения о назначении
имен, применяемые в вашей организации (и команде). Посмотрите, какие
наименования таблиц и колонок используются в разных системах. Если
соглашений о назначении имен нет – самое время их разработать. Обычно
применяется подход, при котором имя колонки формируется из трёх
частей:
Первичное слово – это основное, категоризирующее понятие, которое
зачастую соотносится с названием исходной сущности, содержащей эту
колонку. В отдельных случаях квалификаторы вовсе не требуются. Например,
поле в таблице фактов Sales, обозначающее объем продаж в долларах,
так и назовем: Sales_Dollar_Amount. В Итернете вы найдете самые
разнообразные соглашения о назначении имен. Для начала можно посмотреть
здесь:
В процессе построения модели, совместно с командой, отвечающей
за ее разработку (включающей одного-двух представителей «от бизнеса»),
составьте предварительный вариант именования полей и подумайте над
обоснованием. Когда модель будет практически готова, соберитесь
снова и обсудите, насколько теперь наименования в ней правильны
и уместны (этот прием полезен также и на следующем шаге).
Помимо общих совещаний, для обсуждения наименований следует также
встречаться по отдельности с основными заинтересованными сторонами.
Это обычно ключевые бизнес-пользователи, а также старшие менеджеры,
которые могут иметь на этот счет собственную точку зрения. Если
они предпочитают иные названия полей, нежели те, которые вы предлагаете
– постарайтесь понять, почему. Помогите им как можно более четко
определить элементы данных, задавайте вопросы о том, что именно
тот или иной термин означает в их понимании. Возможно, не хватает
квалификаторов или классифицирующих слов для прояснения и уточнения
смысла? Например, аналитик по продажам интересуется показателем
(числом) «Продажи». Но оказывается, что на самом деле это не просто
продажи, а объем продаж, связанных с комиссионным вознаграждением
(Sales_Comissionable_Amount). А это совсем не то же самое, что брутто-продажи
(Sales_Gross_Amount) или чистый объем продаж (Sales_Net_Amount).
Полученный в результате набор имен вносится в текущую версию модели
данных. Отдельно отслеживайте и фиксируйте альтернативные наименования
колонок и аргументы в их пользу. В дальнейшем это поможет в обосновании
окончательного списка названий.
Шаг 3 - Достижение согласия
Наконец у вас есть полный, выверенный набор наименований, а ключевые
пользователи уже ознакомились с моделью данных. Теперь соберите
всех заинтересованных участников процесса в зале для совещаний как
минимум на полдня (а, возможно, и больше – если полей в модели достаточно
много, или народ склонен к дискуссиям). Начните с обобщенной, высокоуровневой
модели, и пройдитесь по всем полям, таблица за таблицей. К этому
моменту было уже достаточно итераций и обсуждений модели и наименований,
множество вопросов решено, а оставшиеся – понятны всем присутствующим.
Цель встречи – достичь соглашения по финальной, окончательной версии
набора имен. Как правило, это означает, что оставшиеся в меньшинстве
будут вынуждены принять волю большинства и распрощаться с любимыми
наименованиями отдельных полей. Просто удивительно, насколько этот
процесс может быть эмоциональным! Ведь имена в данном случае представляют
наше видение бизнеса, и люди всеми силами стараются, чтобы имена
эти были «правильными». Не выпускайте их из помещения, пока не договорятся
(если это, конечно, вообще возможно). Ведь, если собирать их еще
раз, снова будет потрачена масса времени на повторное изложение
всевозможных аргументов.
После того, как согласие, наконец, достигнуто, и получен окончательный
набор наименований, задокументируйте его самым тщательным образом
и передайте проектировщикам для внесения в финальную версию модели
данных.
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS