Как избежать сложных объединений в схеме звезды? - PullRequest
2 голосов
/ 29 июня 2010

Моя таблица фактов содержит оценку пользователя по курсу, который он выбрал.Некоторые детали курса, которые я должен показать в отчете, взяты из нескольких таблиц (в фактической базе данных OLTP).
Создать ли ненормализованную версию этой записи курса в таблице измерений?
Или же я просто присоединяю таблицу фактов непосредственно к соединению таблицы курса с другими таблицами, которые описывают этот курс (тип_курса, факультет, создавший этот курс и т. Д.)

Ответы [ 4 ]

2 голосов
/ 02 июля 2010

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

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

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

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

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

1 голос
/ 06 июля 2010

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

Также помните, что, хотя вы получаете сокращение накладных расходов на соединение, есть некоторые недостатки:

  • Потеря гибкости, которая может помешать развитию по мере расширения склада
  • Полное сканирование таблицы занимает больше времени (в традиционных СУБД на основе строк, таких как SQL Server)
  • Потребление дискового пространства

Вам придется рассматривать каждый случай отдельно.

Возможно, стоит также рассмотреть возможность создания материализованного представления, если такая возможность предлагается вашей СУБД.

1 голос
/ 30 июня 2010

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

Если бы вы опубликовали модель (схему), было бы легче прокомментировать / помочь.

0 голосов
/ 03 июня 2011

У нас обычно есть схема снежинки в качестве физического проекта DWH, но мы добавляем слой представления отчетов, который объединяет схему снежинки в схему звезды.

Таким образом, ваш куб OLAP становится намного проще и проще в управлении.

...