TransliteRickSherman BusinessIntelligenceGuidebook - FromDataIntegrationtoAnalytics MorganKaufmann2014r1191 229.en - Id

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/344614112
Translite Rick Sherman - Business Intelligence Guidebook From Data

Integration to Analytics-Morgan Kaufmann (2014)r (1)[191-229].en.id
Book · September 2001
CITATIONS READS
0 421
1 author:
Gabriela Saratu
Universitas Pembanguan Nasional "Veteran" Jakarta
1 PUBLICATION 0 CITATIONS
SEE PROFILE
All content following this page was uploaded by Gabriela Saratu on 12 October 2020.
The user has requested enhancement of the downloaded file.

CH APTER 9
PEMODELAN DIMENSI
INFORMASI DALAM BAB INI:
• Pemodelan dimensi
• Fakta
• Dimensi hierarki dan kunci Skema

•
• ER vs. pemodelan dimensi
• Tujuan dimensi
• Tabel fakta
• Konsistensi dan kesesuaian
• Dimensi dan fakta lanjutan
PENGANTAR PEMODELAN DIMENSI

Seperti pemodelan hubungan perusahaan (ER), pemodelan dimensi adalah teknik desain logis. Pemodelan dimensi jauh lebih
cocok untuk aplikasi business intelligence (BI) dan data warehousing (DW). Ini menggambarkan proses bisnis di seluruh
perusahaan dan mengatur data itu dan strukturnya dengan cara yang logis. Tujuan dari pemodelan dimensi adalah untuk
mengaktifkan pelaporan, kueri, dan analisis BI. Model normalisasi dimensional hybrid paling baik untuk mendukung permintaan
integrasi DW.
Konsep utama dalam pemodelan dimensi adalah fakta, dimensi, dan atribut. Ada berbagai jenis fakta, bergantung pada apakah
mereka dapat ditambahkan bersama. Dimensi dapat memiliki hierarki yang berbeda, dan memiliki atribut yang menentukan siapa, apa, di
mana, dan mengapa model dimensi. Butir, atau tingkat granularitas, adalah konsep kunci lainnya dengan pemodelan dimensi, karena ia
menentukan tingkat detail.
Fakta, dimensi, dan atribut dapat diatur dalam beberapa cara, yang disebut skema. Pilihan skema bergantung pada
variabel seperti jenis pelaporan yang perlu difasilitasi oleh model dan jenis alat BI yang digunakan. Membangun model
dimensi mencakup potongan puzzle tambahan seperti kalender dan dimensi waktu, dan potongan yang lebih rumit seperti
dimensi degeneratif dan tabel fakta gabungan.
Selain menjelaskan konsep tersebut, bab ini akan membandingkan pendekatan antara model ER dan model
dimensional.
Lihat situs web buku itu www.BIguidebook.com untuk template pemodelan data.
Buku Panduan Business Intelligence. http://dx.doi.org/10.1016/B978-0-12-411461-6.00009-5

197
Hak Cipta © 2015 Elsevier Inc. Semua hak dilindungi undang-undang.
198 BAB 9 PEMODELAN DIMENSI
PEMANDANGAN TINGKAT TINGGI DARI MODEL DIMENSI

Seperti yang ditunjukkan pada Gambar 9.1 , ada dua entitas kunci dalam model dimensi: fakta (ukuran) dan dimensi (konteks). Contoh
menunjukkan elemen-elemen ini:
• Faktanya Tbl_Fact_Store_Sales merupakan inti dari model dimensi.

• Empat dimensi sekeliling yang menentukan dan memasukkan ke dalam konteks penjualan toko:
• Di pojok kanan atas adalah item Tbl_Dim_Item, itulah produk yang dijual.
• Di bawah itu adalah tanggalnya, Tbl_Dim_Date, yaitu saat produk tersebut dijual. Di pojok kiri bawah adalah
• pelanggan, Tbl_Dim_Customer, siapa yang membeli produk. Di pojok kiri atas adalah pembeli, Tbl_Dim_Buyer,
• yang membeli produk untuk toko.
Di konteksnya, contoh menunjukkan bahwa ketika seseorang membeli produk, kita dapat menggunakan model ini untuk menangkapnya
informasi tentang proses bisnis itu. Detailnya akan dibahas lebih detail di bagian berikut.
GAMBAR 9.1
Tinjauan pemodelan dimensi.
FAKTA
Fakta adalah ukuran aktivitas bisnis, seperti peristiwa atau transaksi bisnis, dan umumnya numerik. Contoh fakta adalah
penjualan, pengeluaran, dan tingkat persediaan. Pengukuran numerik dapat mencakup hitungan, jumlah dolar, persentase,
atau rasio.
Fakta bisa dikumpulkan atau diturunkan. Misalnya, Anda dapat menjumlahkan total pendapatan atau menghitung
profitabilitas sekumpulan transaksi penjualan. Fakta memberikan ukuran tentang seberapa baik atau seberapa buruk
kinerja bisnis. Fakta juga disebut sebagai ukuran kinerja organisasi.
Tabel fakta dinormalisasi dan mengandung sedikit redundansi. Hitungan catatan tabel fakta bisa menjadi sangat besar. Sembilan puluh
persen data dalam model dimensi biasanya terletak di tabel fakta. Kekhawatiran desain pemodelan dimensi utama ketika bekerja dengan data
dalam tabel fakta adalah bagaimana meminimalkan dan menstandarkannya dan membuatnya konsisten.
FActS 199
KUNCI TABEL FAKTA
Tabel fakta terdiri dari dua jenis kolom: kunci dan ukuran. Yang pertama, kolom kunci, terdiri dari sekelompok kunci asing
(FK) yang menunjuk ke kunci utama tabel dimensi yang terkait dengan tabel fakta ini untuk memungkinkan analisis bisnis.
Hubungan antara tabel fakta dan dimensi adalah satu-ke-banyak, seperti yang dijelaskan di bagian pemodelan ER pada
Bab 8.
Gambar 9.2 menunjukkan kolom kunci dalam tabel fakta penjualan ( Fact_OnlineSales):
• DateKey —Tanggal dan waktu pembelian dilakukan

• StoreKey —Toko online tempat pembelian dilakukan
• Kunci produk —Produk yang telah dibeli
• CustomerKey —Pelanggan yang melakukan pembelian
• PromotionKey -Promosi penjualan
• CurrencyKey —Mata uang yang digunakan untuk melakukan pembelian
Kunci utama tabel fakta biasanya berupa kunci multi bagian yang terdiri dari kombinasi kunci asing yang dapat mengidentifikasi
baris tabel fakta secara unik. Kunci ini juga dapat disebut sebagai kunci gabungan atau gabungan. Kunci multi bagian mungkin
merupakan bagian dari kunci asing seperti dalam contoh kami:
DateKey, StoreKey, ProductKey, dan CustomerKey dapat mengidentifikasi setiap baris secara unik dalam tabel fakta penjualan.
GAMBAR 9.2
Tabel fakta — kunci.

GAMBAR 9.3
Tabel fakta — kunci utama dengan dimensi degeneratif.
Anda memiliki dua alternatif jika tidak ada kombinasi kunci asing yang menciptakan keunikan yang diperlukan untuk membuat
kunci utama:
• Pertama, sistem operasional yang mencatat transaksi bisnis atau peristiwa yang digunakan untuk mengisi tabel fakta biasanya
membuat pengidentifikasi unik yang terkait dengan transaksi tersebut. Contoh pengenal ini adalah nomor pesanan penjualan,
nomor faktur, dan nomor pelacakan pengiriman. Pengenal ini disebut dimensi degeneratif dan dibahas nanti dalam bab ini. Jika
menggabungkan pengenal ini dengan subset dari kunci asing menciptakan keunikan, maka kunci multi bagian ini akan menjadi
kunci utama. Gambar 9.3 mengilustrasikan jenis kunci utama ini dengan kolom DateKey, StoreKey, ProductKey, dan CustomerKey dipasangkan
dengan SalesOrderNumber menjadi kunci utama.
• Kedua, jika Anda tidak dapat mengidentifikasi baris unik dengan salah satu metode yang dibahas sejauh ini, buat kunci utama
berdasarkan kunci pengganti. Kunci pengganti, yang sering dibuat oleh sistem database menggunakan file IDENTITAS tipe data, adalah
integer yang nilainya tidak berarti. Gambar 9.4 menggambarkan pendekatan ini. Itu OnlineSalesKey kolom adalah kunci pengganti
yang dibuat sebagai kunci utama. Praktik terbaiknya adalah mengindeks setiap kunci asing dalam tabel fakta karena ini akan
mempercepat kinerja kueri dengan meningkatkan gabungan dan filter.
Salah satu praktik terbaik utama yang perlu Anda terapkan adalah bahwa kunci asing tidak boleh nol. Melakukan analisis
memerlukan penggabungan berbagai dimensi ke tabel fakta, dan Anda harus memiliki nilai kunci asing untuk menjamin hasil bisnis
yang valid. Masing-masing kunci asing menunjuk kembali ke a
FActS 201
GAMBAR 9.4
Tabel fakta — kunci utama adalah kunci pengganti.
dimensi yang sesuai, yang memberikan atribut yang relevan dengan peristiwa penjualan internet seperti siapa pelanggan, di
mana dia tinggal, usianya, dan atribut demografis lainnya.
TABEL FAKTA
Jenis kolom kedua dalam tabel fakta adalah ukuran aktual dari aktivitas bisnis seperti pendapatan penjualan dan kuantitas
pesanan. Setiap pengukuran memiliki grain, yaitu tingkat kerincian dalam pengukuran suatu peristiwa seperti satuan ukuran,
mata uang yang digunakan, atau saldo akhir harian suatu akun. Misalnya, butir mata uang bisa menjadi jumlah dolar, atau lebih
terperinci dan menyertakan sen. Perincian ditentukan oleh sumber datanya.
Bagian yang dilingkari dalam Gambar 9.5 menunjukkan beberapa ukuran penjualan internet: SalesQuantity, SalesAmount,
ReturnAmount, ReturnQuantity, DiscountAmount, DiscountQuantity, dan Total biaya
yang berlaku bagi pelanggan untuk produk yang dibeli pada waktu tertentu. Semua tindakan ini terkait dengan peristiwa bisnis
(penjualan) yang diwakili oleh fakta dan memiliki tingkat perincian terkait dengan peristiwa tersebut.
Saat membuat dan menentukan kolom dan ukuran, pastikan bahwa semua baris memiliki satu grain yang seragam.
Dengan kata lain, mereka harus relevan. Jika contohnya adalah membeli produk, Anda harus memiliki ukuran yang relevan
dengan pembelian tersebut agar kueri dan laporan masuk akal bagi pelaku bisnis. Dalam contoh ini, tabel fakta harus memiliki
biaya total daripada biaya satuan
GAMBAR 9.5
Tabel fakta — perincian.
membandingkannya dengan kuantitas penjualan dan jumlah penjualan; jika tidak, rasio bisnis dan pesanan gabungan akan menghasilkan ukuran yang
salah.
Ini merupakan praktik terbaik yang diterima untuk menyimpan biji-bijian terendah, atau paling detail yang ditangkap dalam proses bisnis. Di Gambar
9.5 , ini akan menyimpan detail tingkat baris pesanan daripada detail header pesanan yang diringkas. Secara historis, data warehousing dan business
intelligence menggunakan data ringkasan, sehingga kueri dan laporan kurang mendetail. Praktik itu didasarkan pada infrastruktur dan keterbatasan
pemrosesan yang tidak lagi berlaku. Sekarang, ini adalah praktik yang mapan untuk menyimpan pada tingkat detail transaksi terendah yang tersedia
dari sistem transaksional atau operasional. Ini memungkinkan paling banyak fleksibilitas, karena begitu Anda meringkas sesuatu, Anda kehilangan
detailnya, membuat data menjadi kurang berguna. Granularitas memungkinkan ekstensibilitas; memiliki tingkat detail terendah memungkinkan Anda
untuk mengumpulkan dan memanipulasi fakta atau ukuran.
JENIS FAKTA
Setelah Anda menentukan ukuran dan tingkat butirnya dalam fakta, Anda perlu menentukan atribut numerik dari
jenis ukuran yang disimpan dalam fakta. Ada tiga jenis ukuran: aditif, semiaditif, dan nonadditif.
Fakta Aditif
Fakta aditif adalah yang paling mudah untuk didefinisikan dan dikelola. Ini hanyalah ukuran tabel fakta yang dapat ditambahkan ke
semua dimensi. Contoh paling sederhana dari fakta aditif adalah jumlah item Anda
UKURAN 203
dibeli di toko online — seperti jumlah buku. Tindakan aditif memungkinkan fakta untuk digabungkan dengan semua dimensi yang
berlaku, yang dalam contoh kita adalah pelanggan, toko, produk, dan tanggal.
Fakta Semiaditif
Fakta semiaditif adalah ukuran dalam tabel fakta yang dapat ditambahkan ke beberapa dimensi tetapi tidak yang lain. Contoh dari
pengukuran ini adalah saldo rekening bank, jumlah siswa yang menghadiri kelas, atau tingkat persediaan. Anda tidak bisa begitu
saja menambahkan saldo akun 12 bulan dan mendapatkan berapa banyak uang yang dimiliki seseorang di rekening bank. Dalam
kasus ini, Anda akan menghitung rata-rata saldo tersebut selama 12 bulan. Namun, pada saat mereka diukur (di akhir bulan), Anda
dapat menambahkan saldo akun semua pelanggan Anda dan mendapatkan total saldo akun pada saat itu.
Fakta Nonadditif
Fakta nonadditif adalah ukuran dalam tabel fakta yang tidak dapat ditambahkan di semua dimensi. Contohnya termasuk harga
unit, rasio, dan suhu; meskipun itu adalah angka, mereka tidak seharusnya ditambahkan. Dalam contoh kehidupan nyata, klien
saya mengambil sampel ketinggian air dalam keadaan tertentu, dan rasio dan ketinggian air tersebut tidak bisa ditambahkan
begitu saja. Mereka harus melihatnya dari sudut pandang ilmiah. Fakta nonadditif tidak dapat ditambahkan seperti kueri SQL
biasa yang hanya dijumlahkan di kolom.
Penting untuk memahami konsep fakta aditif, semiaditif, dan nonaditif karena menggabungkan atau meringkas data adalah bagian
besar dari pelaporan dan analisis. Itu salah satu manfaat utama menggunakan model dimensi, dan salah satu hal yang paling sering
digunakan. Setelah Anda menentukan ukuran dan menentukan apakah itu fakta aditif, nonaditif, atau semiaditif, Anda perlu menetapkan
bagaimana mereka dapat dianalisis di BI. Merupakan tanggung jawab tim BI untuk memastikan bahwa pelaku bisnis yang melakukan
analisis mengetahui jenis ukuran yang mereka akses untuk mencegah risiko penggunaan data secara tidak tepat.
UKURAN
Dimensi adalah entitas yang menetapkan konteks bisnis untuk ukuran (fakta) yang digunakan oleh suatu perusahaan. Dimensi
menentukan siapa, apa, di mana, dan mengapa model dimensi, dan mengelompokkan atribut serupa ke dalam kategori atau bidang
subjek. Contoh dimensi adalah produk, geografi, pelanggan, karyawan, dan waktu. Fakta bersifat numerik, sedangkan dimensi
bersifat deskriptif (meskipun beberapa deskripsi tersebut, seperti harga jual produk, mungkin berupa numerik). Membuat dimensi
memungkinkan fakta menyimpan atribut di satu tempat, daripada mengalikannya secara berlebihan di seluruh baris tabel fakta. Cara
mereka terhubung adalah melalui kunci asing di tabel fakta, yang menghubungkan kembali ke tabel dimensi. Ini adalah tingkat
normalisasi — ini menghilangkan redundansi.
Manfaat lain dari dimensi adalah bahwa selain menghemat ruang penyimpanan dan mengurangi bandwidth untuk berulang kali memindahkan
atribut tersebut ke seluruh jaringan, ini memungkinkan atribut dimensional berubah tanpa harus mengubah fakta yang mendasarinya — menghindari
pemrosesan yang berpotensi rumit dan memakan waktu.
Dimensi menjaga database agar tidak dibanjiri dengan data yang berlebihan. Dengan semua atribut dalam tabel dimensi, atribut
tersebut tidak harus diulangi dalam tabel fakta. Ambil Amazon, misalnya. Data untuk penjualan individu akan berisi nomor identifikasi
produk, tetapi tidak akan mengulangi semua atribut produk (warna, deskripsi, ulasan, dll.). Atribut tersebut berada dalam sebuah
dimensi, dan setiap penjualan individu produk tersebut hanya mengarah ke atribut tersebut.
Dari perspektif bisnis, tujuan utama dimensi itu menggunakan atribut mereka untuk memfilter dan menganalisis data
berdasarkan ukuran kinerja. Di Gambar 9.6 , dimensi adalah produk, DimProduct,
dengan atributnya meliputi nama, berat, ukuran, warna, dan harga jual. Ketika dimensi produk digabungkan dengan tabel fakta penjualan,
seorang pelaku bisnis dapat memeriksa penjualan berdasarkan satu atau beberapa atribut produk spesifik ini, seperti menganalisis penjualan
menurut warna atau ukuran.
GAMBAR 9.6
Dimensi — contoh dasar.
Agar berguna dalam analisis, atribut dimensi memerlukan karakteristik utama berikut:
• Deskriptif agar pelaku bisnis dan perancang aplikasi BI dapat memahaminya.

• Lengkap, tanpa nilai yang hilang.
• Unik, karena nilai-nilai yang dapat diidentifikasi secara unik sangat penting.
• Valid, sehingga datanya berguna untuk bisnis.
HIERARKI DIMENSI
Aspek lain dari konteks bisnis yang diciptakan oleh dimensi adalah bahwa mereka seringkali hierarkis; mereka mengelompokkan
berbagai hal bersama dengan cara yang akan diukur oleh perusahaan itu sendiri. Hierarki ini mewakili hubungan banyak-ke-satu. Contoh
hierarki meliputi:
• Struktur organisasi, seperti organisasi pemasaran atau penjualan.

• Kategori produk atau layanan.
• Pengelompokan geografis seperti wilayah penjualan.
• Waktu. Tahun dipecah menjadi seperempat, bulan, minggu, jam, hari, menit, terus ke detik. Ini adalah hierarki
klasik.
Gambar 9.7 menunjukkan dimensi geografi DimGeografi dengan atribut yang menentukan hierarki. Tingkat hierarki tertinggi adalah
negara atau wilayah ( CountryRegionCode) yang kemudian dipecah menjadi negara bagian atau provinsi ( StateProvinceCode), kemudian
dipecah menjadi kota, dan akhirnya menjadi kode pos.
UKURAN 205
GAMBAR 9.7
Hierarki dimensi.
Contoh ini berfungsi untuk Amerika Serikat dan Kanada, tetapi mungkin perlu dimodifikasi untuk negara lain.
Contoh geografi memperlihatkan hierarki dan bagaimana, menggunakan terminologi BI, Anda dapat menelusuri ke atas dan ke bawah dan ke
seberang. Misalnya, Anda dapat melihat penjualan di tingkat negara atau menelusuri ke tingkat negara bagian, tingkat kota, dan terakhir ke kode pos.
Ini memungkinkan Anda untuk menggabungkan data. Anda akan menggunakan SQL "Kelompokkan Menurut" misalnya, jika data diatur dengan benar
untuk mengelompokkan data dengan kolom atau atribut tertentu dalam hierarki itu dan untuk menjumlahkan data dengan tepat. Penjumlahan itu akan
menggunakan fakta atau ukuran aditif.
KUNCI DIMENSI DAN KUNCI PENGGANTI

Konsep utama dalam membangun dimensi adalah bahwa setiap baris tabel dimensi itu unik. Dalam tabel dimensi, kunci utama adalah satu
bidang dibandingkan dengan fakta, yang menggunakan pengelompokan kunci asing sebagai kunci utamanya.
Gambar 9.8 menunjukkan dua dimensi, DimProduct dan DimGeografi. Masing-masing memiliki bidang tunggal, Kunci produk untuk DimProduct dan GeographyKey
untuk DimGeografi yang digunakan sebagai kunci utama untuk masing-masing tabel tersebut.
GAMBAR 9.8
Kunci dimensi.
Kunci Pengganti
Salah satu praktik terbaik untuk memunculkan dimensi adalah menggunakan kunci pengganti sebagai kunci utama seperti yang digambarkan
dalam Gambar 9.8 Kunci pengganti, yang sering dibuat oleh sistem database, adalah bilangan bulat yang nilainya tidak berarti (lihat bagian berikut
tentang kunci pintar untuk penjelasannya). Dimensi tanggal dan waktu merupakan pengecualian untuk kriteria nilai yang tidak berarti, dan akan
dibahas nanti di bab ini.
catatan: jika jumlah baris maksimum dalam tabel lebih dari 2,1 miliar, Anda perlu menggunakan tipe data bigint atau yang
setara, bukan int.
Dalam Bab 8, kita membahas bagaimana proses penunjukan kunci primer untuk pemodelan ER melibatkan pemilihan kunci yang
secara unik mengidentifikasi entitas. Jika ada lebih dari satu kemungkinan mereka disebut kunci kandidat, dan kunci yang tidak dipilih
adalah kunci alternatif. Meskipun sistem transaksional telah membuat kunci utama yang dapat digunakan dalam model dimensi, namun
praktik terbaiknya adalah menetapkan kunci tersebut sebagai kunci alternatif dan sebagai gantinya membuat kunci pengganti sebagai
kunci utama.
Alasan untuk membuat kunci pengganti adalah:
• Saat mengumpulkan data dimensi dari beberapa sistem sumber, sering kali ada kunci utama yang tidak konsisten atau tidak kompatibel
yang digunakan di seluruh sistem ini.
• Kunci utama dari sistem sumber sering berubah seiring waktu dengan konvensi penamaan atau penomoran yang berbeda digunakan pada
waktu yang berbeda. Selain itu, seiring waktu, aplikasi sumber dapat digantikan oleh sistem yang lebih baru, atau penggabungan dapat
menyebabkan kebutuhan untuk mengganti sistem.
• Konsistensi kunci primer dapat dipertahankan oleh sistem sumber untuk periode yang lebih singkat daripada yang ditentukan oleh
kebutuhan analitis perusahaan.
• Sistem sumber mungkin menggunakan tombol pintar.
Praktik terbaik tambahan adalah mempertahankan kunci utama sistem sumber sebagai kunci alternatif dalam dimensi. Ini juga
disebut kunci alami sistem sumber. Jika ada beberapa sistem sumber dengan kunci alami, Anda harus menambahkan atribut yang
mengidentifikasi sistem sumber. Ini menghasilkan kunci alternatif multi bagian untuk mengidentifikasi kunci alami. Di Gambar 9.9 , CustomerSK
adalah kunci utama dalam dimensi pelanggan, PelangganNK adalah kunci alami dalam dimensi dan kunci utama dalam sistem sumber,
SOR_NK adalah indikator SOR (sistem catatan) dan kunci alternatif multi bagian adalah SOR_NK dan
PelangganNK kolom.
Dim_Customers
PK CustomerSK
SOR_NK
U1 PelangganNK
Judul
Nama depan
Nama tengah
Nama keluarga
GAMBAR 9.9
Kunci pengganti dan alami.

UKURAN 207
Tombol Cerdas
Sistem operasional dan transaksional terkadang menentukan atau mengidentifikasi item seperti produk dengan kunci pintar.
Ini adalah string alfanumerik, mungkin sepanjang 24 atau 40 karakter. String karakter biasanya dibagi menjadi beberapa
substring. Substring memiliki arti, oleh karena itu kata kunci pintar. Misalnya, tiga karakter pertama mungkin menunjukkan di
pabrik mana produk itu dibangun. Lima karakter berikutnya mungkin menunjukkan bahan yang digunakan untuk membuat
produk. Sepuluh berikutnya mungkin menunjukkan ukuran atau karakteristik lain dari konstruksi produk, dan seterusnya.
Pada 1990-an dan 2000-an, ketika beberapa sistem operasional dikembangkan, kunci pintar adalah cara untuk memasukkan banyak
kecerdasan ke dalam kunci, terutama karena memori dan penyimpanan yang terbatas. Tapi hari ini intelijen telah bekerja melawan sebagian
besar sistem operasional. Ada dua alasan utama untuk ini:
• Pertama, di sebagian besar sistem operasional, tombol pintar berubah seiring waktu. Substring beserta artinya dan definisinya berubah. Jadi, saat
Anda mencoba mendapatkan gambaran historis tentang kunci pintar tersebut, Anda akan mengalami ketidakkonsistenan yang cukup besar.
• Kedua, karena setiap sistem operasional memiliki definisi arbitrernya sendiri tentang apa arti kunci pintar tersebut, ketika Anda memiliki
perusahaan yang memiliki beberapa sistem operasional (dan banyak perusahaan melakukannya), terdapat ketidakkonsistenan dalam kunci yang
membuatnya sulit untuk mengidentifikasi produk secara unik. di seluruh perusahaan.
Solusi untuk masalah kunci pintar adalah dengan membuat kunci pengganti — kunci tidak berarti yang akan menjadi pengenal yang
konsisten dan unik dalam suatu dimensi.
Bukan Nilai NULL

Kunci asing yang digunakan sebagai kunci utama dalam tabel fakta tidak boleh berisi nilai null. Untuk contoh bagaimana nilai null
ditetapkan, misalkan baris dalam tabel fakta penjualan memiliki nilai null di kolom pengenal pelanggan yang merupakan kunci asing yang
ditautkan ke dimensi pelanggan. Nilai null dimasukkan ke dalam kolom itu ketika, memuat data dari sistem sumber, proses ETL tidak
dapat menemukan pelanggan yang terkait dengan penjualan itu karena nilainya tidak diketahui, hilang atau tidak valid.
Nilai nol membingungkan orang dan alat BI. Jika Anda memahami SQL, Anda tahu bahwa ada perbedaan antara hasil kueri saat
menggabungkan kunci dengan nilai null atau nonnull. Menggunakan contoh kami lagi, gabungan antara fakta penjualan dan dimensi
pelanggan hanya akan menyertakan baris penjualan yang memiliki nilai (bukan nol) di kunci pelanggan. Ini berarti bahwa jika seorang
pebisnis mencoba menganalisis total penjualan, dia akan kehilangan penjualan tersebut dengan kunci pelanggan nol. Kondisi ini jelas
menghasilkan analisis yang menyesatkan yang berpotensi menimbulkan risiko bisnis. Dan kondisi ini bisa diperburuk jika foreign key lain
juga memiliki nulls.
Praktik terbaik yang menangani potensi risiko bisnis ini meliputi:
• Buat baris di setiap dimensi yang digunakan jika nilai dimensi tidak diketahui, hilang, tidak valid, atau kondisi lain di
mana integritas referensial tidak terpenuhi.
• Karena konvensi penomoran untuk kunci pengganti adalah bilangan bulat positif, gunakan bilangan bulat negatif seperti −999 untuk kunci
baris yang “hilang”.
• Baris dimensi memiliki kunci pengganti bersama dengan atribut yang digunakan untuk memberi nama dan mendeskripsikannya. Buat nama dan
deskripsi standar untuk baris ini yang digunakan di semua dimensi, misalnya, "Tidak Ada", "Tidak diketahui", atau "Tidak valid".
• Minimal, tentukan satu baris per tabel dimensi untuk nilai yang hilang, tetapi jika penting untuk dapat mengidentifikasi kondisi
yang berbeda, gunakan beberapa baris. Jika ada beberapa kondisi yang ditangani, gunakan penomoran dan penamaan
standar untuk setiap kondisi ini di semua dimensi.
Ini mungkin tampak sepele, tetapi alat BI, seperti kueri SQL dengan gabungan, akan menghasilkan hasil yang menyesatkan atau tidak akurat jika
ada null dalam kunci asing tabel fakta. Ini memaparkan bisnis pada risiko yang tidak perlu.
Manfaat
Manfaat utama menggunakan kunci pengganti sebagai kunci utama dimensi adalah untuk memberikan pengenal yang konsisten dan unik di
seluruh sistem sumber dan waktu, serta tidak bergantung pada sistem bisnis. Manfaat tambahan dari kunci pengganti adalah, karena berbasis
integer, ini adalah tipe data yang bagus untuk diindeks dan digabungkan dalam model relasional.
Untuk meringkas, dimensi harus memiliki karakteristik sebagai berikut:
• Baris unik
• Kunci pengganti digunakan sebagai kunci utama
• Kunci utama Non-NULL
SKEMA
Anda sekarang telah mempelajari tentang dimensi, fakta, dan atribut. Saatnya menggabungkan potongan-potongan itu dan
mengisi teka-teki model data dimensi. Ada tiga jenis skema untuk membangun model dimensi: skema bintang, skema kepingan
salju, dan skema multidimensi.
Anda memilih skema yang akan digunakan saat membuat model dimensi dengan mempertimbangkan pertanyaan berikut:
• Jenis analisis apa yang Anda coba lakukan pada data itu dan seberapa rumitnya? Apa
• persyaratan dan batasan analitis?
• Seberapa konsisten data yang ingin Anda kueri dan analisis?
• Alat BI apa yang Anda rencanakan untuk digunakan? Meskipun alat yang berbeda mungkin tampak menunjukkan jenis data, hasil, dan grafik yang
sama, keduanya bisa sangat berbeda di bawah sampul, dan bergantung pada skema tertentu untuk hasil terbaik.
SKEMA BINTANG
Skema bintang adalah skema paling umum untuk model dimensi. Ini adalah tabel fakta yang dikelilingi oleh beberapa tabel dimensi, seperti
yang ditunjukkan pada Gambar 9.10 . Contoh menunjukkan fakta, FactInternetSales; contoh ini tentang menjual produk secara online.
Tabel beberapa dimensi untuk fakta ini adalah:
• DimSalesTerritory —Tempat wilayah penjualan berada

• DimPromotions —Promosi apa yang menjual produk
• DimCurrency —Mata uang apa yang digunakan, seperti dolar atau pound
• DimCustomer —Siapa yang membelinya
• DimDate —Ketika itu dijual
• DimProduct —Produk apa yang mereka jual
Skema 209
GAMBAR 9.10
Skema bintang.
Dan, tentu saja, pemfilteran atau pengelompokan berdasarkan atribut dalam tabel dimensi yang berbeda memungkinkan seorang pelaku bisnis untuk
menganalisis siapa yang membeli apa, di mana lokasinya, kapan mereka membeli, dan apakah mereka membeli menggunakan promosi.
Skema bintang adalah kompromi antara model yang dinormalisasi sepenuhnya dan model yang didenormalisasi. Tabel fakta adalah
tempat sebagian besar data yang disimpan dalam model dimensi berada, jadi penting bahwa fakta disimpan dalam tabel yang dinormalisasi.
Normalisasi ini penting untuk redundansi minimal, kemudahan pemeliharaan, dan peningkatan kinerja kueri.
Dimensi, di sisi lain, adalah tabel yang didenormalisasi berisi atribut yang sering tersebar di beberapa tabel jika model data
3NF digunakan. Di Gambar 9.10 , setiap dimensi yang tercantum memiliki atribut deskriptif dalam tabel yang dinormalisasi atau
"diratakan". Bahkan hierarki yang masing-masing levelnya diwakili oleh entitas terpisah dalam model ER diratakan menjadi tabel
satu dimensi dalam skema bintang.
Keuntungan skema bintang adalah bagus untuk kueri, kinerja, dan analitik. Ini mendukung tugas yang biasanya dilakukan oleh
pebisnis saat mereka menggunakan tabel pivot di spreadsheet, jadi sangat intuitif bagi mereka. Mudah bagi para pebisnis untuk
menggunakan dan memiliki kinerja kueri yang cepat karena alat BI dibuat untuk memanfaatkan konstruksi skema bintang.
SKEMA SALJU
Jenis skema dimensi kedua adalah kepingan salju. Dibutuhkan skema bintang, dengan fakta-fakta yang dikelilingi oleh dimensi
yang dinormalisasi, selangkah lebih maju dengan menormalkan hierarki dalam dimensi tertentu. Setiap level dalam hierarki
dimensional menjadi tabel dimensinya sendiri dengan kunci induk yang dibuat untuk menghubungkan struktur hierarki bersama.
Tabel fakta menyimpan kunci asing ke level terendah dari hierarki dimensi.
Gambar 9.11 menggambarkan skema kepingan salju di mana fakta penjualan FactInternetSales, ditautkan ke dimensi produk, DimProduct.
Jika ini adalah skema bintang, faktanya hanya akan menunjuk kembali
GAMBAR 9.11
Skema kepingan salju.

Skema 211
DimProduct, sama seperti tabel pertama di atas Gambar 9.10 . Namun dalam skema kepingan salju, tabel produk dimensional dibagi
menjadi tingkat hierarki produk berikutnya. Bagian-bagiannya meliputi:
• DimProduct, yang merupakan inti atau tingkat terbawah dari hierarki. Jika ini adalah toko sepeda, mungkin ini adalah sepeda khusus, celana
pendek bersepeda, atau botol air yang dijual.
• DimProductSubcategory, tingkat berikutnya, yang mengeluarkan berbagai produk ke dalam subkategori. Untuk toko sepeda, subkategori yang
berhubungan dengan sepeda mungkin berupa jalan raya, gunung, dan hibrida.
• DimProductCategory, level tertinggi dari hierarki. Untuk toko sepeda, kategori tingkat atas dapat berupa sepeda,
pakaian, dan aksesori.
Dalam contoh ini, dimensi produk dalam skema bintang dibagi menjadi tiga tabel yang mewakili tiga tingkat hierarki — produk,
subkategori produk, dan kategori produk dalam skema kepingan salju. Meringkas berdasarkan data produk untuk penjualan internet
akan memerlukan penggabungan tabel fakta penjualan ke setiap tingkat hierarki produk hingga tingkat tertinggi yang diperlukan
untuk peringkasan tercapai.
Pendekatan ini paling sering digunakan dengan dimensi yang memiliki jumlah baris sangat besar dengan hierarki dalam yang
relatif statis. Jika jumlah level dalam hierarki relatif konstan, pengembang lebih memilih jenis model ini, karena lebih dekat dengan
model ER yang digunakan dalam sistem sumber.
Beberapa alat BI dibuat khusus untuk memanfaatkan skema kepingan salju. Alat tersebut menggunakan metadata — definisi tentang
dimensi model kepingan salju — untuk menghasilkan laporan dan kueri. Namun, sebagian besar alat BI akan meminta pengembang BI
untuk "meratakan" hierarki (lihat Bab 14).
Meskipun pengembang lebih memilih skema kepingan salju karena lebih mudah dirancang, para pebisnis merasa lebih sulit untuk
digunakan dalam analisis. Karena alasan ini, praktik tersebut umumnya tidak dianjurkan dalam domain pemodelan dimensi. Tetapi masih
digunakan karena keunggulan dan kecepatan yang ditawarkannya dengan produk BI tertentu. Bab 10 akan membahas alasan mengapa itu
digunakan.
SKEMA MULTIDIMENSI
Model dimensi ketiga adalah skema multidimensi. Ini adalah database hierarki yang terdiri dari satu struktur, array multidimensi.
Untuk membantu memahami skema multidimensi, konseptualisasikan sebagai tabel pivot spreadsheet, yang merupakan perkiraan
dari kubus multidimensi. Ini berisi semua data rinci dan diringkas di berbagai tingkatan dalam sebuah array. Ini seperti Kubus Rubik
besar, ® seperti yang ditunjukkan pada Gambar 9.12 .
Contoh ini menunjukkan fakta penjualan dengan dimensi untuk produk, tanggal, dan geografi; Ada banyak dimensi tambahan
di "sisi" kubus lainnya. Setiap sel kubus adalah ukuran sebenarnya. Bergantung pada data apa yang dibutuhkan seseorang untuk
masuk ke dalam kubus itu, kombinasi dari berbagai dimensi akan membawanya ke sel dengan data yang mereka butuhkan dalam
larik multidimensi tersebut. Atribut dan hierarki dimensi ditentukan dalam metadata produk multidimensi.
Skema bintang dan kepingan salju secara tradisional disimpan dalam basis data relasional (lihat Bab 7 untuk pembahasan
opsi lain), sedangkan skema multidimensi disimpan dalam basis data multidimensi, juga disebut kubus pemrosesan analitik
online (OLAP). Sedangkan database relasional menggunakan SQL dan standar struktural tertentu — tabel, kolom, kunci asing
— struktur database multidimensi sangat bervariasi dan merupakan hak milik. Database multidimensi menyimpan dan
menggabungkan data di berbagai level dalam hierarki. Mereka memungkinkan menelusuri dan menelusuri ke bawah, yang
berarti Anda dapat mulai dari tingkat terendah atau paling detail, hingga meringkas data, lalu mundur lagi melalui hierarki.
Database ini secara khusus dirancang untuk memahami array multidimensi, file
GAMBAR 9.12
Skema multidimensi.
hierarki, apa yang bisa ditambahkan, apa yang semiaditif, dan apa yang bukan aditif dalam kubus. Sama seperti tabel, kolom,
batasan, dan sebagainya yang perlu didefinisikan untuk database relasional, fakta, dimensi, hierarki, dan sebagainya perlu
didefinisikan dalam repositori metadata database multidimensi.
MODEL BINTANG GANDA

Contoh model dimensi, baik bintang, kepingan salju, atau multidimensi, biasanya menggambarkan model tersebut dengan tabel fakta tunggal yang
dikelilingi oleh dimensi. Meskipun ini adalah ilustrasi populer dan pendekatan hebat yang menyederhanakan penjelasan, kenyataannya adalah
bahwa data dalam suatu perusahaan memerlukan banyak fakta. Contoh fakta adalah penjualan, pengeluaran, inventaris, dan banyak peristiwa
bisnis lain yang terkait dengan menjalankan suatu perusahaan.
Gambar 9.13 menunjukkan dua fakta: penjualan toko dan persediaan toko ( Tbl_Fact_Store_Sales dan Tbl_Fact_
Store_Inventory). Di sisi kanan ada tiga dimensi yang dimiliki oleh kedua fakta: dimensi item,
GAMBAR 9.13
Model bintang multifakta.

ENTIty RELAtIONShIp vERSuS DIMENSIONAL MODELING 213
dimensi tanggal, dan dimensi pembeli. Dimensi bersama disebut sebagai dimensi yang sesuai, konsep yang dibahas
nanti dalam bab ini.
Di sisi kiri contoh adalah dimensi pelanggan dan toko yang tidak dibagi di antara dua fakta. Itu Tbl_Dim_Customer berhubungan
dengan Tbl_Fact_Store_Sales, sedangkan Tbl_Dim_Store berhubungan dengan Tbl_Fact_Store_Inventory.
Dalam contoh dunia nyata mungkin ada ratusan atau ribuan tabel dengan banyak kombinasi dimensi berbeda yang berbagi
berbagai kombinasi fakta. Meskipun model menjadi rumit, hal ini membantu untuk memvisualisasikan subset model data sebagai
bintang untuk lebih memahami dan memvalidasi model.
HUBUNGAN ENTITAS VERSUS DIMENSIONAL MODELING

ER dan model dimensional keduanya menggambarkan proses bisnis yang sama, tetapi sebagai Gambar 9.14 menunjukkan, model ER memiliki entitas
dan hubungan yang jauh lebih banyak daripada model dimensional. (Anda tidak diharapkan dapat melihat detail dalam contoh, ini hanya untuk
menunjukkan, pada tingkat tinggi, perbedaan dalam kompleksitas.) Anda telah melihat perbandingan serupa antara ER dan pemodelan dimensional
pada bab sebelumnya: Gambar 8.3 .
Dalam model dimensi, dimensi didenormalisasi dan fakta dinormalisasi. Lebih lanjut, dalam model dimensional hanya sebagian
fakta yang dipilih dari sistem operasional berdasarkan kebutuhan analitis dan untuk mengurangi kompleksitas. Model dimensional
jelas lebih sederhana, lebih mudah dinavigasi, dan lebih mudah dimengerti daripada model ER.
Penting untuk dicatat bahwa sebagian besar sistem operasional saat ini dibeli, sedangkan sebagian besar sistem analitik dibuat khusus
oleh kelompok teknologi informasi. Jadi, sebagian besar kelompok teknologi informasi akan akrab dengan, atau akan menggunakan
pendekatan pemodelan dimensi sebagai lawan dari pendekatan model ER.
PERBANDINGAN PENDEKATAN
Pemodelan ER, kadang-kadang disebut sebagai pemodelan yang dinormalisasi, adalah standar untuk sistem transaksional (juga disebut
sistem pemrosesan transaksi operasional atau online (OLTP)). Pemodelan dimensi adalah praktik terbaik untuk sistem BI dan OLAP.
Alasannya berasal dari bagaimana kedua sistem memproses dan memanipulasi data.
Data dalam sistem operasional terus diperbarui. Pekerjaan utama dari pekerja ini adalah throughput transaksi. Mereka harus
memelihara dan memperbarui sejumlah besar record, sehingga mereka harus mampu menangani throughput konsisten dalam jumlah
besar dengan volume besar.
Bandingkan dengan BI dan sistem pelaporan yang umumnya tidak melakukan pemutakhiran data. Sebaliknya, mereka menyalin,
mengekstrak, mengubah, dan memuat dari sistem operasional. Mereka tidak melakukan pembaruan waktu nyata seperti sistem operasional.
Fokusnya bukan pada throughput transaksional setelah data dimuat. Fokusnya adalah pada kinerja kueri, dan mengumpulkan serta
menggabungkan kumpulan data yang besar. Itu operasi yang kritis. Sistem transaksional memperbarui sejumlah kecil catatan data cukup sering,
sedangkan sistem BI mengumpulkan dan menggabungkan kumpulan besar catatan data, tetapi tidak terlalu sering — terkadang dalam rentang
waktu yang besar. Data dari sistem BI kemudian digunakan untuk pembuatan laporan. Lihat Tabel 9.1 untuk ringkasan perbedaannya.
Sistem operasional dan model normalisasi yang menyertainya memiliki redundansi minimal untuk mendukung throughput transaksi yang tinggi.
Indeksnya yang terbatas dan penggunaan ruang penyimpanan yang efisien menghilangkan file
alm
od
els.
ENTIty RELAtIONShIp vERSuS DIMENSIONAL MODELING 215
Tabel 9.1 Membandingkan Operasional dan BI
Sistem Operasional BI dan Analytics
Model yang dinormalisasi adalah standar untuk OLTP Sangat Model dimensi standar untuk BI dan OLAP Umumnya tidak
volatil diperbarui
Throughput transaksi (memperbarui dan memelihara banyak Performa kueri (mengumpulkan dan menggabungkan kumpulan record yang besar)
catatan) sangat penting sangat penting
Karakteristik yang mendukung penggunaan model Karakteristik yang mendukung penggunaan model dimensi:
yang dinormalisasi:
Redundansi minimal (normalisasi) Peningkatan redundansi (denormalisasi)

Penggunaan indeks terbatas Peningkatan penggunaan indeks
Penggunaan ruang penyimpanan yang efisien Peningkatan ruang penyimpanan
Hilangkan data yang tidak konsisten Gabungkan data yang tidak konsisten
Beberapa masalah perawatan Meningkatnya masalah perawatan
kebutuhan data yang konsisten, juga berkontribusi pada throughput transaksi yang cepat. Sistem dapat memperbarui dan memelihara
catatan secara instan.
Di sisi lain, dalam pelaporan BI, banyak terjadi redundansi. Bagaimanapun, gudang dan data mart dan apa pun yang Anda
simpan di sisi pelaporan semuanya adalah salinan data yang awalnya ada di sistem operasional. Sistem BI sangat bergantung pada
indeks dan partisi karena memerlukan lebih banyak ruang penyimpanan untuk pelaporan, sedangkan sistem operasional hanya
memerlukan konsistensi internal — tidak harus konsisten dengan data sistem lain. BI perlu memiliki data yang konsisten yang
dikonsolidasikan dari beberapa sistem operasi, sehingga ketidakkonsistenan tersebut mungkin tidak hanya terjadi pada sistem
individual, tetapi di berbagai sistem. Banyak konstruksi dimensional yang dibuat untuk mendukung informasi yang konsisten.
Karena sistem operasional tidak memiliki redundansi dan penggunaan indeks terbatas, masalah pemeliharaan lebih sedikit. Namun,
sistem BI memiliki lebih banyak masalah pemeliharaan daripada sistem operasional karena menyimpan data dalam periode sejarah yang
panjang, dan data tidak berumur dengan baik.
MENGAPA STRUKTUR ITU PENTING
Pertanyaan penting adalah: mengapa struktur ini penting untuk pemodelan data? Setiap struktur memiliki tujuannya, dan Anda membutuhkan
struktur yang tepat untuk pekerjaan yang ada. Pilihannya sangat bergantung pada cara data digunakan dan jenis data warehousing atau alat
intelijen bisnis. Praktik terbaiknya adalah menggunakan model ER yang dinormalisasi untuk sistem OLTP. Penyimpanan data operasional
sering kali mencerminkan struktur OLTP dan diarahkan untuk pelaporan operasional sistem OLTP.
Aplikasi BI dan penyimpanan data terkait BI, di sisi lain, lebih baik disajikan dengan model data dimensional. Alat BI akan
memberikan kinerja terbaik dengan bintang atau kepingan salju dalam melakukan kueri database relasional. Atau, jika aplikasi BI
adalah model multidimensi, maka Anda perlu memilih alat BI yang tepat yang menggunakan model multidimensi tersebut.
Gambar 9.15 menunjukkan, di sisi ER, subset data yang lebih kecil dengan database toko yang diimplementasikan dalam model ER. Contoh ini
menunjukkan proses bisnis. Di bagian atas contoh, pelanggan melakukan panggilan; panggilan ini memiliki tipe. Panggilan pelanggan itu terkait
dengan pelanggan, yang kemudian berhubungan dengan pelanggan
GAMBAR 9.15
ER versus contoh dimensi.
entitas pesanan, yang kemudian terkait dengan entitas item baris pesanan, yang kemudian terkait dengan tempat item baris itu
dipilih, yang stoknya habis. Kemudian, contoh terkait dengan produsen katalog tempat item tersebut berada. Ini sangat berorientasi
pada proses, dan entitas diperbarui saat aktivitas bisnis berlangsung melalui proses bisnis tertentu.
Di sisi dimensi contoh, subset dari database toko terlihat sangat berbeda dari sisi ER. Di tengahnya, fakta adalah sel
penjualan. Tabel fakta penjualan dan memiliki empat kunci untuk pelanggan, geografi, waktu, dan produk. Jadi jika di sisi
kiri dalam model ER terdapat desain khusus proses dan aplikasi, sisi kanan dengan model dimensional memiliki desain
yang digerakkan oleh data dan area subjek. Model dimensional memiliki lebih sedikit tabel, lebih mudah dipahami, dan
kurang berfokus pada proses.
TUJUAN PEMODELAN DIMENSI

Sekarang setelah Anda memahami mengapa pemodelan dimensi adalah pilihan terbaik untuk BI, penting untuk memahami
tujuannya dan bagaimana kesesuaiannya dengan pelaporan bisnis. Para pelaku bisnis di suatu perusahaan mungkin tidak
akan pernah melihat model data yang sebenarnya, tetapi mereka pasti akan menggunakan laporan atau dashboard yang
dibangun. Jadi, penting bahwa model tersebut dapat membantu menghasilkan pelaporan dan analisis yang jelas dan efektif
yang pada akhirnya akan membantu pelaku bisnis melihat data dan membuat keputusan yang tepat untuk perusahaan.
Pemodelan dimensi cocok untuk menghasilkan jenis informasi yang benar-benar perlu dilihat oleh pebisnis. Penggunaan
bisnis umum untuk model ini menampilkan fakta (ukuran) dan dimensi dalam laporan BI, analisis OLAP, atau spreadsheet.
TUJUAN PEMODELAN DIMENSI 217
PEMETAAN LAPORAN BISNIS

Gambar 9.16 menunjukkan laporan bisnis yang menampilkan karyawan teratas dan toko teratas yang diberi peringkat berdasarkan
pendapatan penjualan. Pendapatan penjualan dari karyawan teratas ditampilkan dalam bentuk tabel dan diagram batang. Pendapatan
penjualan toko teratas ditampilkan dalam bentuk tabel dan diagram lingkaran. Fakta (ukuran) ditampilkan sebagai angka dalam tabel dan
secara grafis sebagai ukuran batang atau irisan pai. Daftar nama karyawan dan toko adalah atribut dari Karyawan dan Toko dimensi,
masing-masing. Meskipun tidak ditampilkan dalam contoh ini, biasanya laporan menyediakan filter yang memungkinkan pelaku bisnis
memilih atribut tertentu dari karyawan atau toko untuk analisis yang lebih detail. Bab 14 membahas opsi desain antarmuka BI.
GAMBAR 9.16
Memetakan ke laporan bisnis.
PEMETAAN KE ANALISIS OLAP ATAU SPREADSHEET

Gambar 9.17 menyediakan tampilan yang akan dilihat pengguna bisnis dengan alat penemuan data, kubus OLAP, atau tabel pivot
spreadsheet. Dimensi ditampilkan sebagai label dan tajuk dalam jenis antarmuka ini. Dalam contoh, dimensi adalah wilayah penjualan,
kategori produk, subkategori produk, dan waktu (tahun fiskal). Bagian utama laporan menunjukkan angka pendapatan penjualan yang
sebenarnya. Contoh tersebut juga menunjukkan, di sebelah kiri di bawah kelompok pengukuran, ukuran atau fakta yang terdaftar, dan di
bawah
GAMBAR 9.17
Memetakan ke analisis OLAp.
bahwa dimensi seperti pelanggan, tanggal, karyawan, produk, dan wilayah penjualan. Aspek visual spreadsheet, tabel
pivot, atau kubus OLAP disiapkan secara khusus untuk memanfaatkan model dimensi.
TABEL FAKTA
Ada tiga jenis tabel fakta dalam pemodelan dimensi: transaksi, periodik, dan fakta pengumpul.
• Tabel fakta transaksi adalah yang paling umum dalam pemodelan dimensi. Mereka merekam acara atau transaksi bisnis, satu catatan
pada satu waktu, dengan semua data yang terkait dengan acara tersebut. Contohnya adalah transaksi penjualan, seperti pembelian
buku di Amazon. Pembelian tersebut dicatat dalam tabel fakta transaksi untuk penjualan.
• Tabel fakta periodik merekam snapshot data untuk waktu tertentu, seperti tingkat persediaan di akhir kuartal atau
saldo akun di akhir bulan. Setiap baris mewakili fakta pada titik waktu tertentu.
• Mengumpulkan tabel fakta menyimpan rekor sepanjang waktu acara, menampilkan aktivitas yang sedang berlangsung. Contoh dari
hal ini, menggunakan pesanan penjualan internet, adalah tempat Anda merekam acara pertama, pesanan, lalu Anda mencatat tanggal
dan acara berikutnya seperti saat pesanan dilakukan,
FAct tAbLES 219
saat transaksi kartu kredit diproses, saat pesanan dikirim, berbagai status selama pengiriman, lalu akhirnya saat dikirimkan ke
pelanggan. Ini disebut dimensi tanggal bermain peran dengan peristiwa yang dirujuk dalam contoh kita sebagai tanggal
pemesanan, tanggal pengiriman, dan tanggal pengiriman.
Tabel 9.2 menunjukkan bahwa masing-masing jenis fakta tersebut memiliki sifat atau karakteristik yang berbeda.
Gandum: Perincian setiap tabel menyoroti perbedaan pertama. Butir paling detail disimpan dalam tabel transaksi, di mana Anda
mendapatkan baris untuk setiap acara bisnis yang terkait dengan fakta tersebut. Periodik memiliki lebih sedikit detail, dengan satu baris
mencakup seluruh periode waktu. Misalnya, alih-alih menampilkan setiap transaksi di rekening bank Anda, ini menunjukkan satu baris yang
terkait dengan saldo akhir bulan atau akhir periode. Terakhir, butiran paling detail dan baris paling sedikit adalah tempat Anda mengumpulkan
fakta. Misalnya, Anda memesan, dan semua tanggal yang terkait dengan data pesanan diminta, diisi, dikirim, dll., Dan semua ditempatkan
pada catatan yang sama. Rekor itu diperbarui dan di tempatnya.
Dimensi tanggal: Dimensi tanggal untuk ketiga fakta ini menunjukkan penurunan yang serupa dalam tingkat perincian saat
berkembang dari tabel transaksi ke tabel akumulasi. Misalnya, tabel transaksi mungkin menunjukkan tanggal penjualan, tabel periodik
mungkin menunjukkan penjualan Q1 karena ini hanya akhir periode, dan akhirnya tabel fakta akumulasi mungkin menunjukkan semua
tanggal dari berbagai tahapan siklus penjualan untuk contoh.
Jumlah dimensi: Jumlah dimensi paling sedikit di transaksi, paling banyak di akumulasi, dan di antaranya di
periodik.
Fakta: Perbedaan fakta, demikian pula, adalah bahwa hal itu didasarkan pada transaksi individu (Anda melakukan setoran ke
rekening koran Anda), seluruh periode waktu (saldo bulanan Anda), atau banyak peristiwa selama masa suatu peristiwa (banyak
langkah terlibat saat mengajukan hipotek dengan bank).
Pengukuran: Dalam tabel transaksi, angkanya selalu aditif — Anda dapat menjumlahkan semua setoran yang Anda buat ke
rekening koran Anda. Secara berkala, mereka semiaditif, atau angka rata-rata. Jadi, bank bisa mengetahui rata-rata saldo 12
bulanan Anda. Dalam tabel akumulasi, angka-angka harus diturunkan. Misalnya, ini akan memperoleh perbedaan waktu antara
tanggal Anda pertama kali menghubungi bank tentang mengajukan hipotek dan saat Anda menandatangani dokumen akhir.
Dimensi dan fakta yang sesuai, dan ukuran database: Ketiga jenis tabel fakta telah sesuai
dimensi dan fakta yang sesuai. Ukuran database adalah yang terbesar untuk tabel transaksi, karena ia perlu menyimpan transaksi dalam jumlah
besar; ukurannya paling kecil untuk diakumulasikan, dan di antaranya untuk tabel periodik.
Tabel 9.2 Perbandingan Jenis Tabel Fakta
Properti Transaksi Berkala Mengumpulkan
Gandum Satu baris per transaksi Satu baris per jangka waktu Satu baris per masa acara
Dimensi tanggal Tingkat granularitas terendah Perincian akhir periode Kelipatan per baris
Jumlah dimensi Rata-rata Paling
Fakta Transaksi terkait Terkait periode Banyak acara berakhir

seumur hidup
Pengukuran Aditif Bukan aditif, rata-rata Perlu diturunkan
Dimensi yang sesuai Iya Iya Iya

Fakta yang sesuai Iya Iya Iya
Ukuran database Terbesar Lebih kecil Terkecil

MENCAPAI KONSISTENSI
Menjaga konsistensi data adalah tema yang berulang di DW dan BI. Bisnis yang membuat keputusan berdasarkan data yang tidak
konsisten cenderung membuat kesalahan yang mahal. Konsistensi data membawa kita pada salah satu perbedaan utama antara
sistem operasional dan DW / BI: bahwa sistem operasional hanya perlu menjaga konsistensi data di dalam dirinya sendiri. Di sisi lain,
lingkungan DW atau BI perlu membuat data konsisten di berbagai sistem operasional, dan juga, terkadang, di luar perusahaan.
DIMENSI MENYESUAIKAN
Kebutuhan akan konsistensi ini membawa kita pada dimensi yang sesuai — dimensi yang konsisten dan sesuai di seluruh
perusahaan. Ini memastikan bahwa setiap fakta yang menautkan, misalnya, ke dimensi pelanggan, akan mendapatkan informasi
pelanggan yang konsisten; semua pelaporan dan analitik konsisten karena dimensi yang sesuai ini.
Ada beberapa istilah terkait dimensi yang digunakan dalam industri saat ini:
• Manajemen data master (MDM) Integrasi data

• pelanggan (CDI) Manajemen informasi produk
• (PIM)
Ada kata kunci lain yang digunakan juga. Semuanya berpusat pada gagasan membuat daftar induk pelanggan, produk,
pemasok, organisasi, lokasi, dan waktu. Semua ini adalah dimensi, dan semuanya termasuk dalam kategori menyesuaikan
dimensi untuk dapat melakukan pelaporan dan analitik.
Anda selalu menentukan dimensi pada tingkat yang paling terperinci atau sedetail mungkin. Terkadang itu disebut sebagai level atom.
Dan setiap dimensi yang sesuai memiliki kunci pengganti sebagai kunci utama, dan setiap baris dalam dimensi itu unik. Jika Anda
menyesuaikan atau membuatnya konsisten, Anda bisa mendapatkan pelaporan yang konsisten.
FAKTA YANG MENYESUAIKAN
Dimensi sesuai yang menyertai adalah fakta yang sesuai. Sesuai dalam konteks ini juga berarti melakukan standarisasi —
mendefinisikan definisi standar untuk fakta, ukuran, atau indikator kinerja utama (KPI). Mendefinisikan fakta, ukuran, atau KPI
berarti mendefinisikan aturan bisnis, rumus atau algoritma, alokasi, filter, dan apa pun yang diperlukan untuk mengubah sepotong
data menjadi informasi yang berguna untuk bisnis. Contohnya termasuk menghitung pendapatan, keuntungan, biaya standar,
harga, margin, dan sebagainya. Semua perhitungan ini dilakukan dalam bisnis setiap hari.
Ada dua jebakan yang harus dihindari dalam hal standarisasi fakta: “kebenaran versi tunggal” dan politik.
Pertama, Anda mungkin pernah mendengar ungkapan "versi kebenaran tunggal" saat mempelajari tentang sistem perencanaan
sumber daya perusahaan (ERP) dan data warehousing. Sangat sederhana untuk memikirkan satu interpretasi dari fakta atau ukuran
atau KPI. Pada tataran operasional yaitu pada tataran yang paling detil dalam menjalankan suatu usaha terdapat tafsir atau definisi
fakta yang berbeda-beda berdasarkan konteks usaha. Jangan bingung dengan mengarang angka atau memiliki interpretasi yang
berbeda karena Anda tidak memahaminya. Mungkin ada angka berbeda untuk pendapatan dan keuntungan jika dihitung
DIMENSI DAN FACT LANJUTAN 221
berbeda di berbagai bagian rantai bisnis, berdasarkan set proses bisnis yang berbeda, dan dibuat untuk grup bisnis yang berbeda.
Tenaga penjualan, grup pemasaran, dan grup manufaktur semuanya menjual, memasarkan, atau membangun produk yang sama, tetapi
berdasarkan posisi Anda dalam siklus bisnis dalam perusahaan, Anda akan melihat penghitungan pendapatan atau laba secara berbeda,
karena begitulah caranya akan ditugaskan atau dialokasikan ke grup bisnis Anda.
Ini berarti Anda tidak akan mendapatkan definisi tunggal dari margin keuntungan; Anda akan mendapatkan definisi
margin laba yang berbeda untuk berbagai proses. Namun, setiap proses perlu memiliki ukuran yang sama di seluruh proses
itu, di situlah konsistensi masuk.
Perangkap kedua yang harus dihindari adalah berpikir bahwa angka terlepas dari politik. Seringkali, orang-orang teknis berpikir bahwa
semua yang perlu mereka ketahui tentang aturan bisnis, rumus, dan algoritme adalah mendapatkan angka dan menuliskannya.
Kenyataannya, bagaimanapun, adalah bahwa ada proses yang memakan waktu untuk membuat semua orang setuju tentang apa ukuran
tersebut di seluruh perusahaan. Jika angka secara historis telah dihitung secara manual di spreadsheet, maka aturan bisnis dan hubungan
perlu didokumentasikan dan digunakan dalam merancang model data. Setelah nomor ada dalam model data dan dibagikan, itu terlihat,
transparan, dan harus disepakati. Luangkan waktu untuk mendokumentasikan pengukuran yang tepat dalam model data Anda.
DIMENSI DAN FAKTA LANJUTAN

Pemodelan dimensi menggunakan banyak konsep, hubungan, dan pendekatan dalam membangun beberapa model bisnis yang sangat
canggih yang mendukung proses bisnis. Beberapa istilah yang digunakan dalam pemodelan dimensi, seperti "degeneratif", dapat terdengar
esoterik dan tidak jelas. Namun, saat Anda mempelajari lebih lanjut tentang pemodelan dimensi lanjutan dan perlu menerapkannya di dunia
nyata, Anda akan melihat betapa pentingnya memahami istilah-istilah ini dan bagaimana penerapannya. Penting untuk disadari bahwa ini
bukan hanya konsep esoterik, tetapi sebenarnya sangat berguna dalam merepresentasikan bisnis dan mendukung pelaporan dan analitik.
TANGGAL (ATAU KALENDER) DIMENSI
Dimensi tanggal bukan hanya praktik terbaik, tetapi juga pekerja keras dalam pemodelan dimensi karena hampir setiap fakta memiliki
setidaknya satu tanggal dan sebagian besar kueri memeriksa ukuran terkait tanggal. Meskipun demikian, banyak orang tidak memahami
perlunya dimensi tanggal. Mari kita mulai dengan mengapa jenis dimensi ini dibuat.
Tanggal tidak semudah yang terlihat karena ada lebih banyak hal yang terjadi di balik layar daripada yang diperkirakan. Ketika
para pebisnis melihat tanggal transaksi penjualan, mereka langsung tahu tahun berapa, kuartal, dan bulan penjualan itu. Mereka juga
akan mengetahui apakah penjualan terjadi pada periode yang ingin mereka analisis, misalnya bulan lalu, kuartal terakhir, atau
membandingkan bulan ini dengan bulan pembanding tahun lalu. Pelaku bisnis melakukan manipulasi substring tanggal dan aritmatika
data tanpa menyadarinya.
Hampir setiap tabel fakta memiliki setidaknya satu atribut yaitu tanggal. Atribut itu dapat disimpan sebagai TANGGAL
tipe data "2004-10-27", lebih umum sebagai a TANGGAL WAKTU tipe data dalam format "2004-10-27 23: 40: 01.918" atau
jarang sebagai string karakter alfanumerik.
Berikut ini adalah beberapa manipulasi, perhitungan, atau aturan bisnis substring tanggal potensial yang perlu diterapkan ke
setiap tanggal di setiap baris untuk hampir setiap kueri atau analisis yang dilakukan di BI:
• Memilih tanggal untuk periode kalender tertentu seperti bulan, kuartal, atau tahun. Ini membutuhkan
berfungsi untuk mengekstrak file TANGGAL substring difilter untuk setiap tanggal yang berlaku di setiap baris dalam tabel fakta
yang diperiksa untuk menentukan apakah ada kecocokan. Dan jika periode lebih rinci dari satu tahun, maka setiap tingkat dalam
hierarki (tahun-seperempat-bulan-hari) di atas periode perlu dimasukkan dalam perbandingan substring.
• Memilih atau membandingkan tanggal dengan tipe data DATETIME tidak sama dengan membandingkan tanggal
dengan tipe data DATE. Banyak tanggal di DW memiliki file TANGGAL WAKTU tipe data karena sistem transaksi mencatat tingkat
detail tersebut saat transaksi terjadi, dan detail tersebut dibawa ke DW. Namun, sebagian besar analisis yang dilakukan
perusahaan adalah TANGGAL- berbasis. SQL mengonversi tanggal "2004-10-27" ke waktu default "2004-10-27 00: 00: 00.000"
sebelum dapat membandingkannya dengan TANGGAL WAKTU tipe data. Ini dilakukan agar mereka bisa cocok; mereka harus memiliki
tipe data yang sama. Jadi, peristiwa "2004-10-27 23: 40: 01.918" tidak akan dipilih sama sekali, yang kemudian membuat data
menjadi salah jika analisis bisnis memilih item dengan TANGGAL. Karena itu, setiap kali berkencan dengan a TANGGAL WAKTU tipe
data dibandingkan, itu perlu diubah menjadi TANGGAL
tipe data.
• Beralih antara tanggal kalender standar dan fiskal jika tanggal tersebut berbeda satu sama lain.
Ada rumus yang didasarkan pada aturan pemerintah yang mengonversi tanggal kalender standar ke kalender fiskal yang digunakan
perusahaan.
• Menetapkan hari libur atau periode waktu yang memiliki arti penting bagi perusahaan biasanya ditentukan dengan membuat tabel
pencarian atau secara manual mengkodekan daftar tanggal dalam laporan atau spreadsheet.
• Memilih periode kalender yang dihitung dengan fungsi tanggal seperti kuartal, minggu dalam tahun
dan hari demi tahun.
Sebelum pengenalan konsep dimensi tanggal dalam pemodelan dimensi, setiap aplikasi BI harus melakukan
operasi tanggal ini setiap kali kueri dilakukan.
Mendesain Dimensi Tanggal

Gambar 9.18 menggambarkan tabel fakta ( Fact_Store_Sales) dengan kunci asing ( Date_SK) menautkan ke dimensi tanggal kalender ( Dim_Date).
Meskipun komposisi dimensi data bervariasi antara perusahaan berdasarkan filter dan judul tanggal untuk laporan yang digunakan
oleh pelaku bisnis, desainnya mengikuti standar dan konvensi desain tertentu.
Dua kolom yang wajib dalam dimensi tanggal adalah kunci utama dan nilai tanggal lengkap. Dalam contoh kami, ini adalah Date_SK
kunci utama (dan pengganti), dan Date_Value nilai tanggal penuh.
Untuk kolom wajib pertama, kunci utama, dimensi tanggal adalah satu-satunya pengecualian untuk aturan pemodelan dimensi bahwa
kunci pengganti tabel dimensi harus berupa bilangan bulat yang tidak berarti. Praktik terbaiknya adalah bahwa kunci pengganti tanggal
adalah bilangan bulat dalam bentuk YYYYMMDD denganYYYY = empat digit tahun (1991), MM = bulan dua digit (03), dan DD dua digit hari
(03) menghasilkan 19910303 dalam contoh ini.
Jika kunci pengganti tidak berarti seperti database IDENTITAS jenis data digunakan, maka kunci yang ditetapkan ke tanggal mana pun
akan bervariasi berdasarkan tanggal mulai yang ditetapkan ke dimensi. Artinya berbeda
GAMBAR 9.18
Dimensi tanggal.
tabel dimensi memiliki nilai berbeda yang ditetapkan ke suatu tanggal, mengakibatkan ketidakkonsistenan. Sebaliknya, menggunakan
konvensiYYYMMDD menjamin bahwa tanggal tertentu memiliki nilai yang sama di setiap tabel dimensi tanggal. Misalnya, 3 Maret 1991,
akan menjadi 19910303 pada setiap tabel dimensi tanggal tidak peduli kapan dibuat atau oleh siapa.
Ada beberapa keuntungan menggunakan kunci pintar ini:
• Itu dipahami secara universal

• Ini sesuai dengan standar pertukaran internasional tanggal dan waktu ISO 8601.
• Yang terpenting, konvensi ini menetapkan konsistensi dimensi tanggal, yang membantu memungkinkan berbagi data di perusahaan.
Kolom wajib kedua, yang memiliki nilai tanggal penuh yang biasanya disimpan di a TANGGAL kolom tipe data, sangat penting
karena digunakan sebagai kolom pencarian dalam proses ETL yang menetapkan kunci asing tanggal tabel fakta. Dalam contoh kami,
proses ETL mencocokkan tanggal penjualan dari data penjualan sistem sumber dengan baris yang sesuai dari dimensi tanggal ( Dim_Date)
dan kemudian memberikan kunci asing ( Date_SK) nilai ke tabel fakta penjualan ( Fact_Store_Sales).
Selain dua kolom wajib, berbagai kolom diisi untuk mengaktifkan pemfilteran, penggabungan, pengelompokan, dan pelabelan
tanggal dalam pelaporan dan analitik. Kolom ini dapat berupa numerik atau alfanumerik berdasarkan kebutuhan bisnis.
Beberapa atribut tanggal umum meliputi:
• Periode kalender berasal dari substring tanggal: tahun, bulan, dan hari.
• Beberapa kolom mewakili variasi dari periode kalender yang sama, seperti nama lengkap bulan "September",
singkatan tiga karakter "Sep," terjemahan Polandia "Wrzesie ń, "Numerik
9, karakter yang setara dengan nomor bulan "09" dan variasi lainnya.
• Periode kalender berasal dari fungsi tanggal: kuartal, nomor minggu dalam tahun, nomor hari dalam tahun, nomor hari dalam bulan,
nomor hari dalam minggu, dll.
• Kolom yang digunakan sebagai bendera yang menunjukkan jika suatu hari adalah hari kerja, akhir pekan, hari libur, dll. Bendera ini akan
bervariasi menurut perusahaan, negara, lini bisnis, dan bahkan di sepanjang tahun untuk liburan "mengambang". Hal ini dapat
mengakibatkan dimensi tanggal khusus negara atau bisnis digunakan saat data dianalisis. Perhatikan bahwa penggunaan dimensi tanggal
spesifik ini di lingkungan BI tidak berdampak pada proses ekstrak, transformasi, dan muat (ETL) yang memuat tabel fakta atau desain tabel
fakta yang mendasarinya. Periode musiman yang khusus untuk perusahaan juga dapat ditandai. Misalnya, perusahaan kartu ucapan
• mungkin menandai musim-musim pembelian kartu utama seperti periode waktu menjelang Hari Ibu, sedangkan perusahaan yang berfokus
pada pertanian seperti peralatan pertanian atau pabrik pupuk akan mengalami musim tanam.
Perusahaan mungkin memiliki dua kalender: standar dan kalender fiskal. Kalender standar akan dimulai pada hari
pertama tahun yang berlaku, seperti 1 Januari di Amerika Serikat. Kalender fiskal diatur untuk tujuan pelaporan
pemerintah dan pajak. Ada aturan khusus yang menentukan parameter spesifik seperti tanggal awal tahun, tanggal mulai
setiap kuartal, dan panjang setiap kuartal. Jika kalender standar dan fiskal berbeda, maka dimensi tanggal akan memiliki
standar dan ekuivalen fiskal dari periode kalender untuk setiap baris tanggal.
Manfaat
Menggunakan dimensi tanggal dalam arsitektur BI Anda memungkinkan penyederhanaan dan konsolidasi. Misalnya, menggunakan dimensi
tanggal berarti hal-hal berikut harus dilakukan hanya sekali:
• Kunci asing pengganti tanggal ditetapkan ke setiap bidang tanggal saat dimuat dari sistem sumber.
• Substring data dan kalkulasi data dilakukan saat dimensi tanggal dimuat.
• Konversi kalender standar dan fiskal dibuat saat dimensi tanggal dimuat.
• Semua pengidentifikasi kalender khusus bisnis seperti hari libur dimasukkan ke dalam dimensi tanggal sebagai tabel pencarian tunggal.
Bandingkan ini dengan laporan BI atau analisis bisnis tanpa dimensi tanggal. Mereka perlu melakukan operasi tanggal yang
sama ini di setiap bidang tanggal di setiap baris dalam kueri setiap kali dilakukan. Operasi tanggal ini mungkin diulang ribuan
atau jutaan kali untuk setiap laporan atau analisis dan tak terhitung jumlahnya di seluruh perusahaan!
Manfaat menggunakan dimensi tanggal juga mencakup yang berikut:
• Kecepatan kueri lebih cepat karena Anda melakukan operasi tanggal sekali saat memuat dimensi tanggal versus waktu yang tak terhitung,
seperti yang dibahas di atas. Meskipun setiap operasi tanggal membutuhkan jumlah waktu yang sedikit, itu menambahkan hingga menjadi lebih
signifikan daripada yang diperkirakan.
• Produktifitas ditingkatkan untuk pebisnis dan staf teknologi informasi yang tidak perlu berulang kali dan secara berlebihan
mengkodekan operasi tanggal ini secara manual ke dalam setiap dasbor BI, laporan, kueri, atau spreadsheet.
• Konsistensi ditingkatkan karena tanggal ditetapkan satu kali dan digunakan di seluruh perusahaan tanpa interpretasi yang berbeda atau
kemungkinan kesalahan.
• Analytics ditingkatkan karena semua atribut dimensi tanggal prebuilt yang akan segera tersedia untuk setiap aplikasi BI untuk
digunakan para pelaku bisnis dalam memfilter, menggabungkan, mengelompokkan, dan memberi label periode kalender.
Sepertinya konsep yang sederhana, tetapi dimensi tanggal adalah salah satu ide dasar dalam pemodelan dimensi yang menghasilkan
keuntungan bisnis dan teknologi yang signifikan.
DIMENSI WAKTU
Sebagian besar analisis bisnis yang dilakukan di perusahaan, seperti analisis periode-ke-periode, tahun-ke-tanggal, atau kuartal-ke-tanggal
hanya melibatkan bagian tanggal dari TANGGAL WAKTU tipe data. Waktu aktual terjadinya penjualan, misalnya, biasanya tidak diperlukan
karena sebagian besar metrik kinerja perusahaan diringkas menurut hari, minggu, kuartal, atau tahun. Contoh analisis kinerja yang
menggunakan waktu dalam sehari mencakup perencanaan kapasitas dan pemanfaatan tenaga kerja, tetapi biasanya data waktu hari tidak
relevan dan sebenarnya dapat membingungkan dan menyesatkan.
Ini mengarah pada dua pendekatan tentang cara menangani waktu dalam sehari.
Waktu sebagai Fakta

Pertama, jika analisis waktu-hari tidak relevan atau hanya dilakukan secara terbatas di perusahaan Anda waktu diperlakukan
sebagai fakta. Untuk setiap tanggal dalam tabel fakta, buat dua kolom. Kolom pertama harus memiliki kunci asing yang ditautkan ke
dimensi tanggal kalender yang akan digunakan dalam analisis bisnis ketika waktu tidak relevan. Kolom kedua harus berisi tanggal
dan waktu. Ada beberapa alasan pragmatis untuk mempertahankan waktu meskipun tampaknya tidak ada kebutuhan analitis bisnis:
• Memungkinkan rekonsiliasi tanggal fakta dengan tanggal sistem transaksional.

• Aktifkan sesekali analisis waktu dengan menggunakan kolom fakta secara langsung
TANGGAL WAKTU. Karena jenis analisis ini jarang dilakukan, maka tidak perlu mengakomodasinya dengan dimensi waktu (pendekatan
lain untuk menangani waktu dalam sehari).
• Jika kondisi berubah dan analisis waktu menjadi persyaratan bisnis, maka memiliki atribut fakta dengan TANGGAL WAKTU memungkinkan
jenis analisis ini dipasang kembali dengan menggunakan pendekatan kedua di bawah ini.
Contoh yang digambarkan dalam Gambar 9.19 menunjukkan FactStoreSales tabel dengan kedua kolom ini. Pertama, kunci asing OrderDateKey
yang tertaut ke dimensi tanggal DimOrderDate. Kedua, Tanggal pemesanan kolom berisi penuh TANGGAL WAKTU data.
Waktu Hari sebagai Dimensi

Dengan pendekatan kedua, waktu diatur sebagai dimensi karena ada kebutuhan bagi bisnis untuk menganalisis ukuran kinerja
berdasarkan waktu. Pendekatan ini menyimpan tiga kolom dalam tabel fakta untuk setiap tanggal yang perlu dianalisis oleh bisnis. Dua
kolom yang dibahas dalam pendekatan waktu-hari lainnya — kunci asing yang ditautkan ke dimensi data dan kolom yang menyimpan
penuh TANGGAL WAKTU - termasuk dalam pendekatan ini. Kolom ketiga adalah kunci asing untuk dimensi waktu, seperti yang ditunjukkan
di Angka
9.20 , yang memperluas contoh sebelumnya dengan menambahkan Order_TimeKey ( foreign key) ditautkan ke Redup_ Waktu ( dimensi waktu.)
GAMBAR 9.19
waktu sebagai fakta.
GAMBAR 9.20
waktu sebagai dimensi.
Pertanyaan awal saat mendesain dimensi waktu adalah tingkat butiran apa yang diperlukan untuk analisis waktu hari:
jam, menit, detik, atau seperseratus detik? Jumlah baris bertambah secara signifikan dengan bertambahnya tingkat detail:
untuk jam 24, menit 1440, dan detik 86.400. Butir dimensi waktu harus berupa apa pun yang diperlukan untuk analisis
waktu-hari dan tidak lebih. Bukan karena database atau alat BI akan kewalahan dengan menyimpan data sampai detik,
tetapi visualisasi dan interaksi dengan alat BI menjadi lebih rumit jika tingkat detail melampaui kebutuhan bisnis.
Kunci utama dimensi waktu adalah kunci pengganti, biasanya dimulai dari nol (0). Ini juga termasuk kolom yang berisi waktu
hari dengan tipe data waktu atau yang setara berdasarkan database yang digunakan. Kolom tambahan akan digunakan untuk
tujuan pemfilteran dan deskriptif dalam analisis. Gambar 9.21
mengilustrasikan dimensi waktu sampel dengan butiran satu jam. Time_SK adalah kunci pengganti, Nilai waktu
adalah kolom nilai waktu-hari dan contoh kolom yang tersisa adalah waktu 12 jam; waktu militer; am atau pm; dan
contoh deskripsi tekstual. Pemilihan kolom deskriptif didasarkan pada kebutuhan analitis bisnis.
GAMBAR 9.21
dimensi waktu — butir jam.
Gambar 9.22 menggambarkan dimensi waktu dengan sebutir menit. Dalam contoh, dimensi waktu memiliki kunci pengganti yang
diperlukan Time_SK dan nilai waktu yang disimpan dalam Nilai waktu. Contoh tersebut memiliki daftar kolom filter dan deskriptif, tetapi
perusahaan perlu membuat kolom yang diperlukan untuk mendukung analisis waktu bisnis yang diperlukan.
Periode waktu
Analisis waktu-hari dilakukan di industri seperti ritel (online dan di toko), restoran, utilitas, telekomunikasi, dan
media (online, kabel, dan radio) ketika memeriksa perilaku konsumen. Contohnya termasuk memeriksa metrik
kinerja yang ada dan dampak kampanye menggunakan waktu.
Seringkali analisis waktu-hari ini dilakukan pada periode waktu berdasarkan rentang waktu tertentu. Misalnya, seperti yang
diilustrasikan dalam Gambar 9.23 , sebuah rantai makanan atau perusahaan media telah membuat skema untuk menganalisis
waktu dalam rentang waktu ini: perjalanan pagi adalah 6: 00–9: 00, larut pagi adalah 9: 00– 11:30, makan siang 11: 30–2: 30,
pulang sekolah pada 14: 30–4: 00 dan perjalanan sore pada 4: 00–7: 00. Meskipun tabel fakta dan dimensi waktu berisi butir ke
detail menit, butir waktu hari adalah periode waktu. Bisnis dalam skenario ini tidak peduli dengan apa yang terjadi tepat pada pukul
6:16 pagi karena tingkat detail tersebut adalah "kebisingan" dan bukan sesuatu yang perlu ditindaklanjuti oleh bisnis.
Ada dua pendekatan untuk mendukung analisis waktu-of-day menggunakan rentang waktu. Pertama, jika menggunakan waktu sebagai dimensi,
tambahkan lebih banyak kolom ke dimensi waktu dengan deskripsi rentang waktu yang sesuai
GAMBAR 9.22
dimensi waktu — butir menit.
GAMBAR 9.23
dimensi waktu dengan rentang waktu.
seperti yang diilustrasikan dalam Gambar 9.23 . Dari perspektif pragmatis, tidak mungkin bahwa pita waktu akan tetap statis atau hanya akan ada satu
cara untuk mengelompokkan periode waktu ke dalam pita, tetapi tabel dimensi memungkinkan perusahaan untuk menambahkan sebanyak mungkin
kolom tambahan yang diperlukan.
Gunakan pendekatan kedua saat mengimplementasikan waktu dalam tabel fakta tanpa dimensi waktu. Dengan pendekatan ini,
buat dimensi pita nilai untuk menentukan asosiasi dengan periode waktu dan waktu.
Salah satu pendekatan lebih disukai daripada mengkode periode waktu secara manual ke dalam setiap aplikasi BI atau kueri SQL yang
dilakukan pada data ini karena pengkodean manual berlebihan, mungkin tidak konsisten, tidak mungkin didokumentasikan, dan tidak mudah
dimodifikasi.
DIMENSI TANGGAL DAN WAKTU DI SELURUH ZONA WAKTU
Jika operasi perusahaan menjangkau beberapa zona waktu, praktik terbaiknya adalah mencatat waktu dalam dua tabel fakta dengan
dua zona waktu berbeda. Pertama kali dilacak adalah dalam zona waktu lokal di mana fakta terjadi, seperti di mana pusat panggilan
berada atau dari mana paket dikirim. Zona waktu kedua sesuai dengan waktu standar global yang digunakan sebagai dasar untuk
menghitung offset. Contoh skema ini digambarkan dalam Gambar 9.24 .
GAMBAR 9.24
zona waktu.
Biasanya, Anda memilih satu dari dua standar global: Greenwich Mean Time (GMT) atau zona waktu lokal kantor pusat
perusahaan. Jika kantor pusat berada di Hong Kong, misalnya, perusahaan dapat mengambilnya sebagai waktu lokal,
menjadikannya sebagai standar global mereka sebagai alternatif dari GMT. Selama semuanya terstandarisasi, tidak masalah
zona waktu berbagai pabrik, cabang, atau kantor berada. Sistem akan mencatat waktu acara lokal dan global, sehingga bisnis
dapat mengoordinasikan pandangannya tentang waktu terjadi.
Alasan bisnis untuk menyatakan waktu dalam dua zona waktu adalah karena dua jenis analisis waktu dalam sehari yang
dilakukan:
• Grup bisnis, yang dapat berupa pusat panggilan dan gudang pengiriman dalam contoh ini, akan memeriksa metrik kinerja mereka
seperti waktu respons dan analisis penyeimbangan sumber daya tenaga kerja dalam konteks zona waktu lokal mereka.
• Manajemen senior perusahaan dan grup bisnis global seperti logistik dan penjualan akan memeriksa metrik kinerja selama periode
24 jam menggunakan zona waktu standar global sebagai dasar untuk analisis yang bermakna.
Pendekatan alternatif, seperti menyimpan indikator zona waktu atau perbedaan jam dari garis dasar seperti GMT, akan bergantung pada kalkulasi
tanggal pengkodean manual dalam aplikasi dan spreadsheet BI untuk mengaktifkan analisis. Pengkodean manual memiliki banyak kelemahan
dibandingkan dengan menggunakan pemfilteran dimensional; ini termasuk waktu yang lebih lama untuk membuat kode atribut, biaya perawatan yang
lebih tinggi, dan ketidakkonsistenan dalam analisis.
DIMENSI BERMAIN PERAN

Ada beberapa contoh ketika tabel fakta mereferensikan dimensi beberapa kali sebagai kunci asing. Contohnya adalah:
• Beberapa tanggal yang terkait dengan peristiwa berbeda seperti pesanan, pengiriman, dan pengiriman disimpan dalam tabel fakta yang
terakumulasi.
• Beberapa kolom terkait alamat mengidentifikasi alamat yang berbeda seperti lokasi pengiriman dan penagihan. Beberapa orang seperti
• pelanggan dan staf penjualan yang terkait dengan fakta penjualan atau seorang karyawan dan manajernya dalam analisis terkait tenaga kerja.
Masing-masing kunci asing ini menghubungkan dimensi yang sama untuk menandakan peran yang berbeda untuk dimensi tersebut. Misalnya,
tanggal dapat menandakan pesanan, pengiriman, atau tanggal pengiriman. Istilah "bermain peran" menggambarkan dimensi fisik yang digunakan dalam
konteks bisnis yang berbeda.
GAMBAR 9.25
Pendekatan dimensi bermain peran.
Meskipun konsep ini mudah dimengerti, ini adalah masalah yang berbeda untuk database relasional; meskipun tabel fakta dapat memiliki
beberapa kolom dengan kunci asing yang ditautkan kembali ke dimensi yang sama, kolom ini tidak dapat digunakan dalam kueri yang sama.
Misalnya, Anda tidak akan dapat menanyakan dimensi tanggal dari tabel penjualan dengan memfilter tanggal pengiriman dan tanggal pengiriman.
Untuk mendukung dimensi bermain peran, perlu ada entitas database yang terkait dengan setiap peran. Ada dua pendekatan
berbeda untuk menciptakan entitas dimensi bermain peran:
• Buat tabel terpisah untuk setiap peran

• Buat tampilan untuk setiap peran menggunakan satu dimensi
Membuat tampilan untuk setiap peran jelas merupakan praktik terbaik. Misalnya, lihat elemen di Gambar 9.25 .
• Dimensi tanggal, Dim_Date. Anda akan menyimpannya sekali, dan itu akan membuat tampilan untuk setiap peran yang diterapkan.
• Fakta penjualan internet, FactInternetSales. Ini memiliki tiga tanggal peran berbeda yang dilaporkan semula Dim_Date. Tampilan yang
ditentukan untuk setiap peran tanggal tersebut adalah:
• tampilan tanggal pesanan dimensi, vDimOrderDate
• dimensi tampilan tanggal jatuh tempo, vDimDueDate
• dimensi tampilan tanggal pengiriman, vDimShipDate
• Singkatnya, kami hanya menyimpan Dim_Date sekali, kami membuat tampilan untuk setiap peran, dan tabel fakta serta kunci asing
kembali ke vDimOrderDate, vDimDueDate, dan vDimShipDate versus aslinya
Dim_Date.
Membuat tampilan menghilangkan pemeliharaan dan pembaruan beberapa tabel fisik, menghemat ruang, dan memungkinkan gabungan
banyak arah yang diperlukan untuk analisis bisnis.
DIMENSI DEGENERATIF
Sistem operasional melacak transaksi dan peristiwa bisnis dengan menggunakan dokumen proses bisnis seperti pesanan pembelian,
faktur, reservasi perjalanan, atau tiket konser. Semua dokumen proses ini memiliki
GAMBAR 9.26
Contoh dimensi degeneratif.
pengenal referensi seperti nomor pesanan, faktur, dan reservasi yang unik dan digunakan sebagai kunci utama untuk entitas
dalam skema operasional pendukungnya.
Gambar 9.26 menggambarkan fakta penjualan pengecer yang mencantumkan kunci asing yang tertaut ke toko ( StoreKey),
karyawan ( EmployeeKey), tanggal pemesanan ( OrderDateKey), dan dimensi lain yang secara unik mengidentifikasi
transaksi. Ada beberapa ukuran seperti kuantitas pesanan dan jumlah penjualan. Ada dua atribut CustomerPONumber dan CarrierTrackingNu
yang mewakili pengidentifikasi unik untuk pesanan pembelian pelanggan dan nomor pelacakan operator untuk penjualan.
Dalam sistem operasi, atribut ini akan menjadi kunci asing untuk entitas terkait operasional, tetapi dalam model dimensi
atribut ini tidak akan ditautkan ke dimensi mana pun. Dalam model dimensi, tidak akan ada persyaratan untuk dimensi ini
karena atribut yang terkait dengan entitas ini dalam sistem operasi sudah disimpan di dimensi lain. Misalnya, pesanan
pembelian akan memiliki atribut buatan pelanggan yang akan disimpan di dimensi pelanggan dan terkait alamat.
Atribut ini pada dasarnya adalah kunci asing yang tidak ditautkan ke dimensi mana pun dan disebut sebagai dimensi degeneratif.
Konsep ini sering menimbulkan kebingungan, tetapi sebenarnya hanya dimensi yang atributnya ada di tempat lain. Meskipun Anda
tergoda untuk membuat dimensi untuk setiap atribut ini, informasi ini akan menjadi redundan dengan dimensi lain. Memisahkan,
misalnya, nomor pelacakan operator atau nomor pesanan pembelian pelanggan dalam contoh kami menggambarkan duplikasi, karena
atribut yang sama akan disimpan dalam fakta penjualan pengecer dan dalam dimensi pesanan pembelian.
Jadi, adakah kasus di mana Anda akan mereplikasi data itu? Jawabannya adalah Anda tidak mau. Praktik terbaiknya adalah tidak
menjadikan ini sebagai dimensi terpisah, menempatkannya di tabel transaksi setelah dimensi
kunci asing, dan sebelum atribut numerik. Contoh dari Fact_ResellerSales menunjukkan dua kunci asing yang merupakan kunci utama
dari nomor pesanan penjualan dan nomor item baris; kami kemudian memiliki serangkaian kunci asing yang menunjuk ke berbagai
dimensi.
Contoh ini menunjukkan dua dimensi degeneratif — nomor pelacakan operator dan nomor PO pelanggan — diikuti oleh ukuran
sebenarnya yang terkait dengan penjualan internet. Sadarilah bahwa dimensi degeneratif ini bukanlah bilangan aditif; mereka hanyalah
pengidentifikasi yang digunakan untuk proses bisnis yang tidak kami lacak dalam model dimensi ini. Tetapi, kami mempertahankan
angka-angka ini karena ini adalah tautan kembali ke sistem operasional, dan jika kami ingin mengaudit hasil kami atau mengikatnya
kembali, kami perlu memiliki angka-angka ini. Dan, beberapa pebisnis, daripada menanyakan, misalnya, nomor pesanan penjualan,
mungkin sebenarnya menanyakan nomor PO pelanggan. Dimensi degeneratif memungkinkan kueri semacam itu.
TABEL ACARA
Fakta hampir selalu memiliki ukuran, tetapi ada pengecualian. Pengecualian ini terjadi saat peristiwa bisnis tidak membuat atau
memantau tindakan yang dapat diukur. Fakta-fakta ini disebut tabel fakta atau peristiwa tanpa fakta.
Contoh fakta atau peristiwa tanpa fakta adalah pelajar yang menghadiri kelas atau pasien yang mengunjungi dokter. Dalam kedua kasus
tersebut, tidak ada pengukuran langsung yang terkait dengan salah satu peristiwa tersebut. Ada biaya kuliah yang dibayarkan untuk siswa
untuk menghadiri kelas itu dan tagihan yang dibuat untuk kunjungan dokter, tetapi keduanya terkait dengan fakta lain dan didasarkan pada
atribut lain seperti kursus apa yang didaftarkan siswa dan prosedur apa yang dilakukan dokter. . Dan tagihan akan dibuat apakah pelajar
menghadiri kelas atau pasien melewatkan janji.
Hanya karena tidak ada pengukuran langsung yang terkait dengan fakta tanpa fakta, bukan berarti peristiwa tersebut tidak layak untuk
dilacak. Misalnya, seorang guru dapat mengambil kehadiran di kelas dan menempatkan X di sebelah nama siswa.
Pendekatan untuk melacak fakta-fakta tanpa fakta ini digambarkan dalam Gambar 9.27 . Contoh tersebut menggambarkan hal itu
atribut dibuat sebagai dummy counter fact yang disetel ke 1 atau 0; 1 berarti itu terjadi, siswa muncul di kelas. Hal ini
memungkinkan konektivitas antara tabel fakta dan dimensi — penghitungannya
GAMBAR 9.27
Contoh tabel acara.

acara. Tabel fakta tanpa fakta ini adalah praktik terbaik untuk menangkap peristiwa yang tidak memiliki pengukuran numerik alami.
Contoh menunjukkan acara atau tabel fakta tanpa fakta:
• Ini memiliki Kehadiran Mahasiswa fakta dengan kunci asing untuk siswa, instruktur, lokasi kelas, tanggal kelas, dan
kursus itu sendiri.
• Dalam Kehadiran Mahasiswa Faktanya adalah semua kunci asing tersebut terdaftar, maka item terakhir, kelas yang dihadiri, adalah
penghitung boneka, set ke 1 atau 0.
• Jika siswa muncul, semua kunci asing tersebut diisi dengan 1.

• Jika Anda juga mencatat, Anda dapat menurunkan angka nol jika seorang siswa tidak muncul.
• Dengan daftar setiap siswa dari setiap sesi kelas, Anda dapat menyimpulkan untuk tanggal tertentu berapa banyak siswa yang muncul
dengan menjumlahkan kelas yang dihadiri.
• Anda dapat memfilter 0 nilai untuk menentukan siapa yang tidak menghadiri kelas. Kemudian Anda dapat
• menggabungkan dengan memfilter angka 1 untuk melakukan analisis tren
Menerapkan atribut penghitung dummy dalam tabel fakta tanpa fakta memungkinkan analisis bisnis peristiwa meskipun
peristiwa bisnis ini secara alami tidak memiliki pengukuran numerik yang terkait dengannya.
TABEL FAKTA KONSOLIDASI

Seperti yang telah kita bahas, tabel fakta menyimpan data tentang transaksi atau peristiwa bisnis yang mewakili proses
bisnis tertentu. Tabel fakta dinormalisasi dan dikorelasikan dengan entitas bisnis dalam model data ER sistem
operasional. Ini persis bagaimana skema gudang data harus dirancang jika praktik terbaik diikuti; namun, ketika data
diubah menjadi skema yang mendukung data mart atau kubus, mungkin ada pengecualian untuk aturan ini yang disebut
fakta terkonsolidasi.
Tabel fakta terkonsolidasi adalah tabel fakta yang terpisah dan berbeda dalam sistem operasional, proses bisnis, dan gudang data
yang dikonsolidasikan atau digabungkan untuk memfasilitasi pelaporan dan analisis. Contoh di Gambar 9.28 mengilustrasikan tabel fakta
( Fact_SalesPerformance) menggabungkan ukuran penjualan ( ActualSales), perkiraan penjualan ( ForecastedSales), varian yang dihitung
( ForecastVariance), dan
GAMBAR 9.28
contoh fakta terkonsolidasi.

kunci asing untuk beberapa dimensi yang sesuai — produk, pelanggan, geografi, dan periode pengukuran.
Penggunaan umum lainnya untuk tabel fakta terkonsolidasi adalah analisis kinerja pengeluaran anggaran-ke-aktual.
Asal mula konsolidasi fakta ini berasal dari jenis analisis bisnis yang dilakukan dan kemampuan alat pelaporan (terutama dari masa
awal BI) dan spreadsheet yang digunakan oleh bisnis. Membandingkan anggaran atau prakiraan dengan kinerja aktual merupakan jenis
analisis bisnis yang cukup umum, jadi ada kebutuhan yang sangat kuat untuk memfasilitasi analisis tersebut. Metode termudah yang
tersedia untuk banyak alat pelaporan dan spreadsheet adalah dengan menggabungkan fakta-fakta ini ke dalam satu tabel (yaitu, tabel yang
didenormalisasi atau diratakan).
Dua pertimbangan utama saat menggabungkan tabel fakta adalah fakta berbagi dimensi yang sesuai dan keduanya memiliki butir yang
sama. Untuk memperoleh tingkat detail atau butiran yang sama biasanya membutuhkan agregasi salah satu tabel fakta yang mendasarinya.
Misalnya, penganggaran atau peramalan penjualan atau pengeluaran mungkin dilakukan pada biji-bijian mingguan atau bulanan, sedangkan
penjualan mungkin dicatat dalam waktu nyata dan pengeluaran dapat dicatat setiap hari. Jika salah satu fakta di tabel fakta gabungan
digabungkan, maka detail yang mendasarinya tidak tersedia bagi siapa pun yang menggunakan tabel fakta gabungan untuk analisis.
Merupakan praktik terbaik untuk mempertahankan tabel fakta terpisah dalam skema DW dan hanya mengonsolidasikan tabel fakta di penyimpanan
data terkait BI seperti data mart dan kubus.
REKAP PEMODELAN DIMENSI

Model dimensi adalah sekumpulan dua entitas:
• Fakta, yang mencatat ukuran peristiwa bisnis (seperti penjualan) yang terjadi di suatu perusahaan
• Ukuran, yang mewakili siapa, apa, di mana, dan kapan acara bisnis tersebut
Contoh di Gambar 9.29 merangkum apa yang telah Anda pelajari dalam bab ini dengan menunjukkan segala sesuatu tentang penjualan internet:
• FactInternetSales adalah fakta / peristiwa bisnis, yang dikaitkan dengan beberapa dimensi:
• Produk yang dijual, DimProduct
• Pelanggan yang membelinya, DimCustomer
• Mata uang yang digunakan pelanggan, DimCurrency
• Tanggal penjualan, DimDate

• Promosi yang terkait dengan penjualan, DimPromotion
• Wilayah tempat penjualan dilakukan, DimSalesTerritory
Semua pelaporan dan analitik diarahkan pada model dimensi ini. Seluruh ilmu pemodelan dimensional, tidak hanya
mengembangkan model, tetapi juga dalam melakukan pelaporan dan query, alat pengekstrak transform dan pemuatan, dan alat BI,
menggunakan model dimensional. Meskipun para pelaku bisnis di perusahaan Anda mungkin tidak pernah melihat model data aktual
yang Anda buat, mereka akan menjadi sangat akrab
REcAp PEMODELAN DIMENSI 235
GAMBAR 9.29
Rekapitulasi pemodelan dimensi.
dengan laporan dan dasbor yang mereka bantu hasilkan. Kecuali jika model tersebut dapat menghasilkan pelaporan dan analisis yang jelas dan
efektif, model tersebut tidak akan membantu bisnis melihat data dan menggunakannya untuk membuat keputusan tepat yang memengaruhi operasi.
Pemodelan dimensi adalah kunci untuk menghasilkan informasi bisnis penting ini.

TransliteRickSherman BusinessIntelligenceGuidebook - FromDataIntegrationtoAnalytics MorganKaufmann2014r1191 229.en - Id

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

TransliteRickSherman BusinessIntelligenceGuidebook - FromDataIntegrationtoAnalytics MorganKaufmann2014r1191 229.en - Id

Diunggah oleh

Hak Cipta:

Format Tersedia

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Translite Rick Sherman - Business Intelligence Guidebook From Data

Book · September 2001

The user has requested enhancement of the downloaded file.

INFORMASI DALAM BAB INI:

• Dimensi hierarki dan kunci Skema

• Konsistensi dan kesesuaian

• Dimensi dan fakta lanjutan

PENGANTAR PEMODELAN DIMENSI

Buku Panduan Business Intelligence. http://dx.doi.org/10.1016/B978-0-12-411461-6.00009-5

PEMANDANGAN TINGKAT TINGGI DARI MODEL DIMENSI

• Faktanya Tbl_Fact_Store_Sales merupakan inti dari model dimensi.

Tinjauan pemodelan dimensi.

KUNCI TABEL FAKTA

• DateKey —Tanggal dan waktu pembelian dilakukan

Tabel fakta — kunci.

Tabel fakta — kunci utama dengan dimensi degeneratif.

Tabel fakta — kunci utama adalah kunci pengganti.

Tabel fakta — perincian.

Dimensi — contoh dasar.

• Deskriptif agar pelaku bisnis dan perancang aplikasi BI dapat memahaminya.

• Struktur organisasi, seperti organisasi pemasaran atau penjualan.

KUNCI DIMENSI DAN KUNCI PENGGANTI

menyebabkan kebutuhan untuk mengganti sistem.

kebutuhan analitis perusahaan.

• Sistem sumber mungkin menggunakan tombol pintar.

Kunci pengganti dan alami.

Bukan Nilai NULL

Praktik terbaik yang menangani potensi risiko bisnis ini meliputi:

Untuk meringkas, dimensi harus memiliki karakteristik sebagai berikut:

• Kunci utama Non-NULL

• DimSalesTerritory —Tempat wilayah penjualan berada

Skema kepingan salju.

MODEL BINTANG GANDA

Model bintang multifakta.

HUBUNGAN ENTITAS VERSUS DIMENSIONAL MODELING

Tabel 9.1 Membandingkan Operasional dan BI

Sistem Operasional BI dan Analytics

catatan) sangat penting sangat penting

Redundansi minimal (normalisasi) Peningkatan redundansi (denormalisasi)

Penggunaan ruang penyimpanan yang efisien Peningkatan ruang penyimpanan

Beberapa masalah perawatan Meningkatnya masalah perawatan

MENGAPA STRUKTUR ITU PENTING

ER versus contoh dimensi.

TUJUAN PEMODELAN DIMENSI

PEMETAAN LAPORAN BISNIS

Memetakan ke laporan bisnis.

PEMETAAN KE ANALISIS OLAP ATAU SPREADSHEET

Memetakan ke analisis OLAp.

Tabel 9.2 Perbandingan Jenis Tabel Fakta

Properti Transaksi Berkala Mengumpulkan

Jumlah dimensi Rata-rata Paling

Fakta Transaksi terkait Terkait periode Banyak acara berakhir

Pengukuran Aditif Bukan aditif, rata-rata Perlu diturunkan

Dimensi yang sesuai Iya Iya Iya

Ukuran database Terbesar Lebih kecil Terkecil

• Manajemen data master (MDM) Integrasi data

FAKTA YANG MENYESUAIKAN

DIMENSI DAN FAKTA LANJUTAN

TANGGAL (ATAU KALENDER) DIMENSI

Mendesain Dimensi Tanggal

Ada beberapa keuntungan menggunakan kunci pintar ini:

• Itu dipahami secara universal