Populating the Data Warehouse

Ada lima subjek mengenai populating data warehouse dalam rangkaian yang terjadi di dalam
system data warehouse:
1. Loading the stage: kita melakukan load pada data source system ke dalam stage. Pada
umumnya, fokusnya adalah untuk mengambil data secepat mungkin tanpa melakukan
terlalu banyak transpormasi. Dengan kata lain, structural table mirip dengan table source
system.
2. Membuat data firewall: kita memeriksa kualitas data saat data diambil dari stage ke NDS
atau ODS. Pengecekkan dilakukan dengan menggunakan aturan yang telah ditetapkan
tindakan apa yang harus dilakukan: reject data, allow data atau fix data.
3. Mempopulasikan normalisasi data store: yaitu ketika kita memuat data dari stage ke
NDS atau BPO. Setelah data melewati data firewall. Keduanya dinormalisasi
menyimpan data yang terdiri dari entitas dengan minimal adanya redundansi data. Kita
akan merurusan dengan normalisasi data dan key.
4. Mempopulasikan table dimensi: yaitu ketika kita memuat data ODS NDS atau ke table
dimensi DDS. Hal ini dilakukan setelah kita mengisi dan menyimpan data yang
dinormalisasi. DDS adalah penyimpanan dimensional dimana data dinormalisasikan.
5. Mempopulasikan table factual: yaitu langkah terakhir dalam mengisi data warehouse.
Hal ini dilakukan setelah kita mengisi table dimensi di DDS. Data dari NDS atau ODS
dimuat dimuat ke table factual DDS.
Stage Loading
Jika kita menggunakan file sebagai data warehouse stage, kita harus memberi nama file
dan struktur direktori dengan hati-hati, khususnya ketika menggabungkan tanggal ke dalam nama
file atau nama direktori. Kita perlu memiliki hak akses dan izin untuk folder stage. Kita harus
mendefinisikan penghapusan dan proses pengarsipan, penanganan kegagalan dan frekuensi
loading. Yang paling penting adalah mendefinisikan rincian format file. Pengalokasian kapasitas
pada disk juga sangat penting dalam perencanaan. Ini adalah titik sederhana namun akan
menyebabkan masalah jika kita salah memperkirakannya. Dan kita harus memastikan proses
ETL akan mampu mengatasi jika kita kekurangan ruang pada disk. Ruang disk untuk stage
direncanakan berdasarkan volume ekstraksi data harian maksimum dari source system dan
berapa lama kita akan mengarsipkan data.

Jika stage Anda adalah database, lebih baik untuk tidak menempatkan setiap indeks
atau constraint (seperti tidak null, kunci primer, atau check kendala) dalam database panggung.
Alasan utama untuk ini adalah bukan karena kinerja, tetapi karena kita ingin menangkap dan
melaporkan data yang buruk dalam proses kualitas data. Kami ingin memungkinkan data yang
buruk seperti nol dan duplikat kunci primer ke dalam tabel stage sehingga bisa melaporkannya.
Jika kita membatasi stage table kita untuk menolak nol dan duplikat kunci primer, maka proses
kualitas data yang berada di antara stage dan NDS tidak akan mampu menangkap isu-isu DQ ini
dan melaporkannya untuk koreksi dalam sistem sumber. Dengan cara ini, ketika kita mengisi
NDS, kita dapat menerapkan seperangkat aturan yang komprehensif dan ketat yang menyaring
data yang buruk ke daerah karantina kualitas data untuk pelaporan dan pengolahan lebih lanjut
seperti pembersihan, memperbaiki, reimporting, atau pengarsipan.
Mengindeks tabel stage umumnya tidak diperlukan. Hal ini karena cara tabel stage yang
terstruktur dan dipilih. Cara terbaik untuk melakukan ini adalah dengan memuat data ke dalam
tabel panggung kosong tanpa indeks dan kemudian pilih semua catatan dari meja tersebut untuk
memuat ke NDS. Jika Anda berencana untuk menyimpan, misalnya, lima hari data stage, jika
Anda membutuhkan mereka dalam hal kegagalan, lebih baik tidak untuk menyimpan data hari
sebelumnya di meja yang sama. Alasan pertama mengapa kita tidak bisa kembali ke sistem
sumber dan restage karena data sistem sumber mungkin telah berubah. Alasan kedua adalah
kinerja. Dengan kata lain, itu lebih cepat untuk reload NDS dari panggung daripada mengambil
data dari sistem sumber lagi.
Data Firewall
Konsep firewall data mirip dengan konsep firewall di jaringan. Firewall Data adalah
program yang memeriksa data yang masuk. Secara fisik, itu adalah paket SSIS atau prosedur
yang tersimpan. Kita menempatkan firewall data antara stage dan NDS, yang akan
memungkinkan atau menolak data yang tergantung pada aturan kualitas data yang ditentukan.
Seperti firewall jaringan, Data firewall juga memiliki mekanisme untuk melaporkan data apa
yang telah ditolak, berdasarkan aturan apa, dan kapan. Hal ini karena setiap kali data firewall
menangkap atau menemukan data yang buruk (seperti yang didefinisikan oleh aturan kualitas
data), data yang buruk disimpan dalam database kualitas data, bersama dengan yang aturan

digunakan untuk menangkap data yang buruk, apa tindakan yang diambil , dan ketika itu terjadi.
Yang kemudian dapat laporan dari database kualitas data ini. Kita juga bisa mengatur sistem
kualitas data untuk memberitahu ke orang-orang yang tepat ketika aturan kualitas data tertentu
dilanggar.
Tidak seperti firewall jaringan, data firewall juga dapat memperbaiki atau membenarkan
data yang buruk. Ketika firewall Data mendeteksi data yang buruk, kita dapat mengatur untuk
melakukan salah satu dari tiga tindakan ini: menolak data (tidak memuatnya ke dalam gudang
data), mengizinkan data (load ke dalam gudang data), atau memperbaiki data (mengoreksi data
sebelum loading ke dalam gudang data).
Sebuah firewall data merupakan bagian penting dari pengisian data warehouse karena
untuk memastikan kualitas data. Sebelum kita memuat data ke dalam normalized data store (atau
menjadi DDS jika kita menggunakan DDS hanya arsitektur), kita memeriksa data dengan
melewati data melalui aturan firewall.
Data firewall sangat penting dalam data warehouse karena data firewall memblok data
yang buruk. Data firewall terinspirasi oleh fungsi firewall dalam jaringan. Dalam jaringan, jika
kita memiliki firewall antara segmen jaringan, secara default semuanya sudah diblokir. Jadi,
untuk memiliki konektivitas antara segmen A dan segmen B kita perlu memungkinkan lalu lintas
jaringan melalui firewall. Kita dapat menentukan lalu lintas jaringan dengan menentukan nomor
port. Misalnya, hole untuk lalu lintas web HTTP berbeda dari hole ODBC. Lihat gambar
dibawah ini.

Gambar Perbedaan hole di dalam firewall yang berbeda tipe traffic

Mempopulasikan NDS
Dalam arsitektur NDS + DDS, kita perlu mengisi table di NDS sebelum kita mengisi
table dimensi dan factual di DDS. Hal ini karena kita mengisi DDS berdasarkan data di NDS.
Mengisi dan menyimpan data yang dinormalisasikan sangat berbeda dari stage. Hal ini karena
ketika kita mengisi NDS, kita perlu untuk menormalkan data, sedangkan saat mengisi stage, kita
tidak perlu untuk menormalkan data. Kita mengambil beberapa data dari table stage atau
langsung dari source system dan kemudian memuat ke database NDS. Jika catatan tidak ada di
NDS, kita masukkan. Jika catatan sudah ada, kita memperbaharuinya. Ketika mengisi NDS, kita
perlu mempertimbangkan beberapa isu, yaitu:.
a. Normalisasi.
Di NDS, tabel dinormalisasi, sehingga ketika loading data dari stage, kita perlu untuk
menormalkannya agar sesuai dengan struktur NDS. Ini berarti kita harus mengisi tabel
tertentu terlebih dahulu sebelum kita dapat mengisi tabel utama.
b. Data Eksternal.
Ada kemungkinan bahwa data dari sumber eksternal tidak sesuai dengan data dari source
system. Ini berarti bahwa ketika kita memuat data ke dalam NDS, kita mungkin perlu
melakukan beberapa konversi data.
c. Kunci Manajemen.

Di NDS, kita perlu menciptakan dan memelihara kunci data warehouse internal, yang
juga akan digunakan di DDS. Ketika loading data ke dalam NDS, kita perlu mengelola
kunci ini.
d. Tabel Junction.
Tabel junction memungkinkan kita untuk menerapkan hubungan many-to-many. Ketika
mengisi tabel junction, kita perlu mengikuti urutan tertentu.

Diagram Entity relationship dari tabel store dalam source system dan NDS

Menggunakan aturan DQ untuk memperbaiki data yang masuk untuk

mencegah duplikasi data di NDS

Pemetaan untuk tabel product_status antara source system dan NDS

Menggunakan SSIS untuk mengumpulkan NDS
Normalized Data Store (NDS), adalah tempat penyimpanan master data internal dalam
bentuk satu atau lebih database yang telah dinormalisasi untuk tujuan menggabungkan data dari
berbagai sumber data yang tersimpan pada stage, sebelum data dimuat pada tempat penyimpanan
yang dapat diakses langsung oleh pengguna.
Pada tahap ini akan dilakukan pengisian tabel pada skema NDS dengan menggunakan
Slowly Changing Dimension Wizard pada SSIS. Slowly Changing Dimension merupakan sebuah
teknik yang digunakan dalam pemodelan dimensional untuk mempertahankan informasi
historikal sehubungan dengan data dimensional. Dengan menggunakan Slowly Changing
Dimension Wizard maka dimungkinkan untuk melakukan insert dan update pada tabel di dalam
skema NDS. Pengisian tiap tabel pada database NDS menyertakan relasi yang terdapat antar
tabel di dalamnya. Sumber data yang digunakan untuk database NDS berasal dari sumber data
database stage.
Upsert Using SQL and Lookup

SCD transformation umumnya dikenal dengan upsert-in, update jika exist, insert jika
tidak exist. Ini adalah basic operation di data warehouse, dan kita akan menemukan operasi ini
berkali-kali ketika membangun sistem ETL data warehouse. Ada dua metode yang umum
digunakan dalam prakteknya, untuk melakukan upsert. Pertama adalah menggunakan SQL
statement, dan kedua menggunakan lookup transformation.