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

Question

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

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

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

Опции, которые я вижу, включают:

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

Answer 1

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

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