Мысли о размерности мер для BI

Question

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

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

Мне интересно, как другие справляются с этой ситуацией. В настоящее время у нас есть около двадцати мер.

Answer 1

Инстинктивно мне это не нравится: это модель EAV, которая не очень популярна (вы можете узнать причины Google).

• Модель EAV, как правило, считается головной болью для запроса и обслуживания
• Различные меры сочетаются с различными измерениями; этот подход может легко превратиться в «одну гигантскую таблицу фактов для всего» вместо нескольких небольших таблиц фактов для конкретных областей отчетности
• Я подозреваю, что в конечном итоге вы создадите представления, которые в любом случае создадут вид нескольких таблиц фактов
• Вы умножите количество строк в вашей таблице фактов на количество мер, в результате чего физическая таблица будет намного больше
• Даже при хорошей схеме индексации / разбиения запросы, содержащие более одного показателя, должны будут прочитать намного больше строк, чтобы получить данные
• А как насчет мер с различными типами данных?
• Легко ли это поддерживается в вашем инструменте отчетности?

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

Answer 2

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

«Меры» - этопо существу, другое измерение (и часто упоминается как таковое в документации).Я полагаю, что SSAS использует в основном закулисную структуру, ориентированную на столбцы.

Однако у наивного применения этого подхода есть некоторые проблемы, которые могут прийти к вам в большей или меньшей степени.*

У вас есть только одна мера, [Значение], [Сумма] или как она называется.Если ваш инструмент не позволяет вводить вычисленные меры в интерфейс, тогда вы не можете отсортировать весь набор данных по значению одного из ваших типов атрибутов.ProClarity и построитель отчетов> = 2.0 сделают это, а Excel - нет.

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

Хотя этоне сильно отличаясь от куба, он будет медленно запрашивать базу данных и увеличивать требования к хранилищу.Это также сложный запрос к базе данных.