Использование микростратегии в высоконормализованной базе данных SQL Server

Независимо от того, какой инструмент создания отчетов вы используете, у вас будут проблемы с производительностью, если в фоновом режиме используются сложные соединения типа «снежинка». Это связано с тем, что каждый пользователь, который запускает отчет, вызывает запуск одного и того же SQL - некоторые инструменты имеют умные кэши, но это не работает, когда у вас есть выбранные пользователем подсказки.

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

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

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

Я не знаю, активна ли эта тема, но вот некоторые мысли.

Базы данных транзакций, на мой взгляд, не лучший вариант для создания отчетов BI. Реляционная модель хорошо подходит для повседневных и оперативных отчетов.

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

Этому утверждению есть ряд причин. Я не буду вдаваться во все причины. Лучше всего приобрести любую из прекрасных книг Кимбала по пространственному моделированию.

Я пытался использовать несколько различных пакетов отчетов, включая MicroStrategy, и самым большим фактором, определяющим, будет ли ваш проект работать или нет, является наличие у вас хорошего дизайна многомерной базы данных для вашего BI Warehouse. Это, конечно, означает использование некоторого процесса ETL для преобразования реляционных данных в многомерные данные.

Надеюсь это поможет.

Я использовал инструменты Microstrategy много лет назад. Мои комментарии могут быть устаревшими. В то время это был идеальный инструмент против звездной схемы. Он может генерировать множество оптимизированных операторов SQL для предоставления набора результатов. Однако он не работал нормально на 3-й нормальной форме db.

В третьей нормальной форме db я бы предложил альтернативный инструмент, такой как бизнес-объекты, которые могут обрабатывать любую структуру db. Я видел вселенную бизнес-объектов поверх системы перестрахования OLTP с более чем 5000 таблиц/представлений 3-й нормальной формы, и это работало нормально. Но когда вы начинаете использовать 3-ю нормальную форму, трудно получить правильные результаты для всех возможных запросов, а также это будет намного медленнее по сравнению с денормализованной схемой звезды.

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