Kas ir olap kubs programmā Excel. SSAS projekta izveide. Kas ir analīze un kāpēc tā ir nepieciešama?
Nopietna uzņēmuma informācijas sistēmās parasti ir lietojumprogrammas, kas paredzētas datu, to dinamikas, tendenču utt. sarežģītai analīzei. Attiecīgi augstākā vadība kļūst par galvenajiem analīzes rezultātu patērētājiem. Šāda analīze galu galā ir paredzēta, lai atbalstītu lēmumu pieņemšanu. Un, lai pieņemtu jebkuru vadības lēmumu, ir nepieciešama nepieciešamā informācija, parasti kvantitatīvā. Lai to izdarītu, šie dati ir jāapkopo no visiem Informācijas sistēmas izveidojiet tos vienotā formātā un pēc tam analizējiet tos. Šim nolūkam tiek izveidotas datu noliktavas.Kas ir datu noliktava?
Parasti - vieta, kur tiek savākta visa analītiski vērtīgā informācija. Prasības šādiem veikaliem atbilst klasiskajai OLAP definīcijai un tiks paskaidrotas tālāk.Dažreiz Noliktavai ir cits mērķis - visu uzņēmuma datu integrācija, lai saglabātu informācijas integritāti un atbilstību visās informācijas sistēmās. Tas. repozitorijs uzkrāj ne tikai analītisko, bet gandrīz visu informāciju un var nodrošināt to direktoriju veidā atpakaļ uz citām sistēmām.
Tipiska datu noliktava parasti atšķiras no tipiskas relāciju datu bāzes. Pirmkārt, parastās datu bāzes ir paredzētas, lai palīdzētu lietotājiem veikt ikdienas darbu, savukārt datu noliktavas ir paredzētas lēmumu pieņemšanai. Piemēram, preču pārdošana un rēķinu izrakstīšana tiek veikta, izmantojot datu bāzi, kas paredzēta darījumu apstrādei, un pārdošanas dinamikas analīze vairāku gadu garumā, kas ļauj plānot darbu ar piegādātājiem, tiek veikta, izmantojot datu noliktavu.
Otrkārt, ja tradicionālās datubāzes tiek pakļautas pastāvīgām izmaiņām, lietotājiem strādājot, datu noliktava ir samērā stabila: tajā esošie dati parasti tiek atjaunināti saskaņā ar grafiku (piemēram, katru nedēļu, katru dienu vai stundu, atkarībā no vajadzībām). Ideālā gadījumā bagātināšanas process ir vienkārši jaunu datu pievienošana noteiktā laika periodā, nemainot iepriekšējo informāciju, kas jau atrodas noliktavā.
Un treškārt, parastās datu bāzes visbiežāk ir datu avots, kas nonāk noliktavā. Turklāt krātuvi var papildināt ar ārējie avoti, piemēram, statistikas atskaites.
Kā tiek uzbūvēta noliktava?
ETL– pamatkoncepcija: trīs posmi:- Ekstrakcija – datu iegūšana no ārējiem avotiem saprotamā formātā;
- Transformācija – avota datu struktūras pārveidošana analītiskās sistēmas veidošanai ērtās struktūrās;
Atgriezīsimies pie analīzes.
Kas ir analīze un kāpēc tā ir nepieciešama?
Analīze ir datu izpēte, lai pieņemtu lēmumus. Analītiskās sistēmas sauc par lēmumu atbalsta sistēmām ( DSS).Šeit ir vērts norādīt uz atšķirību starp darbu ar DSS un vienkāršu regulētu un neregulētu pārskatu kopumu. DSS analīze gandrīz vienmēr ir interaktīva un iteratīva. Tie. analītiķis iedziļinās datos, veidojot un koriģējot analītiskos vaicājumus, kā arī saņem atskaites, kuru struktūra var būt iepriekš nezināma. Tālāk mēs pie tā atgriezīsimies sīkāk, kad apspriedīsim vaicājuma valodu. MDX.
OLAP
Lēmumu atbalsta sistēmām parasti ir līdzekļi, lai sniegtu lietotājam apkopotus datus par dažādiem paraugiem no sākotnējās kopas uztverei un analīzei ērtā formā (tabulas, diagrammas utt.). Tradicionālā pieeja avota datu segmentēšanai ietver vienas vai vairāku daudzdimensiju datu kopu (ko bieži sauc par hiperkubu vai metakubu) izvilkšanu no avota datiem, kuru asīs ir atribūti, bet šūnās ir apkopoti kvantitatīvi dati. (Šādus datus var glabāt arī relāciju tabulās, taču šajā gadījumā runa ir par datu loģisku organizēšanu, nevis par to uzglabāšanas fizisko ieviešanu.) Gar katru asi var sakārtot atribūtus hierarhiju veidā, atspoguļo dažādus to detalizācijas līmeņus. Pateicoties šim datu modelim, lietotāji var formulēt sarežģītus vaicājumus, ģenerēt atskaites un iegūt datu apakškopas.Sarežģītas daudzdimensiju datu analīzes tehnoloģiju sauc par OLAP (On-Line Analytical Processing). OLAP ir galvenā tradicionālās datu noliktavas sastāvdaļa. OLAP jēdzienu 1993. gadā aprakstīja Edgars Kods, slavens datubāzu pētnieks un relāciju datu modeļa autors. 1995. gadā, pamatojoties uz Codd izvirzītajām prasībām, tika formulēts tā sauktais FASMI tests (Fast Analysis of Shared Multidimensional Information), ietverot šādas prasības daudzdimensiju analīzes lietojumprogrammām:
- sniedzot lietotājam analīzes rezultātus pieņemamā laikā (parasti ne vairāk kā 5 s), pat par mazāk detalizētas analīzes rēķina;
- spēja veikt jebkuru loģisko un statistisko analīzi, kas raksturīga šo pieteikumu, un saglabājot to galalietotājam pieejamā formā;
- vairāku lietotāju piekļuve datiem ar atbilstošu bloķēšanas mehānismu un autorizētu piekļuves līdzekļu atbalstu;
- daudzdimensionāls konceptuāls datu attēlojums, t.sk pilnīgs atbalsts hierarhijām un vairākām hierarhijām (šī ir galvenā OLAP prasība);
- iespēja piekļūt jebkurai nepieciešamajai informācijai neatkarīgi no tās apjoma un uzglabāšanas vietas.
Pirms runājam par dažādām OLAP ieviešanām, aplūkosim tuvāk, kas ir kubi no loģiskā viedokļa.
Daudzdimensionāli jēdzieni
Mēs izmantosim Northwind datubāzi, kas iekļauta Microsoft, lai ilustrētu OLAP principus. SQL serveris un kas ir tipiska datu bāze, kurā tiek glabāta informācija par uzņēmuma, kas nodarbojas ar pārtikas vairumtirdzniecību, tirdzniecības operācijām. Šādi dati ietver informāciju par piegādātājiem, klientiem, piegādāto preču sarakstu un to kategorijām, datus par pasūtījumiem un pasūtītajām precēm, uzņēmuma darbinieku sarakstu.Kubs
Ņemsim, piemēram, tabulu Rēķini1, kurā ir uzņēmuma pasūtījumi. Lauki šajā tabulā būs šādi:- Pasūtījuma datums
- Valsts
- Pilsēta
- Klienta vārds
- Piegādes uzņēmums
- produkta nosaukums
- Preču daudzums
- Pasūtījuma cena
- Kāda ir klientu no konkrētas valsts veikto pasūtījumu kopējā vērtība?
- Kāda ir pasūtījumu kopējā vērtība, ko klienti veikuši noteiktā valstī un piegādājis noteikts uzņēmums?
- Kāda ir to pasūtījumu kopējā vērtība, kurus konkrētajā gadā veikuši klienti konkrētā valstī un piegādājis konkrēts uzņēmums?
Šī vaicājuma rezultāts vienmēr būs skaitļu kolonna un to aprakstošu atribūtu saraksts (piemēram, valsts) - tā ir viendimensionāla datu kopa vai, matemātiskā valodā, vektors.
Iedomāsimies, ka jāiegūst informācija par kopējām pasūtījumu izmaksām no visām valstīm un to sadalījumu starp piegādes kompānijām - iegūsim skaitļu tabulu (matricu), kur piegādes uzņēmumi būs norādīti kolonnu virsrakstos, valstis rindā virsraksti, un šūnās būs pasūtījumu daudzums. Šis ir divdimensiju datu masīvs. Šo datu kopu sauc par rakurstabulu ( rakurstabula) vai crosstab.
Ja gribam iegūt vienādus datus, bet arī pēc gada, tad parādīsies vēl viena izmaiņa, t.i. datu kopa kļūs trīsdimensiju (nosacīts 3. kārtas tensors vai 3-dimensiju “kubs”).
Acīmredzot maksimālais dimensiju skaits ir visu atribūtu skaits (datums, valsts, klients utt.), kas raksturo mūsu apkopotos datus (pasūtījumu daudzums, produktu skaits utt.).
Tā mēs nonākam pie daudzdimensionalitātes jēdziena un tās iemiesojuma - daudzdimensiju kubs. Mēs sauksim šādu tabulu faktu tabula" Izmēri vai kuba asis ( izmēriem) ir atribūti, kuru koordinātas ir izteiktas ar šo atribūtu individuālajām vērtībām, kas atrodas faktu tabulā. Tie. piemēram, ja informācija par pasūtījumiem sistēmā tika uzturēta no 2003. līdz 2010. gadam, tad šogad ass sastāvēs no 8 atbilstošiem punktiem. Ja pasūtījumi nāk no trim valstīm, tad valsts asī būs 3 punkti utt. Neatkarīgi no tā, cik valstu ir iekļautas valsts direktorijā. Punktus uz ass sauc par tās “locekļiem” ( Biedri).
Šajā gadījumā paši apkopotie dati tiks saukti par “pasākumiem” ( Mērs). Lai izvairītos no neskaidrībām ar "izmēriem", pēdējos vēlams saukt par "asīm". Pasākumu kopums veido citu "Pasākumu" asi ( Pasākumi). Tajā ir tik daudz dalībnieku (punktu), cik lielumu (apkopoto kolonnu) ir faktu tabulā.
Dimensiju vai asu dalībniekus var apvienot ar vienu vai vairākām hierarhijām ( hierarhija). Paskaidrosim, kas ir hierarhija ar piemēru: pilsētas no pasūtījumiem var apvienot rajonos, rajonus reģionos, valsts reģionus, valstis kontinentos vai citās vienībās. Tie. ir hierarhiska struktūra - kontinents- valsts-reģions-rajons-pilsēta- 5 līmeņi ( Līmenis). Reģionam tiek apkopoti dati par visām tajā iekļautajām pilsētām. Reģionam visos rajonos, kuros ir visas pilsētas utt. Kāpēc mums ir vajadzīgas vairākas hierarhijas? Piemēram, uz pasūtījuma datuma ass mēs varam vēlēties grupēt punktus (t.i., dienas) hierarhijā Gads-mēnesis-diena vai pēc Gads-Nedēļa-Diena: abos gadījumos ir trīs līmeņi. Acīmredzot nedēļa un mēnesis grupē dienas atšķirīgi. Ir arī hierarhijas, kuru līmeņu skaits nav determinēts un ir atkarīgs no datiem. Piemēram, mapes datora diskā.
Datu apkopošana var notikt, izmantojot vairākas standarta funkcijas: summa, minimums, maksimums, vidējais, skaits.
MDX
Pāriesim pie vaicājumu valodas daudzdimensiju datos.SQL valoda sākotnēji tika izstrādāta nevis programmētājiem, bet analītiķiem (un tāpēc tai ir sintakse, kas atgādina dabisko valodu). Bet laika gaitā tas kļuva arvien sarežģītāks, un tagad daži analītiķi zina, kā to labi izmantot, ja vispār zina. Tas ir kļuvis par programmētāju rīku. MDX vaicājumu valodu, kuru baumas, ka Microsoft savvaļā izstrādājis mūsu bijušais tautietis Mosha (vai Mosha) Posumansky, arī sākotnēji bija paredzēts domāt analītiķiem, taču tās koncepcijas un sintakse (kas neskaidri atgādina SQL un pilnībā veltīgi, t.i., jo tas tikai mulsina), pat sarežģītāk nekā SQL. Tomēr tā pamati joprojām ir viegli saprotami.
Mēs to aplūkosim sīkāk, jo tā ir vienīgā valoda, kas ir saņēmusi standarta statusu vispārējā XMLA protokola standarta ietvaros, un, otrkārt, tāpēc, ka pastāv tā atvērtā koda ieviešana Mondrian projekta veidā no uzņēmuma. Pentaho. Citas OLAP analīzes sistēmas (piemēram, Oracle OLAP Option) parasti izmanto savus SQL sintakses paplašinājumus, taču tās arī paziņo par atbalstu MDX.
Darbs ar analītisko datu kopām nozīmē tikai to nolasīšanu, nevis rakstīšanu. Tas. MDX nav klauzulas datu mainīšanai, bet tikai viena atlases klauzula - atlasiet.
OLAP varat izveidot daudzdimensiju kubus šķēles– t.i. kad dati tiek filtrēti pa vienu vai vairākām asīm, vai prognozes– kad kubs “sabrūk” pa vienu vai vairākām asīm, apkopojot datus. Piemēram, mūsu pirmais piemērs ar pasūtījumu daudzumu no valstīm ir kuba projekcija uz valsts asi. MDX vaicājums šim gadījumam izskatīsies šādi:
Atlasiet ...Bērni rindās no
Kas te ir?
Izvēlieties– atslēgas vārds sintaksē iekļauts tikai skaistumam.
ir ass nosaukums. Visi īpašvārdi MDX ir rakstīti kvadrātiekavās.
ir hierarhijas nosaukums. Mūsu gadījumā tā ir valsts un pilsētas hierarhija
– tas ir hierarhijas pirmajā līmenī esošās ass locekļa nosaukums (t.i., valsts) Visi – tas ir metadalībnieks, kas apvieno visus ass locekļus. Katrā asī ir šāds metatermins. Piemēram, gada asī ir “Visi gadi” utt.
Bērni ir dalībnieka funkcija. Katram dalībniekam ir pieejamas vairākas funkcijas. Piemēram, vecākiem. Līmenis, hierarhija, kas atgriež attiecīgi priekšteci, līmeni hierarhijā un pašu hierarhiju, kurai šajā gadījumā pieder dalībnieks. Bērni — atgriež šī dalībnieka pakārtoto dalībnieku kopu. Tie. mūsu gadījumā – valstis.
uz rindām– Norāda, kā iegūtajā tabulā sakārtot šos datus. Šajā gadījumā - rindu galvenē. Iespējamās vērtības šeit: kolonnās, lapās, rindkopās utt. Ir iespējams arī vienkārši norādīt pēc indeksa, sākot no 0.
no– šī ir norāde uz kubu, no kura tiek veikta atlase.
Ko darīt, ja mums nav vajadzīgas visas valstis, bet tikai dažas konkrētas valstis? Lai to izdarītu, mēs varam pieprasījumā skaidri norādīt valstis, kas mums ir vajadzīgas, nevis atlasīt visu, izmantojot funkciju Bērni.
Atlasiet ( ..., ... ) rindās no
Cirtainās lencēs šajā gadījumā ir kopas deklarācija ( Iestatīt). Kopa ir saraksts, dalībnieku uzskaitījums no vienas ass.
Tagad uzrakstīsim vaicājumu mūsu otrajam piemēram – izvadei piegādes personas kontekstā:
Atlasiet ...Bērni rindās .Dalībnieki kolonnās no
Pievienots šeit:
– ass;
.Biedri– ass funkcija, kas atgriež visus tajā esošos terminus. Hierarhijai un līmenim ir viena un tā pati funkcija. Jo Šajā asī ir tikai viena hierarhija, tad tās norādi var izlaist, jo līmenis un hierarhija arī ir vienādi, tad jūs varat parādīt visus dalībniekus vienā sarakstā.
Manuprāt, jau ir skaidrs, kā mēs varam to turpināt ar mūsu trešo piemēru, detalizēti pa gadiem. Bet labāk neurbināsim pa gadiem, bet filtrēsim – t.i. veidot šķēli Lai to izdarītu, mēs uzrakstīsim šādu vaicājumu:
Atlasiet ..Bērni rindās .Dalībnieki kolonnās, no kurienes (.)
Kur te ir filtrācija?
kur- atslēgvārds
ir viens no hierarhijas locekļiem
. Pilns nosaukums, ieskaitot visus terminus, būtu: ..
, bet tāpēc Tā kā šī elementa nosaukums asī ir unikāls, visus nosaukuma starpposma precizējumus var izlaist.
Kāpēc datuma vārds ir iekavās? Iekavas ir virkne ( korts). Korpuss ir viena vai vairākas koordinātas dažādi cirvji Piemēram, lai filtrētu pa divām asīm vienlaikus, iekavās mēs uzskaitām divus terminus no savādāk mērījumi atdalīti ar komatiem. Tas nozīmē, ka kortežs definē kuba “šķēli” (vai “filtrēšanu”, ja šāda terminoloģija ir tuvāka).
Korpuss tiek izmantots ne tikai filtrēšanai. Korpusi var būt arī rindu/kolonnu/lapu galvenēs utt.
Tas ir nepieciešams, piemēram, lai parādītu trīsdimensiju vaicājuma rezultātu divdimensiju tabulā.
Atlasiet crossjoin(...Bērni, ..Bērni) rindās .Biedri kolonnās, no kurienes (.)
Crossjoin ir funkcija. Tas atgriež virkņu kopu (jā, kopa var saturēt korekcijas!), kas iegūta no divu kopu Dekarta reizinājuma. Tie. iegūtajā komplektā būs visas iespējamās valstu un gadu kombinācijas. Tādējādi rindu galvenēs būs vērtību pāris: Valsts gads.
Jautājums ir, kur ir norāde par to, kādi skaitliskie raksturlielumi ir jāattēlo? Šajā gadījumā tiek izmantots šim kubam definētais noklusējuma mērs, t.i. Pasūtījuma cena. Ja vēlamies iegūt citu mēru, tad atceramies, ka mēri ir dimensijas dalībnieki Pasākumi. Un mēs rīkojamies tieši tāpat kā ar citām asīm. Tie. filtrējot vaicājumu pēc kāda no mēriem, šūnās tiks parādīts tieši šis pasākums.
Jautājums: Kāda ir atšķirība starp filtrēšanu kur un filtrēšanu, norādot ass elementus rindās. Atbilde: praktiski nekas. Vienkārši, kur ir norādīta šķēle tām asīm, kuras nepiedalās virsrakstu veidošanā. Tie. tā pati ass nevar būt klāt tajā pašā laikā uz rindām, un iekšā kur.
Aprēķinātie locekļi
Vairāk sarežģīti vaicājumi Jūs varat deklarēt aprēķinātos dalībniekus. Gan atribūta, gan mēra asu dalībnieki. Tie. Varat deklarēt, piemēram, jaunu pasākumu, kas parādīs katras valsts ieguldījumu kopējā pasūtījumu summā:Ar biedru. kā '.CurrentMember / ..', FORMAT_STRING='0,00%' atlasiet ...Bērni rindās, no kurienes .
Aprēķins notiek tādas šūnas kontekstā, kurā ir zināmi visi tās koordinātu atribūti. Katrai no kuba asīm atbilstošās koordinātas (biedrus) var iegūt, izmantojot funkciju CurrentMember. Šeit mums ir jāsaprot, ka izteiksme .Pašreizējais dalībnieks/..’ nedala vienu terminu ar otru, bet dala attiecīgie apkopotie dati kubu šķēles! Tie. esošās teritorijas šķēle tiks sadalīta šķēlē visām teritorijām, t.i. visu pasūtījumu kopējā vērtība. FORMAT_STRING – nosaka vērtību attēlošanas formātu, t.i. %.
Vēl viens aprēķinātā dalībnieka piemērs, bet uz gadu ass:
Ar biedru. kā '. -.'
Acīmredzot pārskatā būs nevis vienība, bet gan atbilstošo sadaļu atšķirība, t.i. pasūtījumu apjoma starpība šajos divos gados.
Parādīt ROLAP
OLAP sistēmas vienā vai otrā veidā ir balstītas uz kāda veida datu glabāšanas un organizēšanas sistēmu. Kad mēs runājam par par RDBMS, tad viņi runā par ROLAP (mēs atstāsim MOLAP un HOLAP uz pašmācība). ROLAP – OLAP uz relāciju datu bāzes, t.i. aprakstītas parastu divdimensiju tabulu veidā. ROLAP sistēmas pārveido MDX vaicājumus par SQL. Galvenā datu bāzu skaitļošanas problēma ir ātra apkopošana. Lai ātrāk apkopotu, dati datubāzē parasti ir ļoti denormalizēti, t.i. netiek glabāti ļoti efektīvi, ņemot vērā diska aizņemto vietu un datu bāzes integritātes uzraudzību. Turklāt tajos ir arī papildu tabulas, kurās tiek glabāti daļēji apkopoti dati. Tāpēc OLAP parasti tiek izveidota atsevišķa datu bāzes shēma, kas tikai daļēji atkārto sākotnējo darījumu datu bāzu struktūru direktoriju izteiksmē.Navigācija
Daudzas OLAP sistēmas piedāvā interaktīvus navigācijas rīkus jau ģenerētiem vaicājumiem (un attiecīgi atlasītajiem datiem). Šajā gadījumā tiek izmantota tā sauktā “urbšana” vai “urbšana”. Piemērotāks tulkojums krievu valodā būtu vārds "padziļināšana". Bet tā ir gaumes lieta, dažās vidēs vārds “urbšana” ir pielipis.Urbt– šī ir atskaites detalizācija, samazinot datu apkopošanas pakāpi, apvienojumā ar filtrēšanu pa kādu citu asi (vai vairākām asīm). Ir vairāki urbšanas veidi:
- urbt uz leju– filtrēšana pa vienu no atskaites avota asīm, parādot detalizētu informāciju par pēcnācējiem atlasītā filtrēšanas dalībnieka hierarhijā. Piemēram, ja ir pārskats par pasūtījumu sadalījumu pa valstīm un gadiem, tad, noklikšķinot uz 2007. gada, tiks parādīts pārskats, kas sadalīts pa tām pašām valstīm un 2007. gada mēnešiem.
- urbja pusē– filtrēšana zem vienas vai vairākām atlasītajām asīm un apkopojuma noņemšana gar vienu vai vairākām citām asīm. Piemēram, ja ir pārskats par pasūtījumu sadalījumu pa valstīm un gadiem, tad, noklikšķinot uz 2007. gada, tiks parādīts cits pārskats, kas sadalīts, piemēram, pa valstīm un piegādātājiem ar filtrēšanu līdz 2007. gadam.
- urbis-sile– agregācijas noņemšana pa visām asīm un vienlaicīga filtrēšana pa tām – ļauj redzēt avota datus no faktu tabulas, no kuras iegūta atskaites vērtība. Tie. Noklikšķinot uz šūnas vērtības, tiek parādīts pārskats ar visiem pasūtījumiem, kas sniedza šo summu. Sava veida tūlītēja urbšana pašos kuba “dziļumos”.
Tagi: pievienojiet atzīmes
Esmu Habras iedzīvotājs diezgan ilgu laiku, bet nekad neesmu lasījis rakstus par daudzdimensiju kubu, OLAP un MDX tēmu, lai gan tēma ir ļoti interesanta un ar katru dienu kļūst arvien aktuālāka.
Nav noslēpums, ka šajā īsajā datu bāzu, elektroniskās uzskaites un tiešsaistes sistēmu izstrādes laikā ir sakrājies ļoti daudz pašu datu. Tagad interesē arī pilnīga arhīvu analīze un, iespējams, mēģinājums paredzēt situācijas līdzīgiem modeļiem nākotnē.
No otras puses, lielie uzņēmumi pat vairāku gadu, mēnešu vai pat nedēļu laikā var uzkrāt tik lielu datu apjomu, ka pat to pamata analīzei ir nepieciešamas ārkārtējas pieejas un stingras aparatūras prasības. Tās varētu būt banku darījumu apstrādes sistēmas, valūtas maiņas aģenti, telefona operatori utt.
Es domāju, ka visi labi zina 2 dažādas pieejas datu bāzes projektēšanai: OLTP un OLAP. Pirmā pieeja (tiešsaistes darījumu apstrāde — darījumu apstrāde reāllaikā) ir paredzēta efektīvai datu apkopošanai reāllaikā, savukārt otrā (tiešsaistes analītiskā apstrāde — reāllaika analītiskā apstrāde) ir īpaši paredzēta datu paraugu ņemšanai un apstrādei visefektīvākajā veidā. veidā.
Apskatīsim mūsdienu OLAP kubu galvenās iespējas un to, kādas problēmas tie atrisina (par pamatu tiek ņemti Analīzes pakalpojumi 2005/2008):
- ātra piekļuve uz datiem
- iepriekšēja agregācija
- hierarhija
- strādājot ar laiku
- daudzdimensiju datu piekļuves valoda
- KPI (galvenie veiktspējas rādītāji)
- datuma ieguve
- daudzlīmeņu kešatmiņa
- daudzvalodu atbalsts
Nedaudz vairāk par iespējām
Ātra piekļuve datiemFaktiski ātra piekļuve datiem neatkarīgi no masīva lieluma ir OLAP sistēmu pamatā. Tā kā šī ir galvenā uzmanība, datu noliktava parasti tiek veidota, pamatojoties uz principiem, kas atšķiras no relāciju datu bāzu principiem.
Šeit vienkāršu datu iegūšanas laiks tiek mērīts sekundes daļās, un vaicājumam, kas pārsniedz dažas sekundes, visticamāk, ir nepieciešama optimizācija.
Iepriekšēja apkopošana
Papildus ātrai esošo datu izgūšanai tas nodrošina arī iespēju iepriekš apkopot “visticamāk, tiks izmantotas” vērtības. Piemēram, ja mums ir ikdienas ieraksti par noteikta produkta pārdošanu, sistēma Var būt Mēs varam arī iepriekš apkopot mēneša un ceturkšņa pārdošanas apjomus, kas nozīmē, ka, ja mēs pieprasām datus reizi mēnesī vai ceturksnī, sistēma nekavējoties sniegs rezultātu. Kāpēc ne vienmēr notiek priekšapkopošana?Jo teorētiski iespējamas preču/laika/utt kombinācijas. var būt milzīgs skaits, kas nozīmē, ka jums ir jābūt skaidriem noteikumiem, kuriem elementiem tiks veidots apkopojums un kuriem nē. Kopumā tēma par šo noteikumu ņemšanu vērā un faktisko apkopojumu veidošanu ir diezgan plaša un ir pelnījusi atsevišķu rakstu.
Hierarhijas
Likumsakarīgi, ka, analizējot datus un veidojot gala atskaites, ir jāņem vērā fakts, ka mēneši sastāv no dienām, un tie paši veido ceturkšņus, un pilsētas tiek iekļautas apgabalos, kas savukārt ir daļa no reģioniem vai valstīm. . Labā ziņa ir tā OLAP kubi sākotnēji viņi aplūko datus no hierarhiju un attiecību ar citiem vienas entītijas parametriem viedokļa, tāpēc hierarhiju veidošana un izmantošana kubos ir ļoti vienkārša lieta.
Darbs ar laiku
Tā kā datu analīze galvenokārt notiek laika apgabalos, OLAP sistēmās laikam tiek piešķirta īpaša nozīme, kas nozīmē, ka, vienkārši definējot sistēmai, kur mums šeit ir laiks, turpmāk varēs ērti izmantot tādas funkcijas kā Gads līdz datumam, Mēnesis līdz datumam. ( periods no gada/mēneša sākuma līdz pašreizējam datumam), Paralēlais periods (tajā pašā dienā vai mēnesī, bet pagājušajā gadā) utt.
Daudzdimensiju datu piekļuves valoda
MDX(Multidimensional Expressions) - vaicājumu valoda vienkāršai un efektīvai piekļuvei daudzdimensiju datu struktūrām. Un tas izsaka visu – zemāk būs daži piemēri.
Galvenie veiktspējas rādītāji (KPI)
Galvenie darbības rādītāji ir finanšu un nefinanšu mērīšanas sistēma, kas palīdz organizācijai noteikt stratēģisko mērķu sasniegšanu. Galvenos darbības rādītājus var diezgan vienkārši definēt OLAP sistēmās un izmantot pārskatos.
Ieguves datums
Datu ieguve (Datu ieguve) - būtībā, identificējot slēptos modeļus vai attiecības starp mainīgajiem lielās datu kopās.
Angļu valodas terminam “Data Mining” nav viennozīmīga tulkojuma krievu valodā (datu ieguve, datu ieguve, informācijas ieguve, datu/informācijas ieguve), tāpēc vairumā gadījumu tas tiek lietots oriģinālā. Visveiksmīgākais netiešais tulkojums ir termins “datu ieguve” (DMA). Tomēr šī ir atsevišķa, ne mazāk interesanta tēma, kas jāapsver.
Daudzlīmeņu kešatmiņa
Faktiski, lai nodrošinātu vislielāko datu piekļuves ātrumu, papildus sarežģītajām datu struktūrām un iepriekšējai apkopošanai OLAP sistēmas atbalsta daudzlīmeņu kešatmiņu. Papildus vienkāršu vaicājumu saglabāšanai kešatmiņā tiek saglabātas arī no veikala nolasītās datu daļas, apkopotās vērtības un aprēķinātās vērtības. Tādējādi, jo ilgāk strādājat ar OLAP kubu, jo ātrāk tas sāk darboties. Ir arī jēdziens “kešatmiņas iesildīšana” - darbība, kas sagatavo OLAP sistēmu darbam ar konkrētiem ziņojumiem, vaicājumiem vai visiem kopā.
Daudzvalodu atbalsts
Jā, jā, jā. Vismaz Analysis Services 2005/2008 (lai gan Enterprise Edition) sākotnēji atbalsta daudzvalodību. Pietiek nodrošināt savu datu virknes parametru tulkojumu, un klients, kurš norādījis savu valodu, saņems lokalizētus datus.
Daudzdimensiju kubi
Kas tad īsti ir šie daudzdimensionālie kubi?Iedomāsimies 3-dimensiju telpu, kuras asis ir laiks, produkti un klienti.
Punkts šādā laukā norādīs faktu, ka kāds no pircējiem iegādājies konkrētu preci noteiktā mēnesī.
Faktiski plakne (vai visu šādu punktu kopa) būs kubs, un attiecīgi Laiks, Produkti un Klienti būs tā izmēri.
Ir nedaudz grūtāk iedomāties (un uzzīmēt) četrdimensionālu vai vairāk kubu, taču būtība nemainās, un pats galvenais, OLAP sistēmām ir pilnīgi vienalga, cik dimensijās jūs strādāsit (saprātīgās robežās). robežas, protams).
Nedaudz no MDX
Tātad, kāds ir MDX skaistums? Visticamāk, mums ir jāapraksta nevis tas, kā mēs vēlamies atlasīt datus, bet gan Kas tieši mēs gribam.Piemēram,
ATLASĪT
( . ) SOLONĀS,
( ., . ) RINDĀS
NO
KUR (., .)
Tas nozīmē, ka es vēlos, lai Mozambikā jūnijā un jūlijā pārdoto iPhone tālruņu skaits.
Tajā pašā laikā es aprakstu kurasšie ir dati, kurus es vēlos un Kā Es gribu tos redzēt ziņojumā.
Skaisti, vai ne?
Šeit ir nedaudz sarežģītāk:
AR biedru AverageSpend AS
. / .
ATLASĪT
( Vidējie tēriņi ) SOLONĀS,
( .., .. ) UZ RINDĀM
NO
KUR (.)* Šis avota kods tika izcelts, izmantojot avota koda izcelšanas rīku.
Faktiski vispirms mēs nosakām formulu “vidējā pirkuma lieluma” aprēķināšanai un mēģinām salīdzināt, kurš (kurš dzimums) tērē vairāk naudas vienā Apple veikala apmeklējumā.
Pati valoda ir ārkārtīgi interesanta gan pētīšanai, gan lietošanai, un, iespējams, ir pelnījusi daudz diskusiju.
Secinājums
Patiesībā šis raksts aptver ļoti maz pat pamatjēdzienu, es to sauktu par "uzkodu" - iespēju ieinteresēt Habras kopienu par šo tēmu un attīstīt to tālāk. Runājot par attīstību, šeit ir milzīgs neapstrādāts lauks, un es ar prieku atbildēšu uz visiem jūsu jautājumiem.P.S.Šis ir mans pirmais ieraksts par OLAP un pirmā publikācija par Habré — es būtu ļoti pateicīgs par konstruktīvām atsauksmēm.
Atjaunināt: Pārnesu uz SQL, pārlikšu uz OLAP, tiklīdz atļaus veidot jaunus blogus.
Tagi: pievienojiet atzīmes
Šī darba ietvaros tiks izskatīti šādi jautājumi:
- Kas ir OLAP kubi?
- Kas ir mēri, dimensijas, hierarhijas?
- Kāda veida darbības var veikt ar OLAP kubiem?
Galvenais OLAP postulāts ir datu prezentācijas daudzdimensionalitāte. OLAP terminoloģijā kuba jeb hiperkuba jēdzienu izmanto, lai aprakstītu daudzdimensiju diskrētu datu telpu.
Kubs ir daudzdimensionāla datu struktūra, no kuras lietotājs-analītiķis var pieprasīt informāciju. Kubi tiek veidoti no faktiem un izmēriem.
Dati- tie ir dati par objektiem un notikumiem uzņēmumā, kas tiks analizēti. Tāda paša veida fakti veido mērus. Mērs ir vērtības veids kuba šūnā.
Mērījumi- tie ir datu elementi, ar kuriem tiek analizēti fakti. Šādu elementu kolekcija veido dimensijas atribūtu (piemēram, nedēļas dienas var veidot laika dimensijas atribūtu). Komercuzņēmumu biznesa analīzes uzdevumos dimensijas bieži ietver tādas kategorijas kā "laiks", "pārdošana", "produkti", "klienti", "darbinieki", "ģeogrāfiskā atrašanās vieta". Mērījumi visbiežāk ir hierarhiskās struktūras, kas ir loģiskas kategorijas, ar kurām lietotājs var analizēt faktiskos datus. Katrai hierarhijai var būt viens vai vairāki līmeņi. Tādējādi dimensijas “ģeogrāfiskā atrašanās vieta” hierarhija var ietvert līmeņus: “valsts – reģions – pilsēta”. Laika hierarhijā mēs varam atšķirt, piemēram, šādu līmeņu secību: Dimensijai var būt vairākas hierarhijas (katrai vienas dimensijas hierarhijai jābūt vienam un tam pašam dimensiju tabulas atslēgas atribūtam).
Kubs var saturēt faktiskos datus no vienas vai vairākām faktu tabulām un visbiežāk satur vairākas dimensijas. Jebkuram konkrētam kubam parasti ir īpašs analīzes fokuss.
1. attēlā parādīts kuba piemērs, kas paredzēts, lai analizētu noteikta uzņēmuma naftas produktu pārdošanu pēc reģiona. Šim kubam ir trīs dimensijas (laiks, produkts un reģions) un viens mērs (pārdošanas apjoms, kas izteikts naudas izteiksmē). Mērījumu vērtības tiek saglabātas attiecīgajās kuba šūnās. Katru šūnu unikāli identificē katras dimensijas locekļu kopa, ko sauc par kopu. Piemēram, šūna, kas atrodas kuba apakšējā kreisajā stūrī (satur vērtību 98399 $), tiek norādīta ar korteži [2005. gada jūlijs, Tālie Austrumi, Dīzeļdegviela]. Šeit vērtība 98 399 USD parāda dīzeļdegvielas pārdošanas apjomu (naudas izteiksmē) Tālajos Austrumos 2005. gada jūlijā.
Ir arī vērts atzīmēt, ka dažas šūnas nesatur nekādas vērtības: šīs šūnas ir tukšas, jo faktu tabulā nav par tām datu.
Rīsi. 1. Kubs ar informāciju par naftas produktu pārdošanu dažādos reģionos
Šādu kubu izveides galvenais mērķis ir samazināt vaicājumu apstrādes laiku, kas no faktiskajiem datiem iegūst nepieciešamo informāciju. Lai veiktu šo uzdevumu, kubi parasti satur iepriekš aprēķinātas kopsummas, ko sauc agregācijas(apkopojumi). Tie. kubs aptver datu telpu, kas ir lielāka par reālo - tajā ir loģiski, aprēķināti punkti. Apkopošanas funkcijas ļauj aprēķināt punktu vērtības loģiskajā telpā, pamatojoties uz faktiskajām vērtībām. Vienkāršākās apkopošanas funkcijas ir SUM, MAX, MIN, COUNT. Tā, piemēram, izmantojot funkciju MAX, piemērā norādītajam kubam varat noteikt, kad dīzeļdegvielas pārdošanas maksimums bija Tālajos Austrumos utt.
Vēl viena specifiska daudzdimensiju kubu iezīme ir izcelsmes noteikšanas grūtības. Piemēram, kā iestatīt punktu 0 kategorijai Produkts vai Reģioni? Šīs problēmas risinājums ir ieviest īpašu atribūtu, kas apvieno visus dimensijas elementus. Šis atribūts (izveidots automātiski) satur tikai vienu elementu - All. Vienkāršām apkopošanas funkcijām, piemēram, summa, elements Visi ir līdzvērtīgs visu elementu vērtību summai konkrētās dimensijas faktiskajā telpā.
Svarīgs jēdziens daudzdimensiju datu modelī ir apakštelpa jeb apakškubs. Apakškubs ir kuba pilnas telpas daļa kādas daudzdimensiju figūras formā kuba iekšpusē. Tā kā kuba daudzdimensiju telpa ir diskrēta un ierobežota, arī apakškubs ir diskrēts un ierobežots.
Darbības ar OLAP kubiem
Ar OLAP kubu var veikt šādas darbības:
- šķēle;
- rotācija;
- konsolidācija;
- detalizēti.
Rīsi. 2. OLAP kuba šķēle
Rotācija(3. attēls) - atskaitē vai parādītajā lapā uzrādīto mērījumu atrašanās vietas maiņas darbība. Piemēram, rotācijas darbība var ietvert tabulas rindu un kolonnu pārkārtošanu. Turklāt, pagriežot datu kubu, tiek pārvietotas ārpus tabulas esošās dimensijas ar izmēriem parādītajā lapā un otrādi.
Kopumā katrs speciālists zina, kas mūsdienās ir OLAP. Vismaz jēdzieni “OLAP” un “daudzdimensiju dati” ir cieši saistīti mūsu prātos. Tomēr to, ka šī tēma atkal tiek aktualizēta, ceru, apstiprinās lielākā daļa lasītāju, jo, lai ideja par kaut ko laika gaitā nenovecotu, ir periodiski jāsazinās ar gudri cilvēki vai lasi rakstus labā publikācijā...
Datu noliktavas (OLAP vieta informācijas struktūra uzņēmumi)
Termins "OLAP" ir nesaraujami saistīts ar terminu "datu noliktava" (Datu noliktava).
Lūk, definīcija, ko formulējis datu noliktavas “dibinātājs” Bils Inmons: “Datu noliktava ir domēnam specifiska, laika ziņā nemainīga datu kolekcija, lai atbalstītu vadības lēmumu pieņemšanu.”
Dati noliktavā nāk no operētājsistēmām (OLTP sistēmām), kas paredzētas biznesa procesu automatizēšanai. Turklāt repozitoriju var papildināt no ārējiem avotiem, piemēram, statistikas pārskatiem.
Kāpēc veidot datu noliktavas - galu galā tajās ir acīmredzami lieka informācija, kas jau “dzīvo” datu bāzēs vai operētājsistēmas failos? Atbilde var būt īsa: nav iespējams vai ļoti grūti tieši analizēt datus no operētājsistēmām. Tas ir saistīts ar dažādiem iemesliem, tostarp datu sadrumstalotību, to glabāšanu dažādos DBVS formātos un dažādos korporatīvā tīkla “stūros”. Bet pat tad, ja uzņēmums visus savus datus glabā centrālajā datu bāzes serverī (kas ir ārkārtīgi reti), analītiķis gandrīz noteikti nesapratīs to sarežģītās, dažreiz mulsinošās struktūras. Autoram ir diezgan skumja pieredze, mēģinot “pabarot” izsalkušos analītiķus ar “neapstrādātiem” datiem no operētājsistēmām - tas izrādījās viņiem “par daudz”.
Tādējādi repozitorija mērķis ir nodrošināt analīzes “izejvielas” vienuviet un vienkāršā, saprotamā struktūrā. Ralfs Kimbals savas grāmatas "Datu noliktavas rīkkopa" priekšvārdā raksta, ka, ja, izlasījis visu grāmatu, lasītājs saprot tikai vienu - proti, ka noliktavas struktūrai jābūt vienkāršai -, autors ņems vērā savu uzdevums izpildīts.
Ir vēl viens iemesls, kas attaisno atsevišķas repozitorija parādīšanos - sarežģīti analītiski vaicājumi operatīvā informācija lēnāk pašreizējais darbs uzņēmumiem, ilgstoši bloķējot tabulas un sagrābjot servera resursus.
Manuprāt, repozitorijs ne vienmēr nozīmē gigantisku datu uzkrāšanu - galvenais, lai tas būtu ērts analīzei. Vispārīgi runājot, mazām krātuvēm ir atsevišķs termins - Data Marts (datu kioski), taču mūsu krievu praksē to bieži nedzird.
OLAP - ērts analīzes rīks
Centralizācija un ērta strukturēšana nav viss, kas nepieciešams analītiķim. Viņam joprojām ir nepieciešams rīks informācijas apskatei un vizualizēšanai. Tradicionālajiem pārskatiem, pat tiem, kas veidoti vienā repozitorijā, trūkst vienas lietas - elastības. Tos nevar "savīt", "izvērst" vai "sakļaut", lai iegūtu vēlamo datu skatu. Protams, var piezvanīt programmētājam (ja viņš grib nākt), un viņš (ja nav aizņemts) pietiekami ātri sastādīs jaunu ziņojumu - teiksim, stundas laikā (rakstu un neticu tas pats - dzīvē tas tik ātri nenotiek; dosim viņam trīs stundas) . Izrādās, ka analītiķis var pārbaudīt ne vairāk kā divas idejas dienā. Un viņš (ja viņš ir labs analītiķis) var nākt klajā ar vairākas šādas idejas stundā. Un jo vairāk datu “šķēles” un “sadaļas” analītiķis redz, jo vairāk viņam ir ideju, kuru pārbaudei, savukārt, ir vajadzīgas arvien jaunas “šķēles”. Ja vien viņam būtu rīks, kas ļautu vienkārši un ērti paplašināt un sakļaut datus! OLAP darbojas kā šāds rīks.
Lai gan OLAP nav nepieciešams datu noliktavas atribūts, to arvien vairāk izmanto, lai analizētu noliktavā uzkrāto informāciju.
Tipiskā repozitorijā iekļautās sastāvdaļas ir parādītas attēlā. 1.
Rīsi. 1. Datu noliktavas struktūra
Darbības dati tiek vākti no dažādiem avotiem, iztīrīti, integrēti un glabāti relāciju veikalā. Turklāt tie jau ir pieejami analīzei, izmantojot dažādus ziņošanas rīkus. Pēc tam dati (pilnībā vai daļēji) tiek sagatavoti OLAP analīzei. Tos var ielādēt īpašā OLAP datu bāzē vai glabāt relāciju krātuvē. Tās svarīgākais elements ir metadati, t.i., informācija par datu struktūru, izvietojumu un transformāciju. Pateicoties tiem, tiek nodrošināta efektīva dažādu uzglabāšanas komponentu mijiedarbība.
Rezumējot, mēs varam definēt OLAP kā rīku komplektu noliktavā uzkrāto datu daudzdimensionālai analīzei. Teorētiski OLAP rīkus var pielietot tieši operatīvajiem datiem vai to precīzām kopijām (lai netraucētu operatīvajiem lietotājiem). Bet tādējādi mēs riskējam uzkāpt uz jau iepriekš aprakstītā grābekļa, t.i., sākt analizēt operatīvos datus, kas nav tieši piemēroti analīzei.
OLAP definīcija un pamatjēdzieni
Vispirms atšifrēsim: OLAP ir tiešsaistes analītiskā apstrāde, t.i., operatīvo datu analīze. OLAP 12 noteicošos principus 1993. gadā formulēja E. F. Kods, relāciju datu bāzu “izgudrotājs”. Vēlāk tā definīcija tika pārveidota par tā saukto FASMI testu, kas prasa, lai OLAP lietojumprogramma nodrošinātu iespēju ātri analizēt kopīgotu daudzdimensiju informāciju ().
FASMI tests
Ātri(Ātri) - analīze jāveic vienlīdz ātri par visiem informācijas aspektiem. Pieņemamais reakcijas laiks ir 5 sekundes vai mazāk.
Analīze(Analīze) - ir jābūt iespējai veikt pamata veidu skaitlisko un statistisko analīzi, ko iepriekš definējis lietojumprogrammas izstrādātājs vai brīvi definējis lietotājs.
Dalīts(Koplietots) - daudziem lietotājiem ir jābūt piekļuvei datiem, savukārt ir nepieciešams kontrolēt piekļuvi konfidenciālai informācijai.
Daudzdimensionāls(Daudzdimensiju) ir galvenā, visbūtiskākā OLAP īpašība.
Informācija(Informācija) - lietojumprogrammai ir jābūt iespējai piekļūt jebkurai nepieciešamajai informācijai neatkarīgi no tās apjoma un uzglabāšanas vietas.
OLAP = daudzdimensiju skats = kubs
OLAP nodrošina ērtus un ātrus līdzekļus biznesa informācijas piekļuvei, apskatei un analīzei. Lietotājs saņem dabisku, intuitīvu datu modeli, sakārtojot tos daudzdimensionālu kubu (Cubes) veidā. Daudzdimensionālās koordinātu sistēmas asis ir analizējamā biznesa procesa galvenie atribūti. Piemēram, pārdošanai tas varētu būt produkts, reģions, pircēja veids. Laiks tiek izmantots kā viena no dimensijām. Asu krustpunktos - izmēri (Dimensions) - ir dati, kas kvantitatīvi raksturo procesu - mēri (Measures). Tie var būt pārdošanas apjomi gabalos vai naudas izteiksmē, krājumu atlikumi, izmaksas utt. Lietotājs, kurš analizē informāciju, var “sagriezt” kubu dažādos virzienos, saņemt kopsavilkumu (piemēram, pa gadiem) vai, gluži pretēji, detalizētu (pa nedēļām) informāciju un veikt citas manipulācijas, kas viņam ienāk prātā analīzes procesā.
Kā mērījumi trīsdimensiju kubā, kas parādīts attēlā. 2, tiek izmantoti pārdošanas apjomi, un kā izmēri tiek izmantoti laiks, produkts un veikals. Mērījumi tiek parādīti noteiktos grupēšanas līmeņos: produkti tiek grupēti pēc kategorijas, veikali pēc valsts un darījumu laika dati pēc mēneša. Nedaudz vēlāk aplūkosim grupēšanas (hierarhijas) līmeņus sīkāk.
Rīsi. 2. Kuba piemērs
Kuba "griešana".
Pat trīsdimensiju kubu ir grūti parādīt datora ekrānā, lai būtu redzamas interesējošo mēru vērtības. Ko mēs varam teikt par kubiem, kuriem ir vairāk nekā trīs dimensijas? Lai vizualizētu kubā glabātos datus, parasti tiek izmantoti pazīstami divdimensiju, t.i., tabulas skati ar sarežģītiem hierarhiskiem rindu un kolonnu virsrakstiem.
Divdimensiju kuba attēlojumu var iegūt, “izgriežot” to pāri vienai vai vairākām asīm (izmēriem): mēs nofiksējam visu izmēru vērtības, izņemot divus, un iegūstam parastu divdimensiju tabulu. Tabulas horizontālā ass (kolonnu galvenes) apzīmē vienu dimensiju, vertikālā ass (rindu galvenes) apzīmē citu, un tabulas šūnas attēlo mērījumu vērtības. Šajā gadījumā mēru kopa faktiski tiek uzskatīta par vienu no dimensijām — mēs vai nu izvēlamies vienu mēru, ko parādīt (un tad varam ievietot divas dimensijas rindu un kolonnu virsrakstos), vai arī parāda vairākus mērus (un pēc tam vienu no tabulas asis aizņems mērījumu nosaukumi, bet pārējās - vienīgās “neizgrieztās” dimensijas vērtības).
Apskatiet att. 3 - šeit ir divdimensiju kuba šķēle vienam pasākumam - Vienības pārdošana (pārdotās vienības) un divas "nesagrieztas" dimensijas - Veikals (Veikals) un Laiks (Laiks).
Rīsi. 3. 2D kuba šķēle vienam pasākumam
Attēlā 4. attēlā ir parādīta tikai viena “nesagriezta” dimensija — Veikals, bet tajā ir parādītas vairāku mēru vērtības — Vienības pārdošana (pārdotās vienības), Pārdošana veikalā (pārdošanas summa) un Veikala izmaksas (veikala izdevumi).
Rīsi. 4. 2D kuba šķēle vairākiem mēriem
Kuba divdimensiju attēlojums ir iespējams arī tad, ja ir “neizgrieztas” vairāk nekā divas dimensijas. Šajā gadījumā uz šķēluma asīm (rindām un kolonnām) tiks novietoti divi vai vairāki “izgrieztā” kuba izmēri - skatīt att. 5.
Rīsi. 5. 2D kuba šķēle ar vairākiem izmēriem uz vienas ass
Tagi
Vērtības, kas "noliktas" pa izmēriem, sauc par elementiem vai etiķetēm. Etiķetes tiek izmantotas gan kuba “izgriešanai”, gan atlasīto datu ierobežošanai (filtrēšanai) - kad dimensijā, kas paliek “neizgriezta”, mūs interesē nevis visas vērtības, bet gan to apakškopa, piemēram, trīs pilsētas. no vairākiem desmitiem. Iezīmju vērtības tiek parādītas 2D kuba skatā kā rindu un kolonnu virsraksti.
Hierarhijas un līmeņi
Etiķetes var apvienot hierarhijās, kas sastāv no viena vai vairākiem līmeņiem. Piemēram, kategorijas Veikals iezīmes dabiski tiek grupētas hierarhijā ar līmeņiem:
Valsts
Valsts
Pilsēta
Veikals.
Kopējās vērtības tiek aprēķinātas atbilstoši hierarhijas līmeņiem, piemēram, pārdošanas apjoms ASV ("valsts" līmenis) vai Kalifornijas līmenis ("štata" līmenis). Ir iespējams ieviest vairāk nekā vienu hierarhiju vienā dimensijā - teiksim, laikam: (gads, ceturksnis, mēnesis, diena) un (gads, nedēļa, diena).
OLAP lietojumprogrammu arhitektūra
Viss, kas tika teikts iepriekš par OLAP, būtībā bija saistīts ar daudzdimensionālu datu prezentāciju. Tas, kā dati tiek glabāti, rupji runājot, neskar ne gala lietotāju, ne klienta izmantotā rīka izstrādātājus.
Daudzdimensionalitāti OLAP lietojumprogrammās var iedalīt trīs līmeņos:
- Daudzdimensionāla datu reprezentācija – galalietotāja rīki, kas nodrošina daudzdimensionālu datu vizualizāciju un manipulācijas ar tiem; slānis daudzdimensionāls attēlojums abstrahējas no datu fiziskās struktūras un uztver datus kā daudzdimensionālus.
- Daudzdimensiju apstrāde - rīks (valoda) daudzdimensiju vaicājumu formulēšanai (tradicionālā relāciju SQL valoda izrādās šeit nepiemērots) un apstrādātāju, kas spēj apstrādāt un izpildīt šādu pieprasījumu.
- Daudzdimensiju krātuve ir datu fiziskas organizēšanas līdzeklis, kas nodrošina daudzdimensiju vaicājumu efektīvu izpildi.
Pirmie divi līmeņi ir obligāti visos OLAP rīkos. Lai gan trešais līmenis ir plaši izplatīts, tas nav nepieciešams, jo datus daudzdimensionālam attēlojumam var iegūt no parastajām relāciju struktūrām; Daudzdimensiju vaicājumu procesors šajā gadījumā pārvērš daudzdimensiju vaicājumus SQL vaicājumos, kurus izpilda relāciju DBVS.
Konkrēti OLAP produkti, kā likums, ir vai nu daudzdimensiju datu attēlošanas rīks, OLAP klients (piemēram, rakurstabulas programmā Excel 2000 no Microsoft vai ProClarity no Knosys), vai daudzdimensiju servera DBVS, OLAP serveris (piemēram, Oracle Express Server vai Microsoft OLAP pakalpojumi).
Daudzdimensiju apstrādes slānis parasti ir iebūvēts OLAP klientā un/vai OLAP serverī, taču to var izolēt tīrā veidā, piemēram, Microsoft Pivot Table Service komponentā.
Daudzdimensiju datu uzglabāšanas tehniskie aspekti
Kā minēts iepriekš, OLAP analīzes rīki var arī iegūt datus tieši no relāciju sistēmām. Šī pieeja bija pievilcīgāka tajos laikos, kad OLAP serveri nebija iekļauti vadošo DBVS ražotāju cenu sarakstos. Bet šodien Oracle, Informix un Microsoft piedāvā pilnvērtīgus OLAP serverus, un pat tie IT vadītāji, kuriem nepatīk savos tīklos veidot dažādu ražotāju programmatūras “zoodārzu”, var iegādāties (pareizāk sakot, iesniegt atbilstošu pieprasījumu uzņēmuma vadība) OLAP serveris ar tādu pašu zīmolu kā galvenais datu bāzes serveris.
OLAP serveri vai daudzdimensiju datu bāzes serveri var uzglabāt savus daudzdimensiju datus dažādos veidos. Pirms šo metožu izskatīšanas mums ir jārunā par tik svarīgu aspektu kā vienību uzglabāšana. Fakts ir tāds, ka jebkurā datu noliktavā - gan parastajā, gan daudzdimensiju - kopā ar detalizētiem datiem, kas iegūti no operētājsistēmām, tiek glabāti arī kopsavilkuma rādītāji (apkopotie rādītāji, apkopojumi), piemēram, pārdošanas apjomu summa pa mēnešiem, pa preču kategorijām utt. . Apkopotie dati tiek glabāti tikai ar mērķi paātrināt vaicājumu izpildi. Galu galā, no vienas puses, noliktavā parasti tiek uzkrāts ļoti liels datu apjoms, un, no otras puses, analītiķus vairumā gadījumu interesē nevis detalizēti, bet vispārināti rādītāji. Un, ja katru reizi būtu jāsaskaita miljoniem atsevišķu pārdošanas gadījumu, lai aprēķinātu kopējo gada pārdošanas apjomu, ātrums, visticamāk, būtu nepieņemams. Tāpēc, ielādējot datus daudzdimensionālā datu bāzē, tiek aprēķināti un saglabāti visi kopējie rādītāji vai daļa no tiem.
Bet, kā zināms, par visu ir jāmaksā. Un, lai nodrošinātu kopsavilkuma datu pieprasījumu apstrādes ātrumu, jums ir jāmaksā par datu apjoma pieaugumu un to ielādes laiku. Turklāt apjoma pieaugums var kļūt burtiski katastrofāls - vienā no publicētajiem standartizēti testi pilnam agregātu aprēķinam 10 MB oriģinālajiem datiem bija nepieciešami 2,4 GB, t.i., dati pieauga 240 reizes! Datu “uzbriešanas” pakāpe, aprēķinot agregātus, ir atkarīga no kuba izmēru skaita un šo izmēru struktūras, t.i., “tēvu” un “bērnu” skaita attiecības dažādos mērījumu līmeņos. Lai atrisinātu apkopojumu glabāšanas problēmu, dažreiz tiek izmantotas sarežģītas shēmas, kas ļauj panākt ievērojamu vaicājuma veiktspējas pieaugumu, aprēķinot ne visus iespējamos apkopojumus.
Tagad par dažādām informācijas glabāšanas iespējām. Gan granulētos datus, gan apkopotos datus var glabāt relāciju vai daudzdimensiju struktūrās. Daudzdimensionālā krātuve ļauj apstrādāt datus kā daudzdimensionālu masīvu, kas nodrošina vienlīdz ātrus kopējo rādītāju aprēķinus un dažādas daudzdimensionālas transformācijas pa jebkuru no dimensijām. Pirms kāda laika OLAP produkti atbalstīja relāciju vai daudzdimensiju krātuvi. Mūsdienās, kā likums, viens un tas pats produkts nodrošina abus šos uzglabāšanas veidus, kā arī trešo veidu - jauktu. Tiek piemēroti šādi noteikumi:
- MOLAP(Multidimensional OLAP) - gan detalizēti dati, gan apkopojumi tiek glabāti daudzdimensionālā datu bāzē. Šajā gadījumā tiek iegūta vislielākā dublēšanās, jo daudzdimensiju dati pilnībā satur relāciju datus.
- ROLAP(relāciju OLAP) - detalizēti dati paliek tur, kur tie sākotnēji "dzīvoja" - relāciju datu bāzē; agregāti tiek glabāti vienā un tajā pašā datu bāzē speciāli izveidotās pakalpojumu tabulās.
- HOLAP(Hybrid OLAP) - detalizēti dati paliek vietā (relāciju datu bāzē), un apkopojumi tiek glabāti daudzdimensiju datu bāzē.
Katrai no šīm metodēm ir savas priekšrocības un trūkumi, un tās jāizmanto atkarībā no apstākļiem - datu apjoma, relāciju DBVS jaudas utt.
Uzglabājot datus daudzdimensiju struktūrās, tukšu vērtību glabāšanas dēļ var rasties "uzpūšanās" problēma. Galu galā, ja daudzdimensiju masīvā telpa ir rezervēta visām iespējamām dimensiju etiķešu kombinācijām, bet faktiski tiek aizpildīta tikai neliela daļa (piemēram, virkne produktu tiek pārdoti tikai nedaudzos reģionos), tad lielākā daļa kubs būs tukšs, lai gan vieta būs aizņemta. Mūsdienu OLAP produkti var tikt galā ar šo problēmu.
Turpinājums sekos. Turpmāk runāsim par konkrētiem vadošo ražotāju ražotajiem OLAP produktiem.
04.07.2011. Dereks Komingors
Ja esat strādājis kādā ar tehnoloģijām saistītā jomā, droši vien esat dzirdējis terminu "kubs"; tomēr lielākā daļa parasto datu bāzes administratoru un izstrādātāju nestrādāja ar šiem objektiem. Cubes nodrošina jaudīgu datu arhitektūru ātrai daudzdimensiju informācijas apkopošanai. Ja jūsu organizācijai ir jāanalizē liels datu apjoms, tad ideāls risinājums tas būs kubs
Kas ir kubs?
Relāciju datu bāzes tika izstrādātas, lai apstrādātu tūkstošiem vienlaicīgu darījumu, vienlaikus saglabājot veiktspēju un datu integritāti. Pēc konstrukcijas relāciju datu bāzes nav efektīvas liela datu apjoma apkopošanā un meklēšanā. Lai apkopotu un atgrieztu lielu datu apjomu, relāciju datu bāzei jāsaņem uz kopu balstīts vaicājums, kura informācija tiks apkopota un apkopota lidojuma laikā. Šādi relāciju vaicājumi ir ļoti dārgi, jo tie balstās uz vairākiem savienojumiem un agregētās funkcijas; Apkopotie relāciju vaicājumi ir īpaši neefektīvi, strādājot ar lielu datu apjomu.
Kubi ir daudzdimensiju entītijas, kas izstrādātas, lai novērstu šo trūkumu relāciju datu bāzēs. Izmantojot kubu, varat nodrošināt lietotājiem datu struktūru, kas nodrošina ātru atbildi uz vaicājumiem ar lieliem apkopošanas apjomiem. Kubi veic šo “apkopošanas burvību”, vispirms apkopojot datus (dimensijas) vairākās dimensijās. Apstrādes laikā parasti tiek veikta kuba iepriekšēja agregācija. Apstrādājot kubu, tiek izveidoti iepriekš aprēķināti datu apkopojumi, kas binārā formā tiek glabāti diskā.
Kubs ir centrālā datu struktūra operētājsistēma SQL Server Analytical Services (SSAS) OLAP datu analīze. Kubus parasti veido no pamatā esošās relāciju datu bāzes, ko sauc par dimensiju modeli, taču tie ir atsevišķas tehniskas vienības. Loģiski, ka kubs ir datu noliktava, ko veido izmēri (izmēri) un mērījumi (mēri). Kategorijas satur aprakstošas funkcijas un hierarhijas, savukārt dimensijas ir fakti, ko aprakstāt dimensijās. Dimensijas tiek grupētas loģiskās kombinācijās, ko sauc par dimensiju grupām. Jūs saistāt izmērus ar mērījumu grupām, pamatojoties uz raksturlielumu - detalizācijas pakāpi.
IN failu sistēma kubs tiek realizēts kā saistītu bināro failu secība. Kuba binārā arhitektūra atvieglo lielu daudzdimensiju datu ātru izguvi.
Es minēju, ka kubi tiek veidoti no pamatā esošās relāciju datu bāzes, ko sauc par dimensiju modeli. Dimensiju modelī ir relāciju tabulas (faktu un dimensiju), kas to savieno ar kuba entītijām. Faktu tabulās ir ietverti tādi izmēri kā pārdotā produkta daudzums. Dimensiju tabulās tiek glabāti aprakstoši atribūti, piemēram, produktu nosaukumi, datumi un darbinieku vārdi. Parasti faktu tabulas un dimensiju tabulas ir saistītas, izmantojot primārās ārējās atslēgas ierobežojumus, ar ārējām atslēgām, kas atrodas faktu tabulā (šī relāciju saistība attiecas uz iepriekš apspriesto kuba granularitātes atribūtu). Ja dimensiju tabulas ir tieši saistītas ar faktu tabulu, tiek izveidota zvaigznīšu shēma. Ja dimensiju tabulas nav tieši saistītas ar faktu tabulu, rezultāts ir sniegpārsliņu shēma.
Lūdzu, ņemiet vērā, ka izmēru modeļi tiek klasificēti atbilstoši pielietojumam. Datu tirgus ir dimensiju modelis, kas paredzēts vienam biznesa procesam, piemēram, pārdošanai vai krājumu pārvaldībai. Datu noliktava ir dimensiju modelis, kas paredzēts biznesa procesu komponentu uztveršanai, lai atvieglotu starpuzņēmumu procesu analīzi.
Programmatūras prasības
Tagad, kad jums ir pamatzināšanas par to, kas ir kubi un kāpēc tie ir svarīgi, es ieslēgšu pārnesumus un vedīšu jūs uz soli pa solim, kā izveidot savu pirmo kubu, izmantojot SSAS. Ir daži pamata komponenti programmatūra, kas jums būs nepieciešams, tāpēc, pirms sākat veidot savu pirmo kubu, pārliecinieties, vai jūsu sistēma atbilst prasībām.
Mans Internet Sales kuba paraugs tiks izveidots no AdventureWorksDW 2005 testa datu bāzes. Testa kubu veidošu no testu datubāzē atrodamo tabulu apakškopas, kas noderēs interneta pārdošanas datu analīzei. 1. attēlā parādīts datu bāzes tabulu pamata izkārtojums. Tā kā es izmantoju versiju 2005, varat sekot maniem norādījumiem, izmantojot vai nu SQL Server 2005, vai SQL Server 2008.
| 1. attēls. Adventure Works interneta pārdošanas datu tirgus apakškopa |
Adventure WorksDW 2005 apmācību datubāze ir atrodama CodePlex vietnē: msftdbprodsamples.codeplex.com. Atrodiet saiti “SQL Server 2005 produktu paraugu datu bāzes joprojām ir pieejamas” (http://codeplex.com/MSFTDBProdSamples/Release/ProjectReleases.aspx?ReleaseId=4004). Apmācību datu bāze ir ietverta failā AdventureWorksBI.msi (http://msftdbprodsamples.codeplex.com/releases/view/4004#DownloadId=11755).
Kā minēts, jums ir jābūt piekļuvei SQL Server 2008 vai 2005 gadījumam, tostarp SSAS un Business Intelligence Development Studio (BIDS) komponentiem. Es izmantošu SQL Server 2008, tāpēc, ja izmantojat SQL Server 2005, iespējams, pamanīsit dažas smalkas atšķirības.
SSAS projekta izveide
Pirmā lieta, kas jums jādara, ir izveidot SSAS projektu, izmantojot BIDS. Atrodiet BIDS izvēlnē Sākt un pēc tam izvēlnē Microsoft SQL Server 2008/2005 apakšvienumā SQL Server Business Intelligence Development Studio. Noklikšķinot uz šīs pogas, tiks palaists BIDS ar noklusējuma uzplaiksnījumu ekrānu. Izveidot jauns projekts SSAS, atlasot Fails, Jauns, Projekts. Jūs redzēsiet dialoglodziņu Jauns projekts, kas parādīts 1. attēlā. Atlasiet mapi Analysis Services Project un iestatiet projekta aprakstu uz SQLMAG_MyFirstCube. Noklikšķiniet uz Labi.
Kad projekts ir izveidots, ar peles labo pogu noklikšķiniet uz tā Solution Explorer un atlasiet konteksta izvēlne Rekvizītu vienums. Tagad dialoglodziņa SQLMAG_MyFirstCube: Property Pages kreisajā pusē atlasiet sadaļu Izvietošana un pārskatiet mērķa servera un datu bāzes iestatījumu iestatījumus, kā parādīts 2. attēlā. Ja strādājat izplatītā SQL Server vidē, jums būs jākvalificējas. Rekvizīts Target Server ar tā servera nosaukumu, kurā plānojat izvietot. Noklikšķiniet uz Labi, kad esat apmierināts ar šī SSAS projekta izvietošanas iestatījumiem.
Datu avota noteikšana
Pirmais objekts, kas jums jāizveido, ir datu avots. Datu avota objekts nodrošina shēmu un datus, ko izmanto, lai izveidotu objektus, kas saistīti ar kubu un tā pamatnē. Lai izveidotu datu avota objektu pakalpojumā BIDS, izmantojiet datu avota vedni.
Palaidiet datu avota vedni, ar peles labo pogu noklikšķinot uz mapes Datu avots panelī Solution Explorer un atlasot Jauns datu avots. Jūs atklāsiet, ka SSAS objektu izveidei BIDS ir attīstības raksturs. Vispirms vednis iepazīstina jūs ar objekta izveides procesu un vispārīgajiem iestatījumiem. Pēc tam noformētājā atverat iegūto SSAS objektu un, ja nepieciešams, to detalizēti pielāgojat. Kad esat pārspējis uzvednes ekrānu, definējiet jaunu datu savienojumu, noklikšķinot uz pogas Jauns. Atlasiet un izveidojiet jaunu savienojumu, pamatojoties uz Native OLEDB\SQL Server Native Client 10, kas norāda uz vajadzīgo. SQL serveris Serveris, kuram pieder vēlamā datu bāzes instance. Atkarībā no SQL Server vides iestatījumiem varat izmantot Windows vai SQL Server autentifikāciju. Noklikšķiniet uz pogas Pārbaudīt savienojumu, lai pārliecinātos, ka esat pareizi identificējis datu bāzes savienojumu, un pēc tam noklikšķiniet uz Labi.
Tālāk seko informācija par uzdošanos, kas, tāpat kā datu asociācija, ir atkarīga no SQL Server vides struktūras. Privilēģiju aizņemšanās ir drošības konteksts, uz kuru SSAS paļaujas, apstrādājot savus objektus. Ja izvietošanu pārvaldāt primārajā, vienā serverī (vai klēpjdatorā), kā es pieņemu, ka to dara lielākā daļa lasītāju, varat vienkārši atlasīt opciju Izmantot pakalpojuma kontu. Noklikšķiniet uz Tālāk, lai pabeigtu datu avota vedni un iestatītu AWDW2005 kā datu avota nosaukumu. Tas ir diezgan ērti, ka jūs varat izmantot šo metodi testēšanas nolūkos, taču reālā ražošanas vidē tas nav pats labākais labākā prakse- izmantojiet pakalpojuma kontu. Labāk ir norādīt domēnu Konti aizņemties SSAS savienojuma tiesības ar datu avotu.
Datu avota skats
Jūsu definētajam datu avotam nākamais solis SSAS kuba veidošanas procesā ir datu avota skata (DSV) izveide. DSV nodrošina iespēju atdalīt shēmu, ko sagaida jūsu kubs, no pamatā esošās datu bāzes shēmas. Rezultātā DSV var izmantot, lai paplašinātu pamatā esošo relāciju shēmu, veidojot kubu. Dažas no galvenajām DSV funkcijām datu avotu shēmu paplašināšanai ietver nosauktos vaicājumus, loģiskās attiecības starp tabulām un nosauktas aprēķinātās kolonnas.
Dosimies uz priekšu un ar peles labo pogu noklikšķiniet uz DSV mapes un atlasiet Jauns datu avota skats, lai palaistu vedni Izveidot jaunu DSV skatu. Dialoglodziņā solī Atlasīt datu avotu atlasiet relāciju datu bāzes savienojumu un noklikšķiniet uz Tālāk. Atlasiet tabulas FactInternetSales, DimProduct, DimTime, DimCustomer un noklikšķiniet uz vienas labās bultiņas pogas, lai pārvietotu šīs tabulas uz kolonnu Iekļauts. Visbeidzot noklikšķiniet uz Tālāk un pabeidziet vedņa darbību, pieņemot noklusējuma nosaukumu un noklikšķinot uz Pabeigt.
Šajā brīdī jums vajadzētu būt DSV skatam, kas atrodas Solution Explorer mapē Datu avota skati. Veiciet dubultklikšķi uz jaunā DSV, lai palaistu DSV noformētāju. Jums vajadzētu redzēt visas četras konkrētā DSV tabulas, kā parādīts 2. attēlā.
Datu bāzes dimensiju izveide
Kā paskaidroju iepriekš, dimensijas nodrošina dimensiju un hierarhiju aprakstošas iezīmes, kas tiek izmantotas, lai iespējotu apkopošanu virs detalizācijas līmeņa. Ir svarīgi saprast atšķirību starp datu bāzes dimensiju un kuba dimensiju: datu bāzes izmēri nodrošina pamata dimensiju objektus vairākām kuba dimensijām, kas tiks izmantotas kuba izveidošanai.
Datu bāzes un kuba izmēri nodrošina elegantu risinājumu koncepcijai, kas pazīstama kā "lomas izmēri". Uz lomu balstītas dimensijas tiek izmantotas, ja viena kuba dimensija ir jāizmanto vairākas reizes. Datums ir ideāls piemērs šajā kuba instancē: jūs izveidosit vienu datuma dimensiju un vienreiz atsaucēsit uz to katram datumam, kuram vēlaties analizēt pārdošanu tiešsaistē. Kalendāra datums būs pirmā jūsu izveidotā dimensija. Ar peles labo pogu noklikšķiniet uz mapes Dimensions programmā Solution Explorer un atlasiet New Dimension, lai palaistu dimensiju vedni. Atlasiet Izmantot esošu tabulu un solī Atlasīt izveides metodi noklikšķiniet uz Tālāk. Veicot darbību Norādīt avota informāciju, nolaižamajā sarakstā Galvenā tabula norādiet tabulu DimTime un noklikšķiniet uz Tālāk. Tagad solī Atlasīt dimensijas atribūtus ir jāatlasa laika dimensijas atribūti. Atlasiet katru atribūtu, kā parādīts 3. attēlā.
Noklikšķiniet uz Tālāk. Kā pēdējo darbību laukā Nosaukums ievadiet aptumšošanas datumu un noklikšķiniet uz Pabeigt, lai pabeigtu dimensiju vedni. Tagad jums vajadzētu redzēt jauno dimensiju Dim Date, kas atrodas Solution Explorer mapē Dimensions.
Pēc tam izmantojiet dimensiju vedni, lai izveidotu produkta un klienta izmērus. Veiciet tās pašas darbības, lai izveidotu bāzes izmēru, kā iepriekš. Strādājot ar dimensiju vedni, pārbaudiet, vai solī Atlasīt dimensijas atribūtus esat atlasījis visus iespējamos atribūtus. Pārējo iestatījumu noklusējuma vērtības ir piemērotas testa kuba eksemplāram.
Interneta pārdošanas kuba izveide
Tagad, kad esat sagatavojis datu bāzes izmērus, varat sākt veidot kubu. Programmā Solution Explorer ar peles labo pogu noklikšķiniet uz mapes Cubes un atlasiet New Cube, lai palaistu kuba vedni. Logā Atlasīt izveides metodi atlasiet opciju Izmantot esošās tabulas. Atlasiet tabulu FactInternetSales mērīšanas grupai solī Atlasīt mērījumu grupas tabulas. Noņemiet atzīmi no izvēles rūtiņām blakus dimensijām Akcijas atslēga, Valūtas atslēga, Pārdošanas teritorijas atslēga un Pārskatīšanas numurs solī Atlasīt mērījumus un noklikšķiniet uz Tālāk.
Ekrānā Atlasīt esošās dimensijas pārliecinieties, vai visas esošās datu bāzes dimensijas ir atlasītas lietošanai kā kuba izmēri. Tā kā es vēlētos, lai šis kubs būtu pēc iespējas vienkāršāks, solī Atlasīt jaunas dimensijas noņemiet atzīmi no FactInternetSales dimensijas. Atstājot atlasītu dimensiju FactInternetSales, jūs izveidosit tā saukto faktu dimensiju vai deģenerētu dimensiju. Faktu dimensijas ir izmēri, kas tika izveidoti, izmantojot pamata faktu tabulu, nevis tradicionālo dimensiju tabulu.
Noklikšķiniet uz Tālāk, lai pārietu uz vedņa pabeigšanas darbību, un laukā Cube Name ievadiet “Mans pirmais kubs”. Noklikšķiniet uz pogas Pabeigt, lai pabeigtu kuba izveides vedņa procesu.
Kuba paplašināšana un apstrāde
Tagad esat gatavs izvietot un apstrādāt pirmo kubu. Ar peles labo pogu noklikšķiniet uz jaunā kuba ikonas Solution Explorer un atlasiet Process. Jūs redzēsit ziņojuma lodziņu, kurā teikts, ka saturs šķiet novecojis. Noklikšķiniet uz Jā, lai izvietotu jauno kubu mērķa SSAS serverī. Kad izvietojat kubu, kuru jūs nosūtāt XML fails for Analisis (XMLA) mērķa SSAS serverim, kas izveido kubu pašā serverī. Kā minēts, apstrādājot kubu, tā binārie faili tiek aizpildīti diskā ar datiem no galvenā avota, kā arī jūsu pievienotajiem papildu metadatiem (kuba izmēriem, izmēriem un iestatījumiem).
Kad izvietošanas process ir pabeigts, tiek parādīts jauns Process Cube dialoglodziņš. Noklikšķiniet uz pogas Palaist, lai sāktu kuba apstrādi, kas tiek atvērts ar logu Process Progress. Kad apstrāde ir pabeigta, noklikšķiniet uz Aizvērt (divas reizes, lai aizvērtu abus dialoglodziņus), lai pabeigtu kuba izvietošanas un apstrādes procesus.
Tagad esat izveidojis, izvietojis un apstrādājis savu pirmo kubu. Varat apskatīt šo jauno kubu, ar peles labo pogu noklikšķinot uz tā Solution Explorer logā un atlasot Pārlūkot. Velciet izmērus uz rakurstabulas centru un dimensiju atribūtus uz rindām un kolonnām, lai izpētītu savu jauno kubu. Ievērojiet, cik ātri kubs apstrādā dažādus apkopošanas vaicājumus. Tagad varat novērtēt OLAP kuba neierobežoto jaudu un līdz ar to arī biznesa vērtību.
Dereks Komingors ( [aizsargāts ar e-pastu]) ir vecākais arhitekts uzņēmumā B. I. Voyage, kuram ir Microsoft partnera statuss biznesa analītikas jomā. Ir SQL Server MVP tituls un vairāki Microsoft sertifikāti
