Cele mai bune practici de import de date în Power BI - SQLBI
Nu toate sugestiile descrise pot fi aplicate tuturor modelelor dvs. de date. Ar trebui să adaptați aceste bune practici la scenariul dvs. specific, analizând cum să atingeți obiectivele care sunt motivul unui anumit tipar mai mult decât abia să îl aplicați, fără a lua în considerare avantajele și dezavantajele fiecărei alegeri.
Chiar dacă articolul menționează Power BI, toate cele mai bune practici descrise sunt valabile și pentru modelele tabulare Power Pivot și Analysis Services. Fișierul demo pe care îl puteți descărca (la sfârșitul articolului) conține un exemplu de fișier Power BI și vizualizările corespunzătoare definite într-un fișier SQL pentru AdventureWorksDW.
Folosiți vizualizări
Importați întotdeauna vizualizări și nu importați niciodată tabele într-un model de date.
Dacă obțineți date dintr-o bază de date relațională, cum ar fi SQL Server sau Oracle, nu ar trebui să importați niciodată un tabel de baze de date direct în modelul dvs. de date. Motivul este că acest lucru creează o dependență puternică între modelul de date fizice și raport. În timp, anumite modificări ale structurii bazei de date ar putea corupe un raport existent. De exemplu, redenumirea unei coloane sau a unui tabel sau modificarea cardinalității unui tabel sunt toate operațiuni care necesită o modificare corespunzătoare la modelul de date Power BI.
Adevărata problemă este că nimeni nu știe câte rapoarte pot fi afectate de o anumită modificare. Chiar dacă o analiză a dependențelor ar fi posibilă din punct de vedere tehnic, astăzi nu avem un instrument și o procedură standard pentru a face acest lucru. Crearea de vizualizări specifice pentru fiecare model de date corespunde introducerii unui strat de indirectare care simplifică gestionarea modificărilor structurii bazei de date.
Cea mai bună practică pentru utilizarea vizualizărilor este:
- Creați o schemă pentru un anumit model de date: de exemplu, ar putea fi numele martorului de date sau numele grupului de rapoarte care va partaja același model de date.
- Creați o vizualizare pentru fiecare tabel pe care doriți să îl creați în modelul de date Power BI din schema respectivă.
- Includeți în vizualizare doar coloanele care sunt utile și vor fi utilizate în modelul de date Power BI.
- Când importați tabelele în Power BI, eliminați numele schemei și păstrați doar numele vizualizării.
Urmând această bună practică, declarați în baza de date care sunt tabelele și coloanele utilizate într-un raport, astfel încât administratorul bazei de date să fie la curent cu dependențele existente din baza de date în sine. Înainte de a publica în producție o modificare a structurii bazei de date, este posibil să se adapteze aceste vizualizări astfel încât acestea să continue să funcționeze returnând același conținut, fără a rupe reîmprospătarea rapoartelor existente. Mai mult, este mult mai ușor să urmăriți dependențele dintre vizualizări și tabele într-o singură bază de date relațională. De exemplu, în SQL Server puteți utiliza caracteristici încorporate (cum ar fi Vizualizarea dependențelor unui tabel) sau instrumente terță parte (cum ar fi SQL Dependency Tracker de la Red Gate).
Păstrarea tuturor vizualizărilor pentru un model de date în aceeași schemă simplifică urmărirea rapoartelor dependente. Schimbarea vizualizării pentru a păstra compatibilitatea cu rapoartele existente este de obicei un prim pas temporar. Dacă ați modificat structura bazei de date, probabil că doriți să reflectați această modificare în rapoarte, dar cu un calendar diferit. Nu veți întârzia implementarea în producerea anumitor modificări ale bazei de date, deoarece nu trebuie să sincronizați implementarea unei noi versiuni a tuturor rapoartelor existente. Trebuie doar să implementați o versiune compatibilă a vizualizărilor care utilizează noua structură și să anunțați analiștii BI care dețin modelul de date că ar putea utiliza o nouă versiune a datelor, coordonând cu aceștia modul de furnizare a noii structuri (pentru de exemplu, prin schimbarea vizualizărilor existente sau prin furnizarea de vizualizări diferite).
Vizualizările create ar trebui să includă o listă explicită de coloane și nu ar trebui să fie una generică, cum ar fi:
Vizualizările pot include transformarea datelor. Acest lucru este important atunci când doriți să includeți logica de afaceri care ar trebui să fie partajată între diferite modele de date, deci nu trebuie să copiați aceeași logică de transformare în mai multe modele de date Power BI.
Prin importarea vizualizărilor în loc de tabele, modelul de date ar putea să nu recunoască toate relațiile existente între tabele, deoarece constrângerile de integritate referențială sunt aplicate tabelelor și nu vizualizărilor. Cu toate acestea, adăugarea manuală a relațiilor la modelul de date este doar un cost minim
Folosiți nume semnificative
Numele atât ale vizualizărilor, cât și ale coloanelor expuse în vizualizări ar trebui să fie ușor de utilizat și identice cu numele expuse utilizatorilor.
Ar trebui să eliminați orice prefix și orice sufix pe care îl puteți folosi în numele tabelelor. De exemplu, este obișnuit să vezi Dim și Fact folosite ca prefixe ale tabelelor într-o schemă stelară relațională. Nu are rost să arăți aceste prefixe utilizatorului. De asemenea, ar trebui să evitați prefixele vizualizărilor precum „v” sau „vw”. Ar trebui să afișați „Clienți” în loc de „DimCustomers” sau „vwCustomers”.
Ar trebui să evitați abrevierile, prefixele și sufixele din numele coloanelor. Cu toate acestea, o excepție este posibilă pentru acronimele bine cunoscute. De exemplu, ar trebui să utilizați „Suma vânzări” în loc de „SalesAmt” sau „SalesAmount”. Puteți utiliza spațiu și caractere speciale în numele coloanelor unei vizualizări. Scopul este de a simplifica viața utilizatorului și nu de a simplifica viața unui programator care trebuie să introducă un nume de coloană în tastatură. În Power BI, aveți Intellisense când scrieți o formulă DAX.