Как избежать сложных объединений в схеме звезд?

Question

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

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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