Database
 sql >> Teknologi Basis Data >  >> RDS >> Database

Dimensi Dimensi:Melihat Jenis Tabel Dimensi Paling Umum di Data Warehousing

Ketika kita memulai proyek data warehousing, hal pertama yang kita lakukan adalah mendefinisikan tabel dimensi. Tabel dimensi adalah bagian yang menarik, kerangka di mana kita membangun pengukuran kita. Mereka datang dalam berbagai bentuk dan ukuran. Dalam artikel ini, kita akan melihat lebih dekat setiap jenis tabel dimensi.

Tabel dimensi memberikan konteks pada proses bisnis yang ingin kita ukur. Mereka memberi tahu kita semua yang perlu kita ketahui tentang suatu peristiwa. Karena mereka memberikan substansi pada pengukuran (yaitu tabel fakta) dari sistem data warehouse (DWH), kami menghabiskan lebih banyak waktu untuk definisi dan identifikasi mereka daripada aspek lain dari proyek. Tabel fakta tentukan pengukuran; tabel dimensi memberikan konteks. (Untuk membaca lebih lanjut tentang tabel fakta, lihat postingan berikut tentang penyimpanan data, skema bintang, skema kepingan salju, dan fakta tentang tabel fakta).

Karakteristik utama tabel dimensi adalah banyak atributnya . Atribut adalah kolom yang kami rangkum, filter, atau agregat. Mereka memiliki kardinalitas rendah dan biasanya tekstual dan temporal. Tabel dimensi memiliki satu kunci utama berdasarkan kunci bisnis yang mendasarinya atau kunci pengganti . Kunci utama ini adalah dasar untuk menggabungkan tabel dimensi ke satu atau beberapa tabel fakta.

Dibandingkan dengan tabel fakta, tabel dimensi berukuran kecil, mudah disimpan, dan berdampak kecil pada performa.

Sekarang mari kita lihat beberapa tabel dimensi yang akan Anda temui di lingkungan gudang data.

Tabel Dimensi Umum:Dimensi Sesuai

Kita akan mulai dengan tipe dasar:dimensi yang sesuai. Ini memiliki banyak atribut, yang dapat dialamatkan dalam beberapa tabel sumber tetapi merujuk ke domain yang sama (pelanggan, kontrak, kesepakatan, dll.) Dimensi yang sesuai digunakan dengan banyak fakta dan harus unik untuk nilai butir/domain di gudang data.

Contoh:




Mari kita lihat tabel dimensi tipikal, DIM_CUSTOMER .

Kami mendefinisikan:

  • id – Kunci utama tabel dimensi.
  • cust_natural_key – Kunci alami bagi pelanggan.
  • first_name – Nama depan pelanggan.
  • last_name – Nama belakang pelanggan.
  • address_residence – Alamat tempat tinggal pelanggan.
  • date_of_birth – Tanggal lahir pelanggan.
  • marital_status - Apakah pelanggan sudah menikah? Didefinisikan sebagai Y (ya) atau N (tidak).
  • gender – Jenis kelamin pelanggan, M (pria) atau F (wanita).

Atribut tabel dimensi tergantung pada kebutuhan bisnis. Kami dapat memperluas jenis tabel ini untuk menyimpan informasi spesifik industri (tanggal default, aktivitas, dll.)

Tabel Dimensi Berubah Perlahan

Seiring berjalannya waktu, dimensi dapat mengubah nilainya. Dalam paragraf berikut, kita akan memeriksa dimensi yang diklasifikasikan menurut cara mereka menyimpan (atau tidak menyimpan) data historis.

Katakanlah Anda memiliki dimensi pelanggan. Beberapa atribut kemungkinan akan berubah dalam masa hidup pelanggan – mis. nomor telepon, alamat, status perkawinan, dll. Jenis tabel ini disebut Ralph Kimball sebagai dimensi yang berubah perlahan, atau SCD.

SCD datang dalam berbagai jenis; delapan di antaranya cukup umum. Dari jumlah tersebut, Anda akan melihat tipe 0 hingga 4 paling banyak; tipe 5, 6, dan 7 adalah hibrida dari lima yang pertama. (Catatan:Skema penomoran SCD ini dimulai dengan 0 bukan 1.)

SCD hybrid memberikan lebih banyak fleksibilitas dan kinerja yang lebih baik, tetapi dengan mengorbankan kesederhanaan. Kami menggunakan jenis tabel ini ketika kami perlu melakukan analisis analitik saat ini data dengan beberapa historis pertimbangan.

SCD Type 0:Mengisi Sekali

Ini adalah tipe paling dasar dari tabel dimensi:Anda mengisinya sekali dan tidak pernah mengisinya lagi. Anggap ini sebagai data referensial. Contoh khas dari hal ini adalah dimensi tanggal. Kita tidak perlu mengisi dimensi ini dengan setiap beban DWH. Tabel dimensi tidak berubah seiring waktu. Anda tidak bisa mendapatkan lebih banyak tanggal atau mengubah tanggal.

Tabel fakta terhubung ke atribut asli dari dimensi.

Contoh

Mari kita lihat dimensi waktu:




Strukturnya cukup sederhana:

  1. id – Kunci pengganti
  2. time_date – Tanggal sebenarnya
  3. time_day – Hari dalam sebulan
  4. time_week – Minggu dalam setahun
  5. time_month – Bulan dalam setahun
  6. time_year – Representasi angka dalam setahun

Tipe SCD 1:Menulis Ulang Data

Seperti namanya, kami menulis ulang jenis tabel dimensi ini dengan setiap beban DWH. Kami tidak perlu menyimpan sejarahnya, tetapi kami berharap akan ada beberapa perubahan.

Perbedaan antara SCD Tipe 0 dan Tipe 1 tidak terletak pada struktur tabel. Ini ada hubungannya dengan penyegaran data. Anda tidak pernah me-refresh data di Tipe 0, tetapi terkadang Anda melakukannya di Tipe 1.

Tabel yang dapat ditulis ulang adalah cara paling sederhana untuk menangani perubahan (hapus/masukkan), tetapi hanya menambahkan sedikit nilai bisnis. Setelah Anda menentukan tabel dimensi seperti ini, akan sulit untuk memasang penelusuran riwayat.

Tabel fakta terhubung ke atribut dimensi saat ini.

Contoh

Mari kita lihat dimensi akun:




Strukturnya adalah sebagai berikut:

  • id – Kunci pengganti tabel
  • account_name – Nama akun
  • account_type – Kategori akun
  • account_activity – Menandai berbagai jenis aktivitas

Jika kita melihat data sebelum perubahan, kita akan melihat ini:

Jika jenis akun telah berubah, data hanya akan ditimpa:

Jenis SCD 2:Melacak Atribut Historis menurut Baris

Ini adalah bentuk pelacakan historis yang paling umum dalam sistem DWH. Tabel SCD Tipe 2 menambahkan baris baru untuk setiap perubahan historis atribut dimensi antara Beban DWH . Dalam tipe ini, kami mendefinisikan kunci utama sebagai kunci pengganti karena kunci bisnis akan memiliki beberapa representasi sepanjang waktu. Ketika baris yang menyimpan perubahan data berubah, kami mendefinisikan nilai baru untuk kunci pengganti yang sesuai dengan nilai dalam tabel fakta. Kita perlu menambahkan setidaknya dua kolom, valid_from dan valid_to , untuk menyimpan riwayat dengan cara ini.

Tabel fakta terhubung ke atribut historis dimensi melalui kunci pengganti. Agregasi dilakukan pada kunci alami .

Contoh

Mari kita lihat tabel dimensi pelanggan sebelumnya, sekarang diperluas dengan dua kolom tanggal:




Mari kita lihat datanya:

Hal-hal yang Perlu Dipertimbangkan:

  • Bagaimana kami menandai baris saat ini, valid_to ? (Biasanya dengan 31.12.9999, atau NULL .)
  • Bagaimana kita bisa menandai baris pertama, valid_from ? (Biasanya dengan 01.01.1900, atau tanggal penyisipan pertama).
  • Apakah Anda mendefinisikan baris inklusif atau eksklusif? (Di atas, kami menggunakan valid_from yang inklusif dan valid_to exclusive eksklusif ).

Jenis SCD 3:Melacak Atribut Historis menurut Kolom

Seperti halnya SCD Tipe 2, tipe ini menambahkan sesuatu untuk mewakili nilai sejarah. Namun, dalam kasus ini, kami menambahkan kolom baru. Ini mewakili nilai atribut baris dimensi sebelum berubah. Biasanya, kami hanya menyimpan versi atribut sebelumnya.

Catatan:SCD ini jarang digunakan.

Tabel fakta terhubung ke atribut dimensi saat ini dan sebelumnya.

Contoh

Mari kita lihat dimensi pelanggan, kali ini dengan alamat tempat tinggal sebelumnya:




Dalam contoh ini, kami menambahkan kolom baru, previous_address_residence , untuk mewakili alamat lama pelanggan. Jika kita melihat contoh awal kita, data dalam tabel ini akan terlihat seperti ini:

Semua informasi historis, kecuali alamat pelanggan sebelumnya, hilang.

SCD Type 4:Menambahkan Dimensi Mini

Jenis dimensi ini tidak didasarkan pada perubahan struktural (Tipe 3) atau pada nilai (Tipe 2). Sebaliknya, ini didasarkan pada perubahan desain pada model. Jika tabel dimensi kita berisi data yang sangat fluktuatif – yaitu data yang sering berubah – ukuran tabel dimensi akan tumbuh secara signifikan.

Untuk mengurangi ini, kami mengekstrak atribut volatil ke dalam dimensi mini . Dimensi mini ini kemudian dapat digabungkan ke tingkat yang relevan dengan bisnis. Namun, agregasi ini tidak bingung dengan agregasi fakta . Contoh akan memperjelas hal ini.

Tabel fakta terhubung ke atribut historis dari dimensi.

Contoh

Mari kita lihat contoh dari data mart keuangan sederhana. Misalkan Anda perlu melacak seberapa terlambat pelanggan tertentu dengan pembayaran mereka. Sebut saja atribut ini hari lewat jatuh tempo, atau DPD. Jika kita melacak DPD setiap hari dalam dimensi Tipe 2, ukuran tabel akan segera meledak melampaui batas yang dapat dikelola. Jadi kami mengekstrak atribut dan menemukan periode DPD yang relevan dengan bisnis – katakanlah dengan kenaikan 30 hari (0-30 DPD, 30-60 DPD, 60-90 DPD, dll.)

Kita dapat mengambil atribut volatilitas tinggi lainnya, seperti usia, dan membangun periode yang relevan dengan bisnis untuk atribut tersebut juga (mis. 20-30 tahun, 30-40 tahun, dll.)

Jika kita melihat data dalam dimensi mini pelanggan, kita akan memiliki sesuatu seperti ini:

Atributnya adalah:

  • id – Kunci utama pengganti
  • DPD_period – Hari melewati batas waktu
  • DEM_period – Periode demografi

Skema bintang sederhana akan terlihat seperti ini:




Perhatikan bahwa untuk melakukan analitik pada atribut dari kedua tabel, kita harus menjembataninya melalui tabel fakta.

Tipe SCD 5:Membuat Dimensi Mini dengan Ekstensi yang Dapat Ditulis Ulang

Ini adalah yang pertama dari konstruksi tabel dimensi hibrida kami. Dalam SCD Tipe 5, kami menambahkan versi data mini-dimensi saat ini ke tabel dimensi. Kita harus ingat bahwa kita hanya akan menambahkan saat ini representasi dari dimensi mini ke dimensi utama.

Kami mengisi ulang ekstensi mini-dimensi ini dengan setiap beban (SCD "dapat ditulis ulang" Tipe 1).

Meskipun historisasi ekstensi ini dapat menyebabkan masalah ukuran, kami telah menguranginya dengan tabel dimensi mini.

Kami menggunakan teknik ini ketika kami ingin melakukan analitik langsung pada tabel dimensi.

Contoh

Memperluas contoh sebelumnya dengan dimensi mini saat ini, kita mendapatkan:




dim_mini_customer_current tabel berisi nilai atribut terbaru yang sesuai dengan dim_customer meja. Sekarang kami dapat melakukan analisis khusus pelanggan tanpa menjembatani tabel fakta (yang sangat lambat).

Tabel fakta terhubung ke atribut historis dari dimensi.

Tipe 6:Dimensi Tipe 2 (Baris Historis) dengan Atribut yang Dapat Ditulis Ulang

Ini adalah konstruksi dimensi yang sangat umum. Kami menambahkan atribut yang menyimpan satu hal, biasanya nilai terakhir yang diketahui, yang kami tulis ulang dengan setiap beban. Ini memungkinkan kami untuk mengelompokkan semua fakta berdasarkan nilainya saat ini, sedangkan atribut historis menampilkan data seperti saat peristiwa terjadi.

Tabel fakta terhubung ke nilai dimensi pada momen waktu peristiwa dengan nilai dimensi arus ekstra.

Contoh

Mari kita perluas tabel pelanggan sebelumnya dengan current_address_residence kolom.




Sekarang kami memiliki atribut yang akan kami perbarui ke nilai saat ini, menggunakan kunci alami (cust_natural_key ).

Tipe 7:Dimensi Tipe 2 (Baris Sejarah) dengan Cermin Saat Ini

Kita dapat menggunakan tipe ini hanya jika ada kunci alami dalam dimensi tabel. Kunci tidak boleh berubah selama masa hidup entitas.

Idenya sederhana:kami menambahkan representasi saat ini dari tabel dimensi ke skema kepingan salju. Kemudian kami memasukkan kunci alami dari dimensi baru ke tabel fakta. (Kunci pengganti dari dimensi sejarah masih ada.)

Tabel fakta terhubung ke nilai dimensi pada momen waktu peristiwa dan ke nilai dimensi saat ini.

Contoh

Mari kita lihat skema bintang akun pelanggan kami. Kami menambahkan dimensi baru, dim_current_customer , ke tabel fakta. Tabel ini terhubung ke tabel fakta melalui kunci alami, cust_natural_key .




Konstruksi ini memungkinkan kami melakukan kueri analitik pada skema bintang dengan nilai atribut pelanggan saat ini dan historis.

Dimensi Domain

Dimensi domain adalah bentuk sederhana dari tabel dimensi. Ini menyimpan informasi tentang domain pengukuran yang mendasari atribut dimensi. Tabel ini menyimpan berbagai kode dan nilai penjelasan.

Contoh

Contoh sederhananya adalah tabel mata uang.




Dalam tabel ini, kami menyimpan informasi deskriptif tentang berbagai unit moneter.

Menurut pendapat pribadi saya, penggunaan terbaik dari dimensi domain adalah dalam dokumentasi nilai data yang kami temukan di sistem DWH.

Dimensi Sampah

Sistem sumber transaksional menghasilkan banyak indikator dan tanda. Atribut ini dapat dianggap sebagai data kategoris, tetapi tidak relevan dengan bisnis atau cukup jelas. Kita dapat memasukkan semua indikator dan flag ini ke dalam tabel satu dimensi yang disebut dimensi sampah . Dimensi sampah adalah alternatif untuk menggunakan dimensi yang merosot. Jika kita tidak ingin membebani tabel fakta dengan banyak dimensi yang merosot, kita membuat satu dimensi sampah.

Kami harus mencatat bahwa kami tidak mengisi semua kemungkinan kombinasi indikator dan bendera. Kami hanya mengisi yang ada di sistem sumber.

Contoh




Tabel dimensi adalah kerangka dunia pergudangan data:semuanya dibangun di sekitarnya. Mereka tidak sebesar tabel fakta, tetapi strukturnya bisa lebih kompleks.

Anda dapat mengumpulkan banyak jenis tabel dimensi, bahkan di luar yang baru saja kita bahas. Bagaimana dengan bisnis dan industri Anda? Jika Anda telah menggabungkan jenis tabel dimensi menjadi sesuatu yang baru, beri tahu kami tentangnya!


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Solusi pembaca untuk tantangan Kepulauan Khusus

  2. Mengapa Menggunakan Tes Unit adalah Investasi Besar untuk Arsitektur Berkualitas Tinggi

  3. Ketik dengan Kuat Parameter Bernilai Tabel itu

  4. Notasi Kaki Gagak

  5. Pernyataan SQL WHERE