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

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

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

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

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

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

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

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

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

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

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

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

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

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

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