Звездная схема, нормализованные размеры, денормализованные ключи уровня иерархии

Учитывая следующие таблицы звездной схемы.

факт, два измерения, две меры.

#   geog_abb  time_date amount     value
#1:       AL 2013-03-26  55.57 9113.3898
#2:       CO 2011-06-28  19.25 9846.6468
#3:       MI 2012-05-15  94.87 4762.5398
#4:       SC 2013-01-22  29.84  649.7681
#5:       ND 2014-12-03  37.05 6419.0224

размер географии, единая иерархия, 3 уровня в иерархии.

#   geog_abb  geog_name geog_division_name geog_region_name
#1:       AK     Alaska            Pacific             West
#2:       AL    Alabama East South Central            South
#3:       AR   Arkansas West South Central            South
#4:       AZ    Arizona           Mountain             West
#5:       CA California            Pacific             West

размер времени, две иерархии, 4 уровня в каждом.

#    time_date time_weekday time_week time_month time_month_name time_quarter time_quarter_name time_year
#1: 2010-01-01       Friday         1          1         January            1                Q1      2010
#2: 2010-01-02     Saturday         1          1         January            1                Q1      2010
#3: 2010-01-03       Sunday         1          1         January            1                Q1      2010
#4: 2010-01-04       Monday         1          1         January            1                Q1      2010
#5: 2010-01-05      Tuesday         1          1         January            1                Q1      2010

Примеры лишены суррогатных ключей для улучшения удобочитаемости. В результатах есть уровни в иерархии без других атрибутов, просто не беспокойтесь, они все еще находятся в иерархии.

В схеме звезд, выраженной как:

         GEOGRAPHY (all fields)
        /
       /
   FACT
       \
        \
         TIME (all fields)

В схеме снежинки, выраженной как:

                    geog_region_name
                   /
                  geog_division_name
                 /
                geog_abb (+ geog_name)
               /
              /
          FACT
              \
               \
                time_date
                   |
hierarchies:       |
        weekly    / \    monthly
                 /   \ 
                /     \
   time_weekday         time_month (+ time_month_name)
            |             |
            |             |
        time_week     time_quarter (+ time_quarter_name)
            |             |
            |             |
        time_year      time_year

Как вы могли бы назвать следующую схему

Есть ли у него какое-то конкретное имя? Starflake?:)

        |>-- geog_region_name
        |
        |>-- geog_division_name
        |
        |>-- geog_abb (+ geog_name)
        |
        |
        geography base
       /
      /
  FACT
      \
       \
        time base
        |
        |
        |>-- time_date
        |
        |>-- time_weekday
        |
        |>-- time_week
        |
        |>-- time_month (+ time_month_name)
        |
        |>-- time_quarter (+ time_quarter_name)
        |
        |>-- time_year

В основном это таблица базовых размеров, в которой хранятся идентификаторы каждого уровня каждой иерархии в пределах измерения. Нет необходимости в рекурсивной прогулке по уровням снежинок, что потенциально меньше объединяет. Данные все еще хорошо нормализованы, только ключи денормализуются в базовую таблицу. Все уровни из всех иерархий привязаны к наименьшему зернистому ключу измерения в размерной базе.
Кроме того, таблица размеров базы данных позволяет обрабатывать временные атрибуты/временные запросы только в этой таблице при степени детализации уровня иерархии.

Вот табличное представление.

Все еще на естественных клавишах!

Факт

#    geog_abb  time_date amount     value
# 1:       AK 2010-01-01 154.43 12395.472
# 2:       AK 2010-01-02  88.89  6257.639
# 3:       AK 2010-01-03  81.74  7193.075
# 4:       AK 2010-01-04 165.87 11150.619
# 5:       AK 2010-01-05   8.75  6953.055

база измерения времени

#     time_date time_year time_quarter time_month time_week time_weekday
# 1: 2010-01-01      2010            1          1         1       Friday
# 2: 2010-01-02      2010            1          1         1     Saturday
# 3: 2010-01-03      2010            1          1         1       Sunday
# 4: 2010-01-04      2010            1          1         1       Monday
# 5: 2010-01-05      2010            1          1         1      Tuesday

нормализация времени до уровней иерархии

#    time_year
# 1:      2010
# 2:      2011
# 3:      2012
# 4:      2013
# 5:      2014

#    time_quarter time_quarter_name
# 1:            1                Q1
# 2:            2                Q2
# 3:            3                Q3
# 4:            4                Q4

#    time_month time_month_name
# 1:          1         January
# 2:          2        February
# 3:          3           March
# 4:          4           April
# 5:          5             May

#    time_week
# 1:         1
# 2:         2
# 3:         3
# 4:         4
# 5:         5

#    time_weekday
# 1:       Friday
# 2:       Monday
# 3:     Saturday
# 4:       Sunday
# 5:     Thursday

#     time_date time_week time_weekday time_year
# 1: 2010-01-01         1       Friday      2010
# 2: 2010-01-02         1     Saturday      2010
# 3: 2010-01-03         1       Sunday      2010
# 4: 2010-01-04         1       Monday      2010
# 5: 2010-01-05         1      Tuesday      2010

Географическая размерная база

#    geog_abb geog_region_name geog_division_name
# 1:       AK             West            Pacific
# 2:       AL            South East South Central
# 3:       AR            South West South Central
# 4:       AZ             West           Mountain
# 5:       CA             West            Pacific

Нормализация размеров географии на уровнях иерархии

#    geog_region_name
# 1:    North Central
# 2:        Northeast
# 3:            South
# 4:             West

#    geog_division_name
# 1: East North Central
# 2: East South Central
# 3:    Middle Atlantic
# 4:           Mountain
# 5:        New England

#    geog_abb  geog_name geog_division_name geog_region_name
# 1:       AK     Alaska            Pacific             West
# 2:       AL    Alabama East South Central            South
# 3:       AR   Arkansas West South Central            South
# 4:       AZ    Arizona           Mountain             West
# 5:       CA California            Pacific             West

Размерная база может хранить также атрибуты первичного ключа, это уменьшит дублирование измерения самого низкого уровня, но будет менее согласованным (уровни time_date от обеих иерархий будут вписываться в базовые таблицы измерения времени).

Какие недостатки могут иметь такие схемы? Я не очень беспокоюсь о скорости объединений и агрегатов, а также адаптивности запросов.
У него есть какое-то имя? Он используется? Если не так?

Ответ 1

Вы строите схему снежинок с ярлыками.

Он используется, и инструменты BI могут легко использовать ярлыки.

Вы также можете иметь ярлыки от родительского уровня измерения до таблицы фактов на уровне ребенка для этого измерения. Он работает, вы можете пропустить соединение, но вам нужно сохранить дополнительный столбец в таблице фактов.

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

Это не очень важно, если вы каждый раз генерируете свою таблицу измерений из нормализованных данных, но вам нужно быть осторожным, даже если вы храните родительский идентификатор в таблице фактов.

Ответ 2

Что вы делаете, это не схема снежинок... она похожа на "Data Vault" и нашу собственную вариацию "Link-Model". Он по существу создает таблицы ссылок, содержащие только ключи, которые находятся между таблицами фактов и таблицами Dim (и другими таблицами Dim). Хотя мы описываем их как таблицы сущностей и таблицы измерений.

Преимущества

Вы можете сравнивать размеры и таблицы фактов, а затем заполнять таблицы ссылок
Сложные практики, такие как "как при отчетности" с "Корректировками", как они найдены в "Страховании", могут быть легко обработаны.
Более интуитивно разделить медленно и быстро изменяющиеся таблицы измерения размеров, которые просто связаны таблицами ссылок. Это экономия времени.
Добавление новых измерений в таблицы фактов довольно просто и быстро, ведь это просто добавление дополнительного целочисленного столбца в таблицу, содержащую только целые числа.
Фактические факты гораздо более интуитивно понятны, чем в обычной схеме. Вы можете создавать отношения между измерениями без какой-либо записи фактов.

Недостатки

Немного более сложная структура схемы, поэтому мы обычно создаем модели Kimball поверх "Link Model", поскольку бизнес-пользователи, как правило, хорошо ее понимают.
Чтобы добавить новое измерение в таблицу фактов или расширить таблицу измерений, можно легко сделать, но схема со временем может засориться.