Power BI Fundamentals

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Power BI, episodul 1 din 14. Majoritatea companiilor înoată în date, dar duc lipsă de insight-uri reale. Ai baze de date, spreadsheet-uri și cloud storage pline de cifre, dar când conducerea întreabă cum a performat un produs în ultimul trimestru, toată lumea intră în panică. Soluția pentru a acoperi acest decalaj dintre cifrele împrăștiate și informațiile coerente este ecosistemul Power BI. Power BI nu este un singur produs software. Este o colecție de servicii, aplicații și conectori concepuți să funcționeze împreună. Treaba lui principală este să ia surse de date care nu au legătură între ele și să le transforme în rapoarte interactive, captivante vizual. O capcană frecventă pentru utilizatorii noi este să confunde diferitele părți ale acestui ecosistem, mai exact aplicația desktop și web service-ul. Sunt tool-uri complet diferite, construite pentru faze diferite din lifecycle-ul de raportare. Ca să nu le încurci, ține minte doar că una este fabrica, iar cealaltă este showroom-ul. Fabrica este Power BI Desktop. Asta este o aplicație gratuită pe care o instalezi pe o mașină Windows locală. Power BI Desktop este tool-ul tău principal de creare și editare. Aici se face munca grea. Aici te conectezi la datele tale brute, le cureți și faci designul pentru layout-ul vizual propriu-zis al raportului tău. Gândește-te la un manager de vânzări care primește un fișier Excel masiv, de tip flat file, plin de înregistrări brute ale tranzacțiilor. Să se holbeze la un milion de rânduri de text nu îl ajută să ia o decizie. El deschide Power BI Desktop pe laptop și se conectează direct la acel fișier Excel. Folosește aplicația desktop ca să construiască un raport, adăugând o hartă care să arate vânzările pe regiuni și un bar chart pentru veniturile lunare. Toată această creare se întâmplă local, pe propriul hardware. Odată ce raportul este gata, managerul are nevoie ca restul echipei să îl vadă. Să trimiți pe mail un fișier masiv este ineficient și duce la coșmaruri de version control. Aici devine interesant. În loc să trimită fișierul, managerul îi dă publish în Power BI service. Power BI service este showroom-ul. Este o platformă software-as-a-service cloud-based, accesată printr-un web browser. Când managerul dă click pe publish în aplicația desktop, raportul este urcat în cloud. Acum, restul echipei de vânzări se poate loga în web service. Ei pot vedea dashboard-urile, pot filtra chart-urile și pot interacționa cu datele. Nu trebuie să instaleze Power BI Desktop și nu trebuie să știe cum a fost construit raportul. Ei doar consumă insight-urile. Există și o a treia piesă pentru a completa imaginea, și anume aplicațiile Power BI Mobile. Astea le permit utilizatorilor de pe telefoane și tablete să acceseze în siguranță exact aceleași rapoarte hostate în cloud service, în timp ce sunt departe de birou. Workflow-ul tipic se mișcă într-o singură direcție. Te conectezi la date și construiești un raport în Power BI Desktop. Dai publish la acel raport în Power BI service. Apoi, tu și echipa ta vedeți și interacționați cu acele rapoarte în service sau pe mobil. Aplicația desktop este pentru creator, iar web service-ul este pentru consumator. Construiești local, dar distribui global. Dacă vrei să ajuți la susținerea emisiunii, poți căuta DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Power BI Fundamentals, episodul 2 din 14. Te loghezi pe o nouă platformă de business intelligence în prima ta zi și te simți de parcă ai păși în cabina unui avion. Sunt zeci de meniuri, liste și elemente cu nume similare, dar tu trebuie doar să găsești metricile cheie ale echipei tale fără să strici nimic. Soluția este să înțelegi arhitectura din Power BI Service. Power BI Service este portalul web pe care îl accesezi la app.powerbi.com. Când te loghezi, ajungi pe ecranul de Home. Pagina asta funcționează ca un punct de plecare personalizat, afișând elementele pe care le folosești cel mai des și pe care le-ai accesat recent. Dar ca să navighezi cu adevărat prin sistem, folosești panoul din partea stângă a ecranului. Cel mai important concept din acel panou de navigare este workspace-ul. Un workspace este un container. El îți găzduiește conținutul. Ai un container personal numit My Workspace, care este strict pentru drafturile și experimentele tale private. Nu-l folosi pentru metricile companiei. Pentru colaborare, te bazezi pe workspace-uri shared. Gândește-te la un workspace shared ca la un folder de proiect securizat, unde o anumită echipă își stochează asset-urile de date unificate. În interiorul unui workspace, vei găsi mai multe tipuri distincte de elemente, iar dacă știi cum se leagă între ele, vei reuși să înțelegi platforma. Baza a tot ceea ce vezi este semantic model-ul. Nu te uiți într-un semantic model ca să vezi chart-uri sau grafice. Este structura de date din spate, care conține tabelele, relațiile și calculele. Este motorul. Fiecare număr pe care îl vezi pe ecran este obținut printr-un query dintr-un semantic model. Deasupra acestui motor stă layer-ul vizual, care de obicei ia forma unui raport. Aici e ideea principală. Oamenii folosesc constant cuvintele raport și dashboard de parcă ar însemna exact același lucru. În Power BI, ele sunt obiecte complet diferite, cu comportamente diferite. Un raport este un document cu mai multe pagini, extrem de interactiv. Este legat de un singur semantic model. Când deschizi un raport, poți da click pe chart-uri pentru a face cross-filter pe alte chart-uri, poți folosi meniuri de tip dropdown ca să dai slice la date și poți naviga prin diferite tab-uri din partea de jos a ecranului. Rapoartele sunt construite pentru explorare aprofundată și analiză detaliată. Un dashboard are întotdeauna o singură pagină. Este un canvas custom unde dai pin la elemente vizuale individuale, cunoscute sub numele de tiles, luate din diverse rapoarte. Pentru că poți da pin la tiles de oriunde, un singur dashboard poate combina date din mai multe semantic models diferite într-un singur overview high-level. Nu poți da filter sau slice pe date direct dintr-un dashboard. Dacă dai click pe un tile, acesta acționează ca un shortcut, ducându-te instant în raportul din spate, de unde a provenit acel chart. Dashboard-urile sunt pentru monitorizare rapidă, dintr-o privire. Rapoartele sunt pentru a săpa în detalii. Când o echipă termină de construit semantic models, rapoartele și dashboard-urile într-un workspace, de obicei nu invită toată compania în acel workspace ca să arunce o privire. În schimb, împachetează elementele finalizate într-un app. În Power BI Service, un app este o colecție compilată, read-only, a conținutului din workspace. Când un angajat nou trebuie să găsească KPI-urile diviziei sale, de obicei dă click pe iconița Apps din panoul de navigare din stânga. App-urile oferă o structură de meniu curată și custom, fără să expună fișierele raw din workspace la modificări accidentale. Să înțelegi ecosistemul înseamnă să înțelegi această ierarhie. Dacă vrei să știi cum a ajuns o anumită metrică pe ecranul tău, urmărește lanțul în sens invers. App-ul distribuie dashboard-ul, dashboard-ul trage vizualurile din raport, raportul vizualizează semantic model-ul, iar semantic model-ul trăiește într-un workspace shared. Asta e tot pentru acest episod. Mersi că m-ai ascultat și spor la construit!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Power BI, episodul 3 din 14. Cea mai mare greșeală pe care o fac noii utilizatori Power BI este să construiască un raport critic în contul personal, să plece în vacanță și să-și lase întreaga echipă complet blocată, fără acces la date. Soluția pentru asta este să înțelegi cum să structurezi corect partea de Workspaces și colaborarea. În Power BI, ai două tipuri distincte de medii pentru conținutul tău. În primul rând, există My Workspace. Acesta este sandbox-ul tău personal. Fiecare utilizator Power BI primește unul automat. Este complet privat. Îl folosești ca să te conectezi la sample data, să testezi o formulă nouă sau să schițezi un layout înainte să-l vadă altcineva. Nu folosi My Workspace pentru raportarea oficială a companiei. Dacă construiești dashboard-ul principal de vânzări aici și apoi pleci din companie, echipa ta se va chinui să acceseze sau să actualizeze acel conținut. Soluția este un Workspace standard. Acesta este un mediu partajat în care echipele colaborează pe semantic models, rapoarte și dashboard-uri. Un workspace acționează ca un container securizat pentru un anumit proiect sau departament. Când creezi un workspace, definești exact cine poate intra în acel container și ce acțiuni poate face. Gândește-te la o echipă de finance care construiește un raport financiar pentru Q3. Ai nevoie de mai multe persoane care să contribuie la date, dar ai nevoie de un control strict asupra celor care pot modifica cifrele finale. Aplici asta folosind patru roluri distincte de workspace. Primul este rolul de Admin. Un Admin de workspace are control total asupra mediului. Poate șterge întregul workspace și decide cine primește acces. Administratorul de sistem sau șeful echipei de date de finance preia acest rol. Următorul este rolul de Member. Cei cu rolul de Member gestionează conținutul și fluxul din workspace. Ei pot adăuga colegi cu permisiuni mai mici, pot actualiza semantic models și pot da share la elementele din workspace. Un analist financiar senior care gestionează procesul de raportare pentru Q3 are nevoie de acest rol. Îi permite să țină proiectul în mișcare și să gestioneze accesul echipei fără să fie nevoie să deranjeze un Admin pentru fiecare mică modificare. Apoi, ai rolul de Contributor. Acesta este rolul principal pentru creatorii de conținut. Cei cu rolul de Contributor pot crea, edita și șterge rapoarte și dashboard-uri în cadrul unui workspace. Ei nu pot gestiona permisiunile și nu pot adăuga utilizatori noi. Analiștii care construiesc graficele și tabelele propriu-zise pentru raportul de Q3 primesc acces de Contributor. Ei construiesc conținutul, dar nu controlează limitele de securitate. În cele din urmă, există rolul de Viewer. Cei cu rolul de Viewer pot să se uite pe rapoarte, să facă cross-highlight pe grafice și să filtreze datele, dar nu pot modifica conținutul sau structura din spate. Atribui acest rol directorilor de finance care trebuie să revizuiască raportul de Q3 și să interacționeze cu datele înainte ca acestea să fie lansate către întreaga companie. Iată ideea principală. Permisiunile dintr-un workspace se aplică întregului container. Nu poți acorda cuiva acces de Contributor la un workspace, dar să-i restricționezi vizualizarea unui anumit raport din interiorul acestuia. Un workspace este o singură limită de securitate. Dacă cineva are acces la workspace, poate vedea tot conținutul din interiorul acestuia, restricționat doar de rolul specific pe care i l-ai atribuit. Structura de workspace te obligă să tratezi raportarea ca pe un proces de echipă rezilient. Păstrând drafturile personale izolate în My Workspace și mutând proiectele de echipă în Workspaces partajate cu roluri explicite, arhitectura ta de date rămâne stabilă și accesibilă, indiferent cine este la birou. Asta e tot pentru acest episod. Ne auzim data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Power BI Fundamentals, episodul 4 din 14. Secretul unui raport incredibil de rapid și extrem de precis nu are, de fapt, nicio legătură cu graficele de pe ecran. Când numerele nu se potrivesc între departamente, problema este rareori interfața vizuală. Este arhitectura de date din spate. Astăzi, ne uităm la modelul semantic. Un model semantic, pe care Power BI îl numea înainte dataset, este creierul invizibil din spatele rapoartelor tale. Este o greșeală comună să vezi Power BI doar ca pe un tool care trage un tabel plat dintr-o bază de date sau dintr-un sheet Excel și desenează un grafic peste el. Nu este deloc așa. Un model semantic este o rețea relațională robustă. Stochează tabelele, dar încapsulează și relațiile dintre ele, metadatele de formatare și logica de business predefinită. Stă exact între sursele tale de date brute, dispersate, și rapoartele vizuale, acționând ca un middle layer organizat. Poți aduce date dintr-o bază de date din cloud, dintr-un fișier local și dintr-un web API, și le poți lega pe toate într-o singură structură coerentă. Asta e partea care contează. Nu ai absolut deloc nevoie de un model nou pentru fiecare raport în parte. Un model semantic bine conceput separă logica de bază a datelor de prezentarea vizuală. Ia un scenariu în care compania ta are nevoie de un singur model Customer Truth. Echipa de marketing vrea să urmărească performanța campaniilor, în timp ce echipa de vânzări trebuie să-și monitorizeze pipeline-ul zilnic. Într-un sistem prost conceput, ambele echipe își extrag propriile date, își scriu propriile reguli de business și, inevitabil, creează versiuni concurente ale realității. Într-o arhitectură matură, ambele echipe își conectează rapoartele individuale la exact același model semantic. Construiești logica complexă o singură dată. Acel singur model Customer Truth poate alimenta în siguranță zece rapoarte complet diferite din întreaga organizație. Dacă definiția unui client activ se schimbă anul viitor, actualizezi modelul central. Toate cele zece rapoarte moștenesc automat noua regulă. Modul în care acest model îți gestionează efectiv datele depinde în întregime de storage mode-ul pe care îl selectezi la creare. Cele două paradigme principale sunt Import și DirectQuery. Modul Import trage datele din sursa originală, le comprimă și le încarcă direct în engine-ul in-memory din Power BI. Asta e alegerea default pentru majoritatea proiectelor. Pentru că datele stau în întregime în memorie, calculele complexe și filtrarea interactivă se întâmplă aproape instant. Rapoartele tale se mișcă excepțional de rapid pentru end user. Limitarea este că ții în cache un snapshot al datelor. Trebuie să programezi refresh-uri periodice pentru a trage update-urile și există limite fizice pentru cât de multe date poți împinge în memorie. DirectQuery are o abordare opusă. Nu se importă niciodată date brute. Modelul semantic stochează doar metadatele structurale, cum ar fi numele tabelelor, tipurile coloanelor și relațiile. Când un utilizator dă click pe un filtru din raportul lui, modelul traduce acel click într-un live query și îl trimite direct înapoi către baza de date din spate. Te bazezi pe DirectQuery atunci când dataset-ul tău este pur și simplu prea masiv pentru a fi importat, sau când business-ul cere vizibilitate aproape în timp real asupra sistemului sursă. Trade-off-ul evident este performanța. Un raport care rulează în modul DirectQuery este doar la fel de rapid ca baza de date care răspunde la întrebări, iar fiecare interacțiune pune un compute load direct pe sistemele tale sursă. Visual-urile din workspace-ul tău sunt doar niște ferestre lightweight care se uită la date. Modelul semantic deține adevărul real, iar dacă faci modelul cum trebuie, rapoartele practic se construiesc singure. Mersi că ai stat câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. Power BI Fundamentals, episodul 5 din 14. Dashboard-ul tău poate arăta frumos, dar este complet inutil dacă cifrele sunt vechi de o săptămână. Adevărata provocare este să aduci date proaspete în cloud atunci când baza ta de date este blocată în spatele unui firewall corporate strict. Rezolvarea acestei probleme este exact ceea ce fac Data Connectors și On-Premises Data Gateway. Power BI este doar un recipient gol până când îi furnizezi informații. Pentru a aduce aceste informații, folosești data connectors. Microsoft oferă sute de astfel de conectori out of the box pentru aproape orice sistem la care te poți gândi. Gândește-te la un conector ca la un traducător specializat, pre-built. Indiferent dacă datele tale stau într-o bază de date Oracle, un data warehouse Snowflake sau un serviciu de cloud precum Salesforce, conectorul face tot greul. El gestionează acele API calls specifice, metodele de autentificare și structurile native de query necesare pentru a comunica cu sistemul target. Tu trebuie doar să oferi credențialele și să selectezi tabelele pe care le vrei. Conectorul îți traduce request-ul exact în limbajul pe care îl înțelege sistemul sursă, ceea ce înseamnă că nu trebuie să scrii niciodată scripturi custom de extragere. Când sursa ta de date este deja în cloud, acest proces este seamless. Power BI iese pe internet, se autentifică și face pull la date. Dar realitatea pentru multe organizații este mult mai complicată. Ce se întâmplă când datele tale stau pe un server fizic aflat în subsolul clădirii de birouri? Nu poți pur și simplu să-i ceri unui Power BI din cloud să coboare în rețeaua ta locală privată. Asta ar cere ca echipa ta de IT să deschidă porturi inbound în firewall, expunându-ți baza de date internă la internetul public. Aici este ideea cheie. Nu trebuie să-ți expui rețeaua internă lumii exterioare pentru a lăsa Power BI să-ți citească datele. În schimb, folosești un On-Premises Data Gateway. Gateway-ul este o mică bucată de software pe care o instalezi pe o mașină din rețeaua ta locală. Stă în spatele firewall-ului tău, aproape de sursele tale interne de date. Acționează ca un bridge securizat, outbound. În loc ca Power BI să-și forțeze intrarea în rețeaua ta, comunicarea se întâmplă complet invers. Gateway-ul verifică constant un queue securizat din cloud, folosind o conexiune standard de internet outbound. Pur și simplu întreabă cloud-ul dacă există request-uri de date în așteptare. Pentru că această conexiune este inițiată din interiorul rețelei tale spre exterior, firewall-urile standard permit trecerea traficului fără nicio configurare specială. Hai să ne uităm la un scenariu practic. Ai un raport de vânzări pentru luni dimineața care trebuie să-și dea refresh automat la șase dimineața. Datele brute de vânzări stau pe acel server din subsol, protejat de firewall. La ora șase, serviciul de cloud Power BI înregistrează un request de refresh programat. Câteva momente mai târziu, gateway-ul tău local face poll la queue-ul din cloud și preia acest request. Gateway-ul descarcă instrucțiunile de query, se conectează direct la baza ta de date locală folosind credențialele rețelei interne și execută query-ul local. Odată ce serverul din subsol termină de procesat request-ul, dă datele brute înapoi către software-ul de gateway. Gateway-ul comprimă și criptează aceste date, apoi le dă push către serviciul de cloud Power BI. Cloud-ul primește pachetul criptat, îl decriptează și îți face update la dashboard-ul de vânzări. Folosind această metodă de outbound polling, gateway-ul îți oferă toată puterea analitică a cloud-ului fără să-ți ceară să-ți muți baza de date fizică din subsol. Mersi că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Power BI, episodul 6 din 14. Dacă un stakeholder are nevoie de mai mult de cinci secunde pentru a înțelege ce îi spune dashboard-ul tău, i-ai pierdut atenția. Să pui zece pie charts fără legătură pe un singur ecran nu este analiză, ci doar zgomot vizual. Crearea unui data story ghidat necesită un design deliberat, iar asta ne aduce la Arta Report Canvas-ului. Un raport Power BI este o vizualizare din mai multe perspective asupra semantic model-ului din spate. Report canvas-ul este workspace-ul gol în care construiești acea vizualizare. Nu se limitează la un singur ecran. Poți adăuga mai multe pagini la un raport, la fel ca la o prezentare. Acest lucru îți permite să descompui întrebările de business complexe într-o secvență logică, dedicând pagini diferite pentru aspecte diferite ale datelor. Populezi canvas-ul cu visuals. Acestea sunt charts-urile, graficele, tabelele și hărțile tale. Alegerea visual-ului potrivit este doar primul pas. Layout-ul dictează modul în care utilizatorul citește informațiile. Un canvas bine conceput ghidează ochiul în mod natural de la metricile top-level până la detaliile granulare. Pentru a gestiona layout-uri complexe, folosești grouping. Grouping-ul îți permite să legi împreună mai multe visuals, forme și text boxes. Când grupezi elemente, acestea se scalează și se mișcă ca o singură unitate. Acest lucru îți menține layout-ul precis și previne deplasarea charts-urilor aliniate cu atenție atunci când ajustezi pagina. Pentru a menține un aspect profesional pe toate acele pagini, folosești themes. Un theme este un set de culori, fonturi și reguli de formatare predefinite. Aplici un theme pe raport, iar fiecare visual se actualizează instantaneu pentru a se potrivi cu el. Acest lucru impune consecvența și te scutește de a introduce manual coduri de culoare în zeci de charts-uri separate. Iată ideea cheie. Adevărata putere a canvas-ului nu constă în modul în care arată visuals-urile, ci în modul în care se comportă. În multe instrumente de raportare, charts-urile sunt imagini izolate. În Power BI, visuals-urile de pe aceeași pagină sunt profund conectate by default. Ele fac cross-filter între ele în mod natural, pe baza relațiilor din semantic model-ul tău. Gândește-te la un raport de performanță regională. Plasezi un bar chart care arată vânzările pe categorii de produse în stânga și o hartă geografică care arată locațiile magazinelor în dreapta. Dacă un utilizator dă click pe bara pentru categoria de electronice, întreaga pagină reacționează. Harta evidențiază instantaneu regiunile specifice care au vândut electronice, estompând restul hărții. Utilizatorul nu a căutat nimic și nu ai scris niciun routing logic pentru a realiza interacțiunea. Canvas-ul știe că aceste visuals au în comun aceleași date din spate, așa că atingerea unuia schimbă automat contextul celorlalte. Acest comportament transformă o pagină statică într-un instrument de explorare interactiv. Arta report canvas-ului este să înveți să te dai la o parte. Prin combinarea layout-urilor curate, a themes-urilor consecvente și a cross-filtering-ului nativ, îi permiți utilizatorului să își pună propriile întrebări pur și simplu dând click pe datele din fața sa. Cam atât pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Noțiuni fundamentale despre Power BI, episodul 7 din 14. Cele mai bune rapoarte nu prezintă doar cifre; ele permit utilizatorului final să poarte o conversație cu datele. Dacă construiești un dashboard static care obligă fiecare stakeholder să se uite la exact aceleași totaluri agregate, utilizatorii tăi vor ajunge în cele din urmă să exporte acele cifre într-un spreadsheet pentru a găsi ceea ce îi interesează cu adevărat. Poți preveni asta făcând datele interactive. Există două modalități principale de a preda controlul datelor către utilizatorii tăi în Power BI. Lumea folosește adesea terminologia interschimbabil, deoarece ambele metode obțin un rezultat final similar, dar user experience-ul este fundamental diferit. Vorbim despre slicere și Filters pane. Un slicer este un tip de visual pe care îl pui direct pe canvas-ul raportului tău. Stă chiar acolo, lângă bar charts și line graphs. Pentru că este un visual on-page, iese foarte mult în evidență. Folosești un slicer atunci când vrei să inviți explicit utilizatorul să schimbe view-ul. Ia ca exemplu un raport de vânzări naționale. Un manager regional îl deschide, dar de fapt vrea să se uite doar la propriul teritoriu. Dacă adaugi un slicer pe canvas și îl configurezi ca un simplu dropdown menu, acel manager își poate selecta regiunea specifică. În momentul în care face acea selecție, toate celelalte visual-uri de pe pagină se actualizează imediat pentru a reflecta doar acea regiune. Slicerele permit utilizatorului să dea drill down exact la ceea ce contează pentru el în acel moment. Le poți formata ca liste, dropdown-uri sau chiar date range sliders, dar scopul lor principal este mereu interacțiunea imediată și vizibilă. Acum, a doua parte a acestui concept este Filters pane. Spre deosebire de un slicer, un filtru nu este plasat pe canvas în sine. Acesta se află într-un side-panel dedicat, atașat la marginea ferestrei raportului. Filters pane este locul unde controlezi scope-ul de bază al datelor tale. Acesta funcționează la mai multe niveluri. Poți trage un câmp de date în panou pentru a filtra doar un anumit chart, o pagină întreagă sau uniform pe absolut fiecare pagină din raportul tău. Iată insight-ul cheie. Cea mai mare diferență dintre un slicer și un filtru este vizibilitatea și controlul. Slicerele sunt întotdeauna vizibile pentru utilizator. Filtrele nu trebuie să fie. În calitate de creator al raportului, poți bloca un filtru astfel încât utilizatorul să nu îl poată modifica, sau îl poți ascunde complet. Dacă vrei să construiești o versiune a raportului tău care să afișeze mereu doar date din anul fiscal curent, ai aplica un page-level filter ascuns pentru anul respectiv. Utilizatorul final nu vede niciodată un buton sau un dropdown. Pur și simplu interacționează cu un raport care este limitat în siguranță la perioada de timp corectă. Adesea, vei utiliza ambele instrumente pe exact aceeași pagină. Stabilești regulile de bază ale datelor tale folosind Filters pane, desenând efectiv o cutie în jurul a ceea ce utilizatorul are voie să vadă. Apoi, plasezi câteva slicere strategice în interiorul canvas-ului, astfel încât utilizatorul să poată explora liber în interiorul acelei cutii. Această abordare îți menține canvas-ul curat. Dacă ai încerca să transformi fiecare variabilă posibilă într-un slicer, raportul tău ar deveni ilizibil. Filters pane ascunde setările secundare, păstrând în același timp cele mai importante opțiuni în prim-plan. Oferă-le utilizatorilor tăi slicere on-canvas pentru întrebările pe care trebuie să le pună în fiecare zi și folosește filtrele din side-pane pentru a impune regulile pe care nu ar trebui să le încalce niciodată. Asta e tot pentru acest episod. Mulțumesc că ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Power BI Fundamentals, episodul 8 din 14. Cea mai grea parte din designul de rapoarte este tensiunea dintre claritate și profunzime. Vrei o pagină principală care să arate clean și să spună instant povestea high-level, dar power userii tăi cer fiecare data point granular. Dacă pui totul pe o singură pagină, devine imposibil de citit. Soluția este să ascunzi complexitatea la o singură interacțiune distanță, folosind deep dive-uri contextuale. În primul rând, ia în considerare tooltip-urile custom pentru paginile de raport. By default, când un user dă hover peste un data point dintr-un visual, Power BI afișează un text box simplu cu valoarea exactă a acelui punct. Asta îți dă un număr, dar nu îți oferă niciun context. Un tooltip pe pagina de raport îți permite să înlocuiești acel box default cu un canvas complet customizat. Construiești o pagină de raport mică, ascunsă, și o configurezi să apară atunci când un user dă hover peste un visual. În loc de un simplu număr, poți afișa un mic trend line sau un gauge chart direct în fereastra de hover. Ia ca exemplu un map visual care arată vânzările totale pe orașe. Când un user dă hover peste data bubble-ul pentru Seattle, apare un tooltip custom. În interiorul acelui pop-up se află un bar chart miniatural care detaliază vânzările din Seattle pe ultimele douăsprezece luni. Userul absoarbe instant acest strat extra de informații și nu părăsește niciodată pagina principală cu harta. Uneori, un hover rapid nu este de ajuns. Când un user trebuie să ruleze un audit complet pe un anumit data point, folosești o pagină de drillthrough. Drillthrough-ul este construit pentru investigații aprofundate. Creezi o pagină de raport complet separată și detaliată și îi atribui un field specific, cum ar fi o locație geografică sau o categorie de produse. Asta îi spune lui Power BI că această pagină este o destinație pentru acțiunile de drillthrough. Întoarce-te la aceeași hartă. Userul dă hover pe Seattle, vede trendul lunar, dar decide că numerele necesită o privire mai atentă. Dă click dreapta pe bubble-ul din Seattle și selectează drillthrough. Power BI îl mută de pe hartă și îl duce pe pagina ta de detalii. Cel mai important e că transmite selecția mai departe. Noua pagină este filtrată automat pentru a afișa doar datele pentru Seattle. Acum, se uită la un tabel complet cu tranzacțiile brute de pe facturi. E ușor să confunzi aceste două feature-uri. Tooltip-urile sunt hover box-uri custom care afișează mini-visual-uri fără a părăsi pagina curentă. Sunt gândite pentru o privire rapidă. Drillthrough-ul duce userul pe o pagină de detalii complet nouă, filtrată exact pe selecția lui. Necesită un click explicit și este gândit pentru o analiză aprofundată. Aici e ideea cheie. Nu trebuie să înghesui tabele dense de tranzacții lângă executive summary-urile tale high-level. Folosește tooltip-urile pentru a răspunde la întrebările imediate de follow-up și bazează-te pe paginile de drillthrough pentru a gestiona auditurile complexe. Dashboard-ul tău principal rămâne rapid și aerisit, în timp ce userii tăi au în continuare acces exact la datele de care au nevoie. Dacă vrei să susții podcastul, poți căuta DevStoriesEU pe Patreon — ne ajută enorm. Mersi că ai stat cu noi. Sper că ai învățat ceva nou.

Salut, sunt Alex de la DEV STORIES DOT EU. Power BI Fundamentals, episodul 9 din 14. Poți ajunge doar până la un anumit punct făcând drag and drop la fields pe un canvas. În cele din urmă, ai nevoie ca raportul tău să răspundă la întrebări complexe care nu sunt scrise explicit în baza ta de date. Aici intervine Data Analysis Expressions, sau DAX. Este tentant să te gândești la DAX ca la niște formule avansate de Excel. Arată similar, iar multe nume de funcții sunt identice. Dar Excel operează pe un grid de celule statice, individuale. DAX operează exclusiv pe coloane și tabele întregi. Nu faci niciodată point cu DAX către rândul trei, coloana C. Faci point către coloana de sales amount și lași engine-ul să-și dea seama de restul. Pentru a demistifica DAX, trebuie doar să stăpânești două concepte structurale principale. Acestea sunt calculated columns și measures. Un calculated column este evaluat row by row. Dacă ai nevoie de o coloană care înmulțește unit price cu quantity sold pentru fiecare tranzacție în parte, folosești un calculated column. Engine-ul calculează rezultatul o singură dată, atunci când datele sunt încărcate sau primesc refresh, și îl stochează în memorie. Devine o parte fizică a dataset-ului tău, ceea ce îl face util pentru categorisirea datelor sau construirea de axe pe un chart. Aici este ideea de bază. Calculated columns sunt statice. Nu se modifică atunci când userul interacționează cu dashboard-ul tău. Measures, pe de altă parte, sunt complet dinamice. Un measure nu calculează row by row și nu stochează valori precalculate în memorie. În schimb, calculează un aggregate on the fly, condus de ceva numit filter context. Filter context înseamnă pur și simplu combinația de filtre active în raportul tău la un moment dat. Asta e partea care contează. Când un user dă click pe un anumit an pe un timeline, sau selectează o anumită regiune dintr-un drop-down menu, el schimbă filter context-ul. Acel DAX measure ascultă acele click-uri, restricționează tabelele din spate din memorie pentru a se potrivi cu selecția și recalculează instantaneu răspunsul final. Ia în considerare un scenariu în care scrii un singur DAX measure pentru Year over Year Growth. Pentru că este un measure, nu se blochează într-un singur view specific. Dacă userul tău se uită la un summary card high-level, exact același measure calculează creșterea globală pentru întreaga companie. Dacă dă click pe regiunea europeană de pe o hartă, acel measure se recalculează instantaneu pentru a afișa doar creșterea din Europa. Dacă îi dă slice mai departe după o anumită linie de produse în noiembrie, același measure afișează creșterea doar pentru acel produs în luna respectivă. Scrii matematica din spate o singură dată, iar filter context-ul face munca grea de a o aplica la orice vrea userul să vadă. Calculated columns construiesc structura după care faci slice. Measures efectuează matematica dinamic, pe baza acelor slices. Înțelegerea acestei distincții previne performance bottlenecks masive, cum ar fi încercarea de a forța un row calculation care consumă multă memorie să facă treaba unui aggregate dinamic. Adevărata putere a DAX nu constă în memorarea a sute de funcții distincte, ci în înțelegerea faptului că fiecare calcul are loc în cadrul unei granițe invizibile, în continuă schimbare, setate de user. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Power BI Fundamentals, episodul 10 din 14. Executivii nu au timp să dea click prin cinci documente diferite cu mai multe pagini doar pentru a afla dacă afacerea este sănătoasă. Ei vor să vadă esențialul, pe un singur ecran, chiar acum. Funcționalitatea creată special pentru a rezolva această problemă este dashboard-ul Power BI. Oamenii folosesc adesea cuvintele report și dashboard ca fiind interschimbabile. În ecosistemul Power BI, trebuie să le tratezi drept concepte complet diferite. Un report este un instrument interactiv, cu mai multe pagini, conceput pentru analize aprofundate și este aproape întotdeauna legat de un singur dataset la bază. Un dashboard este strict un canvas pe o singură pagină. Este un rezumat executiv. În plus, nu construiești dashboard-uri în Power BI Desktop. Ele sunt un artefact exclusiv pentru Power BI service. Mai întâi îți construiești report-urile, le publici, și apoi construiești dashboard-ul în întregime în browser. Gândește-te la un CEO care vrea să verifice trei metrici specifice pe telefon în fiecare dimineață. Trebuie să vadă venitul zilnic, server uptime-ul și scorul actual de satisfacție a clienților. Aceste metrici provin în mod natural din zone complet deconectate ale afacerii. Metrica de venit se află într-un report financiar complex. Server uptime-ul este urmărit într-un report dedicat de infrastructură IT. Scorul de satisfacție se află pe pagina trei a unui report de marketing. Nu poți îmbina cu ușurință aceste trei dataset-uri distincte într-un singur report standard. În schimb, creezi un dashboard folosind un mecanism numit pinning. Navighezi la report-ul financiar publicat în browser, selectezi visual-ul de tip card pentru venitul total și îi dai pin pe un dashboard nou. Apoi deschizi report-ul de IT, iei gauge-ul de server uptime și îi dai pin pe același dashboard. În cele din urmă, faci același lucru pentru scorul de satisfacție din report-ul de marketing. Odată ce le-ai dat pin pe canvas-ul dashboard-ului, aceste visual-uri individuale sunt cunoscute sub numele de tiles. Dashboard-ul tău pe o singură pagină este acum o colecție curatoriată de tiles care extrag date live din mai multe report-uri diferite, ceea ce înseamnă că face legătura între mai multe dataset-uri diferite de la bază. Această agregare cross-report este motivul exact pentru care există dashboard-urile. Ele depășesc limitele dataset-urilor individuale pentru a crea o vizualizare unificată. Când un executiv deschide acest dashboard, primește o actualizare de status imediată, dintr-o privire. Nu interacționează cu datele de aici așa cum ar face-o într-un report. În schimb, tile-urile acționează ca puncte de intrare. Dacă tile-ul de venit zilnic arată o scădere bruscă, executivul pur și simplu dă click pe acel tile specific. Această acțiune scoate imediat utilizatorul din dashboard și îl duce direct în report-ul financiar de la bază de unde a provenit acel visual. Iată ideea principală. Dashboard-ul nu este un înlocuitor pentru layer-ul tău de reporting detaliat. Este un layer de curatoriere care stă deasupra acestuia. Un dashboard bine conceput nu încearcă să răspundă la fiecare întrebare analitică posibilă; pur și simplu direcționează utilizatorul către report-ul exact de la bază care conține răspunsurile de care are nevoie chiar acum. Mersi că ne-ai ascultat. Până data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Power BI, episodul 11 din 14. Dacă împarți un workspace cu cinci sute de oameni care trebuie doar să vadă datele, faci o greșeală. Le arăți dezordinea din bucătărie când ei au venit doar să mănânce. Modul corect de a livra conținutul final este să împachetezi experiența, iar asta înseamnă să folosești un Power BI App. Un Power BI App nu este un program software de sine stătător pe care îl descarci dintr-un app store pe telefon. În acest context, un App este o colecție de dashboard-uri și rapoarte, prezentate ca un singur pachet unificat. Este metoda oficială de distribuție pentru conținutul tău Power BI finalizat. Hai să clarificăm din start principala confuzie, și anume diferența dintre un workspace și un App. Un workspace este bucătăria ta. Acolo, creatorii de rapoarte se conectează la date, construiesc modele și testează diferite layout-uri de chart-uri. Este o zonă de colaborare destinată celor care construiesc, și poate fi aglomerată cu rapoarte draft și dataset-uri brute. App-ul este sala de mese. Este curat, organizat și conceput strict pentru consum. Când publici un App, iei farfuriile gata pregătite din bucătărie și le prezinți oaspeților tăi. Gândește-te că trebuie să lansezi metricele oficiale ale companiei pe 2026 către cinci sute de angajați din diferite departamente. Nu vrei ca ei să caute printr-un workspace ca să-și dea seama care raport e versiunea finală. De asemenea, nu vrei să le trimiți cinci link-uri web diferite. În schimb, creezi un App. Când construiești un App, selectezi exact ce dashboard-uri și rapoarte din workspace-ul tău vrei să incluzi. Lași în urmă draft-urile. Apoi, creezi un meniu de navigare custom. Aici devine interesant. În loc de o listă simplă de fișiere, poți grupa rapoartele care au legătură între ele sub headere collapsible. Poți ordona paginile astfel încât povestea să curgă logic, de la rezumate high-level până la detalii granulare. Poți chiar să aplici o anumită temă de culori și să adaugi logo-ul companiei tale. Pentru end-user, experiența este seamless. Ei instalează App-ul o singură dată din directorul organizațional. Când îl deschid, primesc o interfață branded, read-only. Nu există butoane de edit care să le distragă atenția. Nu pot șterge accidental un visual sau altera dataset-ul. Pur și simplu folosesc meniul lateral pentru a da click prin rapoarte. Dacă deschid aplicația de mobil Power BI, App-ul și structura lui de navigare custom funcționează perfect și acolo. Iată ideea de bază pentru mentenanța acestui conținut. Pentru că workspace-ul și App-ul sunt separate, poți face update la rapoarte fără să strici experiența utilizatorului. Dacă o metrică trebuie ajustată, faci acea modificare în bucătăria din workspace. Cei cinci sute de utilizatori ai tăi nu văd visual-urile stricate sau chart-urile pe jumătate terminate în timp ce lucrezi. App-ul lor rămâne exact la fel până când ești complet gata. După ce ai terminat, dai click pe update la App, iar noua versiune devine live pentru toată lumea în același timp. Când trebuie să livrezi un set de rapoarte coerent și ușor de navigat către un public larg, construiește workspace-ul pentru autorii tăi, dar împachetează App-ul pentru consumatori. Îți mulțumesc că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. Power BI Fundamentals, episodul 12 din 14. Cea mai rapidă modalitate de a garanta că nimeni nu se uită la dashboard-ul tău este să îi pui să deschidă un nou tab în browser, să găsească un bookmark și să se logheze într-un portal separat. Context switching-ul omoară adopția. Dacă vrei ca oamenii să folosească datele, trebuie să le pui exact acolo unde ei comunică deja. Asta este ideea centrală din spatele conceptului Meeting Users Where They Work. Pentru majoritatea organizațiilor, acel loc este Microsoft Teams. Power BI se integrează profund în Teams pentru a elimina fricțiunea de context switching. În loc să trimiți un link către un dashboard pe chat, aduci dashboard-ul direct în workspace. Gândește-te la o echipă dintr-un depozit care trebuie să verifice nivelul stocurilor în fiecare dimineață. Poți să dai pin unui raport de inventar live, direct ca un tab în canalul lor dedicat de Teams. Dau click pe tab, iar datele sunt pur și simplu acolo, fix lângă mesajele lor de dimineață. Există o neînțelegere frecventă despre cum arată chestia asta. A face push la un raport în Teams nu înseamnă doar să trimiți un screenshot static sau un PDF deconectat. Înseamnă să dai embed raportului Power BI complet, live și interactiv, în mod securizat, direct în clientul de Teams. Userii pot da slice, filter și drill down în date, direct din canal. Permisiunile de securitate rămân strict aplicate. Dacă un user nu are permisiuni să vadă datele în serviciul Power BI, nu le va putea vedea nici în Teams. De asemenea, poți începe un thread de conversație atașat direct de un anumit visual din raport, păstrând discuția și datele în exact același context. Asta acoperă comunicarea zilnică. Acum gândește-te la ședințele executive. Prezentările sunt, de obicei, locul unde datele se duc să moară. Cineva face un screenshot la un chart, îi dă paste într-un slide, și cinci minute mai târziu, baza de date din spate își face update. Slide-ul devine instant out of date. Power BI rezolvă asta permițându-ți să dai embed la pagini de raport live direct în slide-urile de PowerPoint. Când deschizi prezentarea, chart-ul trage cele mai recente cifre. Aici e ideea cheie. Pentru că raportul embedded este complet interactiv, schimbă modul în care se desfășoară ședințele. Când un stakeholder pune o întrebare specifică despre un spike în vânzări, nu trebuie să o notezi și să promiți că revii cu un follow-up mai târziu. Poți da click pe acel data point direct pe slide-ul prezentării, poți face cross-filter pe visual-uri și poți răspunde la întrebare live. În final, avem Excel. Nu vei opri niciodată userii de business să își dorească datele într-un spreadsheet. În loc să te lupți cu acest comportament și să te uiți cum oamenii exportă fișiere CSV statice și necontrolate, poți integra Power BI perfect cu Excel. Userii pot conecta PivotTable-uri, chart-uri și formule standard de Excel direct la un dataset Power BI publicat. Datele rămân gestionate centralizat, securizate și precise pe server. Între timp, userii pot analiza acel single source of truth folosind interfața de tip grid pe care o cunosc deja. Nu construiești o cultură data-driven forțând pe toată lumea să învețe o nouă aplicație standalone. Faci asta injectând date live, de încredere, direct în tool-urile de comunicare pe care le deschid deja în fiecare dimineață. Îți mulțumesc că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamente Power BI, episodul 13 din 14. Probabil că petreci prea mult timp dând refresh la dashboard-uri doar ca să verifici dacă totul funcționează fără probleme. Userii tăi fac exact același lucru, logându-se în fiecare dimineață doar ca să confirme că numerele sunt normale. Nu te mai baza pe oameni ca să verifice problemele de rutină. Lasă datele să-ți spună când ceva nu merge bine. Asta e ideea centrală din spatele BI-ului proactiv, realizată prin combinarea alertelor de date din Power BI cu Power Automate. În mod tradițional, business intelligence-ul este reactiv. Construiești un raport, îi dai publish și aștepți ca cineva să-l deschidă. BI-ul proactiv inversează modelul ăsta. Sistemul se monitorizează singur și îți trimite informații doar atunci când atenția ta este cu adevărat necesară. Când o anumită metrică depășește un prag predefinit, sistemul ia măsuri imediat. Înainte să setezi asta, trebuie să clarificăm o confuzie comună. Nu poți atașa aceste alerte automate la orice visual ascuns adânc într-o pagină complexă de raport. Alertele de date din Power BI sunt strict legate de anumite tipuri de visual-uri de pe un dashboard. Le poți configura doar pe tile-uri cu o singură valoare, mai exact pe gauge-uri, KPI-uri și card-uri. Dacă ai o metrică critică pe care vrei să o monitorizezi într-un raport detaliat, trebuie mai întâi să dai pin acelui visual specific pe un dashboard pentru a debloca funcția de alerting. Hai să trecem printr-un scenariu concret. Să presupunem că urmărești vânzările zilnice pentru o locație importantă de retail. Așteptarea de baseline este de zece mii de dolari pe zi. Dacă vânzările scad sub acest număr, să aștepți ca un manager să verifice dashboard-ul vineri este prea târziu. Ai nevoie de un răspuns imediat. Mai întâi, configurezi o alertă de date pe card-ul de pe dashboard care afișează vânzările zilnice. Definești o regulă care îi spune lui Power BI să declanșeze o alertă dacă valoarea scade sub zece mii. Fii atent la partea asta. Power BI nu monitorizează baza de date sursă în timp real. În schimb, ori de câte ori dataset-ul Power BI din spate își face refresh, sistemul evaluează noul număr de pe acel card. Dacă este îndeplinită condiția, alerta se declanșează. By default, o alertă declanșată generează pur și simplu o notificare în interiorul serviciului Power BI sau trimite un email basic persoanei care a creat regula. Ca să faci asta cu adevărat util în cadrul unui business, o integrezi cu Power Automate. Power Automate stă liniștit în fundal și ascultă după acea alertă specifică de date din Power BI. Când alerta se declanșează, Power BI transmite un data payload către Power Automate. Acest payload conține titlul alertei, pragul pe care l-ai setat și valoarea reală care a încălcat regula. Folosești aceste valori dinamice pentru a construi un workflow downstream. Poți configura flow-ul astfel încât, în momentul în care metrica de vânzări scade, să se întâmple automat două lucruri. În primul rând, flow-ul extrage valoarea reală a vânzărilor și trimite o notificare imediată direct pe telefonul mobil al managerului de magazin. În al doilea rând, trimite un email automat echipei regionale cu cifrele exacte și un link direct înapoi către dashboard pentru investigații suplimentare. Nimeni nu a trebuit să deschidă manual Power BI ca să descopere problema. Prin integrarea alertelor din dashboard cu automatizarea downstream, elimini blocajul uman din răspunsul la incidente. Adevărata valoare a unui sistem de monitorizare nu se măsoară prin câți oameni se uită la el în fiecare zi, ci prin cât de repede forțează o acțiune în momentul în care o limită critică este încălcată. Asta e tot pentru acest episod. Mersi pentru ascultare și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Power BI Fundamentals, episodul 14 din 14. Te uiți la un canvas gol, având nevoie de un raport de vânzări complet până la sfârșitul zilei. În loc să faci drag and drop la câmpuri ore în șir, pui pur și simplu o întrebare în plain text, iar layout-ul se construiește singur. Viitorul în business intelligence este conversațional, susținut de Copilot în Power BI. Există o teamă persistentă că inteligența artificială este aici pentru a înlocui data analyst-ul. Nu este cazul. Copilot este un asistent puternic conceput special pentru a-ți accelera primul draft. El se ocupă de setup-ul inițial plictisitor, lăsându-ți timp să te concentrezi pe rafinarea insight-urilor reale. Acoperă distanța dintre raw data și un raport finalizat folosind limbaj natural, făcând faza inițială de creare mult mai rapidă. Când deschizi report builder-ul, poți interacționa direct cu panoul Copilot. Tastezi un prompt, cum ar fi să-i ceri să creeze un rezumat al performanței vânzărilor. Copilot analizează imediat semantic model-ul din spate. El determină ce metrici contează în funcție de cerința ta, selectează tipurile de vizualuri adecvate și generează automat o pagină de raport completă. Nu trebuie să plasezi manual bar chart-uri sau să configurezi axe pentru a începe. Îți declari intenția, iar sistemul traduce acea intenție într-un layout concret. Acest lucru schimbă fundamental modul în care abordezi crearea rapoartelor, trecând de la construcția manuală la o direcție high-level. Iată insight-ul cheie. Copilot nu construiește doar chart-uri; scrie povestea datelor tale. Alături de vizualuri, generează un text box narativ care rezumă factorii cheie și trendurile în plain English. Acesta nu este un text static. Deoarece este legat direct de semantic model, narațiunea este complet dinamică. Dacă datele din spate se modifică peste noapte sau dacă un user dă click pe o anumită regiune dintr-un map visual, textul se rescrie instantaneu pentru a reflecta noul context. Rezumatul rămâne mereu sincronizat cu view-ul curent al datelor, fără a necesita update-uri manuale. Această interfață conversațională reduce drastic bariera de intrare pentru generarea de insight-uri. Nu ai nevoie de cunoștințe tehnice aprofundate despre tool pentru a extrage valoare din date. Cu toate acestea, menții controlul absolut. Odată ce AI-ul generează acel layout și acea narațiune inițială, intervii tu. Poți redimensiona vizualurile, poți ajusta formatarea sau poți modifica narațiunea pentru a se potrivi exact specificațiilor tale. Este un workflow colaborativ. Copilot construiește fundația grea, iar tu aplici retușurile finale pentru a te asigura că produsul final îndeplinește standardele organizației tale. Adevărata putere a limbajului natural în business intelligence nu constă doar în economisirea câtorva click-uri de mouse; este vorba despre eliminarea completă a fricțiunii dintre a avea o întrebare de business și a vedea răspunsul pe ecran. Întrucât acesta este episodul final al seriei noastre de fundamentals, îți recomand cu căldură să explorezi documentația oficială Microsoft și să încerci aceste funcționalități hands-on cu propriile tale semantic models. Dacă ai idei despre ce ar trebui să acoperim în continuare, vizitează devstories dot eu pentru a sugera subiecte pentru seriile viitoare. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!