Acasă › DE › Ce este olap cube în excel. Crearea unui proiect SSAS. Ce este analiza și de ce este necesară?

Ce este olap cube în excel. Crearea unui proiect SSAS. Ce este analiza și de ce este necesară?

Sistemele informatice ale unei întreprinderi serioase, de regulă, conțin aplicații concepute pentru analiza complexă a datelor, dinamica acestora, tendințele etc. În consecință, managementul de vârf devine principalii consumatori ai rezultatelor analizei. O astfel de analiză este în cele din urmă menită să sprijine luarea deciziilor. Iar pentru a lua orice decizie de management este nevoie de informatiile necesare, de obicei cantitative. Pentru a face acest lucru, este necesar să colectați aceste date de la toți sisteme de informareîntreprinderi, aduceți-le într-un format comun și apoi analizați-le. În acest scop, sunt create Depozite de date.

Ce este un depozit de date?

De obicei - locul unde sunt colectate toate informațiile cu valoare analitică. Cerințele pentru astfel de magazine corespund definiției clasice a OLAP și vor fi explicate mai jos.

Uneori, Warehouse are un alt scop - integrarea tuturor datelor companiei, pentru a menține integritatea și relevanța informațiilor în cadrul tuturor sistemelor informaționale. Acea. depozitul acumulează nu numai informații analitice, ci aproape toate informațiile și le poate furniza sub formă de directoare înapoi către alte sisteme.

Un depozit de date tipic este de obicei diferit de o bază de date relațională tipică. În primul rând, bazele de date obișnuite sunt concepute pentru a ajuta utilizatorii să efectueze munca de zi cu zi, în timp ce depozitele de date sunt concepute pentru a lua decizii. De exemplu, vânzarea mărfurilor și emiterea facturilor se realizează folosind o bază de date concepută pentru procesarea tranzacțiilor, iar analiza dinamicii vânzărilor pe mai mulți ani, care permite planificarea lucrului cu furnizorii, se realizează cu ajutorul unui depozit de date.

În al doilea rând, în timp ce bazele de date tradiționale sunt supuse unor schimbări constante pe măsură ce utilizatorii lucrează, depozitul de date este relativ stabil: datele din acesta sunt de obicei actualizate conform unui program (de exemplu, săptămânal, zilnic sau orar, în funcție de nevoi). În mod ideal, procesul de îmbogățire este pur și simplu adăugarea de date noi într-o perioadă de timp, fără a modifica informațiile anterioare aflate deja în depozit.

Și în al treilea rând, bazele de date obișnuite sunt cel mai adesea sursa de date care ajung în depozit. În plus, depozitul poate fi completat prin surse externe, de exemplu rapoarte statistice.

Cum se construiește un depozit?

ETL– concept de bază: trei etape:

Extracție – extragerea datelor din surse externe într-un format ușor de înțeles;
Transformare – transformarea structurii datelor sursă în structuri convenabile pentru construirea unui sistem analitic;

Să mai adăugăm o etapă - curățarea datelor ( Curatenie) – procesul de filtrare a datelor irelevante sau de corectare a datelor eronate pe baza metodelor statistice sau expertizate. Pentru a nu genera mai târziu rapoarte precum „Vânzări pentru 20011”.

Să revenim la analiză.

Ce este analiza și de ce este necesară?

Analiza este studiul datelor în scopul luării deciziilor. Sistemele analitice se numesc sisteme suport de decizie ( DSS).

Aici merită să subliniem diferența dintre lucrul cu DSS și un set simplu de rapoarte reglementate și nereglementate. Analiza în DSS este aproape întotdeauna interactivă și iterativă. Acestea. analistul cercetează datele, compunând și ajustând interogări analitice și primește rapoarte, a căror structură poate fi necunoscută în prealabil. Vom reveni la aceasta mai detaliat mai jos când discutăm limbajul de interogare. MDX.

OLAP

Sistemele de sprijin pentru decizii au de obicei mijloacele de a furniza utilizatorului date agregate pentru diverse mostre din setul original într-o formă convenabilă pentru percepție și analiză (tabele, diagrame etc.). Abordarea tradițională a segmentării datelor sursă implică extragerea din datele sursă a unuia sau mai multor seturi de date multidimensionale (numite adesea hipercub sau metacub), ale căror axe conțin atribute, iar celulele conțin date cantitative agregate. (Astfel de date pot fi stocate și în tabele relaționale, dar în acest caz vorbim despre organizarea logică a datelor, și nu despre implementarea fizică a stocării acestora.) De-a lungul fiecărei axe, atributele pot fi organizate sub formă de ierarhii, reprezentând diferite niveluri de detaliu a acestora. Datorită acestui model de date, utilizatorii pot formula interogări complexe, pot genera rapoarte și pot obține subseturi de date.

Tehnologia pentru analiza complexă a datelor multidimensionale se numește OLAP (On-Line Analytical Processing). OLAP este o componentă cheie a depozitării tradiționale de date. Conceptul de OLAP a fost descris în 1993 de Edgar Codd, un renumit cercetător de baze de date și autor al modelului de date relaționale. În 1995, pe baza cerințelor stabilite de Codd, a fost formulat așa-numitul test FASMI (Fast Analysis of Shared Multidimensional Information), incluzând următoarele cerințe pentru aplicațiile de analiză multidimensională:

furnizarea utilizatorului de rezultate de analiză într-un timp acceptabil (de obicei nu mai mult de 5 s), chiar și cu prețul unei analize mai puțin detaliate;
capacitatea de a efectua orice analiză logică și statistică caracteristică aceasta aplicație, și salvarea acestuia într-o formă accesibilă utilizatorului final;
acces multi-utilizator la date cu suport pentru mecanisme de blocare adecvate si mijloace de acces autorizate;
reprezentarea conceptuală multidimensională a datelor, inclusiv sprijin deplin pentru ierarhii și ierarhii multiple (aceasta este o cerință cheie a OLAP);
capacitatea de a accesa orice informație necesară, indiferent de volumul și locația de stocare.

Trebuie remarcat faptul că funcționalitatea OLAP poate fi implementată căi diferite, începând cu cele mai simple instrumente de analiză a datelor din aplicațiile de birou și terminând cu sisteme analitice distribuite bazate pe produse server. Acestea. OLAP nu este o tehnologie, dar ideologie.

Înainte de a vorbi despre diferitele implementări OLAP, să aruncăm o privire mai atentă la ce sunt cuburile din punct de vedere logic.

Concepte multidimensionale

Vom folosi baza de date Northwind inclusă cu Microsoft pentru a ilustra principiile OLAP. SQL Serverși care este o bază de date tipică care stochează informații despre operațiunile comerciale ale unei companii angajate în furnizarea cu ridicata de alimente. Aceste date includ informații despre furnizori, clienți, o listă de bunuri furnizate și categoriile acestora, date despre comenzi și bunuri comandate, o listă a angajaților companiei.

cub

Să luăm de exemplu tabelul Facturi1, care conține comenzile companiei. Câmpurile din acest tabel vor fi după cum urmează:

Data comandă
O tara
Oraș
Numele clientului
Companie de livrări
numele produsului
Cantitatea de mărfuri
Pretul comenzii

Ce date agregate putem obține din acest punct de vedere? De obicei, acestea sunt răspunsuri la întrebări precum:

Care este valoarea totală a comenzilor plasate de clienți dintr-o anumită țară?
Care este valoarea totală a comenzilor plasate de clienți într-o anumită țară și livrate de o anumită companie?
Care este valoarea totală a comenzilor plasate de clienți într-o anumită țară într-un anumit an și livrate de o anumită companie?

Toate aceste date pot fi obținute din acest tabel folosind interogări SQL destul de evidente cu grupare.

Rezultatul acestei interogări va fi întotdeauna o coloană de numere și o listă de atribute care o descriu (de exemplu, țara) - acesta este un set de date unidimensional sau, în limbaj matematic, un vector.

Să ne imaginăm că trebuie să obținem informații despre costul total al comenzilor din toate țările și distribuția acestora între companiile de livrare - vom obține un tabel (matrice) de numere, unde companiile de livrare vor fi enumerate în titlurile coloanei, țările pe rând titluri, iar în celule va exista o cantitate de comenzi. Acesta este un tablou de date bidimensional. Acest set de date se numește tabel pivot ( masă rotativă) sau tabel încrucișat.

Dacă vrem să obținem aceleași date, dar și pe an, atunci va apărea o altă modificare, adică. setul de date va deveni tridimensional (un tensor condiționat de ordinul 3 sau un „cub”) tridimensional.

Evident, numărul maxim de dimensiuni este numărul tuturor atributelor (Data, Țara, Client, etc.) care descriu datele noastre agregate (cantitatea de comenzi, numărul de produse etc.).

Așa ajungem la conceptul de multidimensionalitate și întruchiparea lui - cub multidimensional. Vom numi o astfel de masă „ tabel de fapte" Dimensiuni sau axe cuburilor ( dimensiuni) sunt atribute ale căror coordonate sunt exprimate prin valorile individuale ale acestor atribute prezente în tabelul de fapte. Acestea. de exemplu, dacă informațiile despre comenzi au fost menținute în sistem din 2003 până în 2010, atunci axa din acest an va consta din 8 puncte corespunzătoare. Dacă comenzile vin din trei țări, atunci axa țării va conține 3 puncte etc. Indiferent de câte țări sunt incluse în directorul de țări. Punctele de pe o axă sunt numite „membrii” ei ( Membrii).

În acest caz, datele agregate în sine vor fi numite „măsuri” ( Măsura). Pentru a evita confuzia cu „dimensiunile”, acestea din urmă sunt de preferință numite „axe”. Setul de măsuri formează o altă axă „Măsuri” ( Măsuri). Are atâția membri (puncte) câte măsuri (coloane agregate) există în tabelul de fapte.

Membrii dimensiunilor sau axelor pot fi combinați prin una sau mai multe ierarhii ( ierarhie). Să explicăm ce este ierarhia cu un exemplu: orașele din ordine pot fi unite în districte, districte în regiuni, regiuni ale unei țări, țări în continente sau alte entități. Acestea. există o structură ierarhică - continent- tara-regiune-raion-oras– 5 niveluri ( Nivel). Pentru o regiune, datele sunt agregate pentru toate orașele care sunt incluse în aceasta. Pentru o regiune din toate districtele care conțin toate orașele etc. De ce avem nevoie de mai multe ierarhii? De exemplu, pe axa datei comenzii putem dori să grupăm punctele (adică zile) într-o ierarhie An lună zi sau prin An-Săptămâna-Ziu: în ambele cazuri există trei niveluri. Evident, Săptămâna și Luna grupează zilele diferit. Există și ierarhii, numărul de niveluri în care nu este determinist și depinde de date. De exemplu, folderele de pe un disc de computer.

Agregarea datelor poate avea loc folosind mai multe funcții standard: sumă, minim, maxim, medie, numărare.

MDX

Să trecem la limbajul de interogare în date multidimensionale.
Limbajul SQL a fost conceput inițial nu pentru programatori, ci pentru analiști (și, prin urmare, are o sintaxă care seamănă cu limbajul natural). Dar cu timpul a devenit din ce în ce mai complicat și acum puțini analiști știu să-l folosească bine, dacă este deloc. A devenit un instrument pentru programatori. Limbajul de interogări MDX, despre care se zvonește că ar fi fost dezvoltat de fostul nostru compatriot Mosha (sau Mosha) Posumansky în sălbăticia Microsoft, a fost inițial destinat să se adreseze analiștilor, dar conceptele și sintaxa sa (care amintește vag de SQL și complet în zadar, adică pentru că doar încurcă), chiar mai complicat decât SQL. Cu toate acestea, elementele de bază sunt încă ușor de înțeles.

O vom analiza în detaliu deoarece este singura limbă care a primit statutul standard în cadrul standardului general de protocol XMLA și, în al doilea rând, pentru că există o implementare open-source a acestuia sub forma proiectului Mondrian de la companie. Pentaho. Alte sisteme de analiză OLAP (de exemplu, Oracle OLAP Option) folosesc de obicei propriile extensii ale sintaxei SQL, cu toate acestea, declară și suport pentru MDX.

Lucrul cu seturi de date analitice înseamnă doar să le citești și nu înseamnă să le scrii. Acea. MDX nu are clauze pentru modificarea datelor, ci doar o clauză de selecție - select.

În OLAP puteți face cuburi multidimensionale felii– adică când datele sunt filtrate de-a lungul uneia sau mai multor axe sau proiecții– când cubul „se prăbușește” de-a lungul uneia sau mai multor axe, agregând date. De exemplu, primul nostru exemplu cu cantitatea de comenzi din țări este o proiecție a cubului pe axa Țară. Interogarea MDX pentru acest caz va arăta astfel:

Selectați...Copii pe rânduri din
Ce este aici?

Selectați– cuvântul cheie este inclus în sintaxă numai pentru frumusețe.
este numele axei. Toate numele proprii în MDX sunt scrise între paranteze drepte.
este numele ierarhiei. În cazul nostru, aceasta este ierarhia Țară-Oraș
– acesta este numele membrului axei de la primul nivel al ierarhiei (adică țara) Toate – acesta este un meta-membru care unește toți membrii axei. Există un astfel de meta-termen în fiecare axă. De exemplu, în axa anului există „Toți anii”, etc.
Copii este o funcție de membru. Fiecare membru are mai multe funcții disponibile. Cum ar fi Parent. Nivel, Ierarhie, revenind respectiv strămoșul, nivelul din ierarhie și ierarhia însăși căreia îi aparține membrul în acest caz. Copii - Returnează un set de membri copii ai acestui membru. Acestea. în cazul nostru – țări.
pe rânduri– Indică modul de aranjare a acestor date în tabelul rezultat. În acest caz - în antetul liniilor. Valori posibile aici: pe coloane, pe pagini, pe paragrafe etc. De asemenea, este posibil să indicați pur și simplu prin index, începând de la 0.
din– aceasta este o indicație a cubului din care se face selecția.

Dacă nu avem nevoie de toate țările, ci doar de câteva anumite țări? Pentru a face acest lucru, putem specifica în mod explicit în cerere țările de care avem nevoie, în loc să selectăm totul folosind funcția Copii.

Selectați ( ..., ... ) pe rândurile din
Acoladele în acest caz sunt declarația setului ( A stabilit). Un set este o listă, o enumerare a membrilor dintr-o axă.

Acum să scriem o interogare pentru cel de-al doilea exemplu – rezultat în contextul unei persoane de livrare:

Selectați ...Copii pe rânduri .Membri pe coloane din
Adăugat aici:
– axa;
.Membri– o funcție de axă care returnează toți termenii de pe ea. Ierarhia și nivelul au aceeași funcție. Deoarece Există o singură ierarhie în această axă, atunci indicarea ei poate fi omisă, deoarece nivelul și ierarhia sunt, de asemenea, aceleași, atunci puteți afișa toți membrii într-o singură listă.

Cred că este deja evident cum putem continua acest lucru cu al treilea exemplu cu detalii de la an. Dar haideți mai bine să nu detaliem pe an, ci să filtram - de exemplu. construi o felie Pentru a face acest lucru, vom scrie următoarea interogare:

Selectați ..Copii pe rânduri .Membri pe coloane de unde (.)
Unde este filtrarea aici?

Unde- cuvânt cheie
este un membru al ierarhiei . Numele complet, inclusiv toți termenii, ar fi: .. , ci pentru că Deoarece numele acestui membru este unic în cadrul axei, toate clarificările intermediare ale numelui pot fi omise.

De ce termenul de dată este între paranteze? Parantezele sunt un tuplu ( tuplu). Un tuplu este una sau mai multe coordonate de-a lungul variat topoare De exemplu, pentru a filtra de-a lungul a două axe simultan, în paranteze enumerăm doi termeni din diferit măsurători separate prin virgule. Adică, tuplul definește o „felie” a cubului (sau „filtrare”, dacă o astfel de terminologie este mai apropiată).

Tuplul este folosit pentru mai mult decât pentru filtrare. Tuplurile pot fi, de asemenea, în anteturile de rând/coloană/pagină etc.

Acest lucru este necesar, de exemplu, pentru a afișa rezultatul unei interogări tridimensionale într-un tabel bidimensional.

Selectați combinarea încrucișată(...Copii, ..Copii) pe rânduri .Membri pe coloane de unde (.)
Unire încrucișată este o funcție. Returnează un set de tupluri (da, o mulțime poate conține tupluri!) rezultat din produsul cartezian a două mulțimi. Acestea. setul rezultat va conține toate combinațiile posibile de țări și ani. Antetele rândurilor vor conține astfel o pereche de valori: Țara-An.

Întrebarea este, unde este indicația ce caracteristici numerice ar trebui să fie afișate? În acest caz, se utilizează măsura implicită definită pentru acest cub, adică. Pretul comenzii. Dacă vrem să derivăm o altă măsură, atunci ne amintim că măsurile sunt membrii unei dimensiuni Măsuri. Și acționăm exact în același mod ca și cu celelalte axe. Acestea. filtrarea unei interogări după una dintre măsuri va afișa exact această măsură în celule.

Întrebare: Care este diferența dintre filtrarea în unde și filtrarea prin specificarea membrilor axei pe rânduri. Răspuns: practic nimic. Pur și simplu acolo unde este indicată o felie pentru acele axe care nu participă la formarea titlurilor. Acestea. aceeași axă nu poti fi prezent în același timp pe rânduri, si in Unde.

Membrii calculati

Pentru mai mult interogări complexe Puteți declara membri calculati. Membrii atât ai axei de atribut, cât și ai axei de măsură. Acestea. Puteți declara, de exemplu, o nouă măsură care va afișa contribuția fiecărei țări la suma totală de comenzi:

Cu membru. ca '.CurrentMember / ..', FORMAT_STRING='0,00%' selectați ...Copii pe rânduri de unde .
Calculul are loc în contextul unei celule în care sunt cunoscute toate atributele de coordonate ale acesteia. Coordonatele (membrii) corespunzătoare pot fi obținute prin funcția CurrentMember pentru fiecare dintre axele cubului. Aici trebuie să înțelegem că expresia .Membru Actual/..’ nu împarte un termen cu altul, ci împarte date agregate relevante felii cuburi! Acestea. felia pentru teritoriul actual va fi împărțită într-o felie pentru toate teritoriile, i.e. valoarea totală a tuturor comenzilor. FORMAT_STRING – setează formatul pentru afișarea valorilor, de ex. %.

Un alt exemplu de membru calculat, dar pe axa anilor:

Cu membru. la fel de '. - .’
Evident, raportul nu va conține o unitate, ci diferența secțiunilor corespunzătoare, i.e. diferența în cantitatea comenzilor în acești doi ani.

Afișare în ROLAP

Sistemele OLAP se bazează într-un fel sau altul pe un fel de sistem de stocare și organizare a datelor. Când despre care vorbim despre RDBMS, apoi vorbesc despre ROLAP (vom lăsa MOLAP și HOLAP pentru auto-studiu). ROLAP – OLAP pe o bază de date relațională, de ex. descrise sub forma unor tabele bidimensionale obișnuite. Sistemele ROLAP convertesc interogările MDX în SQL. Principala problemă de calcul pentru baze de date este agregarea rapidă. Pentru a agrega mai rapid, datele din baza de date sunt de obicei foarte denormalizate, de exemplu. nu sunt stocate foarte eficient în ceea ce privește spațiul pe disc ocupat și monitorizarea integrității bazei de date. În plus, conțin tabele auxiliare care stochează date parțial agregate. Prin urmare, pentru OLAP, de obicei este creată o schemă de bază de date separată, care reproduce doar parțial structura bazelor de date tranzacționale originale în ceea ce privește directoarele.

Navigare

Multe sisteme OLAP oferă instrumente de navigare interactive pentru o interogare deja generată (și datele selectate în consecință). În acest caz, se folosește așa-numita „găurire” sau „găurire”. O traducere mai adecvată în rusă ar fi cuvântul „aprofundare”. Dar aceasta este o chestiune de gust, în unele medii cuvântul „foraj” s-a blocat.

Burghiu– acesta este detalierea raportului prin reducerea gradului de agregare a datelor, combinată cu filtrarea de-a lungul unei alte axe (sau mai multor axe). Există mai multe tipuri de foraj:

drill-down– filtrarea de-a lungul uneia dintre axele sursă ale raportului cu afișarea informațiilor detaliate despre descendenți din ierarhia membrului de filtrare selectat. De exemplu, dacă există un raport privind distribuția comenzilor defalcate pe țări și ani, atunci făcând clic pe anul 2007 se va afișa un raport defalcat pe aceleași țări și luni ale anului 2007.
partea de foraj– filtrarea sub una sau mai multe axe selectate și eliminarea agregării de-a lungul uneia sau mai multor alte axe. De exemplu, dacă există un raport privind distribuția comenzilor defalcate pe țări și ani, atunci făcând clic pe anul 2007 se va afișa un alt raport defalcat, de exemplu, pe țări și furnizori cu filtrare până în 2007.
jgheab de foraj– eliminarea agregării de-a lungul tuturor axelor și filtrarea simultană de-a lungul acestora – vă permite să vedeți datele sursă din tabelul de fapte din care a fost obținută valoarea din raport. Acestea. Când faceți clic pe valoarea unei celule, este afișat un raport cu toate comenzile care au oferit această sumă. Un fel de găurire instantanee chiar în „adâncimea” cubului.

Asta e tot. Acum, dacă decideți să vă dedicați Business Intelligence și OLAP, este timpul să începeți să citiți literatură serioasă.

Etichete: Adăugați etichete

Sunt locuitor în Habr de ceva vreme, dar nu am citit niciodată articole pe tema cuburilor multidimensionale, OLAP și MDX, deși subiectul este foarte interesant și devine din ce în ce mai relevant pe zi ce trece.
Nu este un secret pentru nimeni că în acea perioadă scurtă de dezvoltare a bazelor de date, contabilității electronice și sistemelor online, s-au acumulat o mulțime de date în sine. Acum, o analiză completă a arhivelor și, probabil, o încercare de a prezice situații pentru modele similare în viitor, este, de asemenea, de interes.
Pe de altă parte, companiile mari, chiar și pe parcursul mai multor ani, luni sau chiar săptămâni, pot acumula cantități atât de mari de date încât chiar și analiza lor de bază necesită abordări extraordinare și cerințe hardware stricte. Acestea ar putea fi sisteme de procesare a tranzacțiilor bancare, agenți de schimb, operatori de telefonie etc.
Cred că toată lumea cunoaște 2 abordări diferite ale proiectării bazelor de date: OLTP și OLAP. Prima abordare (Online Transaction Processing - procesarea tranzacțiilor în timp real) este concepută pentru colectarea eficientă a datelor în timp real, în timp ce a doua (Procesare analitică online - procesare analitică în timp real) vizează în mod specific eșantionarea și prelucrarea datelor în cel mai eficient mod. cale.

Să ne uităm la principalele capabilități ale cuburilor OLAP moderne și la ce probleme rezolvă (Serviciile de analiză 2005/2008 sunt luate ca bază):

acces rapid la date
preagregare
ierarhie
lucrul cu timpul
limbaj multidimensional de acces la date
KPI (Indicatori cheie de performanță)
minerit de date
cache pe mai multe niveluri
suport multilingv

Deci, să ne uităm puțin mai detaliat la capacitățile cuburilor OLAP.

Mai multe despre posibilități

Acces rapid la date
De fapt, accesul rapid la date, indiferent de dimensiunea matricei, este baza sistemelor OLAP. Deoarece acesta este punctul central, un depozit de date este de obicei construit pe principii diferite de cele ale bazelor de date relaționale.
Aici, timpul necesar pentru preluarea datelor simple este măsurat în fracțiuni de secundă, iar o interogare care depășește câteva secunde necesită cel mai probabil optimizare.

Preagregare
Pe lângă recuperarea rapidă a datelor existente, oferă și capacitatea de a preagrega valorile „cel mai probabil să fie utilizate”. De exemplu, dacă avem înregistrări zilnice ale vânzărilor unui anumit produs, sistemul Pot fi De asemenea, putem preagrega sumele de vânzări lunare și trimestriale, ceea ce înseamnă că dacă solicităm date lunar sau trimestrial, sistemul ne va oferi instantaneu rezultatul. De ce nu are loc întotdeauna pre-agregarea?Deoarece combinații teoretic posibile de bunuri/timp/etc. poate exista un număr mare, ceea ce înseamnă că trebuie să aveți reguli clare pentru ce elemente va fi construită agregarea și pentru care nu. În general, subiectul luării în considerare a acestor reguli și a designului real al agregărilor este destul de extins și merită un articol separat în sine.

Ierarhii
Este firesc ca atunci când se analizează datele și se elaborează rapoarte finale, trebuie să se țină cont de faptul că lunile constau în zile și ele însele formează sferturi, iar orașele sunt incluse în zone, care la rândul lor fac parte din regiuni sau țări. . Vestea bună este că cuburi OLAP inițial ei consideră datele din punctul de vedere al ierarhiilor și al relațiilor cu alți parametri ai aceleiași entități, așa că construirea și utilizarea ierarhiilor în cuburi este o chestiune foarte simplă.

Lucrul cu timpul
Deoarece analiza datelor are loc în principal în zone de timp, timpului i se acordă o importanță deosebită în sistemele OLAP, ceea ce înseamnă că prin simpla definire pentru sistemul unde avem timp aici, în viitor puteți utiliza cu ușurință funcții precum Anul până la data, Luna până la data ( perioada de la începutul anului/lunii până la data curentă), Perioada paralelă (în aceeași zi sau lună, dar anul trecut), etc.

Limbajul de acces la date multidimensional
MDX(Multidimensional Expressions) - un limbaj de interogare pentru acces simplu și eficient la structurile de date multidimensionale. Și asta spune totul – vor fi câteva exemple mai jos.

Indicatori cheie de performanță (KPI)
indicatori de performanta este un sistem de măsurare financiară și non-financiară care ajută o organizație să determine atingerea obiectivelor strategice. Indicatorii cheie de performanță pot fi definiți destul de simplu în sistemele OLAP și utilizați în rapoarte.

Data mineritului
Exploatarea datelor (Exploatarea datelor) - în esență, identificarea tiparelor ascunse sau a relațiilor dintre variabile în seturi mari de date.
Termenul englezesc „Data Mining” nu are o traducere clară în rusă (mining de date, minare de date, extragere de informații, extragere de date/informații), prin urmare, în majoritatea cazurilor, este folosit în original. Cea mai de succes traducere indirectă este termenul „data mining” (DMA). Cu toate acestea, acesta este un subiect separat, nu mai puțin interesant de luat în considerare.

Memorarea în cache pe mai multe niveluri
De fapt, pentru a asigura cea mai mare viteză de acces la date, pe lângă structurile de date și preagregările complicate, sistemele OLAP acceptă stocarea în cache pe mai multe niveluri. Pe lângă stocarea în cache a interogărilor simple, sunt stocate în cache și părți de date citite din magazin, valorile agregate și valorile calculate. Astfel, cu cât lucrați mai mult cu un cub OLAP, cu atât mai repede începe să funcționeze. Există, de asemenea, conceptul de „încălzire a memoriei cache” - o operație care pregătește sistemul OLAP pentru a lucra cu rapoarte specifice, interogări sau toate combinate.

Suport multilingv
Da da da. Cel puțin, Analysis Services 2005/2008 (deși Enterprise Edition) acceptă nativ multilingvismul. Este suficient să oferiți o traducere a parametrilor șir ai datelor dvs., iar clientul care și-a specificat limba va primi date localizate.

Cuburi multidimensionale

Deci, ce sunt exact aceste cuburi multidimensionale?
Să ne imaginăm un spațiu tridimensional ale cărui axe sunt Timpul, Produsele și Clienții.
Un punct într-un astfel de spațiu va indica faptul că unul dintre cumpărători a cumpărat un anumit produs într-o anumită lună.

De fapt, planul (sau setul tuturor acestor puncte) va fi cubul și, în consecință, Timpul, Produsele și Clienții vor fi dimensiunile acestuia.
Este puțin mai dificil să-ți imaginezi (și să desenezi) un cub cu patru dimensiuni sau mai multe, dar esența nu se schimbă și, cel mai important, pentru sistemele OLAP nu contează deloc în câte dimensiuni vei lucra (în limite rezonabile). limite, desigur).

Un pic de MDX

Deci, care este frumusețea MDX? Cel mai probabil, este că trebuie să descriem nu cum vrem să selectăm datele, ci Ce anume noi vrem.
De exemplu,

SELECTAȚI
( . ) PE COLONI,
( ., . ) PE RÂNDURI
DIN
UNDE (., .)

Ceea ce înseamnă că vreau numărul de iPhone-uri vândute în iunie și iulie în Mozambic.
În același timp, descriu care acestea sunt datele pe care le vreau și Cum Vreau să-i văd în raport.
Frumos, nu-i așa?

Iată un pic mai complicat:

CU MEMBRU Cheltuieli medii AS
. / .
SELECTAȚI
( Cheltuieli medii ) PE COLONI,
( .., .. ) PE RÂNDURI
DIN
UNDE(.)
* Acest cod sursă a fost evidențiat cu Sursa de evidențiere a codului.

De fapt, mai întâi determinăm formula pentru calcularea „dimensiunii medii de achiziție” și încercăm să comparăm cine (ce sex) cheltuiește mai mulți bani într-o singură vizită la magazinul Apple.

Limba în sine este extrem de interesantă atât de studiat, cât și de folosit și poate că merită multă discuție.

Concluzie

De fapt, acest articol acoperă foarte puțin, chiar și conceptele de bază; l-aș numi „aperitiv” - o oportunitate de a interesa comunitatea Habra în acest subiect și de a-l dezvolta în continuare. În ceea ce privește dezvoltarea, aici este un câmp imens nearat și voi răspunde cu plăcere la toate întrebările dumneavoastră.

P.S. Aceasta este prima mea postare despre OLAP și prima publicație despre Habré - aș fi foarte recunoscător pentru feedback constructiv.
Actualizați: L-am transferat în SQL, îl voi transfera în OLAP imediat ce îmi permit să creez bloguri noi.

Etichete: Adăugați etichete

În cadrul acestei lucrări vor fi luate în considerare următoarele aspecte:

Ce sunt cuburile OLAP?
Ce sunt măsurile, dimensiunile, ierarhiile?
Ce tipuri de operații pot fi efectuate pe cuburile OLAP?

Conceptul de cub OLAP

Principalul postulat al OLAP este multidimensionalitatea în prezentarea datelor. În terminologia OLAP, conceptul de cub sau hipercub este folosit pentru a descrie un spațiu de date discret multidimensional.

cub este o structură de date multidimensională din care un utilizator-analist poate interoga informații. Cuburile sunt create din fapte și dimensiuni.

Date- acestea sunt date despre obiecte și evenimente din companie care vor fi supuse analizei. Faptele de același tip formează măsuri. O măsură este tipul de valoare dintr-o celulă cub.

Măsurătorile- acestea sunt elementele de date prin care sunt analizate faptele. O colecție de astfel de elemente formează un atribut de dimensiune (de exemplu, zilele săptămânii pot forma un atribut de dimensiune de timp). În sarcinile de analiză a afacerilor pentru întreprinderile comerciale, dimensiunile includ adesea categorii precum „timp”, „vânzări”, „produse”, „clienți”, „angajați”, „locație geografică”. Măsurătorile sunt cel mai des structuri ierarhice, care sunt categorii logice prin care utilizatorul poate analiza datele reale. Fiecare ierarhie poate avea unul sau mai multe niveluri. Astfel, ierarhia dimensiunii „locație geografică” poate include nivelurile: „țară - regiune - oraș”. În ierarhia de timp, putem distinge, de exemplu, următoarea succesiune de niveluri: O dimensiune poate avea mai multe ierarhii (fiecare ierarhie a unei dimensiuni trebuie să aibă același atribut cheie al tabelului de dimensiuni).

Un cub poate conține date reale din unul sau mai multe tabele de fapte și, cel mai adesea, conține mai multe dimensiuni. Orice cub dat are de obicei un focus specific pentru analiză.

Figura 1 prezintă un exemplu de cub conceput pentru a analiza vânzările de produse petroliere de către o anumită companie pe regiune. Acest cub are trei dimensiuni (timp, produs și regiune) și o singură măsură (volumul vânzărilor exprimat în termeni monetari). Valorile de măsurare sunt stocate în celulele corespunzătoare ale cubului. Fiecare celulă este identificată în mod unic de un set de membri ai fiecărei dimensiuni, numit tuplu. De exemplu, celula situată în colțul din stânga jos al cubului (conține valoarea 98399 USD) este specificată de tuplu [iulie 2005, Orientul Îndepărtat, Diesel]. Aici valoarea de 98.399 USD arată volumul vânzărilor (în termeni monetari) de motorină în Orientul Îndepărtat pentru iulie 2005.

De asemenea, este de remarcat faptul că unele celule nu conțin nicio valoare: aceste celule sunt goale deoarece tabelul de fapte nu conține date pentru ele.

Orez. 1. Cub cu informații despre vânzările de produse petroliere în diferite regiuni

Scopul final al creării unor astfel de cuburi este de a minimiza timpul de procesare a interogărilor care extrag informațiile necesare din datele reale. Pentru a îndeplini această sarcină, cuburile conțin de obicei totaluri precalculate numite agregarilor(agregații). Acestea. cubul acoperă un spațiu de date mai mare decât cel real - există puncte logice, calculate în el. Funcțiile de agregare vă permit să calculați valorile punctelor din spațiul logic pe baza valorilor reale. Cele mai simple funcții de agregare sunt SUM, MAX, MIN, COUNT. Deci, de exemplu, folosind funcția MAX, pentru cubul dat în exemplu, puteți identifica când a avut loc vârful vânzărilor de motorină în Orientul Îndepărtat etc.

O altă caracteristică specifică a cuburilor multidimensionale este dificultatea de a determina originea. De exemplu, cum setați punctul 0 pentru dimensiunea Produs sau Regiuni? Soluția la această problemă este introducerea unui atribut special care combină toate elementele dimensiunii. Acest atribut (creat automat) conține un singur element - Toate. Pentru funcțiile de agregare simple, cum ar fi suma, elementul All este echivalent cu suma valorilor tuturor elementelor din spațiul real al unei dimensiuni date.

Un concept important într-un model de date multidimensional este subspațiul sau subcubul. Un subcub este o parte a întregului spațiu al unui cub sub forma unei figuri multidimensionale din interiorul cubului. Deoarece spațiul multidimensional al unui cub este discret și limitat, subcubul este, de asemenea, discret și limitat.

Operații pe cuburi OLAP

Următoarele operații pot fi efectuate pe un cub OLAP:

felie;
rotație;
consolidare;
detalierea.

Felie(Figura 2) este un caz special al unui subcub. Aceasta este o procedură pentru formarea unui subset al unei matrice de date multidimensionale corespunzătoare unei singure valori a unuia sau mai multor elemente de dimensiune neincluse în acest subset. De exemplu, pentru a afla cum au progresat vânzările de produse petroliere de-a lungul timpului numai într-o anumită regiune, și anume în Urali, trebuie să fixați dimensiunea „Produse” pe elementul „Ural” și să extrageți subsetul (subcubul) corespunzător din cub.

Orez. 2. OLAP cub felie

Rotație(Figura 3) - operația de schimbare a locației măsurătorilor prezentate într-un raport sau pe pagina afișată. De exemplu, o operație de rotație poate implica rearanjarea rândurilor și coloanelor unui tabel. În plus, rotirea unui cub de date mută dimensiunile din afara tabelului la locul lor cu dimensiunile prezente pe pagina afișată și invers.

În general, fiecare specialist știe ce este OLAP astăzi. Cel puțin, conceptele de „OLAP” și „date multidimensionale” sunt strâns legate în mintea noastră. Cu toate acestea, faptul că acest subiect este pus din nou, sper, va fi aprobat de majoritatea cititorilor, deoarece pentru ca ideea de ceva să nu devină depășită în timp, trebuie să comunicați periodic cu oameni destepti sau citește articole într-o publicație bună...

Depozitele de date (locul OLAP în structura informatiei intreprinderi)

Termenul „OLAP” este indisolubil legat de termenul „depozit de date” (Data Warehouse).

Iată definiția formulată de „părintele fondator” al depozitării de date, Bill Inmon: „Un depozit de date este o colecție de date specifică domeniului, limitată în timp și imuabilă pentru a sprijini luarea deciziilor de management.”

Datele din depozit provin din sisteme operaționale (sisteme OLTP), care sunt concepute pentru a automatiza procesele de afaceri. În plus, depozitul poate fi completat din surse externe, cum ar fi rapoartele statistice.

De ce să construim depozite de date - până la urmă, acestea conțin informații redundante, evident, care deja „trăiește” în baze de date sau fișiere ale sistemului de operare? Răspunsul poate fi scurt: este imposibil sau foarte dificil să analizezi direct datele din sistemele de operare. Acest lucru se datorează diverselor motive, inclusiv fragmentării datelor, stocării acestora în diferite formate DBMS și în diferite „colțuri” ale rețelei corporative. Dar chiar dacă o întreprindere își stochează toate datele pe un server central de baze de date (ceea ce este extrem de rar), un analist aproape sigur nu le va înțelege structurile complexe, uneori confuze. Autorul are o experiență destul de tristă de a încerca să „hrănească” analiștii înfometați cu date „brute” din sistemele operaționale - sa dovedit a fi „prea mult pentru ei”.

Astfel, scopul depozitului este de a furniza „materiile prime” pentru analiză într-un singur loc și într-o structură simplă, de înțeles. Ralph Kimball, în prefața cărții sale „The Data Warehouse Toolkit”, scrie că, dacă, după ce a citit întreaga carte, cititorul înțelege un singur lucru - și anume că structura depozitului ar trebui să fie simplă - autorul își va lua în considerare sarcina finalizată.

Există un alt motiv care justifică apariția unui depozit separat - interogări analitice complexe la informații operaționaleîncetini munca curenta companii, blocând tabele pentru o lungă perioadă de timp și confiscând resursele serverului.

În opinia mea, un depozit nu înseamnă neapărat o acumulare gigantică de date - principalul lucru este că este convenabil pentru analiză. În general, există un termen separat pentru facilitățile de stocare mici - Data Marts (chioșcuri de date), dar în practica noastră rusă nu îl auzi des.

OLAP - un instrument de analiză convenabil

Centralizarea și structurarea convenabilă nu sunt tot ceea ce are nevoie un analist. Mai are nevoie de un instrument pentru vizualizarea și vizualizarea informațiilor. Rapoartelor tradiționale, chiar și cele construite pe un singur depozit, le lipsește un singur lucru - flexibilitatea. Ele nu pot fi „răsucite”, „extinse” sau „restrânse” pentru a obține vizualizarea dorită a datelor. Desigur, puteți suna un programator (dacă vrea să vină), iar el (dacă nu este ocupat) va face un nou raport suficient de repede - să zicem, într-o oră (scriu asta și nu cred eu însumi - nu se întâmplă atât de repede în viață; să-i dăm trei ore) . Se pare că un analist nu poate testa mai mult de două idei pe zi. Și el (dacă este un analist bun) poate veni cu mai multe astfel de idei pe oră. Și cu cât analistul vede mai multe „slices” și „secțiuni” de date, cu atât mai multe idei are, care, la rândul lor, necesită din ce în ce mai multe „slices” pentru verificare. Dacă ar avea un instrument care să-i permită să extindă și să restrângă datele simplu și convenabil! OLAP acționează ca un astfel de instrument.

Deși OLAP nu este un atribut necesar al unui depozit de date, acesta este din ce în ce mai folosit pentru a analiza informațiile acumulate în depozit.

Componentele incluse într-un depozit tipic sunt prezentate în Fig. 1.

Orez. 1. Structura depozitului de date

Datele operaționale sunt colectate din diverse surse, curățate, integrate și stocate într-un magazin relațional. În plus, acestea sunt deja disponibile pentru analiză folosind diverse instrumente de raportare. Apoi datele (în întregime sau parțial) sunt pregătite pentru analiza OLAP. Acestea pot fi încărcate într-o bază de date OLAP specială sau stocate în stocare relațională. Cel mai important element al său sunt metadatele, adică informații despre structura, plasarea și transformarea datelor. Datorită acestora, este asigurată interacțiunea eficientă a diferitelor componente de stocare.

Pentru a rezuma, putem defini OLAP ca un set de instrumente pentru analiza multidimensională a datelor acumulate într-un depozit. Teoretic, instrumentele OLAP pot fi aplicate direct datelor operaționale sau copiilor exacte ale acestora (pentru a nu interfera cu utilizatorii operaționali). Dar riscăm astfel să călcăm pe grebla deja descrisă mai sus, adică să începem să analizăm date operaționale care nu sunt direct potrivite pentru analiză.

Definiția și conceptele de bază ale OLAP

În primul rând, să descifrăm: OLAP este procesarea analitică online, adică analiza datelor operaționale. Cele 12 principii definitorii ale OLAP au fost formulate în 1993 de E. F. Codd, „inventatorul” bazelor de date relaționale. Mai târziu, definiția sa a fost reluată în așa-numitul test FASMI, care necesită ca aplicația OLAP să ofere capacitatea de a analiza rapid informațiile multidimensionale partajate ().

Testul FASMI

Rapid(Rapid) - analiza trebuie efectuată la fel de rapid pe toate aspectele informațiilor. Timpul de răspuns acceptabil este de 5 secunde sau mai puțin.

Analiză(Analiză) - trebuie să se poată efectua tipuri de bază de analiză numerică și statistică, predefinite de dezvoltatorul aplicației sau definite liber de utilizator.

Impartit(Partajat) - mulți utilizatori trebuie să aibă acces la date, în timp ce este necesar să se controleze accesul la informații confidențiale.

Multidimensional(Multidimensional) este principala, cea mai esențială caracteristică a OLAP.

informație(Informații) - aplicația trebuie să poată accesa orice informație necesară, indiferent de volumul și locația de stocare.

OLAP = Vedere multidimensională = Cub

OLAP oferă mijloace convenabile și rapide de accesare, vizualizare și analiză a informațiilor de afaceri. Utilizatorul primește un model de date natural, intuitiv, organizându-le sub formă de cuburi multidimensionale (Cuburi). Axele sistemului de coordonate multidimensionale sunt principalele atribute ale procesului de afaceri analizat. De exemplu, pentru vânzări ar putea fi produs, regiune, tip de cumpărător. Timpul este folosit ca una dintre dimensiuni. La intersecțiile axelor - dimensiuni (Dimensiuni) - există date care caracterizează cantitativ procesul - măsuri (Măsuri). Acestea pot fi volume de vânzări pe bucăți sau în termeni monetari, solduri stocuri, costuri etc. Utilizatorul care analizează informațiile poate „taia” cubul în funcție de directii diferite, primește rezumat (de exemplu, pe an) sau, dimpotrivă, informații detaliate (pe săptămână) și efectuează alte manipulări care îi vin în minte în timpul procesului de analiză.

Ca măsurători în cubul tridimensional prezentat în Fig. 2, sunt utilizate sumele vânzărilor, iar timpul, produsul și magazinul sunt folosite ca dimensiuni. Măsurătorile sunt prezentate la niveluri specifice de grupare: produsele sunt grupate pe categorii, magazinele în funcție de țară și datele privind momentul tranzacțiilor pe lună. Puțin mai târziu ne vom uita la nivelurile de grupare (ierarhie) mai detaliat.

Orez. 2. Exemplu de cub

„Tăierea” unui cub

Chiar și un cub tridimensional este dificil de afișat pe ecranul unui computer, astfel încât valorile măsurilor de interes să fie vizibile. Ce putem spune despre cuburile cu mai mult de trei dimensiuni? Pentru a vizualiza datele stocate într-un cub, de regulă, sunt utilizate vizualizări bidimensionale familiare, adică tabelare, cu titluri ierarhice complexe de rânduri și coloane.

O reprezentare bidimensională a unui cub poate fi obținută prin „tăierea” acestuia pe una sau mai multe axe (dimensiuni): fixăm valorile tuturor dimensiunilor, cu excepția a două, și obținem un tabel bidimensional obișnuit. Axa orizontală a tabelului (anteturile coloanelor) reprezintă o dimensiune, axa verticală (antetele rândurilor) reprezintă o alta, iar celulele tabelului reprezintă valorile măsurilor. În acest caz, un set de măsuri este de fapt considerat ca unul dintre dimensiuni - fie selectăm o măsură de afișat (și apoi putem plasa două dimensiuni în titlurile rândurilor și coloanelor), fie arătăm mai multe măsuri (și apoi una dintre axele tabelului vor fi ocupate de numele măsurilor, iar celelalte - valori ale singurei dimensiuni „netăiate”).

Aruncă o privire la fig. 3 - aici este o felie bidimensională a cubului pentru o măsură - Vânzări unitare (bucăți vândute) și două dimensiuni „netăiate” - Magazin (Magazin) și Timp (Timp).

Orez. 3. 2D cub felie pentru o măsură

În fig. Figura 4 prezintă o singură dimensiune „netăiată” - Magazin, dar afișează valorile mai multor măsuri - Vânzări unitare (unități vândute), Vânzări în magazin (suma vânzării) și Cost magazin (cheltuieli magazin).

Orez. 4. 2D cub felie pentru mai multe măsuri

O reprezentare bidimensională a unui cub este, de asemenea, posibilă atunci când mai mult de două dimensiuni rămân „netăiate”. În acest caz, două sau mai multe dimensiuni ale cubului „tăiat” vor fi plasate pe axele de felie (rânduri și coloane) - vezi Fig. 5.

Orez. 5. Secțiune de cub 2D cu dimensiuni multiple pe o axă

Etichete

Valorile „așezate” de-a lungul dimensiunilor se numesc membri sau etichete. Etichetele sunt folosite atât pentru a „tăia” cubul, cât și pentru a limita (filtra) datele selectate - când într-o dimensiune care rămâne „netăiată” nu ne interesează toate valorile, ci un subset al acestora, de exemplu, trei orașe din câteva zeci. Valorile etichetelor apar în vizualizarea cubului 2D ca titluri de rând și coloană.

Ierarhii și niveluri

Etichetele pot fi combinate în ierarhii formate din unul sau mai multe niveluri. De exemplu, etichetele dimensiunii Magazin sunt grupate în mod natural într-o ierarhie cu niveluri:

Țară

Stat

Oraș

Magazin.

Valorile agregate sunt calculate în funcție de nivelurile ierarhice, de exemplu volumul vânzărilor pentru SUA (nivelul „Țară”) sau pentru California (nivelul „stat”). Este posibil să implementați mai mult de o ierarhie într-o singură dimensiune - să zicem, pentru timp: (An, Trimestru, Lună, Zi) și (An, Săptămână, Zi).

Arhitectura aplicațiilor OLAP

Tot ce s-a spus mai sus despre OLAP ține în esență de prezentarea multidimensională a datelor. Modul în care sunt stocate datele, în linii mari, nu privește nici utilizatorul final, nici dezvoltatorii instrumentului pe care îl folosește clientul.

Multidimensionalitatea în aplicațiile OLAP poate fi împărțită în trei niveluri:

Reprezentarea datelor multidimensionale - instrumente pentru utilizatorul final care oferă vizualizare și manipulare multidimensională a datelor; strat reprezentare multidimensională face abstracție din structura fizică a datelor și percepe datele ca fiind multidimensionale.
Procesare multidimensională - un instrument (limbaj) pentru formularea de interogări multidimensionale (relaționale tradiționale Limbajul SQL se dovedește a fi nepotrivit aici) și un procesor capabil să prelucreze și să execute o astfel de cerere.
Stocarea multidimensională este un mijloc de organizare fizică a datelor care asigură executarea eficientă a interogărilor multidimensionale.

Primele două niveluri sunt obligatorii în toate instrumentele OLAP. Al treilea nivel, deși larg răspândit, nu este necesar, deoarece datele pentru o reprezentare multidimensională pot fi extrase din structuri relaționale obișnuite; Procesorul de interogări multidimensionale în acest caz traduce interogările multidimensionale în interogări SQL care sunt executate de SGBD relațional.

Produsele OLAP specifice, de regulă, sunt fie un instrument de reprezentare a datelor multidimensionale, un client OLAP (de exemplu, Pivot Tables în Excel 2000 de la Microsoft sau ProClarity de la Knosys), fie un server multidimensional DBMS, un server OLAP (de exemplu, Oracle Express Server sau Microsoft OLAP Services).

Stratul de procesare multidimensional este de obicei încorporat în clientul OLAP și/sau serverul OLAP, dar poate fi izolat în forma sa pură, cum ar fi componenta Pivot Table Service de la Microsoft.

Aspecte tehnice ale stocării datelor multidimensionale

După cum sa menționat mai sus, instrumentele de analiză OLAP pot extrage date direct din sistemele relaționale. Această abordare era mai atractivă în acele vremuri când serverele OLAP nu erau incluse în listele de prețuri ale producătorilor de top DBMS. Dar astăzi, Oracle, Informix și Microsoft oferă servere OLAP cu drepturi depline și chiar și acei manageri IT cărora nu le place să creeze o „zoo” de software de la diferiți producători în rețelele lor pot cumpăra (sau mai degrabă, pot face o cerere corespunzătoare către managementul companiei ) Server OLAP de aceeași marcă cu serverul principal de baze de date.

Serverele OLAP sau serverele de baze de date multidimensionale își pot stoca datele multidimensionale în moduri diferite. Înainte de a lua în considerare aceste metode, trebuie să vorbim despre un aspect atât de important ca depozitarea unităților. Cert este că în orice depozit de date - atât obișnuit, cât și multidimensional - alături de datele detaliate extrase din sistemele operaționale, sunt stocați și indicatori de sinteză (indicatori agregați, agregari), precum suma volumelor vânzărilor pe lună, pe categorii de mărfuri etc. . Agregatele sunt stocate în mod explicit cu scopul exclusiv de a accelera executarea cererilor. La urma urmei, pe de o parte, de regulă, în depozit se acumulează o cantitate foarte mare de date, iar pe de altă parte, analiștii, în majoritatea cazurilor, nu sunt interesați de indicatori detaliați, ci generalizați. Și dacă ar trebui să se adună milioane de vânzări individuale de fiecare dată pentru a calcula vânzările totale pentru anul, viteza ar fi cel mai probabil inacceptabilă. Prin urmare, la încărcarea datelor într-o bază de date multidimensională, toți indicatorii totali sau o parte a acestora sunt calculați și stocați.

Dar, după cum știți, trebuie să plătiți pentru tot. Iar pentru viteza de procesare a cererilor de date rezumative, trebuie să plătiți pentru o creștere a volumelor de date și a timpului de încărcare a acestora. Mai mult decât atât, o creștere a volumului poate deveni literalmente catastrofală - într-una dintre cele publicate teste standardizate un calcul complet al agregatelor pentru 10 MB de date originale a necesitat 2,4 GB, adică datele au crescut de 240 de ori! Gradul de „umflare” a datelor la calcularea agregatelor depinde de numărul de dimensiuni ale cubului și de structura acestor dimensiuni, adică de raportul dintre numărul de „părți” și „copii” la diferite niveluri de măsurare. Pentru a rezolva problema stocării agregatelor, uneori sunt utilizate scheme complexe, care fac posibilă obținerea unei creșteri semnificative a performanței interogării atunci când se calculează nu toate agregatele posibile.

Acum despre diferitele opțiuni pentru stocarea informațiilor. Atât datele granulare, cât și agregatele pot fi stocate în structuri relaționale sau multidimensionale. Stocarea multidimensională vă permite să tratați datele ca o matrice multidimensională, ceea ce asigură calcule la fel de rapide ale indicatorilor totali și diverse transformări multidimensionale de-a lungul oricărei dimensiuni. Cu ceva timp în urmă, produsele OLAP acceptau stocarea fie relațională, fie multidimensională. Astăzi, de regulă, același produs oferă ambele tipuri de depozitare, precum și un al treilea tip - mixt. Se aplică următorii termeni:

MOLAP(OLAP multidimensional) - atât datele detaliate, cât și agregatele sunt stocate într-o bază de date multidimensională. În acest caz, se obține cea mai mare redundanță, deoarece datele multidimensionale conțin complet date relaționale.
ROLAP(OLAP relațional) - datele detaliate rămân acolo unde „locuiau” inițial - în baza de date relațională; agregatele sunt stocate în aceeași bază de date în tabele de servicii special create.
HOLAP(OLAP hibrid) - datele detaliate rămân la locul lor (într-o bază de date relațională), iar agregatele sunt stocate într-o bază de date multidimensională.

Fiecare dintre aceste metode are propriile avantaje și dezavantaje și ar trebui utilizată în funcție de condiții - volumul de date, puterea SGBD-ului relațional etc.

La stocarea datelor în structuri multidimensionale, există o potențială problemă de „balonare” din cauza stocării valorilor goale. La urma urmei, dacă într-o matrice multidimensională spațiul este rezervat pentru toate combinațiile posibile de etichete de dimensiuni, dar numai o mică parte este de fapt umplută (de exemplu, un număr de produse sunt vândute doar într-un număr mic de regiuni), atunci majoritatea cubul va fi gol, deși spațiul va fi ocupat. Produsele OLAP moderne pot face față acestei probleme.

Va urma. În viitor, vom vorbi despre produse specifice OLAP produse de producători de top.

04.07.2011 Derek Comingore

Dacă ați lucrat în orice domeniu legat de tehnologie, probabil că ați auzit termenul „cub”; totuși, majoritatea administratorilor și dezvoltatorilor de baze de date obișnuiți nu au lucrat cu aceste obiecte. Cuburile oferă o arhitectură de date puternică pentru agregarea rapidă a informațiilor multidimensionale. Dacă organizația dvs. trebuie să analizeze volume mari de date, atunci solutie ideala va fi un cub

Ce este un cub?

Bazele de date relaționale au fost concepute pentru a gestiona mii de tranzacții simultane, menținând în același timp performanța și integritatea datelor. Prin proiectare, bazele de date relaționale nu sunt eficiente în agregarea și căutarea unor volume mari de date. Pentru a agrega și returna volume mari de date, o bază de date relațională trebuie să primească o interogare bazată pe set, informațiile pentru care vor fi colectate și agregate din mers. Astfel de interogări relaționale sunt foarte costisitoare deoarece se bazează pe mai multe îmbinări și funcții agregate; Interogările relaționale agregate sunt deosebit de ineficiente atunci când se lucrează cu cantități mari de date.

Cuburile sunt entități multidimensionale concepute pentru a aborda această deficiență în bazele de date relaționale. Folosind un cub, puteți oferi utilizatorilor o structură de date care oferă răspuns rapid la interogări cu volume mari de agregare. Cuburile efectuează această „magie de agregare” prin mai întâi agregând date (dimensiuni) pe mai multe dimensiuni. Preagregarea cubului se realizează de obicei în timpul procesării. Când procesați un cub, produceți agregari de date precalculate care sunt stocate în formă binară pe disc.

Cubul este structura centrală de date în sistem de operare Analiza datelor OLAP SQL Server Analytical Services (SSAS). Cuburile sunt de obicei construite dintr-o bază de date relațională subiacentă numită model dimensional, dar sunt entități tehnice separate. În mod logic, un cub este un depozit de date care este format din dimensiuni (dimensiuni) și măsurători (măsuri). Dimensiunile conțin caracteristici descriptive și ierarhii, în timp ce dimensiunile sunt faptele pe care le descrieți în dimensiuni. Dimensiunile sunt grupate în combinații logice numite grupuri de dimensiuni. Conectați dimensiunile la grupuri de măsurători pe baza unei caracteristici - gradul de detaliu.

ÎN Sistemul de fișiere un cub este implementat ca o secvență de fișiere binare legate. Arhitectura binară a cubului facilitează recuperarea rapidă a unor volume mari de date multidimensionale.

Am menționat că cuburile sunt construite dintr-o bază de date relațională subiacentă numită model dimensional. Modelul de dimensiune conține tabele relaționale (fapt și dimensiune) care îl conectează la entitățile cubului. Tabelele informative conțin dimensiuni precum cantitatea de produs vândută. Tabelele de dimensiuni stochează atribute descriptive, cum ar fi numele produselor, datele și numele angajaților. De obicei, tabelele de fapte și tabelele de dimensiuni sunt legate prin constrângeri de cheie străină primară, cu cheile străine situate în tabelul de fapte (această relație relațională se referă la atributul de granularitate a cubului discutat mai sus). Când tabelele de dimensiuni sunt legate direct la un tabel de fapte, se formează o schemă stea. Când tabelele de dimensiuni nu sunt direct legate de un tabel de fapte, rezultatul este o schemă fulg de zăpadă.

Vă rugăm să rețineți că modelele dimensionale sunt clasificate în funcție de aplicație. Un data mart este un model dimensional care este conceput pentru un singur proces de afaceri, cum ar fi gestionarea vânzărilor sau a stocurilor. Un depozit de date este un model dimensional conceput pentru a capta procesele de afaceri componente, astfel încât să faciliteze analiza proceselor inter-business.

Cerințe software

Acum că aveți o înțelegere de bază despre ce sunt cuburile și de ce sunt importante, voi porni roțile și vă voi face un tur pas cu pas al construirii primului dvs. cub folosind SSAS. Există câteva componente de bază software, de care veți avea nevoie, așa că înainte de a începe să construiți primul dvs. cub, asigurați-vă că sistemul dvs. îndeplinește cerințele.

Exemplul meu de cub de vânzări pe Internet va fi construit din baza de date de testare AdventureWorksDW 2005. Voi construi cubul de testare dintr-un subset de tabele găsite în baza de date de testare care va fi utilă pentru analiza datelor de vânzări pe Internet. Figura 1 prezintă aspectul de bază al tabelelor bazei de date. Deoarece folosesc versiunea 2005, puteți urma instrucțiunile mele folosind fie SQL Server 2005, fie SQL Server 2008.

Figura 1. Subsetul magazinului de date Adventure Works Internet Sales

Baza de date de instruire Adventure WorksDW 2005 poate fi găsită pe site-ul CodePlex: msftdbprodsamples.codeplex.com. Găsiți linkul „Basele de date cu mostre de produse SQL Server 2005 sunt încă disponibile” (http://codeplex.com/MSFTDBProdSamples/Release/ProjectReleases.aspx?ReleaseId=4004). Baza de date de instruire este conținută în fișierul AdventureWorksBI.msi (http://msftdbprodsamples.codeplex.com/releases/view/4004#DownloadId=11755).

După cum sa menționat, trebuie să aveți acces la o instanță a SQL Server 2008 sau 2005, inclusiv componentele SSAS și Business Intelligence Development Studio (BIDS). Voi folosi SQL Server 2008, așa că este posibil să vedeți unele diferențe subtile dacă utilizați SQL Server 2005.

Crearea unui proiect SSAS

Primul lucru pe care ar trebui să-l faceți este să creați un proiect SSAS folosind BIDS. Găsiți OFERTE în meniul Start și apoi în meniul Microsoft SQL Server 2008/2005, subpunctul SQL Server Business Intelligence Development Studio. Făcând clic pe acest buton, veți lansa BIDS cu ecranul de deschidere implicit. Crea proiect nou SSAS selectând Fișier, Nou, Proiect. Veți vedea caseta de dialog Proiect nou, pe care o arată Figura 1. Selectați folderul Proiect Analysis Services și setați descrierea proiectului la SQLMAG_MyFirstCube. Faceți clic pe OK.

Odată ce proiectul este creat, faceți clic dreapta pe el în Solution Explorer și selectați meniul contextual Element de proprietăți. Acum selectați secțiunea Implementare din partea stângă a casetei de dialog SQLMAG_MyFirstCube: Pagini de proprietate și revizuiți setările pentru serverul țintă și pentru setările bazei de date, așa cum arată Figura 2. Dacă lucrați într-un mediu SQL Server distribuit, va trebui să vă calificați proprietatea Target Server cu numele serverului pe care urmează să îl implementați. Faceți clic pe OK când sunteți mulțumit de setările de implementare pentru acest proiect SSAS.

Definirea sursei de date

Primul obiect pe care trebuie să-l creați este sursa de date. Un obiect sursă de date oferă schema și datele utilizate pentru a construi obiectele asociate cu și la baza cubului. Pentru a crea un obiect sursă de date în BIDS, utilizați Expertul sursă de date.

Porniți Expertul sursă de date făcând clic dreapta pe folderul Sursă de date din panoul Explorator de soluții și selectând Sursă de date nouă. Veți descoperi că crearea de obiecte SSAS în BIDS are o natură de dezvoltare. Vrăjitorul vă ghidează mai întâi prin procesul de creare a obiectelor și setările generale. Și apoi deschideți obiectul SSAS rezultat în designer și îl personalizați în detaliu, dacă este necesar. După ce ați trecut de ecranul de solicitare, definiți o nouă conexiune de date făcând clic pe butonul Nou. Selectați și creați o nouă conexiune bazată pe Native OLEDB\SQL Server Native Client 10 care indică către cea pe care o doriți SQL Server Server care deține instanța de bază de date dorită. Puteți utiliza fie autentificarea Windows, fie SQL Server, în funcție de setările mediului SQL Server. Faceți clic pe butonul Testare conexiune pentru a vă asigura că ați identificat corect conexiunea la baza de date, apoi faceți clic pe OK.

Urmează informațiile de uzurpare a identității, care, la fel ca asocierea datelor, depind de modul în care este structurat mediul SQL Server. Împrumutul cu privilegii este contextul de securitate pe care se bazează SSAS atunci când își procesează obiectele. Dacă vă gestionați implementarea pe un server principal, unic (sau laptop), așa cum presupun că sunt majoritatea cititorilor, puteți selecta pur și simplu opțiunea Utilizați contul de serviciu. Faceți clic pe Următorul pentru a finaliza Expertul sursă de date și setați AWDW2005 ca Nume sursă de date. Este destul de convenabil să poți folosi această metodă în scopuri de testare, dar într-un mediu de producție real nu este cel mai cea mai buna practica- utilizați un cont de serviciu. Este mai bine să specificați domeniul Conturi pentru a împrumuta drepturi de conectare SSAS la sursa de date.

Vizualizare sursă de date

Pentru sursa de date pe care ați definit-o, următorul pas în procesul de construire a cubului SSAS este să creați o vizualizare a sursei de date (DSV). DSV oferă capacitatea de a separa schema pe care o așteaptă cubul de cea a bazei de date de bază. Ca rezultat, DSV poate fi folosit pentru a extinde schema relațională subiacentă atunci când se construiește un cub. Unele dintre caracteristicile cheie ale DSV pentru extinderea schemelor surselor de date includ interogări cu nume, relații logice între tabele și coloane calculate cu nume.

Să mergem mai departe și să facem clic dreapta pe folderul DSV și să selectăm Vizualizare sursă de date nouă pentru a lansa expertul Creare nouă vizualizare DSV. În caseta de dialog, la pasul Selectați o sursă de date, selectați o conexiune de bază de date relațională și faceți clic pe Următorul. Selectați tabelele FactInternetSales, DimProduct, DimTime, DimCustomer și faceți clic pe butonul săgeată dreapta pentru a muta aceste tabele în coloana Inclus. În cele din urmă, faceți clic pe Următorul și finalizați expertul acceptând numele implicit și făcând clic pe Terminare.

În acest moment, ar trebui să aveți o vizualizare DSV situată sub folderul Vizualizări sursei de date din Solution Explorer. Faceți dublu clic pe noul DSV pentru a lansa designerul DSV. Ar trebui să vedeți toate cele patru tabele pentru un anumit DSV, așa cum se arată în Figura 2.

Crearea dimensiunilor bazei de date

După cum am explicat mai sus, dimensiunile oferă caracteristici descriptive ale dimensiunilor și ierarhiilor care sunt utilizate pentru a permite agregarea peste nivelul de detaliu. Este important să înțelegeți diferența dintre o dimensiune de bază de date și o dimensiune de cub: dimensiunile din baza de date furnizează obiectele dimensiuni de bază pentru mai multe dimensiuni ale cubului care vor fi utilizate pentru a construi cubul.

Dimensiunile bazelor de date și ale cubului oferă o soluție elegantă pentru un concept cunoscut sub numele de „dimensiuni de rol”. Dimensiunile bazate pe roluri sunt utilizate atunci când trebuie să utilizați o singură dimensiune într-un cub de mai multe ori. Data este un exemplu perfect în această instanță de cub: veți construi o singură dimensiune de dată și veți face referire la aceasta o dată pentru fiecare dată pentru care doriți să analizați vânzările online. Data calendaristică va fi prima dimensiune pe care o creați. Faceți clic dreapta pe folderul Dimensions din Solution Explorer și selectați New Dimension pentru a lansa Dimension Wizard. Selectați Utilizați un tabel existent și faceți clic pe Următorul în pasul Selectați metoda de creare. La pasul Specificare informații sursă, specificați tabelul DimTime din lista verticală Tabel principal și faceți clic pe Următorul. Acum, la pasul Selectare atribute dimensiuni, trebuie să selectați atributele dimensiunii de timp. Selectați fiecare atribut, așa cum arată Figura 3.

Faceți clic pe Următorul. Ca pas final, introduceți Dim Date în câmpul Name și faceți clic pe Terminare pentru a finaliza Dimension Wizard. Ar trebui să vedeți acum noua dimensiune Dim Date situată sub folderul Dimensiuni din Solution Explorer.

Apoi utilizați Dimension Wizard pentru a crea dimensiuni de produs și de client. Urmați aceiași pași pentru a crea dimensiunea de bază ca înainte. Când lucrați cu Dimension Wizard, asigurați-vă că selectați toate atributele potențiale în pasul Select Dimension Attributes. Valorile implicite pentru celelalte setări sunt bune pentru o instanță de cub de testare.

Crearea unui cub de vânzări pe internet

Acum că ați pregătit dimensiunile bazei de date, puteți începe să construiți cubul. În Solution Explorer, faceți clic dreapta pe folderul Cubes și selectați New Cube pentru a lansa Cube Wizard. În fereastra Selectați metoda de creare, selectați opțiunea Utilizați tabele existente. Selectați tabelul FactInternetSales pentru Measure Group în pasul Select Measure Group Tables. Debifați casetele de lângă dimensiunile Cheie de promovare, Cheie monedă, Cheie teritoriu de vânzare și Număr de revizuire în pasul Selectați măsuri și faceți clic pe Următorul.

În ecranul Selectare dimensiuni existente, asigurați-vă că toate dimensiunile bazei de date existente sunt selectate pentru a fi utilizate ca dimensiuni de cub. Deoarece aș dori să păstrez acest cub cât mai simplu posibil, deselectați dimensiunea FactInternetSales în pasul Selectați dimensiuni noi. Lăsând selectată dimensiunea FactInternetSales, veți crea ceea ce se numește o dimensiune de fapt sau o dimensiune degenerată. Dimensiunile de fapt sunt dimensiuni care au fost create folosind un tabel de fapte de bază, spre deosebire de un tabel de dimensiuni tradițional.

Faceți clic pe Următorul pentru a merge la pasul Finalizarea expertului și introduceți „Primul meu cub” în câmpul Nume cub. Faceți clic pe butonul Finish pentru a finaliza procesul Creare Cube Wizard.

Extinderea și procesarea unui cub

Acum sunteți gata să implementați și să procesați primul cub. Faceți clic dreapta pe pictograma cub nou în Solution Explorer și selectați Process. Veți vedea o casetă de mesaj care spune că conținutul pare a fi învechit. Faceți clic pe Da pentru a implementa noul cub pe serverul SSAS țintă. Când implementați un cub, trimiteți fișier XML pentru Analiză (XMLA) către serverul SSAS țintă, care creează un cub pe serverul însuși. După cum sa menționat, procesarea unui cub populează binarele sale de pe disc cu date din sursa principală, precum și cu metadate suplimentare pe care le-ați adăugat (dimensiunile, dimensiunile și setările cubului).

Odată ce procesul de implementare este finalizat, apare o nouă casetă de dialog Process Cube. Faceți clic pe butonul Run pentru a începe procesarea cubului, care se deschide cu fereastra Process Progress. Când procesarea este finalizată, faceți clic pe Închidere (de două ori pentru a închide ambele casete de dialog) pentru a finaliza procesele de implementare și procesare a cubului.

Acum ați construit, implementat și procesat primul dvs. cub. Puteți vizualiza acest nou cub făcând clic dreapta pe el în fereastra Solution Explorer și selectând Răsfoire. Trageți dimensiunile în centrul tabelului pivot și atributele dimensiunilor pe rânduri și coloane pentru a explora noul dvs. cub. Observați cât de repede procesează cubul diferite interogări de agregare. Acum puteți aprecia puterea nelimitată și, prin urmare, valoarea de afaceri a cubului OLAP.

Derek Comingore ( [email protected]) este arhitect senior la B. I. Voyage, care are statut de Partener Microsoft în domeniul analizei de afaceri. Are titlul SQL Server MVP și mai multe certificări Microsoft

Popular în categoria: