Какой тип данных для атрибутов типа даты в размерной таблице, включая даты начала и окончания?

Question

Я проектирую хранилище данных с использованием многомерного моделирования.Я прочитал большую часть инструментария хранилища данных от Kimbal & Ross.Мой вопрос касается столбцов в размерной таблице, которые содержат даты.Например, вот таблица для пользователей приложения:

CREATE TABLE user_dim (
   user_key BIGINT,  -- surrogate key
   user_id BIGINT,   -- natural key
   user_name VARCHAR(100),
   ...
   user_added_date DATE, -- type 0, date user added to the system
   ...
   -- Type-2 SCD administrative columns
   row_start_date DATE, -- first effective date for this row
   row_end_date DATE,   -- last effective date for this row, 9999-12-31 if current
   row_current_flag VARCHAR(10), -- current or expired
)

Последние три атрибута предназначены для реализации медленно меняющихся измерений типа 2.См. Страницу Кимбала 150-151.

Вопрос 1. Существуют ли передовые практики для типов данных столбцов row_start_date и row_end_date?Тип может быть DATE (как показано), STRING / VARCHAR / CHAR («YYYY-MM-DD») или даже BIGINT (внешний ключ для измерения даты).Я не думаю, что будет много фильтрации по датам начала / окончания строки, поэтому ключ к измерению даты не требуется.

Вопрос 2. Существует ли передовая практика для типа данных атрибутов измерения, таких как «user_added_date»?Я вижу, что кто-то хочет, чтобы отчеты о пользователях добавлялись за финансовый квартал, поэтому было бы полезно использовать внешний ключ для измерения даты.Есть ли у этого недостатки, кроме необходимости присоединиться от измерения пользователя к измерению даты для отображения атрибута?

Если это имеет значение, я использую Amazon Redshift.

Answer 1

Для вопроса 1: row_start_date и row_end_date не являются частью входящих данных. Как вы упомянули, они созданы искусственно для целей SCD типа 2, поэтому у них не должно быть ключа к измерению даты. У пользователя dim нет причин иметь ключ к измерению даты. Для типа данных YYYY-MM-DD должно быть в порядке.

Для Вопроса 2: Если у вас есть такое требование, я бы предложил создать производную таблицу фактов (часто называемую таблицей фактов накопительного снимка), чтобы сохранить производные показатели, такие как user_added_date

Подробнее см. https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/accumulating-snapshot-fact-table/

Answer 2

Вопрос 1: Для SCD от и до даты я предлагаю вам использовать метку времени.Я предпочитаю БЕЗ часового пояса и убедитесь, что все ваши временные метки указаны в формате UTC

Вопрос 2. Я всегда настраиваю таблицу измерений даты с логическим ключом фактической даты.таким образом, вы можете присоединить любую дату (например, дату начала пользователя) к измерению даты, чтобы найти, например, «финансовый месяц» или что-то еще вне измерения даты.Но также вы можете видеть дату без присоединения к измерению даты как ее обычное представление (сохраняемое как дата)

При использовании красного смещения (или любой столбчатой ​​СУБД MPP) целесообразно немного денормализовать.например, используйте схему звезды, а не схему снежинки.Это из-за эффективности, которую приносит столбчатый, и имеет дело с неэффективными объединениями (потому что нет индексов)