Bunul Business Intelligence (BI), permite organizației dumneavoastră să interogheze date obținute din surse de încredere și să utilizeze răspunsurile pentru a obține un avantaj competitiv în industria dumneavoastră. Primul pas pentru realizarea unui BI eficient este un depozit bine conceput. Proiectarea depozitului de date este procesul de construire a unei soluții de integrare a datelor din mai multe surse care să susțină raportarea analitică și analiza datelor. Un depozit de date prost proiectat poate duce la achiziționarea și utilizarea unor date sursă inexacte care afectează negativ productivitatea și creșterea organizației dumneavoastră. Această postare pe blog va arunca o privire la nivel înalt asupra procesului de proiectare a depozitului de date, de la colectarea cerințelor până la implementare.
Colectarea cerințelor
Colectarea cerințelor este primul pas al procesului de proiectare a depozitului de date. Scopul etapei de colectare a cerințelor este de a determina criteriile pentru o implementare de succes a depozitului de date. Strategia de afaceri pe termen lung a unei organizații ar trebui să fie la fel de importantă ca și cerințele tehnice și de afaceri curente. Trebuie identificate cerințele de analiză a utilizatorilor și de raportare, precum și cerințele de hardware, dezvoltare, testare, implementare și instruire a utilizatorilor.
După ce strategia comercială și tehnică a fost decisă, următorul pas este să se abordeze modul în care organizația va face backup-ul depozitului de date și cum se va recupera în cazul în care sistemul eșuează. Elaborarea unui plan de recuperare în caz de dezastru, în timp ce se colectează cerințele, asigură faptul că organizația este pregătită să răspundă rapid la amenințările directe și indirecte la adresa depozitului de date.
Configurarea mediului fizic
După ce sunt stabilite cerințele de afaceri, următorul pas este determinarea mediului fizic pentru depozitul de date. Cel puțin, ar trebui să existe servere fizice separate pentru aplicații și baze de date, precum și procese ETL/ELT, OLAP, cuburi și procese de raportare separate, configurate pentru dezvoltare, testare și producție. Construirea unor medii fizice separate asigură faptul că toate modificările pot fi testate înainte de a le muta în producție, dezvoltarea și testarea pot avea loc fără a opri mediul de producție, iar dacă integritatea datelor devine suspectă, personalul IT poate investiga problema fără a avea un impact negativ asupra mediului de producție.
Modelarea datelor
După ce au fost definite colectarea cerințelor și mediile fizice, următorul pas este definirea modului în care structurile de date vor fi accesate, conectate, procesate și stocate în depozitul de date. Acest proces este cunoscut sub numele de modelare a datelor. În timpul acestei faze de proiectare a depozitului de date, este momentul în care sunt identificate sursele de date. Cunoașterea locului în care se află datele originale și, la fel de important, a disponibilității acestor date, este crucială pentru succesul proiectului. Odată ce sursele de date au fost identificate, echipa depozitului de date poate începe să construiască structurile logice și fizice pe baza cerințelor stabilite.
ETL
Procesul ETL necesită cel mai mult timp pentru a fi dezvoltat și consumă cea mai mare parte a implementării. Identificarea surselor de date în timpul fazei de modelare a datelor poate contribui la reducerea timpului de dezvoltare ETL. Scopul ETL este de a oferi viteze de încărcare optimizate fără a sacrifica calitatea. Eșecul în această etapă a procesului poate duce la performanțe slabe ale procesului ETL și ale întregului sistem de depozit de date.
Proiectarea cuburilor OLAP
Procesarea analitică în linie (OLAP) este motorul de răspuns care oferă infrastructura pentru interogarea ad-hoc a utilizatorului și analiza multidimensională. Specificațiile de proiectare OLAP ar trebui să provină de la cei care vor interoga datele. Documentația care specifică dimensiunile și măsurile cubului OLAP ar trebui să fie obținută la începutul procesului de proiectare a depozitului de date. Cele trei elemente critice ale proiectării OLAP includ:
- Măsuri de grupare – valori numerice pe care doriți să le analizați, cum ar fi veniturile, numărul de clienți, câte produse cumpără clienții sau valoarea medie a achizițiilor.
- Dimensiunea – unde sunt stocate măsurile pentru analiză, cum ar fi regiunea geografică, luna sau trimestrul.
- Granularitatea – cel mai mic nivel de detaliu pe care doriți să îl includeți în setul de date OLAP.
În timpul dezvoltării, asigurați-vă că procesul cubului OLAP este optimizat. Un depozit de date nu este, de obicei, o execuție prioritară pe timp de noapte și, odată ce depozitul de date a fost actualizat, rămâne puțin timp pentru actualizarea cubului OLAP. Neactualizarea în timp util a niciunuia dintre ele ar putea duce la reducerea performanțelor sistemului. Acordarea timpului necesar pentru a explora cea mai eficientă cale de generare a cubului OLAP poate reduce sau preveni problemele de performanță după ce depozitul de date intră în funcțiune.
Front End Development
În acest moment, cerințele de afaceri au fost capturate, mediul fizic este complet, modelul de date a fost decis și procesul ETL a fost documentat. Următorul pas este să se lucreze la modul în care utilizatorii vor accesa depozitul de date. Dezvoltarea front-end este modul în care utilizatorii vor accesa datele pentru analiză și vor rula rapoarte. Există mai multe opțiuni disponibile, inclusiv construirea front-end-ului la nivel intern sau achiziționarea unui produs gata de utilizare. Oricum ar fi, există câteva considerente de care trebuie să țineți cont pentru a asigura cea mai bună experiență pentru utilizatorii finali.
Accesul sigur la date de pe orice dispozitiv – desktop, laptop, tabletă sau telefon – ar trebui să fie principalul considerent. Instrumentul ar trebui să permită echipei dvs. de dezvoltare să modifice structura backend pe măsură ce se schimbă cerințele de raportare la nivel de întreprindere. De asemenea, ar trebui să ofere o interfață grafică pentru utilizatori (GUI) care să permită utilizatorilor să își personalizeze rapoartele în funcție de necesități. Motorul OLAP și datele pot fi cele mai bune din clasă, dar dacă utilizatorii nu pot utiliza datele, depozitul de date devine un depozit de date costisitor și inutil.
Dezvoltarea rapoartelor
Pentru majoritatea utilizatorilor finali, singurul contact pe care îl au cu depozitul de date este prin intermediul rapoartelor pe care le generează. După cum s-a menționat în secțiunea de dezvoltare frontală, capacitatea utilizatorilor de a-și selecta rapid și eficient criteriile de raportare este o caracteristică esențială pentru generarea rapoartelor din depozitul de date. Opțiunile de livrare sunt un alt aspect de luat în considerare. Pe lângă primirea rapoartelor printr-o interfață web securizată, este posibil ca utilizatorii să dorească sau să aibă nevoie de rapoarte trimise ca atașament de e-mail sau foaie de calcul. Controlul fluxului și vizibilității datelor este un alt aspect al dezvoltării rapoartelor care trebuie abordat. Dezvoltarea unor grupuri de utilizatori cu acces la segmente de date specifice ar trebui să asigure securitatea și controlul datelor. Raportarea se va schimba și ar trebui să se schimbe mult după implementarea inițială. Un depozit de date bine conceput ar trebui să fie capabil să gestioneze noile solicitări de raportare cu puține sau deloc modificări ale sistemului de depozit de date.
Performance Tuning
Principal în acest post, recomandarea a fost de a crea medii de dezvoltare și de testare separate. Procedând astfel, organizațiile pot asigura reglarea performanțelor sistemului în ceea ce privește ETL, procesarea interogărilor și furnizarea de rapoarte fără a întrerupe mediul de producție curent. Asigurați-vă că mediile de dezvoltare și testare-hardware și aplicații imită mediul de producție, astfel încât îmbunătățirile de performanță create în dezvoltare să funcționeze în mediul de producție live.
Testarea
După ce sistemul de depozit de date a fost dezvoltat în conformitate cu cerințele de afaceri, următorul pas este testarea acestuia. Testarea, sau asigurarea calității, este o etapă care nu ar trebui să fie omisă, deoarece va permite echipei depozitului de date să expună și să rezolve problemele înainte de lansarea inițială. Nefinalizarea fazei de testare ar putea duce la întârzieri în implementare sau la încetarea proiectului de depozit de date.
Implementare
Timp de intrare în funcțiune. Decizia de a pune sistemul la dispoziția tuturor deodată sau de a efectua o lansare eșalonată, va depinde de numărul de utilizatori finali și de modul în care aceștia vor accesa sistemul de depozit de date. Un alt aspect important al oricărei implementări de sistem și care este adesea omis, este instruirea utilizatorilor finali. Nu contează cât de „intuitivă” consideră echipa depozitului de date și dezvoltatorii că este interfața grafică (GUI), dacă utilizatorii finali reali consideră că instrumentul este dificil de utilizat sau nu înțeleg beneficiile utilizării depozitului de date pentru raportare și analiză, aceștia nu se vor implica.
Înțelegerea celor mai bune practici pentru proiectarea depozitului de date
Proiectarea depozitului de date este un efort care necesită mult timp și reprezintă o provocare. Vor exista aspecte bune, rele și urâte găsite în fiecare etapă. Cu toate acestea, dacă o organizație își face timp pentru a dezvolta cerințe solide la început, etapele ulterioare ale procesului vor decurge mai logic și vor duce la o implementare de succes a depozitului de date.
.