коды поиска в измерении хранилища данных

Многие ключевые объекты в вышестоящей OLTP-системе имеют множество кодов поиска для конкретных доменов, с которыми пользователи знакомы и которые хотят продолжать использовать в отчетах хранилища данных. Такие вещи, как product_category = "SRB6", Inventive_scheme = "APP3" и т. Д. Эти коды имеют длинные описания форм, но это не то, с чем пользователи знакомы и не хотят этого.

Между кодами низкая корреляция, а количество элементов, как правило, не такое низкое, поэтому размер мусора не кажется правильным. Размеры сердечника обычно относятся к SCD типа II, и поисковые коды вряд ли изменятся.

Как я могу лучше всего смоделировать эти коды поиска, не используя снежинку таблиц поиска 3NF по измерению?

Я вижу следующие варианты:

  • поместите код и подробное описание прямо в таблицу размеров
  • поместите исходную систему, код и описание в единое глобальное измерение «поиска» с суррогатным ключом и используйте этот суррогатный ключ в измерении сущности.
  • Сочетание обоих; поисковые запросы тусклые суррогатный ключ, код и описание в измерении и SCD типа II поисковые запросы тусклые
  • Другой ?

data-warehouse lookup dimensional-modeling data-modeling
person gregn    schedule 17.05.2018    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Типичный подход к размерному моделированию заключается в том, чтобы просто разместить коды и подробные описания прямо в таблице измерений, к которой они относятся. Например. DimProduct будет иметь столбцы, описывающие категорию продукта, как коды, так и описания, если это необходимо.

Другие системы отдают приоритет общему управлению поисками, нормализацией и т. Д. И будут использовать другие варианты, как вы предложили, но они не будут многомерной моделью и не получат выгоды от легкой читаемости модели и производительности от уменьшенного количества объединений.

person Rich    schedule 17.05.2018
comment
да, я думаю, что это затуманивает аспект управления поиском. - person gregn; 17.05.2018
comment
Ах да, вы упомянули в вопросе, что их много. В Kimball Group сказали бы, что понятность модели для пользователей, которые не понимают базы данных, и производительность должны быть вашими основными целями: и если это означает, что вам нужно делать больше работы «на кухне» за кулисами, чтобы упростить задачу для пользователей, пусть так и будет. - person Rich; 18.05.2018