Агрегирование данных - ежедневный SQL-скрипт против хранилища данных

Question

Простите, если об этом уже спрашивали (я очень мало знаю о хранилище данных / BI и еще не освоил ключевые слова).

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

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

В течение дня мой скрипт будет запущен, и я смогу использовать powerpivot для этой новой таблицы,Все это, оставаясь там, где мне удобно: обычный старый SQL.

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

NB. Производимые отчеты обычно связаны с другой базой данных для получения более значимой информации.Задача, которая очень хорошо выполнена Powerpivot.

Answer 1

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

Учитывая, что вы проявили интерес к подходу таблиц измерений / фактов к хранилищу данных, канонические книги по этому подходуобычно считается:

• Набор инструментов хранилища данных (Кимбалл, Росс)
• Набор инструментов жизненного цикла хранилища дат (Кимбалл, Росс, Торнтуэйт, Манди, Беккер)

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

Реализация DWH может занять много времени, поэтому, возможно, стоит продолжить с вашимсуществующий подход, даже если вы решили построить DWH.

Answer 2

Хорошие новости: похоже, у вас уже есть хранилище данных. «Хранилище данных» - это очень общий термин, без реального формального определения - оно в значительной степени означает то, что вы хотите.

Общепринятые характеристики:

• Хранилища данных не работают на оперативных базах данных
• Схемы хранилищ данных оптимизированы для запросов, а не для соответствия "нормальной форме"
• Хранилища данных заполняются процедурами «Извлечение, преобразование, загрузка» (ETL).

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

Answer 3

Наиболее эффективными являются простые решения, которые соответствуют существующим потребностям и соответствуют имеющимся наборам навыков.

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