Как стать автором
Обновить

Комментарии 21

я только сейчас понял что тело «оборачивается переменными».
с нетерпением жду продолжения
Жаль что данные случайны — думаю многим было бы интересно пOLAPать реальную статистику Хабра.
да. был бы признателен за реальный пример.
у меня просто есть данные вида
дата — дата — дата — факт — факт — факт…
работаю сводными таблицами… но очень хочется увидить все это в OLAPe как оно и с чем едят.
и кстати плусующим… помогите человеку перенести из SQL в OLAP.
«дата — дата — дата — факт — факт — факт» — это как? OLAP — это тип информационных систем. SQL — язык такой. OLAP система вполне может выполнять sql- запросы.
Спасибо! Интересно.
Жду продолжения...)
Ипическая сила! Вот это круто! Спасибо большое.
интересно продолжение… если окажется реально удобным надо будет переписать сбор статистики на проекте :)
Очередной раз спасибо за просвещение… теперь хоть в вики заглянул чтобы посмотреть что такое OLAP
хорошая статья, кратко и понятно
только я бы по больше раскрыл суть измерений, в частности, иерархические, так как в основном то они и используются
Иерархии полностью раскроются во время построения куба, хотя таблица DimTime уже сейчас «приоткрывает» нам конечный вид иерархии времени (год->месяц->день). Дальше — круче!
Звезда, снежинка — все это забавно, конечно =)
Но заметьте, ведь строить таким образом многомерные кубы в системе, в которой количество измерений заранее в принципе неизвестно, непреемлемо. Это не есть хороший метод, ИМХО.
Да и, думаю, вообще неинтересно и уныло использовать такие методы. Я хочу сказать, что много лучше было бы строить кубы на основе метаданных измерений, количество которых может быть произвольным, без использования таблицы для каждого измерения. А данные банально храняться в одной таблице, к которой обращаемся с помощью сгенерированных на основе взаимного расположения измерений и выбранных в них элементах SQL запросов.
И при каждом запросе субд выполняет full scan одной большой таблицы?
Забегая наперед, скажу, что, как минимум, начиная с Analysis Services 2005 — это стало возможно. Другое дело, что не зная наперед о структуре ваших данных, куб не сможет преагрегировать значения, а также вы не сможете эфективно использовать кэш сервера. В результате, если построить куб на чисто «виртуальных» метаданных, то выгоды в скорости запросов будут совсем небольшие (для небольших измерений) или их совсем не будет (если размеры измерений превосходят 2-3 миллиона записей). Но, я часто вижу использование подобных «виртуальных» измерений на продакшн системах, особенно для маленьких, динамических измерений (порядка 10-100 членов).
Как я понял, из реальной базы данных при помощи представлений можно сделать «звезду» или «снежинку». Но насколько этот подход рационален?
Смотря с какой стороны посмотреть. Это, однозначно, экономит вам дисковое пространство, но лимитирует вас в гибкости и скорости загрузки данных в куб. Например, если вам нужно каким-то хитрым образом «очистить» данные перед загрузкой, ваше представление может не справится с задачей. Или если само представление будет очень сложным с точки зрения запроса, загрузка данных в куб будет занимать много времени.
Еще как аргумент — очень часто данные в куб берутся из нескольких источников, что делает невозможным использование только представлений.
Бывает так, что к «Реально базе данных» вообще не подобраться. Например DBA какого нибудь ораклового сервера, где АБС-ка крутиться вам просто не разрешит создавать на реальной базе свои вьюшки и вообще выполнять какие-либо запросы. Мало ли чё вы там сджойните и как, а потом банк не сможет целый день работать. В таком случае можнл выгружать новые данные в плоские файлы, а оттуда забирать в хранилище.
все эти советы, зачем строить звезду снежинку, из разряда как поменьше работать не думаю о перформансе
метаданные=тормознутось
в этом и есть задача толкового разработчика — проектирование красивой схемы, а не драгэнддроп и тыканье мышкой
Я честно говоря тоже не понял смысла сферического коня в вакууме — где же здесь куб.

Представляю, как быстро ляжет сервак, если данные о голосовании сделать из трех таблиц включая отдельную таблицу для таймстампа на 8 полей. Жесть!
Реально отдельная «таблица для timestampa» сильно сокращает нагрузку на сервер. А куб на картинке хорошо просматривается.
Перезалейте изображения, пожалуйста.
Картинки не отображаются
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Публикации

Истории