Как глубоко зайти при денормализации - PullRequest
Новая
       139

Как глубоко зайти при денормализации

1 голос
/ 09 мая 2019

Я денормализовал базу данных OLTP для использования в DWH. На данный момент я занимаюсь денормализацией учебных групп.

  • У каждой учебной группы есть ключ, указывающий на 1 проект.
  • У каждого проекта есть ключ, указывающий на 1 отдел.
  • У каждого отдела есть ключ, указывающий на 1 университет.
  • В каждом университете есть ключ, указывающий на 1 город.

Теперь я знаю, что вы должны денормализовать ваш * OLTP, но в этом департаменте dwh будет самостоятельное измерение. Это касается и университета. Достаточно ли добавить ключ из учебной группы, указывающий на отдел, или разумнее денормализовать, насколько это возможно, и добавить все атрибуты из отдела и все атрибуты из связанных с ним таблиц M: 1 в группу исследования измерения? Даже когда кафедра и университет будут сами по себе измерениями?

Другими словами: как далеко / глубоко вы продвигаетесь при денормализации?

1 Ответ

1 голос
/ 09 мая 2019

Ключевая концепция, лежащая в основе размерной модели:

  • Храните таблицы фактов в 3NF (третья нормальная форма);
  • Денормализовать ваши размеры в 2NF (вторая нормальная форма)

Так что в идеале единственными объединениями, которые вы должны иметь в своей модели, являются соединения между таблицами фактов и соответствующими измерениями.

Как часть этой философии:

  • Избегайте конструкций с «снежинками», где размеры содержат ключи к другим измерениям. Всегда можно придумать модель данных, которая обеспечивает ту же функциональность, что и снежные хлопья, без нарушения правила 3NF / 2NF;
  • Никогда не имейте прямых связей между двумя отдельными измерениями (т. Е. Отделом и учебной группой) напрямую. Все отношения между измерениями должны решаться с помощью таблиц фактов;
  • Никогда не имейте прямых соединений между 2 отдельными таблицами фактов. Любые отношения между таблицами фактов должны решаться с помощью общих измерений.

Наконец, рассмотрим, что многомерный дизайн, помимо оптимизации данных для запросов, служит второй важной цели: это семантическая модель бизнеса (или что-то еще, что он представляет). Поэтому при принятии решения о объединении элементов данных в измерения и факты учитывайте их «логическую близость» - они должны иметь интуитивный смысл для конечных пользователей. Если вам трудно объяснить аналитику BI значение вашего измерения или таблицы фактов, скорее всего, вы допустили ошибку моделирования.

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

В общем, если вы видите отношения 1: 1 или 1: M между элементами измерений, это часто указывает на то, что они должны быть нормализованы в одну и ту же таблицу (опять же, только если их комбинация имеет логический смысл). Если отношения M: M, скорее всего, они принадлежат разным таблицам (вы можете принудительно поместить их в одну таблицу, но часто такие таблицы выглядят как существа Франкенштейна).

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

...