Memodelkan data di gudang

  • 7 menit

Tanpa pemodelan data, setiap consumer harus mencari tahu tabel mana yang terkait satu sama lain, menulis logika agregasi mereka sendiri, dan menebak arti kolom. Pemodelan data memecahkan masalah ini dengan menyematkan struktur, logika bisnis, dan dokumentasi langsung ke gudang. Di gudang Microsoft Fabric, Anda menyiapkan data untuk kejernihan, menentukan hubungan antara tabel, menstandarkan akses melalui pandangan dan ukuran, dan menerbitkan model semantik untuk laporan. Pilihan pemodelan ini memengaruhi setiap pengalaman hilir, termasuk kueri T-SQL, laporan Power BI, dan analitik bahasa alami berbasis AI.

Menyiapkan data untuk digunakan

Sebelum menentukan hubungan atau menambahkan perhitungan, Anda perlu membersihkan apa yang dilihat konsumen. Tabel gudang data mentah sering berisi tabel penahapan, kolom kunci pengganti, dan penanda internal yang dimaksudkan untuk proses ETL, bukan untuk analisis. Objek-objek ini membuat kebisingan saat konsumen menelusuri data. Menyiapkan gudang untuk konsumsi berarti memunculkan hanya apa yang relevan dan membuatnya dapat dimengerti.

Dalam tampilan model, Anda dapat mengambil beberapa langkah untuk meningkatkan pengalaman consumer:

  • Sembunyikan objek internal seperti tabel penahapan, kolom kunci pengganti, dan artefak ETL yang membuat daftar bidang lebih berantakan.
  • Ganti nama kolom untuk menggunakan nama yang ramah bisnis di mana nama kolom gudang bersifat teknis atau disingkat. Misalnya, ganti nama CustRgn menjadi Customer Region.
  • Tambahkan deskripsi ke tabel dan kolom sehingga konsumen memahami apa yang diwakili data tanpa mengacu pada dokumentasi eksternal.

Langkah-langkah ini penting di luar hanya keteraturan. Copilot dalam agen data Power BI dan Fabric IQ mengandalkan nama tabel, nama kolom, dan deskripsi untuk menafsirkan pertanyaan bahasa alami dan menghasilkan SQL atau DAX yang akurat. Kolom bernama Customer Region dengan deskripsi seperti "Wilayah geografis alamat utama pelanggan" menghasilkan hasil bahasa alami yang lebih baik daripada CustRgn tanpa deskripsi.

Dengan tabel yang bersih dan dinamai dengan baik, Anda siap untuk menentukan bagaimana tabel tersebut terhubung satu sama lain.

Memahami hubungan antar tabel

Hubungan adalah koneksi logis antara dua tabel yang memungkinkan pemfilteran, pengelompokan, dan agregasi di seluruh tabel tersebut. Dalam skema bintang, hubungan menghubungkan tabel fakta ke tabel dimensi melalui kolom kunci bersama.

Misalnya, kolom CustomerKey yang ada di FactSales dan DimCustomer menetapkan tautan yang memungkinkan analisis penjualan berdasarkan atribut pelanggan seperti wilayah, segmen, atau jenis akun.

Setiap hubungan memiliki dua properti penting.

  • Kardinalitas menjelaskan bagaimana baris dalam dua tabel berkaitan. Dalam skema bintang, hubungan fakta-ke-dimensi biasanya banyak-ke-satu, yang berarti banyak baris-baris fakta dipetakan ke satu baris dimensi.
  • Arah filter silang menentukan cara filter disebarluaskan di antara tabel. Arah tunggal, di mana dimensi memfilter tabel fakta, adalah pengaturan standar untuk sebagian besar desain skema bintang karena menjaga agar perilaku filter tetap dapat diprediksi dan berkinerja baik.

Tanpa hubungan yang ditentukan, setiap consumer yang ingin menggabungkan data di seluruh tabel perlu menulis logika JOIN eksplisit. Hubungan menghapus pengulangan itu dengan mengodekan koneksi sekali. Saat Anda membuat model semantik dari gudang, hubungan ini menginformasikan bagaimana agen data Power BI, Copilot, dan Fabric IQ menginterpretasikan data. Agen data, misalnya, menggunakan hubungan untuk menghasilkan gabungan yang akurat saat menerjemahkan pertanyaan bahasa alami ke dalam SQL.

Catatan

Sebagian besar gudang data menggunakan pemodelan dimensi. Hubungan dapat dibuat untuk membentuk skema bintang, yang merupakan model ideal untuk analitik. Untuk informasi selengkapnya, lihat model dimensi Design dalam modul Microsoft Fabric.

Standarisasi akses data dengan tampilan dan ukuran

Sekarang setelah tabel Anda bersih dan terhubung, langkah selanjutnya adalah memberi konsumen cara yang andal dan konsisten untuk mengkueri dan menghitung terhadap data tersebut. Tanpa standardisasi, setiap tim menulis logika gabungannya sendiri, menerapkan filternya sendiri, dan menentukan rumusnya sendiri, yang mengarah pada hasil yang bertentangan.

Tampilan memberikan konsistensi ini untuk konsumen T-SQL. Tampilan merangkum logika penggabungan, filter, dan pilihan kolom ke dalam kueri yang dapat digunakan kembali dan dapat direferensikan oleh konsumen seperti tabel. Misalnya, tampilan yang menggabungkan tabel fakta dan dimensi, memfilter pesanan yang sudah selesai, dan menampilkan hanya kolom yang dibutuhkan analis memberi setiap konsumen T-SQL titik awal yang dapat diandalkan. Tampilan juga berfungsi sebagai sumber data yang stabil untuk laporan. Daripada membuat laporan secara langsung terhadap tabel dasar yang mungkin berubah, Anda dapat mengarahkan laporan pada tampilan yang menyajikan bentuk yang konsisten.

Pengukuran memberikan konsistensi yang sama untuk perhitungan DAX. Ukuran adalah ekspresi DAX yang dapat digunakan kembali yang menentukan perhitungan seperti total, rata-rata, rasio, atau hitungan. Anda membuat pengukuran langsung dalam tampilan model gudang dengan memilih tabel dan menambahkan ukuran baru. Misalnya, ukuran Total Sales yang menjumlahkan kolom SalesAmount memastikan setiap consumer menggunakan perhitungan yang sama.

Karena definisi pengukuran hidup dengan data, definisi tersebut menjadi satu-satunya sumber kebenaran untuk metrik tersebut. Ketika bisnis mengubah cara menghitung pendapatan, Anda memperbarui pengukuran di satu tempat daripada melacak setiap laporan yang berisi rumusnya sendiri.

Bersama-sama, tampilan dan ukuran mencakup kedua sisi konsumsi: tampilan menstandarkan bagaimana konsumen T-SQL mengakses dan mengkueri data, sementara ukuran menstandarkan bagaimana perhitungan bisnis ditampilkan di laporan dan dasbor.

Petunjuk

Rumus DAX dan desain pengukuran tingkat lanjut dibahas secara mendalam dalam modul selanjutnya. Untuk tampilan dan prosedur tersimpan, lihat unit sebelumnya tentang mengkueri dan mengubah data.

Membuat model semantik untuk pelaporan Power BI

Dengan tabel yang disiapkan, hubungan yang ditentukan, dan tampilan dan ukuran standar, gudang siap untuk pelaporan hilir. Tim yang mengkueri gudang secara langsung dengan menggunakan T-SQL atau terhubung melalui alat pihak ketiga dapat bekerja dengan model gudang as-is. Namun, saat Anda ingin membangun laporan dan dasbor Power BI interaktif, membuat model semantik adalah langkah berikutnya.

Model semantik yang dibuat dari Fabric warehouse menggunakan mode Direct Lake. Tidak seperti mode impor tradisional, yang menyalin data ke dalam memori Power BI, Direct Lake membaca data langsung dari file OneLake Parquet. Ini berarti laporan mencerminkan data gudang terbaru tanpa memerlukan refresh terjadwal. Ini juga berarti Anda menghindari kelebihan penyimpanan dan pemrosesan dalam mempertahankan salinan data yang terpisah.

Cuplikan layar laporan Power BI.

Petunjuk

Desain model semantik dan pola skalabilitas dicakup dalam kedalaman yang lebih besar dalam Desain model semantik yang dapat diskalakan. Unit ini berfokus pada pemodelan data di gudang itu sendiri.