Acara
Bergabunglah dengan kami di FabCon Vegas
31 Mar, 23 - 2 Apr, 23
Acara utama yang dipimpin komunitas Microsoft Fabric, Power BI, SQL, dan AI. 31 Maret hingga 2 April 2025.
Daftar hari iniBrowser ini sudah tidak didukung.
Mutakhirkan ke Microsoft Edge untuk memanfaatkan fitur, pembaruan keamanan, dan dukungan teknis terkini.
Artikel ini menargetkan Power BI Desktop pemodel data. Ini menjelaskan desain skema bintang dan relevansinya untuk mengembangkan model semantik Power BI yang dioptimalkan untuk performa dan kegunaan.
Penting
Model semantik Power BI bergantung pada Power Query untuk mengimpor atau menyambungkan ke data. Itu berarti Anda harus menggunakan Power Query untuk mengubah dan menyiapkan data sumber, yang mungkin menantang ketika Anda memiliki volume data besar atau Anda perlu menerapkan konsep tingkat lanjut seperti mengubah dimensi secara perlahan (dijelaskan nanti di artikel ini).
Saat Anda dihadapkan dengan tantangan ini, kami sarankan Anda terlebih dahulu mengembangkan proses gudang data dan Ekstrak, Transformasi, dan Muat (ETL) untuk memuat gudang data secara berkala. Model semantik Anda kemudian dapat terhubung ke gudang data. Untuk informasi selengkapnya, lihat Pemodelan dimensi di Microsoft Fabric Warehouse.
Tip
Artikel ini tidak dimaksudkan untuk memberikan diskusi lengkap tentang desain skema bintang. Untuk informasi selengkapnya, lihat langsung ke konten yang diterbitkan secara luas, seperti Toolkit Gudang Data: Panduan Definitif untuk Pemodelan Dimensi (edisi ke-3, 2013) oleh Ralph Kimball, dan lainnya.
Skema bintang adalah pendekatan pemodelan matang yang diadopsi secara luas oleh gudang data relasional. Skema bintang membutuhkan pemodel untuk mengklasifikasikan tabel model sebagai dimensi atau fakta.
Date
kunci dimensi dan ProductKey
. Sangat mudah untuk memahami bahwa tabel memiliki dua dimensi. Namun, granuralitas tidak dapat ditentukan tanpa mempertimbangkan nilai kunci dimensi. Dalam contoh ini, pertimbangkan bahwa nilai yang disimpan dalam Date
kolom adalah hari pertama setiap bulan. Dalam kasus ini, granuralitas berada pada tingkat produk bulan.Umumnya, tabel dimensi berisi jumlah baris yang relatif kecil. Tabel fakta, di sisi lain, dapat berisi sejumlah besar baris dan terus bertambah dari waktu ke waktu.
Untuk memahami beberapa konsep skema bintang yang dijelaskan dalam artikel ini, penting untuk mengetahui dua istilah: normalisasi dan denormalisasi.
Normalisasi adalah istilah yang digunakan untuk menjelaskan data yang disimpan dengan cara yang mengurangi data berulang. Pertimbangkan tabel produk yang memiliki kolom nilai kunci unik, seperti kunci produk, dan kolom lain yang menjelaskan karakteristik produk, seperti nama produk, kategori, warna, dan ukuran. Tabel penjualan dianggap dinormalisasi ketika hanya menyimpan kunci, seperti kunci produk. Dalam gambar berikut, perhatikan bahwa hanya kolom yang ProductKey
merekam produk.
Namun, jika tabel penjualan menyimpan detail produk di luar kunci, tabel tersebut dianggap di-denormalisasi. Dalam gambar berikut, perhatikan bahwa ProductKey
dan kolom terkait produk lainnya merekam produk.
Saat Anda sumber data dari file ekspor atau ekstrak data, kemungkinan data tersebut mewakili sekumpulan data yang dinormalisasi. Dalam hal ini, gunakan Power Query untuk mengubah dan membentuk data sumber menjadi beberapa tabel yang dinormalisasi.
Seperti yang dijelaskan dalam artikel ini, Anda harus berusaha untuk mengembangkan model semantik Power BI yang dioptimalkan dengan tabel yang mewakili fakta dan data dimensi yang dinormalisasi. Namun, ada satu pengecualian di mana dimensi snowflake mungkin didenormalisasi untuk menghasilkan satu tabel model.
Desain skema bintang dan banyak konsep terkait yang diperkenalkan dalam artikel ini sangat relevan dengan pengembangan model Power BI yang dioptimalkan untuk performa dan kegunaan.
Pertimbangkan bahwa setiap visual laporan Power BI menghasilkan kueri yang dikirim ke model semantik Power BI. Umumnya, kueri memfilter, mengelompokkan, dan meringkas data model. Model yang dirancang dengan baik, adalah model yang menyediakan tabel untuk pemfilteran dan pengelompokan, dan tabel untuk dirangkum. Desain ini cocok dengan prinsip skema bintang:
Tidak ada properti tabel yang diatur pemodel untuk mengatur jenis tabel sebagai dimensi atau fakta. Hal ini sebenarnya ditentukan oleh hubungan model. Hubungan model menetapkan jalur penyebaran filter antara dua tabel, dan itu adalah properti kardinalitas hubungan yang menentukan jenis tabel. Kardinalitas hubungan yang sama adalah satu-ke-banyak atau kebalikannya banyak-ke-satu. Sisi "satu" selalu merupakan tabel dimensi sementara sisi "banyak" selalu merupakan tabel fakta.
Desain model yang terstruktur dengan baik mencakup tabel yang merupakan tabel dimensi atau tabel fakta. Hindari mencampur dua jenis bersama-sama untuk satu tabel. Kami juga menyarankan agar Anda berusaha untuk memberikan jumlah tabel yang tepat dengan hubungan yang tepat. Penting juga bahwa tabel fakta selalu memuat data pada butir yang konsisten.
Terakhir, penting untuk dipahami bahwa desain model yang optimal adalah bagian sains dan seni bagian. Terkadang Anda dapat memutuskan dengan panduan yang baik ketika masuk akal untuk melakukannya.
Ada banyak konsep yang terkait dengan desain skema bintang yang dapat diterapkan ke model semantik Power BI. Konsep-konsep ini meliputi:
Dalam desain skema bintang, ukuran adalah kolom tabel fakta yang menyimpan nilai yang akan diringkas. Dalam model semantik Power BI, pengukuran memiliki definisi yang berbeda—tetapi serupa—. Model mendukung langkah-langkah eksplisit dan implisit.
SUM
, , MIN
, MAX
AVERAGE
, dan lainnya untuk menghasilkan hasil nilai skalar pada waktu kueri (nilai tidak pernah disimpan dalam model). Ekspresi pengukuran dapat berkisar dari agregasi kolom sederhana hingga rumus yang lebih canggih yang menggantikan konteks filter dan/atau propagasi hubungan. Untuk informasi selengkapnya, baca tentang Dasar-Dasar DAX di Power BI Desktop.Sales Amount
penjual Adventure Works dapat dirangkum dengan berbagai cara (jumlah, jumlah, rata-rata, median, min, maks, dan lainnya), tanpa perlu membuat ukuran untuk setiap jenis agregasi yang mungkin.Di panel Data , langkah-langkah eksplisit diwakili oleh ikon kalkulator sementara ukuran implisit diwakili oleh simbol sigma (∑).
Namun, ada tiga alasan menarik mengapa Anda dapat membuat langkah-langkah, bahkan untuk ringkasan tingkat kolom sederhana:
Ketika Anda tahu penulis laporan Anda akan mengkueri model semantik dengan menggunakan Ekspresi Multidmensional (MDX), model harus menyertakan langkah-langkah eksplisit. Itu karena MDX tidak dapat mencapai ringkasan nilai kolom. Terutama, MDX digunakan saat melakukan Analisis di Excel karena PivotTable mengeluarkan kueri MDX.
Saat Anda mengetahui penulis laporan Anda akan membuat laporan paginasi Power BI dengan menggunakan perancang kueri MDX, model semantik harus menyertakan langkah-langkah eksplisit. Hanya desainer kueri MDX yang mendukung agregat server. Jadi, jika penulis laporan perlu memiliki langkah-langkah yang dievaluasi oleh Power BI (bukan oleh mesin laporan yang diberi nomor halaman), mereka harus menggunakan desainer kueri MDX.
Saat Anda ingin mengontrol bagaimana penulis laporan Meringkas kolom dengan cara tertentu. Misalnya, kolom penjualan Unit Price
penjual (yang mewakili laju per unit) dapat diringkas, tetapi hanya dengan menggunakan fungsi agregasi tertentu. Ini tidak boleh dijumlahkan, tetapi tepat untuk meringkas dengan menggunakan fungsi agregasi lain seperti min, maks, atau rata-rata. Dalam hal ini, pemodel dapat menyembunyikan Unit Price
kolom, dan membuat pengukuran untuk semua fungsi agregasi yang sesuai.
Pendekatan desain ini berfungsi dengan baik untuk laporan yang ditulis dalam layanan Power BI dan untuk Tanya Jawab Umum. Namun, koneksi langsung Power BI Desktop memungkinkan penulis laporan menampilkan bidang tersembunyi di panel Data, yang dapat mengakibatkan menghindari pendekatan desain ini.
Kunci pengganti adalah pengidentifikasi unik yang Anda tambahkan ke tabel untuk mendukung pemodelan skema bintang. Menurut definisi, kunci pengganti tidak ditentukan atau disimpan dalam data sumber. Umumnya, kunci pengganti ditambahkan ke tabel dimensi gudang data relasional untuk menyediakan pengidentifikasi unik untuk setiap baris tabel dimensi.
Hubungan model semantik Power BI didasarkan pada satu kolom unik dalam satu tabel, yang menyebarluaskan filter ke satu kolom dalam tabel yang berbeda. Saat tabel dimensi dalam model semantik Anda tidak menyertakan satu kolom unik, Anda harus menambahkan pengidentifikasi unik untuk menjadi sisi "satu" hubungan. Di Power BI Desktop, Anda bisa mencapai persyaratan ini dengan menambahkan kolom indeks Power Query.
Anda harus menggabungkan kueri ini dengan kueri sisi "banyak" sehingga Anda juga dapat menambahkan kolom indeks ke dalamnya. Saat Anda memuat kueri ini ke model semantik, Anda kemudian dapat membuat hubungan satu-ke-banyak antara tabel model.
Dimensi snowflake adalah kumpulan tabel yang dinormalisasi untuk satu entitas bisnis. Misalnya, Adventure Works mengklasifikasikan produk berdasarkan kategori dan subkategori. Kategori ditetapkan ke subkategori, dan produk pada gilirannya ditugaskan ke subkategori. Di gudang data relasional Adventure Works, dimensi produk dinormalisasi dan disimpan dalam tiga tabel terkait: DimProductCategory
, DimProductSubcategory
, dan DimProduct
.
Jika Anda menggunakan imajinasi, Anda dapat menggambarkan tabel yang dinormalisasi yang diposisikan ke luar dari tabel fakta, membentuk desain snowflake.
Di Power BI Desktop, Anda dapat memilih untuk meniru desain dimensi snowflake (mungkin karena data sumber Anda tidak) atau menggabungkan tabel sumber untuk membentuk tabel model tunggal yang didenormalisasi. Umumnya, manfaat tabel model tunggal melebihi manfaat dari beberapa tabel model. Keputusan yang paling optimal dapat bergantung pada volume data dan persyaratan kegunaan untuk model.
Saat Anda memilih untuk meniru desain dimensi snowflake:
Saat Anda memilih untuk berintegrasi ke dalam satu tabel model, Anda juga dapat menentukan hierarki yang mencakup butir dimensi tertinggi dan terendah. Mungkin, penyimpanan data denormalisasi redundan dapat mengakibatkan peningkatan ukuran penyimpanan model, terutama untuk tabel dimensi besar.
Dimensi yang berubah secara perlahan (atau SCD) adalah dimensi yang mengelola perubahan anggota dimensi dengan tepat dari waktu ke waktu. Ini berlaku ketika nilai entitas bisnis berubah lambat dari waktu ke waktu dengan cara yang tidak diencana. Contoh yang baik dari SCD adalah dimensi pelanggan, karena kolom detail kontaknya seperti alamat email dan nomor telepon jarang berubah. Sebaliknya, beberapa dimensi dianggap berubah dengan cepat ketika atribut dimensi sering berubah, seperti harga pasar saham. Pendekatan desain umum dalam hal ini adalah untuk menyimpan nilai atribut yang berubah dengan cepat dalam ukuran tabel fakta.
Teori desain skema bintang mengacu pada dua jenis SCD umum: Jenis 1 dan Jenis 2. Tabel dimensi dapat berupa Tipe 1 atau Tipe 2, atau mendukung kedua jenis secara bersamaan untuk kolom yang berbeda.
SCD Tipe 1 selalu mencerminkan nilai terbaru, dan bila perubahan dalam data sumber terdeteksi, data tabel dimensi akan ditimpa. Pendekatan desain ini bersifat umum untuk kolom yang menyimpan nilai tambahan, seperti alamat email atau nomor telepon pelanggan. Saat alamat email pelanggan atau nomor telepon berubah, tabel dimensi memperbarui baris pelanggan dengan nilai baru. Seolah-olah pelanggan selalu memiliki informasi kontak ini.
Refresh non-inkremental tabel dimensi model Power BI mencapai hasil SCD Tipe 1. Jenis ini me-refresh data tabel untuk memastikan nilai terbaru dimuat.
SCD Tipe 2 mendukung pembuatan versi anggota dimensi. Jika sistem sumber tidak menyimpan versi, biasanya proses beban gudang data yang mendeteksi perubahan dan mengelola perubahan dalam tabel dimensi dengan tepat. Dalam hal ini, tabel dimensi harus menggunakan kunci pengganti untuk memberikan referensi unik ke versi anggota dimensi. Hal ini juga mencakup kolom yang menentukan validitas rentang tanggal versi (misalnya, StartDate
dan EndDate
) dan mungkin kolom bendera (misalnya, IsCurrent
) untuk dengan mudah memfilter menurut anggota dimensi saat ini.
Misalnya, Adventure Works menetapkan setiap tenaga penjual ke wilayah penjualan. Saat staf penjualan memindahkan wilayah, versi staf penjualan baru harus dibuat untuk memastikan bahwa fakta historis tetap terkait dengan wilayah sebelumnya. Untuk mendukung analisis historis yang akurat tentang penjualan menurut staf penjualan, tabel dimensi harus menyimpan versi staf penjualan dan wilayah yang terkait. Tabel juga harus menyertakan nilai tanggal mulai dan berakhir untuk menentukan validitas waktu. Versi saat ini mungkin menentukan tanggal akhir kosong (atau 31/12/9999), yang menunjukkan bahwa baris adalah versi saat ini. Tabel juga harus memiliki kunci pengganti karena kunci bisnis (dalam hal ini, ID karyawan) tidak akan unik.
Penting untuk dipahami bahwa ketika data sumber tidak menyimpan versi, Anda harus menggunakan sistem perantara (seperti gudang data) untuk mendeteksi dan menyimpan perubahan. Proses pemuatan tabel harus mempertahankan data yang ada dan mendeteksi perubahan. Ketika perubahan terdeteksi, proses pemuatan tabel akan berhenti menggunakan versi saat ini. Hal ini mencatat perubahan ini dengan memperbarui nilai EndDate
dan memasukkan versi baru dengan nilai StartDate
yang dimulai dari nilai EndDate
sebelumnya. Selain itu, fakta terkait harus menggunakan pencarian berbasis waktu untuk mengambil nilai kunci dimensi yang relevan dengan tanggal fakta. Model semantik Power BI menggunakan Power Query, sehingga tidak dapat menghasilkan hasil ini. Namun, ini dapat memuat data dari tabel dimensi SCD Jenis 2 yang telah dimuat sebelumnya.
Tip
Untuk mempelajari cara menerapkan tabel dimensi SCD Tipe 2 di gudang Fabric, lihat Mengelola perubahan historis.
Model semantik Power BI harus mendukung kueri data historis untuk anggota, terlepas dari perubahan, dan untuk versi anggota, yang mewakili status anggota tertentu tepat waktu. Dalam konteks Adventure Works, desain ini memungkinkan Anda untuk mengkueri staf penjualan terlepas dari wilayah penjualan yang ditetapkan, atau untuk versi tenaga penjualan tertentu.
Untuk mencapai persyaratan ini, tabel dimensi model semantik Power BI harus menyertakan kolom untuk memfilter tenaga penjualan, dan kolom yang berbeda untuk memfilter versi tenaga penjualan tertentu. Penting bahwa kolom versi menyediakan deskripsi non-ambigu, seperti David Campbell (12/15/2008-06/26/2019)
atau David Campbell (06/27/2019-Current)
. Penting juga untuk mendidik penulis laporan dan konsumen tentang dasar-dasar SCD Jenis 2, dan cara mencapai desain laporan yang sesuai dengan menerapkan filter yang benar.
Ini adalah praktik desain yang baik untuk menyertakan hierarki yang memungkinkan visual menelusuri tingkat versi.
Dimensi bermain peran adalah dimensi yang dapat memfilter fakta terkait secara berbeda. Misalnya, di Adventure Works tabel dimensi tanggal memiliki tiga hubungan dengan fakta penjualan penjual. Tabel dimensi yang sama dapat digunakan untuk memfilter fakta berdasarkan tanggal pemesanan, tanggal pengiriman, atau tanggal pengiriman.
Di gudang data, pendekatan desain yang diterima adalah menentukan tabel dimensi tanggal tunggal. Pada waktu kueri, "peran" dimensi tanggal ditetapkan oleh kolom fakta yang Anda gunakan untuk menggabungkan tabel. Misalnya, saat Anda menganalisis penjualan berdasarkan tanggal pesanan, gabungan tabel berkaitan dengan kolom tanggal pesanan penjualan penjual.
Dalam model semantik Power BI, desain ini dapat ditiru dengan membuat beberapa hubungan di antara dua tabel. Dalam contoh Adventure Works, tabel penjualan tanggal dan penjual akan memiliki tiga hubungan.
Meskipun desain ini dimungkinkan, hanya ada satu hubungan aktif antara dua tabel model semantik Power BI. Semua hubungan yang tersisa harus diatur ke tidak aktif. Memiliki satu hubungan aktif berarti ada penyebaran filter default dari tanggal ke penjualan penjual. Dalam hal ini, hubungan aktif diatur ke filter paling umum yang digunakan oleh laporan, yang di Adventure Works adalah hubungan tanggal pesanan.
Satu-satunya cara untuk menggunakan hubungan yang tidak aktif adalah dengan menentukan ekspresi DAX yang menggunakan fungsi USERELATIONSHIP. Dalam contoh kami, pengembang model harus membuat langkah-langkah untuk mengaktifkan analisis penjualan penjual berdasarkan tanggal pengiriman dan tanggal pengiriman. Pekerjaan ini bisa membosankan, terutama ketika tabel penjual mendefinisikan banyak langkah. Ini juga membuat panel Data yang berantakan yang memiliki ukuran yang berlebihan. Ada batasan lain juga:
Untuk mengatasi keterbatasan ini, teknik pemodelan Power BI umum adalah membuat tabel dimensi untuk setiap instans pemutaran peran. Anda bisa membuat setiap tabel dimensi sebagai kueri referensi menggunakan Power Query, atau tabel terhitung menggunakan DAX. Model dapat berisi Date
tabel, tabel, Ship Date
dan Delivery Date
tabel, masing-masing dengan hubungan tunggal dan aktif dengan kolom tabel penjualan penjual masing-masing.
Pendekatan desain ini tidak mengharuskan Anda untuk menentukan beberapa langkah untuk peran tanggal yang berbeda, dan memungkinkan pemfilteran simultan dengan peran tanggal yang berbeda. Namun, harga kecil untuk dibayar dengan pendekatan desain ini, adalah bahwa akan ada duplikasi tabel dimensi tanggal yang menghasilkan peningkatan ukuran penyimpanan model. Karena tabel dimensi biasanya menyimpan lebih sedikit baris yang relatif terhadap tabel fakta, itu jarang menjadi perhatian.
Kami sarankan Anda mengikuti praktik desain yang baik saat membuat tabel dimensi model untuk setiap peran:
Year
kolom di semua tabel tanggal (nama kolom unik dalam tabelnya), kolom tersebut tidak menjelaskan sendiri dengan judul visual default. Pertimbangkan untuk mengganti nama kolom di setiap tabel peran dimensi sehingga Ship Date
tabel memiliki kolom tahun bernama Ship Year
, dan sebagainya.Date
, yang digunakan untuk memfilter banyak tabel fakta. Jika tabel ini memiliki, misalnya, hubungan aktif dengan kolom tanggal pesanan penjualan penjual, pertimbangkan untuk memberikan deskripsi tabel seperti Filters reseller sales by order date
.Untuk informasi selengkapnya, lihat Panduan hubungan aktif vs tidak aktif.
Dimensi sampah berguna ketika ada banyak dimensi, terutama terdiri dari beberapa atribut (mungkin satu), dan ketika atribut ini memiliki beberapa nilai. Kandidat yang baik termasuk kolom status pesanan, atau kolom demografi pelanggan seperti jenis kelamin atau kelompok usia.
Tujuan desain dimensi sampah adalah untuk mengonsolidasikan banyak dimensi kecil ke dalam satu dimensi untuk mengurangi ukuran penyimpanan model dan juga mengurangi kekacauan panel Data dengan memunculkan lebih sedikit tabel model.
Tabel dimensi sampah biasanya merupakan produk Kartesius dari semua anggota atribut dimensi, dengan kolom kunci pengganti untuk mengidentifikasi setiap baris secara unik. Anda dapat membuat dimensi di gudang data, atau dengan menggunakan Power Query untuk membuat kueri yang melakukan gabungan kueri luar penuh, lalu menambahkan kunci pengganti (kolom indeks).
Anda memuat kueri ini ke model sebagai tabel dimensi. Anda juga perlu menggabungkan kueri ini dengan kueri fakta sehingga kolom indeks dimuat ke model untuk mendukung pembuatan hubungan model "satu-ke-banyak".
Dimensi degenerasi mengacu pada atribut tabel fakta yang diperlukan untuk pemfilteran. Di Adventure Works, nomor pesanan penjualan penjual adalah contoh yang baik. Dalam hal ini, tidak masuk akal untuk membuat tabel independen yang hanya terdiri dari kolom yang satu ini karena akan meningkatkan ukuran penyimpanan model dan mengakibatkan kekacauan panel Data .
Dalam model semantik Power BI, mungkin sesuai untuk menambahkan kolom nomor pesanan penjualan ke tabel fakta untuk memungkinkan pemfilteran atau pengelompokan menurut nomor pesanan penjualan. Ini adalah pengecualian untuk aturan yang sebelumnya diperkenalkan bahwa Anda tidak boleh mencampur jenis tabel (umumnya, tabel model harus berupa dimensi atau fakta).
Namun, jika tabel penjualan penjual Adventure Works memiliki kolom nomor pesanan dan nomor baris pesanan, dan diperlukan untuk pemfilteran, membuat tabel dimensi yang merosok akan menjadi desain yang baik. Untuk informasi selengkapnya, lihat Panduan hubungan satu-ke-satu (Dimensi degenerasi).
Tabel fakta tanpa fakta tidak menyertakan kolom pengukuran apa pun. Tabel ini hanya berisi kunci dimensi.
Tabel fakta tanpa fakta dapat menyimpan pengamatan yang ditentukan oleh kunci dimensi. Misalnya, pada tanggal dan waktu tertentu, pelanggan tertentu masuk ke situs web Anda. Anda dapat menentukan ukuran untuk menghitung baris tabel fakta tanpa fakta untuk melakukan analisis kapan dan berapa banyak pelanggan yang masuk.
Penggunaan tabel fakta yang lebih menarik adalah menyimpan hubungan antar dimensi, dan ini adalah pendekatan desain model semantik Power BI yang kami sarankan untuk menentukan hubungan dimensi banyak ke banyak. Dalam desain hubungan dimensi banyak ke banyak, tabel fakta tanpa fakta disebut sebagai tabel bridging.
Misalnya, pertimbangkan bahwa tenaga penjualan dapat ditetapkan ke satu atau beberapa wilayah penjualan. Tabel bridging akan dirancang sebagai tabel fakta tanpa fakta yang terdiri dari dua kolom: kunci tenaga penjualan dan kunci wilayah. Nilai duplikat dapat disimpan di kedua kolom.
Pendekatan desain banyak ke banyak ini didokumentasikan dengan baik, dan dapat dicapai tanpa tabel bridging. Namun, pendekatan bridging table dianggap sebagai praktik terbaik saat berkaitan dengan dua dimensi. Untuk informasi selengkapnya, lihat Panduan hubungan banyak-ke-banyak (Menghubungkan dua tabel jenis dimensi).
Untuk informasi selengkapnya tentang desain skema bintang atau desain model semantik Power BI, lihat artikel berikut ini:
Acara
Bergabunglah dengan kami di FabCon Vegas
31 Mar, 23 - 2 Apr, 23
Acara utama yang dipimpin komunitas Microsoft Fabric, Power BI, SQL, dan AI. 31 Maret hingga 2 April 2025.
Daftar hari iniPelatihan
Modul
Mendesain model semantik di Power BI - Training
Proses pembuatan model semantik yang rumit di Power BI sangat mudah. Jika data masuk dari lebih dari satu sistem transaksional, tanpa disadari Anda dapat memiliki lusinan tabel yang harus ditangani. Membangun model semantik yang hebat adalah tentang menyederhanakan kekacauan. Skema star adalah salah satu cara untuk menyederhanakan model semantik, dan Anda belajar tentang terminologi dan implementasinya dalam modul ini. Anda juga akan mempelajari tentang mengapa memilih granuralitas data yang benar penting u
Sertifikasi
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Menunjukkan metode dan praktik terbaik yang selaras dengan persyaratan bisnis dan teknis untuk pemodelan, visualisasi, dan analisis data dengan Microsoft Power BI.