DATA WAREHOUSE DESIGN

Diajukan untuk memenuhi salah satu mata kuliah Sistem Informasi Manajemen
dan Database

Dosen Pengampu : Arief Nurhandika, S.E., M.Ak,

Disusun Oleh:
Kelompok 4
1. Della Restu Pratiwi 20220610138
2. Ida Nurfarida 20220610155
3. Risa Suci Lestari 20220610152
4. Wulan Salma Hana 20220610045

Kelas : AKUNC-2022-02

PROGRAM STUDI AKUNTANSI

FAKULTAS EKONOMI DAN BISNIS
UNIVERSITAS KUNINGAN
2023
 KATA PENGANTAR

Puji syukur kami panjatkan kepada kehadirat Tuhan Yang Maha Esa karena atas
segala rahmat dan karunia-Nya sehingga tugas makalah kami yang berjudul “Data Warehouse
Design” ini dapat kami selesaikan. Adapun tujuan dari pembuatan makalah ini adalah untuk
memenuhi tugas mata kuliah Sistem Informasi Manajemen dan Database. Semua konsep
yang dibahas dalam makalah ini tentunya bertujuan untuk memberikan penjelasan serta
pemahaman yang mendalam mengenai Data Warehouse Design. Semoga makalah ini
memberikan banyak manfaat bagi seluruh pihak terutama para pembaca untuk dapat lebih
memahami Data Warehouse Design.

Dalam proses penyusunan makalah ini tentu tidak terlepas dari bantuan, dukungan,
dan bimbingan serta motivasi dari berbagai pihak terkait. Oleh karena itu, dalam kesempatan
yang berbahagia ini kami ingin mengucapkan terima kasih yang sebesar-besarnya kepada :

1. Bapak Arief Nurhandika, S.E., M.Ak. selaku dosen pengampu mata kuliah Sistem
Informasi dan Database.
2. Yang tercinta, Orang tua kami yang telah memberikan dukungan dan motivasi dalam
proses pembelajaran serta penyusunan makalah ini.
3. Seluruh rekan-rekan mahasiswa kelas AKUNC-02-2022 yang telah memberikan
semangat dan apresiasi posistifnya kepada kami.
4. Dan yang paling utama, kami mengucapkan terima kasih kepada diri kami sendiri
yang telah berhasil menyelesaikan tugas makalah ini dengan baik.

Kami selaku penulis menyadari bahwa makalah yang telah kami susun ini masih
terdapat banyak sekali kekurangan baik dari segi isi maupun teknik penulisannya. Untuk itu
kami mengharapkan kritik dan saran yang membangun demi kesempurnaan makalah ini.
Demikian makalah ini kami buat, semoga dapat memberikan esensi yang tinggi bagi kita
semua.

Kuningan, 7 Desember 2023

Kelompok 4

i
 DAFTAR ISI

KATA PENGANTAR..................................................................................................................i
DAFTAR ISI..............................................................................................................................ii
BAB I.........................................................................................................................................1
PENDAHULUAN......................................................................................................................1
1.1 Latar Belakang.............................................................................................................1
1.2 Rumusan Masalah.......................................................................................................1
1.3 Tujuan..........................................................................................................................1
BAB II........................................................................................................................................3
PEMBAHASAN........................................................................................................................3
2.1 Merancang Penggunaan Data Warehouse Database Design............................................3
2.2 Pemodelan Dimensi.........................................................................................................4
2.2.1 Perbandingan model DM dan ER.............................................................................8
2.3 Metodologi Desain Basis Data untuk Gudang Data.......................................................9
2.4 Kriteria untuk Menilai Dimensi Data Warehouse..........................................................17
2.5 Desain Data Warehousing Menggunakan Oracle...........................................................18
2.5.1 Komponen Pembuat Repositori Oracle...................................................................19
2.5.2 Menggunakan Oracle Warehouse Builder...............................................................20
BAB III.....................................................................................................................................27
PENUTUP................................................................................................................................27
3.1 Kesimpulan................................................................................................................27
3.2 Saran..........................................................................................................................28
DAFTAR PUSTAKA...............................................................................................................29

ii
 BAB I
PENDAHULUAN
1.1 Latar Belakang

Di era globalisasi dan persaingan bisnis yang semakin meningkat, organisasi

harus mengambil keputusan yang cerdas dan tepat waktu untuk mempertahankan dan
meningkatkan daya saingnya. Keputusan berdasarkan informasi yang akurat dan
relevan adalah kunci keberhasilan yang paling penting. Namun, karena pesatnya
pertumbuhan jumlah dan variasi informasi yang dihasilkan oleh berbagai sistem
operasi, organisasi sering kali menghadapi tantangan dalam mengelola dan
menganalisis informasi secara efektif.
Di sinilah konsep Data Warehouse menjadi sangat penting. Data Warehouse
merupakan gudang data terintegrasi yang dirancang khusus untuk mendukung proses
pengambilan keputusan. Dengan merancang gudang data yang tepat, organisasi dapat
mengintegrasikan data dari berbagai sumber, membersihkannya, dan mengaturnya
secara terstruktur. Hal ini tidak hanya memfasilitasi akses terhadap informasi, tetapi
juga memungkinkan organisasi untuk melakukan analisis mendalam, mengidentifikasi
tren dan memprediksi perubahan pasar.
Pentingnya desain data warehouse terletak pada kemampuannya untuk
memberikan pandangan holistik terhadap data perusahaan, memfasilitasi pengambilan
keputusan berdasarkan fakta, dan memastikan ketersediaan data yang konsisten. Oleh
karena itu, makalah ini membahas konsep data warehouse design secara mendalam.

1.2 Rumusan Masalah

1. Bagaimana merancang penggunaan Data Warehouse Database Design?

2. Bagaimana Pemodelan Dimensi?
3. Bagaimana metodologi desain basis data untuk data wearhouse?
4. Bagaiamana kriteria untuk menilai data warehouse dimensions?
5. Bagaimana merancang data warehouse menggunakan produk Oracle?

1.3 Tujuan

1. Untuk mengetahui dan memahami bagaimana merancang penggunaan Data

Warehouse Database Design.
2. Untuk mengetahui dan memahami Pemodelan Dimensi.
3. Untuk mengetahui dan memahami metodologi desain basis data untuk data
werehouse.

1
4. Untuk mengetahui dan memahami kriteria untuk menilai data warehouse
dimensions.
5. Untuk mengetahui dan memahami Bagaimana merancang data warehouse
menggunakan produk Oracle

2
 BAB II
PEMBAHASAN

2.1 Merancang Penggunaan Data Warehouse Database Design

Sebelum membahas data warehouse design lebih lanjut, kita akan menjelaskan
kembali pengertian data warehouse terlebih dahulu.
Data warehouse adalah pusat penyimpanan data dari suatu
organisasi/perusahaan. Misalnya: data penjualan, transaksi keuangan, cover asuransi, statistik
permainan olahraga, dll.
Pengertian Data Warehouse Design menurut para ahli yaitu :
- W.H. Inmon dan Richard D.H
Warehousing adalah koleksi data yang mempunyai sifat berorientasi subjek,
terintegrasi,
time-variant, dan bersifat tetap dari koleksi data dalam mendukung proses
pengambilan keputusan management.
- Vidette Poe
Data warehousing merupakan basisdata yang bersifat analisis dan read only yang
digunakan sebagai fondasi dari sistem penunjang keputusan.
- Paul Lane
Data warehousing merupakan basisdata relasional yang didesain lebih kepada query
dan analisa dari pada proses transaksi, biasanya mengandung history data dari proses
transaksi dan bisa juga data dari sumber lainnya.
Merancang database informasi warehouse sangatlah kompleks. Untuk memulai
proyek gudang data, kita perlu memiliki pemahaman yang jelas tentang pertanyaan-
pertanyaan berikut: apa kebutuhan pengguna yang paling penting, dan data apa yang harus
diperbarui sesegera mungkin? apa kebutuhan pengguna yang paling penting, dan data apa
yang harus diperbarui sesegera mungkin? Selain dari itu, apakah proyek ini diperlukan untuk
berskala kecil dan lebih mudah dikelola, namun pada saat yang sama menyediakan
infrastruktur yang pada akhirnya dapat menyediakan gudang data berskala besar untuk semua
bisnis? Pertanyaan seperti ini menyoroti beberapa isu paling penting dalam pengembangan
data warehouse. Bagi banyak perusahaan solusinya adalah data mart yang sudah dijelaskan di
BAB 31.5. Data marts memungkinkan desainer untuk membangun sesuatu yang jauh lebih
sederhana dan dapat dicapai untuk kelompok pengguna tertentu. Hanya sedikit perancang

3
yang bersedia berkomitmen untuk membuat desain di seluruh perusahaan yang harus
memenuhi semua kebutuhan pengguna dalam satu waktu. Namun, terlepas dari solusi
sementara untuk membangun data mart, tujuannya tetap sama; penciptaan akhir dari gudang
data yang mendukung kebutuhan perusahaan.

Fase pengumpulan dan analisis dari proyek gudang data melibatkan wawancara
dengan anggota staf yang cocok seuperti pemakai pemasaran, pemakai keuangan, pemakai
penjualan, pemakai operasional, dan manajemen untuk memungkinkan identifikasi indikator
kinerja utama yang diprioritaskan untuk bisnis yang perlu dipantau oleh gudang data. Pada
periode yang serupa, wawancara dilakukan dengan anggota staf yang bertanggung jawab atas
Pemrosesan Transaksi Online (OLTP) untuk mengidentifikasi, sumber data mana yang bisa
menyediakan data yang bersih, valid, dan konsisten yang akan tetap didukung selama
beberapa tahun ke depan.

Wawancara memberikan informasi yang diperlukan untuk tampilan top-down

(kebutuhan pengguna) dan tampilan bottom-up (sumber data apa yang tersedia) dari data
warehouse. Dengan kedua pandangan ini, kami siap untuk memulai proses perancangan data
warehouse.

Komponen data data dasar gudang gudang dijelaskan menggunakan teknik yang
dikenal sebagai pemodelan dimensi . _komponen data dasar dijelaskan menggunakan teknik
yang dikenal sebagai pemodelan dimensi . Pada bagian selanjutnya , Berikutnya pertama -
tama kami akan menjelaskan beberapa konsep yang terkait dengan model dimensi dan
membandingkannya dengan model Entity-Relationship ( ER) tradisional ( lihat Bab 11 dan
12).

Kemudian, dengan menggunakan metodologi metodologi langkah demi

langkah ,langkah membuat model tiga dimensi menggunakan sampel pekerjaan
menggunakan sampel pekerjaan dari versi dari diperlukan untuk studi DreamHome.

2.2 Pemodelan Dimensi

Pemodelan dimensi menggunakan konsep pemodelan Entity-Relationship (ER)

dengan beberapa batasan penting. Setiap model dimensi (DM) terdiri dari satu tabel dengan
kunci utama komposit, yang disebut tabel fakta, dan sekumpulan tabel yang lebih kecil yang

4
disebut tabel dimensi. Setiap tabel dimensi memiliki kunci primer sederhana (non- komposit)
yang sesuai dengan salah satu komponen kunci komposit dalam tabel fakta. Dengan kata lain,
kunci utama dari tabel fakta terdiri dari dua atau lebih kunci asing. Struktur 'seperti bintang'
yang khas ini disebut skema bintang atau gabungan bintang. Contoh skema bintang untuk
penjualan properti DreamHome ditunjukkan pada Gambar 32.1. Perhatikan bahwa kunci
asing (diberi label {FK}) disertakan dalam model dimensi.

Fitur penting lainnya dari DM adalah bahwa semua kunci alami diganti dengan kunci
pengganti. Ini berarti bahwa setiap gabungan antara tabel fakta dan tabel dimensi didasarkan
pada kunci pengganti, bukan kunci alami. Setiap kunci pengganti harus memiliki struktur
umum berdasarkan bilangan bulat sederhana. Penggunaan surrogate key memungkinkan data
di gudang memiliki independensi dari data yang digunakan dan dihasilkan oleh sistem OLTP.
Sebagai contoh, setiap cabang memiliki kunci alami, yaitu branchNo dan juga kunci
pengganti yaitu branchID.

Skema bintang mengeksploitasi karakteristik data faktual sehingga fakta dihasilkan

oleh peristiwa yang terjadi di masa lalu, dan tidak mungkin berubah, terlepas dari bagaimana
mereka dianalisis. Karena sebagian besar data dalam data warehouse direpresentasikan
sebagai fakta, tabel fakta dapat menjadi sangat besar relatif terhadap tabel dimensi. Dengan
demikian, penting untuk memperlakukan data fakta sebagai data referensi hanya-baca yang
tidak akan berubah dari waktu ke waktu. Tabel fakta yang paling berguna berisi satu atau
lebih ukuran numerik, atau 'fakta', yang terjadi untuk setiap record. Pada Gambar 32.1, fakta-
fakta tersebut adalah offerPrice, sellingPrice, saleCommission, dan saleRevenue. Fakta yang
paling berguna dalam tabel fakta adalah numerik dan aditif karena aplikasi data warehouse
hampir tidak pernah mengakses satu record; sebaliknya, mereka mengakses ratusan, ribuan,
atau bahkan jutaan record dalam satu waktu dan hal yang paling berguna untuk dilakukan
dengan begitu banyak record adalah menggabungkannya.

5
 Skema bintang bisa digunakan kepada menyelak daya kueri tambah
mendenormalisasi keterangan rujukan ke bagian dalam skedul faset tunggal. Sebagai contoh,
ambang Gambar 32.1, camkan bahwa sejumlah skedul faset (yaitu PropertyForSale, Branch,
ClientBuyer, Staff, dan Owner) mengandung bukti lokasi (kota, wilayah, dan negara), yang
diulang-ulang. Denormalisasi betul digunakan momen tersua beberapa jasad yang teruit
tambah skedul faset yang kencang diakses, sehingga tidak terlazim mengerjakan join ke
skedul lain kepada mengakses simbol-simbol tersebut. Denormalisasi tidak sepikiran jika
bukti embel-embel tidak terlalu kencang diakses, karena overhead pemindaian skedul faset
yang diperluas bertemu tidak diimbangi tambah laba bagian dalam daya kueri.

6
 Terdapat disparitas ambang rancangan bintang yang disebut rancangan paruhan salju,
yang memungkinkan perspektif memegang perspektif. Sebagai contoh, kita bisa
menormalkan keterangan lingkungan (tanda pengenal kota, wilayah, dan negara) di catatan
perspektif Cabang ambang Gambar 32.reservoir menjelang menyelenggarakan dua catatan
perspektif baru yang disebut Kota dan Wilayah. Versi normalisasi pecah catatan perspektif
Cabang pecah rancangan penjualan milik ditunjukkan ambang Gambar 32.2. Dalam
rancangan snowflake, keterangan lingkungan di catatan perspektif PropertyForSale,
ClientBuyer, Staff, dan Owner juga akan dihapus dan catatan perspektif City dan Region
yang baru akan dibagi tambah catatan-catatan ini.

Skema sejadah fakta yang paling cocok memperuntukkan bauran rangka bintang yang
didenormalisasi dan rangka pecahan salju yang tidak didenormalisasi. Kombinasi rangka
bintang dan snowflake ini disebut rangka starflake. Beberapa bagian bisa tampil bagian
dalam kedua arsitektur kepada memufakati kehendak kueri yang berbeda. Apakah rangka itu
bintang, pecahan salju, atau pecahan bintang, arsitektur yang bisa diprediksi dan pokok
berusul anutan bagian yang mendasarinya menjual nilai penting bagian dalam jagat ruang
fakta terhitung:

- Efisiensi Konsistensi bentuk sejadah fakta yang melambari memungkinkan akses yang
lebih efisien ke fakta oleh berbagai aparat terhitung setia usaha komplain dan aparat
kueri.
- Kemampuan kepada menepik transmutasi kehendak Skema bintang bisa beradaptasi
tambah transmutasi kehendak pemakai, karena semua bagian selangkah bagian dalam hal
menahan akses ke sijil fakta. Ini bermakna bahwa desainnya lebih mampu memompong
kasus pemakai yang bersemangat ad hoc.
- Ekstensibilitas Model faset bisa diperluas; seumpama pola bentuk masyarakat yang harus
didukung oleh DM meliputi:(a) (bagus) memuat evidensi baru kali evidensi termasuk
konsisten pakai p e r i n c i bagus n mendasar semenjak urutan evidensi yang terdapat;
(b) memuat faset baru, kali terdapat esa etos semenjak faset termasuk yang didefinisikan
menjelang setiap kritik evidensi yang terdapat;(c) memuat lambang faset baru; dan (d)

7
 bersimpang kritik faset yang terdapat ke tahap belah yang lebih rendah semenjak rintik
kala terhingga ke depan.
- Kemampuan menjelang memodelkan keadaan jual beli masyarakat semakin berlebihan
penghampiran konvensional menjelang mendebik keadaan pemodelan yang masyarakat
di kosmos jual beli. Setiap keadaan ini memegang setaraf preferensi yang dipahami pakai
ketakziman yang bisa secara distingtif diprogram bagian dalam klerek laporan, aparat
serahkan kueri, dan antarmuka pemakai lainnya; misalnya, faset yang bergeser secara
perlahan di mana faset 'konstan' seumpama Cabang atau Staf sebenarnya berevolusi
secara perlahan dan tidak sinkron. Kami mengomongkan faset yang bergeser secara
perlahan secara lebih rinci di Bagian 32.3, Langkah 8.
- Pemrosesan kueri yang bisa diprediksi Aplikasi bukti warehouse yang melewati semata-
mata akan memuat lebih berlebihan lambang faset semenjak bagian dalam denah bintang
tunggal. Aplikasi yang melewati akan menalikan urutan evidensi yang terpencil bersama-
arah-arah menyeberangi faset bersama (sesuai). Meskipun integritas alur star schema
bagian dalam anutan faset perusahaan sangat kompleks, pemrosesan query sangat bisa
diprediksi karena hadirat tahap terendah, setiap urutan evidensi harus di-query secara
independen.

2.2.1 Perbandingan model DM dan ER

Pada putaran ini kita mengumpamakan dan memperlainkan teladan gatra (DM) pakai
teladan Entity-Relationship (ER). Seperti yang dijelaskan dekat putaran sebelumnya, DM
biasanya digunakan kepada merencanakan unsur database berbunga masukan warehouse
sedangkan teladan ER secara tradisional digunakan kepada menjabarkan database kepada tata
Online Transaction Processing (OLTP).Pemodelan ER adalah kiat kepada men catat pertautan
di jarak zat. Tujuan tonggak berbunga pemodelan ER adalah kepada melenyapkan redundansi
bagian dalam masukan. Hal ini sangat membangun kurang pemrosesan permufakatan karena
permufakatan dibuat sangat sederhana dan deterministik. Sebagai contoh, permufakatan yang
memperbarui alamat pelanggan biasanya mengakses esa record bagian dalam register Klien.
Akses ini sangat awal karena memperuntukkan perincian dekat sendi tonggak clientNo.
Namun, bagian dalam memperkuat pemrosesan permufakatan berperan efisien, database
sejenis itu tidak bisa secara efisien dan mudah menjunjung kueri pemakai risiko yang
berwatak ad hoc. Aplikasi jual beli tradisional sebagai pemesanan konsumen, kekuasaan stok,
dan faktur konsumen bermaksud berlebihan register pakai berlebihan rencah di jarak mereka.

8
Model ER kepada seimbang perusahaan bisa menyimpan ratusan zat logis, yang bisa
dipetakan ke ratusan register fisik. Pemodelan ER tradisional tidak menjunjung produk terima
tonggak berbunga pergudangan masukan, yaitu pengumpulan masukan yang intuitif dan
berkinerja tinggi.Kunci kepada menangkap pertautan jarak teladan gatra dan teladan Entity-
Relationship adalah bahwa teladan ER esa biasanya tercerai berperan sejumlah DM.
Beberapa DM kelak diasosiasikan menembusi register gatra 'bersama'. Kami menguraikan
pertautan jarak teladan ER dan DM secara lebih rinci di putaran berikut, di mana saya
menggelindingkan metodologi komposisi database kepada kamar masukan.

2.3 Metodologi Desain Basis Data untuk Gudang Data

Di bagian ini, kami menjelaskan metode langkah demi langkah dalam mendesain
database. Metode ini diusulkan oleh Kimball dan disebut ‘Metodologi Sembilan Langkah’
(Kimball, 1996). Langkah-langkah metode ini ditunjukkan pada Tabel 32.1. Ada banyak
pendekatan yang memberikan jalur alternatif untuk membuat gudang data. Salah satu
pendekatan yang berhasil adalah dengan membagi desain data warehouse menjadi beberapa
bagian yang lebih mudah dikelola, yaitu penyimpanan data. Sebagai langkah selanjutnya,
integrasi penyimpanan data yang lebih kecil mengarah pada penciptaan gudang data di
seluruh perusahaan. Jadi, gudang data adalah kombinasi penyimpanan data terpisah yang
diterapkan selama periode waktu tertentu, mungkin oleh tim teknik yang berbeda, dan
mungkin pada platform perangkat keras dan perangkat lunak yang berbeda. Metodologi
sembilan langkah mendefinisikan langkah-langkah yang diperlukan untuk merancang tanda
data. Namun, metode ini juga menggabungkan penyimpanan data yang terpisah sehingga
seiring waktu penyimpanan data tersebut bergabung menjadi satu penyimpanan data. Kami
sekarang menjelaskan secara rinci langkah-langkah yang ditunjukkan pada Tabel 32.1
menggunakan contoh yang diambil dari versi studi kasus DreamHome yang diperluas.

Langkah 1: Pilih proses

Proses (fungsi) mengacu pada topik penyimpanan data tertentu. Gudang data pertama yang
dibangun kemungkinan besar harus tepat waktu, sesuai anggaran, dan menjawab pertanyaan
bisnis yang paling mendesak. Opsi terbaik untuk tanda data pertama biasanya merupakan
opsi terkait penjualan. Sumber informasi ini biasanya mudah diakses dan berkualitas tinggi.
Saat kami memilih penyimpanan data pertama untuk DreamHome, kami pertama kali
menyadari bahwa proses bisnis DreamHome yang berbeda meliputi:

9
 - penjualan properti;
- penyewaan properti (leasing);
- menginvestigasi properti;
- promosi properti;
- perlindungan properti.

Kebutuhan bukti yang tersangkut tambah kiat-kiat ini ditunjukkan bagian dalam skema ER
muka Gambar 32.3. Perhatikan bahwa skema ER ini menakhlikkan babak berpunca
dokumentasi konstruksi, yang menjelajahkan susunan Pemrosesan Transaksi Online (OLTP)
yang diperlukan menjelang mengangkat kiat kulak DreamHome. Diagram ER muka
Gambar32.3 duga disederhanakan tambah menempatkan tanda semata-mata muka materi dan
koneksi asas dan dibuat tambah menginvestigasi Langkah reservoir dan
mengharamkanmenepis berpunca metodologi konstruksi database yang dijelaskan
sebelumnya di Bab 15 dan 16. Entitas yang diarsir mewakili kenyataan-kenyataan rumusan
menjelang setiap kiat kulak DreamHome. Proses kulak yang dipilih menjelang berperan bukti
mart perdana adalah penjualan properti. Bagian berpunca ER yang asli

10
Langkah 2: Pemilihan bilah

Memilih grain berarti memutuskan dengan tepat apa yang diwakili oleh entri dalam tabel
data. Misalnya, entitas PropertySale, yang diarsir pada gambar 32.4, mewakili fakta tentang
setiap penjualan properti dan menjadi tabel fakta untuk skema bintang Penjualan Properti
yang ditunjukkan sebelumnya pada gambar 32.1. Oleh karena itu, inti dari tabel fakta
PropertySale adalah penjualan properti individual. Hanya ketika tabel fakta dipilih, kita
dapat mengidentifikasi dimensi tabel fakta. Misalnya, entitas cabang, staf, pemilik, pembeli
pelanggan, properti, dan promosi pada Gambar 32.4 digunakan untuk merujuk pada data
terkait penjualan real estat dan merupakan tabel dimensi untuk skema bintang penjualan real
estat yang ditunjukkan sebelumnya pada gambar 32.1. Kami juga memasukkan waktu
sebagai dimensi inti yang selalu hadir dalam skema bintang. Keputusan target pada tabel
fakta juga menentukan target pada setiap tabel dimensi. Misalnya, jika judul tabel data
PropertySale adalah penjualan satu properti, maka judul dimensi ClientBuyer adalah
informasi tentang pelanggan yang membeli properti tersebut.

Langkah 3: Identifikasi dan sesuaikan dimensi

Dimensi memberikan konteks untuk mengajukan pertanyaan tentang fakta dalam tabel fakta.
Serangkaian pengukuran yang dibangun dengan baik membuat pemasaran data dapat
dimengerti dan mudah digunakan. Kami mendefinisikan dimensi dengan cukup detail untuk
mendeskripsikan hal-hal seperti pelanggan dan real estat secara akurat. Misalnya, dalam tabel
dimensi ClientBuyer, setiap pelanggan dijelaskan dengan atribut clientID, clientNo,
clientName, clientType, kota, wilayah, dan negara, seperti yang ditunjukkan pada Gambar

11
32.1. Seperangkat dimensi yang kurang terwakili atau tidak lengkap melemahkan kegunaan
penyimpanan data bagi bisnis.

Jika dua penyimpanan data mempunyai dimensi apa pun, keduanya harus sama persis, atau
salah satunya harus merupakan bagian matematis dari dimensi lainnya. Hanya dengan cara
ini dua penyimpanan data dapat berbagi satu atau lebih dimensi dalam satu aplikasi. Jika
suatu dimensi digunakan di lebih dari satu penyimpanan data, maka disebut
berkorespondensi. Contoh dimensi yang harus sesuai dengan penjualan properti dan
pencatatan properti adalah dimensi Waktu, PropertyForSale, Cabang, dan Promosi. Jika
dimensi ini tidak sinkron atau tidak sinkron antar pusat data, seluruh gudang data akan gagal

12
karena kedua penanda data tidak dapat diakses secara bersamaan. Misalnya, pada Gambar
32.5, kami menampilkan bagan bintang PropertyForSale dan PropertyPromotion dari waktu
ke waktu, dengan PropertyForSale, Cabang, dan Promosi sebagai dimensi terkait dalam
bayangan cahaya.

Langkah 4: Pilih fakta

Entitas dalam tabel fakta menentukan fakta mana yang dapat digunakan dalam penyimpanan
data. Semua fakta harus diungkapkan pada tingkat tertentu. Dengan kata lain, jika objek tabel
fakta adalah penjualan suatu properti, semua fakta numerik harus berhubungan dengan

13
penjualan tersebut. Selain itu, faktanya harus bersifat numerik dan dapat diringkas. Pada
Gambar 32.6, kami menggunakan diagram bintang dari proses sewa properti DreamHome
untuk mengilustrasikan tabel data yang tidak terstruktur dengan baik. Tabel data ini tidak
dapat digunakan dengan fakta non-numerik (promotionName dan staffName), fakta yang
tidak terkait (Sewa bulanan), dan fakta (pendapatan tahun lalu) yang memiliki presisi
berbeda dibandingkan fakta lain dalam tabel. Gambar 32.7 menunjukkan bagaimana tabel
fakta sewa direpresentasikan dalam gambar 32.6 dapat diperbaiki sehingga tabel data
terstruktur dengan baik. Fakta dapat ditambahkan ke tabel fakta kapan saja selama sesuai
dengan isi tabel.

Langkah 5: Menyimpan pra-perkiraan bagian dalam jadwal evidensi

Setelah evidensi-evidensi dipilih, setiap evidensi harus diperiksa ulang menjelang

menetapkan apakah kedapatan keleluasaan menjelang mengabdikan pra-perkiraan. Contoh
kebanyakan terbit tujuan menjelang mempunyai pra-perkiraan kelahirannya giliran evidensi-
evidensi terjalin terbit komplain faedah rugi. Situasi ini akan cekang tampil giliran jadwal
evidensi didasarkan ambang faktur atau penjualan. Gambar 32.7 menyinggir jadwal evidensi
tambah tanda pengenal rentDuration, totalRent, clientAllowance, staffCommission, dan
totalRevenue. Jenis-macam evidensi ini efektif karena berjuang adalah perhitungan aditif,
terbit mana kita bisa menggapai data berguna serupa rata-rata clientAllowance berdalil
penyatuan sejumlah komentar jadwal evidensi. Untuk mencacah totalPendapatan yang
dihasilkan lampu pijar penyewaan properti, abdi menyurutkan TunjanganKlien dan
KomisiStaf terbit totalSewa. Meskipun totalPendapatan selalu bisa ditemukan terbit tanda
pengenal-tanda pengenal ini, kita masih terlazim mempunyai totalPendapatan. Hal ini
terutama berlangsung menjelang etik yang sangat penting hisab perusahaan, serupa
totalPendapatan, atau jika kedapatan jalan pemakai mencacah totalPendapatan tambah tidak
benar. Biaya yang ditimbulkan terbit kekufuran pemakai bagian dalam mencacah putar
totalPendapatan bisadiimbangi tambah sejumput ongkos pengarsipan masukan yang
berlebihan.

Langkah 6: Lingkari bagan pengukuran

Pada titik ini, kita kembali ke tabel dimensi dan menambahkan sebanyak mungkin deskripsi
tekstual ke dimensi tersebut. Deskripsi teks harus seintuitif mungkin dan mudah dipahami

14
pengguna. Kegunaan penyimpanan data ditentukan oleh cakupan dan sifat atribut tabel
dimensi.

Langkah 7: Pilih durasi database

Durasi mengukur seberapa jauh ke belakang tabel fakta berada. Banyak perusahaan perlu
melihat periode yang sama satu atau dua tahun sebelumnya. Perusahaan lain, seperti
perusahaan asuransi, mungkin memiliki persyaratan hukum untuk menyimpan data
setidaknya selama lima tahun. Tabel data yang sangat besar menyebabkan setidaknya dua
masalah desain gudang data yang sangat penting. Pertama, mendapatkan data lama
seringkali lebih sulit. Semakin tua datanya, semakin besar kemungkinan terjadinya masalah
dalam membaca dan menafsirkan file atau kaset lama. Kedua, sebaiknya digunakan versi
lama dengan dimensi signifikan, bukan versi baru. Hal ini dikenal sebagai masalah dimensi
yang perlahan berubah dan#039;, yang akan dijelaskan lebih detail pada langkah berikutnya.

Langkah 8: Ikuti dimensi yang berubah secara perlahan

Masalah perubahan dimensi yang lambat berarti, misalnya, Anda harus menggunakan
deskripsi akurat tentang pelanggan lama dan cabang lama dengan riwayat transaksi lama.
Gudang data sering kali perlu menentukan kunci umum untuk dimensi penting ini guna
membedakan beberapa gambaran pelanggan dan cabang selama periode waktu tertentu. Ada
tiga tipe utama dimensi yang berubah secara perlahan: tipe 1, di mana atribut dari dimensi
yang berubah diganti; Tipe 2, dimana atribut dimensi yang diubah menyebabkan rekaman
dimensi baru dibuat; dan Tipe 3, dimana atribut dimensi yang diubah membuat atribut
alternatif sehingga nilai atribut lama dan baru dapat digunakan secara bersamaan dalam
rekaman dimensi yang sama.

Langkah 9: Tetapkan prioritas dan status permintaan

Di sini kita melihat masalah desain fisik. Masalah tata letak fisik utama yang mempengaruhi
persepsi pengguna akhir terhadap penyimpanan data adalah pengurutan fisik tabel fakta
pada disk dan keberadaan ringkasan atau agregat yang disimpan sebelumnya. Selain masalah
ini, ada beberapa masalah desain fisik lainnya yang memengaruhi manajemen, pencadangan,
kinerja indeks, dan keamanan. Untuk informasi lebih lanjut mengenai isu-isu yang
mempengaruhi desain fisik gudang data, pembaca mengacu pada Anahory dan Murray

15
(1997). Pada akhir metodologi ini, kami memiliki desain data-sentris yang mendukung
kebutuhan proses bisnis tertentu dan memungkinkan integrasi yang mudah dengan
penyimpanan data serupa lainnya, yang pada akhirnya membentuk gudang data di seluruh
perusahaan. Tabel 32.2 mencantumkan tabel data dan dimensi yang terkait dengan setiap
skema bintang proses bisnis DreamHome (didefinisikan pada langkah 1 metode).

Kami mengintegrasikan skema bintang ke dalam proses bisnis DreamHome menggunakan

dimensi formulir. Misalnya, semua tabel data berbagi dimensi waktu dan cabang, seperti yang
ditunjukkan pada Tabel 32.2. Model dimensi yang berisi lebih dari satu tabel fakta dibagi
dengan satu atau lebih tabel dimensi yang bersesuaian disebut konstelasi fakta. Konstelasi
fakta pada database DreamHome ditunjukkan pada Gambar 32.8. Model ini telah
disederhanakan dengan hanya menampilkan nama fakta dan tabel dimensi. Perhatikan

16
bahwa tabel data ditampilkan dengan warna gelap dan semua tabel dimensi yang akan
dikonversi ditampilkan dengan warna terang.

2.4 Kriteria untuk Menilai Dimensi Data Warehouse

Sejak tahun 1980an, data warehouse telah mengembangkan teknik desainnya sendiri
yang berbeda dari sistem OLTP. Teknik desain dimensi telah menjadi pendekatan pilihan di
sebagian besar gudang data. Pada bagian ini, kami menjelaskan kriteria yang diajukan oleh
Ralph Kimball untuk mengukur sejauh mana suatu sistem mendukung dimensi penyimpanan
informasi (Kimball, 2000a,b). Saat mengevaluasi gudang data terpisah, ingatlah bahwa hanya
sedikit vendor yang berusaha memberikan solusi terintegrasi penuh. Namun, karena data
warehouse adalah sistem yang lengkap, kriteria tersebut hanya digunakan untuk
mengevaluasi sistem yang lengkap, bukan kumpulan paket terfragmentasi yang mungkin
tidak pernah terintegrasi dengan baik. Ada dua puluh kriteria dan mereka dibagi menjadi tiga
kelompok besar: arsitektur, kontrol dan ekspresi, seperti yang ditunjukkan pada Tabel 32.3.
Tujuan dari penetapan kriteria ini adalah untuk menciptakan standar obyektif untuk
mengevaluasi seberapa baik suatu sistem mendukung pandangan dimensi gudang data dan
untuk menetapkan ambang batas yang tinggi bagi vendor untuk mempunyai tujuan dalam
meningkatkan sistem mereka. Cara yang dimaksudkan untuk menggunakan daftar ini adalah
dengan mengevaluasi sistem dengan nilai 0 atau 1 untuk setiap kriteria. Suatu sistem hanya
akan merespons nilai 1 jika memenuhi definisi dukungan penuh untuk kriteria tersebut.
Misalnya, sistem yang menyediakan navigasi gabungan (kriteria keempat) yang hanya
tersedia untuk satu alat antarmuka pengguna akan menerima skor nol karena navigasi
gabungan tidak diekspos. Dengan kata lain, kriteria tersebut tidak memiliki nilai parsial.
Kriteria arsitektur adalah karakteristik dasar organisasi keseluruhan sistem. Kriteria ini
biasanya mencakup sistem backend melalui DBMS hingga antarmuka pengguna dan desktop

17
pengguna. Kriteria pengelolaan lebih bersifat taktis dibandingkan kriteria arsitektural, namun
dianggap penting untuk kelancaran dan gudang data berorientasi dimensi. Kriteria ini
biasanya berlaku untuk staf TI yang membangun dan memelihara gudang data.

Kriteria rona kebanyakan menakhlikkan kodrat analitik yang dibutuhkan bagian dalam
suasana denyut nyata. Komunitas pemakai buah menempuh hidup semua tolok ukur rona
secara langsung. Kriteria rona kepada perkara bagian bukan semata-mata fitur yang dicari
pemakai bagian dalam data warehouse, tetapi berupaya semua adalah kodrat yang terlazim
memeras gaya perkara bagian. Sistem yang mengangkat kebanyakan atau semua tolok ukur
bagian ini akan mudah beradaptasi, lebih mudah dikelola, dan mampu memukul berlebihan
praktik lingkungan nyata. Poin utama dari sistem dimensi adalah bahwa sistem ini didorong
oleh masalah bisnis dan pengguna akhir.

2.5 Desain Data Warehousing Menggunakan Oracle

Bagian ini menjelaskan Oracle Warehouse Builder (OWB) sebagai bagian utama dari solusi
Oracle Warehouse, yang memungkinkan Anda merencanakan dan menyebarkan gudang data,
penyimpanan data, 1197, dan aplikasi data e-commerce. OWB adalah alat desain dan

18
ekstraksi, konversi dan pemuatan (ETL). Aspek penting dari OWB dari sudut pandang
pelanggan adalah memungkinkan integrasi lingkungan data warehouse tradisional dengan
lingkungan e-bisnis baru (Oracle Corporation, 2000). Bagian ini pertama-tama memberikan
gambaran umum tentang komponen OWB dan teknologi yang mendasarinya, dan kemudian
menjelaskan bagaimana pengguna akan menerapkan OWB pada tugas-tugas pergudangan
data pada umumnya.

2.5.1 Komponen Pembuat Repositori Oracle

OWB menyediakan komponen fungsional penting berikut:
- Repositori yang terdiri dari sekumpulan tabel database Oracle yang diakses melalui
lapisan akses berbasis Java. Repositori ini didasarkan pada standar Common
Warehouse Model (CWM), yang memungkinkan produk lain yang mendukung
standar ini menggunakan metadata OWB (lihat Bagian 31.4.3).
- Antarmuka pengguna grafis (GUI) yang memungkinkan akses ke database. GUI
mencakup editor grafis dan penggunaan penyihir yang ekstensif. Antarmuka
pengguna ditulis dalam Java, sehingga antarmuka pengguna bersifat portabel.
- Generator kode, juga ditulis dalam Java, menghasilkan kode yang memungkinkan
penerapan gudang data. Berbagai kode yang dihasilkan oleh OWB dibahas nanti di
bagian ini.
- Integrator, yaitu komponen yang dirancang untuk mengekstrak data dari jenis sumber
tertentu. Selain mendukung Oracle, sumber data relasional, non-relasional, dan file
tetap lainnya, integrator OWB memungkinkan penggunaan data dalam aplikasi
perencanaan sumber daya perusahaan (ERP) seperti Oracle dan SAP R/3. SAP
Integrator menyediakan akses ke tabel transparan SAP menggunakan kode PL/SQL
yang dihasilkan oleh OWB.
- Antarmuka terbuka yang memungkinkan pengembang memperluas kemampuan
ekstraksi OWB sambil memanfaatkan kerangka OWB. Antarmuka terbuka ini
tersedia untuk pengembang sebagai bagian dari Kit Pengembangan Perangkat Lunak
(SDK) OWB.
- Runtime, yang merupakan kumpulan tabel, array, paket, dan trigger yang diinstal pada
skema target. Objek database ini membentuk dasar kemampuan audit dan
deteksi/resolusi kesalahan OWB. Misalnya, pengunduhan dapat dimulai ulang
berdasarkan informasi yang disimpan dalam jadwal yang dijalankan. OWB mencakup
audit runtime, yang memungkinkan Anda menelusuri tabel runtime dan laporan

19
 runtime. Arsitektur Oracle Warehouse Builder ditunjukkan pada Gambar 32.9. Oracle
Warehouse Builder adalah bagian penting dari gudang data Oracle yang lebih besar.
Produk lain yang harus digunakan OWB untuk penyimpanan data meliputi:
- Oracle - mesin OWB (karena tidak ada server eksternal);
- Oracle Enterprise Manager - untuk perencanaan;
- Oracle Workflow - untuk manajemen ketergantungan;
- Oracle Pure-Extract - MVS untuk penggunaan komputer;
- Oracle Pure-Integrate - meningkatkan kualitas data pelanggan;
- Oracle Gateways - untuk mengakses data relasional dan komputer.

2.5.2 Menggunakan Oracle Warehouse Builder

Pada putaran ini patik menerangkan bagaimana OWB praktis pemakai bagian dalam
sejumlah jabatan pergudangan fakta yang sipil seumpama menjelaskan bentuk fakta mula,
mengonsep jambar target, memvisualkan mula ke target, memperbaiki kode, menginstansiasi
jambar, mengekstrak fakta, dan merawat jambar.

A. Menentukan mula

Setelah kelas perkiraan ditentukan dan semua mula fakta perkiraan diidentifikasi,
perlengkapan seumpama OWB bisa digunakan kepada membantu fakta warehouse. OWB
bisa mendebik bineka mula fakta pakai mengabdikan integrator. OWB juga menyimpan
sketsa modul, yang mewujudkan klasifikasi reguler berpokok sasaran-sasaran yang teruit.

20
 Ada dua macam modul: mula fakta dan jambar. Sebagai contoh, modul mula fakta bisa
mengandung semua hikmat register bagian dalam database OLTP yang mewujudkan mula
kepada fakta warehouse. Dan modul rumpun jambar menerima mengandung hikmat fakta,
dimensi, dan register tontonan yang menyelaraskan jambar fakta. Penting kepada dicatat
bahwa modul semata-mata mengandung hikmat, yaitu metadata, mengenai mula atau jambar,
dan bukan sasaran yang bisa diisi atau ditanyakan. Seorang pemakai mendapati integrator
yang seia sekata kepada mula fakta, dan setiap integrator mengakses mula dan merekrut
metadata yang menjelaskannya.

B. Sumber-sumber Oracle

Untuk menggandengkan ke database Oracle, pemakai memintal integrator kepada

database Oracle. Selanjutnya, pemakai menerimakan sejumlah bukti relasi yang lebih rinci,
misalnya label pemakai, ucapan sandi, dan string relasi SQL*Net. Informasi ini digunakan
kepada menetapkan kapstok fundamen fakta bagian dalam fundamen fakta yang bekerja
bekas pengumpulan repositori OWB.

OWB mengabdikan kapstok fundamen fakta ini kepada menganjurkan edaran perkara
berpokok fundamen fakta mula dan mengekstrak metadata yang menerangkan register dan
bentuk yang membuang jumlah pemakai. Pengguna menjalani surah ini seumpama taktik
penelitian mula secara optis dan memintal sasaran yang diminati.

C. Sumber-mula non-Oracle

Basis fakta non-Oracle diakses pakai lembaga yang persis serupa pakai fundamen fakta
Oracle. Yang memungkinkan surah ini adalah teknologi Transparent Gateway berpokok
Oracle. Intinya, Transparent Gateway memungkinkan database non-Oracle diperlakukan
pakai lembaga yang persis serupa seumpama database Oracle.

Pada fase SQL, setelah kapstok database yang berorientasi ke database non-Oracle
perkiraan ditentukan, database non-Oracle bisa ditanyakan melewati SELECT seumpama
halnya database Oracle. Dalam OWB, yang harus dilakukan pemakai adalah mendapati
macam database, sehingga OWB bisa memintal Transparent Gateway yang seia sekata
kepada hikmat link database. Dalam peristiwa mula mainframe MVS, OWB dan Oracle Pure-
Extract menahan ekstraksi fakta berpokok mula-mula seumpama IMS, DB2, dan VSAM.
Rencananya, Oracle Pure-Extract ambang kesudahannya akan diintegrasikan pakai teknologi
OWB.

21
 D. File datar

OWB memondong dua macam file boyak: file yang dibatasi susila dan file pakai panjang
tetap. Jika mula fakta adalah file boyak, pemakai memintal integrator kepada file boyak dan
menetapkan urat dan label file. Proses penciptaan meta-fakta yang memetakan sama file gaib
pakai taktik yang digunakan kepada sama register bagian dalam database. Pada sama register,
database yang menyimpan memegang bukti yang sukatan mengenai register termasuk
seumpama label register, label kolom, dan rumpun fakta. Informasi ini bisa pakai mudah
ditanyakan berpokok edaran. Dengan sama file, di faktor lain, pemakai praktis bagian dalam
taktik penciptaan metadata pakai sejumlah nyana cerdas yang disediakan oleh OWB. Dalam
OWB, taktik ini disebut pengumpulan sampel.

E. Data web

Dengan berkembangnya Internet, sanggahan baru kepada fakta warehousing adalah

mengangkat fakta berpokok lokasi Web. Ada berbagai macam fakta bagian dalam dunia e-
Bisnis: fakta Web transaksional yang disimpan bagian dalam fundamen fakta yang
mendasarinya; fakta clickstream yang disimpan bagian dalam file log server Web; fakta
pencoretan bagian dalam fundamen fakta atau file log; dan fakta clickstream yang
dikonsolidasikan bagian dalam file log perlengkapan ulasan Web. OWB bisa mendebik
semua mula ini pakai fitur bawaannya kepada mengakses fundamen fakta dan file boyak.

F. Kualitas data

Solusi kepada sanggahan mutu fakta adalah OWB pakai Oracle Pure-Integrate. Oracle
Pure-Integrate adalah peranti kalem perpaduan fakta konsumen yang mengotomatiskan
penciptaan memoar konsumen yang terkonsolidasi dan fakta kulak teruit kepada memondong
pelaksanaan e-Business dan tata usaha aliansi konsumen. Pure-Integrate menutup OWB pakai
menahan fitur-fitur canggaan dan pencopotan fakta fase melebar yang dirancang tertentu
kepada menyetujui keperluan pelaksanaan database. Fitur-fitur termasuk kisi-kisi lain:

- Pemrosesan label dan alamat yang terstruktur kepada menstandarisasi, mengoreksi,

dan memperhebat bayangan label dan tanah lapang konsumen;
- pencocokan probabilistik fase melebar kepada mendapati konsumen, kulak, pendapa
tingkatan, pendapa tingkatan super, atau materi lain yang tersisih[a] dan tidak
menyimpan cap sipil;

22
 - konsolidasi berlandas pranata yang kuat dugaan kepada mengolah fakta yang saling
bersengketa dan mereka akhir terstruktur 'terbaik' berpokok fakta yang cocok.

G. Merancang Gudang Target

Setelah perkara asal diidentifikasi dan didefinisikan, instansi selanjutnya adalah

merencanakan los tujuan berlandasan desakan pemakai. Salah tunggal komposisi yang paling
tersohor bagian dalam informasi warehousing adalah denah bintang dan variasinya,
seumpama yang dibahas di Bagian 32.2. Selain itu, berlebihan aparat intelijen komersial
seumpama Oracle Discoverer dioptimalkan kepada komposisi serupa ini. OWB memanggul
semua diskrepansi komposisi denah bintang. Ia menyimpan fitur wizard dan pengarah grafis
kepada urutan evidensi dan dimensi. Sebagai contoh, bagian dalam Dimension Editor,
pemakai secara grafis mengisahkan atribut, level, dan hirarki berpunca seimbang dimensi.

H. Memetakan Sumber ke Target

Ketika asal dan tujuan duga didefinisikan tambah baik, praktik selanjutnya adalah
memerikan keduanya. Ingatlah bahwa kedapatan dua rupa modul: modul asal dan modul los.
Modul bisa digunakan pulang berkali-lungkang bagian dalam pemetaan yang berbeda. Modul
los bisa digunakan seumpama modul asal. Sebagai contoh, bagian dalam komposisi di mana
kita menyimpan landasan informasi OLTP yang menempatkan sambungan hidup los
informasi pusat, yang muka gilirannya menempatkan sambungan hidup informasi mart, los
informasi adalah tujuan (berpunca faset landasan informasi OLTP) dan asal (berpunca faset
informasi mart).Pemetaan OWB didefinisikan muka dua fase. Pemetaan fase tinggi yang
menyinggir modul asal dan tujuan. Satu fase di bawahnya adalah pemetaan serpih yang
memungkinkan pemakai memerikan risalah asal ke risalah tujuan dan mengisahkan
canggaan. OWB menyimpan referensi canggaan kiriman yang bisa digunakan pemakai
kepada mengidas canggaan yang duga ditentukan. Pengguna juga bisa mengisahkan
canggaan berupaya pribadi di PL /SQL dan Java.

I. Menghasilkan kode

Code Generator adalah anggota OWB yang menyampaikan terjemahan tujuan dan
pemetaan asal-ke-tujuan dan mereka cipta komando kepada menjelmakan los. Jenis komando
yang dihasilkan bermacam ragam terpulang muka rupa korban yang butuh diimplementasikan
oleh pemakai.

- Desain logis versus desain fisik

23
 Sebelum menumbuhkan komando, pemakai terutama duga berproses muka fase
terstruktur, yaitu muka fase terjemahan korban. Pada fase ini, pemakai ingat tambah
memaklumi semua serpih dan pertalian (semantik) berpunca seimbang korban, tetapi
belum ingat tambah mengisahkan sifat konkretisasi barang apa. Sebagai contoh,
pertimbangkan seimbang urutan yang akan diimplementasikan bagian dalam database
Oracle. Pada fase terstruktur, pemakai raih ingat tambah personalitas urutan, bujet
risalah, personalitas risalah dan bentuk informasi, dan pertalian barang apa yang
dimiliki urutan tertera tambah urutan lain. Namun, muka fase tubuh, pertanyaannya
adalah: bagaimana urutan ini bisa diimplementasikan secara optimal bagian dalam
database Oracle? Pengguna saat ini harus melihat dng cermat bagian-bagian
seumpama balai urutan, indeks, dan indeks penyimpanan (lihat Bagian 8.2.2). OWB
memungkinkan pemakai kepada menyoroti dan memalsukan seimbang korban muka
fase terstruktur dan tubuh. Definisi terstruktur dan serpih konkretisasi tubuh
disinkronkan secara otomatis.
- Konfigurasi
Dalam OWB, menetapkan properti fisik ke suatu objek disebut konfigurasi. Properti
spesifik yang dapat didefinisikan bergantung pada objek yang didefinisikan. Objek-
objek ini mencakup, misalnya, parameter penyimpanan, indeks, ruang tabel, dan
partisi.
- Validasi
Merupakan praktik yang baik untuk memeriksa kelengkapan dan konsistensi definisi
objek sebelum membuat kode. OWB menyediakan fungsi validasi untuk
mengotomatisasi proses ini. Contoh kesalahan yang terdeteksi dalam proses validasi
adalah perbedaan tipe data sumber dan target serta kesalahan kunci asing.
- Generasi
Berikut ini adalah beberapa jenis kode utama yang dihasilkan oleh OWB:
 Perintah SQL Data Definition Language (DDL) (DDL) dengan
definisi tabel fakta dan dimensi diimplementasikan sebagai skema
relasional dalam database Oracle. OWB menghasilkan skrip SQL DDL
yang membuat skema ini. Skrip dapat dijalankan dari OWB atau
disimpan ke sistem file untuk dieksekusi secara manual nanti.
 Program PL/SQL Pemetaan sumber-ke-target membuat program
PL/SQL jika sumbernya adalah database Oracle atau non-Oracle.

24
 Program PL/SQL mengakses database sumber melalui koneksi
database, melakukan transformasi yang ditentukan dalam pemetaan,
dan memuat data ke dalam tabel target.
 File kontrol SQL*Loader, Jika sumber gabungan adalah file datar,
OWB akan membuat file kontrol yang dapat digunakan dengan
SQL*Loader.
 Skrip Tcl OWB juga menghasilkan skrip Tcl. Skrip ini dapat digunakan
untuk menjadwalkan deskriptor PL/SQL dan SQL*Loader agar
dijalankan di Oracle Enterprise Manager—misalnya, untuk
memperbarui repositori secara berkala.
- Menginstalasi gudang dan mengekstrak data
Sebelum memindahkan data dari sumber ke database target, pengembang harus
menjalankan skrip DDL yang dihasilkan untuk membuat skema target, yaitu
repositori. OWB menyebut tahap ini implementasi. Setelah skema tujuan ada,
program PL/SQL dapat mentransfer data dari sumber ke tujuan. Perhatikan bahwa
mekanisme transfer data dasar adalah INSERT. . . SELECT. . . menggunakan tautan
basis data. Ketika kesalahan terjadi, rutin mencatat kesalahan tersebut dalam tabel
pelacakan kesalahan di salah satu paket runtime OWB.
- Memelihara gudang
Setelah penyimpanan data dipakai dan pemuatan awal selesai, penyimpanan data
harus disimpan. Misalnya, tabel data harus diperbarui secara berkala sehingga kueri
dapat memberikan hasil terkini. Tabel dimensi harus diperluas dan diperbarui,
meskipun lebih jarang dibandingkan tabel data. Contoh dimensi yang berubah secara
perlahan adalah tabel Pelanggan, dimana alamat pelanggan, status perkawinan, atau
nama dapat berubah seiring waktu. Selain INSERT, OWB mendukung cara lain
dalam menangani repositori:
- PEMBARUAN
- HAPUS
- ADD/UPDATE (tambahkan baris; jika ada, perbarui)
- UPDATE/Insert (memperbarui baris; jika hilang, tambahkan)

Fitur-fitur ini memberi pengguna OWB berbagai alat untuk pemeliharaan rutin.
Antarmuka OWB dengan Oracle Enterprise Manager untuk tugas pemeliharaan berulang;

25
seperti pembaruan basis data yang dijadwalkan secara berkala. Untuk dependensi yang
kompleks, OWB terintegrasi dengan Oracle Workflow.

- Integrasi metadata

OWB didasarkan pada standar Common Warehouse Model (CWM). OWB dapat bertukar
metadata dengan Oracle Express dan Oracle Discoverer serta alat intelijen bisnis standar
lainnya.

26
 BAB III
PENUTUP
3.1 Kesimpulan

Data warehouse adalah pusat penyimpanan data dari suatu organisasi/perusahaan.

Misalnya: data penjualan, transaksi keuangan, cover asuransi, statistik permainan
olahraga, dll.

Merancang database informasi warehouse sangatlah kompleks. Untuk memulai

proyek gudang data, kita perlu memiliki pemahaman yang jelas tentang pertanyaan-
pertanyaan seperti: apa kebutuhan pengguna yang paling penting, dan data apa yang
harus diperbarui sesegera mungkin? apa kebutuhan pengguna yang paling penting,
dan data apa yang harus diperbarui sesegera mungkin? Pertanyaan seperti ini
menyoroti beberapa isu paling penting dalam pengembangan data warehouse.

Pemodelan dimensi adalah teknik desain yang bertujuan untuk menyajikan data
dalam bentuk standar dan intuitif yang memungkinkan akses berkinerja tinggi.
Pemodelan dimensi menggunakan konsep pemodelan Entity-Relationship (ER)
dengan beberapa batasan penting. Setiap model dimensi (DM) terdiri dari satu tabel
dengan kunci utama komposit, yang disebut tabel fakta, dan satu set tabel yang lebih
kecil yang disebut tabel dimensi. Setiap tabel dimensi memiliki kunci primer
sederhana (non-komposit) yang sama persis dengan salah satu komponen kunci
komposit pada tabel fakta. Dengan kata lain, kunci utama dari tabel fakta terdiri dari
dua atau lebih kunci asing. Struktur 'seperti bintang' yang khas ini disebut skema
bintang atau gabungan bintang.

Skema bintang adalah struktur logis yang memiliki tabel fakta yang berisi data
faktual di tengahnya, dikelilingi oleh tabel dimensi yang berisi data referensi (yang
dapat didenormalisasi).

Metodologi Desain Basis Data untuk Gudang Data, Metode ini diusulkan oleh
Kimball dan disebut ‘Metodologi Sembilan Langkah’ (Kimball, 1996). Metodologi
sembilan langkah yaitu: memilih proses, memilih biji-bijian, mengidentifikasi dan
menyesuaikan dimensi, memilih fakta, menyimpan pra-perhitungan dalam tabel fakta,
melengkapi tabel dimensi, memilih durasi basis data, melacak dimensi yang berubah
secara perlahan, dan menentukan prioritas kueri dan mode kueri.

27
 Desain Data Warehousing menggunakan Orade, Oracle Warehouse Builder
(OWB) bagian utama dari solusi Oracle Warehouse, yang memungkinkan untuk
merencanakan dan menyebarkan gudang data, penyimpanan data, dan aplikasi data e-
commerce. OWB adalah alat desain dan ekstraksi, konversi dan pemuatan (ETL).

3.2Saran

Diharapkan metodologi desain basis data sembilan langkah dapat membantu

mendesain gudang data suatu perusahaan/organisasi. Desain Data WareHouse yang efektif
berperan dalam mendukung analisis data yang akurat dan pengambilan keputusan strategis
bagi suatu organisasi. Desain Data WareHouse juga berfungsi untuk mempersiapkan
organisasi untuk menghadapi tantangan dan pertumbuhan di masa depan.

28
 DAFTAR PUSTAKA

Connoly, Thomas & Carolyn Begg. 2015. Database Systems A Practical Approach to Design,
Implementation, and Management 6th Edition-Global Edition.
Triono, P (2017, April 10). 5 Definisi Data Warehousing Menurut Para Ahli. Retrieved from
blogspot.com:
https://definisimenurutparaahli.blogspot.com/2017/04/5-definisi-metode-menurut-
para-ahli.html

29