7
BAB 2 LANDASAN TEORI
2.1 Data dan Informasi M enurut Laudon (2006, p13), data adalah kumpulan fakta yang masih mentah yang menjelaskan aktivitas-aktivitas yang terjadi dalam organisasi atau lingkungan fisik, sebelum terorganisir dan diubah menjadi bentuk yang dimengerti dan dapat digunakan. M enurut Inmon (2005, p493) data adalah rekaman dari fakta, konsep, atau instruksi di dalam media penyimpanan untuk komunikasi, perolehan, dan pemrosesan oleh cara otomatis dan presentasi sebagai informasi yang dapat dimengerti oleh manusia. Informasi adalah data yang dapat dimengerti dan dievaluasi oleh manusia untuk memecahkan masalah atau membuat keputusan. Sehingga dapat disimpulkan, data adalah fakta-fakta yang memuat kejadian, tempat dan subyek yang terjadi, dan informasi adalah data yang telah diolah dan menjadi berguna bagi perusahaan.
8
2.2 Pengertian Database M enurut Connolly (2005, p14), database adalah suatu kumpulan dari data yang terhubung secara logis, dan deskripsi dari data ini, dirancang untuk memenuhi kebutuhan informasi dari sebuah organisasi. Database bersifat tunggal, memiliki tempat penyimpanan data yang besar di mana dapat digunakan secara bersama-sama oleh banyak departemen dan user. M enurut Inmon (2002, p388), “a database is a collection of interrelated data stored (often with controlled, limited redundancy) according to a schema” yang dapat diartikan bahwa database adalah sekumpulan penyimpanan data yang berhubungan (sering dengan pengontrolan, redudansi yang terbatas) yang berdasarkan suatu skema. Berdasarkan definisi diatas, dapat disimpulkan bahwa database merupakan suatu kumpulan data yang saling berhubungan dan terintegrasi, yang dirancang untuk kebutuhan informasi perusahaan.
2.3 Pengertian Entity Relationship Modeling M enurut Connoly dan Begg (2005, p342), salah satu aspek yang sulit dalam perancangan database adalah kenyataan bahwa perancang, programmer dan pemakai akhir cenderung melihat data dengan cara yang berbeda. Untuk memastikan pemahaman secara alamiah dari data dan bagaimana data digunakan oleh perusahaan dibutuhkan sebuah bentuk komunikasi non-teknis dan bebas dari
9
kebingungan. Berikut ini adalah notasi Entity Relationship Modeling menurut Connoly dan Begg : Ent ity Name
A
B Relate to >
Relationshi p Name Gambar 2.1 Notasi Entity – Relationship Modeling
2.3.1 Entity Type M enurut Connoly dan Begg (2005, p343), Entity type adalah kumpulan objek-objek yang berproperti sama, dimana properti tersebut diidentifikasikan memiliki keberadaan yang bebas. 2.3.2 Attribute M enurut Connoly dan Begg (2005, p350-352), atribut adalah sifat dari sebuah entity atau sebuah tipe relationship. Atribut menyimpan nilai dari setiap entity occurrence dan mewakili bagian utama dari data yang disimpan dalam basis data.
10
Atribut domain adalah sejumlah nilai yang diperkenankan untuk satu atau lebih atribut. Setiap atribut yang dihubungkan dengan sejumlah nilai disebut domain. Domain mendefinisikan nilai-nilai yang dimiliki sebuah atribut yang sama dengan konsep domain pada model relational. Simple attribute adalah atribut yang terdiri dari satu komponen tunggal dengan keberadaan yang bebas. Simple attribute tidak bisa dibagi lagi kedalam komponen yang lebih kecil. Single value attribute adalah atribut yang hanya menyimpan nilai tunggal untuk suatu sifat dari entity. Multi value entity adalah atribut yang bisa menyimpan nilai lebih dari satu untuk suatu sifat entity. Derived attribute adalah atribut yang menunjukkan nilai yang diperoleh dari atribut yang berhubungan, tidak terlalu dibutuhkan dalam tipe entity yang sama. 2.3.3 Relationship Type M enurut Connoly dan Begg
(2005, p346), relationship type
adalah sekumpulan hubungan antara satu atau lebih tipe-tipe entity. M enurut Connoly dan Begg
(2005, p347), derajat dari
relationship adalah jumlah dari partisipasi tipe entity dalam sebuah tipe relationship tertentu. Sebuah relationship berderajat dua disebut binary, berderajat tiga disebut ternary dan berderajat empat disebut quarternary.
11
2.3.4 Kunci M enurut Connoly dan Begg (2005, p78), kunci relasi sangat dibutuhkan untuk mengidentifikasi satu atau lebih atribut yang memiliki nilai unik untuk setiap tuple dalam relasi. M acam-macam kunci relasi : a. Composite key adalah kunci yang disusun berdasarkan lebih dari satu atribut. b. Candidate key adalah suatu atribut atau set minimal atribut yang mengidentifikasikan secara unik suatu kejadian spesifik dari entity. c. Primary key adalah satu atribut atau set minimal atribut yang tidak hanya mengidentifikasikan secara unik suatu kejadian spesifik, tapi juga dapat mewakili setiap kejadian dari suatu entity. d. Alternative key adalah kunci kandidat yang tidak terpakai sebagai kunci primer. e. Foreign key adalah satu atribut yang melengkapi satu hubungan (relationship) yang menunjuk ke induknya.
12
2.4 Pengertian OLTP (On-Line Transaction Processing) M enurut Inmon (2005, p500) OLTP adalah lingkungan permrosesan transaksi performance tingkat tinggi. OLTP (On-Line Transaction Processing) menggambarkan kebutuhan sistem dalam ruang lingkup operasional dan merupakan proses yang mendukung operasi bisnis sehari-hari. OLTP dirancang untuk memungkinkan terjadinya pengaksesan secara bersamaan oleh beberapa user terhadap sumber data yang sama dan mengatur proses yang diperlukan. Sesuai dengan namanya, OLTP mengizinkan transaksi untuk mengakses langsung ke database. Transaksi yang dilakukan termasuk operasi insert, update, dan delete. Database OLTP biasanya bersifat relasional dan dalam bentuk normal ketiga, serta yang terpenting, database OLTP dibangun untuk mampu menangani banyak transaksi dengan performa tinggi. Jadi dapat disimpulkan, bahwa OLTP memungkinkan banyak user untuk mengakses secara bersamaan terhadap sumber database yang sama, dimana database-nya bersifat relasional dan sudah ternormalisasi.
2.5 Pengertian Data warehouse M enurut Connnolly (2005, p1151) , data warehouse adalah koleksi data yang mempunyai sifat berorientasi pada subjek, terintegrasi, memiliki rentang waktu, dan koleksi datanya tidak mengalami perubahan dalam mendukung proses pengambilan keputusan ditingkatan manajerial.
13
M enurut Inmon (2002, p495), data warehouse adalah koleksi data yang berorientasi subjek (subject oriented), terintegrasi (integrated) memiliki rentang waktu (time variant), dan tidak mengalamai perubahan (non volatile) untuk mendukung proses pembuatan keputusan manajemen. M enurut M cLeod (2004, p406), data warehouse adalah sebuah sistem penyimpanan data yang berkapasitas besar, dimana data dikumpulkan dengan menambahkan record baru daripada meng-update record yang sudah ada dengan informasi baru. Data jenis ini digunakan hanya untuk proses pengambilan keputusan dan bukan untuk kegiatan operasional perusahaan sehari-hari. Berdasarkan pengertian-pengertian diatas, dapat disimpulkan bahwa data warehouse adalah kumpulan-kumpulan data yang dapat mendukung proses pengambilan keputusan dalam suatu perusahaan.
2.6 Karakteristik Data warehouse M enurut
Inmon
(Connolly,
2005,
p1151),
data
warehouse
memiliki
karakteristik: •
Subject-oriented Data warehouse diorganisasikan pada subjek-subjek
utama dari
perusahaan (seperti pelanggan, produk, dan penjualan), bukan pada areaarea aplikasi utama (seperti faktur pelanggan, kontrol stok, dan penjualan
14
produk). Hal ini tercermin dalam kebutuhan untuk menyimpan data pendukung keputusan daripada data berorientasi aplikasi. •
Integrated Sumber data berasal dari sistem-sistem aplikasi perusahaan yang berbeda-beda. Sumber data sering tidak konsisten misalnya perbedaan format data. Integrasi sumber data harus dibuat konsisten dalam menampilkan data agar dapat menyatukan pandangan user terhadap data.
•
Time variant Data dalam data warehouse hanya akurat dan valid pada suatu rentang waktu tertentu. Tabel 2.1 Perbandingan waktu data operasional dengan Data warehouse
Data Operasional Berisi current data value.
Data Warehouse Berisi snapshot data sesuai waktu tertentu.
Horizon waktu dalam range 60-90 Horizon waktu dalam range 5-10 tahun. hari Element waktu adalah optional Element waktu memiliki key. sebagai key . Data dapat dirubah.
Sekali snapshot dibuat, record tidak dapat dirubah.
15
•
Non-volatile Salah satu karakteristik data warehouse adalah nonvolatile. Dalam data warehouse hanya ada 2 operasi data yaitu “load data” dan “acces data” atau dengan kata lain hanya ada perintah insert dan select. Sehingga konsekuensi logis bahwa pada desain fisikal dapat dilakukan optimisasi akses terhadap data serta tidak terdapatnya redundancy data karena terlebih dahulu sudah dilakukan penyaringan atau seleksi data, Data warehouse hanya berisi “summary data”, data yang masuk sudah mengalami transformasi serta terjadinya horizon waktu
Tabel 2.2 Perbandingan Sistem OLTP dengan Data warehouse
Sistem OLTP
Sistem Data warehouse
Current Value Data
Historical Data
Berorientasi Aplikasi
Berorientasi Subjek
Data bersifat dinamis
Data bersifat statis
Transaction Driven
Analysis driven
Non-reduncancy (normalisasi)
Redundancy (denormalisasi)
M enyimpan detail data
M enyimpan detail, lightly dan highly summarized data
M elayani banyak user (operational)
M elayani sedikit user (managerial)
16
M endukung keputusan harian
M endukung keputusan strategis
Sumber : (Connoly, 2005, p1153)
2.7 Struktur Data warehouse M enurut Inmon (2005, p33), struktur data warehouse terdiri dari older level of detail, current level of detail, lightly summarized data, dan highly summarized data. Data yang mengalir ke dalam data warehouse berasal dari lingkungan operasional. Biasanya transformasi data yang penting terjadi pada perjalanan dari level operasional ke level data warehouse. Seiring berjalannya waktu, data dari current detail dapat berubah menjadi older detail. Karena data diringkas, data mengalami perubahan dari current detail ke lightly summarized data, kemudian dari lightly summarized data menjadi highly summarized data. Struktur data warehouse terdiri dari: •
Current Detail Data Data yang aktif saat ini merupakan level terendah dari data warehouse, dan biasanya memerlukan tempat penyimpanan (storage) yang besar. Beberapa alasan mengapa current detail data menjadi perhatian utama : -
M enggambarkan kejadian yang baru terjadi dan selalu menjadi perhatian utama.
17
-
Sangat besar jumlahnya dan disimpan pada tingkatan penyimpanan terendah.
-
Hampir selalu disimpan di media penyimpanan karena cepat diakses tetapi mahal dan kompleks diatur.
-
Biasa digunakan dalam membuat rekapitulasi data sehingga current detail data harus akurat.
•
Older Detail Data M erupakan data historis yang bisa berupa hasil backup yang disimpan dalam media penyimpanan yang terpisah dan dapat diakses kembali pada saat tertentu. Penyusunan direktori untuk older detail data harus berdasarkan umur data sehinga dapat memudahkan dalam mengakses.
•
Lightly Summarized Data M erupakan ringkasan dari current detail data, belum bersifat total summary. Data-data ini memiliki tingkatan detail yang lebih tinggi dan mendukung kebutuhan data warehouse pada tingkat departemen. Akses terhadap data jenis ini biasanya digunakan untuk memantau kondisi yang sedang dan sudah berjalan.
•
Highly Summarized Data M erupakan data yang bersifat total summary. Digunakan untuk melakukan analisa perbandingan data berdasarkan urutan waktu dan analisis yang menggunakan database multidimensi.
18
Highly summarize Light ly summarize d(Data M e t a d a t a
Current det ail
Operational transformat io
Old detail
Gambar 2.2 Struktur Data Warehouse (Johan Setiawan,”Teori Data Warehouse”)
2.8 Metadata Metadata merupakan data tentang data, gambaran tentang struktur, isi, kunci, indeks dari data. Metadata bukan merupakan data hasil dari kegiatan operasional seperti current detail data, older detail data, lightly summarized data, dan highly summarized data. Metadata memuat informasi penting dalam data warehouse.
19
Metadata digunakan dalam banyak fungsi antara lain : •
Sebagai direktori yang dipakai oleh user dalam mencari lokasi data dalam data warehouse.
•
Sebagai panduan pemetaan dalam proses transformasi dari data operasional ke dalam lingkungan data warehouse.
•
Sebagai panduan untuk proses detail data menjadi summary data untuk diolah menjadi lightly summarized data dan kemudian menjadi highly summarized data. Metadata merupakan suatu bentuk jaringan yang sangat penting bagi
pengguna data warehouse. Data yang tersedia haruslah dapat digunakan oleh pemakai dengan menggunakan istilah yang sesuai dengan cara pemakai dalam melakukan pekerjaannya. Karena data warehouse harus melayani banyak fungsi, metadata penting memahami data yang sama dengan nama yang berbeda pula. Metadata dibuat untuk menjawab kebutuhan dari suatu fungsi tertentu karena tiap departemen biasanya menggunakan struktur data yang spesifik meskipun asal datanya sama.
2.9 Arsitektur Data Warehouse Arsitektur Data Warehouse adalah sekumpulan aturan dari suatu struktur yang memberikan kerangka suatu perancangan sistem. Arsitektur data
20
untuk data warehouse mempunyai komponen utama yaitu database yang dapat dibaca.
Gambar 2.3 Arsitektur Data Warehouse
2.10 Bentuk Data warehouse Didalam memutuskan bentuk mana yang akan kita gunakan dalam suatu perusahaan, terlebih dahulu kita harus mengetahui kebutuhan yang kita perlukan didalam menjalankan aplikasi yang ingin kita rancang. Bentuk umum yang sering digunakan dalam data warehouse adalah dibagi atas 3 bentuk yakni: 1. Functional Data warehouse Data warehouse fungsional diperoleh dari hasil kegiatan operasional sehari-hari, data warehouse dibuat lebih dari satu dan dikelompokkan berdasarkan masing-masing fungsi yang ada didalam
21
perusahaan seperti fungsi keuangan atau financial, fungsi marketing, fungsi kinerja personalia, dan lain-lainnya. Keuntungan dari bentuk ini adalah sistem mudah dibangun dengan biaya yang relatif murah sedangkan kerugiannya adalah resiko kehilangan konsistensi data dan terbatasnya kemampuan dalam pengumpulan data bagi pengguna.
Gambar 2.4 Functional Data Warehouse (Johan Setiawan,”Teori Data Warehouse”)
2. Centralized Data warehouse Centralized Data
warehouse mempunyai bentuk seperti
functional data warehouse, namun disini sumber data terlebih dahulu dikumpulkan atau diintegrasikan pada suatu tempat terpusat, kemudian
22
barulah data tersebut dibagi-bagi berdasarkan fungsi-fungsi yang dibutuhkan oleh perusahaan, dan bentuk ini sering digunakan oleh perusahaan-perusahaan yang belum memiliki jaringan eksternal. Keuntungan dari bentuk ini adalah data benar-benar terpadu karena konsistensinya yang tinggi sedangkan kerugiannya adalah biaya yang mahal serta perlu waktu yang cukup lama dalam membangun bentuk ini.
Gambar 2.5 Centralized Data warehouse (Johan Setiawan,”Teori Data Warehouse”)
3. Distributed Data warehouse Distributed Data warehouse menggunakan Gateway yang berguna sebagai jembatan antara lokasi data warehouse dengan workstation yang menggunakan sistem yang beraneka ragam atau berbeda, sehingga pada bentuk ini memungkinkan kita untuk
23
mengakses sumber data yang berada diluar lokasi perusahaan (eksternal). Data warehouse ini memungkinkan tiap departemen dalam perusahaan membangun sistem operasionalnya sendiri, serta dapat membangun pengumpulan data fungsionalnya masing-masing dan menggabungkan bagian-bagian tersebut dengan teknologi client-server. Keuntungan dari bentuk ini adalah kelebihan dalam mengakses data dari luar perusahaan yang telah mengalami sinkronisasi terlebih dahulu dan tetap terjaga konsistensinya, namun kerugian dari bentuk ini adalah bentuk yang paling mahal dan kompleks untuk diterapkan, karena sistem operasinya dikelola secara terpisah.
Gambar 2.6 Distributed Data warehouse (Johan Setiawan,”Teori Data Warehouse”)
24
2.11. Perancangan Data warehouse M enurut metodologi Kimball (Connolly, 2005, p1187), terdapat Sembilan tahapan dalam membangun data warehouse (nine step methodology), yaitu: 1. Pemilihan proses (choosing the process) Proses yang mengacu pada subyek yang dibutuhkan oleh data mart. Pada tahap ini, ditentukan proses bisnis apa yang akan digunakan data warehouse. 2. Pemilihan grain (choosing the grain) Tahap yang menentukan apa yang dipresentasikan oleh record tabel fakta. Pada tahap ini, akan ditentukan tingkat detail data. 3. Identifikasi dan penyesuaian dimensi (identifying and conforming the dimension) M embuat dimensi yang dibutuhkan untuk menjelaskan seluruh isi yang terdapat pada tabel fakta. Sekumpulan dimensi yang terbangun dengan baik membuat data mart menjadi mudah dimengerti dan mudah digunakan. Tabel dimensi juga memuat hubungan dari measurement. 4. Pemilihan fakta (choosing the fact) Tahap pemilihan fakta yang dimaksudkan sebagai sebuah proses yang menentukan tabel fakta yang dapat mengimplikasikan semua grain yang
25
digunakan pada data mart. Keseluruhan fakta harus diekspresikan pada level yang dinyatakan oleh grain. Pada tahap ini juga diidentifikasi measurement yang diperlukan. 5. Penyimpanan pre-calculation di tabel fakta (storing pre-calculation in the fact table) Setelah tabel fakta terpilih, setiap tabel fakta tersebut harus diperiksa ulang untuk menentukan apakah ada fakta-fakta yang dapat diterapkan precalculation dan dilakukan penyimpanan pada tabel fakta. 6. M emastikan tabel dimensi (Roundingn out the dimension table) Pada tahap ini dilakukan pemeriksaan ulang pada tabel dimensi dan menambah sebanyak mungkin deskripsi teks dalam dimensi, serta menentukan hierarki atribut dimensi untuk mempermudah proses analisis. Gambaran teks haruslah mudah digunakan dan dimengerti user. 7. Pemilihan durasi database (choosing the duration of the database) M engukur waktu periode database untuk beberapa tahun kebelakang. Pada beberapa perusahaan ada kebutuhan untuk melihat data pada waktu yang sama, atau data setahun, atau dua tahun sebelumnya. 8. M elacak perubahan dari dimensi secara perlahan (tracking slowly changing dimension)
26
Dimensi dapat berubah secara perlahan seiring berjalannya waktu dan kebutuhan. Perubahan dalam dimensi yang dimaksud terjadinya perubahan data (update) dari dimensi. Untuk memantau perubahan tersebut, digunakan tipe-tipe slowly changing dimension (SCD), yaitu: •
Tipe 1 : M enulis ulang dimensi yang berubah
•
Tipe 2 : M enambah baris baru pada tabel dimensi dengan surrogate key yang baru, tetapi masih menggunakan id yang sama.
•
Tipe 3 : Adanya penambahan atribut alternative yang baru sehingga penggunaan record yang lama dan baru bisa digunakan secara bersamaan pada satu record dimensi yang sama.
9. Penentuan prioritas dan model query (deciding the query priorities and the query modes) Pada tahap ini, kita menentukan masalah desain fisik dari data warehouse yaitu dengan menentukan urutan fisik dari tabel fakta pada media penyimpanan dan adanya penggunaan agregasi. Selain itu pada tahap ini dilakukan pertimbangan terhadap masalah indexing, backup, dan security. Isu rancangan fisik yang paling kritis yang mempengaruhi persepsi end-user data mart.
27
2.12 Perancangan Data Warehouse dengan Skema Bintang M enurut Connoly (2005, p1183), skema bintang adalah sebuah struktur logika yang mempunyai sebuat tabel fakta yang berisi data fakta di tengah dan dikelilingi oleh tabel-tabel dimensi yang berisi data referensi atau keterangan yang biasanya dapat didenormalisasi. M enurut Poe (1996, p33) metode yang digunakan untuk merancang data warehouse adalah dengan menggunakan perancangan
yang dilakukan
dengan
skema bintang, yaitu metode
struktur yang sederhana dengan
menggunakan beberapa tabel atau jalur yang terhubung dengan baik dan jelas. Dengan menggunakan skema bintang ini akan menghasilkan waktu respon yang lebih cepat dalam query data dibandingkan dengan proses transaksional dengan menggunakan normalisasi. Selain itu skema bintang memudahkan end user untuk memahami struktur database pada data warehouse yang dirancang. Keuntungan dari penggunaan skema bintang: 1.
Respon data lebih cepat daripada perancangan database operasional.
2.
M empermudah dalam hal modifikasi atau pengembangan data warehouse yang terus menerus.
3.
End-user dapat menyesuaikan cara berfikir dan menggunakan data.
4.
M enyederhanakan pemahaman dan penelusuran metadata bagi pemakai dan pengembang.
28
Tabel dalam S kema Bintang Dalam skema bintang terdapat 2 tipe tabel yaitu tabel fakta dan tabel dimensi. Tabel fakta disebut juga tabel mayor terdiri dari data kuantitatif atau data fakta mengenai bisnis, informasi yang diquery. Informasi ini sering diukur secara numerik dan dapat mengandung banyak kolom dan baris. Tabel dimensi disebut juga tabel minor karena lebih kecil dan mencerminkan dimensi bisnis. Jenis Skema Bintang Dengan penggunaanya terdapat 2 jenis skema bintang yang tergantung dengan kebutuhan, yaitu Skema Bintang Sederhana dan Skema Bintang M ajemuk yang akan terinci lebih lanjut berikut ini: Skema Bintang Sederhana Dalam
skema
bintang
sederhana,
setiap
tabel
mempunyai primary key yang terdiri dari sebuah kolom atau lebih. Primary key akan membuat setiap baris menjadi unik. Primary key tersebut pada tabel fakta akan menjadi foreign key. Primary key pada tabel fakta, terdiri dari satu atau lebih foreign key.
29
Gambar 2.7 Skema Bintang Sederhana (Johan Setiawan,”Teori Data Warehouse”)
Pada gambar menunjukan hubungan antara
satu tabel
fakta dan tiga tabel dimensi. Tabel utama terdapat primary key yang terdiri dari tiga foreign key, yaitu kunci-1, kunci-2 dan kunci-3, yang masing– masing merupakan primary key di tabel masing-masing. Dalam sebuah skema bintang, dapat juga memiliki lebih dari satu tabel fakta, karena adanya fakta yang tidak saling berhubungan. Tabel semacam ini umumnya digunakan untuk jumlah data yang besar dan untuk berbagai macam tabel data yang teragregasi
30
Gambar 2.8 Skema Bintang Dengan Beberapa Tabel Fakta (Johan Setiawan,”Teori Data Warehouse”)
Pada gambar diatas terdapat dua tabel fakta dan tiga tabel dimensi yang memperlihatkan hubungan many to one antara foreign key pada kedua tabel fakta tersebut dengan primary key pada masing masing tabel dimensi. Tabel dimensi mungkin juga mengandung foreign key yang mereferensikan primary key di tabel dimensi yang lain. Tabel dimensi yang direferensikan secondary dimension tabel.
ini dinamakan outboard
atau
31
Gambar 2.9 Skema Bintang Dengan Tabel Dimensi Tambahan (Johan Setiawan,”Teori Data Warehouse”)
2.13 ETL (Extract, Tran sform dan Loading) ETL merupakan proses-proses dalam data warehouse yang meliputi : 1. mengekstrak data dari sumber-sumber eksternal 2. mentransformasikan data 3. memasukkan data ke bentuk akhir, yaitu data warehouse. Tujuan
ETL adalah
mengumpulkan,
menyaring,
mengolah
dan
menggabungkan data-data dari berbagai sumber untuk disimpan ke dalam data warehouse.
32
Karakteristik dari data ETL antara lain: •
Detailed Data detail menyediakan fleksibilitas bagi user untuk membentuk
stuktur data menjadi struktur yang paling tepat sesuai dengan yang dibutuhkan. •
Historical Data periodik digunakan untuk menyediakan historical perspective.
•
Normalized Normalized data menyediakan integritas dan fleksibilitas yang lebih
baik dibandingkan dengan denormalized data. Pada denormalisasi, data biasanya digunakan untuk mengakses secara periodik menggunakan batch process. Beberapa struktur data warehouse adalah denormalisasi. •
Comprehensive Reconcile data menggambarkan perspektif yang luas, yang dirancang
sesuai model data perusahaan. •
Timely Untuk data warehousing, data harus lengkap sehingga pembuat
keputusan dapat bertindak saat itu juga. •
Quality Control
33
Kualitas data tidak diragukan dan integritas, karena data sudah diringkas ke dalam data mart dan digunakan untuk pengambilan keputusan.
2.14 Pengertian Real Time Data warehouse Real time data warehouse adalah pengembangan dari data warehouse tradisional dengan mengurangi waktu proses ETL dari database source ke database OLAP (data warehouse), sehingga jeda waktu dapat ditekan seminimal mungkin. Dalam hal ini, bukan berarti tidak ada jeda waktu sama sekali dalam proses tersebut. Dalam real-time data warehouse, terdapat 2 hal penting yang harus dilakukan : 1. M engurangi atau
menghilangkan
waktu
yang diperlukan
untuk
mendapatkan dan mengganti data dari sistem sumber 2. M enghilangkan, atau mengurangi sebanyak mungkin waktu yang diperlukan untuk extract, transform, dan loading data M enurut M ike Schmitz, untuk membangun real time data warehouse, dapat dilakukan dengan dua cara, yaitu: 1. Continuous Proses ETL secara terus menerus dari database source ke data warehouse, menggunakan trigger.
34
2. Periodic batch M enggunakan job dalam menjalankan proses transform ke data warehouse. 2.14.1 Proses CTF (Captu re, Transform, Flow) Proses ETL merupakan proses yang membutuhkan resource yang besar dan waktu yang panjang. Kebanyakan tools ETL juga bukan merupakan engine real-time. Karena pertumbuhan bisnis dan peningkatan data, proses ETL semakin tidak efektif untuk dipakai. Karena itulah diberikan solusi yaitu proses CTF (Capture, Transform, Flow)
Gambar 2.10 Proses CTF dalam Data Warehouse (www.grcdi.nl/considerations.pdf
35
A. Capture Terdapat
beberapa
teknik
digunakan
oleh
data
integration/software tambahan untuk memindahkan data. Pada dasarnya, integration tools melakukan salah satu ”push” dan ”pull” pada data yang akan dipindah pada sebuah event driven atau polling basis. Push integration dimulai pada sumber setiap target yang tersubscribe, artinya, seiring perubahan terjadi, maka akan terjadi capture dan pengiriman atau “push” melalui setiap target. Pull integration dimulai pada target oleh setiap target yang disubscribe. Dengan kata lain, sistem target meng-extract perubahan yang di-capture dan melakukan “pull” ke database local. Event driven integration merupakan teknik yang melibatkan kejadian pada sumber memulai capture dan transmisi perubahan yang terjadi. Polling melibatkan proses pengawasan yang menyelidiki status untuk memulai capture dan aplikasi perubahan database. ”Change data capture”, setiap terjadi penambahan, perubahan, atau penghapusan dalam lingkungan database, secara otomatis di-capture dan dilakukan ”push” secara real-time ke data warehouse. Update pada data warehouse dilakukan secara incremental, sehingga hanya data terbaru saja dari update terakhir yang akan di-push ke data warehouse.
36
B. Transformation Proses transform data melalui beberapa lingkungan komputer dan database bisa memperbaiki masalah pada saat menggabungkan informasi untuk data warehouse. Transformasi data dan integrasi software bisa memenuhi kebutuhan ini untuk membuat data warehouse lebih berguna dan bermakna untuk user. Proyek data warehouse memerlukan data operasional di ubah formatnya, peningkatan dan
standarnisasi untuk mengoptimalkan
performance data warehouse. C. Flow Proses flow menunjuk kepada proses melengkapi bahan dari data yang telah di-transfrom pada real time dari sistem operasional kesatu atau lebih sistem subscriber. Aliran data harus lancar dan arus informasi bits yang berlanjut sambil melawan batch loading dari data.
2.15 Oracle Real Time Data Warehouse Oracle secara bertahap telah memperkenalkan fitur-fitur dalam database yang telah mensupport real time data warehouse, fitur-fitur tersebut meliputi : 1. change data capture
37
2. external tabel, tabel functions, pipelining, dan merge command 3. fast refresh materialized views Dalam penulisan ini, hanya akan dijelaskan fitur change data capture yang akan digunakan dalam pembuatan skripsi kami. 2.15.1 Change Data Capture (CDC) Dalam proses extract hal yang sangat penting adalah incremental extraction, yang disebut Change Data Capture. Pada saat data warehouse mengambil data dari sistem operasional, maka data warehouse memerlukan data yang hanya telah mengalami perubahan sejak proses extract terakhir. Change Data
Capture merupakan kunci yang
memungkinkan teknologi real time data warehousing. Change Data Capture adalah sebuah set software dengan pola design untuk menetapkan dan mengecek data yang telah berubah dalam database sehingga data tersebut dapat diambil sebagai data yang berubah. Change Data Capture (CDC) adalah pendekatan innovative untuk data terintegrasi yang berdasarkan proses identifikasi, menangkap, dan mengirim perubahan yang terjadi kedalam sumber data perusahaan. Change Data Capture merupakan elemen penting untuk mengoptimalkan proses extract dari source sistem. Chage data capture tidak meng-extract ulang semua data dari sumber, tetapi hanya mengambil data yang berubah dan terbaru. Change Data Capture
38
membantu mengidentifikasi data dalam sumber sistem yang telah berubah sejak proses extract terakhir. Dengan Change Data Capture, proses extract data berlangsung pada waktu yang sama dengan operasi INSERT, UPDATE dan DELETE yang terjadi pada tabel sumber, dan data yang berubah disimpan di dalam database change tabel. Data yang berubah, saat ditangkap, lalu tersedia untuk target sistem dalam suatu cara terkendali, menggunakan database view. Change Data Capture melakukan extract dengan efisien hanya pada data yang baru,
telah berubah datanya, sehingga change data
capture melakukan extract pada volume data yang lebih kecil. Change data capture dapat mengidentifikasi data yang berubah pada source sistem. Oracle Change Data Capture dapat mengatasi masalah-masalah berikut : 1. Oracle Change Data Capture menyediakan kemampuan untuk menangkap data yang berubah dari oracle database. Yang dapat diambil pada keadaan synchronously dan asynchronously dengan memanfaatkan archive redo log. 2. Oracle Change Data Capture menyediakan kemampuan tidak hanya menangkap data yang berubah, tapi juga mempublikasikan data tersebut dan mengijinkan aplikasi untuk menggunakan data tersebut.
39
3. Oracle Change Data Capture framework dapat digunakan untuk mengoptimalkan proses ETL (Extract, Transformation dan Loading).
Change Data Capture memiliki komponen-komponen : 1. Source sistem : OLTP database dalam database Oracle. Karena CDC menangkap perubahan yang terjadi dalam sumber tabel secara terus menerus dan real time, overhead yang drastis terjadi selama waktu penangkapan. 2. Change Source : (SYNC_SOURCE merupakan sistem yang dihasilkan oleh sumber perubahan), menampilkan sistem sumber dan memuat set perubahan (koleksi dari tabel yang berubah). 3. Change Set : (SYNC_SET merupakan sistem yang dihasilkan dari set perubahan) merupakan koleksi dari satu atau banyak tabel yang berubah. 4. Change Tabel merupakan tabel relational yang memuat semua sumber data tabel yang berubah dan juga sistem metadata yang dibutuhkan untuk mengatur tabel yang berubah. Publisher, sebagai DBA yang bertanggung jawab untuk mensetting CDC data sistem dan mengaturnya. Publisher mengidentifikasi tabel sumber dimana data yang berubah harus ditangkap
dan
mengirimnya ke dalam tabel yang berubah. Publisher juga
40
mengatur akse untuk mempublikasikan data tersebut dengan menggunakan hak akses seperti GRANT dan REVOKE. 5. Subscriber
merupakan
aplikasi
data
warehouse
yang
didasarkan
pada
menggunakan data yang berubah. Arsitektur
Change
Data
Capture
publisher/subscriber model. Publisher menangkap data yang berubah tersebut dan membuat data tersebut tersedia untuk subscriber. Subscriber menggunakan data yang diperoleh dari publisher. Pada umumnya, Change Data Capture sistem mempunyai satu publisher dan banyak subscriber. Publisher pertama kali mengidentifikasi tabel sumber dimana perubahan data perlu untuk ditangkap. Kemudian, menangkap data yang berubah tersebut dan menyimpannya dalam tabel perubahan yang diciptakan. Lalu, mengijinkan subscriber mengawasi akses kepada data tersebut Change Data Capture dapat menangkap dan menerbitkan perubahan data yang dilakukan dalam salah satu mode berikut :
1. Synchronous
41
Dengan menggunakan trigger pada source database, setiap perubahan data akan langsung ditangkap setelah operasi DM L (INSERT, UPDATE dan DELETE). Dalam mode ini, perubahan data ditangkap sebagai bagian dari transaksi saat merubah tabel sumber.
Gambar 2.11 Synchronous Change Data Capture (Oracle Database Data Warehousing Guide 10g Release 2)
2. Asynchronous Perubahan data ditangkap setelah SQL statement menjalankan operasi DM L, dengan menggunakan kelebihan dari data yang dikirim pada redo log file. Dalam mode ini,
42
perubahan data tidak ditangkap sebagai bagian dari transaksi yang merubah
tabel
sumber
dan
karena
itu
tidak
mempengaruhi transaksi.
Gambar 2.12 Asynchronous AutoLog Change Data Capture (Oracle Database Data Warehousing Guide 10g Release 2)
Berikut ini merupakan keuntungan dari menangkap perubahan data menggunakan Change Data Capture :
1. Completeness
43
Change Data Capture dapat menangkap
semua
dampak dari operasi insert, update dan delete, termasuk nilai dari sebelum dan sesudah operasi update. 2. Performance Asynchronous
Change
Data
Capture
dapat
dikonfigurasi untuk meminimalkan dampak performance dalam sumber database. 3. Interface Change
Data
Capture
berisi
paket
PL/SQL
DBMS_CDC_PUBLISH dan DBMS_CDC_SUBSCRIBE, yang memberikan kemudahan untuk digunakan dalam mem-publish dan subscribe interface. 4. Cost Change Data Capture mengurangi biaya pengeluaran karena proses ini menyederhanakan proses extract dari perubahan data dari database sumber.
