Агрегат — это тип сводки, используемый в размерных моделях хранилищ данных для сокращения времени, необходимого для предоставления ответов на типичные запросы по большим наборам данных . Причина, по которой агрегаты могут так резко повысить производительность хранилища данных, заключается в сокращении количества строк, к которым необходимо получить доступ при ответе на запрос. [1]
В своей простейшей форме агрегат представляет собой простую сводную таблицу, которая может быть получена путем выполнения запроса Group by SQL. Более распространенное использование агрегатов — взять измерение и изменить его гранулярность. При изменении гранулярности измерения таблица фактов должна быть частично суммирована, чтобы соответствовать новой гранулярности нового измерения , тем самым создавая новые размерные и фактографические таблицы, чтобы соответствовать этому новому уровню гранулярности.
Агрегаты иногда называют предварительно рассчитанными сводными данными, поскольку агрегации обычно представляют собой предварительно рассчитанные, частично суммированные данные, которые хранятся в новых агрегированных таблицах. Когда факты агрегируются, это делается либо путем устранения размерности, либо путем связывания фактов со свернутым измерением. Свернутые измерения должны быть сжатыми версиями измерений, связанных с гранулярными базовыми фактами. Таким образом, агрегированные таблицы измерений должны соответствовать таблицам базовых измерений. [2]
В 1996 году Ральф Кимбалл , которого по праву считают одним из первых архитекторов хранилищ данных, заявил: [3]
Единственный наиболее радикальный способ повлиять на производительность в большом хранилище данных — предоставить правильный набор агрегированных (сводных) записей, которые сосуществуют с первичными базовыми записями. Агрегаты могут иметь очень существенное влияние на производительность, в некоторых случаях ускоряя запросы в сто или даже тысячу раз. Не существует других способов получить столь впечатляющий прирост.
Наличие агрегатов и атомарных данных увеличивает сложность размерной модели. Эта сложность должна быть прозрачной для пользователей хранилища данных, поэтому при выполнении запроса хранилище данных должно возвращать данные из таблицы с правильной степенью детализации. Поэтому при выполнении запросов к хранилищу данных должна быть реализована функциональность навигатора агрегатов, чтобы помочь определить правильную таблицу с правильной степенью детализации. Количество возможных агрегаций определяется каждой возможной комбинацией детализации измерений. Поскольку для построения всех возможных агрегаций потребовалось бы много накладных расходов, хорошей идеей будет выбрать подмножество таблиц, на основе которых будут создаваться агрегации. Лучший способ выбрать это подмножество и решить, какие агрегации строить, — это отслеживать запросы и проектировать агрегации для соответствия шаблонам запросов. [4]
Наличие агрегированных данных в размерной модели делает среду более сложной. Чтобы сделать эту дополнительную сложность прозрачной для пользователя, функционал, известный как агрегатная навигация, используется для запроса размерных и фактологических таблиц с правильным уровнем зернистости. Агрегатная навигация по сути проверяет запрос, чтобы увидеть, можно ли на него ответить, используя меньшую агрегатную таблицу. [5]
Реализации агрегатных навигаторов можно найти в ряде технологий:
Обычно рекомендуется использовать любую из первых трех технологий, поскольку преимущества в последнем случае ограничиваются одним интерфейсным инструментом BI [6]