Depozit de date

Organizarea și schema de funcționare a unui sistem Datawarehouse în domeniul business intelligence

În tehnologia informației , în cadrul sistemelor informaționale , în practicile de business intelligence pentru depozite de date (din engleză literalmente data warehouse , prescurtat DW) înțelegem în general o colectare sau agregare de date structurate, provenind din surse operaționale interne ( SGBD ) și externe la sistemul de informații al companiei, util pentru analize și rapoarte de informații , adaptate mai întâi prin instrumente specifice pentru transformarea datelor de tip ETL , și apoi analizate prin instrumente de analiză de tip OLAP (interogări multidimensionale) sau miniere de date , de obicei pentru utilizarea corporativă strategică în procesele de luare a deciziilor în afaceri .

Poate fi văzut ca o bază de date mare numai în citire ( schemă la citire ), prin urmare utilă pentru analiza istorică sau fără operațiile CRUD obișnuite tipice bazelor de date relaționale operaționale ( schemă la scriere ). În contextul analizei multidimensionale OLAP, subsetul DW se numește mart de date .

Definiții

William H. Inmon , cel care a vorbit pentru prima dată în mod explicit despre depozitul de date , îl definește ca o colecție de date „integrată, orientată spre subiect, variabilă în timp și nevolatilă” pentru a sprijini procesele decizionale .

Integrarea datelor este principala caracteristică distinctivă a DW în comparație cu alte sisteme de asistare a deciziilor.

Conform Inmon , colectarea datelor este:

Integrat : o cerință fundamentală a unui depozit de date este integrarea datelor colectate. Datele de la mai multe sisteme tranzacționale și surse externe curg în depozitul de date. Scopul integrării poate fi atins urmând căi diferite: prin utilizarea metodelor uniforme de codificare, prin urmărirea omogenității semantice a tuturor variabilelor, prin utilizarea acelorași unități de măsură;
Orientat spre subiect : DW este orientat către teme specifice de afaceri, aplicații sau funcții. Într-un DW, datele sunt stocate astfel încât să poată fi citite sau prelucrate cu ușurință de către utilizatori. Prin urmare, obiectivul nu mai este acela de a minimiza redundanța prin normalizare, ci de a furniza date organizate în așa fel încât să favorizeze producția de informații. Trecem de la proiectarea prin funcții la o modelare a datelor care permite o viziune multidimensională a acestora;
Variabilă în timp : datele stocate într-un DW acoperă un orizont de timp mult mai lung decât cel stocat într-un sistem operațional. DW conține o serie de informații referitoare la zonele de interes care surprind situația referitoare la un anumit fenomen într-un anumit interval de timp destul de lung. Aceasta implică faptul că datele conținute într-un DW sunt actualizate până la o anumită dată care, în majoritatea cazurilor, este anterioară datei în care utilizatorul interogă sistemul. Acest lucru diferă de ceea ce se întâmplă într-un sistem tranzacțional, în care datele corespund întotdeauna unei situații actualizate, de obicei incapabile să ofere o imagine istorică a fenomenului analizat;
Non-volatil : această caracteristică indică nemodificabilitatea datelor conținute în DW, care permite accesul numai în citire. Aceasta implică o simplitate a proiectării bazei de date în comparație cu cea a unei aplicații tranzacționale. În acest context, eventualele anomalii datorate actualizărilor nu sunt luate în considerare și nici instrumentele complexe nu sunt utilizate pentru a gestiona integritatea referențială sau pentru a bloca înregistrările care pot fi accesate de alți utilizatori în timpul fazei de actualizare.

Prin urmare, depozitul de date descrie procesul de achiziționare, transformare și distribuire a informațiilor prezente în interiorul sau în afara companiilor ca un sprijin pentru factorii de decizie . Acesta diferă substanțial de sistemele de management normale care, dimpotrivă, au sarcina de a automatiza operațiunile de rutină .

Se poate observa că definiția Inmon citată anterior este indiferentă față de caracteristicile arhitecturale ale sistemelor tranzacționale și de localizarea fizică a datelor în diversele baze de date.

Dacă accentul este pus pe capacitatea de a sprijini luarea deciziilor, depozitul de date poate fi construit în moduri diferite, care pot varia de la logica complet centralizată la logica complet distribuită.

Componente și arhitectură

Elementele de bază ale arhitecturii sunt:

Date provenite din sisteme tranzacționale : sunt acel set de date procesate de sistemele tranzacționale ale companiei. Ele pot fi conținute în aceeași bază de date, provenind din baze de date diferite sau chiar externe companiei. De multe ori arhitectura unui depozit de date implică integrarea datelor interne cu cele externe. Utilizarea acestora din urmă permite îmbogățirea activelor informaționale.
Mișcarea datelor : această componentă este responsabilă pentru extragerea datelor din sistemele tranzacționale, integrarea datelor corporative și a datelor externe, prelucrarea prealabilă a datelor, verificarea consistenței datelor, conversia structurilor de date și actualizarea dicționarelor de date.
Depozitul de date : datele extrase din arhivele tranzacționale sunt stocate intern în depozitul de date . În depozitul de date , accesul la date este permis în modul de citire numai. Aceste date au o dimensiune istorică și se referă la subiecte comerciale. Ele pot fi stocate într-un depozit central sau pe un martor de date . Termenul data mart identifică un depozit de date mic, specializat pentru o anumită zonă de activitate. Gândiți-vă, de exemplu, la martorul de date de marketing , în care datele filtrate de arhive tranzacționale sunt stocate pentru a permite analiza clienților. Prin urmare, în cadrul băncii pot exista mai multe marturi de date , cu scopuri diferite și care vizează acoperirea diferitelor domenii de activitate. Datele conținute în depozitul de date pot fi agregate și indexate pentru a răspunde nevoilor specifice de informații.
Metadate : metadatele sunt informații suplimentare care îmbogățesc datele conținute în depozitul de date . Adesea acestea sunt numite „ date despre date ” în jargon, indicând originea, utilizarea, valoarea sau funcția datelor. În acest sens, sunt create cataloage de informații reale. Acestea din urmă sunt fișierele care conțin metadatele. Catalogul permite să explice utilizatorului natura datelor din depozitul de date , semnificația lor semantică, din ce arhive provin și istoricitatea lor.
Utilizatorul final : datele conținute în depozitul de date sunt prezentate utilizatorului final, care are un set de instrumente pentru a efectua procesarea și a produce informații adecvate. Instrumentele disponibile utilizatorului pot fi simple interogări și generatoare de rapoarte, interfețe grafice care permit reprezentarea datelor sau sisteme mai complexe de analiză a datelor.

Depozitul de date este organizat pe patru niveluri arhitecturale:

transformarea datelor: este nivelul care se ocupă cu achiziționarea datelor și validarea acestora;
pregătirea și „stocarea” datelor: acesta este stratul care furnizează date utilizatorilor și aplicațiilor analitice;
interpretarea și analiza datelor: acesta este nivelul, cu valoare adăugată ridicată, care prezidează transformarea datelor în informații cu valoare strategică;
prezentarea datelor: este nivelul, cu valoare adăugată redusă, care prezidează prezentarea finală către utilizatori a informațiilor și, prin urmare, a răspunsurilor căutate.

În ansamblu, depozitul de date este un sistem periferic, adică nu se află fizic pe sistemul central de informații. Motivul pentru aceasta se regăsește în tipul de activitate desfășurată: o platformă de tip tranzacțional este mai orientată spre executarea constantă a operațiunilor de actualizare, deci optimizarea se realizează mai ales pe I / O ; pe de altă parte, o platformă de sprijinire a deciziilor trebuie optimizată pentru a efectua un număr limitat de interogări deosebit de complexe. O excepție de la această regulă poate fi reprezentată de soluțiile mainframe, unde posibilitatea definirii mașinilor virtuale în cadrul aceleiași mașini fizice permite coexistența pe același server fizic a aplicațiilor tranzacționale și a aplicațiilor sistemului de suport pentru decizii .

Acum să vedem în detaliu cum este realizată o arhitectură de depozit de date .

Stratul de transformare a datelor

Același subiect în detaliu: extrageți, transformați, încărcați și curățați datele .

Figura 1: Diagrama simplă a unui depozit de date. Procesul ETL extrage informații din bazele de date sursă, le transformă și le încarcă în depozitul de date.

Figura 2: Diagrama simplă a unei soluții de integrare a datelor. Un proiectant de sistem construiește o schemă mediată prin care utilizatorii pot efectua interogări. Baza de date virtuală se interfață cu bazele de date sursă printr-un wrapper, dacă este necesar.

Arhitectura pornește de la stratul numit transformare a datelor , adică de la setul de aplicații care realizează activitatea de extragere, transformare și încărcare a datelor din sistemele tranzacționale care alimentează depozitul de date .

În majoritatea cazurilor, faza de extragere a datelor din sistemele de hrănire este implementată utilizând limbile proprii ale platformelor de hrănire. Acestea sunt în mare parte interogări ad hoc, parametrizate în funcție de intervalul de timp, efectuate periodic, de obicei, în momentele de activitate mai redusă a sistemului.

Faza de transformare, cea cu cea mai mare valoare adăugată dintre cele trei conținute în acest strat de aplicație, aplică reguli de integrare, transformare și curățare ( regulă de afaceri ) datelor extrase din sistemele de alimentare. În acest strat, credibilitatea datelor de depozitare a datelor cu utilizatorii este foarte des în joc. În majoritatea cazurilor, datele extrase din sistemele tranzacționale sunt incomplete sau, în orice caz, inadecvate pentru luarea deciziilor, deoarece nu sunt în concordanță cu analizele care trebuie efectuate.

În unele cazuri, operațiunile de transformare pot provoca o respingere , ceea ce semnalează incapacitatea de a accepta o parte din fluxul de alimentare din cauza „impurității” din datele sursă.

Posibilele cauze ale respingerii sunt diverse:

Codificări incoerente . Același obiect este codat diferit în funcție de sistemul de alimentare. În timpul fazei de transformare, fiecare flux de alimentare va fi recodificat în urma codificării convenționale definite pentru depozitul de date;
Unități / formate incoerente . Acesta este cazul în care aceeași cantitate este măsurată cu unități de măsură sau reprezentată cu diferite formate în funcție de sistemul de alimentare de origine. În timpul fazei de transformare, fiecare flux de alimentare va fi transformat într-o singură unitate convențională de măsură pentru depozitul de date;
Confesiuni incoerente . Acesta este cazul în care, în funcție de sursă, același obiect (de obicei date) este denumit diferit. De obicei, datele din depozit sunt identificate pe baza definiției conținute în metadatele sistemului;
Date incomplete sau incorecte . În cele trei cazuri anterioare, operațiunile de transformare au constat în esență din activități de conversie, în anumite limite automatizabile. În acest caz, însă, operațiunea de transformare poate necesita intervenția umană pentru a rezolva cazurile care nu pot fi prevăzute a priori.

Pregătirea datelor și stratul de stocare

Același subiect în detaliu: Integrarea datelor .

Odată ce datele au trecut de stratul de transformare , acestea sunt „stocate” în acest strat arhitectural pentru a permite:

crearea de rezumate de informații pentru utilizatori ( date marts și agregări) prin proceduri ad hoc care sunt declanșate de obicei (în ceea ce privește actualizările) la finalizarea operațiunilor de extracție, transformare și încărcare;
executarea analizelor avansate, bazate în principal pe algoritmi statistici, care necesită operarea la detaliile maxime disponibile ale datelor pentru a obține rezultate semnificative.

Acest nivel coincide cu detaliile maxime disponibile (în termeni de date) în cadrul sistemului de depozitare a datelor .

Stratul de interpretare și analiză a datelor

La acest nivel există obiecte care sunt foarte diferite între ele în ceea ce privește funcția și tehnologia. Funcționalitățile de bază realizate de acest nivel arhitectural sunt: agregarea, analiza și interpretarea.

Agregare

Funcția „agregare” construiește sinteze de decizie pornind de la datele detaliate prezente în stratul anterior. Aici trebuie făcută o clarificare arhitecturală importantă.

Într-o situație în care nu există un depozit de date , utilizatorii sunt obligați să acceseze sisteme vechi pentru a obține informațiile de care au nevoie.

În unele cazuri, se poate decide extragerea unuia sau mai multor rezumate (date mart) din sistemele vechi pentru utilizatorii care vor efectua analiza asupra acestora. În această situație, chiar dacă tehnologia și arhitectura seamănă cu cele ale unui depozit de date , imposibilitatea de a ajunge la date cu mai multe detalii decât cea a rezumatelor disponibile îi reduce puterea informațională.

Mai mult, depozitul de date nu trebuie considerat neapărat ca o bază de date la care toți utilizatorii au acces gratuit pentru propriile analize. Acest lucru poate fi adevărat acolo unde utilizatorii sunt instruiți în mod deosebit și, în orice caz, prezintă dezavantaje, deoarece resursele hardware necesare pentru a sprijini un număr mare de utilizatori care efectuează interogări complexe sunt dificil de prezis și planificat. Multe proiecte presupuse de depozitare eșuează tocmai pentru că sunt limitate la importul de date fără a le pune la dispoziția utilizatorilor mai puțin experimentați.

Situația ideală este aceea în care există un depozit central de date , care conține toate datele la nivelul minim de detaliu necesar pentru a efectua analize avansate și pentru a construi agregări pentru toți utilizatorii. În acest caz, martele de date pot fi tematice (adică conțin toate informațiile despre un anumit subiect) sau pentru grupuri specifice de utilizatori.

Această strategie arhitecturală face din depozitul de date un adevărat proces de livrare a informațiilor , în care solicitarea de noi sinteze decizionale implică nu construirea altor fluxuri de putere, ci mai degrabă crearea altor date martiale. Dezvoltarea de noi date mart este o activitate normală de gestionare a depozitului de date . Diferența cu ceea ce ar trebui făcut cu ajutorul sistemelor vechi este în esență una dintre costuri: generarea unui nou martor de date într-o arhitectură de depozitare are costuri și timp semnificativ mai mici pentru dezvoltare și controlul calității datelor.

Analiză și interpretare

Exemplu de cub OLAP tridimensional: produse, oraș, timp

Funcția de analiză vă permite să efectuați anchete asupra agregatelor construite de sistem. De obicei, funcțiile de analiză ale unui depozit de date se bazează pe o tehnologie OLAP ( procesare analitică on-line ).

OLAP este în esență o abordare a luării deciziilor care se concentrează pe analiza dimensională a informațiilor. Principalele sale caracteristici sunt:

este orientată către utilizatorii de afaceri : afacerea se face în „dimensiuni” și nu în „tabele” și cei care analizează și încearcă să o înțeleagă motivează tocmai după mărime; acesta este motivul pentru care, odată ce cele două concepte fundamentale ( dimensiunea și ierarhia ) au fost înțelese, orice utilizator de afaceri poate folosi un instrument OLAP;
este conceput pentru rezolvarea problemelor nestructurate : spre deosebire de instrumentele tradiționale de raportare care prezintă deja răspunsuri preambalate, instrumentele OLAP stimulează întrebările și permit analiza cauză-efect. Acest lucru se întâmplă datorită structurii lor care permite navigarea între informații, folosind ierarhiile și relațiile dintre informațiile în sine ca căi;
se concentrează pe informații : motoarele OLAP nu sunt în sine instrumente de prezentare a informațiilor, ci arhitecturi optimizate de stocare a datelor și navigare; rezultă că tot ceea ce un utilizator găsește în acest mediu este doar informațiile de care are nevoie, organizate în conformitate cu logica dimensiunilor de analiză a afacerii;
(în consecință) creează eficiență : în mod evident, rezultatul net al tuturor acestora este eficiența creată de aceste sisteme cu capacitatea lor de a merge de la general la particular și de a ajuta utilizatorul să găsească informațiile necesare pe baza căilor logice și nu „flipping”.

Stratul de prezentare a datelor

Același subiect în detaliu: OLAP și Data Mining .

Acest nivel conține sistemele de prezentare a informațiilor către utilizatori.

Sistemele aparținând acestui nivel arhitectural pot fi grupate în trei mari categorii:

specializate Business Intelligence instrumente: în această categorie, foarte larg în ceea ce privește soluțiile de pe piață, vom găsi instrumente pentru construirea de interogări, OLAP instrumente de navigare (OLAP vizualizare) și, într - un sens larg, de asemenea , browsere web , care sunt din ce în ce interfață comună pentru diferite aplicații;
Instrumente de automatizare a biroului : adesea furnizorii de software prezenți cu soluțiile lor la nivelul arhitectural anterior indică drept soluții front-end instrumentele obișnuite de lucru zilnic, cum ar fi procesoarele de text și foile de calcul. Aceasta este o soluție liniștitoare pentru utilizatorii care se apropie pentru prima dată de depozitul de date, deoarece aceștia nu sunt obligați să învețe noi instrumente complexe. Problema constă în faptul că această soluție este adecvată în ceea ce privește productivitatea și eficiența, este mai mică pentru utilizarea intensivă a depozitului de date , deoarece aceste instrumente, în acest caz, au limite arhitecturale și funcționale semnificative;
grafică și instrumente de publicare: și aici predomină o considerație a eficienței și productivității: instrumentele de Business Intelligence sunt capabile să genereze grafică și tabele pentru utilizatorii lor, soluția în cauză servește practic pentru a evita pașii dubli ineficienți.

Datele

Un depozit de date cuprinde mai multe straturi de date:

Date detaliate actuale: acestea sunt datele la cel mai înalt nivel de detaliu despre care se crede că sunt utile pentru procesele decizionale, pe baza unor nevoi cunoscute și rezonabil previzibile. În realitate, această parte include nu numai datele reale (adică valabile la momentul interogării), ci și o anumită fereastră de timp a datelor istorice. În plus față de posibila primă agregare, datele de la acest nivel au suferit deja toate celelalte operațiuni cu privire la datele operaționale: filtrarea informațiilor inutile, interogarea informațiilor din diferite surse, transformarea în ceea ce privește schema de date a depozitului de date .
Date istorice detaliate: datele detaliate care depășesc intervalul de timp al datelor „curente”, dar care se încadrează totuși în intervalul de timp al depozitului de date sunt plasate pe suporturi mai puțin exigente și mai scumpe, dar și mai puțin accesibile.
Date agregate: prezența datelor agregate în depozitul de date derivă din considerații de eficiență și caracter practic în a răspunde cererilor utilizatorilor; de fapt, toate informațiile care pot fi obținute din datele agregate pot fi teoretic obținute din datele detaliate, dar acest lucru ar necesita recalcularea lor din când în când. În acest fel, totuși, nevoi neprevăzute care necesită agregări, altele decât cele pregătite, nu pot fi satisfăcute, dar în acest scop datele detaliate sunt păstrate în orice caz.

Proiecta

Așa cum am menționat mai devreme, depozitul de date este un sistem de procesare analitică on-line ( OLAP ) care diferă de sistemele de procesare a tranzacțiilor on-line ( OLTP ), deși datele provin din acesta din urmă. Sistemele OLAP sunt sisteme orientate spre subiect, sunt integrate, istorice și permanente. Acestea nu includ date analitice și statice, cum ar fi sistemele OLTP, de asemenea, datele OLAP nu sunt potrivite pentru utilizarea de zi cu zi, dar sunt utilizate pentru analiză.

Un depozit de date este întotdeauna separat de mediul său operațional. Datele din depozitul de date nu se modifică niciodată; sunt stocate la început și puse la dispoziție și nu sunt actualizate ca în sistemele OLTP. Înainte de a fi stocate în depozitul de date , datele sunt integrate urmând diferite strategii.

Sursa de date pentru un depozit de date este un sistem de operare, chiar dacă primul nu este o copie pură a acestuia din urmă: datele dintr-un sistem de decizie sunt filtrate, clasificate cronologic, valorile rezumate sunt adăugate și modificate înainte de a fi încărcate în depozit de date. În special, pentru microdate, datele sunt rezumate la două niveluri distincte de agregare: primul nivel ( primul nivel de date mart ) specifică unitatea de timp, iar în al doilea nivel ( data final mart ) doar date la o frecvență mai mare. Astfel, dacă datele sunt accesate mai frecvent, nivelul de rezumare este mai mare. Cu alte cuvinte, sunt stocate mai puține date, iar accesarea datelor este mai rapidă și mai eficientă.

Există două abordări principale pentru dezvoltarea unui mediu de depozitare de date: prima se bazează pe crearea unui depozit de date central, utilizând date din sistemul principal și din alte surse. Acest depozit central de date poate fi apoi utilizat pentru a crea și actualiza depozite de date departamentale sau marturi de date locale. A doua abordare se bazează pe crearea de marturi de date independente, fiecare stocate direct de sistemul central și alte surse de date.

Abordarea depozitului de date central poate începe cu un depozit de date simplu , care poate fi extins în timp pentru a satisface utilizatorii cu cerințe în creștere și pentru a deveni un mediu care conține sisteme de depozitare de date interconectate. Într-un mediu de depozitare de date simplificat, trebuie organizate trei zone:

extragerea și transformarea datelor din sistemele de operare;
baza de date a depozitului de date;
instrumentele de interpretare a datelor.

Trebuie să monitorizați rețeaua care permite utilizatorilor să acceseze. De obicei, există cel puțin trei depozite pentru metadate și alte informații conexe: unul pentru a descrie structura datelor, pentru transformarea acestora și pentru extragerea datelor; una pentru depozitul de date ; și unul sau mai multe pentru instrumentele de navigare. Aceste depozite trebuie să fie organizate individual și în ansamblu. Datele din mediul bazei de date ale depozitului de date ar trebui tratate cu aceeași grijă. Complexitatea acestei sarcini depinde de complexitatea bazei de date alese, dar include copii de rezervă, recuperare, reorganizare, arhivare, monitorizare și operațiuni de reglare. Subseturi de date departamentale sau locale ( date marts ) sunt create pentru a îmbunătăți performanța consultărilor utilizatorilor și pentru a reduce dependența de depozitul de date . Acest strat suplimentar de date mărește complexitatea gestionării mediului: adaugă un alt strat de metadate și, eventual, un alt depozit, necesită controlul și gestionarea distribuției datelor de date mart și, cu excepția cazului în care administrarea datelor mart este complet descentralizată local, necesită, de asemenea, gestionarea datelor din baza de date data mart . Situația devine și mai dificilă dacă mediul continuă să evolueze prin crearea mai multor depozite de date . În unele dintre aceste cazuri, complexitățile administrative devin copleșitoare.

În abordarea independentă a martorilor de date , crearea unui singur martor de date orientată spre rezolvarea unei anumite probleme este o soluție simplă. Cele trei zone care trebuie administrate sunt:

extragerea datelor din surse și transformarea lor în structuri de date corecte pentru baza de date de date mart ;
baza de date a martorului de date în sine;
instrumentele de interpretare a datelor.

Deoarece acest mediu nu conține volume mari de depozit de date , este mai ușor de gestionat. Dacă s-ar adopta o astfel de soluție simplă de date mart în construirea și organizarea depozitului de date , sarcina administratorului ar fi relativ ușoară. Această abordare nu se oprește de obicei la o dată marțială și, odată cu adăugarea a mai multor date , situația devine mai complicată. Sarcina de a aduce mai multe date separate într-un singur mediu de stocare a datelor este extrem de dificilă. Fiecare martie de date este de obicei dezvoltată individual. Astfel de date martiale au potențialul de a deveni parte a sistemului de bază. În acest fel, pot pune problema discrepanțelor în definirea datelor pe care depozitul de date a fost conceput să le rezolve. Această situație neatractivă este evitată numai dacă există o arhitectură centralizată de administrare a dezvoltării sistemului.

Depozitul de date poate conține volume foarte mari de date, care nu sunt întotdeauna interesante pentru toți utilizatorii. Lucrul cu aceste volume de date fără legătură poate fi ineficient și poate consuma o mulțime de resurse de calcul. În această situație, este posibil să împărțiți depozitul de date în zone specializate de interes.

În plus, multe instrumente de exploatare a datelor își creează primele medii, fiecare cu propriul depozit. Acest depozit conține informațiile necesare pentru explorarea datelor. Dacă depozitul de date este administrat central, aceste medii trebuie încorporate în structura centrală de management. Chiar și atunci când responsabilitatea pentru administrarea instrumentelor de exploatare a datelor este la nivel local, este nevoie de o legătură între sistemul de administrare centrală și mediile distribuite. Această legătură este necesară pentru a se asigura că schimbările instrumentelor în mediile distribuite pot fi identificate și la nivel central.

Alte aspecte de proiectare

Nivelurile operaționale ale depozitului de date pot exista în două condiții fundamentale:

existența unei organizații de sprijin adecvate pentru proces, cu roluri și responsabilități definite. În mod similar cu aplicațiile tranzacționale, un sistem de susținere a deciziilor necesită cifre organizaționale cu responsabilitatea de a-l menține, în special într-o cheie evolutivă, pentru a se asigura că este aliniat constant cu nevoile utilizatorilor de afaceri, o condiție necesară și suficientă pentru ca acesta să continue să exista;
accentul corect pe tehnologia de susținere a proceselor, alcătuit din alegeri echilibrate bazate pe nevoile funcționale ale procesului în sine. Tehnologia este crucială pentru depozitul de date , având în vedere problemele de integrare a sistemului pe care le implică. Gestionarea constantă a variabilei tehnologice este unul dintre factorii de succes ai depozitului de date , începând de la alegerile inițiale pentru a ajunge la gestionarea operațională a actualizărilor și extensiilor platformei.

Aplicații

Depozitul de date este un sistem informațional în care datele sunt organizate și structurate pentru acces ușor de către utilizator și pentru a oferi suport pentru procesele decizionale. Următoarele sisteme sunt activate de depozitul de date:

DSS ( Sistem de sprijin pentru decizii );
EIS ( Executive / Enterprise Information System ).

Primul este utilizat pentru a rezolva probleme specifice, în timp ce al doilea permite o circulație continuă a datelor care nu depinde de probleme specifice.

În bănci și instituții financiare, în general, domeniile de utilizare sunt multiple, deoarece toate domeniile de management ale acestor organizații sunt caracterizate de volume considerabile de date asupra cărora trebuie luate decizii strategice. Deoarece depozitul de date poate avea valoare strategică, în cadrul acestor tipuri de organizații este esențial pentru management să definească o strategie pentru depozitul de date. Strategia de depozitare a datelor este în esență o cale evolutivă care duce compania de la aplicații DW non -critice la o situație în care depozitul de date este o componentă fundamentală a sistemului informațional corporativ.

Strategia de depozitare a datelor a unei companii poate fi clasificată în două dimensiuni fundamentale:

utilizzo del DW esistente: livello di maturità degli utenti e delle funzioni di supporto del DW nell'utilizzo dell'esistente;
utilizzo del DW in prospettiva: di utilizzo del DW come piattaforma di decision support .

Le aziende attraversano dunque quattro fasi nella storia dell'utilizzo del data warehouse :

la prima fase, chiamata "supporto" (basso utilizzo del DW esistente, basso utilizzo prospettico del DW), è la fase in cui si trovano le aziende che hanno fallito uno o più progetti di warehousing e non pensano di ampliarne l'utilizzo prospettico. In questa fase si possono trovare anche aziende che non hanno un DW e non pensano di realizzarlo;
la seconda fase, chiamata "opportunità" (basso utilizzo del DW esistente, alto utilizzo prospettico del DW), è la fase in cui si trovano le aziende che, pur avendo fallito uno o più progetti di warehousing o avendo semplicemente esplorato la tematica senza approfondirla, puntano a sviluppare le attività di decision support tramite il data warehouse.
la terza fase (alto utilizzo del DW esistente, alto utilizzo prospettico del DW), è quella fase in cui il data warehouse diviene "strategico" per i processi decisionali aziendali. In questa fase si trovano tutte quelle aziende che hanno intrapreso con successo un progetto di warehousing e che ne stanno sfruttando a pieno le potenzialità;
la quarta fase, chiamata factory (alto utilizzo del DW esistente, basso utilizzo prospettico del DW) è la fase in cui si trovano le aziende in cui il data warehouse è maturo, la metodologia di implementazione consolidata e le aree decisionali critiche sono presidiate. In questa fase l'imperativo principale è l'efficienza e il risparmio di costi derivanti dal data warehouse e nel suo utilizzo. Un processo di sclerotizzazione nell'uso del data warehouse può in alcuni casi far tornare l'azienda alla prima fase.

Individuiamo ora quali sono le aree applicative più indicate per il data warehouse nel settore finanziario.

Controllo di gestione

Questa può essere l'area applicativa di base per un sistema di data warehousing in qualunque organizzazione. In questo caso il data warehouse viene utilizzato sostanzialmente come piattaforma di reporting e analisi di redditività. È inutile e pericoloso ipotizzare di realizzare un data warehouse solo per il controllo di gestione. Tale iniziativa ha senso solo se questo è il primo passo evolutivo nella strategia di data warehousing dell'azienda. Infatti, costruire un data warehouse per il controllo di gestione consente di analizzare e risolvere rapidamente esigenze estremamente rilevanti ed il cui beneficio è immediatamente chiaro, affrontando problemi (a livello di struttura, validazione e calcolo dei dati) ben noti nella loro struttura.

Gestione dei rischi e delle risorse

Un'altra area applicativa interessante è identificabile nelle attività di gestione dei rischi e delle risorse (vedi Gestione del rischio ), soprattutto in due attività ben specifiche: l'analisi e la simulazione dei portafogli e dei relativi rischi; il reporting.

Tali aree applicative sono di particolare importanza e strategicità ed il data warehouse è lo strumento appropriato per affrontarle, anche per la possibilità di integrare al suo interno dati provenienti da fonti esterne all'azienda. In questo caso il data warehouse va dotato di strumenti di analisi avanzati e basati su algoritmi statistici di analisi e simulazione. Una recente normativa entrata in vigore in Italia a Gennaio 2016, impone alle Compagnie di Assicurazione di dotarsi di sistemi di elaborazione dati che promuovano l'integrità, la trasparenza e la completezza dei dati destinati alla sorveglianza ed al controllo. Di contro molte Aziende hanno rivolto la loro attenzione proprio verso il DWH come sistema di elaborazione che certifica i dati. Si parla in questo caso di qualità dei dati.

Un'altra sotto-area di grande interesse può essere lo sviluppo di sistemi per l'individuazione delle frodi. Anche in questo caso è necessario il ricorso a strumentazione di tipo statistico.

Supporto alle vendite

Non necessariamente il data warehouse è appropriato per affrontare e risolvere questo tipo di esigenza, a meno che esista la necessità di immagazzinare e gestire rilevanti masse di dati. In molti casi la banca dati di marketing è banalmente un'anagrafica clienti arricchita di alcune informazioni "non amministrative", in casi più avanzati diventa uno strumento fondamentale di supporto al " marketing one-to-one ". In questo caso di marketing costituisce una base di informazioni fondamentale per indirizzare correttamente campagne e iniziative promozionali o per attivare servizi avanzati di assistenza alla clientela. In questo caso, data la rilevante massa di dati da gestire, il data warehouse può diventare la piattaforma tecnologica ideale.

Nel settore bancario il marketing one-to-one è allo stadio embrionale, almeno dal punto di vista del marketing centrale, e questo è dovuto al fatto che molto spesso il marketing one-to-one viene fatto dalla filiale, l'unica struttura aziendale in grado storicamente di instaurare un rapporto fiduciario con il cliente finale, che identifica l'azienda nello "sportello" e nel suo "impiegato".

Sistema informativo di marketing

Si tratta di utilizzare il data warehouse come una sorta di dorsale di rete per supportare una serie di applicazioni integrate orientate alle analisi commerciali e di marketing . Gli aspetti fondamentali che caratterizzano questo tipo di architettura sono essenzialmente due:

la possibilità di integrare basi di dati transazionali diverse in un'unica base dati analitica e produrre quindi "viste" integrate della clientela, del mercato e dei prodotti;
la possibilità di effettuare analisi con strumenti e logiche diverse su una base unica.

L'idea di fondo del sistema informativo di marketing è quella di sviluppare un percorso evolutivo che parta dal reporting di base per arrivare ad analisi avanzate, passando attraverso sistemi di analisi del portafoglio prodotti e clienti e procedure di budgeting e simulazione.

Supporto al call center

Anche in questo caso il data warehouse è un'opzione tecnologica, non l'unica praticabile e non necessariamente la più economica. Utilizzare un'architettura di data warehousing a supporto di un'attività di call center ha sicuramente senso nel caso in cui le richieste non sono necessariamente di tipo strutturato e quindi risolvibili con il classico "inquiry (interrogazione) da terminale". È evidente però che la tipologia di utente per questo tipo di sistema è più evoluto del normale operatore di call center .

Base di conoscenza

Anche in questo caso valgono le considerazioni fatte per la banca dati di marketing: non necessariamente il data warehouse è la tecnologia più idonea per questo tipo di esigenza, ma lo diventa nel momento in cui la conoscenza in oggetto è costituita prevalentemente da informazioni strutturate e preferibilmente numeriche. In questo caso, anche dal punto di vista tecnologico, una banca dati relazionale è sicuramente la soluzione più idonea, efficiente ed economica. Non è così se invece le informazioni sono di tipo destrutturato, in questo caso la soluzione più adatta è una piattaforma di groupware. Si deve però fare attenzione a non confondersi con le cosiddette banche dati multimediali: il fatto che una banca dati relazionale abbia funzionalità multimediali non significa che sia un data warehouse . Infatti, ciò che distingue un data warehouse da ciò che non lo è, non è la tecnologia utilizzata, ma l'architettura applicativa e il disegno della base di dati.

Poiché dunque la conoscenza non è solo nei dati strutturati (o strutturabili), ma anche in quelli non strutturati (per es. corrispondenza, documentazione tecnica e di progetto, insieme delle competenze e conoscenze di ogni persona, ...), da alcuni anni anche questo tipo di conoscenza viene riconosciuta come patrimonio aziendale al pari dei dati operativi, attirando l'interesse di chi si occupa di gestione aziendale.

Engineering di prodotto

Il data warehouse può essere una piattaforma decisionale per l'analisi e la concettualizzazione di nuovi prodotti da offrire alla clientela e/o per aggredire nuovi mercati o segmenti di mercato. Tale funzionalità è ovviamente supportata se il data warehouse è dotato non solo di strumenti di analisi dei risultati, ma anche di ambienti di simulazione che consentono la costruzione ed il testing 'in laboratorio' di nuove soluzioni da proporre ai clienti. In tali ambienti è possibile individuare alcuni importanti aspetti come la marginalità, il punto di pareggio economico, il segmento di clientela interessato, i meccanismi di cannibalizzazione, l'elasticità della domanda e l'impatto sull'equilibrio finanziario aziendale.

e-business

La diffusione del canale digitale nel settore finanziario pone una serie di problemi e di opportunità nuove. In primo luogo questo tipo di canale implica una velocità di cambiamento e quindi di reazione nettamente superiore. Il data warehouse può essere lo strumento analitico che consente di cogliere dinamiche all'interno di rilevanti masse di transazioni on-line. In secondo luogo l'informazione può essere uno strumento di supporto o l'oggetto stesso della transazione e in questo caso il data warehouse può essere la piattaforma utilizzata per coprire tale ambito applicativo.

Il data warehouse può essere quindi di supporto a sistemi di trading on-line sia dal punto di vista dell'analisi che dal punto di vista dell'architettura dati.

Bibliografia

Fabio Corbisiero, Osservatorio welfare. Sistemi, flussi e osservatori delle politiche sociali . Franco Angeli, 2008.
De Luca A., Marketing bancario e metodi statistici applicati. , Angeli, 2005.
Joe Ganczarski, Data Warehouse Implementations: Critical Implementation Factors Study . VDM Verlag, 2009. ISBN 3-639-18589-7 ISBN 978-3-639-18589-8
Ralph Kimball e Margy Ross, The Data Warehouse Toolkit . John Wiley & Sons, Inc.
Dulli Susi, Furini Sara e Peron Edmondo, Data warehouse. Teoria ed esercizi , Progetto Libreria, 2008.

Voci correlate

Collegamenti esterni

( EN ) Data warehouse , su Enciclopedia Britannica , Encyclopædia Britannica, Inc.

Controllo di autorità	LCCN ( EN ) sh97003695 · NDL ( EN , JA ) 00911488

Portale Internet

Portale Sicurezza informatica