Pemodelan dimensi di Microsoft Fabric Warehouse: Tabel dimensi

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 merancang tabel dimensi 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 berada dalam kontrol penuh untuk membuat tabel model dimensi Anda dan memuatnya dengan data.

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 mengacu pada Gudang Fabric, 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.

Dalam model dimensi, tabel dimensi menjelaskan entitas yang relevan dengan persyaratan bisnis dan analitik Anda. Secara luas, tabel dimensi mewakili hal-hal yang Anda model. Hal-hal bisa berupa produk, orang, tempat, atau konsep lain, termasuk tanggal dan waktu. Untuk mengidentifikasi tabel dimensi dengan mudah, Anda biasanya mengawali namanya dengan d_ atau Dim_.

Struktur tabel dimensi

Untuk menjelaskan struktur tabel dimensi, pertimbangkan contoh tabel dimensi tenaga penjualan berikut bernama d_Salesperson. Contoh ini menerapkan praktik desain yang baik. Setiap grup kolom dijelaskan di bagian berikut.

CREATE TABLE d_Salesperson
(
    --Surrogate key
    Salesperson_SK INT NOT NULL,
    
    --Natural key(s)
    EmployeeID VARCHAR(20) NOT NULL,
    
    --Dimension attributes
    FirstName VARCHAR(20) NOT NULL,
    <…>
    
    --Foreign key(s) to other dimensions
    SalesRegion_FK INT NOT NULL,
    <…>
    
    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditIsInferred BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

File Kunci Pengganti

Tabel dimensi sampel memiliki kunci pengganti, yang diberi nama Salesperson_SK. Kunci pengganti adalah pengidentifikasi unik kolom tunggal yang dihasilkan dan disimpan dalam tabel dimensi. Ini adalah kolom kunci utama yang digunakan untuk berhubungan dengan tabel lain dalam model dimensi.

Kunci pengganti berusaha untuk mengisolasi gudang data dari perubahan data sumber. Mereka juga memberikan banyak manfaat lain, memungkinkan Anda untuk:

• Mengonsolidasikan beberapa sumber data (menghindari bentrokan pengidentifikasi duplikat).
• Mengonsolidasikan kunci alami multi-kolom ke dalam kunci kolom tunggal yang lebih efisien.
• Lacak riwayat dimensi dengan dimensi yang berubah perlahan (SCD) tipe 2.
• Batasi lebar tabel fakta untuk pengoptimalan penyimpanan (dengan memilih jenis data bilangan bulat sekecil mungkin).

Kolom kunci pengganti adalah praktik yang direkomendasikan, bahkan ketika kunci alami (dijelaskan berikutnya) tampaknya kandidat yang dapat diterima. Anda juga harus menghindari memberikan arti pada nilai kunci (kecuali untuk kunci dimensi tanggal dan waktu, seperti yang dijelaskan nanti).

Kunci alami

Tabel dimensi sampel juga memiliki kunci alami, yang diberi nama EmployeeID. Kunci alami adalah kunci yang disimpan dalam sistem sumber. Ini memungkinkan kaitkan data dimensi dengan sistem sumbernya, yang biasanya dilakukan oleh proses Ekstrak, Muat, dan Transformasi (ETL) untuk memuat tabel dimensi. Terkadang kunci alami disebut kunci bisnis, dan nilainya mungkin bermakna bagi pengguna bisnis.

Terkadang dimensi tidak memiliki kunci alami. Itu bisa menjadi kasus untuk dimensi tanggal atau dimensi pencarian Anda, atau saat Anda menghasilkan data dimensi dengan menormalkan file datar.

Atribut dimensi

Tabel dimensi sampel juga memiliki atribut dimensi, seperti FirstName kolom . Atribut dimensi menyediakan konteks untuk data numerik yang disimpan dalam tabel fakta terkait. Kolom tersebut biasanya berupa kolom teks yang digunakan dalam kueri analitik untuk memfilter dan mengelompokkan (ikatan dan dadu), tetapi tidak untuk diagregasi sendiri. Beberapa tabel dimensi berisi beberapa atribut, sementara yang lain berisi banyak atribut (sebanyak yang diperlukan untuk mendukung persyaratan kueri model dimensi).

Tip

Cara yang baik untuk menentukan dimensi dan atribut mana yang Anda butuhkan adalah menemukan orang yang tepat dan mengajukan pertanyaan yang tepat. Secara khusus, tetap waspada untuk penyebutan kata dengan. Misalnya, ketika seseorang mengatakan mereka perlu menganalisis penjualan oleh tenaga penjualan, berdasarkan bulan, dan berdasarkan kategori produk, mereka memberi tahu Anda bahwa mereka membutuhkan dimensi yang memiliki atribut tersebut.

Jika Anda berencana untuk membuat model semantik Direct Lake, Anda harus menyertakan semua kolom yang mungkin diperlukan untuk pemfilteran dan pengelompokan sebagai atribut dimensi. Itu karena model semantik Direct Lake tidak mendukung kolom terhitung.

Kunci Asing

Tabel dimensi sampel juga memiliki kunci asing, yang diberi nama SalesRegion_FK. Tabel dimensi lainnya dapat mereferensikan kunci asing, dan kehadirannya dalam tabel dimensi adalah kasus khusus. Ini menunjukkan bahwa tabel terkait dengan tabel dimensi lain, yang berarti bahwa tabel tersebut mungkin merupakan bagian dari dimensi snowflake atau terkait dengan dimensi outrigger.

Fabric Warehouse mendukung batasan kunci asing tetapi tidak dapat diberlakukan. Oleh karena itu, penting bahwa pengujian proses ETL Anda untuk integritas antara tabel terkait saat data dimuat.

Ini masih merupakan ide yang baik untuk membuat kunci asing. Salah satu alasan yang baik untuk membuat kunci asing yang tidak diberlakukan adalah untuk memungkinkan alat pemodelan, seperti Power BI Desktop, untuk secara otomatis mendeteksi dan membuat hubungan antar tabel dalam model semantik.

Atribut pelacakan historis

Tabel dimensi sampel juga memiliki berbagai atribut pelacakan historis. Atribut pelacakan historis bersifat opsional berdasarkan kebutuhan Anda untuk melacak perubahan tertentu saat terjadi di sistem sumber. Mereka memungkinkan penyimpanan nilai untuk mendukung peran utama gudang data, yaitu menggambarkan masa lalu secara akurat. Secara khusus, atribut ini menyimpan konteks historis karena proses ETL memuat data baru atau diubah ke dalam dimensi.

Untuk informasi selengkapnya, lihat Mengelola perubahan historis nanti di artikel ini.

Atribut audit

Tabel dimensi sampel juga memiliki berbagai atribut audit. Atribut audit bersifat opsional tetapi direkomendasikan. Mereka memungkinkan Anda melacak kapan dan bagaimana rekaman dimensi dibuat atau dimodifikasi, dan mereka dapat menyertakan informasi diagnostik atau pemecahan masalah yang dimunculkan selama proses ETL. Misalnya, Anda ingin melacak siapa (atau proses apa) yang memperbarui baris, dan kapan. Atribut audit juga dapat membantu mendiagnosis masalah yang menantang, seperti ketika proses ETL berhenti secara tak terduga. Mereka juga dapat menandai anggota dimensi sebagai kesalahan atau anggota yang disimpulkan.

Ukuran tabel dimensi

Seringkali, dimensi yang paling berguna dan serbaguna dalam model dimensi adalah dimensi besar dan lebar. Mereka besar dalam hal baris (lebih dari jutaan) dan luas dalam hal jumlah atribut dimensi (berpotensi ratusan). Ukuran tidak begitu penting (meskipun Anda harus merancang dan mengoptimalkan untuk ukuran sekecil mungkin). Yang penting adalah dimensi mendukung pemfilteran, pengelompokan, dan analisis historis data fakta yang diperlukan.

Dimensi besar mungkin bersumber dari beberapa sistem sumber. Dalam hal ini, pemrosesan dimensi perlu menggabungkan, menggabungkan, mendeduplikasi, dan menstandarkan data; dan tetapkan kunci pengganti.

Sebagai perbandingan, beberapa dimensi kecil. Mereka mungkin mewakili tabel pencarian yang hanya berisi beberapa rekaman dan atribut. Seringkali dimensi kecil ini menyimpan nilai kategori yang terkait dengan transaksi dalam tabel fakta, dan diimplementasikan sebagai dimensi dengan kunci pengganti untuk berhubungan dengan rekaman fakta.

Tip

Ketika Anda memiliki banyak dimensi kecil, pertimbangkan untuk mengonsolidasikannya ke dalam dimensi sampah.

Konsep desain dimensi

Bagian ini menjelaskan berbagai konsep desain dimensi.

Denormalisasi vs. normalisasi

Hampir selalu kasus bahwa tabel dimensi harus dinormalisasi. Meskipun normalisasi adalah istilah yang digunakan untuk menjelaskan data yang disimpan dengan cara yang mengurangi data berulang, denormalisasi adalah istilah yang digunakan untuk menentukan di mana data redundan yang telah dikomputasi sebelumnya ada. Data redundan biasanya ada karena penyimpanan hierarki (dibahas kemudian), yang berarti bahwa hierarki diratakan. Misalnya, dimensi produk dapat menyimpan subkategori (dan atribut terkaitnya) dan kategori (dan atribut terkaitnya).

Karena dimensi umumnya kecil (jika dibandingkan dengan tabel fakta), biaya penyimpanan data redundan hampir selalu melebihi performa dan kegunaan kueri yang ditingkatkan.

Dimensi Snowflake

Salah satu pengecualian untuk denormalisasi adalah merancang dimensi snowflake. Dimensi snowflake dinormalisasi, dan menyimpan data dimensi di beberapa tabel terkait.

Diagram berikut menggambarkan dimensi snowflake yang terdiri dari tiga tabel dimensi terkait: Product, , Subcategorydan Category.

Pertimbangkan untuk menerapkan dimensi snowflake saat:

• Dimensinya sangat besar dan biaya penyimpanan melebihi kebutuhan akan performa kueri yang tinggi. (Namun, secara berkala menilai kembali bahwa ini masih tetap terjadi.)
• Anda memerlukan kunci untuk menghubungkan dimensi dengan fakta yang lebih tinggi. Misalnya, tabel fakta penjualan menyimpan baris di tingkat produk, tetapi tabel fakta target penjualan menyimpan baris di tingkat subkataan.
• Anda perlu melacak perubahan historis pada tingkat granularitas yang lebih tinggi.

Catatan

Perlu diingat bahwa hierarki dalam model semantik Power BI hanya dapat didasarkan pada kolom dari tabel model semantik tunggal. Oleh karena itu, dimensi snowflake harus memberikan hasil denormalisasi dengan menggunakan tampilan yang menggabungkan tabel snowflake bersama-sama.

Hirarki

Umumnya, kolom dimensi menghasilkan hierarki. Hierarki memungkinkan eksplorasi data pada tingkat ringkasan yang berbeda. Misalnya, tampilan awal visual matriks mungkin menunjukkan penjualan tahunan, dan konsumen laporan dapat memilih untuk menelusuri paling detail untuk mengungkapkan penjualan triwulanan dan bulanan.

Ada tiga cara untuk menyimpan hierarki dalam dimensi. Anda dapat menggunakan:

• Kolom dari dimensi tunggal yang dinormalisasi.
• Dimensi snowflake, yang terdiri dari beberapa tabel terkait.
• Hubungan induk-anak (referensi mandiri) dalam dimensi.

Hierarki dapat seimbang atau tidak seimbang. Penting juga untuk dipahami bahwa beberapa hierarki mengamuk.

Hierarki seimbang

Hierarki seimbang adalah jenis hierarki yang paling umum. Hierarki seimbang memiliki jumlah tingkat yang sama. Contoh umum hierarki seimbang adalah hierarki kalender dalam dimensi tanggal yang terdiri dari tingkat untuk tahun, kuartal, bulan, dan tanggal.

Diagram berikut menggambarkan hierarki wilayah penjualan yang seimbang. Ini terdiri dari dua tingkat, yang merupakan grup wilayah penjualan dan wilayah penjualan.

Tingkat hierarki seimbang didasarkan pada kolom dari dimensi tunggal yang dinormalisasi, atau dari tabel yang membentuk dimensi snowflake. Ketika berdasarkan dimensi tunggal yang didenormalisasi, kolom yang mewakili tingkat yang lebih tinggi berisi data redundan.

Untuk hierarki seimbang, fakta selalu berkaitan dengan satu tingkat hierarki, yang biasanya merupakan tingkat terendah. Dengan begitu, fakta dapat diagregasi (digulung) ke tingkat hierarki tertinggi. Fakta dapat berhubungan dengan tingkat apa pun, yang ditentukan oleh butir tabel fakta. Misalnya, tabel fakta penjualan mungkin disimpan pada tingkat tanggal, sementara tabel fakta target penjualan mungkin disimpan pada tingkat kuartal.

Hierarki yang tidak seimbang

Hierarki yang tidak seimbang adalah jenis hierarki yang kurang umum. Hierarki yang tidak seimbang memiliki tingkat berdasarkan hubungan induk-anak. Untuk alasan ini, jumlah tingkat dalam hierarki yang tidak seimbang ditentukan oleh baris dimensi, dan bukan kolom tabel dimensi tertentu.

Contoh umum hierarki yang tidak seimbang adalah hierarki karyawan di mana setiap baris dalam dimensi karyawan berkaitan dengan baris manajer pelaporan dalam tabel yang sama. Dalam hal ini, setiap karyawan dapat menjadi manajer dengan karyawan pelaporan. Secara alami, beberapa cabang hierarki akan memiliki lebih banyak tingkat daripada yang lain.

Diagram berikut menggambarkan hierarki yang tidak seimbang. Ini terdiri dari empat tingkat, dan setiap anggota dalam hierarki adalah tenaga penjual. Perhatikan bahwa tenaga penjualan memiliki jumlah leluhur yang berbeda dalam hierarki sesuai dengan siapa mereka melapor.

Contoh umum hierarki tidak seimbang lainnya termasuk tagihan bahan, model kepemilikan perusahaan, dan buku besar umum.

Untuk hierarki yang tidak seimbang, fakta selalu terkait dengan butir dimensi. Misalnya, fakta penjualan terkait dengan tenaga penjualan yang berbeda, yang memiliki struktur pelaporan yang berbeda. Tabel dimensi akan memiliki kunci pengganti (bernama Salesperson_SK) dan ReportsTo_Salesperson_FK kolom kunci asing, yang mereferensikan kolom kunci utama. Setiap tenaga penjualan tanpa siapa pun untuk dikelola belum tentu berada di tingkat terendah dari cabang hierarki apa pun. Ketika mereka tidak berada di tingkat terendah, tenaga penjualan mungkin menjual produk dan memiliki tenaga penjualan pelaporan yang juga menjual produk. Jadi, rollup data fakta harus mempertimbangkan staf penjualan individu dan semua keturunannya.

Mengkueri hierarki induk-anak bisa rumit dan lambat, terutama untuk dimensi besar. Meskipun sistem sumber mungkin menyimpan hubungan sebagai induk-anak, kami sarankan Anda menaturalisasi hierarki. Dalam hal ini, naturalisasi berarti mengubah dan menyimpan tingkat hierarki dalam dimensi sebagai kolom.

Tip

Jika Anda memilih untuk tidak menaturalisasi hierarki, Anda masih bisa membuat hierarki berdasarkan hubungan induk-anak dalam model semantik Power BI. Namun, pendekatan ini tidak disarankan untuk dimensi besar. Untuk informasi selengkapnya, lihat Memahami fungsi untuk hierarki induk-anak di DAX.

Hierarki yang tidak jelas

Terkadang hierarki dirusak karena induk anggota dalam hierarki ada pada tingkat yang tidak tepat di atasnya. Dalam kasus ini, nilai tingkat yang hilang mengulangi nilai induk.

Pertimbangkan contoh hierarki geografi yang seimbang. Hierarki yang tidak jelas ada ketika negara/wilayah tidak memiliki negara bagian atau provinsi. Misalnya, Selandia Baru tidak memiliki negara bagian atau provinsi. Jadi, saat Anda menyisipkan baris Selandia Baru, Anda juga harus menyimpan nilai negara/wilayah di StateProvince kolom .

Diagram berikut menggambarkan hierarki wilayah geografis yang tidak jelas.

Mengelola perubahan historis

Jika perlu, perubahan historis dapat dikelola dengan menerapkan dimensi yang berubah secara perlahan (SCD). SCD mempertahankan konteks historis sebagai data baru atau yang diubah, dimuat ke dalamnya.

Berikut adalah jenis SCD yang paling umum.

• Jenis 1: Timpa anggota dimensi yang ada.
• Jenis 2: Sisipkan anggota dimensi versi berbasis waktu baru.
• Jenis 3: Lacak riwayat terbatas dengan atribut.

Ada kemungkinan bahwa dimensi dapat mendukung perubahan tipe SCD 1 dan SCD tipe 2.

SCD tipe 3 tidak umum digunakan, sebagian karena fakta bahwa sulit untuk digunakan dalam model semantik. Pertimbangkan dengan cermat apakah pendekatan SCD tipe 2 akan lebih cocok.

Tip

Jika Anda mengantisipasi dimensi yang berubah dengan cepat, yang merupakan dimensi yang memiliki atribut yang sering berubah, pertimbangkan untuk menambahkan atribut tersebut ke tabel fakta sebagai gantinya. Jika atribut numerik, seperti harga produk, Anda dapat menambahkannya sebagai ukuran dalam tabel fakta. Jika atribut adalah nilai teks, Anda dapat membuat dimensi berdasarkan semua nilai teks dan menambahkan kunci dimensinya ke tabel fakta.

SCD tipe 1

Perubahan SCD jenis 1 menimpa baris dimensi yang ada karena tidak perlu melacak perubahan. Jenis SCD ini juga dapat digunakan untuk memperbaiki kesalahan. Ini adalah jenis SCD umum, dan harus digunakan untuk sebagian besar atribut yang berubah, seperti nama pelanggan, alamat email, dan lainnya.

Diagram berikut menggambarkan status sebelum dan sesudah anggota dimensi tenaga penjualan di mana nomor telepon mereka telah berubah.

Jenis SCD ini tidak mempertahankan perspektif historis karena baris yang ada diperbarui. Itu berarti perubahan SCD tipe 1 dapat menghasilkan agregasi tingkat yang lebih tinggi yang berbeda. Misalnya, jika tenaga penjualan ditetapkan ke wilayah penjualan yang berbeda, perubahan SCD jenis 1 akan menimpa baris dimensi. Rollup hasil penjualan historis tenaga penjualan ke wilayah kemudian akan menghasilkan hasil yang berbeda karena sekarang menggunakan wilayah penjualan baru saat ini. Seolah-olah tenaga penjualan itu selalu ditetapkan ke wilayah penjualan baru.

SCD tipe 2

Perubahan SCD tipe 2 menghasilkan baris baru yang mewakili versi berbasis waktu anggota dimensi. Selalu ada baris versi saat ini, dan mencerminkan status anggota dimensi dalam sistem sumber. Atribut pelacakan historis dalam nilai penyimpanan tabel dimensi yang memungkinkan mengidentifikasi versi saat ini (bendera saat ini adalah TRUE) dan periode waktu validitasnya. Kunci pengganti diperlukan karena akan ada kunci alami duplikat saat beberapa versi disimpan.

Ini adalah jenis SCD yang umum, tetapi harus dicadangkan untuk atribut yang harus mempertahankan perspektif historis.

Misalnya, jika tenaga penjualan ditetapkan ke wilayah penjualan yang berbeda, perubahan SCD jenis 2 melibatkan operasi pembaruan dan operasi penyisipan.

1. Operasi pembaruan menimpa versi saat ini untuk mengatur atribut pelacakan historis. Secara khusus, kolom validitas akhir diatur ke tanggal pemrosesan ETL (atau tanda waktu yang sesuai dalam sistem sumber) dan bendera saat ini diatur ke FALSE.
2. Operasi sisipkan menambahkan versi baru saat ini, mengatur kolom validitas mulai ke nilai kolom validitas akhir (digunakan untuk memperbarui versi sebelumnya) dan bendera saat ini ke TRUE.

Penting untuk dipahami bahwa granularitas tabel fakta terkait tidak berada di tingkat tenaga penjualan, melainkan tingkat versi tenaga penjualan. Rollup hasil penjualan historis mereka ke wilayah akan menghasilkan hasil yang benar tetapi akan ada dua (atau lebih) versi anggota tenaga penjualan untuk dianalisis.

Diagram berikut menggambarkan status sebelum dan sesudah anggota dimensi tenaga penjualan tempat wilayah penjualan mereka telah berubah. Karena organisasi ingin menganalisis upaya tenaga penjualan berdasarkan wilayah tempat mereka ditetapkan, organisasi tersebut memicu perubahan SCD tipe 2.

Tip

Saat tabel dimensi mendukung perubahan SCD jenis 2, Anda harus menyertakan atribut label yang menjelaskan anggota dan versi. Pertimbangkan contoh ketika staf penjualan Lynn Tsoflias dari Adventure Works mengubah penugasan dari wilayah penjualan Australia ke wilayah penjualan Inggris. Atribut label untuk versi pertama dapat membaca "Lynn Tsoflias (Australia)" dan atribut label untuk versi baru saat ini dapat membaca "Lynn Tsoflias (Inggris)." Jika bermanfaat, Anda mungkin juga menyertakan tanggal validitas dalam label.

Anda harus menyeimbangkan kebutuhan akan akurasi historis versus kegunaan dan efisiensi. Cobalah untuk menghindari terlalu banyak perubahan SCD tipe 2 pada tabel dimensi karena dapat mengakibatkan jumlah versi yang luar biasa yang mungkin menyulitkan analis untuk memahaminya.

Selain itu, terlalu banyak versi dapat menunjukkan bahwa atribut yang berubah mungkin lebih baik disimpan dalam tabel fakta. Memperluas contoh sebelumnya, jika perubahan wilayah penjualan sering terjadi, wilayah penjualan dapat disimpan sebagai kunci dimensi dalam tabel fakta daripada menerapkan SCD tipe 2.

Pertimbangkan atribut pelacakan historis SCD tipe 2 berikut.

CREATE TABLE d_Salesperson
(
    <…>

    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,

    <…>
);

Berikut adalah tujuan atribut pelacakan historis.

• Kolom RecChangeDate_FK menyimpan tanggal ketika perubahan mulai berlaku. Ini memungkinkan Anda untuk mengkueri kapan perubahan terjadi.
• Kolom RecValidFromKey dan RecValidToKey menyimpan tanggal validitas efektif untuk baris. Pertimbangkan untuk menyimpan tanggal paling awal yang ditemukan dalam dimensi tanggal untuk RecValidFromKey mewakili versi awal, dan menyimpan 01/01/9999 untuk RecValidToKey versi saat ini.
• Kolom RecReason bersifat opsional. Ini memungkinkan mendokumen alasan mengapa versi disisipkan. Ini dapat mengodekan atribut mana yang berubah, atau bisa menjadi kode dari sistem sumber yang menyatakan alasan bisnis tertentu.
• Kolom RecIsCurrent memungkinkan untuk mengambil versi saat ini saja. Ini digunakan ketika proses ETL mencari kunci dimensi saat memuat tabel fakta.

Catatan

Beberapa sistem sumber tidak menyimpan perubahan historis, jadi penting bahwa dimensi diproses secara teratur untuk mendeteksi perubahan dan menerapkan versi baru. Dengan demikian, Anda dapat mendeteksi perubahan segera setelah terjadi, dan tanggal validitasnya akan akurat.

SCD tipe 3

Perubahan SCD jenis 3 melacak riwayat terbatas dengan atribut. Pendekatan ini dapat berguna ketika ada kebutuhan untuk merekam perubahan terakhir, atau sejumlah perubahan terbaru.

Jenis SCD ini mempertahankan perspektif historis terbatas . Ini mungkin berguna ketika hanya nilai awal dan saat ini yang harus disimpan. Dalam hal ini, perubahan sementara tidak akan diperlukan.

Misalnya, jika tenaga penjualan ditetapkan ke wilayah penjualan yang berbeda, perubahan SCD jenis 3 menimpa baris dimensi. Kolom yang secara khusus menyimpan wilayah penjualan sebelumnya ditetapkan sebagai wilayah penjualan sebelumnya, dan wilayah penjualan baru ditetapkan sebagai wilayah penjualan saat ini.

Diagram berikut menggambarkan status sebelum dan sesudah anggota dimensi tenaga penjualan tempat wilayah penjualan mereka telah berubah. Karena organisasi ingin menentukan penetapan wilayah penjualan sebelumnya, organisasi tersebut memicu perubahan TIPE 3 SCD.

Anggota dimensi khusus

Anda mungkin menyisipkan baris ke dalam dimensi yang mewakili status hilang, tidak diketahui, N/A, atau kesalahan. Misalnya, Anda dapat menggunakan nilai kunci pengganti berikut.

Nilai kunci	Tujuan
0	Hilang (tidak tersedia di sistem sumber)
-1	Tidak diketahui (kegagalan pencarian selama pemuatan tabel fakta)
-2	N/A (tidak berlaku)
-3	Kesalahan

Kalender dan waktu

Hampir tanpa pengecualian, tabel fakta menyimpan langkah-langkah pada titik waktu tertentu. Untuk mendukung analisis berdasarkan tanggal (dan mungkin waktu), harus ada dimensi kalender (tanggal dan waktu).

Tidak jarang sistem sumber akan memiliki data dimensi kalender, sehingga harus dibuat di gudang data. Biasanya, ini dihasilkan sekali, dan jika merupakan dimensi kalender, ini diperpanjang dengan tanggal mendatang saat diperlukan.

Dimensi tanggal

Dimensi tanggal (atau kalender) adalah dimensi yang paling umum digunakan untuk analisis. Ini menyimpan satu baris per tanggal, dan mendukung persyaratan umum untuk memfilter atau mengelompokkan menurut periode tanggal tertentu, seperti tahun, kuartal, atau bulan.

Penting

Dimensi tanggal tidak boleh menyertakan biji-bijian yang meluas hingga waktu. Jika analisis waktu hari diperlukan, Anda harus memiliki dimensi tanggal dan dimensi waktu (dijelaskan berikutnya). Tabel fakta yang menyimpan fakta waktu hari harus memiliki dua kunci asing, satu untuk masing-masing dimensi ini.

Kunci alami dimensi tanggal harus menggunakan jenis data tanggal . Kunci pengganti harus menyimpan tanggal dengan menggunakan YYYYMMDD format dan jenis data int . Praktik yang diterima ini harus menjadi satu-satunya pengecualian (bersama dimensi waktu) ketika nilai kunci pengganti memiliki arti dan dapat dibaca manusia. Menyimpan YYYYMMDD sebagai jenis data int tidak hanya efisien dan diurutkan secara numerik, tetapi juga sesuai dengan format tanggal Organisasi Standar Internasional (ISO) 8601 yang tidak ambigu.

Berikut adalah beberapa atribut umum untuk disertakan dalam dimensi tanggal.

• Year, , QuarterMonth,Day
• QuarterNumberInYear, MonthNumberInYear – yang mungkin diperlukan untuk mengurutkan label teks.
• FiscalYear, – FiscalQuarter beberapa jadwal akuntansi perusahaan mulai pertengahan tahun, sehingga awal/akhir tahun kalender dan tahun fiskal berbeda.
• FiscalQuarterNumberInYear, FiscalMonthNumberInYear – yang mungkin diperlukan untuk mengurutkan label teks.
• WeekOfYear – ada beberapa cara untuk melabeli minggu dalam setahun, termasuk standar ISO yang memiliki 52 atau 53 minggu.
• IsHoliday, HolidayText – jika organisasi Anda beroperasi di beberapa geografi, Anda harus mempertahankan beberapa set daftar hari libur yang diamati setiap geografi sebagai dimensi terpisah atau dinaturalisasi dalam beberapa atribut dalam dimensi tanggal. HolidayText Menambahkan atribut dapat membantu mengidentifikasi hari libur untuk pelaporan.
• IsWeekday – demikian pula, di beberapa geografi, minggu kerja standar tidak senin hingga Jumat. Misalnya, minggu kerja adalah Minggu hingga Kamis di banyak wilayah Timur Tengah, sementara wilayah lain menggunakan minggu kerja empat hari atau enam hari.
• LastDayOfMonth
• RelativeYearOffset, , RelativeQuarterOffsetRelativeMonthOffset, RelativeDayOffset – yang mungkin diperlukan untuk mendukung pemfilteran tanggal relatif (misalnya, bulan sebelumnya). Periode saat ini menggunakan offset nol (0); periode sebelumnya menyimpan offset dari -1, -2, -3...; periode mendatang menyimpan offset 1, 2, 3....

Seperti halnya dimensi apa pun, yang penting adalah berisi atribut yang mendukung persyaratan pemfilteran, pengelompokan, dan hierarki yang diketahui. Mungkin juga ada atribut yang menyimpan terjemahan label ke dalam bahasa lain.

Ketika dimensi digunakan untuk berhubungan dengan fakta yang lebih tinggi, tabel fakta dapat menggunakan tanggal pertama periode tanggal. Misalnya, tabel fakta target penjualan yang menyimpan target tenaga penjualan triwulanan akan menyimpan tanggal pertama kuartal dalam dimensi tanggal. Pendekatan alternatif adalah membuat kolom kunci dalam tabel tanggal. Misalnya, kunci seperempat dapat menyimpan kunci kuartal dengan menggunakan YYYYQ format dan jenis data smallint .

Dimensi harus diisi dengan rentang tanggal yang diketahui yang digunakan oleh semua tabel fakta. Ini juga harus mencakup tanggal di masa mendatang ketika gudang data menyimpan fakta tentang target, anggaran, atau perkiraan. Seperti halnya dimensi lain, Anda mungkin menyertakan baris yang mewakili situasi hilang, tidak diketahui, N/A, atau kesalahan.

Tip

Cari internet untuk "generator dimensi tanggal" untuk menemukan skrip dan spreadsheet yang menghasilkan data tanggal.

Biasanya, pada awal tahun depan, proses ETL harus memperpanjang baris dimensi tanggal ke jumlah tahun ke depan tertentu. Ketika dimensi menyertakan atribut offset relatif, proses ETL harus dijalankan setiap hari untuk memperbarui nilai atribut offset berdasarkan tanggal saat ini (hari ini).

Dimensi waktu

Terkadang, fakta perlu disimpan pada satu titik waktu (seperti pada waktu sehari). Dalam hal ini, buat dimensi waktu (atau jam). Ini bisa memiliki butiran menit (24 x 60 = 1.440 baris) atau bahkan detik (24 x 60 x 60 = 86.400 baris). Kemungkinan biji-bijian lainnya termasuk setengah jam atau jam.

Kunci alami dimensi waktu harus menggunakan jenis data waktu . Kunci pengganti dapat menggunakan format yang sesuai dan menyimpan nilai yang memiliki arti dan dapat dibaca manusia, misalnya, dengan menggunakan HHMM format atau HHMMSS .

Berikut adalah beberapa atribut umum untuk disertakan dalam dimensi waktu.

• Hour, , HalfHourQuarterHour,Minute
• Label periode waktu (pagi, sore, malam, malam)
• Nama shift kerja
• Bendera puncak atau di luar puncak

Dimensi yang sesuai

Beberapa dimensi mungkin sesuai dimensi. Dimensi yang sesuai berkaitan dengan banyak tabel fakta, sehingga mereka dibagikan oleh beberapa bintang dalam model dimensi. Mereka memberikan konsistensi dan dapat membantu Anda mengurangi pengembangan dan pemeliharaan yang sedang berlangsung.

Misalnya, biasanya tabel fakta menyimpan setidaknya satu kunci dimensi tanggal (karena aktivitas hampir selalu direkam berdasarkan tanggal dan/atau waktu). Untuk alasan itu, dimensi tanggal adalah dimensi yang sesuai umum. Oleh karena itu, Anda harus memastikan bahwa dimensi tanggal Anda menyertakan atribut yang relevan untuk analisis semua tabel fakta.

Diagram berikut menunjukkan Sales tabel fakta dan Inventory tabel fakta. Setiap tabel fakta berkaitan dengan Date dimensi dan Product dimensi, yang merupakan dimensi yang sesuai.

Sebagai contoh lain, karyawan dan pengguna Anda bisa menjadi sekumpulan orang yang sama. Dalam hal ini, mungkin masuk akal untuk menggabungkan atribut setiap entitas untuk menghasilkan satu dimensi yang sesuai.

Dimensi pemutaran peran

Saat dimensi direferensikan beberapa kali dalam tabel fakta, dimensi ini dikenal sebagai dimensi pemutaran peran.

Misalnya, ketika tabel fakta penjualan memiliki tanggal pesanan, tanggal pengiriman, dan kunci dimensi tanggal pengiriman, dimensi tanggal berkaitan dengan tiga cara. Setiap cara mewakili peran yang berbeda, namun hanya ada satu dimensi tanggal fisik.

Diagram berikut menggambarkan Flight tabel fakta. Dimensi Airport adalah dimensi bermain peran karena terkait dua kali dengan tabel fakta sebagai Departure Airport dimensi dan Arrival Airport dimensi.

Dimensi sampah

Dimensi sampah berguna ketika ada banyak dimensi independen, terutama ketika mereka terdiri dari beberapa atribut (mungkin satu), dan ketika atribut ini memiliki kardinalitas rendah (beberapa nilai). Tujuan dimensi sampah adalah untuk mengonsolidasikan banyak dimensi kecil ke dalam satu dimensi. Pendekatan desain ini dapat mengurangi jumlah dimensi, dan mengurangi jumlah kunci tabel fakta dan dengan demikian ukuran penyimpanan tabel fakta. Mereka juga membantu mengurangi kekacauan panel Data karena menyajikan lebih sedikit tabel kepada pengguna.

Tabel dimensi sampah biasanya menyimpan produk Kartesius dari semua nilai atribut dimensi, dengan atribut kunci pengganti.

Kandidat yang baik termasuk bendera dan indikator, status pesanan, dan status demografi pelanggan (jenis kelamin, kelompok usia, dan lainnya).

Diagram berikut menggambarkan dimensi sampah bernama Sales Status yang menggabungkan nilai status pesanan dan nilai status pengiriman.

Dimensi degenerasi

Dimensi degenerasi dapat terjadi ketika dimensi berada pada butir yang sama dengan fakta terkait. Contoh umum dimensi degenerasi adalah dimensi nomor pesanan penjualan yang berkaitan dengan tabel fakta penjualan. Biasanya, nomor faktur adalah atribut non-hierarkis tunggal dalam tabel fakta. Jadi, ini adalah praktik yang diterima untuk tidak menyalin data ini untuk membuat tabel dimensi terpisah.

Diagram berikut menggambarkan Sales Order dimensi yang merupakan dimensi degenerasi berdasarkan SalesOrderNumber kolom dalam tabel fakta penjualan. Dimensi ini diimplementasikan sebagai tampilan yang mengambil nilai nomor pesanan penjualan yang berbeda.

Tip

Dimungkinkan untuk membuat tampilan di Gudang Fabric yang menyajikan dimensi degenerasi sebagai dimensi untuk tujuan kueri.

Dari perspektif pemodelan semantik Power BI, dimensi degenerasi dapat dibuat sebagai tabel terpisah dengan menggunakan Power Query. Dengan begitu, model semantik sesuai dengan praktik terbaik bahwa bidang yang digunakan untuk memfilter atau mengelompokkan bersumber dari tabel dimensi, dan bidang yang digunakan untuk meringkas fakta bersumber dari tabel fakta.

Dimensi outrigger

Saat tabel dimensi berkaitan dengan tabel dimensi lain, tabel tersebut dikenal sebagai dimensi outrigger. Dimensi outrigger dapat membantu menyesuaikan dan menggunakan kembali definisi dalam model dimensi.

Misalnya, Anda dapat membuat dimensi geografi yang menyimpan lokasi geografis untuk setiap kode pos. Dimensi tersebut kemudian dapat direferensikan oleh dimensi pelanggan dan dimensi tenaga penjual Anda, yang akan menyimpan kunci pengganti dimensi geografi. Dengan begitu, pelanggan dan tenaga penjualan kemudian dapat dianalisis dengan menggunakan lokasi geografis yang konsisten.

Diagram berikut menggambarkan Geography dimensi yang merupakan dimensi outrigger. Ini tidak berhubungan langsung dengan Sales tabel fakta. Sebaliknya, ini terkait secara tidak langsung melalui Customer dimensi dan Salesperson dimensi.

Pertimbangkan bahwa dimensi tanggal dapat digunakan sebagai dimensi outrigger saat tabel dimensi lain mengaitkan tanggal penyimpanan. Misalnya, tanggal lahir dalam dimensi pelanggan dapat disimpan dengan menggunakan kunci pengganti tabel dimensi tanggal.

Dimensi multinila

Saat atribut dimensi harus menyimpan beberapa nilai, Anda perlu merancang dimensi multinilai. Anda menerapkan dimensi multinila dengan membuat tabel jembatan (kadang-kadang disebut tabel gabungan). Tabel jembatan menyimpan hubungan banyak ke banyak antar entitas.

Misalnya, pertimbangkan ada dimensi tenaga penjualan, dan bahwa setiap tenaga penjualan ditetapkan ke satu atau mungkin lebih banyak wilayah penjualan. Dalam hal ini, masuk akal untuk membuat dimensi wilayah penjualan. Dimensi tersebut menyimpan setiap wilayah penjualan hanya sekali. Tabel terpisah, yang dikenal sebagai tabel jembatan, menyimpan baris untuk setiap staf penjualan dan hubungan wilayah penjualan. Secara fisik, ada hubungan satu-ke-banyak dari dimensi tenaga penjual ke tabel jembatan, dan hubungan satu ke banyak lainnya dari dimensi wilayah penjualan ke tabel jembatan. Secara logis, ada hubungan banyak ke banyak antara tenaga penjualan dan wilayah penjualan.

Dalam diagram berikut, Account tabel dimensi berkaitan dengan Transaction tabel fakta. Karena pelanggan dapat memiliki beberapa akun dan akun dapat memiliki beberapa pelanggan, Customer tabel dimensi terkait melalui Customer Account tabel jembatan.

Konten terkait

Di artikel berikutnya dalam seri ini, pelajari tentang panduan dan praktik terbaik desain untuk tabel fakta.