BAB 2 LANDASAN TEORI
2.1 Teori-teori Dasar/Umum 2.1.1 Pengertian Data M enurut O’Brien (2005, p38), data adalah fakta atau observasi mentah, yang biasanya mengenai fenomena fisik, atau transaksi bisnis. Sedangkan menurut M cLeod (2001, p12), data terdiri dari fakta- fakta dan angka-angka yang secara relatif tidak berarti bagi pemakai, merupakan fakta mentah yang belum diolah. M enurut Inmon (2005, p493), data adalah suatu pencatatan dari fakta, konsep, atau instruksi dalam suatu media penyimpanan untuk komunikasi, pencarian, dan pemrosesan dengan menggunakan alat otomatis dan presentasi sebagai infomasi yang dapat dimengerti oleh manusia.
2.1.2 Pengertian Informasi M enurut M c.Leod (2001, p21), informasi adalah data yang telah diproses atau data yang telah memiliki arti dan pengertian. M enurut O’Brien (2005, p38), informasi adalah data yang telah diubah menjadi konteks yang berarti dan berguna bagi para pemakai akhir tertentu. M enurut Inmon (2005, p498), informasi adalah data yang dikumpulkan dan dievaluasi untuk memecahkan suatu masalah atau membuat keputusan.
7
8
M enurut Saunders (2009, p17), dalam dunia bisnis, dengan mengetahui informasi apa yang dibutuhkan oleh business users akan membantu dalam menentukan kebutuhan data yang harus tersedia dalam data warehouse.
2.1.3 Database M enurut Ramakrishnan dan Gehrke (2003, p4), database adalah sebuah kumpulan data yang secara khusus menggambarkan aktivitas dari satu atau lebih organisasi yang saling berhubungan.
Sebagai contoh, sebuah database
universitas dapat mengandung informasi tentang: •
Entities, seperti mahasiswa, fakultas, mata kuliah, dan ruang kelas
•
Relationships diantara entities seperti pendaftaran mahasiswa dalam mata kuliah, mata kuliah yang diberikan fakultas, dan penggunaan ruang kelas untuk mata kuliah
2.1.4 Pengertian Data mart M enurut M atteo Golfarelli, Stefano Rizzi (2009, p1), data mart ialah data yang diambil dari ringkasan data warehouse ke dalam informasi yang relevan untuk membuat keputusan, dalam bentuk multidimensional cubes, yang secara khusus di-query-kan oleh OLAP dan reporting front-ends. M enurut Conolly dan Begg (2005, p1171) , data mart merupakan bagian dari data warehouse yang mendukung kebutuhan informasi bagian departemen atau fungsi bisnis tertentu.
9
Karakteristik yang membedakan antara data mart dengan data warehouse yaitu: •
Data mart berfokus pada kebutuhan pengguna yang berhubungan dengan satu bagian departemen atau fungsi bisnis.
•
Data mart tidak berisi data operasional yang bersifat detil.
•
Data mart lebih dimengerti dan digunakan karena berisi data yang lebih sedikit dibandingkan data warehouse.
2.1.5 On-Line Transaction Processing (OLTP) M enurut Connolly (2005, p1149), OLTP systems adalah sistem yang dirancang untuk menangani high transaction, dengan transaksi yang secara khusus membuat perubahan kecil terhadap data operasional organisasi, yaitu data yang diperlukan organisasi untuk menangani day – to- day operation. M enurut Vieira (2000, p892), OLTP systems ialah didesain untuk membolehkan
concurrency,
membuatnya mungkin
untuk
banyak user
mengakses sumber data yang sama dan membangun proses yang mereka butuhkan, sistem ini mengijinkan transaksi-transaksi (dengan kata lain , mengontrol perubahan pada data dalam table, seperti insert, update, delete selama pembangunan proses bisnis).
2.1.6 Entity Relationship Modelling M enurut Connolly dan Begg (2005, p330), pemodelan entity relationship adalah pendekatan dari atas ke bawah untuk merancang database yang dimulai
10
dengan mengidentifikasi data yang penting yang dikenal dengan sebutan entitas dan hubungan antara data harus diperlihatkan dalam model ini. Konsep dasar dari pemodelan entity relationship yaitu: a. Entitas (Entity) M enurut Connolly dan Begg (2005, p331), entity type ialah sekumpulan objek dengan properti yang sama, dimana diidentifikasikan oleh perusahaan karena mempunyai keadaan bebas. M enurut Connolly dan Begg (2005, p333), entity occurrence ialah objek yang didefinisikan secara unik dari entity type. Entity type digambarkan dalam bentuk bujur sangkar dengan diberi nama entitas, yang umumnya ialah kata benda tunggal, dapat dilihat pada gambar 2.1
Gambar 2. 1 Diagram dari entity type Branch dan Staff (Connolly dan Begg, 2005, p333)
b. Hubungan (Relationship) M enurut Connolly dan Begg (2005, p334), relationship type ialah sekumpulan asosiasi yang berarti diantara entity types. Sedangkan, relationship occurrence ialah sebuah asosiasi yang dapat diidentifikasi secara unik dimana terdiri dari satu occurrence untuk masing-masing entity type yang berhubungan.
11
Setiap relationship type digambarkan dengan garis yang menghubungkan entity type, dan diberi nama hubungannya seperti pada gambar 2.2 Pada umumnya, hubungan menggunakan kata kerja atau frase pendek yang mengandung kata kerja. Jika memungkinkan, nama hubungannya bersifat unik. Secara umum, nama hubungan hanya mempunyai arti untuk satu arah saja. Contohnya: pada gambar di bawah ini menyatakan bahwa Branch memiliki Staff.
Gambar 2. 2 Diagram dari relationship type Branch mempunyai Staff (Connolly dan Begg, 2005, p335)
c. Atribut (Attribute) M enurut Connolly dan Begg (2005, p338), atribut ialah properti dari sebuah entitas atau relationship type. Contohnya, staff memiliki atribut staffNo, nama, posisi, dan gaji.
12
2.1.7 Perbedaan Sistem OLTP dengan Sistem Data warehouse M enurut Conolly (2005, p1153), perbedaan antara sistem OLTP dan sistem data warehouse ialah: Sistem OLTP
Sistem Data warehouse
M enangani data-data yang sekarang
M enangani data-data historis
M enyimpan data detil
M enyimpan data detil,sedikit ringkas dan sangat ringkas
Datanya dinamis
Datanya statis
Pemrosesan berulang kali
Pemrosesan ad hoc, tidak terstruktur, dan heuristic
High level of transaction throughput
Medium to low level of transaction troughput
Pola penggunaan dapat diperkirakan
Pola
penggunaan
tidak
dapat
diperkirakan Transaction-driven
Analysis-driven
Berorientasi pada aplikasi
Berorientasi pada subyek
M endukung pengambilan keputusan M endukung pengambilan keputusan sehari-hari Digunakan operasional
strategis oleh
banyak
user Digunakan oleh sejumlah kecil user manajerial
Tabel 2.1 Perbedaan Sistem OLTP dengan Sistem Data warehouse (Connolly, p1153)
13
2.1.8 Pengertian OLAP( Online Analytical Processing) M enurut Hoffer et al (2005, p480), OLAP adalah penggunaan sekumpulan alat grafikal yang menyediakan kepada user sebuah tampilan multidimensional dari data user dan memampukan user untuk menganalisa data menggunakan teknik penyajian yang sederhana. M enurut M allach (2000, p531), OLAP adalah suatu kategori teknologi software yang memungkinkan analis, manajer dan eksekutif lainnya untuk memperoleh wawasan tentang data dengan cepat, konsisten, dan akses interaktif ke dalam variasi yang lebih luas jika dimungkinkan untuk melihat informasi yang telah diubah dari data mentah menjadi dimensi yang nyata dari suatu perusahaan agar dimengerti oleh user. M enurut Sarawagi, Sunita (2001, p1), online analytical processing (OLAP) dikembangkan untuk membantu para analis melakukan pengambilan keputusan berdasarkan data transaksi historis. Secara logikal, menggambarkan sebuah gambaran
multidimensional
dari
data
dengan
beberapa
atribut
yang
dikategorikan seperti Products dan Stores yang dibentuk menjadi dimensi dan atribut numerik seperti Sales dan Revenue yang dibentuk sebagai measures atau cells dari multidimensional cube.
2.1.9 Konsep Data warehouse 2.1.9.1 Pengertian Data warehouse M enurut Inmon (2002, p29), sebuah data warehouse ialah sebuah kumpulan data yang integrated, subject-oriented, nonvolatile, dan time variant yang mendukung manajemen pengambilan keputusan.
14
M enurut Laudon (2006, p233), data warehouse adalah database yang menyimpan data penting saat ini dan historis dari kebutuhan informasi untuk manajer dalam perusahaan. M enurut Adelman dan M oss (2000, p36), data warehouse adalah sebuah lingkungan yang terdiri dari satu atau lebih database terintegrasi dan
terekonsiliasi
yang didesain
untuk
mengantarkan
business
intelligence yang konsisten dan terekonsiliasi untuk seluruh unit bisnis dalam organisasi, untuk menjawab kebutuhan bisnis yang spesifik dan untuk mendukung tujuan strategis perusahaan.
2.1.9.2 Keuntungan Data warehouse M enurut Connolly dan Begg (2005, p1152), data warehouse yang telah diimplementasikan dengan baik dapat memberikan keuntungan yang besar bagi organisasi, yaitu: •
Potensi nilai kembali yang besar pada investasi Sebuah organisasi harus mengeluarkan uang dan sumber daya
dalam jumlah yang cukup besar untuk memastikan kalau data warehouse telah diimplementasikan dengan baik, biaya yang dikeluarkan tergantung dari solusi teknikal yang diinginkan. Akan tetapi, setelah data warehouse digunakan,
maka kemungkinan
didapatkannya ROI
(Return
on
Investment) relatif lebih besar. •
Keuntungan kompetitif Keuntungan kompetitif didapatkan apabila pengambil keputusan
mengakses data yang dapat mengungkapkan informasi yang sebelumnya
15
tidak diketahui, tidak tersedia, misalnya informasi mengenai konsumen, tren, dan permintaan. •
M eningkatkan produktivitas para pengambil keputusan perusahaan Data warehouse meningkatkan produktivitas para pengambil
keputusan perusahaan dengan menciptakan sebuah database yang terintegrasi secara konsisten, berorientasi pada subjek, dan data historis. Data warehouse mengintegrasikan data dari beberapa sistem yang tidak compatible ke dalam bentuk yang menyediakan satu pandangan yang konsisten dari organisasi. Dengan mengubah data menjadi informasi yang berguna, maka seorang manajer bisnis dapat membuat analisa yang lebih akurat dan konsisten.
2.1.9.3 Karakteristik Data warehouse M enurut Inmon (2005, pp29-32), karakteristik dari data warehouse yaitu subject oriented, integrated, nonvolatile dan time variant. Keempat karakteristik ini saling terkait satu sama lain, sehingga ke semuanya harus diimplementasikan agar suatu data warehouse bisa secara efektif memiliki data yang mendukung pengambilan keputusan. 2.1.9.3.1 Subject Oriented (Berorientasi S ubyek) Sistem operasi secara klasik diorganisasikan sekitar aplikasi fungsional
dari
perusahaan.
Untuk
perusahaan
asuransi,
aplikasinya dapat berupa auto, health, life dan casuality. Area subyek utama dari perusahaan asuransi dapat berupa customer, policy, premium, dan claim. Untuk perusahaan, area subyek utama
16
dapat berupa product, order, vendor, bill of material, dan raw goods. Untuk pedagang eceran, area subyek utama dapat berupa product, sale, vendor.
Gambar 2. 3 Contoh subject orientation atas data (Inmon, 2005, p30)
2.1.9.3.2 Integrated (Terintegrasi) Data diambil dari banyak sumber berbeda kemudian dimasukkan ke dalam data warehouse. Selama data diambil data tersebut diubah, dilakukan format kembali, diurutkan, diringkas dan seterusnya. Hasilnya, data terletak dalam data warehouse
17
yang memiliki pandangan terpadu. Data yang dimasukkan ke dalam data warehouse dilakukan dengan berbagai cara yang tidak konsisten pada level aplikasi akan ditinggalkan. Sebagai contoh, masalah pengkodean gender, ini sedikit bermasalah apakah data dalam warehouse dikodekan sebagai m/f atau 1/0. Tidak peduli bagaimana metode atau sumber aplikasi, warehouse akan mengkodekan secara konsisten. Jika data aplikasi dikodekan sebagai x/y untuk gender, ini akan diubah ketika dipindahkan ke dalam warehouse. Pertimbangan yang sama tentang konsistensi juga diaplikasikan ke berbagai isu desain aplikasi seperti, peraturan penamaan, struktur kunci, pengukuran atribut, dan karakteristik fisik data.
18
Gambar 2. 4 Contoh integration (Inmon, 2005, p31)
2.1.9.3.3 Nonvolatile (Tidak mudah berubah) Data dalam lingkungan operasional di-update secara teratur, tetapi data pada data warehouse menunjukkan karakteristik yang berbeda. Data pada data warehouse di-load dan diakses tetapi tidak di-update. Ketika data pada data warehouse di-load, data diload di dalam sebuah snapshot (static format).
19
Ketika terjadi perubahan selanjutnya, snapshot record yang baru ditulis. Dengan melakukan hal tersebut, sebuah histori dari data disimpan dalam data warehouse.
Gambar 2. 5 Contoh nonvolatility (Inmon, 2005, p32)
2.1.9.3.4 Time Variant (Variansi Waktu) Time variant menyatakan bahwa setiap unit data dalam data warehouse adalah akurat pada waktu tertentu. Dalam beberapa kasus, record ditandai. Dalam kasus lain, sebuah record memiliki tanggal transaksi. Tetapi pada setiap kasus, ada beberapa bentuk penanda waktu untuk menunjukkan record tersebut akurat.
20
Gambar 2. 6 Time variancy (Inmon, 2005, p32)
2.1.9.4 S truktur Data warehouse Berdasarkan
Inmon
(2005,
pp33-34),
gambar
di
bawah
menunjukkan tingkat detil yang berbeda dalam data warehouse. Terdapat older level of detail (biasanya berganti-ganti, penyimpanan bulk), current level of detail, level of lightly summarized data (level data mart), dan level of highly summarized data. Data mengalir ke dalam data warehouse dari lingkungan operasional. Biasanya transformasi penting dari data terjadi pada jalur dari tingkat data operasional ke tingkat data warehouse. Seiring berjalannya waktu, data dari current detail mengalir menuju older detail. Apabila data di-summarize, data akan beralih dari current detail menuju lightly summarized data, kemudian dari lightly summarized data menuju highly summarized data.
21
Gambar 2. 7 Struktur data dalam data warehouse (Inmon, 2005, p34)
2.1.9.5 Granularity M enurut Inmon (2005, p41), granularity mengarah ke level of detail atau ringkasan data pada data warehouse. Semakin detil data semakin rendah tingkat granularity. Semakin ringkas data, semakin tinggi tingkat granularity. Ringkasan dari semua transaksi pada suatu bulan akan menjadi tingkat yang tinggi atas granularity. Granularity dari data akan menjadi sebuah persoalan desain utama pada lingkungan data warehouse karena mempengaruhi volume data pada data warehouse dan jenis query yang dapat dijawab. Pada banyak kasus, data yang masuk ke data warehouse berada pada tingkat granularity yang terlalu tinggi artinya developer harus menghabiskan banyak sumber daya
22
untuk memecah data. Kadang – kadang data masuk ke data warehouse pada tingkat granularity yang terlalu rendah.
2.1.9.6 Metadata M enurut Inmon (2005, p102), metadata adalah sebuah komponen penting dari lingkungan data warehouse. M etadata atau data tentang data, telah menjadi bagian dari lingkungan pemrosesan informasi selama telah ada program dan data. Tetapi dalam dunia data warehouse, metadata mendapatkan tingkat kepentingan yang baru, untuk segala usaha yang paling efektif digunakan pada data warehouse. M etadata memungkinkan end-user atau decision support system analyst untuk menavigasi melalui beberapa kemungkinan. Ketika user akan menggunakan data warehouse yang tidak memiliki metadata, maka user tidak tahu darimana akan memulai analisa. Dengan adanya metadata, maka user dapat dengan cepat mencari data yang penting atau menentukan data yang tidak ada dalam data warehouse. M etadata bertindak sebagai index untuk isi dari data warehouse. M etadata items menyimpan hal – hal sebagai berikut: •
Struktur data bagi programmer
•
Struktur data bagi DSS Analyst
•
Sumber data untuk data warehouse
•
Transformasi data ke data warehouse
•
Data model
23
•
Relationship antara data model dan data warehouse
•
Histori dari extracts
2.1.9.7 Arsitektur Data warehouse Arsitektur data warehouse menurut Connolly dan Begg (2005, p1162) sebagai berikut:
Gambar 2. 8 Arsitektur Data warehouse (Connolly,2005, p1162)
24
M enurut Connolly (2005, p1156), arsitektur data warehouse terdiri atas: a. Operational Data Sumber data untuk data warehouse disediakan dari: •
Mainframe data operasional disimpan dalam generasi pertama database hirarkis dan database jaringan. Itu diperkirakan bahwa mayoritas dari data operasional perusahaan ialah berada dalam sistem ini
•
Data-data antar bagian departemen yang tersimpan dalam beraneka ragam sistem penyimpanan file seperti VSAM , RM S, dan relational DBM S seperti Informix dan Oracle.
•
Data internal yang tersimpan di workstation dan private server.
•
Sistem eksternal seperti internet, database komersial, atau database yang berhubungan dengan pelanggan atau supplier dari organisasi.
b. Operational Data Store Suatu operational data store (ODS) adalah suatu media penyimpanan atas data operasional yang terbaru dan terintegrasi yang digunakan untuk analisis. ODS menstrukturkan dan menyediakan data dengan cara yang sama seperti data warehouse, tetapi sesungguhnya bertindak secara sederhana sebagai tempat penampungan sementara sebelum data dipindahkan ke warehouse.
25
ODS diciptakan ketika sistem operasional ditemukan tidak mampu
untuk
mencapai
keberhasilan
sistem
pelaporan.
ODS
menyediakan manfaat yang berguna dari suatu relational database dalam mengambil keputusan yang mendukung fungsi data warehouse. c. Load Manager Load manager melakukan semua operasi yang berhubungan dengan extract dan load data ke dalam data warehouse. Data di-extract secara langsung dari sumber data atau umumnya dari penyimpanan data operasional. Operasi yang dilakukan oleh load manager dapat meliputi transformasi data yang sederhana untuk mempersiapkan data tersebut agar dapat dimasukkan ke dalam warehouse. d. Warehouse Manager Warehouse
manager
melaksanakan
semua
operasi
yang
berhubungan dengan pengelolaan atas data dalam warehouse. Operasioperasi yang dilaksanakan oleh warehouse manager meliputi: •
Analisa atas data untuk memastikan konsistensinya.
•
Transformasi dan penggabungan sumber data dari tempat penyimpanan sementara ke dalam tabel-tabel data warehouse.
•
Pembuatan index dan view pada tabel-tabel dasar.
•
M enghasilkan denormalisasi (jika diperlukan).
•
M enghasilkan agregasi (jika diperlukan).
•
Backup dan archieve data.
26
e. Query Manager Query manager melakukan semua operasi yang berkaitan dengan pengelolaan dari query user. Komponen ini secara khusus dibangun menggunakan tool akses data end-user, tool pengontrol data warehouse, fasilitas database, dan custom-built program. Kompleksitas query manager ditentukan oleh fasilitas yang disediakan oleh tool akses enduser dan database. Operasi yang dilakukan komponen ini meliputi pengarahan query pada tabel yang sesuai dan penjadwalan pelaksanaan query. Dalam beberapa kasus, terkadang query manager juga menghasilkan profil query yang mengijinkan warehouse manager menentukan kesesuaian index dan agregasi. f. Detailed Data Area ini menyimpan semua data detil di dalam skema database, yang bertujuan untuk melengkapkan kumpulan data untuk data warehouse. Dalam banyak kasus, data yang terperinci tidaklah disimpan secara online tetapi dapat disediakan melalui agregasi data pada tingkatan detil berikutnya. g. Lightly dan Highly Summarized Data Area ini menyimpan semua lightly dan highly summarized (aggregated) data yang dihasilkan oleh warehouse manager. Area ini adalah tempat penampungan sementara sebelum dilakukan perubahan secara berkelanjutan untuk merespon perubahan profil query.
27
Tujuan ringkasan informasi ini adalah untuk mempercepat pencapaian query. M eskipun biaya operasi akan meningkat sehubungan dengan proses peringkasan data tersebut, ini akan diseimbangkan dengan menghapus keperluan untuk secara terus-menerus melakukan operasi ringkasan (seperti penyortiran atau pengelompokan) dalam menjawab query user. Ringkasan data di-update secara terus- menerus ketika ada data baru terisi ke dalam warehouse. h. Archive / Backup Data Area ini menyimpan semua detil dan ringkasan data untuk kepentingan archiving dan backup. Walaupun ringkasan data dihasilkan dari detil data, itu akan mungkin untuk membutuhkan backup ringkasan data secara online jika data ini disimpan melebihi periode penyimpanan untuk data yang terinci. Data ditransfer ke arsip penyimpanan seperti magnetic tape atau optical disk. i. M etadata Area ini menyimpan semua definisi metadata yang digunakan oleh semua proses di dalam warehouse. M etadata digunakan untuk berbagai tujuan termasuk: •
Proses extract dan load atas metadata digunakan untuk memetakan sumber data ke dalam pandangan umum data dalam warehouse.
•
Proses pengelolaan warehouse – metadata digunakan untuk mengotomatisasi pembuatan atas tabel ringkasan.
28
•
Sebagai bagian proses pengelolaan query – metadata digunakan untuk mengarahkan suatu query dengan sumber data yang tepat.
j. End-User Access Tools Tujuan yang utama dari data warehouse adalah menyediakan informasi kepada user untuk mendukung pengambilan keputusan. Para user ini berinteraksi dengan warehouse menggunakan end-user access tools. Ada 5 kelompok utama dari end-user access tools: •
Reporting dan query tools Reporting tools meliputi production reporting tools dan report
writers. Production reporting tools digunakan untuk menghasilkan laporan operasional regular (biasa), seperti pemesanan pelanggan dan pembayaran staff. Sedangkan report writer adalah desktop tools yang dirancang untuk end-user. Query tools untuk data warehouse relational dirancang untuk menerima SQL atau menghasilkan pernyataan SQL untuk proses query data yang tersimpan dalam data warehouse. •
Application development tools Aplikasi yang dapat digunakan user yaitu graphical data access
yang dirancang secara utama untuk sisi client server. Beberapa application development tools terintegrasi dengan OLAP tools dan dapat mengakses semua sistem basis data utama, mencakup Oracle, Sybase dan Informix.
29
•
Executive Information System (EIS) tools. Executive information system, lebih dikenal sebagai “everybody’s
information systems”, yang semula dikembangkan untuk mendukung pengambilan keputusan tingkat tinggi. Kemudian meluas untuk mendukung semua tingkat manajemen. Executive information system tools yang terisolasi dengan mainframe memungkinkan user membuat aplikasi pendukung pengambilan keputusan untuk menyediakan overview data organisasi dan mengakses sumber data eksternal. Saat ini perbedaan antara EIS dan decision support tools lainnya semakin
tidak
jelas,
sejak
pengembangan
EIS
melakukan
penambahan fasilitas-fasilitas tambahan dan menyediakan aplikasi custom–build untuk area bisnis seperti penjualan, pemasaran, dan keuangan. •
Online Analytical Processing (OLAP) tools. Online analytical processing tools berbasis pada konsep basis
data multidimensi dan memperbolehkan user untuk menganalisis data menggunakan view yang kompleks dan multidimensional. Tools ini mengasumsikan bahwa data diatur dalam model multidimensi yang didukung oleh special multidimensional database (M DDB) atau oleh basis
data
relasional
multidimensional queries.
yang
dirancang
untuk
mendapatkan
30
•
Data mining tools. Data mining adalah proses menemukan korelasi, pola dan arah
baru yang mempunyai arti dengan ‘menambang’ (mining) sejumlah besar data dengan menggunakan teknik statistik, matematika dan artificial intelligence (AI). Data mining memiliki potensi untuk mengganti kemampuan dari OLAP tools.
2.1.9.8 Data warehouse Data Flows M enurut Connolly dan Begg (2005, p1162), data warehouse fokus pada manajemen lima arus data primer yaitu: 1. Inflow adalah proses yang berhubungan dengan pengekstrakan (extraction), pembersihan (cleansing), dan pemuatan (loading) data dari sumber data ke dalam data warehouse. 2. Upflow adalah proses yang berhubungan dengan penambahan nilai ke dalam data di dalam data warehouse melalui peringkasan, pemadatan, dan pendistribusian data. 3. Downflow adalah proses mengarsip dan membuat backup data dalam data warehouse. 4. Outflow adalah proses membuat data agar tersedia bagi end-user. 5. Metaflow adalah proses yang berhubungan dengan manajemen metadata.
31
2.1.9.9 ETL ( Extraction, Transformation, Loading) a. Data Extraction M enurut Kimball dan Ross (2002, p8), extraction ialah langkah pertama dalam proses mendapatkan data ke dalam lingkungan data warehouse. M enurut
Dyche (2000, p157), data ditemukan
dan
dipindahkan dari sistem operasional ke data warehouse atau platform transformasi. b. Data Transformation M enurut Kimball dan Ross (2002, p8), setelah data diextract, ada sejumlah transformation yang mungkin dilakukan, seperti melakukan cleansing data (memperbaiki kesalahan pengejaan kata, mengatasi masalah elemen yang hilang, atau mengubah ke bentuk standard), mengkombinasikan data dari berbagai sumber, dan memberikan warehouse keys. c. Data Loading M enurut Kimball dan Ross (2002, p8), setelah melakukan transformasi maka data dapat dimuat ke dalam data warehouse.
2.1.9.10 Anatomi Data warehouse 2.1.9.10.1 Data warehouse Terpusat Berdasarkan Inmon (2005, p193), sebagian besar organisasi membangun dan memelihara lingkungan data warehouse terpusat
32
tunggal. Pengaturan ini dilakukan karena memiliki beberapa alasan yaitu: •
Data dalam warehouse terintegrasi antar perusahaan dan gambaran terintegrasi digunakan hanya pada kantor pusat.
•
Perusahaan mengoperasikan sebuah model bisnis terpusat.
•
Volume
data
dalam
data
warehouse
seperti sebuah
penyimpanan tunggal yang terpusat. •
Sekalipun data dapat diintegrasikan, jika data diedarkan melalui banyak local
sites,
maka
akan
mempersulit
pengaksesan.
2.1.9.10.2 Data warehouse Terdistribusi M enurut Inmon (2005, p193), tiga tipe dari data warehouse terdistribusi: •
Bisnis terdistribusi secara geografis atau dibedakan menurut lini produk. Oleh karena hal tersebut, maka disebutlah data warehouse lokal dan data warehouse global. Data warehouse lokal mewakili data dan proses di lokasi yang terpencil dan data warehouse global mewakili bagian dari bisnis yang diintegrasikan melalui keseluruhan bisnis.
•
Lingkungan data warehouse akan memegang banyak data dan volume data akan didistribusikan melalui beberapa
33
processor. Secara logikal hanya ada satu data warehouse, tetapi secara fisikal terdapat banyak data warehouse yang semuanya mempunyai hubungan yang dekat tetapi diletakkan pada processor yang terpisah. Konfigurasi ini dapat
disebut
dengan
teknologi
data
warehouse
terdistribusi. •
Lingkungan data warehouse tumbuh dalam sebuah kebiasaan yang tidak terorganisasi. Data warehouse yang pertama
muncul,
kemudian
diikuti
yang
lainnya.
Kurangnya koordinasi dari pertumbuhan data warehouse yang berbeda biasanya menghasilkan sebuah perbedaan secara politik dan organisasi. Kasus ini dapat disebut dengan data warehouse terdistribusi yang secara bebas berkembang.
2.1.9.11 External Data dan Data Warehouse M enurut Inmon (2005, pp257-258), kebanyakan organisasi membangun data warehouse mereka pada data yang berasal dari sistem yang ada (yakni, diatas data internal ke perusahaan). Di hampir setiap kasus, data ini dapat disebut data internal, terstruktur. Data internal berasal dari perusahaan dan telah dibentuk ke dalam format yang teratur. Satu keseluruhan besar atas data lain yang sah digunakan untuk sebuah perusahaan yang tidak dihasilkan dari sistem perusahaan sendiri disebut data eksternal dan biasanya memasuki perusahaan dalam format yang
34
tidak terduga. Data warehouse ialah tempat yang ideal untuk menyimpan data eksternal. M enurut Inmon (2005, p268), data warehouse mampu menangani lebih dari data internal, terstruktur. Ada banyak informasi yang relevan untuk menjalankan perusahaan yang berasal dari sumber-sumber di luar perusahaan.
Gambar 2.9 External Data dalam Data Warehouse
2.1.9.12 Metodologi Perancangan Data warehouse M enurut Connolly dan Begg (2002, p1183), dimensionality modeling adalah sebuah teknik logical design yang bertujuan untuk menghadirkan data dalam sebuah bentuk yang standard dan intuitif yang memungkinkan pengaksesan database dengan performa yang tinggi. Ada
beberapa
konsep
pemodelan
data
warehouse
pada
dimensionality modeling yang dikenal umum pada saat ini, konsep –
35
konsep tersebut antara lain ialah star schema, snowflake schema, dan starflake schema.
2.1.9.12.1 Star Schema ( S kema Bintang) M enurut Hoffer et al (2005, p467), star schema terdiri dari dua macam tabel, yaitu tabel fakta (fact table) dan tabel dimensi (dimension table). Tabel fakta mengandung fakta atau data kuantitatif mengenai sebuah bisnis seperti jumlah unit terjual, jumlah order, dan sebagainya. Tabel dimensi berisi data deskriptif mengenai subjek bisnis. Tabel dimensi biasanya adalah sebagai sumber
attribute yang digunakan
untuk
mengkualifikasi,
mengkategorikan, atau meringkas fakta dalam query, report, atau grafik. M enurut Ponniah (2001, pp210-216), star schema adalah teknik dasar desain data untuk data warehouse. Struktur star schema adalah suatu struktur yang dapat dengan mudah dipahami dan digunakan oleh user seperti yang terlihat pada gambar 2.10. Struktur tersebut mencerminkan bagaimana user biasanya memandang ukuran-ukuran kritis mengikuti dimensi-dimensi bisnis yang ada.
36
Gambar 2. 10 Contoh star schema (http://www.juergenkonicek.de/Pictures/DWHSchemas.gif)
Keuntungan star schema: 1. M udah dipahami user Star schema menggambarkan dengan jelas bagaimana user berpikir dan memerlukan data untuk query dan analisis. Star schema menggambarkan hubungan antar tabel sama seperti cara user melihat hubungan tersebut secara normal. 2. M engoptimalkan navigasi Star schema mengoptimalisasikan navigasi melalui database sehingga lebih mudah dilihat. M eskipun hasil query terlihat kompleks, tetapi navigasi itu memudahkan user. 3.
Paling cocok untuk pemrosesan query
37
Star schema paling cocok untuk pemrosesan query karena skema ini berpusat pada query. Tanpa bergantung pada banyak dimensi dan kompleksitas query, setiap query akan dengan mudah dijalankan, pertama dengan memilih baris dari tabel dimensi dan kemudian menemukan baris yang sama di tabel fakta.
2.1.9.12.2 Snowflake Schema (S kema Snowflake) M enurut
Ponniah
(2001,
p235),
snowflake
schema
merupakan variasi lain dari skema bintang dimana tabel dimensi dari skema bintang dinormalisasi, seperti yang digambarkan pada gambar 2.11.
Gambar 2. 11 Contoh snowflake schema (http://www.juergenkonicek.de/Pictures/DWHSchemas.gif)
38
Keuntungan snowflake schema: a. Ukuran penyimpanan kecil di dalam tempat penyimpanan. b. Struktur yang normal lebih mudah untuk di-update dan dijaga.
Kerugian snowflake schema: a. Skemanya kurang intuitif atau jelas dan end-user terhambat oleh kompleksitas. b. Sulit untuk mencari isi skema karena terlalu kompleks. c. Performa query menurun karena adanya tambahan gabungan tabel.
2.1.9.12.3 Starflake Schema ( S kema Starflake) M enurut Connolly dan Begg (2005, p1185), starflake schema adalah struktur campuran (hybrid) yang berisi gabungan dari star schema dan snowflake schema .
39
Gambar 2. 12 Contoh starflake schema (http://www.juergenkonicek.de/Pictures/DWHSchemas.gif)
2.1.9.13 Komponen Dimensional Modelling a. Fact M enurut Kimball dan Ross (2002, p402), fact atau fakta adalah sebuah ukuran dari performansi bisnis, biasanya berupa numerical dan penjumlahan. Hal ini berlanjut pada pengertian dari tabel fact sebagai lokasi penyimpanan untuk fact yang ada. b. Fact Table M enurut Inmon ( 2005, p497), fact table ialah pusat dari tabel star join dimana data dengan banyak kepentingan tersimpan. M enurut Kimball dan Ross (2002, p402), fact table pada sebuah star schema ialah tabel central dengan pengukuran performansi bisnis dalam bentuk numerik yang memiliki karakteristik berupa
40
sebuah composite key, yang tiap-tiap elemennya adalah foreign key yang didapat dari tabel dimensi. c. Dimension M enurut Kimball dan Ross (2002, p399), dimension atau dimensi merupakan sebuah entitas independent pada sebuah model dimensional yang berfungsi sebagai pintu masuk atau mekanisme untuk memecah-mecah pengukuran tambahan yang ada pada tabel fakta dari model dimensional. d. Dimension Table M enurut Inmon (2005, p495), dimension table atau tabel dimensi merupakan
tempat
dimana data tambahan
yang
berhubungan dengan tabel fakta ditempatkan pada sebuah tabel multidimensional. M enurut Kimball dan Ross (2002, p399), tabel dimensi ialah sebuah tabel pada model dimensional yang memiliki sebuah primary key tunggal dan kolom dengan atribut deskriptif. e. Surrogate Key M enurut Kimball dan Ross (2002, p414), surrogate key ialah key berupa integer yang secara sequential ditambahkan sesuai dengan keperluan untuk membentuk sebuah tabel dimensi dan elemen yang menggabungkannya dengan tabel fakta. Pada tabel dimensi, surrogate key bertindak sebagai primary key. Sedangkan pada tabel fakta, surrogate key bertindak sebagai foreign key yang menspesifikasikan dimensi.
41
2.1.9.14 Keuntungan dimensionality modelling M enurut
Connoly
dan
Begg
(2005,
p1185),
keuntungan
menggunakan konsep pemodelan dimensional dalam lingkungan data warehouse adalah: •
Efisiensi Kekonsistenan dari struktur database yang menggunakan model dimensional memungkinkan akses data yang lebih efisien dengan menggunakan berbagai macam tools seperti membuat laporan dan query tools.
•
Kemampuan untuk menangani kebutuhan perubahan Star schema dapat beradaptasi dengan perubahan dalam kebutuhan user sehinggga semua dimensi menjadi sama dalam hal menyediakan akses ke tabel fakta.
•
Ekstensibilitas M odel dimensional dirancang untuk dapat mengalami perluasan. Sebagai contoh, penambahan fakta terkait proses bisnis baru dengan tingkat granularitas yang telah ada sebelumnya, penambahan dimensi baru dapat dilakukan selama dimensi ini memiliki elemen yang menghubungkannya dengan fakta, dan penambahan atribut dimensi.
•
Kemampuan untuk membuat model dari situasi bisnis yang terjadi Perkembangan pada dunia bisnis pada saat ini selalu terjadi, salah satunya merupakan penyebab terjadinya slowly changing dimension, dan dimensional model memiliki kapasitas untuk menghadapi hal ini.
42
•
Pemrosesan query yang dapat diprediksikan Aplikasi data
warehouse yang melakukan drill down akan
menambahkan atribut dimensi dari dalam sebuah star schema. Aplikasi ini akan berhubungan dengan tabel-tabel fakta yang terpisah secara bersamaan melalui shared (conformed) dimension. Walaupun hal ini terkesan rumit, pemrosesan query sangat dapat diprediksi karena pada tingkat terendah, setiap tabel fakta dapat di-query secara terpisah.
2.1.9.15 Agregasi M enurut Inmon (2005, p114), terdapat banyak kasus dimana data dalam data warehouse tidak memenuhi kriteria stabilitas dan tidak sering berubah, kasus lainnya dimana jumlah data menjadi terlalu banyak, sering terjadi perubahan isi data, dan sebagainya. Dalam kasus-kasus seperti demikian, dapat dilakukan agregasi yang mengelompokkan beberapa data detil operasional yang berbeda ke dalam satu record tunggal. Record tunggal itu disebut sebagai profile record atau aggregate record. Sebuah profile record dibuat untuk mengelompokkan record detil yang sangat banyak jumlahnya. Sebagai contoh, sebuah perusahaan telepon pada akhir bulan mengumpulkan semua data-data aktivitas telepon para pelanggan dalam sebulan kedalam data record pelanggan dalam data warehouse.
43
Agregasi dari data operasional kedalam sebuah record tunggal dalam data warehouse dapat dilakukan dengan menggunakan beberapa cara, seperti: •
Nilai-nilai yang diambil dari data operasional dapat diringkas.
•
Unit-unit data operasional dapat dihitung / dijumlahkan, dimana jumlah dari unit data tersebut disimpan.
•
Unit-unit atas data dapat diproses untuk menentukan yang paling tinggi, paling rendah, rata-ratanya, dan lain-lain.
•
Kejadian pertama dan terakhir dari data dapat ditangkap
•
Tipe data tertentu, yang berada dalam batasan dari beberapa parameter, dapat diukur.
•
Data yang efektif pada momen waktu tertentu dapat ditangkap
•
Data yang paling muda dan yang paling tua dapat ditangkap
2.1.9.16 Denormalisasi M enurut Inmon (2005, p495), denormalisasi adalah teknik dari penempatan data normalisasi dalam lokasi fisik yang mengoptimalkan kinerja dari sistem. M enurut Rainardi (2008, p30), denormalized database ialah sebuah database dengan beberapa redundancy data tidak hilang melalui sebuah proses normalisasi.
44
2.1.9.17 Tahapan Membangun Data warehouse Berdasarkan Ralph Kimball yang dikutip oleh Connolly dan Begg (2005, pp1187-1193), metodologi yang dikemukakan dalam membangun data warehouse ada 9 tahapan, dikenal dengan nine-step methodology. Sembilan tahapan tersebut adalah: 1. M emilih proses (Choosing the process) Proses menunjuk pada subyek yang ada dari sebuah bagian data mart. Data mart pertama yang akan dibangun harus tepat waktu, disesuaikan dengan anggaran dan menjawab pertanyaan bisnis yang banyak diutarakan. 2. M emilih grain (Choosing the grain) M emilih grain berarti menentukan secara tepat apa yang direpresentasikan oleh record pada tabel fakta. Sebagai contoh PropertySale merepresentasikan fakta mengenai setiap penjualan properti dan menjadi tabel fakta dari skema bintang PropertySale. Oleh karena itu, grain dari tabel fakta PropertySale adalah penjualan properti itu sendiri. Ketika grain dari tabel fakta dipilih, dimensi dapat diidentifikasi dari tabel fakta. Sebagai contoh, yaitu Branch, Staff, Owner, ClientBuyer, PropertyForSale, dan Promotion entity akan digunakan untuk tabel dimensi pada skema bintang. Tabel dimensi Time termasuk dalam dimensi utama yang selalu ada dalam skema bintang. M emutuskan grain untuk tabel fakta juga menentukan grain untuk setiap tabel dimensi. M isalnya, grain pada tabel fakta PropertySale adalah setiap penjualan
45
properti itu sendiri, kemudian grain pada dimensi Client adalah detil dari klien yang membeli properti. 3. Identifikasi dan penyesuaian dimensi (Identifying and conforming the dimensions) Dimensi menetapkan konteks pertanyaan mengenai fakta dalam tabel fakta. Kumpulan dimensi yang baik membuat data mart mudah dimengerti dan digunakan. Dimensi diidentifikasikan dengan detil untuk menjelaskan suatu hal seperti client dan property pada grain yang tepat. Sebagai contoh dimensi client buyer mendeskripsikan atribut ID, nama, tipe, kota, area dan negara. 4. M emilih fakta (Choosing the fact) Grain dari tabel fakta menentukan fakta yang bisa digunakan. M isalnya, grain dari tabel fakta adalah setiap penjualan properti, kemudian semua fakta numerik harus menunjuk pada penjualan ini. Fakta-fakta tersebut harus numerik dan dapat ditambah. 5. M enyimpan pre-calculation pada tabel fakta (Storing pre-calculation in the fact-table) Setelah fakta-fakta dipilih maka dilakukan pengkajian ulang untuk menentukan apakah ada fakta-fakta yang dapat diterapkan untuk precalculation (kalkulasi awal). Contoh umum dari kebutuhan untuk penyimpanan pre-calculation muncul ketika fakta berisi pernyataan untung atau rugi. Situasi ini akan meningkat ketika tabel fakta didasarkan pada invoice atau sales.
46
6. Rounding out the dimension table Dalam langkah
ini,
kembali pada dimension
table dan
menambahkan gambaran teks terhadap dimensi yang memungkinkan. Gambaran teks harus mudah digunakan dan dimengerti oleh user. Kegunaan suatu data mart ditentukan oleh lingkup dan atribut tabel dimensi. 7. M emilih durasi dari basis data (Choosing the duration of the database) Durasi mengukur seberapa jauh waktu tabel fakta berjalan. Sebagai contoh, perusahaan asuransi memiliki kebutuhan untuk menyimpan data dalam jangka waktu 5 tahun atau lebih. Tabel fakta yang sangat besar menimbulkan dua persoalan. Pertama, semakin tua umur data, akan muncul masalah pembacaan dan interpretasi file lama. Kedua, menimbulkan kemungkinan versi dimensi lama digunakan, bukan versi terbarunya. Hal ini akan dibahas lebih lanjut pada tahap delapan ”Tracking slowly changing dimensions”. 8. M elacak perubahan dari dimensi secara perlahan (Tracking slowly changing dimensions) M engamati perubahan dari dimensi pada dimension table. Ada tiga tipe dasar dari perubahan dimensi yang perlahan, yaitu: •
Tipe 1, di mana atribut dimensi yang diubah dituliskan ulang (overwritten);
•
Tipe 2, di mana atribut dimensi yang diubah menyebabkan pembentukan record baru dalam dimensi;
47
•
Tipe 3, di mana atribut dimensi yang diubah mengakibatkan sebuah atribut atau kolom alternatif dibuat, jadi antara record yang lama dan baru dapat diakses secara bersama-sama.
9. M emutuskan prioritas dan mode dari query (Deciding the query priorities and the query modes) M empertimbangkan pengaruh dari rancangan fisik, seperti penyortiran urutan tabel fakta pada disk dan keberadaan dari penyimpanan awal ringkasan (summaries) atau penjumlahan (aggregate). Selain itu, masalah administrasi, backup, kinerja indeks, dan keamanan juga merupakan faktor yang harus diperhatikan.
2.2 Teori-teori Khusus 2.2.1 Penjualan M enurut M ulyadi (2001, p202), ”Kegiatan penjualan terdiri dari transaksi penjualan barang atau jasa, baik secara kredit maupun tunai”. Ditinjau dari pembayaran yang dilakukan pembeli, maka jenis penjualan dibedakan menjadi dua, yaitu: 1. Penjualan tunai M enurut M ulyadi (2001, p455), “Penjualan tunai dilaksanakan oleh perusahaan dengan cara mewajibkan pembeli melakukan pembayaran harga barang lebih dahulu sebelum barang diserahkan oleh perusahaan kepada pembeli. Setelah uang diterima oleh perusahaan, barang kemudian diserahkan kepada pembeli dan transaksi penjualan tunai kemudian dicatat oleh perusahaan”.
48
2. Penjualan kredit M enurut M ulyadi (2001, p210), “Penjualan kredit dilaksanakan oleh perusahaan dengan cara mengirimkan barang sesuai dengan order yang diterima dari pembeli untuk jangka waktu tertentu perusahaan mempunyai tagihan kepada pembeli tersebut”. M enurut Yunarto (2006, p313), di setiap perusahaan selalu ditemui ada banyak sekali laporan yang berhubungan dengan penjualan. Hal ini dapat diatasi dengan memiliki database tersendiri yang disebut dengan istilah data warehouse sehingga pengaksesan data penjualan menjadi lebih fleksibel. Ini akan sering dikonsumsi oleh top management yang sering membutuhkan informasi yang sangat dinamik dimana ada penampilan informasi dalam bentuk grafis, fungsi drill-down (misalnya pada penjualan per kelompok customer, ketika diklik akan menampilkan penjualan per customer), dan lain-lain.
2.2.2 Pembelian M enurut M ulyadi (2001, pp299-300), pembelian digunakan dalam perusahaan untuk pengadaan barang yang diperlukan perusahaan. Fungsi pembelian bertanggung jawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang, dan mengeluarkan order pembelian kepada pemasok yang dipilih dalam pengadaan barang, dan mengeluarkan order pembelian kepada pemasok yang dipilih. M enurut Kakouris (2006, p709), pembelian sekarang diakui sebagai sebuah fungsi strategis, tidak hanya karena keputusan dibuat oleh manajer pembelian yang memiliki pengaruh besar pada kinerja perusahaan secara
49
keseluruhan, tetapi juga karena para pebisnis harus mengatur proses yang menghubungkan mereka dengan para pemasok mereka.
2.2.3
Content Provider M enurut M endes (2004, p31), content provider adalah perusahaan yang
membuat dan menyediakan konten dalam bentuk digital untuk pelanggan dengan menggunakan perantara pihak ketiga. Sebuah content provider menawarkan keahlian dan kepemimpinan dalam pasar dan penting bahwa provider memahami kebutuhan dan keinginan pelanggan, sehingga ia dapat membuat dan memberi harga konten dengan tepat.
