PT Sun Artha Putra Mandiri
Standard Operating Procedure – Development Data Warehouse
Nomor SOP: 0009/SAPM/SOP-TC/IX/2021
> TUJUAN
Merupakan acuan alur untuk proses pengembangan Data Warehouse.
> SCOPE
Tahapan-tahapan yang terdapat pada pengembangan Data Warehouse.
> DEFINISI
Data Warehouse merupakan jenis dari sistem manajemen data yang dirancang untuk digunakan dalam aktivitas
business intelligence.
> PROSEDUR BAKU
1. DESAIN DATA WAREHOUSE
Pada tahap ini, desain data warehouse dibuat dari dokumen requirement dan assessment yang
dibuat. Dalam mendesain data warehouse, beberapa hal berikut perlu diperhatikan yaitu:
1.1. Pemodelan tanggal dan waktu.
- Membangun dimensi/tabel baru untuk tanggal secara tersendiri. Key dapat
menggunakan tipe data integer
- Bila memerlukan analisis per jam/menit/detik, dapat membuat dimensi baru lagi
yang berisi jam, menit, dan detik yang terhubung ke fact table.
1.2. Menghindari snowflaking secara umum.
Menggunakan snowflaking hanya pada kasus yang memang diperlukan. Contoh yang
memerlukan snowflaking adalah apabila suatu toko mengadakan promosi, yang di
dalamnya terdapat tanggal dimulai promosi dan tanggal berakhir promosi.
1.3. Menggunakan surrogate key dengan tipe data integer.
1.4. Penanganan slowly changing dimension.
Pada dimensi yang mengalami perubahan nilai secara lambat, terdapat beberapa opsi
penanganan dimensi:
- Overwrite, mengganti nilai lama dengan nilai baru. Cara ini mudah dan cepat,
namun akan ‘menghapus’ data historis yang menggunakan nilai lama.
- Menambah baris (menambah record baru) pada dimensi, cara ini paling umum
digunakan, dan dapat menyimpan data historis yang menggunakan nilai lama.
- Menambah kolom pada dimensi, mempertahankan nilai lama, dan menambahkan kolom
“nilai saat ini”. Digunakan apabila tidak ingin menunjukkan perubahan secara
eksplisit.
1.5. Penanganan rapidly changing dimension.
Beberapa dimensi dapat mengalami perubahan secara cepat, terutama apabila dimensi
tersebut memiliki banyak atribut. Salah satu solusi dari masalah ini adalah dengan
memisahkan atribut yang sering berubah pada suatu dimensi ke dimensi baru, yang
kemudian dinamakan "mini-dimensi". Ketika fact table dibangun, foreign keys dari
dimensi asal dan mini-dimensi digabung.
1.6. Penanganan hierarki data: fixed depth dan variable depth.
- Fixed depth, kondisi ketika hierarki data dapat diprediksi jumlah hierarkinya
(N). Contoh: tanggal (tahun-trimester-bulan-minggu-hari, sesuai kebutuhan).
Dalam kasus ini, dapat dilakukan penyimpanan atribut sebanyak N yang
berhubungan dengan masing-masing level.
- Variable depth, kondisi ketika hierarki data tidak dapat diprediksi jumlah
hierarkinya. Dalam kasus ini, salah satu solusinya adalah dengan membangun
bridge table untuk masing-masing level, dengan isi atributnya adalah:
• Parent key, key yang akan di-join apabila ingin menurunkan hierarki
(descend).
• Subsidiary key, key yang akan di-join apabila ingin menaikkan hierarki
(ascend).
• Level name, nama level saat ini.
• Bottom flag, penanda apabila tidak ada level di bawahnya.
• Top flag, penanda apabila tidak ada level di atasnya.
1.7. Multivalued dimension
Beberapa kasus membutuhkan tabel multi-valued dimension ke dalam fact table.
Beberapa pendekatan yang digunakan adalah:
- Pilih satu nilai dan buang sisanya (menyebabkan berkurangnya nilai guna pada
data multi-value.
- Memperbanyak kolom pada dimensi untuk menampung sejumlah dimensi multi-value
(menyebabkan jumlah nilai yang ditampung terbatas pada jumlah kolom yang
ditetapkan di awal).
- Membangun bridge table antara fact table dengan multi-valued dimension.
Bridge table berisi record sejumlah banyaknya data pada multi-valued
dimension dengan key untuk dihubungkan dengan fact table (solusi terbaik,
namun membutuhkan waktu untuk implementasi).
1.8. Conformed dimension
Conformed Dimension merupakan dimensi yang memiliki arti sama pada fakta apapun yang
dihubungkan. Kedua dimensi disebut sebagai conform apabila memiliki nama kolom yang
sama dan domain content yang sama. Kedua dimensi dengan konten yang sama kecuali
primary keys tidak bisa disebut conform.
2. SETUP DEVELOPMENT ENVIRONMENT
Setelah menentukan desain untuk data warehouse, tahap selanjutnya adalah menyiapkan
konfigurasi untuk development environment.
3. DATA COLLECTION AND DATA SAMPLE
Pada tahap ini, data dikumpulkan dari sumber data yang diberikan klien. Setelah itu, diambil
sebagian data untuk dijadikan sampel data yang akan diujicoba pada sistem yang akan
dikembangkan. Pengambilan sampel dilakukan untuk mempercepat proses pengembangan dengan tidak
melakukan loading pada seluruh data yang ada.
4. DEVELOPMENT PROCESS
Tahap ini merupakan proses pengembangan data warehouse dengan sampel data yang telah
didapatkan. Pengembangan yang dilakukan secara umum terbagi menjadi 2 tahap, yaitu koneksi data
dan visualisasi data (mengacu pada SOP Pembuatan Dashboard).
5. TESTING DAN VALIDASI
Pada tahap ini, data warehouse yang telah dikembangkan akan diuji dengan serangkaian uji kasus
(test case) untuk memastikan bahwa data di dalam data warehouse teruji reliabel, akurat, dan
konsisten dengan kerangka data dari organisasi. Apabila terdapat hasil yang tidak valid, maka
proses development process akan dijalankan kembali hingga pengujian mendapat hasil yang valid.
6. SETUP DAN KONFIGURASI LIVE ENVIRONMENT
Setelah didapatkan hasil yang valid pada tahap sebelumnya, maka selanjutnya adalah menyiapkan
konfigurasi live environment dengan penyesuaian dari hasil pengembangan sebelumnya. Live
environment dikembangkan dengan pertimbangkan bahwa produk akan digunakan oleh real user untuk
melakukan aktivitas bisnis.
7. VALIDASI DENGAN DATASET YANG LEBIH BESAR
Setelah live environment dibuat, dilakukan validasi ulang dengan dataset yang lebih besar. Hal
ini untuk memastikan test case teruji dengan baik terhadap lebih banyak kemungkinan data yang
ada. Apabila terdapat kendala maupun hasil yang tidak sesuai, maka kendala tersebut akan
diperbaiki terlebih dahulu. Setelah hasil yang didapat telah valid, maka selanjutnya akan
dijadwalkan dengan User untuk melakukan UAT.
8. TESTING DAN QUALITY CONTROL (QC) BERDASARKAN DOKUMENTASI AWAL
Testing dan quality control (QC) dilakukan oleh Developer bersama dengan tim Functional.
Apabila lolos hasil testing dan quality control, maka tim Functional akan menjadwalkan User
Acceptance Test (UAT). Apabila belum, maka hasil kode program akan dikembalikan ke tim Developer
untuk direvisi. Rincian dari langkah quality control ini dapat merujuk pada SOP QC – UAT BAST
nomor 0006/SAPM/SOP-FN/IX/2021.
9. USER ACCEPTANCE TEST (UAT)
Pada tahap ini, UAT dilakukan oleh tim Functional bersama dengan User. Apabila hasil program
tidak disetujui oleh User, maka tim Internal akan memperbaiki ketidaksesuaian atas hasil
tersebut dengan persetujuan tim Internal maupun User. Rincian dari Langkah UAT dapat merujuk
pada SOP QC – UAT BAST nomor 0006/SAPM/SOP-FN/IX/2021.
10. BERITA ACARA SERAH TERIMA (BAST)
Setelah dilakukan UAT, tim Functional wajib melakukan UAT BAST kepada User dengan mengirimkan
dokumen UAT (dapat melalui Docusign) untuk ditandatangani oleh tim Functional dan User agar
tidak ada konflik saat go-live. Proses UAT BAST harus dilakukan di saat itu juga (di hari yang
sama) sebelum sesi UAT berakhir.
> FLOWCHART
