Sfaturi pentru o implementare de succes a LuckyTemplates

Vom continua seria noastră despre planificarea și implementarea proiectelor LuckyTemplates. De data aceasta, vom discuta despre designul setului de date , profilarea și modurile . Consultați prima parte a seriei noastre de planificare a proiectelor care se ocupă de modurile de implementare și a doua parte care vorbește despre descoperire și asimilare .

Cuprins

• Design set de date pentru implementarea proiectului LuckyTemplates
  • 4 pași pentru proiectarea setului de date
  • Selectați procesul de afaceri.
    • Anti-modelul de evitat în implementarea LuckyTemplates
  • Declară boabele.
  • Identificați dimensiunile.
  • Definiți faptele.
• Matricea magistralei de date pentru implementarea proiectului LuckyTemplates
• Profilarea datelor pentru implementarea LuckyTemplates
  • Servicii de integrare SQL Server
  • DAX Studio
  • LuckyTemplates Desktop
• Planificarea setului de date pentru implementarea LuckyTemplates
  • Alegerea unui mod de set de date
  • Câteva întrebări de pus atunci când alegeți modurile setului de date
• Concluzie

Design set de date pentru implementarea proiectului LuckyTemplates

Să vorbim despre procesul de proiectare a setului de date și să discutăm despre matricea magistralei depozitului de date , care este un instrument care există de ceva vreme.

Proiectarea seturilor de date power BI este similară cu proiectarea depozitelor de date. Așadar, atât seturile de date, cât și depozitele de date au concepte similare, cum ar fi tabele de fapte și dimensiuni, scheme stea, dimensiuni care se schimbă lent, granularitatea tabelelor de fapte și chei informate locale pentru construirea de relații între tabele.

4 pași pentru proiectarea setului de date

Există patru pași în procesul de proiectare a setului de date: selectați procesul de afaceri , declarați granulația tabelelor de fapte, identificați dimensiunile și apoi definiți faptele .

Selectați procesul de afaceri.

Pentru primul pas, fiecare proces de afaceri este reprezentat printr-un tabel de fapte cu o schemă stea de relații mai multe la unu cu dimensiunile.

În timpul unui proces de descoperire sau de colectare a cerințelor, este dificil să te concentrezi pe un singur proces de afaceri în mod izolat, deoarece utilizatorii analizează în mod regulat mai multe procese de afaceri simultan.

Anti-modelul de evitat în implementarea LuckyTemplates

Anti-modelul comun (care este un răspuns la o problemă recurentă care este în general ineficientă și potențial contraproductivă) pe care doriți să-l evitați în proiectele LuckyTemplates este dezvoltarea de seturi de date pentru proiecte sau echipe specifice, mai degrabă decât pentru procesele de afaceri .

De exemplu, dezvoltarea unui set de date exclusiv pentru echipa de marketing și a unui alt set de date pentru organizația de vânzări. Această abordare duce în mod natural la irosirea resurselor, deoarece aceleași date de vânzări sunt interogate și reîmprospătate de două ori în ambele seturi de date. Acestea vor consuma și resurse de stocare în serviciul LuckyTemplates.

acestea sunt câteva dintre motivele pentru care doriți să treceți printr-un proces bun pentru proiectarea setului de date. O abordare izolată duce la probleme de gestionare și de control al versiunilor, deoarece seturile de date pot conține variații și transformări.

Deși nevoile analitice ale utilizatorilor sau echipelor sunt prioritatea proiectelor LuckyTemplates, este, de asemenea, important să se planifice soluții durabile care să poată fi partajate în cele din urmă între echipe.

Declară boabele.

Tabelele de fapte acoperă în cele din urmă nivelul de detaliu disponibil pentru interogările analitice, precum și cantitatea de date care pot fi accesate.

Deci, granulație mai mare înseamnă mai multe detalii, în timp ce granulație mai mică înseamnă mai puține detalii. Un exemplu în acest sens este atunci când doriți să obțineți nivelul liniei de comandă de vânzări sau dacă doriți ca proiectul să conțină doar nivelul rezumat al fiecărei comenzi de vânzări și să nu ajungă la produsele specifice care au fost comandate ca parte a vânzării respective.

Uneori, acest cereale poate varia în funcție de intervalul de timp. Am întâlnit o serie de clienți care doresc tabele de fapte foarte detaliate pentru trimestrul curent, dar pentru trimestrele precedente, au nevoie doar să știe care au fost vânzările totale pentru trimestrul respectiv.

În timpul acestui pas, doriți să determinați ce reprezintă fiecare rând al diferitelor procese de afaceri . De exemplu, fiecare rând al tabelului de date despre vânzări din depozitul nostru de date reprezintă linia unei comenzi de vânzări de la un client.

În schimb, rândurile unui plan de vânzări și marjă vor fi agregate într-o lună calendaristică, subcategorie de produse și regiune de teritoriu de vânzare. deci, în acest caz, aveți două tabele de fapte diferite și două granule diferite. dacă doriți să comparați cele două, vor fi implicate unele lucrări de modelare a datelor.

Identificați dimensiunile.

Dimensiunile sunt doar produsul secundar natural al boabelor alese în pasul anterior de proiectare.

Deci, un singur rând eșantion din tabelul de fapte ar trebui să indice în mod clar dimensiunile entității de afaceri asociate cu procesul dat, cum ar fi clientul care a achiziționat un proiect individual, produsul la o anumită dată și la o anumită oră. Tabelele de fapte care reprezintă boabele inferioare au dimensiuni mai puține.

De exemplu, un tabel de fapte care reprezintă nivelul antetului unei comenzi de achiziție poate identifica furnizorul, dar nu și achiziția individuală a produsului de la furnizor. deci, în acest caz, nu veți avea nevoie de o categorie de produse sau de o dimensiune de subcategorie de produse incluse.

Definiți faptele.

Faptele reprezintă coloanele numerice incluse în tabelele de fapte. Deci, în timp ce coloanele de dimensiuni de la pasul 3 sunt folosite pentru relații, coloanele de fapte sunt utilizate în măsurile care conțin logica de agregare, cum ar fi suma unei coloane de cantitate sau media unei coloane de preț.

Matricea magistralei de date pentru implementarea proiectului LuckyTemplates

Matricea de magistrală a depozitului de date este un element de bază al arhitecturii depozitului de date Ralph Kimball, care oferă o abordare incrementală și integrată a proiectării depozitului de date.

Arhitectura pe care o vedeți aici este din The Data Warehouse Toolkit , ediția a treia de Ralph Kimball. Permite modele de date scalabile pe care mai multe echipe sau funcții de afaceri le necesită adesea pentru a accesa aceleași procese și dimensiuni de afaceri.

Păstrarea unei matrice de magistrală de depozit de date este utilă. când îl completați, veți ști dacă există alte seturi de date care conțin tabele de fapte și tabele de dimensiuni similare. aceasta promovează reutilizarea proiectului și îmbunătățește comunicarea proiectului.

Deci, fiecare rând reflectă un proces de afaceri important și recurent, cum ar fi închiderea lunară a registrului general. fiecare coloană reprezintă o entitate de afaceri, care se poate referi la unul sau mai multe dintre procesele de afaceri, în timp ce rândurile umbrite reprezintă procesul de afaceri care sunt incluse în proiect.

Profilarea datelor pentru implementarea LuckyTemplates

odată ce ați identificat granulația și procesul de proiectare a setului de date în patru pași a fost finalizat, acesta ar trebui să fie urmat imediat de o analiză tehnică a datelor sursă ale tabelelor de fapte și dimensiuni .

Metadatele tehnice, inclusiv diagramele bazei de date și rezultatele profilării datelor, sunt esențiale pentru etapa de planificare a proiectului.

Aceste informații sunt utilizate pentru a se asigura că setul de date power BI reflectă definițiile de afaceri intenționate și este construit pe o sursă solidă și de încredere.

Deci, trei sunt trei moduri diferite de a colecta acele informații de profilare, care ar trebui să fie primul pas pe care îl vor face oamenii odată ce ies din procesul de proiectare.

Servicii de integrare SQL Server

Există câteva moduri de a proceda în acest sens. O metodă este să utilizați o sarcină de profilare a datelor într-un pachet SQL Server Integration Services (SSIS).

Sarcina de profilare a datelor necesită o conexiune ADO.NET și poate scrie rezultatul într-un fișier XML sau într-o variabilă SSIS.

În acest exemplu, datele sursă ADO.NET sunt un depozit de date AdventureWorks, o bază de date și un server SQL, iar destinația este un fișier XML.

Deci, odată ce sarcina este executată, fișierul XML poate fi citit printr-un vizualizator de profil de date SQL server. Puteți vedea rezultatele în termeni de numărare nulă și procente de numărare nulă.

DAX Studio

Un alt mod de profilare a datelor este prin DAX Studio. trebuie să ingerați efectiv datele într-un set de date LuckyTemplates accesând DAX Studio, accesați fila avansată și rulați VertiPaq Analyzer .

Vă va afișa același tip de informații despre cardinalitatea coloanelor dvs., astfel încât să știți care dintre ele ocupă cel mai mult spațiu în modelul dvs. de date. include toate diferitele statistici din jurul datelor.

LuckyTemplates Desktop

profilarea datelor este disponibilă și în interogare de putere din desktopul LuckyTemplates. dacă accesați fila Vizualizare , puteți activa lucruri precum calitatea coloanei, distribuția coloanei și profilul coloanei. Pentru cel puțin primele mii de rânduri, puteți vedea informații precum erori, valori nule, medii și abateri standard.

Planificarea setului de date pentru implementarea LuckyTemplates

După ce datele sursă sunt profilate și evaluate în raport cu cerințele identificate în procesul de proiectare a setului de date în patru pași, echipa BI poate analiza în continuare opțiunile de implementare pentru setul de date.

În aproape toate proiectele power BI, chiar și în cele cu investiții semnificative în instrumentele și procesele de date ale întreprinderii, depozit, arhitectură și ETL, este necesar un anumit nivel de logică, integrare sau transformare suplimentară pentru a îmbunătăți calitatea și valoarea datelor sursă.

Etapa de planificare a setului de date determină modul în care problemele identificate de transformare a datelor sunt abordate pentru a sprijini setul de date. În plus, echipa de proiect trebuie să stabilească dacă să dezvolte un set de date în modul de import , un set de date cu interogare directă sau un set de date compus .

Pentru a clarifica procesul de planificare a setului de date, această diagramă identifică diferitele straturi ale depozitului de date și ale setului de date LuckyTemplates unde pot fi implementate transformarea și logica de afaceri.

în unele proiecte, este necesară o transformare minimă și poate fi inclusă cu ușurință în setul de date power BI. De exemplu, dacă sunt necesare doar câteva coloane suplimentare pentru un tabel de dimensiuni și există îndrumări simple cu privire la modul în care vor fi calculate aceste coloane, organizația IT poate alege să implementeze aceste transformări în cadrul M power queries, mai degrabă decât să revizuiască depozitul de date.

Dacă decalajul substanțial dintre nevoile BI și depozitul de date corporativ este lăsat să persistă, atunci seturile de date LuckyTemplates devin mai complexe de construit și de întreținut.

Designerii de seturi de date ar trebui să analizeze și să comunice în mod regulat implicațiile setului de date dacă există niveluri mai mari de complexitate.

Cu toate acestea, dacă logica de transformare necesară este complexă sau extinsă, cu mai multe operațiuni comune, filtre de rând și modificări ale tipului de date, atunci organizația IT poate alege să implementeze modificări esențiale în depozitul de date pentru a sprijini noul set de date și viitoarele proiecte BI.

De exemplu, un tabel intermediar și o procedură de stocare SQL pot fi necesare pentru a susține, revizui și actualiza procesul, sau poate fi necesară crearea unui index pentru a îmbunătăți performanța interogărilor pentru seturile de date DirectQuery.

Alegerea unui mod de set de date

Un pas ulterior, dar strâns legat de planificarea setului de date, este alegerea între modul implicit de import, modul DirectQuery/live sau modul compozit.

În unele proiecte, aceasta este o decizie simplă în care o singură opțiune este fezabilă sau realistă, având în vedere cerințele cunoscute, în timp ce alte proiecte vor presupune o analiză semnificativă a avantajelor și dezavantajelor fiecărui design.

Deci, dacă o sursă de date este considerată lentă sau prost echipată pentru a gestiona un volum mare de interogări analitice, atunci un set de date în modul de import este foarte probabil opțiunea preferată.

De asemenea, dacă vizibilitatea aproape în timp real a unei surse de date este esențială, atunci DirectQuery sau modul live este singura opțiune pentru a realiza acest lucru. modurile DirectQuery și live sunt foarte asemănătoare unul cu celălalt. Ambele metode nu stochează date în setul de date în sine și ambele interogează direct sistemele sursă pentru a prelua date pe baza acțiunii utilizatorului. Acum avem seturi de date DirectQuery pentru LuckyTemplates și DirectQuery pentru Analysis Services.

Câteva întrebări de pus atunci când alegeți modurile setului de date

Iată câteva întrebări de adresat atunci când decideți ce mod să utilizați. Există o singură sursă pentru setul nostru de date? Dacă nu există o singură sursă, atunci nu ați putut utiliza sursa DirectQuery/Live în trecut.

Chiar dacă acum avem seturi de date în modul compozit, este totuși o întrebare bună de pus de la început, deoarece dacă nu există o sursă unică, atunci va fi fie de import, fie compozit.

Dacă sursa DirectQuery/Live este o opțiune, este sursa capabilă să accepte interogări analitice? Dacă lucrați cu miliarde sau trilioane de rânduri, atunci poate că un set de date în modul de import nu este fezabil și va trebui să mergeți în modul DirectQuery sau modul compus pentru a vă asigura că setul de date este utilizabil.

Dacă sursa DirectQuery/Live este capabilă să suporte volumul de lucru, este conexiunea DirectQuery/Live mai valoroasă decât performanța și flexibilitatea oferite de un model de import?

Concluzie

Această postare încheie această serie despre planificarea proiectelor LuckyTemplates. cred că aceștia sunt pașii esențiali pentru fiecare proiect power BI la care lucrați. Acești pași sunt importanți atunci când se efectuează diligența necesară, în special într-un cadru de business intelligence pentru întreprinderi.

Toate cele bune,

Greg Deckler