1.

Introduction to Data Warehousing Concepts

Bab ini memberikan gambaran umum tentang implementasi pergudangan data Oracle. Itu
mengandung:

 Apa Itu Gudang Data?

 Membandingkan Lingkungan OLTP dan Data Warehousing

 Tugas Gudang Data Umum

 Arsitektur Data Warehouse

A. What Is a Data Warehouse?

Sebuah gudang data adalah database yang dirancang untuk memungkinkan kegiatan intelijen
bisnis: itu ada untuk membantu pengguna memahami dan meningkatkan kinerja organisasi
mereka. Ini dirancang untuk permintaan dan analisis daripada untuk pemrosesan transaksi, dan
biasanya berisi data historis yang berasal dari data transaksi, tetapi dapat mencakup data dari
sumber lain. Gudang data memisahkan beban kerja analisis dari beban kerja transaksi dan
memungkinkan organisasi untuk mengkonsolidasikan data dari beberapa sumber. Ini membantu
dalam:

 Memelihara catatan sejarah

 Menganalisis data untuk mendapatkan pemahaman yang lebih baik tentang bisnis dan untuk
meningkatkan bisnis

Selain database relasional, lingkungan gudang data dapat mencakup solusi ekstraksi,
transportasi, transformasi, dan pemuatan (ETL), analisis statistik, pelaporan, kemampuan
penambangan data, alat analisis klien, dan aplikasi lain yang mengelola proses pengumpulan
data. , mengubahnya menjadi informasi yang berguna dan dapat ditindaklanjuti, dan
mengirimkannya ke pengguna bisnis.
Untuk mencapai tujuan peningkatan kecerdasan bisnis, gudang data bekerja dengan data yang
dikumpulkan dari berbagai sumber. Sumber data dapat berasal dari sistem yang dikembangkan
secara internal, aplikasi yang dibeli, sindikasi data pihak ketiga, dan sumber lainnya. Ini mungkin
melibatkan transaksi, produksi, pemasaran, sumber daya manusia dan banyak lagi. Di dunia data
besar saat ini, data mungkin berupa miliaran klik individu di situs web atau aliran data besar-
besaran dari sensor yang dibangun ke dalam mesin yang kompleks.

Gudang data berbeda dari sistem pemrosesan transaksi online (OLTP). Dengan gudang data,
Anda memisahkan beban kerja analisis dari beban kerja transaksi. Jadi gudang data adalah sistem
yang sangat berorientasi baca. Mereka memiliki jumlah membaca data yang jauh lebih tinggi
dibandingkan dengan menulis dan memperbarui. Hal ini memungkinkan kinerja analitis yang jauh
lebih baik dan menghindari dampak pada sistem transaksi Anda. Sistem gudang data dapat
dioptimalkan untuk mengkonsolidasikan data dari banyak sumber untuk mencapai tujuan utama:
menjadi "satu-satunya sumber kebenaran" organisasi Anda. Ada nilai besar dalam memiliki
sumber data yang konsisten yang dapat dilihat oleh semua pengguna; itu mencegah banyak
perselisihan dan meningkatkan efisiensi pengambilan keputusan.
Gudang data biasanya menyimpan data selama berbulan-bulan atau bertahun-tahun untuk
mendukung analisis historis. Data di gudang data biasanya dimuat melalui proses ekstraksi,
transformasi, dan pemuatan (ETL) dari berbagai sumber data. Gudang data modern bergerak
menuju arsitektur ekstrak, muat, transformasi (ELT) di mana semua atau sebagian besar
transformasi data dilakukan pada database yang menampung gudang data. Penting untuk dicatat
bahwa mendefinisikan proses ETL adalah bagian yang sangat besar dari upaya desain gudang
data. Demikian pula, kecepatan dan keandalan operasi ETL adalah dasar dari gudang data setelah
aktif dan berjalan.

Pengguna data warehouse melakukan analisis data yang seringkali berhubungan dengan waktu.
Contohnya termasuk konsolidasi angka penjualan tahun lalu, analisis persediaan, dan laba per
produk dan per pelanggan. Tetapi berfokus pada waktu atau tidak, pengguna ingin "mengiris dan
memotong" data mereka sesuka mereka dan gudang data yang dirancang dengan baik akan
cukup fleksibel untuk memenuhi permintaan tersebut. Pengguna terkadang membutuhkan data
yang sangat teragregasi, dan di lain waktu mereka perlu menelusuri detailnya. Analisis yang lebih
canggih mencakup analisis tren dan penambangan data, yang menggunakan data yang ada untuk
meramalkan tren atau memprediksi masa depan. Gudang data bertindak sebagai mesin dasar
yang digunakan oleh lingkungan intelijen bisnis middleware yang menyajikan laporan, dasbor,
dan antarmuka lainnya kepada pengguna akhir.

Meskipun pembahasan di atas telah difokuskan pada istilah "data warehouse", ada dua istilah
penting lainnya yang perlu disebutkan. Ini adalah data mart dan penyimpanan data operasi
(ODS).
Data mart memiliki peran yang sama dengan gudang data, tetapi cakupannya sengaja dibatasi.
Ini dapat melayani satu departemen atau lini bisnis tertentu. Keuntungan dari data mart versus
data warehouse adalah dapat dibuat lebih cepat karena cakupannya yang terbatas. Namun, data
mart juga menimbulkan masalah dengan inkonsistensi. Dibutuhkan disiplin yang ketat untuk
menjaga konsistensi definisi data dan perhitungan di seluruh data mart. Masalah ini telah diakui
secara luas, sehingga data mart ada dalam dua gaya. Data mart independen adalah mereka yang
diberi makan langsung dari sumber data. Mereka dapat berubah menjadi pulau informasi yang
tidak konsisten. Data mart dependen diumpankan dari gudang data yang ada. Data mart
dependen dapat menghindari masalah inkonsistensi, tetapi mereka memerlukan gudang data
tingkat perusahaan yang sudah ada.
Penyimpanan data operasional ada untuk mendukung operasi sehari-hari. Data ODS dibersihkan
dan divalidasi, tetapi tidak mendalam secara historis: mungkin hanya data untuk hari ini. Alih-alih
mendukung kueri kaya historis yang dapat ditangani oleh gudang data, ODS memberikan gudang
data tempat untuk mendapatkan akses ke data terkini, yang belum dimuat ke dalam gudang data.
ODS juga dapat digunakan sebagai sumber untuk memuat gudang data. Karena teknik pemuatan
data warehousing menjadi lebih maju, gudang data mungkin kurang membutuhkan ODS sebagai
sumber untuk memuat data. Sebaliknya, sistem trickle-feed konstan dapat memuat gudang data
hampir secara real time.

Cara umum untuk memperkenalkan data warehousing adalah dengan mengacu pada
karakteristik data warehouse seperti yang dikemukakan oleh William Inmon:

 Berorientasi Subjek
 Terintegrasi
 Tidak mudah menguap
 Varian Waktu
Berorientasi Subjek
Gudang data dirancang untuk membantu Anda menganalisis data. Misalnya, untuk mempelajari
lebih lanjut tentang data penjualan perusahaan Anda, Anda dapat membangun gudang data yang
berkonsentrasi pada penjualan. Dengan menggunakan gudang data ini, Anda dapat menjawab
pertanyaan seperti "Siapa pelanggan terbaik kami untuk item ini tahun lalu?" atau "Siapa yang
mungkin menjadi pelanggan terbaik kita tahun depan?" Kemampuan untuk mendefinisikan
gudang data berdasarkan materi pelajaran, penjualan dalam hal ini, membuat gudang data
berorientasi pada subjek.
Terintegrasi
Integrasi erat kaitannya dengan orientasi mata pelajaran. Gudang data harus menempatkan data
dari sumber yang berbeda ke dalam format yang konsisten. Mereka harus menyelesaikan
masalah seperti konflik penamaan dan inkonsistensi di antara unit ukuran. Ketika mereka
mencapai ini, mereka dikatakan terintegrasi.
Tidak mudah menguap
Nonvolatile artinya, setelah dimasukkan ke dalam data warehouse, data tidak boleh berubah. Ini
logis karena tujuan dari gudang data adalah untuk memungkinkan Anda menganalisis apa yang
telah terjadi.
Varian Waktu
Fokus gudang data pada perubahan dari waktu ke waktu adalah apa yang dimaksud dengan
istilah varian waktu. Untuk menemukan tren dan mengidentifikasi pola dan hubungan
tersembunyi dalam bisnis, analis membutuhkan data dalam jumlah besar. Ini sangat kontras
dengan sistem pemrosesan transaksi online (OLTP), di mana persyaratan kinerja menuntut agar
data historis dipindahkan ke arsip.

Karakteristik Utama Data Warehouse

Karakteristik utama dari data warehouse adalah sebagai berikut:

 Data disusun untuk kemudahan akses dan kinerja kueri berkecepatan tinggi.
 Pengguna akhir peka terhadap waktu dan menginginkan waktu respons yang cepat.
 Sejumlah besar data historis digunakan.
 Kueri sering kali mengambil data dalam jumlah besar, mungkin ribuan baris.
 Baik kueri standar maupun ad hoc adalah umum.
 Beban data melibatkan banyak sumber dan transformasi.
Secara umum, kinerja kueri yang cepat dengan throughput data yang tinggi adalah kunci
keberhasilan gudang data.
B. Membandingkan Lingkungan OLTP dan Data Warehousing
Ada perbedaan penting antara sistem OLTP dan gudang data. Satu perbedaan utama antara jenis
sistem adalah bahwa gudang data tidak secara eksklusif dalam bentuk normal ketiga (3NF), jenis
normalisasi data yang umum di lingkungan OLTP.

Gudang data dan sistem OLTP memiliki persyaratan yang sangat berbeda. Berikut adalah
beberapa contoh perbedaan antara gudang data biasa dan sistem OLTP:

 Beban kerja
Gudang data dirancang untuk mengakomodasi kueri ad hoc dan analisis data. Anda mungkin
tidak mengetahui beban kerja gudang data Anda sebelumnya, jadi gudang data harus
dioptimalkan agar berkinerja baik untuk berbagai kemungkinan operasi kueri dan analitik.
Sistem OLTP hanya mendukung operasi yang telah ditentukan sebelumnya. Aplikasi Anda
mungkin secara khusus disetel atau dirancang untuk hanya mendukung operasi ini.

 Modifikasi data
Sebuah gudang data diperbarui secara teratur oleh proses ETL (berjalan setiap malam atau
mingguan) menggunakan teknik modifikasi data massal. Pengguna akhir gudang data tidak secara
langsung memperbarui gudang data kecuali saat menggunakan alat analisis, seperti
penambangan data, untuk membuat prediksi dengan probabilitas terkait, menetapkan
pelanggan ke segmen pasar, dan mengembangkan profil pelanggan.

Dalam sistem OLTP, pengguna akhir secara rutin mengeluarkan pernyataan modifikasi data
individual ke database. Basis data OLTP selalu mutakhir, dan mencerminkan keadaan terkini dari
setiap transaksi bisnis.
  Desain skema
Gudang data sering menggunakan skema yang didenormalisasi sebagian untuk mengoptimalkan
kinerja kueri dan analitis.

Sistem OLTP sering menggunakan skema yang sepenuhnya dinormalisasi untuk mengoptimalkan
kinerja pembaruan/penyisipan/penghapusan, dan untuk menjamin konsistensi data.

 Operasi tipikal
Kueri gudang data biasa memindai ribuan atau jutaan baris. Misalnya, "Temukan total penjualan
untuk semua pelanggan bulan lalu."

Operasi OLTP tipikal hanya mengakses segelintir record. Misalnya, "Ambil pesanan saat ini untuk
pelanggan ini."

 Data historis
Gudang data biasanya menyimpan data selama berbulan-bulan atau bertahun-tahun. Ini untuk
mendukung analisis dan pelaporan historis.

Sistem OLTP biasanya menyimpan data hanya dari beberapa minggu atau bulan. Sistem OLTP
hanya menyimpan data historis yang diperlukan agar berhasil memenuhi persyaratan transaksi
saat ini.
C. Tugas Umum Gudang Data
Sebagai administrator atau desainer pergudangan data Oracle, Anda dapat terlibat dalam tugas-
tugas berikut:

 Mengonfigurasi database Oracle untuk digunakan sebagai gudang data

 Merancang gudang data
 Melakukan pemutakhiran perangkat lunak basis data dan pergudangan data ke rilis baru
 Mengelola objek skema, seperti tabel, indeks, dan tampilan terwujud
 Mengelola pengguna dan keamanan
 Mengembangkan rutinitas yang digunakan untuk proses ekstraksi, transformasi, dan
pemuatan (ETL)
 Membuat laporan berdasarkan data yang ada di data warehouse
 Mencadangkan gudang data dan melakukan pemulihan bila perlu
 Memantau kinerja gudang data dan mengambil tindakan pencegahan atau korektif sesuai
kebutuhan
Dalam lingkungan gudang data berukuran kecil hingga menengah, Anda mungkin satu-satunya
orang yang melakukan tugas ini. Di lingkungan perusahaan besar, pekerjaan sering dibagi di
antara beberapa DBA dan desainer, masing-masing dengan spesialisasi mereka sendiri, seperti
keamanan database atau penyetelan database.
Tugas-tugas ini diilustrasikan sebagai berikut:

 Untuk informasi lebih lanjut mengenai partisi, lihat Oracle Database VLDB dan Panduan
Partisi.
 Untuk informasi lebih lanjut mengenai keamanan database, lihat Panduan Keamanan
Database Oracle.
 Untuk informasi lebih lanjut mengenai kinerja database, lihat Panduan Penyetelan Kinerja
Database Oracle dan Panduan Penyetelan SQL Database Oracle.
 Untuk informasi lebih lanjut mengenai pencadangan dan pemulihan, lihat Panduan
Pengguna Pencadangan dan Pemulihan Database Oracle.
 Untuk informasi lebih lanjut mengenai ODI, lihat Panduan Pengembang Oracle Fusion
Middleware untuk Oracle Data Integrator.

D. Arsitektur Data Warehouse

Gudang data dan arsitekturnya bervariasi tergantung pada spesifik situasi organisasi. Tiga
arsitektur umum adalah:

 Arsitektur Gudang Data: Dasar

 Arsitektur Data Warehouse: dengan Staging Area
 Arsitektur Data Warehouse: dengan Staging Area dan Data Mart
Arsitektur Gudang Data: Dasar

Pada Gambar 1-1, metadata dan data mentah dari sistem OLTP tradisional hadir, seperti tipe data
tambahan, data ringkasan. Ringkasan adalah mekanisme untuk melakukan pra-perhitungan
operasi umum yang mahal dan berjalan lama untuk pengambilan data sub-detik. Misalnya, kueri
gudang data yang khas adalah untuk mengambil sesuatu seperti penjualan Agustus. Ringkasan
dalam database Oracle disebut tampilan terwujud.
Penyimpanan gabungan dari data mentah sebagai pusat arsitektur pergudangan data Anda
sering disebut sebagai Enterprise Data Warehouse (EDW). EDW memberikan pandangan 360
derajat ke dalam bisnis organisasi dengan menyimpan semua informasi bisnis yang relevan dalam
format yang paling rinci.
Arsitektur Data Warehouse: dengan Staging Area
Anda harus membersihkan dan mengolah data operasional Anda sebelum memasukkannya ke
dalam gudang, seperti yang ditunjukkan pada Gambar 1-2. Anda dapat melakukan ini secara
terprogram, meskipun sebagian besar gudang data menggunakan area pementasan. Area
pementasan menyederhanakan pembersihan dan konsolidasi data untuk data operasional yang
berasal dari berbagai sistem sumber, terutama untuk gudang data perusahaan di mana semua
informasi yang relevan dari suatu perusahaan dikonsolidasikan. Gambar 1-2 mengilustrasikan
arsitektur tipikal ini.

Arsitektur Data Warehouse: dengan Staging Area dan Data Mart

Meskipun arsitektur pada Gambar 1-2 cukup umum, Anda mungkin ingin menyesuaikan
arsitektur gudang Anda untuk grup yang berbeda dalam organisasi Anda. Anda dapat
melakukannya dengan menambahkan data mart, yang merupakan sistem yang dirancang untuk
lini bisnis tertentu. Gambar 1-3 mengilustrasikan contoh di mana pembelian, penjualan, dan
persediaan dipisahkan. Dalam contoh ini, seorang analis keuangan mungkin ingin menganalisis
data historis untuk pembelian dan penjualan atau menambang data historis untuk membuat
prediksi tentang perilaku pelanggan.

2. Desain Logika Pergudangan Data

Bab ini menjelaskan cara membuat desain logis untuk lingkungan pergudangan data dan
mencakup topik berikut:

 Desain Logis Versus Fisik di Gudang Data

 Membuat Desain Logis
 Tentang Skema Bentuk Normal Ketiga
 Tentang Skema Bintang
 Tentang Toko Kolom Dalam Memori Oracle
 Caching Tabel Besar Otomatis untuk Meningkatkan Kinerja Kueri Paralel Dalam Memori
 Tentang Agregasi Dalam Memori

A. Desain Logis Versus Fisik di Gudang Data

Organisasi Anda telah memutuskan untuk membangun gudang data perusahaan. Anda telah
menentukan persyaratan bisnis dan menyetujui cakupan tujuan bisnis Anda, dan membuat
desain konseptual. Sekarang Anda perlu menerjemahkan kebutuhan Anda ke dalam
penyampaian sistem. Untuk melakukannya, Anda membuat desain logis dan fisik untuk gudang
data. Anda kemudian mendefinisikan:

 Konten data spesifik

 Hubungan di dalam dan di antara kelompok data
 Lingkungan sistem yang mendukung gudang data Anda
 Transformasi data yang diperlukan
 Frekuensi data di-refresh
Desain logis lebih konseptual dan abstrak daripada desain fisik. Dalam desain logis, Anda melihat
hubungan logis di antara objek. Dalam desain fisik, Anda melihat cara paling efektif untuk
menyimpan dan mengambil objek serta menanganinya dari perspektif transportasi dan
pencadangan/pemulihan.

Arahkan desain Anda ke kebutuhan pengguna akhir. Pengguna akhir biasanya ingin melakukan
analisis dan melihat data agregat, bukan pada transaksi individual. Namun, pengguna akhir
mungkin tidak tahu apa yang mereka butuhkan sampai mereka melihatnya. Selain itu, desain
yang terencana dengan baik memungkinkan pertumbuhan dan perubahan seiring kebutuhan
pengguna berubah dan berkembang.
Dengan memulai dengan desain logis, Anda fokus pada persyaratan informasi dan menyimpan
detail implementasi untuk nanti.
B. Membuat Desain Logis

Sebuah desain logis adalah konseptual dan abstrak. Anda belum berurusan dengan detail
implementasi fisik. Anda hanya berurusan dengan mendefinisikan jenis informasi yang Anda
butuhkan.
Salah satu teknik yang dapat Anda gunakan untuk memodelkan persyaratan informasi logis
organisasi Anda adalah pemodelan hubungan entitas. Pemodelan hubungan-entitas melibatkan
pengidentifikasian hal-hal yang penting (entitas), sifat-sifat dari hal-hal ini (atribut), dan
bagaimana mereka terkait satu sama lain (hubungan).
Proses desain logis melibatkan pengaturan data ke dalam serangkaian hubungan logis yang
disebut entitas dan atribut. Entitas mewakili sepotong informasi. Dalam database relasional,
entitas sering dipetakan ke tabel. Atribut adalah komponen entitas yang membantu
mendefinisikan keunikan entitas. Dalam database relasional, atribut memetakan ke kolom.

Untuk memastikan bahwa data Anda konsisten, Anda harus menggunakan pengenal unik.
Pengidentifikasi unik adalah sesuatu yang Anda tambahkan ke tabel sehingga Anda dapat
membedakan antara item yang sama saat item tersebut muncul di tempat yang berbeda. Dalam
desain fisik, ini biasanya merupakan kunci utama.
Pemodelan hubungan entitas murni logis dan berlaku untuk OLTP dan sistem pergudangan data.
Hal ini juga berlaku untuk berbagai teknik pemodelan skema fisik umum yang ditemukan di
lingkungan data warehousing, yaitu skema normalisasi (3NF) di lingkungan Enterprise Data
Warehousing, skema bintang atau kepingan salju di data mart, atau skema hybrid dengan
komponen dari kedua teknik pemodelan klasik ini.
Apa itu Skema?

Skema adalah kumpulan objek database, termasuk tabel, tampilan, indeks, dan sinonim. Anda
dapat menyusun objek skema dalam model skema yang dirancang untuk pergudangan data
dalam berbagai cara. Sebagian besar gudang data menggunakan model dimensi.

Model data sumber Anda dan persyaratan pengguna membantu Anda mendesain skema gudang
data. Terkadang Anda bisa mendapatkan model sumber dari model data perusahaan perusahaan
Anda dan merekayasa balik model data logis untuk gudang data dari sini. Implementasi fisik dari
model gudang data logis mungkin memerlukan beberapa perubahan untuk menyesuaikannya
dengan parameter sistem Anda—ukuran komputer, jumlah pengguna, kapasitas penyimpanan,
jenis jaringan, dan perangkat lunak. Bagian penting dari perancangan skema adalah apakah akan
menggunakan skema bentuk normal ketiga, bintang, atau kepingan salju, dan ini akan dibahas
nanti.
C. Tentang Skema Bentuk Normal Ketiga

Desain Third Normal Form berusaha meminimalkan redundansi data dan menghindari anomali
dalam penyisipan, pembaruan, dan penghapusan data. Desain 3NF memiliki warisan panjang
dalam sistem pemrosesan transaksi online (OLTP). Sistem OLTP harus memaksimalkan kinerja
dan akurasi saat memasukkan, memperbarui, dan menghapus data. Transaksi harus ditangani
secepat mungkin atau bisnis mungkin tidak dapat menangani arus peristiwa, mungkin kehilangan
penjualan atau menimbulkan biaya lain. Oleh karena itu, desain 3NF menghindari manipulasi
data yang berlebihan dan meminimalkan penguncian tabel, yang keduanya dapat memperlambat
penyisipan, pembaruan, dan penghapusan. Desain 3NF juga berfungsi dengan baik untuk
mengabstraksi data dari kebutuhan aplikasi tertentu. Jika tipe data baru ditambahkan ke
lingkungan, Anda dapat memperluas model data dengan relatif mudah dan dampak minimal ke
aplikasi yang ada. Demikian juga, jika Anda memiliki jenis analisis yang benar-benar baru untuk
dilakukan di gudang data Anda, skema 3NF yang dirancang dengan baik akan dapat
menanganinya tanpa memerlukan struktur data yang didesain ulang.

Desain 3NF memiliki fleksibilitas yang tinggi, tetapi ada biayanya. Basis data 3NF menggunakan
sangat banyak tabel dan ini memerlukan kueri kompleks dengan banyak gabungan. Untuk model
perusahaan skala penuh yang dibangun dalam bentuk 3NF, lebih dari seribu tabel biasanya
ditemukan dalam skema. Dengan jenis kueri yang terlibat dalam pergudangan data, yang
seringkali membutuhkan akses ke banyak baris dari banyak tabel, desain ini memaksakan
pemahaman dan hukuman kinerja. Ini bisa menjadi rumit bagi pembuat kueri, apakah mereka
manusia atau alat dan aplikasi intelijen bisnis, untuk memilih dan menggabungkan tabel yang
diperlukan untuk bagian data tertentu ketika ada banyak tabel yang tersedia. Bahkan ketika tabel
dengan mudah dipilih oleh generator kueri, skema 3NF sering mengharuskan sejumlah besar
tabel digunakan dalam satu kueri. Lebih banyak tabel dalam kueri berarti lebih banyak jalur akses
data potensial, yang membuat pekerjaan pengoptimal kueri database menjadi lebih sulit. Hasil
akhirnya bisa menjadi kinerja kueri yang lambat.
Masalah kinerja kueri yang lambat dalam sistem 3NF tidak selalu terbatas pada kueri inti yang
digunakan untuk membuat laporan dan analisis. Itu juga dapat muncul dalam tugas yang lebih
sederhana dari pengguna yang menelusuri subset data untuk memahami kontennya. Demikian
pula, kompleksitas skema 3NF dapat berdampak pada pembuatan daftar pilihan data yang
digunakan untuk membatasi kueri dan laporan. Meskipun ini mungkin tampak masalah yang
relatif kecil, waktu respons yang cepat untuk proses tersebut membuat dampak besar pada
kepuasan pengguna.
Gambar 2-1 menyajikan fragmen kecil dari Skema 3NF. Perhatikan bagaimana informasi pesanan
dipecah menjadi barang pesanan dan pesanan untuk menghindari penyimpanan data yang
berlebihan. Tanda "kaki gagak" pada hubungan antar tabel menunjukkan hubungan satu ke
banyak di antara entitas. Jadi, satu pesanan mungkin memiliki beberapa item pesanan, satu
pelanggan mungkin memiliki banyak pesanan, dan satu produk dapat ditemukan di banyak item
pesanan. Meskipun diagram ini menunjukkan kasus yang sangat kecil, Anda dapat melihat bahwa
meminimalkan redundansi data dapat menyebabkan banyak tabel dalam skema.

Tentang Normalisasi

Normalisasi adalah proses desain data yang memiliki tujuan tingkat tinggi untuk menjaga setiap
fakta hanya di satu tempat untuk menghindari redundansi data dan menyisipkan, memperbarui,
dan menghapus anomali. Ada beberapa tingkat normalisasi, dan bagian ini menjelaskan tiga yang
pertama. Mempertimbangkan betapa mendasarnya istilah bentuk normal ketiga (3NF), masuk
akal untuk melihat bagaimana 3NF tercapai.
Pertimbangkan situasi di mana Anda melacak penjualan. Entitas inti yang Anda lacak adalah
pesanan penjualan, di mana setiap pesanan penjualan berisi detail tentang setiap item yang
dibeli (disebut sebagai item baris): namanya, harga, kuantitas, dan seterusnya. Pesanan juga
berisi nama dan alamat pelanggan dan banyak lagi. Beberapa pesanan memiliki banyak item baris
yang berbeda, dan beberapa pesanan hanya memiliki satu.
Dalam bentuk normal pertama (1NF), tidak ada kelompok data yang berulang dan tidak ada baris
duplikat. Setiap persimpangan baris dan kolom (bidang) hanya berisi satu nilai, dan tidak ada grup
kolom yang berisi fakta yang sama. Untuk menghindari duplikat baris, ada kunci utama. Untuk
pesanan penjualan, dalam bentuk normal pertama, beberapa item baris dari setiap pesanan
penjualan dalam satu bidang tabel tidak ditampilkan. Selain itu, tidak akan ada beberapa kolom
yang menampilkan item baris.
Kemudian muncul bentuk normal kedua (2NF), di mana desainnya dalam bentuk normal pertama
dan setiap kolom bukan kunci bergantung pada kunci utama lengkap. Dengan demikian, item
baris dipecah menjadi tabel item baris pesanan penjualan di mana setiap baris mewakili satu item
baris dari satu pesanan. Anda dapat melihat tabel item baris dan melihat bahwa nama item yang
dijual tidak bergantung pada kunci utama tabel item baris: item penjualan adalah entitasnya
sendiri. Oleh karena itu, Anda memindahkan item penjualan ke tabelnya sendiri yang
menunjukkan nama item. Harga yang dikenakan untuk setiap item dapat bervariasi berdasarkan
pesanan (misalnya, karena diskon) sehingga tetap ada di tabel item baris. Dalam hal pesanan
penjualan, nama dan alamat pelanggan tidak bergantung pada kunci utama pesanan penjualan:
pelanggan adalah entitasnya sendiri. Dengan demikian, Anda memindahkan kolom nama dan
alamat pelanggan ke dalam tabel informasi pelanggan mereka sendiri.
Selanjutnya adalah bentuk normal ketiga, dimana tujuannya adalah untuk memastikan tidak ada
ketergantungan pada atribut bukan kunci. Jadi tujuannya adalah untuk mengambil kolom yang
tidak berhubungan langsung dengan subjek baris (kunci utama), dan meletakkannya di tabel
mereka sendiri. Jadi detail tentang pelanggan, seperti nama pelanggan atau kota pelanggan,
harus diletakkan di tabel terpisah, dan kemudian kunci asing pelanggan ditambahkan ke tabel
pesanan.
Contoh lain tentang perbedaan tabel 2NF dari tabel 3NF adalah tabel pemenang turnamen tenis
yang berisi kolom turnamen, tahun, pemenang, dan tanggal lahir pemenang. Dalam hal ini,
tanggal lahir pemenang rentan terhadap inkonsistensi, karena orang yang sama dapat
ditampilkan dengan tanggal lahir yang berbeda dalam catatan yang berbeda. Cara untuk
menghindari masalah potensial ini adalah dengan memecah meja menjadi satu untuk pemenang
turnamen, dan satu lagi untuk tanggal lahir pemain.
Konsep Desain untuk Skema 3NF

Bagian berikut membahas beberapa konsep dasar ketika memodelkan lingkungan pergudangan
data menggunakan pendekatan skema 3NF. Tujuannya bukan untuk membahas landasan
teoretis untuk pemodelan 3NF (atau bahkan tingkat normalisasi yang lebih tinggi), tetapi untuk
menyoroti beberapa komponen kunci yang relevan untuk pergudangan data.
Beberapa konsep kunci desain skema 3NF yang relevan dengan data warehousing adalah sebagai
berikut:

 Mengidentifikasi Kunci Utama Kandidat

 Hubungan Kunci Asing dan Batasan Integritas Referensial
 Denormalisasi
Mengidentifikasi Kunci Utama Kandidat

Kunci utama adalah atribut yang secara unik mengidentifikasi catatan tertentu dalam tabel. Kunci
utama dapat diidentifikasi melalui satu atau beberapa kolom. Biasanya lebih disukai untuk
mencapai identifikasi unik melalui kolom sesedikit mungkin - idealnya satu atau dua - dan
menggunakan kolom yang kemungkinan besar tidak akan diperbarui atau bahkan diubah secara
massal. Jika model data Anda tidak mengarah pada identifikasi unik sederhana melalui
atributnya, Anda akan memerlukan terlalu banyak atribut untuk mengidentifikasi satu catatan
secara unik, atau data rentan terhadap perubahan, penggunaan kunci pengganti sangat
disarankan.
Secara khusus, skema 3NF bergantung pada identifikasi unik yang tepat dan sederhana karena
kueri cenderung memiliki banyak gabungan tabel dan semua kolom yang diperlukan untuk
mengidentifikasi catatan secara unik diperlukan sebagai kondisi gabungan untuk menghindari
duplikasi baris melalui gabungan.
Hubungan Kunci Asing dan Batasan Integritas Referensial
Skema 3NF di lingkungan pergudangan data sering kali menyerupai model data sistem sumber
OLTP, di mana konsistensi logis antara entitas data diekspresikan dan ditegakkan melalui
hubungan kunci utama - kunci asing, juga dikenal sebagai hubungan induk-anak. Kunci asing
menyelesaikan hubungan 1-ke-banyak dalam sistem relasional dan memastikan konsistensi logis:
misalnya, Anda tidak dapat memiliki item baris pesanan tanpa header pesanan, atau karyawan
yang bekerja untuk departemen yang tidak ada.
Sementara referensial seperti itu selalu diterapkan dalam sistem OLTP, sistem data warehousing
sering menerapkannya sebagai kondisi deklaratif dan tidak diberlakukan, mengandalkan proses
ETL untuk memastikan konsistensi data. Bila memungkinkan, kunci asing dan batasan integritas
referensial harus didefinisikan sebagai kondisi yang tidak diterapkan, karena memungkinkan
optimalisasi kueri dan perkiraan kardinalitas yang lebih baik.
Denormalisasi

Pemodelan normal yang tepat cenderung menguraikan entitas logis - seperti pelanggan. produk,
atau pesanan - ke dalam banyak tabel fisik, bahkan membuat pengambilan informasi sederhana
yang dirasakan membutuhkan untuk menggabungkan banyak tabel. Meskipun ini bukan masalah
dari perspektif pemrosesan kueri, hal ini dapat membebani pengembang aplikasi (untuk menulis
kode) maupun database (untuk menggabungkan informasi yang selalu digunakan bersama-
sama). Tidak jarang melihat beberapa tingkat denormalisasi yang masuk akal dalam model
pergudangan data 3NF, dalam bentuk logis sebagai tampilan atau dalam bentuk fisik melalui
tabel yang sedikit didenormalisasi.
Perawatan harus dilakukan dengan denormalisasi fisik untuk mempertahankan bentuk subjek-
netral dan oleh karena itu fleksibilitas implementasi fisik skema 3NF.

D. Tentang Skema Bintang

Skema bintang sering ditemukan dalam sistem pergudangan data dengan data mart logis atau
fisik yang tertanam. Istilah skema bintang adalah cara lain untuk merujuk pada pendekatan
"pemodelan dimensi" untuk mendefinisikan model data Anda. Sebagian besar deskripsi
pemodelan dimensi menggunakan terminologi yang diambil dari karya Ralph Kimball, konsultan
perintis dan penulis di bidang ini. Pemodelan dimensi menciptakan beberapa skema bintang,
masing-masing berdasarkan proses bisnis seperti pelacakan penjualan atau pengiriman. Setiap
skema bintang dapat dianggap sebagai data mart, dan mungkin sedikitnya 20 data mart dapat
memenuhi kebutuhan intelijen bisnis suatu perusahaan. Dibandingkan dengan desain 3NF,
jumlah tabel yang terlibat dalam pemodelan dimensi adalah sebagian kecil. Banyak skema
bintang akan memiliki di bawah selusin tabel. Skema bintang dirajut bersama melalui dimensi
yang sesuai dan fakta yang sesuai. Dengan demikian, pengguna bisa mendapatkan data dari
beberapa skema bintang dengan sedikit usaha.
Tujuan skema bintang adalah kesederhanaan struktural dan pengambilan data kinerja tinggi.
Karena sebagian besar kueri di era modern dihasilkan oleh alat dan aplikasi pelaporan, sangat
penting untuk membuat pembuatan kueri nyaman dan andal untuk alat dan aplikasi. Faktanya,
banyak alat dan aplikasi intelijen bisnis dirancang dengan harapan bahwa representasi skema
bintang akan tersedia untuk mereka.
Diskusi skema bintang kurang disarikan dari database fisik daripada deskripsi 3NF. Hal ini
disebabkan penekanan pragmatis pemodelan dimensi pada kebutuhan pengguna intelijen bisnis.

Perhatikan betapa berbedanya gaya pemodelan dimensi dari pendekatan 3NF yang
meminimalkan redundansi data dan risiko anomali pembaruan/inset/hapus. Skema bintang
menerima redundansi data (denormalisasi) dalam tabel dimensinya demi kemudahan
pemahaman pengguna dan kinerja pengambilan data yang lebih baik. Kritik umum dari skema
bintang adalah bahwa mereka membatasi fleksibilitas analisis dibandingkan dengan desain 3NF.
Namun, model dimensi yang dirancang dengan baik dapat diperluas untuk memungkinkan jenis
analisis baru, dan skema bintang telah berhasil selama bertahun-tahun di perusahaan terbesar.
Seperti disebutkan sebelumnya, pendekatan modern untuk pergudangan data tidak mengadu
skema bintang dan 3NF satu sama lain. Sebaliknya, kedua teknik digunakan, dengan lapisan dasar
3NF - Gudang Data Perusahaan 3NF, bertindak sebagai data batuan dasar, dan skema bintang
sebagai bagian utama dari lapisan pengoptimalan akses dan kinerja.
Tentang Fakta dan Dimensi dalam Skema Bintang

Skema bintang membagi data menjadi fakta dan dimensi. Fakta adalah ukuran dari beberapa
peristiwa seperti penjualan dan biasanya berupa angka. Dimensi adalah kategori yang Anda
gunakan untuk mengidentifikasi fakta, seperti tanggal, lokasi, dan produk.
Nama "skema bintang" berasal dari fakta bahwa diagram skema biasanya menunjukkan tabel
fakta pusat dengan garis yang menghubungkannya ke tabel dimensi, sehingga kesan grafisnya
mirip dengan bintang. Gambar 2-2 adalah contoh sederhana dengan penjualan sebagai tabel
fakta dan produk, waktu, pelanggan, dan saluran sebagai tabel dimensi.

Tentang Tabel Fakta di Gudang Data

Tabel fakta memiliki data pengukuran. Mereka memiliki banyak baris tetapi biasanya tidak
banyak kolom. Tabel fakta untuk perusahaan besar dapat dengan mudah menampung miliaran
baris. Untuk banyak skema bintang, tabel fakta akan mewakili lebih dari 90 persen dari total
ruang penyimpanan. Tabel fakta memiliki kunci komposit yang terdiri dari kunci utama tabel
dimensi skema.

Tabel fakta berisi fakta tingkat detail atau fakta yang telah dikumpulkan. Tabel fakta yang berisi
kumpulan fakta sering disebut tabel ringkasan. Sebuah tabel fakta biasanya berisi fakta dengan
tingkat agregasi yang sama. Meskipun sebagian besar fakta adalah aditif, mereka juga bisa
menjadi semi-aditif atau non-aditif. Fakta aditif dapat dikumpulkan dengan penjumlahan
aritmatika sederhana. Contoh umum dari ini adalah penjualan. Fakta non-aditif tidak dapat
ditambahkan sama sekali. Contohnya adalah rata-rata. Fakta semi-aditif dapat diagregasikan
sepanjang beberapa dimensi dan tidak bersama yang lain. Contohnya adalah tingkat inventaris
yang disimpan di gudang fisik, di mana Anda mungkin dapat menambahkan di seluruh dimensi
situs gudang, tetapi Anda tidak dapat mengagregasi lintas waktu.
Dalam hal menambahkan baris ke data dalam tabel fakta, ada tiga pendekatan utama:

 Berbasis transaksi
Menampilkan baris untuk detail level terbaik dalam sebuah transaksi. Baris dimasukkan hanya
jika transaksi telah terjadi untuk kombinasi nilai dimensi tertentu. Ini adalah jenis tabel fakta yang
paling umum.

 Snapshot Berkala
Menampilkan data pada akhir interval waktu reguler, seperti harian atau mingguan. Jika baris
untuk snapshot ada di periode sebelumnya, baris dimasukkan untuknya di periode baru
meskipun tidak ada aktivitas yang terkait dengannya yang terjadi dalam interval terakhir. Jenis
tabel fakta ini berguna dalam proses bisnis yang kompleks di mana sulit untuk menghitung nilai
snapshot dari baris transaksi individual.

 Mengumpulkan Snapshot
Menampilkan satu baris untuk setiap kemunculan proses berumur pendek. Baris berisi beberapa
tanggal yang melacak tonggak utama dari proses berumur pendek. Tidak seperti dua jenis tabel
fakta lainnya, baris dalam snapshot yang terakumulasi diperbarui beberapa kali saat proses yang
dilacak bergerak maju.
Tentang Tabel Dimensi di Gudang Data
Tabel dimensi menyediakan data kategori untuk memberikan konteks pada data fakta. Misalnya,
skema bintang untuk data penjualan akan memiliki tabel dimensi untuk produk, tanggal, lokasi
penjualan, promosi, dan lainnya. Tabel dimensi bertindak sebagai tabel pencarian atau referensi
karena informasinya memungkinkan Anda memilih nilai yang digunakan untuk membatasi kueri
Anda. Nilai dalam banyak tabel dimensi mungkin jarang berubah. Sebagai contoh, dimensi
geografi yang menunjukkan kota mungkin cukup statis. Namun ketika nilai dimensi berubah,
sangat penting untuk memperbaruinya dengan cepat dan andal. Tentu saja, ada situasi di mana
nilai dimensi gudang data sering berubah. Dimensi pelanggan untuk suatu perusahaan pasti akan
sering mengalami pembaruan dan penghapusan.
Aspek kunci dari tabel dimensi adalah informasi hierarki yang mereka berikan. Data dimensi
biasanya memiliki baris untuk tingkat detail terendah ditambah baris untuk nilai dimensi
gabungan. Rollup atau agregasi alami ini dalam tabel dimensi disebut hierarki dan menambah
nilai besar untuk analisis. Misalnya, jika Anda ingin menghitung pangsa penjualan yang diwakili
produk tertentu dalam kategori produk spesifiknya, jauh lebih mudah dan lebih dapat diandalkan
untuk memiliki hierarki yang telah ditentukan sebelumnya untuk agregasi produk daripada
menentukan semua elemen kategori produk di masing-masing pertanyaan. Karena informasi
hierarki sangat berharga, biasanya ditemukan banyak hierarki yang tercermin dalam tabel
dimensi.
Tabel dimensi biasanya tekstual dan deskriptif, dan Anda akan menggunakan nilainya sebagai
tajuk baris, tajuk kolom, dan tajuk halaman dari laporan yang dihasilkan oleh kueri Anda.
Meskipun tabel dimensi memiliki baris yang jauh lebih sedikit daripada tabel fakta, tabel ini bisa
sangat lebar, dengan lusinan kolom. Tabel dimensi lokasi mungkin memiliki kolom yang
menunjukkan setiap tingkat hierarki rollupnya, dan mungkin menampilkan beberapa hierarki
yang tercermin dalam tabel. Tabel dimensi lokasi dapat memiliki kolom untuk penggabungan
geografisnya, seperti alamat jalan, kode pos, kota, negara bagian/provinsi, dan negara. Tabel
yang sama dapat menyertakan hierarki rollup yang disiapkan untuk organisasi penjualan, dengan
kolom untuk distrik penjualan, wilayah penjualan, wilayah penjualan, dan karakteristik.

Konsep Desain dalam Skema Bintang

Di sini kita menyentuh beberapa istilah kunci yang digunakan dalam skema bintang. Ini sama
sekali bukan satu set lengkap, tetapi dimaksudkan untuk menyoroti beberapa area yang layak
Anda pertimbangkan.
Butir Data
Salah satu tugas terpenting saat mendesain model Anda adalah mempertimbangkan tingkat
detail yang akan diberikannya, yang disebut sebagai butir data. Pertimbangkan skema penjualan:
apakah biji-bijian akan sangat baik, menyimpan setiap barang yang dibeli oleh setiap pelanggan?
Atau apakah itu akan menjadi butiran kasar, hanya menyimpan total penjualan harian untuk
setiap produk di setiap toko? Dalam pergudangan data modern ada penekanan kuat pada
penyediaan data butir terbaik, karena ini memungkinkan daya analitik maksimum. Pakar
pemodelan dimensi umumnya merekomendasikan bahwa setiap tabel fakta menyimpan hanya
satu tingkat butir. Menyajikan data fakta dalam tabel butir tunggal mendukung kueri dan
pemeliharaan tabel yang lebih andal, karena tidak ada ambiguitas tentang cakupan baris mana
pun dalam tabel fakta.
Bekerja dengan Skema Beberapa Bintang
Karena pendekatan desain skema bintang dimaksudkan untuk membagi data ke dalam proses
yang berbeda, Anda memerlukan cara yang andal dan berkinerja tinggi untuk melintasi skema
saat kueri menjangkau beberapa skema. Salah satu istilah untuk kemampuan ini adalah arsitektur
bus data warehouse. Arsitektur bus data warehouse dapat dicapai dengan dimensi yang sesuai
dan fakta yang sesuai.
Dimensi yang Sesuai
Dimensi yang sesuai berarti bahwa dimensi dirancang secara identik di berbagai skema bintang.
Dimensi yang sesuai menggunakan nilai, nama kolom, dan tipe data yang sama secara konsisten
di beberapa bintang. Dimensi yang sesuai tidak harus berisi jumlah baris yang sama di setiap
salinan tabel dimensi skema, selama baris dalam tabel yang lebih pendek adalah subset
sebenarnya dari tabel yang lebih besar.