#data-modeling #data-warehouse #cube #snowflake-cloud-data-platform
#моделирование данных #хранилище данных #куб #snowflake-облачная платформа данных
Вопрос:
У меня возникли разногласия с коллегой по поводу моделирования хранилища данных.
У нас есть измерение сущности, которое имеет валюту «по умолчанию» и измерение валюты.
Я предположил, что таблица фактов (например, продажи) будет связана с измерением валюты и что у нас будет код валюты в качестве атрибута в измерении сущности (только для информационных целей)
Мой коллега решил связать таблицу фактов с измерением валюты, а также связать измерение сущности с измерением валюты. Он говорит, что это помогло бы ему получить информацию о валюте объекта (обменный курс и т. Д.)
Я не согласен с этим, и он, похоже, не согласен со мной.
Что вы думаете ?
Спасибо!
Ответ №1:
Вы правы, а ваш коллега ошибается.
В правильной размерной модели измерения взаимодействуют друг с другом только через таблицы фактов, никогда напрямую. То же самое верно и для таблиц фактов — вы никогда не связываете их напрямую, только через общие измерения.
Ключевая идея схемы star заключается в том, чтобы иметь набор таблиц измерений в 2NF (вторая нормальная форма), разрешающих их отношения с помощью таблиц фактов в 3NF. Связывание измерений напрямую нарушает этот принцип.
Кроме того, я не понимаю, чего он пытается добиться с помощью прямой ссылки. Информация, которую ищет ваш коллега, может быть легко запрошена из обычно разработанной звездообразной схемы. Просто нет необходимости усложнять вашу модель данных странными конструкциями.
Комментарии:
1. Точно ! Я использовал эти точные аргументы, и он, похоже, не понимает. Он говорит, что предпочитает иметь внешний ключ валюты в таблице сущностей, который приведет его к деталям валюты, а не к простому описанию.
2. Сколько из этих «сведений о валюте» у него есть? Если их сотни, то, возможно, вам нужно использовать это измерение как dim «Валюта по умолчанию». Если есть 5-10 атрибутов валюты, просто перенесите их все в измерение сущности.