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.

bune

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.

Este o bună practică să redenumiți toate coloanele din vizualizări, folosind exact numele pe care le veți expune în interfața cu utilizatorul Power BI. Ar trebui să evitați redenumirea tabelelor și coloanelor într-un model de date Power BI. Motivul pentru aceasta este simplificarea întreținerii și asistenței, în afară de a fi un mod mult mai productiv de redenumire a entităților. Dacă redenumiți o coloană în Power BI, dacă utilizatorul va vedea unele date greșite sau lipsă într-un raport, va deschide un apel de asistență menționând entitățile pe care le cunoaște. Dacă aceste nume sunt definite numai în cadrul unui model de date Power BI, probabil că cererea de asistență va fi redirecționată către modelatorul de date, care de cele mai multe ori va deschide modelul de date doar pentru a afla că un anumit tabel din baza de date nu conține dreptul date. Acest lucru se întâmplă numai pentru că majoritatea DBA-urilor nu sunt conștiente de Power BI sau pur și simplu nu au acces la definiția modelului de date. Prin mutarea redenumirii în vizualizări, permiteți oricărui DBA să analizeze dependențele și să triajeze mai bine solicitarea utilizatorului, ridicând apelul la un alt nivel de asistență numai atunci când problema este legată de o problemă de calcul și nu de o actualizare lipsă a unui subiacent tabel (care poate fi rezolvat chiar de DBA).

Dacă utilizați un nume de schemă pentru a include toate vizualizările, eliminați numele schemei din numele importate în Power BI. Din păcate, nu există o modalitate automată de a face acest lucru sau de a importa numele vizualizărilor fără numele schemei, deci aceasta este o operație de redenumire pe care trebuie să o faceți în Power BI.

Utilizați o tehnică care încalcă în mod clar convenția de numire atunci când importați coloane care ar trebui ascunse utilizatorului. De exemplu, dacă aveți o schemă stelară și utilizați chei surogate, puteți utiliza sufixul cheie în numele coloanei fără spațiu, de exemplu utilizând „Cheie client” în loc de „Cheie client”. S-ar putea să luați în considerare adăugarea unui prefix care să mute numele coloanei la începutul unei ordine alfabetice. De exemplu, puteți utiliza „_CustomerKey” în loc de „CustomerKey”. În acest fel, aceste nume vor fi la începutul listei de nume de coloane și va fi mai ușor să verificați dacă toate sunt ascunse. Cu toate acestea, utilizarea unui prefix nu este o idee bună dacă doriți să permiteți utilizatorului să utilizeze o astfel de coloană în transformări și/sau în asocierea datelor cu alte surse de date. Mai mult, dacă coloana conține o cheie de aplicație în loc de o cheie surogat, poate doriți să păstrați convenția de denumire standard (folosind „Cheia clientului”) pentru a menține coloana vizibilă în modelul de date (astfel încât utilizatorul să o poată afișa în rapoarte).

Evitați ambiguitatea în numele coloanelor și măsurilor

Expuneți coloane numerice agregabile într-o vizualizare folosind nume care nu pot fi confundate cu măsuri, ascundeți aceste coloane în modelul de date și creați măsuri explicite.

Gândiți-vă la măsurătorile în avans. Dacă doriți să prezentați numele „Suma de vânzări” utilizatorilor pentru SUMA tuturor sumelor de vânzări, atunci nu puteți utiliza Suma de vânzări ca nume de coloană, altfel motorul va refuza să creeze măsura, deoarece numele acesteia intră în conflict cu o coloană. Folosirea unor nume ciudate precum „Suma de vânzări” pentru o măsură nu este o soluție bună. Dacă intenționați să agregați un număr față de a-l arăta așa cum este, atunci este mai bine să îl importați în model cu o convenție de denumire, apoi să îl ascundeți și să-l expuneți ca măsură. De exemplu, puteți importa SalesAmount ca LineAmount (fără spații, astfel încât să încălcați în mod intenționat regula de a avea spațiu între cuvinte în numele coloanelor și tabelelor), apoi să o ascundeți din raport și să definiți următoarea măsură vizibilă:

Dacă doriți să păstrați datele subiacente existente, marcați-le ca „Nu rezumați” și expuneți numele coloanelor după convenția de denumire. De exemplu, utilizați Cantitatea de linie și Prețul unitar pentru coloanele vizibile cu numele coloanelor originale OrderQuantity și UnitPrice și creați o măsură care să însumeze corect produsul celor două coloane rând cu rând:

Rețineți că utilizarea măsurilor în locul agregărilor implicite a fost întotdeauna o bună practică din multe motive, dar astăzi, cu noua caracteristică Analizați în Excel, este și mai importantă. De fapt, un tabel pivot în Excel nu are nicio agregare implicită, deci vă bazați doar pe măsuri definite în modelul de date pentru a calcula numerele.

Astfel, alegeți standardul și utilizați-l, dar nu importați coloane de valori așa cum se află în tabelul original, dacă acesta este același nume pe care îl va utiliza utilizatorul dvs. pentru măsură.

Eliminați coloanele inutile

Nu expuneți într-o vizualizare o coloană care nu este necesară în modelul de date Power BI.

Chiar dacă nu știți în prealabil ce coloane vor fi utile în modelul de date, încercați să expuneți doar cele necesare. Adăugarea ulterioară a coloanelor la o vizualizare nu are efecte secundare și considerați că modelul de date Power BI va avea probabil toate coloanele dintr-o vizualizare (la urma urmei este implicit).

Prin reducerea coloanelor expuse în vizualizare, reduceți cantitatea de date încărcate în memorie în Power BI și, mai important, evitați expunerea coloanelor cu cardinalitate ridicată, care sunt utilizate numai din motive tehnice (cum ar fi un timestamp și un nume de utilizator pentru ultima modificare) aplicat unui rând dintr-un tabel).

Un număr mai mic de coloane înseamnă un număr mai mic de dependențe între tabelul fizic și rapoarte. Veți plăti costul întreținerii pentru coloanele folosite numai dacă modelul fizic s-ar schimba în viitor.

Data și ora împărțite

Nu expuneți o coloană DATETIME, împărțiți-o întotdeauna în două coloane, una pentru DATE și una pentru TIME. Reduceți precizia TIME, dacă este necesar, până la oră, minut sau secunde, în funcție de cerințele companiei.

Coloanele cu cardinalitate ridicată sunt scumpe în Power BI și o coloană datetime va avea probabil o valoare unică pentru fiecare rând. Prin împărțirea acestor informații în dată și oră, veți economisi memorie, veți crește performanța și veți face modelul de date mai ușor de utilizat. Puteți face această transformare într-o interogare în Power BI, dar dacă faceți acest lucru în avans în vizualizare, veți crește productivitatea utilizând Power BI.

Aplicați Marcare ca tabel de date tabelelor cu date

Funcțiile de informații temporale necesită marcarea unui tabel ca tabel de dată dacă se folosește o coloană cheie surogat (de obicei un număr întreg) în relația dintre un tabel de fapte și o dimensiune.
Chiar dacă acest lucru nu este necesar atunci când o relație se bazează pe o coloană DATE, este o bună practică să decorați întotdeauna un tabel de date cu atributul „Marcați ca tabel de date”. În acest fel, interfața de utilizare și alte caracteristici ale Power BI sunt conștiente de rolul tabelului, îmbunătățind experiența utilizatorului.

Înainte de februarie 2018, Power BI nu avea atributul „Mark as Date Table”. Este o idee bună să aplicați acest atribut în modelele create înainte de februarie 2018.
Citiți, de asemenea, Time Intelligence în Power BI Desktop pentru mai multe informații.

Adaugă toate numerele dintr-o coloană.

Returnează data specificată în format datetime.

DATA (,) TIMPUL

Convertește ore, minute și secunde date ca numere la o oră în format datetime.