Ghid pentru extragerea de date prietenoasă cu bugetul

Spre deosebire de programarea tradițională a aplicațiilor, în care funcțiile API se schimbă în fiecare zi, programarea bazelor de date rămâne practic aceeași. Prima versiune a Microsoft Visual Studio .NET a fost lansată în februarie 2002, cu o nouă versiune lansată aproximativ la fiecare doi ani, fără a include lansările Service Pack. Acest ritm rapid al schimbării obligă personalul IT să evalueze aplicațiile corporației lor la fiecare doi ani, lăsând funcționalitatea aplicației lor intactă, dar cu un cod sursă complet diferit, pentru a rămâne la curent cu cele mai recente tehnici și tehnologii.

Nu același lucru se poate spune despre codul sursă al bazei de date. O interogare standard de SELECT / FROM / WHERE / GROUP BY , scrisă încă din primele zile ale SQL, funcționează și astăzi. Desigur, asta nu înseamnă că nu au existat progrese în programarea bazelor de date relaționale; au existat și au fost mai mult logice decât tehnice .

Începând din zilele în care Bill Inmon și Ralph Kimball și-au publicat teoriile despre proiectarea depozitelor de date, progresele în programarea bazelor de date s-au concentrat pe prevenirea pierderii informațiilor valoroase și pe extragerea tuturor informațiilor valoroase din date. Odată ce Inmon și Kimball au introdus lumea bazelor de date în depozitul de date, au fost aduse modificări majore instrumentelor ETL (Extract/Transform/Load), care le-au oferit dezvoltatorilor de baze de date acces ușor la metadate și la date din surse non-relaționale de baze de date, cu care era dificil de lucrat. în trecut. Acest lucru a crescut cantitatea de date disponibile din care să extragă informații valoroase, iar această creștere a datelor disponibile a condus la progrese în procesarea datelor prin cuburi OLAP și algoritmi de data mining.

Adăugarea unui depozit de date, a cuburilor OLAP și a algoritmilor de extragere a datelor la arhitectura bazei de date poate eficientiza în mod dramatic procesele de afaceri și poate lumina modele în datele dvs. despre care altfel nu le-ați fi știut că există. Automatizarea poate avea, de asemenea, un impact profund asupra capabilităților de business intelligence.

Cu toate acestea, înainte de a începe să adăugați noi instrumente și tehnologii, ar trebui să vă asigurați că baza de date a tranzacțiilor este construită corect.

Baza de date de tranzacții

Baza de date de tranzacții este fundația, iar dacă baza de date de tranzacții nu este de încredere și exactă, atunci adăugarea a ceva deasupra este o rețetă pentru dezastru.

Un punct important de reținut atunci când adăugați straturi suplimentare la baza de date este că toate proiectele trebuie să prezinte o rentabilitate a investiției , motiv pentru care este mai bine să profitați la maximum de arhitectura dvs. actuală înainte de a adăuga straturi suplimentare. Toate aceste straturi utilizează date care provin dintr-o bază de date de tranzacții. În multe situații, puteți obține același rezultat prin simpla interogare a bazei de date de tranzacții. Desigur, citirea tuturor rapoartelor dvs. dintr-un depozit de date sau dintr-un cub OLAP este metoda ideală, dar atunci când o organizație nu este pregătită pentru acel nivel de complexitate, este mai important ca nevoile sale de raportare să fie îndeplinite mai întâi. Odată ce nevoile de raportare de bază sunt îndeplinite, este mult mai ușor să începeți o discuție despre modul în care un depozit de date adecvat și, eventual, un cub OLAP, îi pot aduce beneficii afacerii.

Aproape fiecare programator cunoaște cele trei reguli de normalizare a bazelor de date. Procedurile stocate citite din baza de date de tranzacții sunt calea către optimizare. Problemele de căutat sunt lizibilitatea, apelurile multiple către aceeași tabelă de bază de date și utilizarea inutilă a variabilelor.

Toți programatorii de baze de date de elită sunt pretențioși în ceea ce privește lizibilitatea procedurilor lor stocate. Există câteva aspecte comune în modul în care profesioniștii în baze de date își formatează interogările, care este diferit de un dezvoltator de aplicații. În mod obișnuit, cuvintele cheie și funcțiile agregate sunt scrise cu majuscule, în timp ce numele tabelelor și câmpurilor folosesc fie majuscule, fie litere de subliniere. Aliasurile de tabel au o anumită corelație cu numele real al tabelului. Alinierea secțiunilor procedurii stocate are un anumit tip de bloc.

Mai jos este un exemplu de interogare care utilizează un format care poate fi citit.

 SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount FROM customer c JOIN purchase_orders po ON c.customer_id = po.customer_id GROUP BY c.customer_id, c.name

Următorul lucru de căutat este dacă o interogare lovește un tabel de mai multe ori. În majoritatea interogărilor, un tabel trebuie accesat o singură dată, cu excepția cazurilor rare în care trebuie să agregați o altă funcție de agregare. Aceasta este o altă greșeală pe care o fac unii programatori de aplicații, poate pentru că un programator de aplicații gândește în termeni de design orientat pe obiecte.

Designul orientat pe obiecte creează obiecte separate pentru fiecare element de date unic, dar un programator de baze de date trebuie să gândească în termeni de logica setată. Doar pentru că o interogare accesează un tabel de mai multe ori decât este necesar, nu înseamnă că interogarea produce date inexacte, însă performanța interogării este afectată.

O altă problemă este scăderea sau duplicarea înregistrărilor de fiecare dată când aveți o alăturare, compromițând acuratețea interogării dvs. Utilizarea inutilă a variabilelor este încă un semn că o interogare a fost dezvoltată de un dezvoltator de aplicații. Dezvoltatorii de aplicații folosesc variabile în codul lor, în timp ce o interogare foarte rar trebuie să folosească variabile, cu excepția cazului în care este declarată ca parametru al procedurii stocate. Încă o dată este un semn că dezvoltatorul nu s-a gândit în termenii logicii setate.

ETL (Extract Transform Load) și raportare

Odată ce baza de date de tranzacții a unui client are interogări care funcționează corespunzător, următorul pas este eficientizarea proceselor de afaceri.

Cel mai simplu mod de a identifica nevoia unei companii de procese ETL sau de raportare automată este de a afla cine citește datele dintr-o bază de date de tranzacții și apoi manipulează datele folosind o foaie de calcul. O foaie de calcul are aceeași structură ca un tabel de bază de date. Ambele conțin rânduri și coloane. Dacă aveți utilizatori finali care manipulează datele pe cont propriu, ar trebui să vă întrebați: „De ce nu poate fi automatizat acest proces?”

Automatizarea proceselor de afaceri oferă o rentabilitate imediată a investiției și ar trebui să fie întotdeauna luată în considerare înainte de a trece la proiecte mai scumpe, cum ar fi depozitarea de date. Identificarea utilizatorilor finali care manipulează datele printr-o foaie de calcul poate părea simplă, dar există o avertizare la acest proces.

Dezvoltatorilor le place să automatizeze procesele; este ceea ce fac ei. Utilizatorilor finali nu le plac neapărat procesele automatizate, mai ales dacă le amenință munca. Așadar, nu fiți naivi și gândiți-vă că utilizatorii finali se vor adresa dvs. și vor identifica sarcinile zilnice care pot fi automatizate. Chiar trebuie să preiei conducerea în identificarea oportunităților de eficientizare.

Un sistem ETL bine construit ar trebui să ofere, de asemenea, capacitatea de a retrage toate datele încărcate într-o bază de date de tranzacții înapoi la fișierul sursă original. Aceasta este o piesă critică a arhitecturii bazei de date. Dacă nu știți exact data/ora la care fiecare înregistrare a fost adăugată, împreună cu numele sursei (nume de utilizator sau nume de fișier) care a adăugat înregistrările, atunci nu sunteți pregătit să gestionați datele proaste încărcate în baza de date a tranzacțiilor. Ar trebui să vă întrebați: „Dar dacă cineva ne trimite un fișier prost?” Cât timp ți-ar lua să identifici înregistrările care provin din el?

Depozitul de date

Există două teorii pentru proiectarea depozitului de date. Diferența dintre teoriile Inmon și Kimball poate fi rezumată după cum urmează:

Teoria Inmon este să dezvolte mai întâi un depozit de date și apoi să construim marturi de date dimensionale pentru raportarea din depozitul de date. Teoria Kimball este să dezvolte mai întâi platforme de date dimensionale pentru raportare și apoi să le îmbine pentru a crea depozitul de date.

Întotdeauna doriți să oferiți clienților cea mai rapidă rentabilitate a investiției. Construirea de magazine de date este un proces simplu. Începeți prin a prelua interogările din spatele rapoartelor dvs. și le schimbați de la returnarea setului de rezultate la stocarea setului de rezultate în tabele permanente. Pur și simplu adăugați TRUNCATE TABLE tablename ; INSERT INTO tablename înainte de cuvântul cheie original SELECT . Odată ce aveți câteva tabele funcționale de data mart, identificarea oportunităților de îmbinare a data mart-urilor ar trebui să se instaleze; căutați interogări de raport care folosesc aceeași listă de tabele și apoi îmbina lista de câmpuri. Acest lucru necesită o interogare mai complicată, mai ales când lista de tabele crește. Cu toate acestea, atâta timp cât testați amănunțit interogarea, fiecare modificare incrementală poate fi făcută fără a întrerupe procesele normale de afaceri.

De fiecare dată când faceți o îmbunătățire a designului unui depozit de date Kimball, aveți ocazia să arătați un ROI clientului. Acest lucru se datorează faptului că depozitul de date este construit primul, iar magazinele de date de raportare sunt construite dintr-un depozit de date static. Prin urmare, suportați majoritatea costurilor la începutul proiectului de depozit de date.

Cubul OLAP

Un cub OLAP poate aduce beneficii unei organizații prin furnizarea de date agregate cu un timp de răspuns rapid, capabilități ad-hoc de detaliere pentru utilizatorii finali și extragerea datelor. Când aveți un cub OLAP adecvat, puteți extrage fiecare bit de valoare din datele dvs. Un cub OLAP este construit deasupra unui depozit de date, dar folosește un alt limbaj, MDX, decât o bază de date standard SQL. De asemenea, necesită un efort de configurare mai implicat decât un server de baze de date. Această complexitate face un proiect OLAP costisitor, plus că este dificil să găsești dezvoltatori MDX experimentați.

Arhitecții de date văd uneori cuburi OLAP existente cu nimic mai mult decât un simplu tablou de bord care utilizează cubul, fără un singur proces care nu ar putea fi înlocuit cu o interogare SQL, depozit de date sau raport predefinit. Un cub OLAP poate oferi un timp de răspuns mai rapid decât un raport predefinit, dar în majoritatea situațiilor diferența este neglijabilă. De asemenea, puteți beneficia de capabilitățile de detaliere, cu toate acestea, înainte de a oferi utilizatorilor finali capabilități de detaliere, este o idee bună să utilizați rapoarte predefinite care oferă o interfață ad-hoc similară.

Acest lucru vă permite să înregistrați interogările ad-hoc pe care utilizatorii finali le execută, apoi puteți identifica noi rapoarte predefinite despre care utilizatorii finali nu și-au dat seama că ar putea fi create. Deoarece atât timpul de răspuns, cât și îmbunătățirile de detaliere sunt de obicei minime atunci când se dezvoltă un cub OLAP, nu este necesar să îl sugerați unui client până când acesta nu are nevoie de o arhitectură a bazei de date care să poată gestiona minarea de date implicată. Acesta este momentul în care puteți impresiona cu adevărat clienții și le puteți arăta ceva despre afacerea lor pe care s-ar putea să nu l-ar fi știut niciodată fără o arhitectură robustă a bazei de date.

După cum am menționat anterior, construirea unui cub OLAP poate fi o provocare. Este o politică bună să luați în considerare un cub OLAP hibrid. PowerPivot de la Microsoft Excel oferă instrumente de extragere a datelor ușor de utilizat, fără complexitatea unui cub OLAP complet. Principalul dezavantaj al unui hibrid este că nu are același timp de răspuns. Cu toate acestea, un mare avantaj este că este mai ușor să creezi rapoarte de extragere a datelor folosind Excel, comparativ cu utilizarea MDX. Când extragerea de date, există trei rapoarte care sunt utile. Putem analiza câteva exemple din lumea reală și cum să le interpretăm.

Toate aceste rapoarte provin dintr-o aplicație automată de tranzacționare zilnică construită de autor.

Raportare vizuală

Raportul diagramei de dispersie

Un raport de dispersie este un raport la nivel de detaliu care compară două variabile. Adăugarea de culoare și dimensiune la punctele reale ajută la vizualizarea rezultatelor reale în raport cu acele variabile.

Raport cutie și mustăți

Acest raport rezumă valorile x și y din raportul diagramei de dispersie. Valorile axei x sunt discretizate într-un set de găleți.

Capetele fiecărei mustăți (linie) reprezintă valorile aberante. Barele galbene și albastru deschis reprezintă intervalele de abatere standard superioară și inferioară.

Model de regresie liniară

Acest raport arată corelația dintre valorile axei x și y, împreună cu o netezire a liniei, care poate fi reprezentată printr-o formulă matematică. Valoarea R pătrat este inclusă pentru a arăta cât de fiabilă este corelația.

Concluzie

Pe măsură ce compania dvs. crește, de obicei, și baza de date va crește.

Majoritatea organizațiilor nu au nevoie inițial de un profesionist în baze de date sau de o companie dedicată științei datelor care să le gestioneze nevoile. În schimb, personalul IT se ocupă de responsabilități multiple sau, după cum se spune, „poartă multe pălării”. Acest lucru funcționează până la un anumit punct, dar în cele din urmă, trebuie să aduci specialiști.

Elementele enumerate în acest document reprezintă o modalitate rapidă și ușoară de a identifica problemele legate de bazele de date de care este posibil să nu fii conștient. Sperăm că a acoperit și modul în care puteți construi instrumente de extragere a datelor de top fără a cheltui mult pe licențe software costisitoare. În acest fel, veți obține o idee mai bună despre cât de mult ar putea beneficia organizația dvs. prin adăugarea unui profesionist în baze de date personalului dvs. IT.