1 BAB II KAJIAN PUSTAKA 2.1 State Of The Art Review Beberapa penelitian yang berkaitan dengan pengembangan model untuk nearly real time data warehouse...
2.1 State Of The Art Review Beberapa penelitian yang berkaitan dengan pengembangan model untuk nearly real time data warehouse (NRTDWH) telah banyak dilakukan, diantaranya penelitian yang dilakukan oleh Wisswani dkk, (2012) yang melakukan pemodelan change data capture untuk nearly real time data warehouse dengan meletakkan trigger pada sisi On Line Transactional Processing (OLTP). NRTDWH dalam penelitian ini diimplementasikan dalam dua tahapan. Tahap pertama dilakukan dengan memodelkan teknik pengambilan data agar data yang dikelola oleh mesin extract, transfer, load (ETL) menjadi lebih ringkas. Tahap ini meletakkan staging area pada on line transactional processing (OLTP). Selain itu pada OLTP juga diterapkan metode change data capture (CDC) yang akan diimplementasikan dengan active database berupa trigger. Tahap kedua adalah proses sinkronisasi pemindahan data dari staging area ke NRTDWH. Penelitian lain tentang NRTDWH juga dilakukan oleh Bokade dkk, (2013) yang membahas tentang framework dari change data capture berdasarkan pada transaction log file dari suatu basis data dan proses ekstraksi data pada real time data warehouse. Pada penelitian ini dijelaskan bahwa ada beberapa teknik dan teknologi yang dapat diterapkan untuk menangani proses CDC, diantaranya yaitu : (1) Transaction Log File; (2) Trigger Method; (3) RDBMS Replication. Pada penelitian
ini
dinyatakan
bahwa
hampir
11
semua
DBMS
memiliki
12
transaction log file yang mencatat semua perubahan yang terjadi dalam basis data yang dilakukan oleh setiap transaksi. Untuk menangkap perubahan yang terjadi pada basis data, kita harus memeriksa dan menganalisa isi dari transaction log file dari basis data. Ketika proses CDC diimplementasikan menggunakan teknik transaction log file maka proses analisa transaction log file tidak akan mempengaruhi operational transactional database. Dari penelusuran yang penulis lakukan di beberapa sumber pustaka, termasuk di beberapa database hasil penelitian seperti www.doaj.com, www.proquest.com, scholar.google.com, ieeexplore.ieee.org, Penelitian yang membahas tentang integrasi NRTDWH dengan SOA masih sangat jarang dilakukan (jumlah jurnal yang ditemukan kurang dari 6). Cristian, (2010) melakukan penelitian tentang pembuatan model data warehouse dengan menggunakan metode service oriented architecture untuk menunjang sistem informasi eksekutif pada Universitas Budi Luhur. Model ini dikembangkan dengan menggunakan metode SOA dengan tujuan untuk menghasilkan data yang bisa diakses oleh end application yang berbeda-beda dan independen terhadap DBMS. Pengembangan data warehouse dalam penelitian ini menggunakan pendekatan business dimensional life cycle. Salah satu pendekatan yang diusulkan oleh Ralph Kimball, yaitu mengintegrasikan pengembangan dari tiga sudut pandang berbeda, yaitu teknologi, data dan aplikasi dari pendekatan bisnis. Untuk model skema yang digunakan ialah star schema, dimana satu tabel fakta dikelilingi oleh beberapa tabel dimensi. Penggunaan skema ini dilandasi atas kemudahan query dan akses terhadap tabel dimensi yang lebih mudah. Model
13
distribusi data warehouse yang dikembangkan berbasis web service dengan framework WSF/PHP. Web service dikembangkan dalam bentuk file PHP dengan format yang disesuaikan dengan framework. Untuk keperluan prototipe ini, dikembangkan contoh 6 service. Penelitian tentang SOA telah banyak dilakukan, diantaranya penelitian Mankad dan Sajja, (2010) yang membahas bagaimana arsitektur Procedural Developments, Structured Design, Client Server Technology, Transaction Processing, Component Oriented N tier, World Wide Web, Object Oriented Architecture telah berhasil membuktikan bahwa mereka sudah mampu memberikan keuntungan dalam perancangan suatu perangkat lunak tertentu. Akan tetapi disaat yang bersamaan mereka kurang efisien untuk memenuhi kebutuhan yang cepat dalam penyediaan beberapa aplikasi seperti aplikasi terintegrasi. Dalam penelitian ini dijelaskan bahwa arsitektur SOA mampu memberikan solusi terhadap kekurangan dari arsitektur seperti di atas karena: 1. SOA dapat dikembangkan dari sistem yang sudah ada. Service dapat dibuat menggunakan teknologi yang sudah ada dengan pendekatan berbasis komponen. Hal ini membuat SOA mampu memberikan alternatif solusi lain secara fleksibel. 2. SOA dapat ditanamkan pada arsitektur berbasis objek dengan menambahkan lapisan abstraksi. 3. SOA bukan hanya suatu arsitektur dari services jika dilihat dari perspektif teknologi tapi juga suatu kebijakan, praktek dan kerangka kerja dimana SOA dapat memastikan bahwa suatu service yang tepat sudah disediakan dan dikonsumsi.
14
4. SOA dapat menawarkan services baru kepada pelanggan tanpa harus khawatir dengan infrastruktur IT yang ada dibelakangnya. 5. SOA dapat memberikan efektivitas biaya dengan mengintegrasikan sistem historis terpisah dengan penurunan waktu siklus dan biaya. 6. SOA dapat mengurangi risiko dengan meningkatkan visibilitas operasi bisnis. Tabel 2.1 berisi daftar penelitian yang sudah dilakukan yang terkait dengan topik yang penulis ambil pada pembuatan thesis ini. Tabel 2.1 Daftar Penelitian yang dijadikan acuan Area Penelitian No
Judul Penelitian
Model Data Warehouse dengan Service 1 Oriented Architecture untuk Menunjang Sistem Informasi Eksekutif Utilization of Web Services for Service 2 Oriented Architecture Change Data Capture on OLTP Staging 3 Area for Nearly Real Time Data Warehouse base on Database Trigger Framework Of Change Data Capture And 4 Real Time Data Warehouse
Tahun
DWH
NRT SOA
2010
√
X
√
2010
X
X
√
2012
√
√
X
2013
√
√
X
2.2 Konsep Data Warehouse Rainardi (2008:p.1) menjelaskan data warehouse merupakan suatu sistem yang mengambil dan menkonsolidasikan data secara periodik dari sistem asal menjadi suatu penyimpanan data dimensional atau ternormalisasi. Data warehouse biasanya akan tetap menyimpan informasi yang berasal dari beberapa tahun belakangan yang akan dipakai untuk business intelligence atau untuk keperluankeperluan analisis. Data warehouse biasanya diperbarui dalam suatu periode waktu tertentu, tidak setiap suatu transaksi terjadi pada sistem asal.
15
Menurut Vincent Rainardi, ada dua definisi utama dari data warehouse yang dikonsepsikan oleh dua orang yang disebut sebagai bapak dari data warehouse, yaitu Bill Inmon dan Ralph Kimball (Rainardi, 2008:p.16). Menurut Bill Inmon, data warehouse merupakan sekumpulan data yang berorientasi subjek, terintegrasi, non-volatile dan
time-variant untuk mendukung pengambilan
keputusan oleh pihak manajemen (Inmon, 2005:p.29). Menurut Ralp Kimball, data warehouse adalah suatu sistem yang mengambil, membersihkan, menyesuaikan, dan mengirimkan sumber data ke dalam penyimpanan data dimensional dan kemudian mendukung serta mengimplementasikan query dan analisis untuk tujuan pengambilan keputusan (Kimball, 2004:p.23). Definisi lain yang cukup menarik tentang data warehouse dikemukakan oleh Hammergren dan Simon (2009), yang menyebutkan data warehouse sebagai data yang dikoordinasikan, dibangun, dan secara periodik disalin dari berbagai sumber ke dalam sebuah lingkungan yang dioptimalkan untuk analisis dan pengolahan informasi (Hammergren, 2009:p.9). 2.3 Karakteristik Data Warehouse Berikut ini adalah karakteristik utama dari data warehouse menurut Turban (2005:p.306-307): a. Berorientasi-subjek Data diorganisasikan oleh subjek detail (misal berdasarkan pelanggan, jenis kebijakan, dan klaim dalam perusahaan asuransi), yang berisi hanya informasi yang relevan untuk mendukung keputusan. Orientasi subjek memungkinkan para pengguna untuk menentukan tidak hanya bagaimana bisnis mereka sedang
16
berjalan, tetapi juga mengapa ia berjalan. Data warehouse berbeda dengan database operasional dalam hal kebanyakan database operasional mempunyai sebuah orientasi produk dan disetel untuk menangani transaksi yang memperbarui database; orientasi subjek menyediakan sebuah pandangan yang menyeluruh mengenai organisasi. b. Terintegrasi Data pada sumber berbeda dapat dienkode dengan cara yang berbeda. Sebagai contoh, data jenis kelamin dapat dienkode sebagai 0 dan 1 di satu tempat dan ‘m’ dan ‘f’ di tempat lain. Di dalam warehouse, enkode tersebut dibuat (dibersihkan) ke dalam satu format sehinga mereka distandarisasi dan konsisten. Banyak organisasi menggunakan terminologi yang sama untuk data dari jenis yang berbeda. Sebagai contoh, “penjualan bersih” bisa berarti komisi bersih untuk departemen pemasaran, tetapi retur penjualan kotor bagi departemen akuntansi. Data yang terintegrasi mengatasi inkonsistensi dan menyediakan istilah yang seragam di organisasi keseluruhan. Juga, format, waktu dan data bervariasi di seluruh bumi. c. Time-variant (time series) Data tidak menyediakan status saat ini. Mereka disimpan untuk lima atau sepuluh tahun atau lebih dan digunakan untuk tren, peramalan, dan perbandingan. Ada kualitas sementara pada sebuah data warehouse. Waktu adalah dimensi penting yang harus didukung oleh semua data warehouse. Data untuk analisis dari berbagai sumber berisi berbagai poin waktu (misal harian, mingguan, bulanan).
17
d. Non-volatile Sekali dimasukkan ke dalam warehouse, data adalah read-only, mereka tidak bisa diubah atau dibarui. Data usang dibuang, dan perubahan direkam sebagai data baru. Ini memungkinkan data warehouse untuk disesuaikan hampir secara eksklusif untuk akses data. Sebagai contoh, sejumlah besar ruang kosong (untuk pertumbuhan data) umumnya tidak diperlukan dan reorganisasi database dapat dijadwalkan bersama dengan operasi pengisian sebuah data warehouse. e. Ringkas Jika diperlukan, data operasional dikumpulkan ke dalam ringkasan-ringkasan. f. Tidak ternormalisasi Data di dalam sebuah data warehouse biasanya tidak dinormalisasi dan sangat redundan. g. Sumber Semua data ada, baik internal maupun eksternal. h. Metadata Metadata digambarkan sebagai data tentang data. 2.4 Arsitektur Data Warehouse Sistem data warehouse memiliki dua arsitektur utama yaitu : arsitektur aliran data dan arsitektur sistem (Rainardi, 2008:p.29). 2.4.1 Arsitektur aliran data Arsitektur aliran data berisi mengenai bagaimana penyimpanan data diatur di dalam data warehouse dan bagaimana data mengalir dari sistem asal ke pengguna melalui penyimpanan-penyimpanan data ini (Rainardi, 2008:p.29).
18
Penyimpanan data (data stores) merupakan komponen penting dari arsitektur aliran data. Penyimpanan data merupakan satu atau beberapa basis data atau filefile yang berisi data dari data warehouse, yang disusun dalam suatu format tertentu dan terlibat dalam proses-proses data warehouse. Berdasarkan hak akses dari pengguna maka penyimpanan data dapat diklasifikasikan menjadi tiga (Rainardi, 2008:p.30), yaitu: a. User facing data store Penyimpanan data yang tersedia untuk end user dan di-query oleh aplikasi end user. b. Internal data store Penyimpanan data yang digunakan secara internal oleh komponen data warehouse untuk tujuan integrasi, pembersihan, pencatatan dan persiapan data dan tidak dibuka untuk diakses oleh end user dan aplikasi end user. c. Hybrid data store Penyimpanan data yang digunakan baik untuk mekanisme internal data warehouse dan untuk diakses oleh end user dan aplikasi end user. Berdasarkan format data, penyimpanan data dapat diklasifikasikan menjadi empat (Rainardi, 2008:p.30), yaitu: a. Stage Stage merupakan penyimpanan data internal yang digunakan untuk merubah dan mempersiapkan data yang diperoleh dari sistem asal, sebelum data dikirim ke penyimpanan data yang lain dalam data warehouse.
19
b. Normalized data store (NDS) NDS merupakan penyimpanan data master internal dalam bentuk satu atau beberapa basis data relasional ternormalisasi untuk tujuan integrasi data yang berasal dari beberapa sumber data yang ditangkap dalam proses stage, sebelum data dikirim ke user-facing data store. c. Operational data store (ODS) ODS merupakan penyimpanan data hybrid dalam bentuk satu atau beberapa basis data relasional ternormalisasi yang mengandung data transaksi serta data master versi terkini untuk tujuan mendukung aplikasi operasional. d. Dimensional data store (DDS) DDS merupakan user facing data store dalam bentuk satu atau beberapa basis data relasional, dimana data disusun dalam format dimensional untuk tujuan mendukung permintaan analisis data. Untuk lebih jelasnya arsitektur aliran data dapat dilihat pada gambar 2.1:
Gambar 2.1 Arsitektur Aliran Data (Sumber : Rainardi, 2008:p.35)
20
2.4.2 Arsitektur sistem Arsitektur sistem berisi mengenai konfigurasi fisik dari server-server, jaringan, perangkat lunak, perangkat penyimpanan, dan klien-klien (Rainardi, 2008:p.29). Perancangan arsitektur sistem membutuhkan pengetahuan tentang perangkat keras (khususnya server), jaringan (yang berhubungan dengan keamanan dan kinerja) serta media penyimpanan (SAN, RAID, Tape Backup). Untuk lebih jelasnya arsitektur sistem dapat dilihat pada gambar 2.2:
Gambar 2.2 Arsitektur Sistem (Sumber : Rainardi, 2008:p.42) 2.5 Metodologi Pengembangan Data Warehouse Pembuatan data warehouse pada penelitian ini menggunakan pendekatan business dimensional lifecycle dari Ralph Kimball. Adapun diagram dari pendekatan business dimensional lifecycle ini dapat dilihat pada gambar 2.3:
21
Project Planning
Business Requirement Definition
Technical Architecture Design
Product Solution & Installation
Dimensional Modelling
Physical Design
End User Application Specification
End User Application Development
Data Staging Design & Development
Deployment
Maintenance & Growth
Project Management
Gambar 2.3 Diagram Business Dimensional Life Cycle (Sumber : Kimball, 1998:p.2.3)
Pendekatan business life cycle yang diusulkan oleh Ralp Kimball ini adalah pendekatan yang mengintegrasikan 3 konsepsi yang berbeda dari sudut pandang bisnis, yaitu teknologi, data, dan aplikasi (Kimball, 1998:p.2.2). Berikut ini akan dijelaskan masing-masing komponen yang terdapat pada diagram business dimensional lifecycle: a. Project Planning Perencanaan proyek membahas definisi dan cakupan dari proyek data warehouse, termasuk penilaian kesiapan dan justifikasi bisnis. Perencanaan proyek berfokus pada sumber daya, ditambah dengan tugas proyek yang akan diberikan, durasi waktu, dan urutan pengerjaan. b. Data Track : Dimensional Modelling Definisi dari kebutuhan bisnis menentukan data yang diperlukan untuk kebutuhan analisis pengguna bisnis. Merancang model data untuk mendukung analisis membutuhkan pendekatan yang berbeda dari yang digunakan untuk
22
desain sistem operasional. Tahapan ini mengidentifikasi tabel fakta, dimensidimensi yang terkait dan atribut-atribut. Desain database logis dilengkapi dengan struktur tabel yang sesuai dan hubungan primary / foreign key. Rencana agregasi awal juga dikembangkan pada tahapan ini. c. Data Track : Physical Design Desain database fisik yang berfokus pada bagaimana cara mendefinisikan struktur fisik yang diperlukan untuk mendukung desain database logis. Elemen utama dari proses ini meliputi mendefinisikan penamaan standar dan menyiapkan lingkungan database. Pengindeksan awal dan strategi partisi juga ditentukan pada tahapan ini. d. Data Track : Data Staging Design and Development Tahapan ini berfokus pada perencanaan dan pembuatan database data staging. Proses pada data staging ini meliputi extraction, transformation, dan load. e. Technology Track : Technical Architecture Design Lingkungan data warehouse membutuhkan integrasi dari beberapa jenis teknologi. Pada tahapan ini akan ditentukan jenis teknologi yang akan dipakai pada data warehouse seperti spesifikasi perangkat keras server, jaringan, perangkat lunak sistem operasi, perangkat lunak basis data, dll. Ada tiga hal penting yang harus dipertimbangkan dalam tahapan ini, yaitu : analisa kebutuhan arsitektur, arsitektur yang sedang berjalan dan arah pengembangan arsitektur di masa depan.
23
f. Technology Track : Product Selection and Installation Pada tahapan ini akan dilakukan proses evaluasi dan pemilihan dari komponenkomponen hardware dan software yang telah dipilih pada tahapan technical architecture design. Setelah dipilih maka komponen ini kemudian akan dipakai/dipasang. g. Application Track : End User Application Specification Sebaiknya mendefinisikan satu set aplikasi pengguna akhir yang standar karena tidak semua bisnis pengguna memerlukan akses ad hoc ke gudang data. Spesifikasi aplikasi menggambarkan template laporan, parameter yang harus dimasukkan oleh pengguna, dan perhitungan yang diperlukan. Spesifikasi ini memastikan bahwa tim pengembangan dan pengguna bisnis memiliki pemahaman umum yang sama akan aplikasi yang akan dikembangkan. h. Application Track : End User Application Development Pada tahapan ini akan dikembangkan end user application yang telah disesuaikan dengan spesifikasi yang telah ditentukan pada tahapan end user application specification. i. Deployment Deployment merupakan proses konvergensi dari teknologi, data, dan aplikasi pengguna akhir yang diakses dari komputer desktop pengguna bisnis. j. Maintenance and Growth Pada tahapan ini akan dilakukan proses pemeliharaan pada teknologi, data, dan aplikasi pengguna akhir yang terdapat dalam lingkungan data warehouse. Seiring perkembangan waktu pasti akan terjadi pertumbuhan data yang pesat
24
dimana mengakibatkan terjadinya penyesuaian pada teknologi, data, dan aplikasi pengguna akhir terhadap kebutuhan yang baru. k. Project Management Manajemen proyek memastikan bahwa kegiatan-kegiatan yang terdapat dalam business dimensional lifecycle tetap berada pada jalur yang benar (spesifikasi yang telah ditentukan sebelumnya) dan berjalan sinkron antar kegiatan satu dengan kegiatan yang lain. 2.6 Sistem ETL dalam Data Warehouse ETL merupakan singkatan dari extract, transform, load. Sistem ETL merupakan sekumpulan proses-proses yang mengambil data dari sistem sumber, melakukan perubahan pada data dan mengirimkan data ke suatu sistem target (Rainardi, 2008:p.4). Menurut Kimball, sistem ETL merupakan pondasi dari data warehouse. Sebuah sistem ETL yang dirancang dengan baik akan mengekstrak data dari sistem sumber, memberlakukan standar kualitas data dan konsistensi data, melakukan penyesuaian data sehingga beberapa sumber berbeda dapat digunakan secara bersama-sama, dan pada akhirnya akan mengirimkan data dalam format siap pakai sehingga pengembang aplikasi dapat membangun aplikasi dan pengguna akhir dapat membuat keputusan (Kimball, 2004:p.xxi). Berikut ini pada gambar 2.4 akan ditunjukkan arsitektur sistem ETL dalam data warehouse khususnya untuk bagian staging area:
25
Gambar 2.4 Arsitektur Sistem ETL pada Bagian Staging Area (Sumber : Kimball, 2004:p.18)
2.6.1 Extraction Data mentah yang berasal dari sistem sumber biasanya ditulis langsung ke disk dengan beberapa restrukturisasi minimal sebelum transformasi konten yang signifikan terjadi. Data dari sistem sumber terstruktur (seperti IMS database, atau XML data set) sering ditulis ke flat file atau tabel relasional dalam langkah ini. Hal ini memungkinkan proses ekstraksi data menjadi sesederhana dan secepat mungkin serta memungkinkan fleksibilitas yang lebih besar untuk mengulangi proses ekstraksi data jika ada gangguan. Data awal yang diambil kemudian dapat dibaca beberapa kali seperlunya untuk mendukung langkah-langkah berikutnya. Dalam beberapa kasus, data awal yang diambil akan dibuang setelah langkah pembersihan selesai, sedangkan pada kasus lain data akan disimpan sebagai arsip cadangan jangka panjang. Data awal yang diambil juga dapat disimpan untuk setidaknya satu siklus capture sehingga perbedaan antara proses ekstraksi data yang berturut-turut dapat dihitung (Kimball, 2004:p.18).
26
2.6.2 Cleaning Proses cleaning ini merupakan salah satu bagian dari proses data transformation. Dalam kebanyakan kasus, tingkat kualitas data yang dapat diterima dari sistem sumber bisa berbeda dengan kualitas yang dibutuhkan oleh data warehouse. Kualitas pengolahan data dapat melibatkan banyak langkah diskrit, termasuk memeriksa nilai-nilai yang valid (apakah ada kode pos? dan apakah kode pos berada dalam rentang nilai yang valid?), memastikan konsistensi pada nilai (apakah kode pos dan kota konsisten?), menghapus duplikat (apakah pelanggan yang sama muncul dua kali dengan atribut sedikit berbeda?), dan memeriksa apakah aturan bisnis yang kompleks dan prosedur telah ditegakkan (apakah pelanggan platinum memiliki keterkaitan dengan status kredit diperpanjang?). Transformasi data-cleaning bahkan mungkin melibatkan intervensi manusia. Hasil langkah pembersihan data sering disimpan secara semi permanen karena transformasi yang diperlukan sulit dan tidak dapat diubah. Ini adalah pertanyaan yang menarik dalam lingkungan apapun, apakah data yang sudah dibersihkan dapat dikirim kembali ke sistem sumber untuk meningkatkan kualitas data mereka dan mengurangi kebutuhan untuk memproses masalah data yang sama berulang-ulang. Bahkan jika data yang sudah dibersihkan tidak dapat dikirimkan ke sistem sumber, permasalahan ini tetap harus dilaporkan supaya dapat dilakukan perbaikan dalam sistem sumber (Kimball, 2004:p.18-19). 2.6.3 Conforming Proses conforming merupakan salah satu bagian dari proses data transformation. Data konformasi diperlukan ketika dua atau lebih sumber data
27
digabungkan ke dalam data warehouse. Sumber data terpisah tidak dapat dilihat bersama-sama kecuali beberapa atau semua label tekstual dalam sumber-sumber ini telah dibuat identik dan kecuali langkah-langkah numerik yang serupa telah dirasionalisasi secara matematis sehingga perbedaan dan rasio antara langkahlangkah ini menjadi masuk akal. Data konformasi merupakan langkah signifikan yang lebih sederhana dari data cleaning. Data konformasi memerlukan kesepakatan perusahaan besar untuk penggunaan domain dan langkah-langkah standar (Kimball, 2004:p.19). 2.6.4 Delivering Proses delivering ini lebih dikenal dengan nama proses loading. Proses delivering adalah suatu proses untuk mengirim data hasil proses transformasi data (data yang sudah dibersihkan dan data yang sudah disesuaikan formatnya) ke dalam data warehouse. Data warehouse ini berupa penyimpanan data dimensional (Data Dimensional Store). Isi dari data dimensional store (DDS) inilah yang akan diakses oleh aplikasi end user baik untuk kepentingan business intelligence (BI), analytics (On Line Analytical Processing), data mining, dashboard, scorecards, reports (Rainardi, 2008). 2.7 Metode ETL Dalam hal siapa yang memindahkan data keluar dari sistem sumber, kita dapat mengkategorikan metode ETL menjadi empat pendekatan (Rainardi, 2008:p.176):
28
a. Proses ETL menarik data keluar dari sistem sumber dengan melakukan query secara reguler ke basis data sistem sumber. Ini merupakan pendekatan yang paling umum digunakan. Proses ETL melakukan koneksi ke basis data sistem sumber, melakukan query data, dan membawa data keluar. b. Proses trigger di basis data sistem sumber mendorong data yang berubah keluar dari sistem sumber. Trigger basis data adalah kumpulan dari perintah SQL yang dieksekusi setiap ada operasi insert, update, atau delete pada suatu tabel. Dengan menggunakan trigger, kita dapat menyimpan baris data yang berubah ke dalam tabel yang lain. c. Proses terjadwal yang terdapat pada sistem sumber yang mengirim data keluar secara reguler. Hal ini mirip dengan pendekatan yang pertama, akan tetapi program yang melakukan query ke basis data bukanlah suatu program ETL eksternal, melainkan suatu program eksporter internal yang berjalan pada server sistem sumber. d. Log reader membaca file log basis data untuk mengidentifikasi perubahan data. File log basis data mengandung suatu catatan dari suatu transaksi yang terjadi pada basis data tersebut. Log reader adalah suatu program yang memahami format dari data yang terdapat pada file log. Log reader membaca file-file log, mengirim data ke luar sistem sumber, dan menyimpan data di tempat lain. Keempat metode ETL ini dapat dilihat pada gambar 2.5:
29
Gambar 2.5 Empat Metode ETL (Sumber : Rainardi, 2008:p.176) 2.8 Pendekatan dalam Pembuatan Data Warehouse Menurut Ponniah, ada dua pendekatan dalam pembuatan data warehouse yaitu pendekatan top-down dan pendekatan bottom-up (Ponniah, 2010:p.29). 2.8.1 Pendekatan Top-Down Bill Inmon adalah salah satu pendukung terdepan dari pendekatan top-down. Dia telah mendefinisikan data warehouse sebagai repositori terpusat untuk seluruh perusahaan. Dalam pendekatan ini, data di gudang data disimpan pada tingkat terendah dari granularity yang didasarkan pada model data dinormalisasi. Dalam visi Inmon, gudang data pada pusat "Corporate Information Factory" (CIF) menyediakan kerangka logis untuk memberikan kecerdasan bisnis (BI) untuk perusahaan. Operasi bisnis menyediakan data untuk mendorong CIF. Data warehouse terpusat akan menyediakan kebutuhan untuk dependent data mart yang mungkin dirancang berdasarkan model data dimensi. Keuntungan dari pendekatan ini adalah: a. Bukan penggabungan dari data mart-data mart yang berbeda. b. Tempat penyimpanan data hanya satu, terpusat.
30
c. Aturan dan kontrol dilakukan secara terpusat. d. Dapat melihat hasil cepat jika diimplementasikan secara iteratif. Kerugian dari pendekatan ini adalah: a. Membutuhkan waktu pengembangan yang lebih lama walaupun dengan menggunakan metode iteratif. b. Memiliki resiko kegagalan yang sangat tinggi. c. Membutuhkan keterampilan lintas fungsional yang sangat tinggi. d. Pengeluaran akan besar jika tidak terdapat pembuktian dari konsep. 2.8.2 Pendekatan Bottom-Up Ralp Kimball, merupakan salah satu pendukung terdepan untuk pendekatan Bottom-Up. Dalam pendekatan ini data mart dibuat pertama kali untuk memberikan analisis dan kemampuan pelaporan untuk subjek bisnis yang spesifik berdasarkan pada model data dimensi. Data mart berisi data pada tingkat terendah dari granularity dan juga sebagai ringkasan, tergantung pada kebutuhan untuk analisis. Data mart ini kemudian akan digabungkan menjadi suatu data warehouse. Keuntungan dari pendekatan ini: a. Cepat dan mudah untuk diimplementasikan. b. Dapat memberikan keuntungan atas investasi dengan suatu konsep yang dapat dibuktikan. c. Resiko kegagalan kecil. d. Dapat melakukan penjadwalan supaya data mart yang penting dibuat terlebih dahulu.
31
Kerugian dari pendekatan ini: a. Setiap data mart memiliki pandangan yang berbeda akan data. b. Dapat terjadi data redundan pada setiap data mart. c. Data tidak konsisten. d. Interface tidak dapat diatur. 2.9 Dimensional Data Modelling Menurut Rainardi (2008), Sebuah gudang data adalah sistem yang mengambil data dari sistem sumber dan meletakkannya ke dalam penyimpanan data dimensi (data dimensional store). Sebuah data dimensional store (DDS) adalah satu atau beberapa database yang berisi kumpulan data mart dimensional. Data mart dimensional adalah sekelompok tabel fakta yang terkait satu sama lainnya dan dikelilingi oleh beberapa tabel dimensi yang berhubungan dengan tabel fakta, yang berisi pengukuran dari kegiatan bisnis yang dikategorikan oleh tabel dimensi (Rainardi, 2008:p.7). Sebuah penyimpanan data dimensional merupakan penyimpanan data dalam bentuk yang tidak dinormalisasi dimana semua tabel dimensinya telah disesuaikan. Tabel dimensi yang sesuai berarti semua tabel dimensi memiliki dimensi yang sama atau satu tabel dimensi adalah subset dari tabel dimensi yang lain. Dimensi A dikatakan himpunan bagian dari dimensi B ketika semua kolom dimensi A ada di dimensi B dan semua baris dimensi A ada di dimensi B (Rainardi, 2008:p.7).
32
Sebuah penyimpanan data dimensional dapat diimplementasikan secara fisik dalam beberapa bentuk skema yang berbeda: skema bintang (star schema), skema kepingan salju (snow flake schema), dan skema galaksi (galaxy schema). a. Skema Bintang Dalam skema bintang, dimensi tidak memiliki sub tabel (sub dimensi). Skema bintang dapat dilihat pada gambar 2.6.
Gambar 2.6 Skema Bintang (Sumber : Inmon, 2005:p.360) b. Skema Kepingan Salju Dalam skema kepingan salju, dimensi dapat memiliki sub dimensi. Tujuan adanya sub dimensi ini adalah untuk meminimalkan terjadinya pengulangan data yang sama (data redundansi). Skema kepingan salju dapat dilihat pada gambar 2.7.
Gambar 2.7 Skema Kepingan Salju (Sumber : Inmon, 2005:p.361)
33
c. Skema Galaksi Galaksi skema juga dikenal dengan nama skema konstelasi fakta (fact constellation schema). Dalam skema galaksi kita memiliki dua atau lebih tabel fakta yang saling terkait satu sama lainnya yang dikelilingi oleh beberapa tabel dimensi. Kelebihan dari skema bintang adalah skema bintang lebih sederhana dan lebih konsisten dari skema kepingan salju dan skema galaksi, karena hanya memiliki satu level pada semua dimensi, sehingga memudahkan proses ETL untuk memuat data ke DDS. Kekurangan skema bintang adalah membutuhkan ruang penyimpanan data yang besar karena banyak terjadi pengulangan data (data redundansi) (Rainardi, 2008:p.7). Kelebihan dari skema kepingan salju adalah bahwa beberapa aplikasi analisis data bekerja lebih baik dengan skema kepingan salju dibandingkan dengan skema bintang atau skema galaksi. Kelebihan yang lain dari skema kepingan salju adalah mengurangi terjadinya data redundansi, sehingga lebih sedikit ruang penyimpanan data yang diperlukan. Kekurangan dari skema kepingan salju adalah skemanya lebih komplek karena adanya sub dimensi. Hal ini menyebabkan waktu respon dari suatu query juga akan menurun karena adanya operasi JOIN untuk menggabungkan tabel dimensi dengan tabel sub dimensi (Rainardi, 2008:p.7). Kelebihan dari skema galaksi adalah kemampuan untuk memodelkan peristiwa bisnis (business event) secara lebih akurat dengan menggunakan beberapa tabel fakta. Kekurangan dari skema galaksi adalah arsitekturnya lebih komplek karena terdapatnya dua atau lebih tabel fakta. Hal ini menyebabkan skema ini lebih
34
susah untuk dipahami dan waktu respon juga jauh lebih lambat dibandingkan skema kepingan salju karena operasi JOIN menjadi lebih komplek karena melibatkan beberapa tabel fakta yang terhubung dengan beberapa tabel dimensi (Rainardi, 2008:p.7). 2.10 Komponen Dimensional Data Modelling Dalam dimensional modelling, basis data dibangun berdasarkan pengukuran numerik dari perusahaan. Tabel fakta mengandung pengukuran dan tabel dimensi mengandung konteks pengukuran yang terdapat disekitarnya (Kimball, 2004:p.209). Dalam dimensional data modelling terdapat dua komponen utama yaitu tabel fakta dan tabel dimensi. 2.10.1 Tabel fakta Hubungan antara tabel fakta dan pengukuran adalah sangat sederhana. Jika pengukuran ada, maka dapat dimodelkan menjadi suatu baris pada tabel fakta. Jika suatu baris dari tabel fakta ada maka itu adalah pengukuran (Kimball, 2004:p.209). Sebuah tabel fakta adalah struktur yang berisi banyak kejadian data. Disekitar tabel fakta adalah tabel dimensi, yang menggambarkan salah satu aspek penting dari tabel fakta. Jumlah kemunculan data pada tabel dimensi lebih sedikit dibandingkan dengan jumlah kemunculan data pada tabel fakta (Inmonn, 2005: p.360). Tabel fakta adalah suatu tabel yang menjadi pusat dari beberapa tabel dimensi dalam skema bintang (Inmonn, 2005:p.497).
35
Ciri-ciri tabel fakta adalah (Wiswani, 2012:p.22): a. Primary key pada tabel fakta terdiri atas gabungan lebih dari satu primary key yang dimiliki tabel-tabel dimensi yang terkait (concatenated key). b. Memiliki tingkatan data yang telah teridentifikasi. c. Mudah untuk melakukan rekap data. d. Memiliki jumlah record yang banyak. e. Memiliki kolom atau atribut yang sedikit. f. Tidak memiliki baris yang berisi nilai null. 2.10.2 Tabel dimensi Tabel dimensi merupakan tempat dimana sekumpulan data yang berhubungan dengan tabel fakta ditempatkan dalam suatu tabel multi dimensi (Inmonn, 2005:p.495). Tabel dimensi adalah tabel yang berisi berbagai atribut yang menjelaskan kunci dimensi yang terdapat pada tabel fakta (Rainardi, 2008:p.76). Ciri-ciri tabel dimensi adalah (Wiswani, 2012:p.22): a. Memiliki key unik pada tabel dimensi (primary key). b. Memiliki jumlah kolom atau atribut yang banyak. c. Atributnya textual dan tidak saling berhubungan. d. Tabelnya tidak dilakukan normalisasi. e. Mempunyai kemampuan untuk drill-down dan roll-up. f. Memiliki jumlah record yang sedikit dibandingkan tabel fakta.
36
2.11 Agregasi Tabel Fakta Agregasi adalah proses perhitungan ringkasan data dari keseluruhan data (record) yang ada. Hal ini sering digunakan untuk mengurangi ukuran tabel fakta dengan menggabungkan data ke dalam ringkasan data jika tabel fakta dibuat. Namun, ketika data diringkas dalam tabel fakta, informasi rinci tidak lagi langsung tersedia bagi analis. Jika informasi rinci diperlukan, baris detail yang diringkas harus diidentifikasi dan dicari, mungkin dalam sistem sumber yang memberikan data. Data tabel fakta harus dipertahankan pada kemungkinan granularity terbaik. Menggabungkan data dalam tabel fakta hanya boleh dilakukan setelah mempertimbangkan konsekuensinya (Technet, 2014). Mencampur data agregat dan rinci dalam tabel fakta dapat menyebabkan masalah dan komplikasi bila menggunakan data warehouse. Sebagai contoh, order penjualan sering berisi beberapa item baris dan mungkin berisi diskon biaya, pajak, atau pengiriman yang diterapkan pada total order bukan item baris individu, namun jumlah dan identifikasi barang dicatat pada tingkat item baris. Permintaan summarization menjadi lebih kompleks dalam situasi ini, dan alat-alat seperti Analysis Services sering membutuhkan pembuatan suatu filter khusus untuk menangani permasalahan ini (Technet, 2014). Ada dua pendekatan yang dapat digunakan dalam situasi ini. Satu pendekatan adalah untuk mengalokasikan nilai-nilai tingkat untuk baris item berdasarkan nilai, kuantitas, atau berat pengiriman. Pendekatan lain adalah untuk membuat dua tabel fakta, satu berisi data pada tingkat item baris, yang lain berisi informasi order-level. Kunci identifikasi urutan harus dilakukan dalam tabel rinci
37
fakta sehingga dua tabel dapat dihubungkan. Urutan tabel kemudian dapat digunakan sebagai tabel dimensi ke tabel detail, dengan nilai order-level yang dianggap sebagai atribut dari tingkat urutan hirarki dimensi (Technet, 2014). 2.12 Manajemen Kunci Sebuah surrogate key adalah identifier dari baris data master dalam data warehouse. Dalam DDS, surrogate key digunakan sebagai primary key dari tabel dimensi. Surrogate key adalah bilangan bulat berurutan, mulai dari 0. Jadi, surrogate key adalah 0, 1, 2, 3, ..., dan seterusnya. Dengan menggunakan surrogate key, kita dapat mengidentifikasi data unik yang terdapat pada tabel dimensi. Surrogate key juga ada pada tabel fakta untuk mengidentifikasi atribut dimensi untuk suatu transaksi bisnis tertentu. Surrogate key digunakan untuk menghubungkan tabel fakta dan tabel dimensi. Misalnya, dengan menggunakan surrogate key, kita dapat mengetahui data detail dari seorang pelanggan yang terlibat pada suatu transaksi tertentu (Rainardi, 2008:p.37). Natural key adalah suatu identifier unik dari baris data pada suatu tabel master yang terdapat dalam sistem sumber (OLTP). Ketika terjadi pengambilan data dari OLTP untuk dikirim ke data staging, maka kita perlu menerjemahkan natural key dari sistem sumber menjadi surrogate key untuk data warehouse. Hal ini dapat dilakukan dengan memeriksa surrogate key yang terdapat pada data staging, untuk setiap nilai natural key dari sistem sumber. Jika natural key ada di data staging, itu berarti data sudah ada di data staging dan perlu diperbarui. Jika
38
natural key tidak ada di data staging, itu berarti data tidak ada di data staging dan perlu dibuat (Rainardi, 2008:p.37). Surrogate key tidak akan memiliki arti apa-apa sebelum dilakukan mapping dengan natural key yang terdapat pada sistem sumber (Kimball, 2004:p.214). 2.13 Metode Ekstraksi Data Setelah kita berhasil melakukan koneksi ke sumber data (sistem sumber) maka selanjutnya kita bisa melakukan proses ekstraksi data. Ketika melakukan ekstraksi data dari suatu basis data relasional yang terdiri dari banyak tabel, kita dapat menggunakan salah satu dari empat metode di bawah ini (Rainardi, 2008:p.180-186) : a. Whole Table Every Time Metode whole table every time akan digunakan jika ukuran tabelnya kecil, seperti suatu tabel yang terdiri dari 3 kolom bertipe integer atau varchar (10), dan hanya berisi beberapa baris data. Alasan yang lebih umum mengapa memakai metode ini adalah karena tidak ada timestamp atau kolom identitas yang dapat digunakan untuk mengetahui baris mana yang telah diperbarui sejak proses ekstraksi data yang terakhir. b. Incremental Extract Tabel transaksi dalam suatu organasisasi besar adalah suatu tabel besar yang berisi ratusan ribu baris bahkan ratusan juta baris (atau lebih banyak lagi). Hal ini menyebabkan proses ekstraksi data dapat memakan waktu berhari-hari untuk mengekstrak data dari seluruh tabel. Proses ini merupakan proses yang sangat
39
intensif memakai sumber daya harddisk (storage device) sehingga dapat menurunkan kinerja transaksional pada aplikasi front-end karena terjadi bottleneck pada basis data. Hal Ini bukanlah pilihan yang layak sebagai metode ekstraksi data (karena waktu yang dibutuhkan untuk mengekstraksi data), jadi perlu suatu metode lain untuk mengekstrak data dari sistem sumber. Untuk mengatasi permasalah seperti kasus ini maka digunakan metode incremental extraction. Incremental extraction adalah teknik untuk men-download hanya baris yang mengalami perubahan data pada sistem sumber, bukan men-download seluruh baris yang terdapat pada suatu tabel. Kita dapat menggunakan beberapa hal untuk mengekstraksi data dengan metode incremental extraction, yaitu : kolom timestamp, kolom identitas, tanggal transaksi, pemicu (triggers), atau kombinasi dari beberapa metode ini. c. Fixed Range Jika tidak mungkin untuk mengekstrak seluruh tabel karena tabel terlalu besar dan tidak mungkin untuk melakukan metode incremental extraction, misalnya, karena tidak ada kolom timestamp atau kolom timestamp tidak dapat diandalkan, karena tidak ada kolom identitas incremental extraction yang dapat diandalkan, dan karena tidak mungkin untuk memasang pemicu (triggers) dalam sistem sumber maka ada satu pendekatan yang lain yang bisa kita lakukan. Kita dapat menggunakan metode "fixed range". Pada dasarnya dengan menggunakan metode fixed range, kita akan mengekstrak sejumlah data yang berada pada suatu jangka waktu tertentu. Misalnya, kita
40
mengekstrak data enam bulan terakhir, berdasarkan tanggal transaksi. Kita bisa mendapatkan durasi periode waktu transaksi dari sumber aplikasi jika ada pembatasan pada aplikasi front-end. Sebagai contoh, ketika proses closing (tutup buku) akhir bulan dilakukan, maka baris data tidak akan dapat diubah lagi. Dalam kasus ini, kita dapat men-download data pada lima minggu terakhir pada saat setiap kali proses ETL berjalan atau kita dapat men-download data di mana tanggal transaksi terjadi setelah tanggal akhir bulan (closing date). Jika tidak ada kolom tanggal transaksi dalam tabel dan kita tidak dapat mengekstrak seluruh tabel karena merupakan suatu tabel besar, maka kita dapat menggunakan systemassigned row ID untuk mengekstrak data dengan metode fixed range, seperti mengekstrak 100.000 baris data yang terakhir. Yang dimaksud dengan system-assigned row ID adalah kolom tersembunyi dalam setiap tabel yang berisi nilai-nilai sekuensial yang diberikan oleh sistem. Tidak semua sistem database memiliki system-assigned row ID; misalnya, Oracle dan Informix memiliki system-assigned row ID, tapi SQL Server dan DB/2 tidak. (Dalam DB/2, system-assigned row ID adalah tipe data, bukan kolom tersembunyi.) Bila menggunakan system-assigned row ID, kita tidak memiliki batasan pada aplikasi front-end, jadi kita perlu memonitor sistem sumber dan mencari tahu berapa banyak baris yang kita perlu ambil setiap kali proses ekstraksi data dilakukan. Men-download kolom primary key setiap hari, dan membandingkan data primary key antar setiap proses download, setiap hari, untuk mendeteksi perubahan pada data. Proses identifikasi baris baru dan baris yang dihapus sangat mudah dilakukan dengan membandingkan primary key.
41
d. Related Tables Jika baris dalam tabel sumber diperbarui, maka kita perlu untuk mengambil baris yang bersesuaian dalam tabel lain yang terkait dengan baris pada tabel yang diperbarui. Sebagai contoh, jika order ID 34552 di tabel header order diperbarui dan diekstraksi ke gudang data, baris untuk order ID 34552 pada tabel detail order juga harus diekstrak ke gudang data, dan sebaliknya. Sebagai contoh, jika sebuah baris dalam tabel detail order diperbarui dan baris tersebut diekstraksi ke dalam gudang data, maka baris yang bersesuaian di tabel header order juga perlu diekstrak ke dalam gudang data. Hal ini juga berlaku pada waktu menyisipkan dan menghapus baris data. Jika baris baru (order baru) dimasukkan ke dalam tabel header order dalam sistem sumber, maka baris tabel detail order yang bersesuaian dengan baris baru pada tabel header order juga perlu dimasukkan ke dalam data warehouse tabel detail order. Jika suatu baris ditandai sebagai “canceled” (soft delete) dalam tabel header order pada sistem sumber, maka baris yang bersesuaian pada tabel detail order juga harus dibatalkan (canceled). Kita juga dapat melakukan hal ini dalam aplikasi data warehouse, tapi idealnya hal itu dilakukan dalam database data warehouse. Jika suatu baris secara fisik dihapus dalam tabel header order, maka baris yang bersesuaian pada tabel detail order dalam data warehouse juga perlu ditandai sebagai dihapus. Untuk melakukan hal ini, maka kita harus mengidentifikasi perubahan baris dalam tabel pertama, dan kemudian menggunakan hubungan relasi antara kunci primer (primary key) dan kunci asing (foreign key), kita juga mengidentifikasi baris dalam tabel kedua, dan
42
sebaliknya. Sebagai contoh, dalam kasus yang melibatkan tabel header order dan tabel detail order, terlebih dahulu kita menemukan adanya baris yang berubah pada tabel header order, maka kemudian kita akan mengidentifikasi baris yang bersesuaian dalam tabel detail order, dan pada akhirnya kita akan mengekstrak kedua set baris dari kedua tabel tersebut ke dalam data warehouse. 2.14 Slowly Changing Dimension Slowly Changing Dimension (SCD) adalah suatu teknik yang digunakan untuk menyimpan nilai historis dari atribut-atribut yang terdapat pada suatu tabel dimensi (Rainardi, 2008:p.80). Ada tiga tipe dari SCD yaitu : a. SCD tipe 1 SCD tipe 1 adalah suatu teknik SCD yang menimpa nilai lama dari suatu atribut dengan nilai yang baru, sehingga nilai lama tidak dipertahankan. b. SCD tipe 2 SCD tipe 2 adalah suatu teknik SCD yang mempertahankan nilai lama dari suatu atribut dengan membuat baris data baru setiap terjadi perubahan pada nilai atribut tersebut. c. SCD tipe 3 SCD tipe 3 adalah suatu teknik SCD yang mempertahankan nilai lama dari suatu atribut dengan meletakkan nilai lama ini pada kolom yang lain pada baris data yang sama. Umumnya, SCD tipe 2 lebih fleksibel untuk menyimpan nilai historis dari atribut-atribut dimensional. Hal ini dikarenakan dengan SCD tipe 2, kita dapat
43
menyimpan banyak versi nilai historis dari atribut-atribut dimensional tanpa mengubah struktur tabel (Rainardi, 2008:p.81). SCD tipe 3 menggunakan kolom untuk menyimpan nilai-nilai lama, sehingga SCD tipe 3 menjadi tidak fleksibel. SCD tipe 3 ideal digunakan untuk situasi di mana kita tidak memiliki banyak versi nilai (lima atau lebih sedikit) dan kita tahu hanya akan ada sejumlah versi dari nilai atribut tersebut. SCD tipe 3 ini juga cocok digunakan ketika perubahan nilai atribut ini mempengaruhi cukup banyak baris data. Dengan kata lain, banyak baris dimensi mengubah nilai atribut ini pada saat yang sama (simultan) (Rainardi, 2008:p.81). 2.15 Real Time Data Warehouse Data warehouse tradisional adalah pasif, memberikan tren historis, sedangkan real-time data warehouse adalah dinamis, memberikan pandangan yang paling up-to-date tentang suatu bisnis secara real time. Sebuah real time data warehouse akan akan diperbarui secara terus menerus, dengan waktu tunggu hampir mendekati nol (Ponniah, 2010:p.50). Real-time ETL bukanlah layanan data warehouse yang benar-benar real time. Dengan kata lain, real time ETL merupakan suatu perangkat lunak yang memindahkan data secara asynchronous (secara terus menerus) ke dalam suatu data warehouse dengan terdapat waktu jeda setelah proses eksekusi transaksi bisnis pada sistem sumber (Kimball, 2004:p.424). Sebuah gudang data, beberapa tahun yang lalu, biasanya diperbarui setiap hari atau setiap minggu. Dalam dua sampai tiga tahun terakhir, telah terjadi lebih banyak dan lebih banyak lagi permintaan untuk meningkatkan frekuensi update
44
data pada gudang data. Para pengguna ingin melihat data dalam gudang data diperbarui setiap dua menit atau bahkan secara real time. Sebuah real time data warehouse adalah gudang data yang diperbarui (dengan ETL) saat transaksi terjadi dalam sistem sumber (Rainardi, 2008:p.27). Sebagai contoh, kita dapat menempatkan pemicu (triggers) pada tabel transaksi penjualan dalam sistem sumber sehingga setiap kali ada transaksi penjualan yang dimasukkan ke dalam database, maka triggers akan aktif dan kemudian akan mengirim data baru ke gudang data sebagai sebuah pesan. Data warehouse memiliki active listener yang dapat menangkap pesan saat pesan sampai ke data warehouse, membersihkan pesan itu, menerapkan data quality service (DQS) pada pesan itu, mengubah format pesan supaya sesuai dengan format data warehouse, dan kemudian memasukkan pesan ke dalam tabel fakta. Ada perbedaan waktu dua detik di sini, antara saat pelanggan membeli produk di situs web dan saat data ini tersedia dalam tabel fakta (Rainardi, 2008:p.27). Pendekatan lain untuk mengimplementasikan real-time data warehouse adalah memodifikasi sumber aplikasi operasional (OLTP) untuk melakukan penulisan ke area data staging dari data warehouse, segera setelah menulis data ke dalam database internal. Dalam staging database, kita dapat menempatkan pemicu yang akan dipanggil setiap kali ada data baru yang akan dimasukkan, dan pemicu ini secara otomatis akan memperbarui data warehouse (Rainardi, 2008:p.27). Pendekatan near real-time data warehouse dapat diimplementasikan dengan menggunakan mini-batch dengan frekuensi dua sampai lima menit. Pendekatan ini lebih memilih untuk menarik data dari area data staging dengan
45
frekuensi dua sampai lima menit dibandingkan menggunakan pemicu. Mini batch ini juga melakukan proses ETL yang standar yaitu pekerjaan-mengubah data dan memuatnya ke dalam basis data dimensional dari data warehouse. Mini-batch juga dapat menarik data secara langsung dari sistem sumber, menghilangkan kebutuhan memodifikasi sistem sumber untuk memperbarui area data staging (Rainardi, 2008:p.27). 2.16 Capture Transform Flow Capture, Transform, dan Flow (CTF) adalah tools untuk proses integrasi data yang relatif baru muncul, yang dirancang untuk menyederhanakan proses pemindahan data secara real time antar teknologi basis data yang berbeda-beda. Lapisan aplikasi dari aplikasi transaksional dihilangkan. Pertukaran langsung antar database-to-database akan dilakukan. Semua transaksi, baik perubahan pada tabel fakta dan tabel dimensi dapat dipindahkan secara langsung dari sistem operasional ke tabel data staging dari data warehouse dengan waktu tunggu yang sangat kecil, hanya beberapa detik (Kimball, 2004:p.444). CTF merupakan suatu pendekatan yang sangat baik untuk perusahaan yang membutuhkan near real time reporting dengan kebutuhan integrasi data yang tidak begitu besar serta (Kimball, 2004:p.445). Skema proses CTF dapat dilihat pada gambar 2.8.
46
Gambar 2.8 Proses Capture, Transform, dan Flow (Sumber : Kimball, 2004:p.445) 2.17 Change Data Capture Change data capture (CDC) mencatat aktifitas insert, update, delete yang dilakukan pada sebuah tabel. Hal ini membuat detail dari perubahan data yang terjadi akan tersedia dalam format relasional yang mudah untuk dipahami. Informasi kolom dan metadata yang diperlukan untuk menerapkan perubahan ini ke lingkungan target ditangkap untuk baris yang diubah dan disimpan dalam tabel perubahan yang mencerminkan struktur kolom pada tabel sumber yang akan dilacak. Fungsi table-valued disediakan untuk memungkinkan akses sistematis ke data yang dirubah oleh konsumen (Technet, 2014). Sebuah contoh yang baik dari konsumen data yang ditargetkan oleh teknologi ini adalah aplikasi extraction, transformation, dan loading (ETL). Sebuah aplikasi ETL secara bertahap mengirim perubahan data dari tabel sumber ke data warehouse atau data mart. Meskipun representasi dari tabel sumber dalam data warehouse harus mencerminkan perubahan dalam tabel sumber, sebuah teknologi
47
end-to-end yang memperbarui data pada replika dari sumber tidaklah tepat. Sebaliknya, kita perlu aliran perubahan data yang handal yang terstruktur sehingga konsumen dapat menerapkannya pada representasi sasaran yang berbeda dari data (Technet, 2014). Gambar 2.9 akan menunjukkan aliran data pada teknologi change data capture.
Gambar 2.9 Aliran Data pada Change Data Capture (Sumber : Technet, 2014)
Sumber perubahan data untuk change data capture adalah transaction log. Setelah proses insert, update, dan delete dilakukan pada tabel sumber yang akan dilacak, entri yang menggambarkan terjadinya perubahan data ini akan ditambahkan ke dalam log. Log ini akan menjadi input untuk proses capture.
48
Kemudian proses change data capture akan membaca log ini dan menyimpan informasi perubahan data pada log ini ke tabel perubahan. Isi dari tabel perubahan ini kemudian akan di-query oleh proses ETL sampai akhirnya perubahan data ini akan dikirim ke dalam data warehouse. Jadi hanya perubahan data terbaru saja yang akan disimpan ke dalam data warehouse (Technet, 2014). 2.18 MS SQL SERVER 2008 R2 SQL Server 2008 R2 adalah kumpulan dari komponen yang dapat kita terapkan secara terpisah atau sebagai sebuah kelompok untuk membentuk sebuah platform data yang scalable. Dalam arti luas, platform data ini terdiri dari dua jenis komponen yaitu : komponen yang akan membantu dalam mengelola data dan komponen-komponen yang akan membantu dalam mewujudkan suatu business intelligence (BI) (Mistry, 2010:p. xvii). Salah satu fitur baru pada SQL Server 2008 R2 adalah Parallel Data Warehouse. Parallel Data Warehouse ditujukan untuk sebuah enterprise data warehouse. Parallel Data Warehouse terdiri dari perangkat lunak dan perangkat keras yang dirancang untuk memenuhi kebutuhan gudang data yang sangat besar. Solusi ini memiliki kemampuan untuk menampung data warehouse sampai ratusan terabyte dengan penggunaan teknologi baru yang disebut sebagai massively parallel processing (MPP). Parallel data warehouse dapat dihubungkan melalui perangkat keras murah yang dikonfigurasi dalam arsitektur hub and spoke. Peningkatan kinerja dapat dicapai dengan pendekatan desain parallel data warehouse karena teknik ini melakukan partisi tabel besar ke beberapa node fisik, dimana setiap node memiliki CPU sendiri, memori, penyimpanan, dan SQL Server
49
instance. Desain ini secara langsung menghilangkan masalah yang terkait dengan kecepatan dan memberikan skalabilitas karena control node mendistribusikan data secara merata ke semua compute node. Control node juga bertanggung jawab untuk mengumpulkan data dari semua compute note ketika jawaban untuk sebuah query harus diberikan ke aplikasi (Mistry, 2010:p. 8-9). Keuntungan Penggunaan MS SQL Server 2008 R2 adalah sebagai berikut (Mistry, 2010:p. 10-11): a. Maximum scalability Windows Server 2008 R2 mendukung hingga 256 processor dan 2 terabyte memori dalam sebuah sistem operasi. b. Hyper-V improvements Hyper-V dapat menggunakan hingga 64 processor dalam host processor pool, yang memungkinkan untuk mengkonsolidasikan lebih banyak SQL Server VMs pada satu host Hyper-V. c. Windows Server 2008 R2 Server Manager Server Manager telah dioptimalkan pada Windows Server 2008 R2. d. Best Practices Analyzer (BPA) Membantu mengurangi kesalahan-kesalahan yang terjadi, yang pada akhirnya dapat membantu memperbaiki dan mencegah penurunan kinerja, skalabilitas, dan downtime. e. Windows PowerShell 2.0 Database Administration (DBA) dapat meningkatkan produktivitas mereka menggunakan
Windows
PowerShell
dengan
menyederhanakan,
50
mengotomatisasi, dan mengkonsolidasikan tugas-tugas yang berulang dan melakukan proses manajemen server di lingkungan SQL Server terdistribusi. 2.18.1 Tipe data pada MS SQL SERVER 2008 Pada SQL Server 2008 terdapat beberapa tipe data, diantaranya adalah: a. Tipe data untuk Bilangan Jenis-jenis dari tipe data bilangan ini dapat dilihat pada tabel 2.2. Tabel 2.2 Tipe Data Numerik Nama Tipe Kelas Ukuran / Keterangan Data Bytes Bit Integer 1 Bit tipe data pertama dalam tabel menggunakan 1 byte. Bigint Integer 8 Tipe data ini memungkinkan untuk menggunakan angka dari –263 sampai dengan 263–1. Int Integer 4 Tipe data ini meliputi angka dari –2,147,483,648 sampai dengan 2,147,483,647. SmallInt Integer 2 Tipe data ini meliputi angka –32,768 sampai dengan 32,767. TinyInt Integer 1 Tipe data ini meliputi angka 0 sampai dengan 255. Decimal or Decimal / Varies Memiliki presisi yang tetap dengan skala Numeric Numeric dari –1038–1 sampai dengan 1038–1. Money Money 8 Satuan moneter dari -263 sampai 263 ditambah presisi sampai empat tempat desimal. SmallMoney Money 4 Satuan moneter dari -214,748.3648 sampai dengan +214,748.3647. Float Approximate Varies Menerima argumen (misalnya, Float Numeric (20)) yang menentukan ukuran dan presisi. Perhatikan bahwa argumen dalam bit, bukan byte. Berkisar dari1.79E + 308 sampai dengan 1.79E + 308. (Sumber : Viera, 2009:p.12-15)
51
b. Tipe Data Special Numeric dan Karakter Jenis-jenis dari tipe data special numeric dan karakter ini dapat dilihat pada tabel 2.3. Tabel 2.3 Tipe Data Special Numeric dan Karakter Nama Tipe Kelas Ukuran Keterangan Data / Bytes Cursor Special 1 Pointer ke kursor. Numeric Timestamp / Special 8 Nilai khusus yang unik yang diberikan rowversion Numeric oleh basis data. (binary) UniqueIdentifier Special 16 Globally Unique Identifier (GUID). Numeric (binary) Char Character Varies Fixed-length data karakter. Data adalah non-Unicode. Panjang maksimal adalah 8.000 karakter. VarChar Character Varies Variabel-length data karakter. Data adalah non-Unicode. Panjang maksimal adalah 8.000 karakter. Dapat menggunakan kata kunci MAX. Text Character Varies Dukungan warisan dari SQL Server 2005 - gunakan varchar (max) sebagai gantinya! Nchar Unicode Varies Fixed-length data karakter. Data adalah Unicode. Panjang maksimal adalah 4.000 karakter. NVarChar Unicode Varies Variabel-length data karakter. Data adalah Unicode. Panjang maksimal adalah 4.000 karakter. Dapat menggunakan kata kunci MAX. Ntext Unicode Varies Ntext ini adalah warisan dari MS SQL Server 2005, gunakan nvarchar (max). Variable-length Unicode Data karakter. Binary Binary Varies Fixed-length data biner dengan Panjang maksimal 8.000 bytes. VarBinary Binary Varies Variabel-length data biner dengan panjang maksimal 8.000 byte. Image Binary Varies Dukungan warisan dari SQL Server 2005 - gunakan VarBinary(max) sebagai gantinya! (Sumber : Viera, 2009:p.12-15)
52
c. Tipe Data Tanggal dan Waktu Jenis-jenis dari tipe data tanggal dan waktu ini dapat dilihat pada tabel 2.4. Tabel 2.4 Tipe Data Tanggal dan Waktu Nama Tipe Kelas Ukuran Keterangan Data / Bytes DateTime Date / 8 Data tanggal dan waktu dari 1 Januari Time 1753, sampai dengan 31 Desember 9999, dengan akurasi tiga-seperseratus detik. DateTime2 Date / Varies Tipe Data DateTime yang diperbarui. Time (6-8) Mendukung rentang tanggal yang lebih besar dan presisi fraksi waktu besar (hingga 100 nanodetik). SmallDateTime Date / 4 Data tanggal dan waktu dari tanggal 1 Time Januari 1900, sampai dengan 6 Juni 2079, dengan akurasi satu menit. DateTimeOffsett Date / Varies Serupa dengan tipe data DateTime tipe, Time (8-10) tetapi juga mengharapkan offset -14:00 sampai dengan +14:00 dari waktu UTC. Waktu disimpan secara internal sebagai waktu UTC, dan setiap perbandingan, pengurutan, dan pengindeksan akan didasarkan pada zona waktu bersatu. Date Date / 3 Menyimpan hanya tanggal data dari Time tanggal 1 Januari 0001, sampai dengan 31 Desember 9999 seperti yang didefinisikan oleh kalender Gregorian. Menggunakan format tanggal standar ANSI (YYYY-MM-DD), tapi akan secara implisit mengkonversi dari beberapa format lain. Time Date / Varies Menyimpan hanya data waktu yang Time (3-5) secara presisi dipilih oleh user sebagai granular 100 nanodetik (yang merupakan default). (Sumber : Viera, 2009:p.12-15)
53
d. Tipe Data Lain Jenis-jenis tipe data ini dapat dilihat pada tabel 2.5. Tabel 2.5 Tipe Data Lain Nama Tipe Kelas Ukuran Keterangan Data / Bytes Table Other Special Tipe data ini biasanya digunakan pada waktu bekerja dengan result sets. Tipe data biasanya dipakai pada User-defined Function atau sebagai parameter untuk Stored Procedures. Tipe data ini tidak dapat digunakan sebagai tipe data dalam tabel definition (Anda tidak bisa membuat tabel bersarang (tabel dalam tabel)). HierarchyID Other Special Tipe data khusus yang menangani informasi posisi hirarki. Menyediakan fungsi khusus untuk kebutuhan hirarki. Perbandingan kedalaman, orangtua / anak, hubungan, dan pengindeksan diperbolehkan. Ukuran yang tepat bervariasi dengan jumlah dan rata-rata kedalaman node dalam hirarki. sql_variant Other Special Tipe data ini terkait dengan tipe data Variant yang terdapat pada VB dan C + +. Pada dasarnya, tipe data ini adalah wadah yang memungkinkan kita untuk memegang sebagian besar tipe data SQL Server lainnya di dalamnya. Kita dapat menggunakan tipe data ini ketika satu kolom atau fungsi harus mampu menangani beberapa tipe data. Tidak seperti pada VB, dengan menggunakan tipe data ini kita dapat memaksa untuk melakukan casting data pada tipe data ini secara eksplisit untuk mengubahnya menjadi tipe data yang lebih spesifik. XML Character Varies Mendefinisikan field karakter untuk XML data. Menyediakan validasi data untuk XML Schema seperti penggunaan fungsi-XML berorientasi khusus. Table Other Special Tipe data ini biasanya digunakan pada waktu bekerja dengan result sets. Tipe data biasanya dipakai pada User-defined Function atau sebagai parameter untuk Stored Procedures. Tipe data ini tidak dapat digunakan sebagai tipe data dalam tabel definition (Anda tidak bisa membuat tabel bersarang (tabel dalam tabel)). (Sumber : Viera, 2009:p.12-15)
54
2.18.2 Basic query pada MS SQL SERVER 2008 Ada 4 operasi dasar yang dapat dilakukan pada suatu basis data, yaitu: select, insert, update, dan delete. Pada SQL Server 2008, sintak untuk penggunaan dari empat operasi basis data ini dapat dilihat pada tabel 2.6: Tabel 2.6 Sintaks Query pada SQL Server 2008 Fungsi Sintak
Nama Query SELECT
Membaca data
INSERT
Menyisipkan data
UPDATE
Memperbarui data
DELETE
Menghapus data
(Sumber : Viera, 2009:p.841-852)
SELECT [FROM <source table(s)> [[AS]
] [[{FULL|INNER|{LEFT|RIGHT} OUTER|CROSS}] JOIN [ON <join condition>] [ ...]]] [WHERE ] [GROUP BY ] [HAVING ] [ORDER BY ] [[FOR XML {RAW|AUTO|EXPLICIT|PATH [(<element>)]}[, XMLDATA][, ELEMENTS][, BINARY base 64]] [OPTION (, [, ...n])] [{ UNION [ALL] | EXCEPT | INTERSECT }] [;] INSERT [INTO]
2.19 Service Oriented Architecture SOA adalah sebuah metode membangun aplikasi yang menggunakan sejumlah kecil, komponen independen yang berkomunikasi satu sama lain dengan saling menawarkan dan menggunakan layanan antar komponen-komponen independen
ini.
Komponen-komponen
ini
dapat
didistribusikan;
pada
kenyataannya, mereka dapat berada di sisi yang berbeda dari dunia (Rainardi, 2008:p.26). Hampir setiap aplikasi besar bisa mendapatkan keuntungan dari pendekatan SOA. Kita tidak perlu untuk membangun satu aplikasi besar lagi. Sebaliknya, kita membangun banyak potongan-potongan kecil aplikasi yang terhubung dan berkomunikasi satu sama lain. Salah satu sifat dari industri TI adalah aplikasi akan perlu diganti setiap beberapa tahun (setiap 4-8 tahun). Bisa jadi karena teknologi yang digunakan sudah usang atau karena fungsionalitas dari aplikasi tersebut sudah tidak mampu mengakomodasi kebutuhan perusahaan. Kepailitan, merger, dan pengambilalihan perusahaan juga merupakan alasan lain untuk melakukan penggantian aplikasi ini (Rainardi, 2008:p.26). Jika kita membuat satu aplikasi raksasa, itu akan menjadi mahal untuk menggantinya. Jika kita membuatnya dari sejumlah kecil, komponen independen, lebih mudah untuk menggantinya. SOA memberi kita lebih banyak fleksibilitas untuk mengganti komponen. Dengan kata lain, kita dapat melakukannya secara bertahap sepotong demi sepotong tanpa mempengaruhi fungsi tersebut. Hal ini karena komponen yang independen; yaitu, mereka tidak peduli bagaimana komponen lainnya bekerja secara internal selama eksternal mereka mendapatkan
56
tanggapan yang mereka butuhkan. Hal ini memungkinkan kita untuk membangun kembali salah satu komponen dengan teknologi yang lebih baru tanpa mempengaruhi yang lain (Rainardi, 2008:p.26). Bagaimana SOA ini berhubungan dengan data warehouse? Sebuah sistem data warehouse terdiri dari banyak komponen: sistem sumber, sistem ETL, mekanisme kualitas data, sistem metadata, audit dan sistem kontrol, sebuah portal BI, aplikasi pelaporan, aplikasi OLAP/analitik, aplikasi data mining, dan sistem database itu sendiri (Rainardi, 2008:p.26). Kita dapat membangun data warehouse sebagai satu aplikasi raksasa dengan semua komponen digabungkan; Hal ini akan menyebabkan kita tidak akan dapat mengganti salah satu komponen tanpa mempengaruhi komponen lainnya. Atau kita dapat membangun data warehouse dengan pendekatan SOA. Kita membangunnya sebagai jumlah yang lebih kecil, komponen independen yang terhubung dan berkomunikasi satu sama lain dengan saling menawarkan dan menggunakan layanan antar komponen-komponen independen ini (Rainardi, 2008:p.26). Semakin banyak aplikasi data warehousing di semua lini yang dibangun menggunakan SOA, seperti misalnya : ETL, pelaporan, analisis, aplikasi BI, data mining, metadata, kualitas data, dan pembersihan data. Di masa depan, dengan menggunakan pendekatan SOA, akan lebih mudah untuk memperbarui salah satu komponen tanpa mempengaruhi komponen yang lain dan untuk menghubungkan berbagai komponen yang dibuat dengan menggunakan teknologi yang berbedabeda (Rainardi, 2008:p.26).
57
SOA adalah pendekatan yang berbeda untuk memisahkan antara perhatian dan pembangunan solusi bisnis dengan memanfaatkan komponen-komponen kecil yang digabungkan dan digunakan kembali. Dengan mengadopsi SOA, organisasi dapat mengaktifkan aplikasi bisnis mereka dengan cepat dan efisien menanggapi bisnis, proses, dan perubahan integrasi yang biasanya terjadi dalam lingkungan perusahaan (Kankanamge, 2012:p. 8). 2.19.1 Arsitektur SOA
Gambar 2.10 Arsitektur SOA (Sumber : Barry, 2013:p.18)
Pada gambar 2.10 dapat dilihat bahwa arsitektur SOA yang paling sederhana adalah dimana ada sebuah service provider dan sebuah service consumer. Service consumer akan mengirimkan service request ke service provider dan kemudian service provider akan mengirimkan service response ke service consumer. 2.19.2 Building block SOA Ketika mempelajari solusi standar berorientasi pada layanan, kita dapat mengindentifikasi tiga building block besar seperti berikut ini (Kankanamge, 2012:p. 9-11):
58
a. Web Services Web service adalah unit individu dari logika bisnis dalam SOA. Web service berkomunikasi satu sama lain dan berkomunikasi dengan program atau aplikasi lain dengan mengirimkan pesan. Web service terdiri dari definisi antarmuka publik yang merupakan bagian pusat dari informasi yang menyediakan layanan dan memungkinkan layanan tersebut untuk dikonsumsi oleh end user. Skema web service standar dapat dilihat pada gambar 2.10.
Gambar 2.11 Basic Web Service (Sumber : Kankanamge, 2012:p.10)
Service container adalah komponen SOA middleware dimana web service diletakkan (hosted) untuk aplikasi consumer sehingga aplikasi consumer dapat berinteraksi dengan web service. b. Mediation Biasanya, transmisi pesan antara node dalam solusi berorientasi layanan tidak hanya terjadi melalui saluran point-to-point. Sebaliknya, sekali pesan diterima, maka pesan akan dialirkan melalui beberapa perantara dan akan dilakukan berbagai transformasi dan konversi yang diperlukan. Perilaku ini umumnya disebut sebagai message mediation. Hal ini merupakan salah satu blok bangunan penting dalam solusi berorientasi layanan.
59
c. Composition Dalam solusi berorientasi layanan, kita tidak bisa mengharapkan layanan web individu berjalan sendiri untuk menyediakan fungsionalitas bisnis yang diinginkan. Sebaliknya, beberapa layanan web bekerja sama dan berpartisipasi dalam berbagai komposisi layanan. Biasanya, web service ditarik bersama-sama secara dinamis pada runtime berdasarkan aturan yang ditetapkan dalam definisi proses bisnis. Proses manajemen atau koordinasi dari proses bisnis ini diatur oleh koordinator proses, yang merupakan komponen middleware SOA yang terkait dengan komposisi layanan web. 2.19.3 SOAP Simple Object Access Protocol (SOAP) dapat dianggap sebagai standar messaging pertama yang digunakan untuk layanan web. Hal ini didefinisikan oleh World Wide Web Consortium (W3C) at http://www.w3.org/TR/2000/NOTESOAP-20000508/ sebagai berikut: SOAP adalah protokol ringan untuk pertukaran informasi dalam lingkungan desentralisasi, lingkungan terdistribusi. SOAP adalah sebuah protokol berbasis XML yang terdiri dari tiga bagian: sebuah amplop yang mendefinisikan kerangka kerja untuk menggambarkan apa yang ada dalam pesan dan bagaimana memprosesnya, seperangkat aturan pengkodean untuk mengungkapkan contoh dari tipe data yang didefinisikan oleh aplikasi, dan konvensi untuk mewakili prosedur panggilan jarak jauh dan tanggapan-tanggapannya.
60
Stuktur dari pesan SOAP dapat dilihat pada gambar 2.11 berikut ini:
Gambar 2.12 Struktur SOAP (Sumber : Kankanamge, 2012:p. 11)
Sebuah pesan SOAP adalah sebuah dokumen XML yang terdiri dari amplop SOAP yang wajib ada, header SOAP yang bersifat opsional, dan body SOAP yang wajib ada. Amplop SOAP adalah elemen pembungkus yang memegang semua node anak yang terdapat dalam suatu pesan SOAP. Elemen header SOAP adalah sebuah blok opsional di mana informasi meta disimpan. Menggunakan header, pesan SOAP mampu mengandung berbagai jenis informasi tambahan yang berkaitan dengan pengiriman dan pengolahan pesan. Ini secara tidak langsung memberikan keleluasaan untuk layanan web seperti dengan mempertahankan header SOAP, layanan tidak perlu untuk menyimpan logika pesan khusus. Biasanya, header SOAP berisi: a. Message processing instructions b. Security policy metadata
61
c. Addressing information d. Message correlation data e. Reliable messaging metadata Body SOAP adalah elemen di mana isi pesan yang sebenarnya diletakkan. Isi body SOAP ini biasanya disebut sebagai message payload.
