My<cod/>.net
Как агрегировать данные из SQL Server 2005
У меня есть около 150 000 строк данных, записанных в базу данных каждый день. Эти строки представляют исходящие статьи, например. Теперь мне нужно показать график с использованием SSRS , который показывает среднее количество статей в день с течением времени . Мне также нужна информация о фактическом количестве статей со вчерашнего дня .
Идея состоит в том, чтобы иметь агрегированное представление обо всех наших транзакциях и иметь что-то, что может указывать на то, что что-то не так (что мы, например, отправляем 20% меньше статей, чем в среднем).
Моя идея состоит в том, чтобы вчерашние данные перемещались в SSAS каждую ночь и там хранили агрегированное значение количества транзакций и фактическое количество транзакций из вчерашних данных. Использование SSAS, как мы надеемся, ускорит отчеты.
Как вы думаете, это правильная идея? Должен ли я пропустить SSAS и иметь отчеты прямо на необработанных данных? Я знаю, как использовать службы reporting services для необработанных данных с использованием стандартных запросов SQL, но как это изменится при запросе SSAS? Я не знаю , с чего начать ..?
Хорошая вещь с SSAS заключается в том, что вы можете получить те индикаторы, о которых вы говорите, довольно легко либо путем создания вычисленных мер, либо с помощью KPIs.
Я начал с предоставления бизнес-аналитики с Microsoft SQL Server 2005 . У него было хорошее введение, но, к сожалению, оно слишком многословно, когда речь заходит о деталях. Но если вы хотите понять SSAS, OLAP и отчетность, используя эту структуру, это хорошее начало.
У Моши Пасуманского есть блог на SSAS и MDX с отличными ссылками .
Кроме того, я бы рекомендовал онлайн-книги Microsofts.
SSAS-это инструмент ETL . В основном вы получаете данные откуда-то (ваши исходящие статьи), делаете что-то с ним (агрегат) и помещаете его где-то еще (ваша таблица агрегатов, хранилище данных и т. д.). Проверьте ссылку для получения подробной информации.
Вы, вероятно, не будете хранить все строки в DB бесконечно, и если вы хотите иметь возможность сообщать о более длинных тенденциях, вам нужно в любом случае выполнить какую-то агрегацию исторических данных. Поэтому использование этого хранилища исторических данных в качестве источника отчетов имеет смысл. Затем вы можете использовать его для создания всевозможных причудливых отчетов.
TL; DR: определите свою сводную таблицу истории с учетом ваших будущих потребностей в отчетности. Используйте SSAS для заполнения таблицы и обновления ее из ежедневных обновлений. Отчет из этой таблицы. Дальнейшее чтение: Звездные схемы и хранилища данных.
@Riri может быть, SSAS-это перебор для ситуации, которую вы представили. Если вам нужно только ежедневно заполнять таблицы сумаризации, вы можете выполнить это, создав обычный сервер JOB in SQL и выполнив его в обычном скрипте T-SQL.
Я использовал этот подход в течение нескольких лет в ежедневном процессе для расчета бизнес-показателей из примерно 9 ГБ новых данных в день. Это работает, это быстро, это просто, и он использует технологию, к которой вы уже привыкли. Если ваш ежедневный процесс становится более сложным (он должен читать из файлов, использовать FTP, отправлять электронные письма), вы можете перейти к пакету SSIS (или любому другому инструменту ETL, который вам нравится), но я не могу рекомендовать использовать SSAS, если вам не нужно предоставить пользователям возможности OLAP.