PlanB,

если в двух словах то есть 2 термина
- факты
- агрегаты

факт это некий показатель на самом нижнем уровне. Например если представить себе торговую сеть сеть факт это продажа одного товара в одном чеке.

агрегат - это суммарные продажи чека/дня/магазина/года/филиала etc.

Теперь представь есть сеть 10000 магазинов, с историей продаж 10000 дней в каждом магазине в день 1000 чеков.

Если тебе нужно будет сформировать объем продаж всей сети за всю историю требуется просуммировать 10000*10000*1000*(количество товаров в чеке) фактов. Что очень долго.

OLAP куб это некая база, которая хранит в себе агрегаты на любом уровне, который ты можешь запросить. Т.е. продажи всей компании за всю историю или в разбивке по магазинам при обращении к кубу будут хранится, а не суммироваться на лету. В этом преимущество - скорость.

Хотя многие архитекторы СУБД сразу создают агрегаты в таблице. Но для экономии места и времени расчета агрегатов они собирают не все факты в агрегаты, а только наиболее часто используемые. Например агрегат продажи помесячные или общий оборот магазина. Таким образом ОЛАП куб это просто раздутая СУБД где посчитаны ВСЕ агрегаты.

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