Bagikan melalui

Pemodelan dimensi di Microsoft Fabric Warehouse: Memasukkan tabel

Berlaku untuk:✅ Titik akhir analitik SQL dan Gudang di Microsoft Fabric

Catatan

Artikel ini membentuk bagian dari seri artikel pemodelan dimensi. Seri ini berfokus pada panduan dan desain praktik terbaik yang terkait dengan pemodelan dimensi di Microsoft Fabric Warehouse.

Artikel ini memberi Anda panduan dan praktik terbaik untuk memuat tabel dimensi dan fakta dalam model dimensi. Ini memberikan panduan praktis untuk Gudang di Microsoft Fabric, yang merupakan pengalaman yang mendukung banyak kemampuan T-SQL, seperti membuat tabel dan mengelola data dalam tabel. Jadi, Anda memiliki kontrol penuh untuk membuat tabel model dimensi Anda dan memasukkan data ke dalamnya.

Catatan

Dalam artikel ini, istilah gudang data mengacu pada gudang data perusahaan, yang memberikan integrasi komprehensif data penting di seluruh organisasi. Sebaliknya, istilah gudang mandiri merujuk pada Fabric Warehouse, yang merupakan penawaran database relasional software as a service (SaaS) yang dapat Anda gunakan untuk mengimplementasikan gudang data. Untuk kejelasan, dalam artikel ini yang terakhir disebutkan sebagai Fabric Warehouse.

Tip

Jika Anda tidak berpengalaman dengan pemodelan dimensi, pertimbangkan serangkaian artikel ini sebagai langkah pertama Anda. Ini tidak dimaksudkan untuk memberikan diskusi lengkap tentang desain pemodelan dimensi. 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.

Memuat model berdimensi

Memuat model dimensi melibatkan proses Ekstrak, Transformasi, dan Muat (ETL) secara berkala. Proses ETL mengorkestrasikan pelaksanaan proses lain, yang umumnya berkaitan dengan penahapan data sumber, menyinkronkan data dimensi, menyisipkan baris ke dalam tabel fakta, dan merekam kesalahan serta data audit.

Untuk solusi Fabric Warehouse, Anda dapat menggunakan Data Factory untuk mengembangkan dan menjalankan proses ETL Anda. Proses ini dapat menahapkan, mengubah, dan memuat data sumber ke dalam tabel model dimensi Anda.

Secara khusus, Anda dapat:

  • Gunakan alur data untuk membangun alur kerja untuk mengatur proses ETL. Alur data dapat menjalankan skrip SQL, prosedur tersimpan, dan banyak lagi.
  • Gunakan aliran data untuk mengembangkan logika kode rendah untuk menyerap data dari ratusan sumber data. Aliran data mendukung menggabungkan data dari beberapa sumber, mengubah data, lalu memuatnya ke tujuan, seperti tabel model dimensi. Aliran data dibangun dengan menggunakan pengalaman Power Query yang sudah tidak asing lagi yang tersedia saat ini di banyak produk Microsoft, termasuk Microsoft Excel dan Power BI Desktop.

Catatan

Pengembangan ETL bisa menjadi kompleks, dan pengembangan bisa menjadi tantangan. Diperkirakan bahwa 60-80 persen dari upaya pengembangan gudang data didedikasikan untuk proses ETL.

Orkestrasi

Alur kerja umum proses ETL adalah untuk:

  1. Secara opsional, muat tabel penahapan.
  2. Tabel dimensi proses.
  3. Memproses tabel fakta.
  4. Secara opsional, lakukan tugas pasca-pemrosesan, seperti memicu refresh konten Fabric dependen (seperti model semantik).

Diagram memperlihatkan empat langkah proses ETL seperti yang dijelaskan dalam paragraf sebelumnya.

Tabel dimensi harus diproses terlebih dahulu untuk memastikan bahwa mereka menyimpan semua anggota dimensi, termasuk yang ditambahkan ke sistem sumber sejak proses ETL terakhir. Ketika ada dependensi antar dimensi, seperti halnya dengan dimensi outrigger, tabel dimensi harus diproses dalam urutan dependensi. Misalnya, dimensi geografi yang digunakan oleh dimensi pelanggan dan dimensi vendor harus diproses sebelum dua dimensi lainnya.

Tabel fakta dapat diproses setelah semua tabel dimensi diproses.

Saat semua tabel model dimensi diproses, Anda dapat memicu refresh model semantik dependen. Ada baiknya juga untuk mengirim pemberitahuan kepada staf yang relevan untuk memberi tahu mereka tentang hasil proses ETL.

Data tahapan

Data staging sumber dapat mendukung persyaratan pemuatan dan transformasi data. Ini melibatkan ekstraksi data sistem sumber dan memuatnya ke dalam tabel penahapan, yang Anda buat untuk mendukung proses ETL. Kami menyarankan agar Anda menyimpan sementara data sumber karena dapat:

  • Meminimalkan dampak pada sistem operasional.
  • Digunakan untuk membantu, dan mengoptimalkan, pemrosesan ETL.
  • Berikan kemampuan untuk memulai ulang proses ETL, tanpa perlu memuat ulang data dari sistem sumber.

Data dalam tabel penahapan tidak boleh diakses oleh pengguna bisnis. Ini hanya relevan dengan proses ETL.

Catatan

Saat data Anda disimpan di Fabric Lakehouse, mungkin tidak perlu mentahapkan datanya di gudang data. Jika menerapkan arsitektur medali, Anda dapat sumber datanya dari lapisan perunggu, perak, atau emas.

Kami menyarankan agar Anda membuat skema di gudang, mungkin bernama staging. Tabel penahapan harus menyerupai tabel sumber sedekat mungkin dalam hal nama kolom dan jenis data. Konten setiap tabel harus dihapus pada awal proses ETL. TRUNCATE TABLE didukung untuk keperluan ini.

Anda juga dapat mempertimbangkan alternatif virtualisasi data sebagai bagian dari strategi penahapan Anda. Anda dapat menggunakan:

Mentransformasikan data

Struktur data sumber Anda mungkin tidak menyerupai struktur tujuan tabel model dimensi Anda. Jadi, proses ETL Anda perlu membentuk ulang data sumber agar selaras dengan struktur tabel model dimensi.

Selain itu, gudang data harus memberikan data yang dibersihkan dan sesuai, sehingga data sumber mungkin perlu diubah untuk memastikan kualitas dan konsistensi.

Catatan

Konsep sampah masuk, sampah keluar tentu berlaku untuk pergudangan data—oleh karena itu, hindari memuat data sampah (kualitas rendah) ke dalam tabel model dimensi Anda.

Berikut adalah beberapa transformasi yang dapat dilakukan proses ETL Anda.

  • Gabungkan data: Data dari sumber yang berbeda dapat diintegrasikan (digabungkan) berdasarkan kunci yang cocok. Misalnya, data produk disimpan di berbagai sistem (seperti manufaktur dan pemasaran), namun semuanya menggunakan unit penyimpanan stok (SKU) umum. Data juga dapat ditambahkan saat berbagi struktur umum. Misalnya, data penjualan disimpan dalam beberapa sistem. Penyatuan penjualan dari setiap sistem dapat menghasilkan superset dari semua data penjualan.
  • Mengonversi jenis data: Jenis data dapat dikonversi ke yang ditentukan dalam tabel model dimensi.
  • Perhitungan: Perhitungan dapat dilakukan untuk menghasilkan nilai untuk tabel model dimensi. Misalnya, untuk tabel dimensi karyawan, Anda dapat menggabungkan nama depan dan belakang untuk menghasilkan nama lengkap. Sebagai contoh lain, untuk tabel fakta penjualan Anda, Anda dapat menghitung pendapatan penjualan kotor, yang merupakan produk dari harga unit dan kuantitas.
  • Mendeteksi dan mengelola perubahan historis: Perubahan dapat dideteksi dan disimpan dengan tepat dalam tabel dimensi. Untuk informasi selengkapnya, lihat Mengelola perubahan historis nanti di artikel ini.
  • Data agregat: Agregasi dapat digunakan untuk mengurangi dimensi tabel fakta dan/atau untuk meningkatkan granularitas fakta. Misalnya, tabel fakta penjualan tidak perlu menyimpan nomor pesanan penjualan. Oleh karena itu, hasil agregat yang dikelompokkan menurut semua kunci dimensi dapat digunakan untuk menyimpan data tabel fakta.

Memuat data

Anda dapat memuat tabel di Fabric Warehouse dengan menggunakan opsi penyerapan data berikut.

  • COPY INTO (T-SQL): Opsi ini berguna saat data sumber terdiri dari file Parquet atau CSV yang disimpan di akun penyimpanan Azure eksternal, seperti ADLS Gen2 atau Azure Blob Storage.
  • Alur data: Selain mengatur proses ETL, alur data dapat menyertakan aktivitas yang menjalankan pernyataan T-SQL, melakukan pencarian, atau menyalin data dari sumber data ke tujuan.
  • Aliran data: Sebagai alternatif untuk alur data, aliran data memberikan pengalaman bebas kode untuk mengubah dan membersihkan data.
  • Pengolahan lintas gudang: Ketika data disimpan di ruang kerja yang sama, pengolahan lintas gudang memungkinkan menggabungkan tabel-tabel gudang atau lakehouse yang berbeda. Ini mendukung perintah T-SQL seperti INSERT…SELECT, , SELECT INTOdan CREATE TABLE AS SELECT (CTAS). Perintah ini sangat berguna ketika Anda ingin mengubah dan memuat data dari tabel penahapan dalam ruang kerja yang sama. Operasi ini juga berbasis set, yang kemungkinan menjadi cara paling efisien dan tercepat untuk memuat tabel model dimensi.

Kiat

Untuk penjelasan lengkap tentang opsi penyerapan data ini termasuk praktik terbaik, lihat Menyerap data ke dalam Gudang.

Pencatatan

Proses ETL biasanya memerlukan pemantauan dan pemeliharaan khusus. Untuk alasan ini, kami sarankan Anda mencatat hasil proses ETL ke tabel model non-dimensi di gudang Anda. Anda harus menghasilkan ID unik untuk setiap proses ETL dan menggunakannya untuk mencatat detail tentang setiap operasi.

Pertimbangkan pengelogan:

  • Proses ETL:
    • ID unik untuk setiap eksekusi ETL
    • Waktu mulai dan waktu akhir
    • Status (berhasil atau gagal)
    • Kesalahan apa pun yang ditemui
  • Setiap tabel model tahap penyusunan dan dimensi:
    • Waktu mulai dan waktu akhir
    • Status (berhasil atau gagal)
    • Baris disisipkan, diperbarui, dan dihapus
    • Jumlah baris tabel akhir
    • Kesalahan apa pun yang ditemui
  • Operasi lainnya:
    • Waktu mulai dan waktu akhir operasi refresh model semantik

Tips

Anda dapat membuat model semantik yang didedikasikan untuk memantau dan menganalisis proses ETL Anda. Durasi proses dapat membantu Anda mengidentifikasi hambatan yang mungkin mendapat manfaat dari peninjauan dan pengoptimalan. Jumlah baris dapat memungkinkan Anda memahami ukuran beban bertambah bertahap setiap kali ETL berjalan, dan juga membantu memprediksi ukuran gudang data di masa mendatang (dan kapan harus meningkatkan kapasitas Fabric, jika sesuai).

Tabel dimensi proses

Memproses tabel dimensi melibatkan sinkronisasi data gudang data dengan sistem sumber. Data sumber pertama kali diubah dan disiapkan untuk dimuat ke dalam tabel dimensinya. Data ini kemudian dicocokkan dengan data tabel dimensi yang ada dengan menggabungkan menggunakan kunci bisnis. Kemudian dimungkinkan untuk menentukan apakah data sumber mewakili data baru atau yang dimodifikasi. Saat tabel dimensi menerapkan dimensi yang berubah secara perlahan (SCD) tipe 1, perubahan dilakukan dengan memperbarui baris tabel dimensi yang ada. Saat tabel menerapkan perubahan SCD tipe 2, versi yang ada kedaluwarsa dan versi baru disisipkan.

Diagram berikut menggambarkan logika yang digunakan untuk memproses tabel dimensi.

Diagram memperlihatkan alur yang menjelaskan bagaimana baris sumber baru dan yang diubah dimuat ke tabel dimensi, seperti yang dijelaskan dalam paragraf berikut.

Pertimbangkan proses dari tabel dimensi Product.

  • Saat produk baru ditambahkan ke sistem asal, baris dimasukkan ke dalam tabel dimensi Product.
  • Saat produk dimodifikasi, baris yang ada dalam tabel dimensi diperbarui atau disisipkan.
    • Saat SCD tipe 1 berlaku, pembaruan dilakukan ke baris yang ada.
    • Saat SCD tipe 2 berlaku, pembaruan dilakukan untuk mengakhiri masa berlaku expire versi baris saat ini, dan baris baru yang mewakili versi yang terbaru disisipkan.
    • Saat SCD tipe 3 berlaku, proses yang mirip dengan SCD tipe 1 terjadi, memperbarui baris yang ada tanpa menyisipkan baris baru.

Kunci pengganti

Sebaiknya setiap tabel dimensi memiliki kunci pengganti, yang harus menggunakan jenis data bilangan bulat sekecil mungkin. Di lingkungan berbasis SQL Server yang biasanya dilakukan dengan membuat kolom identitas, namun fitur ini tidak didukung di Fabric Warehouse. Sebagai gantinya, Anda harus menggunakan teknik solusi alternatif yang menghasilkan pengidentifikasi unik.

Penting

Saat tabel dimensi menyertakan kunci pengganti yang dihasilkan secara otomatis, Anda tidak boleh melakukan pemotongan dan pemuatan ulang penuh. Itu karena hal tersebut dapat membuat tidak valid data yang dimuat ke dalam tabel fakta yang menggunakan dimensi. Selain itu, jika tabel dimensi mendukung perubahan SCD jenis 2 , mungkin tidak mungkin untuk meregenerasi versi historis.

Mengelola perubahan historis

Saat tabel dimensi harus menyimpan perubahan historis, Anda harus menerapkan dimensi (SCD) yang berubah perlahan.

Catatan

Jika baris tabel dimensi adalah anggota yang disimpulkan (disisipkan oleh proses pemuatan fakta), Anda harus memperlakukan perubahan apa pun sebagai detail dimensi yang terlambat tiba alih-alih perubahan SCD. Dalam hal ini, setiap atribut yang diubah harus diperbarui dan kolom bendera anggota yang disimpulkan diatur ke FALSE.

Ada kemungkinan bahwa dimensi bisa mendukung perubahan SCD tipe 1 dan/atau tipe 2.

SCD tipe 1

Saat perubahan SCD tipe 1 terdeteksi, gunakan logika berikut.

  1. Perbarui atribut yang diubah.
  2. Jika tabel menyertakan tanggal terakhir diubah dan terakhir diubah oleh kolom, atur tanggal dan proses saat ini yang membuat modifikasi.

SCD tipe 2

Saat perubahan SCD tipe 2 terdeteksi, gunakan logika berikut.

  1. Kedaluwarsa versi saat ini dengan mengatur kolom validitas tanggal berakhir ke tanggal pemrosesan ETL (atau tanda waktu yang sesuai dalam sistem sumber) dan penanda saat ini ke FALSE.
  2. Jika tabel menyertakan tanggal terakhir diubah dan terakhir diubah oleh kolom, atur tanggal dan proses saat ini yang membuat modifikasi.
  3. Sisipkan anggota baru yang memiliki kolom validitas tanggal mulai yang diatur ke nilai kolom validitas tanggal akhir (digunakan untuk memperbarui versi sebelumnya) dan memiliki bendera versi saat ini yang diatur ke TRUE.
  4. Apabila tabel mencakup kolom tanggal dibuat dan dibuat oleh, tetapkan tanggal saat ini dan proses yang membuat penyisipan.

SCD tipe 3

Saat perubahan SCD tipe 3 terdeteksi, perbarui atribut dengan menggunakan logika serupa untuk memproses SCD tipe 1.

Penghapusan elemen dimensi

Berhati-hatilah jika data sumber menunjukkan bahwa anggota dimensi dihapus (baik karena mereka tidak diambil dari sistem sumber, atau mereka telah ditandai sebagai dihapus). Anda tidak boleh menyinkronkan penghapusan dengan tabel dimensi, kecuali anggota dimensi dibuat dalam kesalahan dan tidak ada rekaman fakta yang terkait dengannya.

Cara yang sesuai untuk menangani penghapusan sumber adalah dengan merekamnya sebagai penghapusan sementara. Penghapusan lembut menandai anggota dimensi sebagai tidak lagi aktif atau valid. Untuk mendukung kasus ini, tabel dimensi Anda harus menyertakan atribut Boolean dengan jenis data bit , seperti IsDeleted. Perbarui kolom ini untuk setiap anggota dimensi yang dihapus menjadi TRUE (1). Versi terbaru dan saat ini dari anggota dimensi mungkin juga ditandai dengan nilai Boolean (bit) di kolom IsCurrent atau IsActive. Semua kueri pelaporan dan model semantik Power BI harus memfilter rekaman yang merupakan penghapusan lunak.

Dimensi tanggal

Dimensi kalender dan waktu adalah kasus khusus karena biasanya tidak memiliki data sumber. Sebaliknya, mereka dihasilkan dengan menggunakan logika tetap.

Anda harus memuat tabel dimensi tanggal di awal setiap tahun baru untuk memperpanjang barisnya ke jumlah tahun ke depan tertentu. Mungkin ada data bisnis lain, misalnya data tahun fiskal, hari libur, nomor minggu untuk diperbarui secara teratur.

Ketika tabel dimensi tanggal menyertakan atribut offset relatif, proses ETL harus dijalankan setiap hari untuk memperbarui nilai atribut offset berdasarkan tanggal saat ini (hari ini).

Kami menyarankan agar logika untuk memperpanjang atau memperbarui tabel dimensi tanggal ditulis dalam T-SQL dan dienkapsulasi dalam prosedur tersimpan.

Memproses tabel fakta

Memproses tabel fakta melibatkan sinkronisasi data gudang data dengan fakta sistem sumber. Data sumber pertama kali diubah dan disiapkan untuk dimuat ke dalam tabel faktanya. Kemudian, untuk setiap kunci dimensi, pencarian menentukan nilai kunci pengganti untuk disimpan di baris fakta. Saat dimensi mendukung SCD tipe 2, kunci pengganti untuk versi saat ini dari anggota dimensi harus diperoleh.

Catatan

Biasanya kunci pengganti dapat dihitung untuk dimensi tanggal dan dimensi waktu karena mereka harus menggunakan format YYYYMMDD atau HHMM. Untuk informasi selengkapnya, lihat Kalender dan waktu.

Jika pencarian kunci dimensi gagal, itu dapat menunjukkan masalah integritas dengan sistem sumber. Dalam hal ini, baris fakta masih harus dimasukkan ke dalam tabel fakta. Kunci dimensi yang valid masih harus disimpan. Salah satu pendekatannya adalah menyimpan anggota dimensi yang spesial (seperti Tidak Diketahui). Pendekatan ini memerlukan pembaruan selanjutnya untuk menetapkan nilai kunci dimensi yang benar dengan benar, jika diketahui.

Penting

Karena Fabric Warehouse tidak memberlakukan kunci asing, sangat penting bahwa proses ETL memeriksa integritas ketika memuat data ke dalam tabel fakta.

Pendekatan lain, relevan ketika ada keyakinan bahwa kunci alami valid, adalah menyisipkan anggota dimensi baru dan kemudian menyimpan nilai kunci penggantinya. Untuk informasi selengkapnya, lihat Anggota dimensi yang disimpulkan nanti di bagian ini.

Diagram berikut menggambarkan logika yang digunakan untuk memproses tabel fakta.

Diagram memperlihatkan alur yang menjelaskan bagaimana baris sumber baru dimuat ke tabel fakta, seperti yang dijelaskan dalam paragraf sebelumnya.

Jika memungkinkan, tabel fakta harus dimuat secara bertahap, yang berarti bahwa fakta baru terdeteksi dan dimasukkan. Strategi beban bertahap lebih dapat diskalakan, dan mengurangi beban kerja untuk sistem sumber dan sistem tujuan.

Penting

Terutama untuk tabel fakta besar, itu harus menjadi upaya terakhir untuk memotong dan memuat ulang tabel fakta. Pendekatan itu mahal dalam hal waktu proses, sumber daya komputasi, dan kemungkinan gangguan pada sistem sumber. Ini juga melibatkan kompleksitas ketika dimensi tabel fakta menerapkan SCD jenis 2. Itu karena pencarian kunci dimensi perlu dilakukan dalam periode validitas versi anggota dimensi.

Mudah-mudahan, Anda dapat secara efisien mendeteksi fakta baru dengan mengandalkan pengidentifikasi sistem sumber atau tanda waktu. Misalnya, ketika sistem sumber dengan andal mencatat pesanan penjualan yang berurutan, Anda dapat menyimpan nomor pesanan penjualan terbaru yang diambil (dikenal sebagai penanda batas tertinggi). Proses berikutnya dapat menggunakan nomor pesanan penjualan tersebut untuk mengambil pesanan penjualan yang baru dibuat, dan sekali lagi, menyimpan nomor pesanan penjualan terbaru yang diambil untuk digunakan oleh proses berikutnya. Ada kemungkinan juga bahwa kolom tanggal pembuatan dapat digunakan untuk mendeteksi pesanan baru dengan andal.

Jika Anda tidak dapat mengandalkan data sistem sumber untuk mendeteksi fakta baru secara efisien, Anda mungkin dapat mengandalkan kemampuan sistem sumber untuk melakukan beban inkremental. Misalnya, SQL Server dan Azure SQL Managed Instance memiliki fitur yang disebut change data capture (CDC), yang dapat melacak perubahan pada setiap baris dalam tabel. Selain itu, SQL Server, Azure SQL Managed Instance, dan Azure SQL Database memiliki fitur yang disebut pelacakan perubahan, yang dapat mengidentifikasi baris yang telah berubah. Saat diaktifkan, ini dapat membantu Anda mendeteksi data baru atau yang diubah secara efisien dalam tabel database apa pun. Anda mungkin juga dapat menambahkan pemicu ke tabel relasional yang menyimpan kunci rekaman tabel yang disisipkan, diperbarui, atau dihapus.

Terakhir, Anda mungkin dapat menghubungkan data sumber dengan tabel fakta dengan menggunakan atribut. Misalnya, nomor pesanan penjualan dan nomor baris pesanan penjualan. Namun, untuk tabel fakta besar, itu bisa menjadi operasi yang sangat mahal untuk mendeteksi fakta baru, diubah, atau dihapus. Ini juga bisa bermasalah ketika sistem sumber mengarsipkan data operasional.

Anggota dimensi yang disimpulkan

Saat proses beban fakta menyisipkan anggota dimensi baru, proses ini dikenal sebagai anggota yang disimpulkan. Misalnya, ketika tamu hotel check-in, mereka diminta untuk bergabung dengan jaringan hotel sebagai anggota loyalitas. Nomor keanggotaan segera dikeluarkan, tetapi detail tamu mungkin tidak mengikuti sampai dokumen dikirimkan oleh tamu (jika pernah).

Yang diketahui tentang anggota dimensi hanyalah kunci alamiahnya. Proses pemuatan fakta harus membuat anggota dimensi baru dengan menggunakan nilai atribut Tidak Diketahui. Yang penting, itu harus mengatur atribut audit ke IsInferredMemberTRUE. Dengan begitu, ketika detail yang tiba terlambat telah didapatkan, proses pemuatan dimensi dapat melakukan pembaruan yang diperlukan pada baris dimensi. Untuk informasi selengkapnya, lihat Mengelola perubahan historis dalam artikel ini.

Pembaruan atau penghapusan fakta

Anda mungkin diharuskan memperbarui atau menghapus data fakta. Misalnya, ketika pesanan penjualan dibatalkan, atau jumlah pesanan diubah. Seperti yang dijelaskan sebelumnya untuk memuat tabel fakta, Anda perlu mendeteksi perubahan secara efisien dan melakukan modifikasi yang sesuai pada data fakta. Dalam contoh ini untuk pesanan yang dibatalkan, status pesanan penjualan mungkin akan berubah dari Buka menjadi Dibatalkan. Perubahan itu akan memerlukan pembaruan data fakta, dan bukan penghapusan baris. Untuk perubahan kuantitas, pembaruan pengukuran kuantitas pada baris fakta akan diperlukan. Strategi menggunakan penghapusan lunak ini mempertahankan riwayat. Penghapusan sementara menandai catatan sebagai tidak lagi aktif atau valid, dan kueri pelaporan serta model semantik Power BI harus memfilter catatan yang merupakan penghapusan sementara.

Saat Anda mengantisipasi pembaruan atau penghapusan fakta, Anda harus menyertakan atribut (seperti nomor pesanan penjualan dan nomor baris pesanan penjualannya) dalam tabel fakta untuk membantu mengidentifikasi baris fakta untuk dimodifikasi. Pastikan untuk mengindeks kolom ini untuk mendukung operasi modifikasi yang efisien.

Terakhir, jika data fakta dimasukkan dengan menggunakan anggota dimensi khusus (seperti Tidak Diketahui), Anda harus menjalankan proses berkala yang mengambil data sumber saat ini untuk baris fakta tersebut dan memperbarui kunci dimensi ke nilai yang valid.

Konten terkait

Untuk informasi selengkapnya tentang memuat data ke dalam Fabric Warehouse, lihat: