Vasha zadacha otnositsya k klassike DWH/OLAP, a imenno razlichanya granulyarnost fakticheskih i planovih dannih.

Vstrechnii vopros - kogda vi smotrite Plan/Fact, vas interesuet granulyarnost po dokumentam, ili vas interesuyut toko dogovora, tak kak tolko po nim imeyutsya planovie dannie?


Esli vas interesuet tolko dannie s urovnya "dogovor", to rasskazhu kak ya delal, tolko u menya bila situaciya mecyac - den. Plan pomyasyachno, a fact s detalizaciei do dnya.

Raaskazhu kak ya delal:
1) Reshenie na urovne OLAP. Kub Plan, Kub Fact - svodish v virtualnom kube (Mne eto chestno ne ponravilos, u hotya zhisnesposobnoe reshenie.

2) Reshenie na urovne DWH. Predagreggiruem facticheskie dannie do urovnya Dogovora v SQL-Servere i v tablicu factov Plan/Fact gruzim i planovie i facticheskie pokazateli s urovnem granulyarnosti "Dogovor". Ya predpochel eto reshenie, kotoroe bolee prosto s tochki zreniya designa kubov i proizvoditelneee na bolshih ob'emah dannih, hotya kak nedostatok - nevozmozhen pryamoi drill-down do urovnya fakticheskih dokumentov. No v moei zadache eto bilo ne vazhno, a vazhno li eto dlya vas?

A vam nikto i ne sovetuet pihat v odnu tablicu dannie raznoi granulyarnosti.

To Tulenev

Prosyaded, esche kak prosyadet.

To Tulenev

вот только интересно - это недостаток конкретных продуктов или самой модели данных

Eto vopros ochen filosofskii - skolko lydei, stolko i menni.

Esli predpolozhit, chto crossjoin - nedostatok produkta MS AS, to nazovite produkt, kotoromu eto sovsem ne pomeha?

est v MS AS gorazdo bolee proizvoditelnii i menee prozhorlivii v otnoshenii pamyati NonEmptyCrossJoin, no i on obladaet ogranicheniyami, tak chto i s nim mozhno popast v situaciyu, chto budete "zhat na pedal gaza, ne snyavshis s ruchnika" :-)

To Sutasu:

Podtverzhdayu slova Juriya pro Parent-Child izmereniya primenitelno k MS AS. Nachinaya s neskolkih desyatkov tisyach, yabi skazal chto uzhe s 10k vi poluchite oschutimie problemi s etim vidom izmereniya po sravneniyu s "normalnim" izmereniem.