Tahap 3: Mendefinisikan Model Dimensi

Proses desain database dimulai dengan pandangan perusahaan dari bisnis dan bidang studi
tertentu yang akan dilaksanakan. Pekerjaan yang Anda lakukan pada model bisnis dan logis
menetapkan stage untuk tahap berikutnya dalam proses desain: pengembangan model dimensi
Meskipun entitas-hubungan diagram secara tradisional dikaitkan dengan model yang sangat
dinormalisasi seperti aplikasi OLTP, teknik ini masih berguna untuk desain data warehouse
dalam bentuk pemodelan dimensi. Dalam pemodelan dimensi, bukan mencari untuk menemukan
unit atom informasi (seperti entitas dan atribut) dan semua hubungan antara mereka, Anda
mengidentifikasi informasi yang dimiliki fact tabel (tabel fakta) sentral dan informasi yang
dimiliki tabel dimensi yang terkait. Hierarki potensi dimensi juga diidentifikasi. Hasil dari model
dimensi biasanya model star (bintang) atau snowflake. Desain dimensi adalah dasar dari desain
database untuk data warehouse.
Catatan: Dalam kursus ini, Anda erat mengamati model dimensi star mengambil contoh dari
skema SH

Skema data warehouse

Struktur table lingkungan warehouse dapat mengambil sejumlah bentuk. Struktur datapemodelan yang biasa ditemui dalam lingkungan data warehouse yang
-

Star Schema (Skema bintang)

Snowflake Schema (Skema bola salju)
Third Normal Form (3NF)

Catatan: Hari ini, sebagian besar skema data warehouse tidak skema bintang atau 3NF skema,
tapi bukannya berbagi karakteristik dari kedua skema; ini disebut model skema sebagai hybrid.
Struktur normalisasi menyimpan jumlah terbesar data dalam jumlah sedikit ruang. Hubungan
entitas pemodelan (ERM) juga berusaha untuk menghilangkan redundansi data. Hal ini sangat
bermanfaat untuk sistem OLTP.
Pemodelan dimensi (DM) adalah desain yang menyajikan data secara intuitif dan memungkinkan
untuk akses kinerja tinggi. Untuk dua alasan, pemodelan dimensi, seperti bintang dan kepingan
salju skema, telah menjadi desain standar untuk data mart dan gudang data.

Model Skema Bintang (Star Schema Model)

Sebuah model skema star dapat digambarkan sebagai simple star: central tabel berisi fact data,
dan beberapa tabel memancar dari itu, yang dihubungkan oleh database primer dan foreign key.
Tidak seperti struktur database lain, skema star telah denormalized dimensi.
Model star (bintang):
-

Mudah dipahami karena struktur sederhana dan mudah.

Dapat memberikan respon yang cepat untuk query dengan optimasi dan pengurangan
jumlah fisik bergabung diperlukan antara fakta dan tabel dimensi.
Berisi metadata sederhana.
Didukung oleh banyak alat front-end
Lambat untuk membangun karena tingkat denormalization

Skema star menyediakan kinerja query yang lebih baik pada biaya bongkar yang lebih kompleks
dan transformasi.

Model Star Dimensional (Star Dimensional Modeling)

Pemodelan dimensi star adalah teknik desain logis yang berusaha untuk menyajikan data dalam
kerangka standar yang intuitif dan memberikan kinerja tinggi. Setiap model dimensi terdiri dari
satu tabel disebut fact tabel dan satu set table smaller yang disebut table dimensi. Karakteristik
(denormalized, star-like structure) ini umumnya dikenal sebagai model star. Dalam hal ini model
star, data yang berlebihan diposting dari satu objek ke yang lain untuk pertimbangan kinerja.
Sebuah fact tabel memiliki banyak bagian primary key dari dua atau lebih foreign key dan
mengungkapkan banyak-ke-banyak hubungan. Setiap tabel dimensi memiliki satu bagian
primary key yang sesuai persis dengan salah satu komponen banyak bagian kunci dalam fact
table.
Catatan: Skema SH menggunakan sebuah model star dimensional, dimana sales adalah fact table
(table fakta) join dengan dimensi seperti CHANNELS, COUNTRIES, TIMES, PROMOTIONS,
PRODUCTS, and seterusnya.

Keuntungan menggunakan model Start Dimensional

-

Memberikan analisis cepat di dimensi yang berbeda untuk drilling down, rotasi, dan
perhitungan analitis untuk kubus multidimensi.
Menciptakan desain database yang meningkatkan kinerja
Memungkinkan pengoptimalan database untuk bekerja dengan desain database yang
lebih sederhana untuk menghasilkan rencana eksekusi yang lebih baik.
Parallels bagaimana pengguna akhir biasanya berpikir dan menggunakan data
Menyediakan desain extensible yang mendukung perubahan kebutuhan bisnis
Memperluas pilihan untuk alat data-akses karena beberapa produk memerlukan
desain skema bintang

Catatan:
-

Definisi antara model star dan snowflake bervariasi antara praktisi. Disini,
diasumsikan bahwa model start berisi fact table (table fakta). Sebagai contoh adalah
sales fact dan Product Dimension. Snowflake, disisi lain mempunyai beberapa tingkat
dimensi yaitu suatu hirarki (sebagai contoh, Sales Fact, Product Dimension, and
Product Group).

Slide berisi daftar keuntungan tingkat tinggi menggunakan model dimensi star.
Keuntungan yang lebih spesifik dan karakteristik dari model bintang tercantum
kemudian dalam pelajaran ini.

Model Skema Snowflake

Menurut Ralph Kimball, "dimensi A dikatakan snowflaked ketika bidang kardinalitas rendah
dalam dimensi telah dipindahkan ke tabel terpisah dan dihubungkan kembali ke tabel asli dengan
artificial keys"
Sebuah model skema Snowflake adalah lebih dekat ke ERD dari model star klasik karena
dimensi data yang lebih normal. Mengembangkan model snowflake berarti membangun hierarki
kelas dari masing-masing dimensi (normalisasi data).
Salah satu alasan utama mengapa model skema star telah menjadi lebih menonjol dari model
snowflake adalah keuntungan kinerja query nya. Dalam lingkungan gudang, kinerja beban lebih
cepat snowflake adalah jauh lebih penting daripada kinerja query lambat.
Catatan: Setiap tabel dimensi ekstra dalam skema snowflake sering mewakili tingkat lain dari
hirarki.

Model Skema Snowflake (Lanjutan)

Model snowflake:
-

Hasil penurunan kinerja karena jumlah yang lebih besar dari tabel bergabung
Menyediakan struktur yang lebih mudah untuk mengubah persyaratan perubahan
Apakah lebih cepat pada loading data ke dalam tabel dinormalisasi yang lebih kecil,
dibandingkan dengan loading ke skema bintang tabel denormalized lebih besar
Memungkinkan menggunakan tabel sejarah untuk mengubah data, bukan bidang
tingkat (indikator).
Memiliki struktur metadata kompleks yang lebih sulit untuk alat pengguna akhir
untuk mendukung.

Selain skema star dan snowflake, terdapat model lain yang dapat dipertimbangkan
Konstelasi: Sebuah model konstelasi (juga disebut model galaksi) terdiri dari serangkaian model
star. Sebuah konstelasi adalah fitur desain yang berguna jika Anda memiliki primary fact table
dan ringkasan tabel dari dimensi yang berbeda. Hal ini dapat menyederhanakan desain dengan
memungkinkan Anda untuk berbagi dimensi di antara banyak fact table (tabel fakta).

Third Normal Form (3NF)

Bentuk Normal Ketiga (3NF) skema adalah teknik database pemodelan relasional klasik yang
meminimalkan redundansi data melalui normalisasi. Suatu hubungan dapat dianggap 3NF jika

tidak ada atribut key non primer direplikasi dalam tabel lainnya. Bila dibandingkan dengan
skema star, di skema 3NF biasanya memiliki jumlah yang lebih besar dari tabel (dengan join
table) karena proses normalisasi ini. Skema 3NF biasanya dipilih untuk kinerja beban yang lebih
baik.
Beberapa data warehouse menggunakan desain skema 3NF. Seperti desain skema lain, data
mereka juga dapat langsung diakses dengan menggunakan kode SQL. Mereka mungkin memiliki
penyimpanan data yang lebih efisien dengan harga kinerja query yang lambat disebabkan join
table yang luas. Beberapa perusahaan besar membangun sebuah 3NF central data warehouse
feeding-bergantung star data marts untuk lini bisnis yang spesifik. Ketika sebuah data warehouse
mempunya table yang lebih besar dan fact tables, mereka harus dipartisi, dengan menggunakan
komposit partisi- misalnya, range-hash:
-

Sebuah range untuk memfasilitasi beban data dan data penghapusan

Sebuah hash di join dengan colom untuk memfasilitasi join partitionwise.
Sebuah number dari partisi hash harus menjadi a power of 2 (#CPU X 2)

Selain itu, parallel execution harus digunakan sehingga bukan satu proses melakukan semua
pekerjaan, banyak proses bekerja secara bersamaan pada unit yang lebih kecil. Parallel degree
seharusnya menjadi power of 2.
Catatan: Operasi partitioning dan parallel tercakup dalam pelajaran berjudul Database Sizing,
Storage, Performance, and Security Considerations.

Fact Table: Characteristics

Fact merupakan ukuran numerical dari bisnis. Fact table adalah table terbesar dalam skema star
dan terdiri dari volume data yang besar, biasanya membuat sampai 90% atay lebih dari total
ukuran basis data. Hal ini dapat dilihat dalam dua bagian:
-

Multipart primary key

Business metrics
Numeric
Additive

------translate lg
Seringkali, ukuran yang mungkin diperlukan di gudang, tetapi mungkin tidak tampak aditif. Ini
dikenal sebagai fakta aditif setengah. Persediaan dan suhu kamar adalah dua pengukuran
numerik tersebut. Ini tidak masuk akal untuk menambahkan ini pengukuran numerik dari waktu
ke waktu, tetapi mereka dapat dikumpulkan dengan menggunakan fungsi SQL selain sum
(misalnya, rata-rata). Meskipun skema bintang biasanya berisi satu tabel fakta, skema lain dapat
berisi beberapa tabel fakta.

Apakah Tabel Fakta Factless? Sebuah tabel fakta factless adalah tabel fakta yang tidak
mengandung nilai aditif numerik, tetapi terdiri eksklusif dari kunci. Ada dua jenis factless tabel
fakta: event-pelacakan dan cakupan. Kegiatan-pelacakan tabel record dan track peristiwa yang
telah terjadi, seperti kehadiran kelas mahasiswa ', sedangkan cakupan tabel factless mendukung
model dimensi ketika tabel fakta utama adalah jarang (misalnya, promosi penjualan meja
factless). Dalam kasus terakhir, peristiwa tidak terjadi. Meskipun data fakta promosi dapat
disimpan dalam tabel fakta itu sendiri, menciptakan cakupan tabel fakta factless jauh lebih
efisien karena kompleks banyak-ke-banyak hubungan yang terbentuk melalui dimensi untuk
promosi memerlukan sejumlah besar rinci dengan nilai nol.

Lebih dari Tabel Fakta Factless

Tabel fakta factless mewakili banyak-ke-banyak hubungan antara dimensi sehingga karakteristik
event dapat dianalisis. Pandangan terwujud umumnya dibangun di atas factless fact tables untuk
membuat ringkasan. Pandangan terwujud dibahas dalam pelajaran berjudul "The ETL Proses:.
Memuat Data"
Contoh:
-

Sumber daya manusia: Studi komposisi angkatan kerja sering dilakukan untuk tujuan
pelaporan dan perencanaan. Analisis karyawan dengan karakteristik yang berbeda
dapat dilakukan dengan menggunakan star ilustrasi. Sebagian besar informasi yang
dihasilkan dari jenis meja adalah serangkaian penting. Dalam contoh ilustrasi,
memilih COUNT (EMP FK) memberikan jumlah karyawan, sedangkan memilih
COUNT (SAL FK) memberikan jumlah karyawan dengan gaji kelas tertentu.
Toko ritel: Promosi khas dalam lingkungan ritel. Rantai ritel kelas atas ingin
membandingkan pelanggan yang tidak menanggapi langsung promosi mail ke orangorang yang melakukan pembelian. Sebuah tabel fakta factless mendukung hubungan
antara dimensi pelanggan, produk, promosi, dan waktu.
Mahasiswa yang hadir: tabel fakta Factless dapat digunakan untuk merekam
kehadiran siswa kelas di sebuah perguruan tinggi atau sekolah sistem. Tidak ada fakta
yang terkait dengan ini, itu adalah masalah apakah siswa menghadiri

Mengindentifikasi base dan Derived Measure

Field dalam fact table Anda data tidak hanya sumber dan data columns. Mungkin lebih banyak
kolom yang ingin menganalisis bisnis, seperti tahun-ke-hari penjualan atau perbedaan persentase
penjualan dari tahun lalu, atau keuntungan. Anda harus melacak fakta berasal serta fakta-fakta
dasar.
Derived Facts adalah data yang dihitung atau dibuat dari dua atau lebih sumber data. Nilai yang
diperoleh dapat lebih efisien disimpan untuk akses, daripada menghitung nilai pada waktu
eksekusi. Misalnya, Keuntungan adalah ukuran berasal, sedangkan penjualan adalah ukuran

dasar. Demikian pula, Gaji dan Komisi adalah langkah-langkah dasar, sedangkan kompensasi
bulanan karyawan adalah ukuran berasal.
Dalam sistem OLTP, langkah-langkah yang berasal tidak disimpan, tetapi berasal data dalam
gudang sangat penting karena dukungan yang melekat untuk query. Ketika Anda simpan berasal
data dalam database, nilai-nilai yang segera tersedia untuk analisis melalui query.
Slide show menunjukkan terjemahan dari beberapa bisnis ukuran model bisnis ke dalam fact
tabel Penjualan. Selain itu, setiap langkah dalam tabel fakta isidentified baik sebagai dasar atau
berasal contoh ukuran-untuk, Profit = Sales_amount -Biaya. Nilai berasal dapat dibuat selama
proses ekstraksi atau transformasi.
Mengikuti proses untuk mengidentifikasi base dan derived measure
-

Mengidentifikasi calon facts: Identifikasi semua basis mungkin dan fakta yang
diperoleh. Mengumpulkan semua laporan yang disampaikan dalam proses
wawancara. Anda dapat mengkompilasi sebuah spreadsheet berisi semua fakta yang
terdaftar di laporan atau diminta dalam wawancara. Menangkap nama sebenarnya, di
mana ia diidentifikasi (nama laporan atau wawancara)
Menghapus duplikat facts: Menghilangkan fakta-fakta duplikat. Anda dapat
kelompok fakta duplikat bersama-sama dan kemudian bekerja dengan pengguna
bisnis untuk menghapus duplikat. Anda juga mengidentifikasi dasar dan berasal fakta
Menemukan dan mendokumentasikan perhitungan yang mendasari: Setelah
mengidentifikasi fakta-fakta yang diperoleh, mendokumentasikan rumus yang akan
digunakan dalam perhitungan.
Referensi silang base fact: Anda harus memastikan bahwa semua fakta dasar yang
diperlukan dalam perhitungan termasuk
Memperoleh persetujuan akhir derived fact: Anda harus memastikan bahwa pengguna
bisnis dan manajemen menyetujui daftar fakta-fakta yang diperoleh yang telah
diidentifikasi.

Fact table measure dapat menjadi:

-

Aditif: aditif tindakan dapat ditambahkan di semua dimensi untuk memberikan

jawaban untuk pertanyaan Anda. Additive Fact merupakan komponen fundamental
dari sebagian besar permintaan. Biasanya, ketika Anda query database, Anda meminta
data diringkas ke tingkat tertentu untuk memenuhi kendala permintaan Anda. Fakta
aditif yang numerik dan dapat secara logis digunakan dalam perhitungan di semua
dimensi. Beberapa contoh tindakan aditif yang unit yang terjual, saldo rekening
pelanggan, dan biaya pengiriman.
Catatan: Anda harus memilih fakta-fakta dalam tabel fakta menjadi numerik dan
aditif (lebih berguna).
Semi Aditif: tindakan Additive Semi dapat ditambahkan bersama beberapa tapi tidak
semua dimensi, seperti saldo rekening bank. Bank mencatat saldo pada akhir setiap
hari perbankan bagi pelanggan, oleh akun, dari waktu ke waktu. Hal ini
memungkinkan bank untuk belajar deposito serta pelanggan individu. Dalam
beberapa kasus, ukuran saldo rekening aditif. Jika pelanggan memegang kedua giro

dan tabungan, Anda dapat menambahkan bersama-sama saldo setiap akun pada akhir
hari dan mendapatkan keseimbangan gabungan bermakna. Anda juga dapat
menambahkan saldo rekening bersama di di cabang yang sama untuk gambar dari
total simpanan di setiap lokasi; Namun, Anda tidak dapat menambahkan bersamasama saldo rekening untuk satu pelanggan selama beberapa hari.
Non Aditif: tindakan non Additive tidak dapat secara logis ditambahkan antara
catatan. Data non Aditif dapat numerik dan biasanya dikombinasikan dalam
perhitungan dengan fakta lain (untuk membuatnya aditif) sebelum ditambahkan di
catatan. Margin persen adalah contoh ukuran non aditif. Langkah-langkah non Aditif
juga ditemukan di tabel fakta factless

Dimensi Tabel Karakteristik Dimensi adalah deskripsi tekstual dari atribut bisnis. Tabel dimensi
biasanya lebih kecil dari tabel fakta dan data perubahan lebih jarang. Tabel dimensi memberikan
perspektif mengenai mengapa dan bagaimana transaksi bisnis dan elemen. Meskipun dimensi
umumnya berisi data yang relatif statis, dimensi pelanggan lebih sering diperbarui.
Dimensi Apakah penting untuk Analisis Kunci model dimensi yang kuat terletak pada kekayaan
dimensi atribut karena mereka menentukan bagaimana fakta-fakta dapat dianalisis. Dimensi
dapat dianggap sebagai titik masuk ke "ruang kenyataan." Selalu nama atribut dalam kosakata
pengguna. Dengan cara itu, dimensi akan mendokumentasikan sendiri dan kekuatan ekspresif
akan menjadi jelas

Menterjemahkan business Dimensions into dimension tables

Menerjemahkan daftar atribut business dimensi ke tabel dimensi bukanlah satu-satu proses
pemetaan sederhana. Anda juga harus memahami struktur data sumber untuk mengidentifikasi
semua elemen sumber data yang perlu dimasukkan dalam data warehouse untuk mendukung
kebutuhan analisis pengguna
Misalnya, slide menunjukkan terjemahan dari dimensi Produk bisnis ke dalam dimension tabel
-

Daftar atribut untuk dimensi Produk bisnis yang terungkap selama fase-model bisnis
Semua informasi sumber data terkait produk-dikumpulkan dan digunakan untuk
membantu menerjemahkan kebutuhan bisnis ke dalam dimensi atribut tabel dimensi
Dalam contoh ini, "ID" bidang (kode yang secara unik mengidentifikasi atribut
produk) dan bidang deskripsi yang tersedia dalam data sumber, dan harus dimasukkan
dalam gudang sehingga pengguna familiar dengan sistem produksi bisa
menyeberang-referensi bidang ID sistem sumber dengan elemen data warehouse

Slowly Changing Dimensions

Data dimensi tidak berubah sebagai dinamis sebagai data fakta. Selama beberapa tahun yang
diberikan, data dimensi dapat berubah. Misalnya, ukuran produk dan paket produk dapat berubah
dalam dimensi Produk selama periode waktu. Demikian pula, nama Negara, State, dan Kota

dapat berubah dalam Countries. Dimensi ini disebut sebagai perlahan-lahan berubah dimensi
(SCDs). Data warehouse harus dapat menyimpan baik data saat ini dan sejarah yang sangat
efektif untuk SCDs. Ada tiga cara untuk mengelola perlahan berubah dimensi.
-

Menimpa atribut dimensi yang ada dengan perubahan. Ini tidak mempengaruhi
tombol juga tidak memasukkan catatan
Menambahkan catatan baru setiap kali perubahan data dimensi. Ini menjaga sejarah
dari rekor lama dan akurat partisi sejarah di waktu; Namun, peningkatan yang
signifikan untuk ukuran database yang dikeluarkan. Periksa butir data sangat erat
ketika pertama kali merancang data warehouse; jika tidak, partisi data tidak akan
terjadi dengan benar. Perhatian harus digunakan ketika menerapkan perubahan ini.
Jika ID digunakan sebagai kunci utama, pelanggaran integritas potensial bisa terjadi.
Menjaga informasi record saat ini, tetapi mencakup beberapa bidang kritis ketika
awalnya merancang data warehouse. Bidang ini menyimpan informasi sebelumnya
dan saat ini, dan harus mencakup atribut waktu untuk menandakan kapan perubahan
terjadi sehingga memungkinkan sejarah perubahan harus dipertahankan. Ini harus
jelas bahwa metode ini meningkatkan kompleksitas dan ukuran komponen meja.
Catatan: Oracle Warehouse Builder mendukung semua tiga pilihan untuk mengelola
SCDs.

Slowly Changing Dimensions : An Example

Sebuah contoh khas dari dimensi perlahan berubah (Produk) ditunjukkan pada slide. Misalnya
menggunakan opsi ketiga seperti yang dijelaskan pada halaman sebelumnya. Note that new
attributes Prod_Eff_From and Prod_Eff_Toare added. Sebuah pengganti kunci ID baru juga
ditambahkan sehingga perubahan ke Products Dimensi dapat dilacak dengan menambahkan
catatan baru. Prod_Id mungkin sama dengan dua recordsm tapi nilai ID berbeda.
Catatan: Sebuah kunci pengganti adalah kunci sistem yang dihasilkan di lingkungan gudang.
Dalam beberapa kasus, metode yang digunakan untuk menjaga data historis berpotensi
memungkinkan duplikat kunci. Untuk memastikan keunikan, kunci pengganti yang dihasilkan
oleh aplikasi yang memelihara data (misalnya, OWB). Diskusi tentang kunci pengganti
disertakan pada halaman berikut.