Trebuie atribuite caracteristicile speciale ale tehnologiei olap. Sisteme analitice OLAP. Ce este OLAP

În 1993, fondatorul abordării relaționale a construirii bazelor de date, Edgar Codd și partenerii (Edgar Codd, matematician și coleg IBM), au publicat un articol inițiat de compania „Arbor Software” (azi este celebra companie „Hyperion Solutions”) , intitulat „Providing OLAP (operational Analytical Processing) for Analyst Users”, care a formulat 12 caracteristici ale tehnologiei OLAP, care au fost completate ulterior cu încă șase. Aceste prevederi au devenit conținutul principal al unei tehnologii noi și foarte promițătoare.

Principalele caracteristici ale tehnologiei OLAP (de bază):

  • reprezentarea conceptuală multidimensională a datelor;
  • manipularea intuitivă a datelor;
  • disponibilitatea și detaliile datelor;
  • extragerea datelor pe lot vs. interpretare;
  • Modele de analiză OLAP;
  • arhitectura client-server (OLAP este accesibil de pe desktop);
  • transparență (acces transparent la date externe);
  • suport multi-utilizator.

Caracteristici speciale (speciale):

  • prelucrarea datelor neformalizate;
  • salvarea rezultatelor OLAP: stocarea lor separat de datele originale;
  • excluderea valorilor lipsă;
  • manipularea valorilor lipsă.

Caracteristici ale raportării (Raport):

  • flexibilitate în raportare;
  • performanța standard de raportare;
  • configurarea automată a stratului fizic de extragere a datelor.

Managementul dimensiunilor:

  • universalitatea măsurătorilor;
  • număr nelimitat de dimensiuni și niveluri de agregare;
  • număr nelimitat de operații între dimensiuni.

Din punct de vedere istoric, astăzi termenul „OLAP” implică nu doar o vizualizare multidimensională a datelor de la utilizatorul final, ci și o reprezentare multidimensională a datelor în baza de date țintă. Cu aceasta este legată apariția termenilor „OLAP relațional” (ROLAP) și „OLAP multidimensional” (MOLAP) ca termeni independenți.

Un serviciu OLAP este un instrument de analiză a unor cantități mari de date în timp real. Interacționând cu sistemul OLAP, utilizatorul va putea efectua vizualizarea flexibilă a informațiilor, obținerea de secțiuni de date arbitrare și efectuarea de operațiuni analitice de detaliere, convoluție, distribuție end-to-end, comparare în timp în mai mulți parametri simultan. Toate lucrările cu sistemul OLAP se desfășoară în ceea ce privește domeniul de activitate și vă permite să construiți modele valide statistic ale situației afacerii.

Software-ul OLAP este un instrument de analiză online a datelor conținute în depozit. Caracteristica principală este că aceste instrumente sunt destinate utilizării nu de către un specialist în tehnologia informației, nu de către un expert statistician, ci de către un profesionist în domeniul aplicat al managementului - un manager al unui departament, departament, management și, în cele din urmă, un director. Instrumentele sunt concepute pentru a permite analistului să comunice cu problema, nu cu computerul. Pe fig. 6.14 prezintă un cub OLAP elementar care vă permite să evaluați datele în trei dimensiuni.


Un cub OLAP multidimensional și un sistem de algoritmi matematici corespunzători pentru procesarea statistică vă permit să analizați date de orice complexitate la orice interval de timp.

Orez. 6.14. Cub OLAP elementar

Având la dispoziție mecanisme flexibile de manipulare și vizualizare a datelor (Fig. 6.15, Fig. 6.16), managerul ia în considerare mai întâi datele din unghiuri diferite, care pot (sau nu) să fie legate de problema rezolvată.

În continuare, compară diverși indicatori de afaceri între ei, încercând să identifice relații ascunse; poate arunca o privire mai atentă asupra datelor, granulând-le, de exemplu, defalcându-le în funcție de timp, regiune sau client sau, dimpotrivă, generalizează și mai mult prezentarea informațiilor pentru a elimina detaliile care distrag atenția. După aceea, folosind modulul de evaluare și simulare statistică, sunt construite mai multe scenarii, iar dintre acestea este selectată cea mai acceptabilă opțiune.

Orez. 6.15.

Un manager de companie, de exemplu, poate veni cu o ipoteză că răspândirea creșterii activelor în diferite ramuri ale companiei depinde de proporția specialiștilor cu educație tehnică și economică în cadrul acestora. Pentru a testa această ipoteză, managerul poate solicita de la depozit și afișa pe grafic raportul interesului pentru el pentru acele sucursale a căror creștere a activelor pentru trimestrul curent a scăzut cu peste 10% față de anul trecut, precum și pentru cele ale căror active au crescut. cu peste 25%. Ar trebui să poată utiliza o selecție simplă din meniul oferit. Dacă rezultatele obținute se încadrează în mod semnificativ în două grupuri corespunzătoare, atunci acesta ar trebui să devină un stimul pentru testarea ulterioară a ipotezei prezentate.

În prezent, o direcție numită Simulare dinamică a primit o dezvoltare rapidă, care implementează pe deplin principiul FASMI de mai sus.

Folosind modelarea dinamică, analistul construiește un model al unei situații de afaceri care se dezvoltă în timp, conform unui scenariu. În același timp, rezultatul unei astfel de modelări pot fi câteva situații noi de afaceri care generează un arbore de decizii posibile cu o evaluare a probabilității și perspectivelor fiecăreia.

Orez. 6.16. SI analitic pentru extragerea, prelucrarea datelor si prezentarea informatiilor

Tabelul 6.3 prezintă caracteristicile comparative ale analizei statice și dinamice.

În seria de articole „Introducere în bazele de date”, publicată recent (vezi ComputerPress nr. 3'2000 - 3'2001), am discutat despre diferite tehnologii și instrumente software utilizate pentru crearea sistemelor informatice - SGBD desktop și server, instrumente de proiectare a datelor, aplicație instrumente de dezvoltare, precum și Business Intelligence - instrumente de analiză și procesare a datelor la nivel de întreprindere care în prezent devin din ce în ce mai populare în lume, inclusiv în țara noastră. Rețineți, totuși, că problemele utilizării instrumentelor de Business Intelligence și a tehnologiilor utilizate pentru a crea aplicații din această clasă nu sunt încă suficient acoperite în literatura națională. Într-o nouă serie de articole, vom încerca să umplem acest gol și să vorbim despre care sunt tehnologiile care stau la baza acestor aplicații. Ca exemple de implementare, vom folosi în principal tehnologiile Microsoft OLAP (în principal Analysis Services în Microsoft SQL Server 2000), dar sperăm că cea mai mare parte a materialului va fi utilă utilizatorilor altor instrumente.

Primul articol din această serie este dedicat elementelor de bază ale OLAP (On-Line Analytical Processing) - o tehnologie pentru analiza multidimensională a datelor. În acesta, vom acoperi conceptele de depozitare de date și OLAP, cerințele pentru depozitarea de date și instrumentele OLAP, organizarea logică a datelor OLAP și termenii și conceptele de bază folosite atunci când discutăm analiza multidimensională.

Ce este un depozit de date

Sistemele informaționale la scară de întreprindere, de regulă, conțin aplicații concepute pentru analiza multidimensională complexă a datelor, dinamica, tendințele acestora etc. O astfel de analiză are scopul în cele din urmă de a ajuta la luarea deciziilor. Adesea aceste sisteme sunt numite sisteme de sprijinire a deciziei.

Este imposibil să luați o decizie managerială fără a deține informațiile necesare pentru aceasta, de obicei cantitative. Acest lucru necesită crearea de depozite de date, adică procesul de colectare, screening și preprocesare a datelor pentru a furniza utilizatorilor informațiile rezultate pentru analiză statistică (și adesea crearea de rapoarte analitice).

Ralph Kimball, unul dintre inițiatorii conceptului de depozit de date, a descris depozitul de date ca „un loc în care oamenii își pot accesa datele” (a se vedea, de exemplu, Ralph Kimball, „The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses” ", John Wiley & Sons, 1996 și „Setul de instrumente Data Webhouse: Construirea unui depozit de date activat pe web”, John Wiley & Sons, 2000). De asemenea, a formulat cerințele de bază pentru depozitele de date:

  • suport pentru extragerea de date de mare viteză din stocare;
  • suport pentru coerența internă a datelor;
  • capacitatea de a obține și compara așa-numitele felii de date (slice și zaruri);
  • disponibilitatea utilităților convenabile pentru vizualizarea datelor în stocare;
  • completitudinea și fiabilitatea datelor stocate;
  • suport pentru un proces de reaprovizionare cu date de calitate.

Adesea, nu este posibilă satisfacerea tuturor cerințelor enumerate în cadrul aceluiași produs. Prin urmare, pentru implementarea depozitelor de date se folosesc de obicei mai multe produse, dintre care unele sunt de fapt mijloace de stocare a datelor, altele sunt mijloace de extragere și vizualizare a acestora, altele sunt mijloace de completare etc.

Un depozit de date tipic este de obicei diferit de o bază de date relațională tipică. În primul rând, bazele de date convenționale sunt concepute pentru a ajuta utilizatorii să-și facă munca zilnică, în timp ce depozitele de date sunt concepute pentru a lua decizii. De exemplu, vânzarea unui produs și emiterea unei facturi se realizează folosind o bază de date concepută pentru procesarea tranzacțiilor, și analizarea dinamicii vânzărilor pe mai mulți ani, ceea ce vă permite să planificați lucrul cu furnizorii, folosind un depozit de date.

În al doilea rând, bazele de date obișnuite sunt supuse unor schimbări constante în cursul activității utilizatorilor, iar 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 are nevoie). În mod ideal, procesul de reaprovizionare este pur și simplu adăugarea de date noi într-o perioadă de timp, fără a modifica informațiile vechi deja stocate.

Și în al treilea rând, bazele de date convenționale sunt cel mai adesea sursa de date care intră în depozit. În plus, depozitul poate fi completat din surse externe, cum ar fi rapoarte statistice.

Ce este OLAP

Sistemele de sprijin pentru decizii au de obicei mijloacele de a furniza utilizatorului date agregate pentru diverse mostre din setul inițial într-o formă convenabilă pentru percepție și analiză. De obicei, astfel de funcții agregate formează un set de date multidimensional (și, prin urmare, non-relațional) (deseori denumit hipercub sau metacub) ale cărui axe conțin parametrii și ale cărui celule conțin datele agregate care depind de ei. De-a lungul fiecărei axe, datele pot fi organizate într-o ierarhie reprezentând diferite niveluri de detaliu. Datorită acestui model de date, utilizatorii pot formula interogări complexe, pot genera rapoarte și pot primi subseturi de date.

Tehnologia analizei complexe a datelor multidimensionale se numeste OLAP (On-Line Analytical Processing). OLAP este o componentă cheie a depozitării datelor. 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 (vezi EF Codd, SB Codd și CTSalley, Providing OLAP (procesare analitică on-line) pentru utilizatorii-analiști: An IT mandat.raport tehnic, 1993). În 1995, pe baza cerințelor conturate de Codd, a fost formulat așa-numitul test FASMI (Fast Analysis of Shared Multidimensional Information - fast analysis of shared multidimensional information), care include următoarele cerințe pentru aplicațiile de analiză multidimensională:

  • furnizarea utilizatorului cu rezultatele analizei î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ă specifică acestei aplicații și de a o salva într-o formă accesibilă utilizatorului final;
  • acces multi-utilizator la date cu suport pentru mecanisme de blocare adecvate și instrumente de acces autorizate;
  • reprezentarea conceptuală multidimensională a datelor, inclusiv suport complet 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ă în diverse moduri, de la cele mai simple instrumente de analiză a datelor din aplicații de birou până la sisteme analitice distribuite bazate pe produse server. Dar înainte de a vorbi despre diferitele implementări ale acestei funcționalități, să ne uităm la ce sunt cuburile OLAP din punct de vedere logic.

Cuburi multidimensionale

În această secțiune, vom arunca o privire mai atentă asupra conceptului de OLAP și cuburi multidimensionale. Ca exemplu de bază de date relațională pe care o vom folosi pentru a ilustra principiile OLAP, vom folosi baza de date Northwind, care este inclusă cu Microsoft SQL Server sau Microsoft Access, care este o bază de date tipică care stochează informații despre operațiunile de tranzacționare ale unui aliment angro. firma de aprovizionare. Astfel de date includ informații despre furnizori, clienți, companii de livrare, o listă de bunuri furnizate și categoriile acestora, date despre comenzi și mărfuri comandate, o listă a angajaților companiei. O descriere detaliată a bazei de date Northwind poate fi găsită în sistemele de ajutor Microsoft SQL Server sau Microsoft Access - nu o oferim aici din cauza lipsei de spațiu.

Pentru a explora conceptul de OLAP, să folosim vizualizarea Facturi și tabelele Produse și Categorii din baza de date Northwind, creând o interogare care va returna detaliile tuturor mărfurilor comandate și facturilor emise:

SELECTAȚI dbo.Invoices.Country, dbo.Invoices.City, dbo.Invoices.CustomerName, dbo.Invoices.Vânzător, dbo.Invoices.OrderDate, dbo.Categories.CategoryName, dbo.Invoices.ProductName, dbohipperInvoicemes,. .Invoices.ExtendedPrice FROM dbo.Products INNER JOIN dbo.Categories ON dbo.Products.CategoryID = dbo.Categories.CategoryID INNER JOIN dbo.Invoices ON dbo.Products.ProductID = dbo.Invoices.ProductID

În Access 2000, o interogare similară arată astfel:

SELECTAȚI Facturi.Țara, Facturi.Oraș, Facturi.Clienți.Nume Companie AS Nume Client, Facturi.Vânzător, Facturi.Data Comandă, Categorii.Nume Categorie, Facturi.Nume Produs, Facturi.Expedieri.Nume Companie AS Expeditor.NumeExtended.Categorii INJOINVOICES INVOICE INVOICE. INNER JOIN Produse ON Invoices.ProductID = Products.ProductID) ON Categories.CategoryID = Products.CategoryID;

Această interogare accesează vizualizarea Facturi, care conține informații despre toate facturile emise, precum și tabelele Categorii și Produse, care conțin informații despre categoriile de produse care au fost comandate și, respectiv, produsele în sine. În urma acestei solicitări, vom primi un set de date despre comandă, inclusiv categoria și numele articolului comandat, data plasării comenzii, numele persoanei care a emis factura, orașul, țara și numele firma care face comanda, precum și numele companiei responsabile cu livrarea.

Pentru comoditate, să salvăm această solicitare ca vizualizare, numind-o Facturi1. Rezultatul accesării acestei reprezentări este prezentat în Fig. unu .

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

  • Care este valoarea totală a comenzilor plasate de clienții din Franța?
  • Care este valoarea totală a comenzilor plasate de clienții din Franța și livrate de Speedy Express?
  • Care este valoarea totală a comenzilor plasate de clienții din Franța în 1997 și livrate de Speedy Express?

Să traducem aceste întrebări în interogări SQL (Tabelul 1).

Rezultatul oricăreia dintre interogările de mai sus este un număr. Dacă înlocuiți parametrul „Franța” din prima interogare cu „Austria” sau cu numele altei țări, puteți rula din nou această interogare și puteți obține un alt număr. După efectuarea acestei proceduri cu toate țările, vom obține următorul set de date (fragmentul este afișat mai jos):

Țară SUM (Preț extins)
Argentina 7327.3
Austria 110788.4
Belgia 28491.65
Brazilia 97407.74
Canada 46190.1
Danemarca 28392.32
Finlanda 15296.35
Franţa 69185.48
Germania 209373.6

Setul rezultat de valori agregate (în acest caz, sume) poate fi interpretat ca un set de date unidimensionale. Același set de date poate fi obținut și ca rezultat al unei interogări cu o clauză GROUP BY de următoarea formă:

SELECTAȚI Țara, SUMA (Preț extins) FROM facturi1 GROUP BY Country

Acum să ne uităm la a doua interogare de mai sus, care conține două condiții în clauza WHERE. Dacă executăm această interogare, înlocuind în ea toate valorile posibile ale parametrilor Country și ShipperName, vom obține un set de date bidimensional de următoarea formă (fragmentul este afișat mai jos):

nume de expeditor
Țară transport maritim federal Speedy Express Pachetul Unit
Argentina 1 210.30 1 816.20 5 092.60
Austria 40 870.77 41 004.13 46 128.93
Belgia 11 393.30 4 717.56 17 713.99
Brazilia 16 514.56 35 398.14 55 013.08
Canada 19 598.78 5 440.42 25 157.08
Danemarca 18 295.30 6 573.97 7 791.74
Finlanda 4 889.84 5 966.21 7 954.00
Franţa 28 737.23 21 140.18 31 480.90
Germania 53 474.88 94 847.12 81 962.58

Un astfel de set de date se numește tabel pivot sau tabel încrucișat (tabel încrucișat, tabel încrucișat). Multe foi de calcul și SGBD-uri desktop vă permit să creați astfel de tabele - de la Paradox pentru DOS la Microsoft Excel 2000. De exemplu, o interogare similară arată astfel în Microsoft Access 2000:

TRANSFORM Sum(Invoices1.ExtendedPrice) AS SumOfExtendedPrice SELECT Invoices1.Country FROM Invoices1 GROUP BY Invoices1.Country PIVOT Invoices1.ShipperName;

Datele agregate pentru un astfel de tabel pivot pot fi obținute și folosind interogarea obișnuită GROUP BY:

SELECT Country,ShipperName, SUM (ExtendedPrice) FROM invoices1 GROUP BY COUNTRY,ShipperName Rețineți, totuși, că rezultatul acestei interogări nu va fi tabelul pivot în sine, ci doar un set de date agregate pentru construcția sa (fragmentul este afișat mai jos ):

Țară nume de expeditor SUM (Preț extins)
Argentina transport maritim federal 845.5
Austria transport maritim federal 35696.78
Belgia transport maritim federal 8747.3
Brazilia transport maritim federal 13998.26

A treia dintre interogările de mai sus are deja trei parametri în clauza WHERE. Variind-le, vom obține un set de date tridimensional (Fig. 2).

Celulele cubului prezentat în fig. 2 conțin date agregate corespunzătoare valorilor parametrilor de interogare din clauza WHERE situată pe axele cubului.

Puteți obține un set de tabele bidimensionale prin tăierea unui cub cu planuri paralele cu fețele sale (acestea sunt notate cu termenii secțiuni transversale și felii).

Evident, datele conținute în celulele cubului pot fi obținute și folosind interogarea corespunzătoare cu clauza GROUP BY. În plus, unele foi de calcul (în special, Microsoft Excel 2000) vă permit, de asemenea, să construiți un set de date tridimensional și să vizualizați diferite secțiuni ale cubului, paralele cu marginea acestuia, prezentate pe foaia registrului de lucru (registru de lucru).

Dacă clauza WHERE conține patru sau mai mulți parametri, setul de valori rezultat (numit și cub OLAP) poate fi 4-dimensional, 5-dimensional și așa mai departe.

După ce am luat în considerare ce sunt cuburile OLAP multidimensionale, să trecem la câțiva termeni și concepte cheie utilizate în analiza datelor multidimensionale.

Câțiva termeni și concepte

Alături de sume, celulele cubului OLAP pot conține rezultatele executării altor funcții agregate ale limbajului SQL, cum ar fi MIN, MAX, AVG, COUNT și în unele cazuri altele (varianță, abatere standard etc.). Pentru a descrie valorile datelor din celule, se folosește termenul rezumat (în cazul general, pot fi mai multe dintre ele într-un cub), pentru a indica datele inițiale pe baza cărora sunt calculate, termenul măsură este folosit și pentru a indica parametrii de interogare, termenul dimensiune (tradus în rusă de obicei ca „dimensiune” când se face referire la cuburi OLAP și ca „dimensiune” când se referă la depozitele de date). Valorile trasate pe axe se numesc membri ai dimensiunilor.

Apropo de dimensiuni, trebuie menționat că valorile trasate pe axe pot avea diferite niveluri de detaliu. De exemplu, ne poate interesa costul total al comenzilor plasate de clienți din diferite țări, sau costul total al comenzilor efectuate de clienți din alte orașe sau chiar clienți individuali. Desigur, setul rezultat de date agregate în al doilea și al treilea caz va fi mai detaliat decât în ​​primul. Rețineți că posibilitatea de a obține date agregate cu grade diferite de detaliu corespunde uneia dintre cerințele pentru depozitele de date - cerința pentru disponibilitatea diferitelor secțiuni de date pentru comparare și analiză.

Întrucât în ​​exemplul luat în considerare, în cazul general, fiecare țară poate avea mai multe orașe, iar un oraș poate avea mai mulți clienți, putem vorbi despre ierarhii de valori în dimensiuni. În acest caz, țările se află la primul nivel al ierarhiei, orașele sunt la al doilea, iar clienții sunt la al treilea (Fig. 3).

Rețineți că ierarhiile pot fi echilibrate, ca, de exemplu, ierarhia prezentată în Fig. 3 , precum și ierarhii bazate pe date date-ora și cele neechilibrate. Un exemplu tipic de ierarhie dezechilibrată este o ierarhie de tip „subordonat șef” (poate fi construită, de exemplu, folosind valorile câmpului Vânzător din setul de date original din exemplul considerat mai sus), este afișat în fig. 4 .

Uneori, termenul de ierarhie părinte-copil este folosit pentru astfel de ierarhii.

Există și ierarhii care ocupă o poziție intermediară între echilibrat și dezechilibrat (sunt notate cu termenul ragged - „neuniform”). Acestea conțin de obicei membri ai căror „părinți” logici nu se află la nivelul imediat superior (de exemplu, în ierarhia geografică există niveluri Țară, Oraș și Stat, dar în același timp există țări în setul de date care nu au state sau regiuni. între nivelurile Țară și Oraș ; Fig. 5).

Rețineți că ierarhiile dezechilibrate și „inegale” nu sunt acceptate de toate instrumentele OLAP. De exemplu, ambele tipuri de ierarhie sunt acceptate în Microsoft Analysis Services 2000, în timp ce numai cele echilibrate sunt acceptate în Microsoft OLAP Services 7.0. Diferite în diferite instrumente OLAP pot fi numărul de niveluri ierarhice și numărul maxim permis de membri ai unui nivel și numărul maxim posibil de dimensiuni în sine.

Concluzie

În acest articol, ne-am familiarizat cu elementele de bază ale OLAP. Am învățat următoarele:

  • Scopul depozitelor de date este de a oferi utilizatorilor informații pentru analiza statistică și luarea deciziilor de management.
  • Depozitele de date trebuie să ofere o viteză mare de achiziție a datelor, capacitatea de a obține și compara așa-numitele segmente de date, precum și consistența, completitudinea și fiabilitatea datelor.
  • OLAP (On-Line Analytical Processing) este o componentă cheie a construirii și utilizării depozitelor de date. Această tehnologie se bazează pe construcția de seturi de date multidimensionale - cuburi OLAP, ale căror axe conțin parametri, iar celulele conțin date agregate care depind de aceștia.
  • Aplicațiile cu funcționalitate OLAP trebuie să ofere utilizatorului rezultatele analizei într-un timp rezonabil, să efectueze analize logice și statistice, să sprijine accesul multi-utilizator la date, să implementeze o reprezentare conceptuală multidimensională a datelor și să poată accesa orice informație necesară.

În plus, am examinat principiile de bază ale organizării logice a cuburilor OLAP și am învățat, de asemenea, termenii și conceptele de bază utilizate în analiza multidimensională. În cele din urmă, am aflat care sunt diferitele tipuri de ierarhii în dimensiunile cubului OLAP.

În următorul articol al acestei serii, ne vom uita la structura tipică a depozitelor de date, vom vorbi despre ceea ce constituie OLAP client și server și, de asemenea, ne vom opri asupra unor aspecte tehnice ale stocării datelor multidimensionale.

ComputerPress 4 "2001

OLAP (OnLine Analytical Processing) nu este numele unui anumit produs, ci al unei întregi tehnologii de procesare analitică online care implică analiza și raportarea datelor. Utilizatorului i se pune la dispoziție un tabel multidimensional care rezumă automat datele în diverse secțiuni și vă permite să gestionați rapid calculele și forma raportului.

Deși în unele publicații procesarea analitică este numită atât online, cât și interactiv, adjectivul „online” reflectă cel mai exact sensul tehnologiei OLAP. Dezvoltarea deciziilor manageriale de management se încadrează în categoria zonelor cele mai fals susceptibile de automatizare. Cu toate acestea, astăzi există o oportunitate de a asista managerul în elaborarea deciziilor și, cel mai important, de a accelera semnificativ procesul de elaborare a deciziilor, selecția și adoptarea acestora.

Sistemele de sprijin pentru decizii au de obicei mijloacele de a furniza utilizatorului date agregate pentru diverse mostre din setul inițial într-o formă convenabilă pentru percepție și analiză. De regulă, astfel de funcții agregate formează un set de date multidimensionale, adesea numit hipercub sau metacub, ale cărui axe conțin parametri, iar celulele conțin date agregate care depind de ei - și astfel de date pot fi stocate și în tabele relaționale, dar în acest În cazul în care vorbim despre o organizare logică a datelor, și nu despre implementarea fizică a stocării acestora.

De-a lungul fiecărei axe, datele pot fi organizate într-o ierarhie reprezentând diferite niveluri de detaliu.

În funcție de dimensiunile din modelul multidimensional, sunt lăsați deoparte factorii care afectează activitățile întreprinderii (de exemplu: timpul, produsele, ramurile companiei etc.). Cubul OLAP rezultat este apoi umplut cu indicatori ai activității întreprinderii (prețuri, vânzări, plan, profituri, flux de numerar etc.). Trebuie remarcat faptul că, spre deosebire de un cub geometric, fețele unui cub OLAP nu trebuie să aibă aceeași dimensiune. Această umplere poate fi efectuată atât cu date reale ale sistemelor operaționale, cât și previzionate pe baza datelor istorice. Dimensiunile hipercuburilor pot fi complexe, ierarhice și se pot stabili relații între ele. În timpul analizei, utilizatorul poate schimba punctul de vedere asupra datelor (așa-numita operațiune de schimbare a vederii logice), vizualizand astfel datele în diferite secțiuni și rezolvând probleme specifice. Pe cuburi pot fi efectuate diverse operații, inclusiv prognoza și programarea condiționată (analiza ce se întâmplă dacă).

Datorită acestui model de date, utilizatorii pot formula interogări complexe, pot genera rapoarte și pot primi subseturi de date. Prelucrarea analitică operațională poate simplifica și accelera semnificativ procesul de pregătire și luare a deciziilor de către personalul de conducere. Prelucrarea analitică online are scopul de a transforma datele în informații. Este fundamental diferit de procesul tradițional de sprijinire a deciziilor, care se bazează, cel mai adesea, pe luarea în considerare a rapoartelor structurate.


Tehnologia OLAP se referă la tipul de analiză intelectuală și implică 12 principii:

1. Reprezentare conceptuală multidimensională. Utilizatorul-analist vede lumea întreprinderii ca fiind de natură multidimensională, iar modelul OLAP trebuie să fie multidimensional la bază.

2. Transparenţă. Arhitectura sistemului OLAP ar trebui să fie deschisă, permițând utilizatorului, oriunde s-ar afla, să comunice folosind un instrument analitic - clientul - cu serverul.

3. Disponibilitate. Un utilizator analist OLAP trebuie să poată efectua analize bazate pe o schemă conceptuală comună care conține date la nivelul întregii întreprinderi într-o bază de date relațională, precum și date din bazele de date moștenite, pe metode de acces comune și pe un model analitic comun. Un sistem OLAP ar trebui să acceseze doar datele care sunt de fapt necesare și să nu aplice principiul general al „pâlniei de bucătărie” care presupune introducerea inutilă.

4. Performanță constantă în elaborarea rapoartelor. Cu o creștere a numărului de dimensiuni sau a dimensiunii bazei de date, utilizatorul analist nu ar trebui să experimenteze o scădere semnificativă a performanței.

5. Arhitectura client-server. Majoritatea datelor care astăzi trebuie supuse prelucrării analitice online sunt conținute pe mainframe cu acces la stațiile de lucru ale utilizatorilor prin LAN. Aceasta înseamnă că produsele OLAP trebuie să poată funcționa într-un mediu client-server.

6. Multidimensionalitate generală. Fiecare dimensiune ar trebui aplicată indiferent de structura și capacitățile sale operaționale. Structurile de date subiacente, formulele și formatele de raportare nu ar trebui să fie părtinitoare către nicio dimensiune.

7. Managementul dinamic al matricelor rare. Designul fizic al unui instrument OLAP trebuie să fie pe deplin adaptabil la modelul analitic specific pentru a gestiona optim matricele rare. Sparsitatea (măsurată ca procent de celule goale față de toate cele posibile) este una dintre caracteristicile propagării datelor.

8. Suport multi-utilizator. Un instrument OLAP trebuie să ofere capacitatea de a partaja interogări și de a crește mai mulți utilizatori analiști, menținând în același timp integritatea și securitatea.

9. Operațiuni încrucișate nelimitate. Diverse operații, datorită naturii lor ierarhice, pot reprezenta relații de dependență în modelul OLAP, adică sunt transversale. Execuția lor nu ar trebui să solicite utilizatorului analist să redefiniți aceste calcule și operațiuni.

10. Manipularea intuitivă a datelor. Vizualizarea utilizatorului analist asupra dimensiunilor definite în modelul analitic trebuie să conțină toate informațiile necesare pentru a efectua acțiuni pe modelul OLAP, i.e. nu ar trebui să necesite utilizarea unui sistem de meniu sau a altor operațiuni cu interfețe cu utilizatorul multiple.

11. Opțiuni flexibile de raportare. Instrumentele de raportare ar trebui să fie sintetizate date sau informații rezultate din modelul de date în orice orientare posibilă. Aceasta înseamnă că rândurile, coloanele sau paginile unui raport trebuie să afișeze mai multe dimensiuni ale unui model OLAP în același timp, cu posibilitatea de a afișa orice subset de elemente (valori) conținute în dimensiune și în orice ordine.

12. Dimensiune și număr nelimitat de niveluri de agregare. Un studiu privind numărul posibil de măsurători necesare necesare într-un model analitic a arătat că până la 19 măsurători pot fi utilizate simultan de către un utilizator analist. Aceasta conduce la o recomandare cu privire la numărul de dimensiuni suportate de sistemul OLAP. Mai mult, fiecare dintre dimensiunile comune nu ar trebui să fie limitată de numărul de niveluri de agregare definite de analistul utilizator.

Ca sisteme OLAP specializate oferite în prezent pe piață, puteți specifica CalliGraph, Business Intelligence.

Pentru a rezolva sarcini simple de analiză a datelor, este posibil să utilizați o soluție bugetară - aplicațiile de birou Microsoft Excel și Access, care conțin instrumente tehnologice elementare OLAP care vă permit să creați tabele pivot și să construiți diverse rapoarte pe baza acestora.

Conceptul de analiză multidimensională a datelor este strâns legat de analiza operațională, care se realizează prin intermediul sistemelor OLAP.

OLAP (On-Line Analytical Processing) este o tehnologie pentru prelucrarea online a datelor analitice care folosește metode și instrumente de colectare, stocare și analiză a datelor multidimensionale pentru a sprijini procesele decizionale.

Scopul principal al sistemelor OLAP este de a susține activități analitice, solicitări arbitrare (deseori se folosește termenul ad-hoc) de la utilizatorii analiști. Scopul analizei OLAP este de a testa ipotezele emergente.

La originile tehnologiei OLAP se află fondatorul abordării relaționale E. Codd. În 1993, a publicat un articol intitulat „OLAP for Analyst Users: What It Should Be”. Această lucrare conturează conceptele de bază ale procesării analitice online și identifică următoarele 12 cerințe care trebuie îndeplinite de produsele care permit prelucrarea analitică online. Tokmakov G.P. Bază de date. Concept de bază de date, model de date relaționale, limbaje SQL. S. 51

Mai jos sunt enumerate cele 12 reguli pe care Codd le-a conturat care definesc OLAP.

1. Multidimensionalitate - Sistemul OLAP la nivel conceptual ar trebui să prezinte datele sub forma unui model multidimensional, care simplifică procesele de analiză și percepție a informațiilor.

2. Transparență – Un sistem OLAP ar trebui să ascundă utilizatorului implementarea reală a unui model multidimensional, metoda de organizare, sursele, instrumentele de procesare și stocare.

3. Disponibilitate -- Un sistem OLAP trebuie să ofere utilizatorului un model de date unic, consecvent și consecvent, permițând accesul la date, indiferent de cum sau unde sunt stocate.

4. Performanță consecventă în elaborarea rapoartelor -- Performanța sistemelor OLAP nu ar trebui să scadă semnificativ pe măsură ce crește numărul de dimensiuni analizate.

5. Arhitectura client-server -- Un sistem OLAP trebuie să poată funcționa într-un mediu client-server, așa cum majoritatea datelor care astăzi trebuie supuse prelucrării analitice online sunt stocate distribuite. Ideea principală aici este că componenta server a instrumentului OLAP ar trebui să fie suficient de inteligentă pentru a permite construirea unei scheme conceptuale comune bazată pe generalizarea și consolidarea diferitelor scheme de baze de date logice și fizice ale întreprinderii pentru a oferi un efect transparent.

6. Egalitatea dimensiunilor -- Un sistem OLAP trebuie să suporte un model multidimensional în care toate dimensiunile sunt egale. Dacă este necesar, pot fi furnizate caracteristici suplimentare măsurătorilor individuale, dar o astfel de oportunitate ar trebui oferită oricărei măsurători.

7. Gestionarea dinamică a matricelor rare -- Un sistem OLAP trebuie să ofere o manipulare optimă a matricelor rare. Rata de acces trebuie menținută indiferent de locația celulelor de date și să fie o valoare constantă pentru modelele cu un număr diferit de dimensiuni și un grad diferit de rară de date.

8. Suport pentru modul multi-utilizator - Sistemul OLAP ar trebui să ofere capacitatea de a lucra cu mai mulți utilizatori împreună cu un model analitic sau de a crea modele diferite pentru aceștia dintr-o singură dată. În același timp, sunt posibile atât citirea, cât și scrierea datelor, astfel încât sistemul trebuie să asigure integritatea și securitatea acestora.

9. Operații încrucișate nelimitate -- Un sistem OLAP trebuie să se asigure că relațiile funcționale descrise folosind un anumit limbaj formal între celulele hipercubului sunt păstrate atunci când se efectuează orice operațiuni de tăiere, rotire, consolidare sau detaliere. Sistemul ar trebui să realizeze în mod independent (automat) transformarea relațiilor stabilite, fără a solicita utilizatorului să le redefinească.

10. Manipularea intuitivă a datelor -- Un sistem OLAP trebuie să ofere o modalitate de a efectua operațiuni de tăiere, rotire, consolidare și forare pe un hipercub, fără ca utilizatorul să fie nevoit să facă multă muncă în interfața utilizatorului. Dimensiunile definite în modelul analitic trebuie să conţină toate informaţiile necesare pentru efectuarea operaţiilor de mai sus.

11. Opțiuni flexibile de raportare -- Un sistem OLAP trebuie să accepte diferite moduri de vizualizare a datelor, de ex. rapoartele trebuie prezentate în orice orientare posibilă. Instrumentele de raportare ar trebui să reprezinte date sintetizate sau informații rezultate din modelul de date în orice orientare posibilă. Aceasta înseamnă că rândurile, coloanele sau paginile ar trebui să arate simultan de la 0 la N dimensiuni, unde N este numărul de dimensiuni ale întregului model analitic. În plus, fiecare dimensiune de conținut afișată într-o singură postare, coloană sau pagină trebuie să permită ca orice subset de elemente (valori) conținute în dimensiune să fie afișat în orice ordine.

12. Dimensiune nelimitată și număr de niveluri de agregare - Un studiu asupra numărului posibil de dimensiuni necesare cerute într-un model analitic a arătat că până la 19 dimensiuni pot fi utilizate simultan. De aici recomandarea puternică ca instrumentul analitic să poată furniza cel puțin 15 și, de preferință, 20 de măsurători simultan. Mai mult, fiecare dintre dimensiunile comune nu ar trebui să fie limitată de numărul de niveluri de agregare și de căi de consolidare definite de analistul utilizator.

Reguli suplimentare ale Codd.

Setul acestor cerințe, care a servit drept definiție de facto a OLAP, provoacă destul de des diverse critici, de exemplu, regulile 1, 2, 3, 6 sunt cerințe, iar regulile 10, 11 sunt dorințe neformalizate. Tokmakov G.P. Bază de date. Concept de bază de date, model de date relaționale, limbaje SQL. P. 68 Astfel, cele 12 cerințe enumerate ale Codd nu vă permit să definiți cu exactitate OLAP. În 1995, Codd a adăugat următoarele șase reguli pe listă:

13. Extragerea loturilor vs. interpretare -- Un sistem OLAP trebuie să fie la fel de eficient pentru a oferi acces atât la datele interne, cât și la cele externe.

14. Suport pentru toate modelele de analiză OLAP -- Un sistem OLAP trebuie să accepte toate cele patru modele de analiză a datelor definite de Codd: categoric, interpretativ, speculativ și stereotip.

15. Manipularea datelor denormalizate -- Un sistem OLAP trebuie integrat cu surse de date denormalizate. Modificările aduse datelor într-un mediu OLAP nu ar trebui să aibă ca rezultat modificări ale datelor stocate în sistemele externe originale.

16. Salvarea rezultatelor OLAP: păstrarea lor separată de datele originale -- Un sistem OLAP care funcționează în modul citire-scriere, după modificarea datelor originale, trebuie să salveze rezultatele separat. Cu alte cuvinte, securitatea datelor sursă este asigurată.

17. Excluderea valorilor lipsă-- Când prezintă date utilizatorului, un sistem OLAP trebuie să elimine toate valorile lipsă. Cu alte cuvinte, valorile lipsă trebuie să fie diferite de valorile nule.

18 Gestionarea valorilor lipsă -- Un sistem OLAP trebuie să ignore toate valorile lipsă, indiferent de sursa lor. Această caracteristică este legată de regula a 17-a.

În plus, Codd a împărțit toate cele 18 reguli în următoarele patru grupuri, numindu-le caracteristici. Aceste grupuri au fost denumite B, S, R și D.

Principalele caracteristici (B) includ următoarele reguli:

Reprezentarea conceptuală multidimensională a datelor (regula 1);

Manipularea intuitivă a datelor (regula 10);

Disponibilitate (regula 3);

Extragerea lotului versus interpretare (regula 13);

Suport pentru toate modelele de analiză OLAP (regula 14);

Arhitectura „client-server” (regula 5);

Transparență (regula 2);

Suport multiplayer (regula 8)

Caracteristici speciale (S):

Prelucrarea datelor nenormalizate (regula 15);

Salvarea rezultatelor OLAP: stocarea acestora separat de datele originale (regula 16);

Excluderea valorilor lipsă (regula 17);

Gestionarea valorilor lipsă (regula 18). Caracteristici de raportare (R):

Flexibilitatea generării rapoartelor (regula 11);

Standardul de performanță al raportului (regula 4);

Configurare automată a stratului fizic (regula originală modificată 7).

Control de măsurare (D):

Universalitatea măsurătorilor (regula 6);

Număr nelimitat de dimensiuni și niveluri de agregare (regula 12);

Operații nelimitate între dimensiuni (regula 9).

dirijarea

S-au scris multe despre OLAP în ultima vreme. Putem spune că există un oarecare boom în jurul acestor tehnologii. Adevărat, pentru noi acest boom este oarecum târziu, dar asta se datorează, desigur, situației generale din țară.

Sistemele informaționale la scară de întreprindere, de regulă, conțin aplicații concepute pentru analiza multidimensională complexă a datelor, dinamica, tendințele acestora etc. O astfel de analiză are scopul în cele din urmă de a ajuta la luarea deciziilor. Adesea aceste sisteme sunt numite sisteme de sprijinire a deciziei.

Sistemele de sprijin pentru decizii au de obicei mijloacele de a furniza utilizatorului date agregate pentru diverse mostre din setul inițial într-o formă convenabilă pentru percepție și analiză. De regulă, astfel de funcții agregate formează un set de date multidimensionale (și, prin urmare, non-relaționale) (numit adesea hipercub sau metacub), ale cărui axe conțin parametri, iar celulele conțin date agregate care depind de ei - și astfel de date pot fi, de asemenea, stocate î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, datele pot fi organizate într-o ierarhie reprezentând diferite niveluri de detaliu. Datorită acestui model de date, utilizatorii pot formula interogări complexe, pot genera rapoarte și pot primi subseturi de date.

Tehnologia analizei complexe a datelor multidimensionale se numeste OLAP (On-Line Analytical Processing).

OLAP este o componentă cheie a depozitării datelor.

Conceptul de OLAP a fost descris în 1993 de Edgar Codd, un cunoscut cercetător de baze de date și autor al modelului de date relaționale.E.F. Codd, S.B. Codd și C.T.Salley, Furnizarea de OLAP (prelucrare analitică on-line) utilizatorilor-analiști: un mandat IT. raport tehnic, 1993).

În 1995, pe baza cerințelor conturate de Codd, a fost formulat așa-numitul test FASMI (Fast Analysis of Shared Multidimensional Information - fast analysis of shared multidimensional information), care include următoarele cerințe pentru aplicațiile de analiză multidimensională:

· furnizarea utilizatorului cu rezultatele analizei î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ă specifică acestei aplicații și de a o salva într-o formă accesibilă utilizatorului final;

· acces multi-utilizator la date cu suport pentru mecanisme de blocare adecvate și instrumente de acces autorizate;

· reprezentarea conceptuală multidimensională a datelor, inclusiv suport complet 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ă în diverse moduri, de la cele mai simple instrumente de analiză a datelor din aplicații de birou până la sisteme analitice distribuite bazate pe produse server. Utilizatorii pot vizualiza cu ușurință datele dintr-o structură multidimensională aplicate propriilor sarcini.

2. Ce este OLAP

OLAP - o abreviere pentru engleza On-Line Analytical Processing - nu este numele unui produs anume, ci al unei intregi tehnologii. În rusă, cel mai convenabil este să apelați procesarea analitică operațională OLAP. Deși în unele publicații procesarea analitică este numită atât online, cât și interactiv, adjectivul „online” reflectă cel mai exact sensul tehnologiei OLAP.

Dezvoltarea deciziilor manageriale de management se încadrează în categoria domeniilor cel mai greu de automatizat. Cu toate acestea, astăzi există o oportunitate de a asista managerul în elaborarea deciziilor și, cel mai important, de a accelera semnificativ procesul de elaborare a deciziilor, selecția și adoptarea acestora. Puteți utiliza OLAP pentru aceasta.

Luați în considerare cum are loc de obicei procesul de dezvoltare a soluțiilor.

Din punct de vedere istoric, soluțiile de automatizare a activităților operaționale sunt cele mai dezvoltate. Vorbim despre sisteme de prelucrare a datelor tranzacționale (OLTP), numite simplu sisteme operaționale. Aceste sisteme asigură înregistrarea unor fapte, păstrarea lor pe termen scurt și păstrarea în arhive. Baza unor astfel de sisteme este asigurată de sistemele de management al bazelor de date relaționale (RDBMS). Abordarea tradițională constă în încercarea de a utiliza sisteme operaționale deja construite pentru suport decizional. De obicei, ei încearcă să construiască un sistem dezvoltat de interogări către sistemul de operare și folosesc rapoartele primite după interpretare direct pentru a sprijini deciziile. Rapoartele pot fi construite pe o bază personalizată, de ex. managerul solicită un raport, și în mod regulat, atunci când rapoartele sunt construite la atingerea anumitor evenimente sau momente. De exemplu, un proces tradițional de sprijinire a deciziilor ar putea arăta astfel: managerul merge la specialistul în informații și îi împărtășește întrebarea. Apoi specialistul în informații construiește o solicitare către sistemul operațional, primește un raport electronic, îl interpretează, apoi îl aduce în atenția personalului de conducere. Desigur, o astfel de schemă oferă suport pentru decizii într-o oarecare măsură, dar are o eficiență extrem de scăzută și un număr mare de dezavantaje. O cantitate mică de date este utilizată pentru a sprijini deciziile critice. Mai sunt si alte probleme. Un astfel de proces este foarte lent, deoarece procesul de scriere a cererilor și interpretarea unui raport electronic este lung. Este nevoie de multe zile, într-un moment în care un lider poate avea nevoie să ia o decizie chiar acum, imediat. Dacă luăm în considerare faptul că managerul, după primirea raportului, poate fi interesat de o altă problemă (să zicem, clarificarea sau solicitarea luării în considerare a datelor într-un context diferit), atunci acest ciclu lent trebuie repetat, iar din moment ce procesul de analiză datele din sistemele operaționale vor fi iterative, apoi se petrece și mai mult timp. O altă problemă este problema diferitelor domenii de activitate ale unui specialist în tehnologia informației și al unui manager, care pot gândi în diferite categorii și, ca urmare, nu se înțeleg. Apoi vor fi necesare iterații suplimentare de rafinare și acesta este din nou momentul, care nu este întotdeauna suficient. O altă problemă importantă este complexitatea rapoartelor de înțeles. Managerul nu are timp să selecteze numerele de interes din raport, mai ales că pot fi prea multe dintre ele (reamintim rapoarte uriașe cu mai multe pagini care folosesc de fapt mai multe pagini, iar restul pentru orice eventualitate). Mai remarcăm că munca de interpretare revine cel mai adesea specialiştilor din departamentele de informare. Adică, un specialist competent este distras de munca de rutină și ineficientă la desenarea diagramelor etc., care, desigur, nu poate afecta în mod favorabil calificările sale. În plus, nu este un secret faptul că în lanțul de interpretare există binevoitori care sunt interesați de denaturarea deliberată a informațiilor primite.

Neajunsurile de mai sus ne fac să ne gândim atât la eficiența generală a sistemului operațional, cât și la costurile asociate cu existența acestuia, deoarece se dovedește că costurile creării unui sistem operațional nu sunt compensate în măsura adecvată de eficiența muncii sale.

De fapt, aceste probleme nu sunt o consecință a calității proaste a sistemului de operare sau a construcției nereușite a acestuia. Rădăcinile problemelor se află în diferența fundamentală dintre activitățile operaționale care sunt automatizate de sistemul operațional și activitățile de dezvoltare și luare a deciziilor. Această diferență constă în faptul că datele sistemelor operaționale sunt pur și simplu înregistrări ale unor evenimente care au avut loc, fapte, dar nu informații în sensul general al cuvântului. Informația este ceva care reduce incertitudinea în orice domeniu. Și ar fi foarte frumos dacă informațiile ar reduce incertitudinea în pregătirea deciziilor. Celebrul E.F. Codd, omul care a fost pionier în tehnologia de gestionare a bazelor de date relaționale în anii 1970: „Deși sistemele de gestionare a bazelor de date relaționale sunt disponibile pentru utilizatori, ele nu au fost niciodată considerate un instrument care oferă funcții puternice de sinteză, analiză și consolidare (funcții numite analiză multidimensională a datelor)” . Vorbim despre sinteza informațiilor, despre cum să transformăm datele sistemelor operaționale în informații și chiar în evaluări calitative. OLAP vă permite să faceți această transformare.

OLAP se bazează pe ideea unui model de date multidimensional. Gândirea umană este multidimensională prin definiție. Când o persoană pune întrebări, el impune restricții, formulând astfel întrebări în mai multe dimensiuni, astfel încât procesul de analiză într-un model multidimensional este foarte apropiat de realitatea gândirii umane. În funcție de dimensiunile din modelul multidimensional, factorii care afectează activitățile întreprinderii sunt amânați (de exemplu: timpul, produsele, departamentele companiei, geografia etc.). Astfel, se obține un hipercub (desigur, numele nu este foarte potrivit, deoarece un cub este de obicei înțeles ca o figură cu margini egale, ceea ce, în acest caz, este departe de a fi cazul), care este apoi umplut cu indicatori. a activității întreprinderii (prețuri, vânzări, plan, profituri, pierderi etc.) etc.). Această umplere poate fi efectuată atât cu date reale ale sistemelor operaționale, cât și previzionate pe baza datelor istorice. Dimensiunile hipercuburilor pot fi complexe, ierarhice și se pot stabili relații între ele. În timpul analizei, utilizatorul poate schimba punctul de vedere asupra datelor (așa-numita operațiune de schimbare a vederii logice), vizualizand astfel datele în diferite secțiuni și rezolvând probleme specifice. Pe cuburi pot fi efectuate diverse operații, inclusiv prognoza și programarea condiționată (analiza ce se întâmplă dacă). Mai mult, operațiunile sunt efectuate deodată pe cuburi, adică. produsul, de exemplu, va avea ca rezultat un produs hipercub, fiecare celulă a căruia este un produs al celulelor hipercuburilor multiplicatoare corespunzătoare. Desigur, este posibil să se efectueze operații pe hipercuburi care au un număr diferit de dimensiuni.

3. Istoria creării tehnologiei OLAP

Ideea procesării datelor pe matrice multidimensionale nu este nouă. De fapt, datează din 1962, când Ken Iverson și-a publicat cartea A Programming Language (APL). Prima implementare practică a APL a avut loc la sfârșitul anilor șaizeci de către IBM. APL este un limbaj foarte elegant, definit matematic, cu variabile multidimensionale și operații gestionate. Acesta a fost intenționat să fie instrumentul original puternic pentru lucrul cu transformări multidimensionale în comparație cu alte limbaje practice de programare.

Cu toate acestea, ideea nu a primit o aplicare în masă de mult timp, deoarece nu venise încă timpul pentru interfețe grafice, dispozitive de imprimare de înaltă calitate, iar afișarea caracterelor grecești necesita ecrane speciale, tastaturi și dispozitive de imprimare. Mai târziu, cuvintele englezești au fost uneori folosite pentru a înlocui operatorii greci, dar luptătorii de puritate APL au zădărnicit încercările de a populariza limba lor preferată. APL consuma și resursele mașinii. În acele zile, utilizarea sa era costisitoare. Programele erau foarte lente de rulat și, în plus, erau foarte scumpe de rulat. Era nevoie de multă memorie, la acea vreme doar volume șocante (aproximativ 6 MB).

Cu toate acestea, enervarea acestor greșeli inițiale nu a distrus ideea. A fost folosit în multe aplicații de afaceri în anii 70 și 80. Multe dintre aceste aplicații aveau caracteristici ale sistemelor moderne de procesare analitică. Așa că IBM a dezvoltat un sistem de operare pentru APL numit VSPC, iar unii oameni l-au considerat mediul ideal pentru uz personal până când foile de calcul au devenit omniprezente.

Dar APL a fost prea greu de utilizat, mai ales că de fiecare dată au existat inconsecvențe între limbajul în sine și hardware-ul pe care s-a încercat să fie implementat.

În anii 1980, APL a devenit disponibil pe mașinile personale, dar nu a găsit utilizare pe piață. Alternativa a fost programarea aplicațiilor multidimensionale folosind matrice în alte limbi. Aceasta a fost o sarcină foarte dificilă chiar și pentru programatorii profesioniști, ceea ce ia forțat să aștepte următoarea generație de produse software multidimensionale.

În 1972, mai multe aplicații software multidimensionale utilizate anterior în scopuri educaționale și-au găsit uz comercial: Express. Rămâne într-o formă complet rescrisă și acum, totuși, conceptele originale din anii 70 au încetat să mai fie relevante. Astăzi, în anii 90, Express este una dintre cele mai populare tehnologii OLAP, iar Oracle(r) va continua să o promoveze și să adauge noi funcții.

Mai multe produse multidimensionale au apărut în anii 80. La începutul deceniului, un produs numit Stratagem, numit mai târziu Acumate (acum deținut de Kenan Technologies), care a fost încă promovat până la începutul anilor 90, dar astăzi, spre deosebire de Express, nu este practic folosit.

Comshare System W a fost un produs multidimensional cu un stil diferit. Introdus în 1981, a fost primul care s-a concentrat mai mult pe utilizatorul final și pe dezvoltarea de aplicații financiare. Acesta a introdus multe concepte care nu au fost bine adaptate, cum ar fi reguli complet non-procedurale, vizualizarea pe tot ecranul și editarea datelor multidimensionale, recalcularea automată și integrarea loturilor cu datele relaționale. Cu toate acestea, Comshare System W era destul de greu pentru hardware-ul vremii în comparație cu alte produse și a fost folosit mai puțin în viitor, s-a vândut mai puțin și nu s-au adus îmbunătățiri produsului. Deși este încă disponibil pe UNIX și astăzi, nu este client-server, ceea ce nu ajută la creșterea ofertei sale pe piața produselor analitice. La sfârșitul anilor 80, Comshare a lansat un produs pentru DOS și mai târziu pentru Windows. Aceste produse au fost numite Commander Prism și au folosit aceleași concepte ca și System W.

Un alt produs creativ de la sfârșitul anilor 80 se numea Metaphor. A fost destinat marketerilor profesioniști. De asemenea, a propus multe concepte noi care abia acum încep să fie utilizate pe scară largă: calculul client-server, utilizarea unui model multidimensional pe date relaționale, dezvoltarea aplicațiilor orientate pe obiecte. Cu toate acestea, hardware-ul PC-ului standard al zilei nu era capabil să ruleze Metaphor, iar vânzătorii au fost forțați să-și dezvolte propriile standarde pentru computere și rețele. Treptat, Metaphor a început să funcționeze cu succes pe mașinile personale în serie, dar produsul a fost realizat exclusiv pentru OS / 2 și avea propria interfață grafică cu utilizatorul.

Apoi, Metaphor a intrat într-o alianță de marketing cu IBM, care a fost absorbită ulterior. La mijlocul anului 1994, IBM a decis să integreze tehnologia Metaphor (redenumită DIS) cu tehnologiile sale viitoare și, prin urmare, să nu mai finanțeze o direcție separată, dar clienții și-au exprimat nemulțumirea și au cerut sprijin continuu pentru produs. Suportul a fost continuat pentru clienții rămași, iar IBM a relansat produsul sub noul nume DIS, ceea ce, totuși, nu l-a făcut popular. Dar conceptele creative și inovatoare ale Metaphor nu au fost uitate și sunt vizibile în multe produse astăzi.

La mijlocul anilor '80 s-a născut termenul EIS (Executive Information System). Primul produs care a demonstrat clar această direcție a fost Pilot's Command Center. A fost un produs care a permis calculul colaborativ, ceea ce numim astăzi calcul client-server. Deoarece puterea computerelor personale în anii 80 era limitată, produsul era foarte „centrat pe server”, dar acest principiu este și astăzi foarte popular. Pilot nu a vândut Centrul de Comandă pentru mult timp, dar a oferit multe dintre conceptele care sunt recunoscute în produsele OLAP de astăzi, inclusiv suport pentru sincronizare automată, calcul multidimensional client-server și control simplificat al procesului de analiză (mouse, ecrane sensibile etc. ). Unele dintre aceste concepte au fost reaplicate mai târziu în Pilot Analysis Server.

La sfârșitul anilor 1980, foile de calcul dominau piața instrumentelor de analiză pentru utilizatorii finali. Prima foaie de calcul multidimensională a fost introdusă de produsul Compete. A fost comercializat ca un produs foarte scump pentru profesioniști, dar vânzătorii nu au reușit să se asigure că produsul ar putea capta piața, iar Computer Associates a achiziționat drepturile asupra acestuia împreună cu alte produse, inclusiv Supercalc și 20/20. Principalul efect al achiziției CA Compete a fost o reducere bruscă a prețului acestuia și eliminarea protecției împotriva copierii, ceea ce a contribuit în mod firesc la distribuția sa. Cu toate acestea, nu a avut succes. Competența se află în centrul Supercalc 5, dar aspectul multidimensional al acestuia nu este promovat. Vechiul Compete este încă folosit uneori datorită faptului că la un moment dat s-au investit mulți bani în el.

Lotus a fost următorul care a încercat să intre pe piața foilor de calcul multidimensionale cu produsul Improv, care rulează pe mașina NeXT. Acest lucru a asigurat, cel puțin, că vânzările de 1-2-3 nu vor scădea, dar când a fost lansat în cele din urmă pentru Windows, Excel avea deja o cotă mare de piață, ceea ce a împiedicat Lotus să facă orice modificări în distribuția pieței. Lotus, la fel ca CA cu Compete, a mutat Improv la partea de jos a pieței, dar aceasta nu a devenit o condiție pentru promovarea de succes pe piață, iar noile dezvoltări în acest domeniu nu au continuat. S-a dovedit că utilizatorii de computere personale preferau foile de calcul 1-2-3 și nu erau interesați de noi caracteristici multidimensionale decât dacă erau pe deplin compatibile cu vechile foi de calcul. De asemenea, conceptele de foi mici de calcul desktop oferite ca aplicații personale nu s-au dovedit cu adevărat convenabile și nu au prins în lumea afacerilor reale. Microsoft(r) a urmat această cale adăugând tabele pivot în Excel. Deși puțini utilizatori Excel au beneficiat de utilizarea acestei caracteristici, acesta este probabil singurul fapt că capabilitățile de analiză multivariată sunt utilizate pe scară largă în lume, pur și simplu pentru că există atât de mulți utilizatori Excel în lume.

4. OLAP, ROLAP, MOLAP...

Este bine cunoscut faptul că atunci când Codd și-a publicat regulile pentru construirea DBMS-ului relațional în 1985, acestea au provocat o reacție puternică și, ulterior, au avut un impact puternic asupra industriei DBMS în general. Cu toate acestea, puțini oameni știu că în 1993 Codd a publicat o lucrare numită „OLAP for Analyst Users: What It Should Be”. În acesta, el a subliniat conceptele de bază ale procesării analitice online și a identificat 12 reguli pe care produsele trebuie să le îndeplinească pentru a oferi procesare analitică online.

Iată regulile (textul original păstrat acolo unde este posibil):

1. Reprezentare conceptuală multidimensională. Utilizatorul analist vede lumea întreprinderii ca fiind de natură multidimensională. În consecință, modelul OLAP trebuie să fie multidimensional în baza sa. O diagramă conceptuală multidimensională sau o reprezentare personalizată facilitează modelarea și analiza, precum și calculele.

2. Transparență. Indiferent dacă produsul OLAP face parte sau nu din instrumentele utilizatorului, acest fapt trebuie să fie transparent pentru utilizator. Dacă OLAP este furnizat de calculul client-server, atunci acest fapt ar trebui, de asemenea, dacă este posibil, să fie invizibil pentru utilizator. OLAP ar trebui să fie livrat în contextul unei arhitecturi cu adevărat deschise, permițând utilizatorului, oriunde s-ar afla, să comunice cu serverul folosind un instrument analitic. În plus, transparența trebuie realizată și atunci când instrumentul analitic interacționează cu medii de baze de date omogene și eterogene.

3. Disponibilitate. Un utilizator analist OLAP trebuie să poată efectua analize bazate pe o schemă conceptuală comună care conține date la nivelul întregii întreprinderi într-o bază de date relațională, precum și date din bazele de date moștenite, pe metode de acces comune și pe un model analitic comun. Aceasta înseamnă că OLAP trebuie să ofere propria logică pentru acces într-un mediu de bază de date eterogen și să efectueze transformările corespunzătoare pentru a prezenta datele utilizatorului. Mai mult, este necesar să aveți grijă în prealabil despre unde și cum și ce tipuri de organizare fizică a datelor vor fi utilizate efectiv. Un sistem OLAP ar trebui să acceseze doar datele care sunt de fapt necesare și nu trebuie să aplice principiul general al „pâlniei de bucătărie” care implică introduceri inutile.

4. Productivitate constantă în elaborarea rapoartelor. Dacă numărul de dimensiuni sau dimensiunea bazei de date crește, utilizatorul analist nu ar trebui să experimenteze nicio degradare semnificativă a performanței. Performanța constantă este esențială pentru menținerea ușurinței de utilizare a utilizatorului final și limitarea complexității OLAP. Dacă utilizatorul analist se confruntă cu diferențe semnificative de performanță în funcție de numărul de dimensiuni, atunci analistul va tinde să compenseze aceste diferențe printr-o strategie de dezvoltare, ceea ce va determina ca datele să fie prezentate în alte moduri decât modul în care datele trebuie de fapt să fie prezentate. fi prezentat. Pierderea timpului ocolind sistemul pentru a compensa inadecvarea acestuia nu este scopul pentru care sunt concepute produsele de analiză.

5. Arhitectura client-server. Cele mai multe dintre datele necesare pentru analiza online astăzi rezidă pe mainframe accesate prin intermediul computerelor. Aceasta înseamnă, prin urmare, că produsele OLAP trebuie să poată funcționa într-un mediu client-server. Din acest punct de vedere, este esențial ca componenta de server a instrumentului de analiză să fie substanțial „inteligentă”, astfel încât diferiți clienți să se poată alătura serverului cu un minim de bătăi de cap și programare de integrare. Serverul „inteligent” trebuie să fie capabil să mapeze și să consolideze între schemele de baze de date logice și fizice neadecvate. Acest lucru va asigura transparența și construirea unei scheme conceptuale, logice și fizice comune.

6. Multidimensionalitate generală. Fiecare dimensiune ar trebui aplicată indiferent de structura și capacitățile sale operaționale. Capabilități operaționale suplimentare pot fi acordate dimensiunilor selectate și, deoarece dimensiunile sunt simetrice, o singură funcție poate fi dată oricărei dimensiuni. Structurile de date subiacente, formulele și formatele de raportare nu ar trebui să fie părtinitoare către nicio dimensiune.

7. Controlul dinamic al matricelor rare. Designul fizic al unui instrument OLAP trebuie să fie pe deplin adaptabil la modelul analitic specific pentru a gestiona optim matricele rare. Pentru orice matrice rară dată, există una și o singură schemă fizică optimă. Această schemă oferă eficiență maximă a memoriei și operabilitate a matricei, cu excepția cazului în care, desigur, întregul set de date se încadrează în memorie. Datele fizice de bază ale unui instrument OLAP trebuie configurate la orice subset de dimensiuni, în orice ordine, pentru operațiuni practice cu modele analitice mari. Metodele de acces fizic ar trebui, de asemenea, să se schimbe dinamic și să conțină diverse tipuri de mecanisme, cum ar fi: calcule directe, arbori B și derivate, hashing, capacitatea de a combina aceste mecanisme dacă este necesar. Sparsitatea (măsurată ca procent de celule goale față de toate cele posibile) este una dintre caracteristicile propagării datelor. Incapacitatea de a controla dispersitatea poate face ca eficiența operațiunilor să nu fie atinsă. Dacă un instrument OLAP nu poate controla și reglementa distribuția valorilor datelor analizate, un model care se pretinde practic, bazat pe multe căi și dimensiuni de consolidare, poate fi de fapt inutil și fără speranță.

8. Suport multi-utilizator. Adesea, mai mulți utilizatori analiști vor trebui să lucreze împreună pe același model analitic sau să creeze modele diferite din aceleași date. Prin urmare, un instrument OLAP trebuie să ofere capabilități de partajare (interogare și anexare), integritate și securitate.

9. Operațiuni încrucișate nelimitate. Diferitele niveluri de acumulare și căi de consolidare, datorită naturii lor ierarhice, reprezintă relații de dependență într-un model sau aplicație OLAP. Prin urmare, instrumentul în sine ar trebui să implice calculele adecvate și să nu solicite utilizatorului analist să redefinească acele calcule și operațiuni. Calculele care nu decurg din aceste relații moștenite trebuie definite prin formule diferite în funcție de limbajul aplicabil. Un astfel de limbaj poate permite calcule și manipulare cu date de orice dimensiune și nu limitează relația dintre celulele de date, nu acordă atenție numărului de atribute comune de date ale celulelor specifice.

10. Manipularea intuitivă a datelor. Reorientarea căilor de consolidare, detalierea, mărirea și alte manipulări reglementate de căile de consolidare ar trebui aplicate printr-o acțiune separată asupra celulelor modelului analitic și nu ar trebui să necesite utilizarea unui sistem de meniu sau alte acțiuni multiple cu interfața cu utilizatorul. Vizualizarea utilizatorului analist asupra dimensiunilor definite în modelul analitic trebuie să conțină toate informațiile necesare pentru a efectua acțiunile de mai sus.

11. Opțiuni flexibile de raportare. Analiza și prezentarea datelor este simplă atunci când rândurile, coloanele și celulele datelor care vor fi comparate vizual între ele vor fi apropiate unele de altele sau în funcție de o funcție logică care are loc în întreprindere. Instrumentele de raportare ar trebui să reprezinte date sintetizate sau informații rezultate din modelul de date în orice orientare posibilă. Aceasta înseamnă că rândurile, coloanele sau paginile ar trebui să arate simultan de la 0 la N dimensiuni, unde N este numărul de dimensiuni ale întregului model analitic. În plus, fiecare dimensiune de conținut afișată într-o singură înregistrare, coloană sau pagină trebuie, de asemenea, să poată afișa orice subset de elemente (valori) conținute în dimensiune, în orice ordine.

12. Dimensiune și număr nelimitat de niveluri de agregare. Un studiu privind numărul posibil de măsurători necesare necesare într-un model analitic a arătat că până la 19 măsurători pot fi utilizate simultan. Prin urmare, se recomandă insistent ca instrumentul analitic să poată furniza cel puțin 15 dimensiuni simultan și de preferință 20. Mai mult, fiecare dintre dimensiunile comune nu ar trebui să fie limitată de numărul de niveluri de agregare și de căi de consolidare definite de utilizatorul analist.

De fapt, dezvoltatorii de produse OLAP de astăzi urmează aceste reguli, sau cel puțin se străduiesc să le respecte. Aceste reguli pot fi considerate baza teoretică a prelucrării analitice operaționale, fiind greu de argumentat cu ele. Ulterior, din cele 12 reguli au fost deduse multe consecințe pe care însă nu le vom da pentru a nu complica inutil povestea.

Să aruncăm o privire mai atentă asupra modului în care produsele OLAP diferă în implementarea lor fizică.

După cum sa menționat mai sus, OLAP se bazează pe ideea procesării datelor pe structuri multidimensionale. Când spunem OLAP, ne referim la faptul că logic structura de date a unui produs analitic este multidimensională. Modul în care este implementat este o altă problemă. Există două tipuri principale de procesare analitică, care includ anumite produse.

MOLAP . De fapt OLAP multidimensional (multidimensional). Produsul se bazează pe o structură de date non-relațională care oferă stocare, procesare și prezentare multidimensională a datelor. În consecință, bazele de date sunt numite și multidimensionale. Produsele din această clasă au de obicei un server de baze de date multidimensional. Datele din procesul de analiză sunt selectate exclusiv dintr-o structură multidimensională. O astfel de structură este foarte productivă.

ROLAP . OLAP relațional. După cum sugerează și numele, structura multidimensională a acestor instrumente este implementată de tabele relaționale. Și datele din procesul de analiză, respectiv, sunt selectate din baza de date relațională de către instrumentul analitic.

Dezavantajele și avantajele fiecărei abordări sunt, în general, evidente. OLAP multidimensional oferă performanțe mai bune, dar structurile nu pot fi folosite pentru a procesa cantități mari de date, deoarece dimensiunile mari necesită resurse hardware mari și, în același timp, dispersitatea hipercuburilor poate fi foarte mare și, prin urmare, utilizarea puterii hardware nu va fi justificată. . Dimpotrivă, OLAP relațional oferă procesare pe matrice mari de date stocate, deoarece este posibil să se asigure o stocare mai economică, dar, în același timp, pierde semnificativ în viteza OLAP-ului multidimensional. Un astfel de raționament a condus la selectarea unei noi clase de instrumente analitice - HOLAP. Aceasta este o prelucrare analitică operațională hibridă (hibridă). Instrumentele acestei clase vă permit să combinați ambele abordări - relaționale și multidimensionale. Accesul poate fi efectuat atât la datele bazelor de date multidimensionale, cât și la datele relaționale.

Există un alt tip destul de exotic de procesare analitică online - DOLAP. Acesta este un „desktop” OLAP. Vorbim despre o astfel de prelucrare analitică, unde hipercuburile sunt mici, dimensiunile lor sunt mici, nevoile sunt modeste, iar pentru o astfel de prelucrare analitică este suficient un computer personal pe desktop.

Prelucrarea analitică operațională poate simplifica și accelera semnificativ procesul de pregătire și luare a deciziilor de către personalul de conducere. Prelucrarea analitică online are scopul de a transforma datele în informații. Este fundamental diferit de procesul tradițional de sprijinire a deciziilor, care se bazează, cel mai adesea, pe luarea în considerare a rapoartelor structurate. Prin analogie, diferența dintre rapoartele structurate și OLAP este aceeași ca între conducerea prin oraș cu tramvaiul și cu mașina. Când mergi cu tramvaiul, acesta se mișcă de-a lungul șinelor, ceea ce face dificil să vezi clădirile îndepărtate, cu atât mai puțin să te apropii de ele. Dimpotrivă, conducerea unei mașini private oferă libertate totală de mișcare (desigur, trebuie respectate regulile de circulație). Puteți ajunge cu mașina până la orice clădire și puteți ajunge în locuri unde tramvaiele nu circulă.

Rapoartele structurate sunt șinele care împiedică libertatea de a lua decizii. OLAP este o mașină pentru deplasarea eficientă pe autostrăzile informaționale.