BAB 2 LANDASAN TEORI
2.1. Teori – teori Umum 2.1.1. Pengertian Data Menurut O’Brien (2004:13), data adalah data mentah atau observasi, tentang fenomena fisik atau transaksi bisnis. Menurut Cegielski & Rainer (2011:10), data adalah deskripsi dasar dari benda, event, aktifitas, dan transaksi yang telah direkam, diklasifikasi, disimpan tetapi belum bisa menyampaikan arti yang lebih spesifik Menurut McLeod & Schell (2008:10), data terdiri atas fakta dan angka yang biasanya tidak bermanfaat karena volumenya yang besar dan sifatnya yang masih belum diolah. Sedangkan menurut Inmon (2005:493), data sebuah rekaman fakta, konsep, atau instruksi pada sebuah media penyimpanan untuk berkomunikasi,
mengambil
dan
mengolah
secara
otomatis
dan
mempresentasikan sebagai sebuah informasi yang dapat dimengerti oleh manusia. Dari penjelasan di atas dapat disimpulkan bahwa data adalah suatu kumpulan fakta mentah yang belum memiliki arti bagi penerimanya dan masih memerlukan adanya suatu pengolahan.
2.1.2. Pengertian Informasi Menurut O’Brien (2004:13), informasi adalah data yang telah dikonversi menjadi berguna dan berarti bagi pengguna akhir yang spesifik.
7
8 Menurut Cegielski & Rainer (2011:10), informasi adalah data yang telah terorganisasi sehingga dapat memberikan arti dan nilai bagi yang menerima informasi. Menurut McLeod & Schell (2008:11), informasi adalah data hasil pemrosesan yang memiliki makna, biasanya menceritakan suatu hal yang belum diketahui kepada pengguna. Menurut
Inmon
(2005:493)
informasi
yang
mengasimilasi
dan
mengevaluasi makhluk hidup untuk memecahkan sebuah masalah dan membuat keputusan. Dari penjelasan di atas dapat disimpulkan bahwa informasi merupakan hasil olahan dari suatu data yang sudah memiliki makna dan dapat memberikan informasi bagi penerimanya.
2.1.3. Pengertian Database Menurut Connolly & Begg (2010:65), database adalah sebuah kumpulan logikal data yang saling berkait, dan deskripsi dari data tersebut, dirancang untuk memenuhi kebutuhan informasi dari sebuah organisasi. Menurut Inmon (2005:493) database adalah sebuah koleksi data yang saling terkait, yang disimpan (sering dikontrol, dan sedikit redudansi) sesuai dengan skema. Sebuah database dapat melayani satu atau beberapa aplikasi. Database menurut Satzinger, et al (2005:398) merupakan sekumpulan data yang terintegrasi pengelolaannya dan dikendalikan secara terpusat. Menurut Whitten & Bentley (2004:518), database adalah kumpulan file yang saling terkait. Kata kuncinya adalah “saling terkait”. Database tidak hanya
merupakan
kumpulan
file.
Record
pada
setiap
file
harus
9 memperbolehkan hubungan-hubungan (anggaplah sebagai pointer) untuk menyimpan file-file lain. Dari penjelasan di atas dapat disimpulkan bahwa database adalah tempat penyimpanan semua record dari suatu perusahaan.
2.1.4. Pengertian Database Management System (DBMS) Menurut Connolly & Begg (2010:66), database management system adalah sebuah perangkat lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, memelihara dan mengontrol akses ke database. Menurut Inmon (2005:494) database management system adalah sebuah sistem manajemen database berbasis perangkat lunak yang dapat digunakan untuk membangun dan mengelola data. Menurut Kimball & Ross (2002:398) database management system adalah sebuah aplikasi komputer yang tujuan utamanya adalah untuk menyimpan, mengambil, dan memodifikasikan data dengan cara yang sangat terstruktur. Data di dalam DBMS biasanya saling dibagi kepada beberapa aplikasi. Menurut Bentley & Whitten (2004:524), database management system adalah perangkat lunak komputer khusus yang disediakan dari vendor-vendor komputer yang digunakan untuk membuat, mengakses, mengontrol dan mengelola database. DBMS dapat merespon perintah-perintah khusus untuk membuat struktur database kemudian membaca, memperbarui, dan menghapus record yang terdapat pada sebuah database.
10 Dari definisi di atas, dapat disimpulkan DBMS adalah perangkat lunak yang mengatur sebuah database, sehingga DBMS merupakan salah satu komponen penting dalam sebuah sistem yang terkomputerisasi.
2.1.5. Pengertian Online Transaction Processing (OLTP) Menurut Connolly & Begg (2010:1198) mengenai OLTP, sistem ini menghasilkan data operasional yang rinci, saat ini dan dapat berubah. Sistem OLTP mengoptimalkan transaksi dalam jumlah besar, yang diprediksi, berulang, dan diperbarui secara intensif. Data OLTP dapat diatur sesuai dengan persyaratan dari transaksi yang terkait dengan aplikasi bisnis dan mendukung keputusan perhari dalam jumlah besar pada pengguna operasional. Menurut Inmon (2005:500) OLTP adalah sebuah proses transaksi yang berkinerja tinggi. Menurut Kimball & Ross (2002:408), OLTP adalah gambaran asli untuk semua aktivitas dan sistem yang berhubungan dengan memasukkan data ke dalam database. Paling sering digunakan dengan mengacu pada database relasional,
meskipun
OLTP
dapat
digunakan
secara
umum
untuk
menggambarkan setiap pemrosesan transaksi. Kontras dengan proses analisis online. Dari definisi di atas, dapat disimpulkan bahwa OLTP adalah suatu sistem yang memproses suatu transaksi secara langsung pada suatu jaringan.
2.1.6. Pengertian Online Analytical Processing (OLAP) Menurut Connolly & Begg (2010:1249), OLAP adalah istilah untuk menggambarkan
sebuah
teknologi
yang
menggunakan
tampilan
11 multidimesional dari data agregat untuk menghasilkan akses yang cepat ke informasi yang strategis untuk tujuan analisis. (Codd et al., 1995). OLAP memungkinkan user untuk mendapatkan pemahaman yang lebih dalam pengetahuan tentang berbagai aspek data perusahaan mereka dengan cepat, konsisten, dan interaktif. OLAP memungkinkan untuk melihat tampilan data perusahaan sedemikian rupa dimana memberikan sebuah gambaran yang lebih baik dari dimensi sebenarnya dari perusahaan. Menurut Inmon (2005:500), OLAP adalah departemen pengolahan dari datamart environment. Menurut Kimball & Ross (2002:408), OLAP biasanya didefinisikan sebagai sebuah kumpulan dari prinsip-prinsip yang menyediakan dimensi kerangka kerja untuk membuat keputusan. OLAP juga digunakan untuk mendefinisikan sebuah konfederasi vendor yang menawarkan nonrelasional, produk multidimensional database yang ditujukan untuk membuat keputusan. Dari definisi di atas, dapat disimpulkan OLAP merupakan suatu metode untuk menyajikan jawaban dari suatu permintaan dari user dimana OLAP bersifat dimensional sehingga aksesnya cepat.
2.1.7. Pengertian Data Warehouse Menurut Connolly & Begg (2005:1150), data warehouse adalah berorientasikan subjek, terpadu, varian waktu dan non volatile dalam pengumpulan data untuk mendukung pembuatan pengambilan keputusan. Menurut Inmon (2005:495), data warehouse merupakan sekumpulan data yang terintegrasi, berorientasikan subjek database yang dirancang untuk mendukung fungsi dari DSS. Dimana setiap unit dari data yang relevan
12 dibeberapa waktu. Data warehouse berisi data atomik dan data ringkasan yang ringan. Menurut Kimball & Ross (2002:423), data warehouse adalah konglomerasi data warehouse dari sebuah organisasi dan area presentasi, dimana data operasional secara khusus disusun untuk kinerja query dan analisis serta kemudahan dalam penggunaan. Sedangkan dalam jurnalnya, menurut Romero & Alberto (2009:2) data warehouse adalah hasil dari homogenisasi dan mengintegrasikan data yang relevan dari organisasi (disimpan dalam sumber data organisasi) dengan tampilan
yang
detail
dan
konsekuen,
dimana
sumber
data
harus
dipertimbangkan sepanjang proses desain. Dari definisi di atas, dapat disimpulkan data warehouse adalah suatu arsitektur yang memiliki karakterisitik berorientasikan subjek, terintegrasi, dimensi waktu dan non volatile yang digunakan dalam mendukung proses pengambilan keputusan.
2.1.8. Karakteristik Data Warehouse Menurut Inmon (2005:29-33), data warehouse memiliki karakteristik sebagai berikut: 1. Subject Orientation Data warehouse berorientasikan subjek artinya sebuah data warehouse dirancang untuk menganalisa data berdasarkan subjek-subjek tertentu seperti pelanggan, barang produk, dan penjualan. Data warehouse berfokus pada model dan analisis pada data untuk membuat keputusan, bukan pada proses ataupun fungsi tertentu.
13 Contoh yang diberikan oleh Inmon (2005:29), “Pada perusahaan asuransi, aplikasi yang berjalan seperti otomotif, bidang kesehatan, dan kecelakaan. Sedangkan subjek utama dari asuransi adalah kebijakan, pelanggan, premi, dan klaim. Pada perusahaan manufaktur, subjek utamanya adalah produk, order, vendor, tagihan material, dan bahan mentah. Untuk perusahaan ritel subjek utamanya adalah produk, SKU (Stock Keeping Unit), penjualan, vendor dan lainnya. Setiap perusahaan memiliki satu set subjek yang unik.”
Gambar 2.1 Contoh Subject Orientation dari Data Warehouse (Inmon, 2005:30) 2. Integrated Integrasi merupakan aspek yang paling penting di dalam data warehouse. Data disuplai dari beberapa sumber yang berbeda ke dalam data warehouse. Data diubah, diformat ulang, disusun kembali, diringkas, dan terintegrasi sehingga data tidak bisa dipecah-pecah karena data yang ada merupakan suatu kesatuan yang menunjang keseluruhan konsep data warehouse. Data yang
14 masuk ke dalam data warehouse dengan berbagai cara dan mempunyai ketidakkonsistenan pada tingkat aplikasi tidak akan dimasukkan. Contoh konsistensi data antara lain adalah penamaan, struktur kunci, ukuran atribut, dan karakteristik data secara fisik. Hasilnya adalah data dalam data warehouse yang mempunyai satu bentuk. Gambar 2.2 di bawah ini akan mengilustrasikan integrasi yang muncul ketika data melewati lingkungan operasional berbasiskan aplikasi ke lingkungan data warehouse.
Gambar 2.2 Contoh dari Integration dari Data Warehouse (Inmon, 2005:31)
3. Non-Volatile Karakteristik ketiga yang terpenting dalam data warehouse adalah nonvolatile. Gambar 2.3 mengambarkan non-volatile dalam suatu data. Dimana menggambarkan operasional data yang diakses dan dimanipulasi pada suatu waktu. Data diperbarui dalam lingkungan operasional sebagai hal biasa, namun data warehouse memiliki karakteristik yang berbeda. Data warehouse di load
15 dan diakses, tetapi tidak di update. Apabila terdapat perubahan maupun pembaruan, maka data lama akan tetap tersimpan. Gambar 2.3 menggambarkan perbedaan antara data operasional dan data warehouse. Dimana data di lingkungan operasional dapat dilakukan perubahan (update), dihapus (delete), dan dimasukkan data baru (insert). Sedangkan data warehouse terjadi proses mass load dan akses data. Sehingga data lama tidak akan tertimpa, yakni tersimpan.
Gambar 2.3 Perbedaan Data di Data Operasional dan Data di Data Warehouse (Inmon, 2005:32)
4. Time-Variant Karakteristik terakhir dalam data warehouse adalah time-variant. Karakteristik ini mengimplikasikan bahwa tiap data dalam data warehouse itu selalu akurat dalam periode tertentu. Dalam satu sisi, sebuah record dalam database memiliki waktu yang telah ditetapkan secara langsung. Di sisi lain, sebuah record mempunyai waktu transaksi. Menurut Inmon (2005:33), dalam varian waktu, bahwa setiap unit di data warehouse dapat dikatakan akurat atau valid pada rentang waktu tertentu. Bisa dengan menggunakan rentang waktu tertentu, seperti 5-10 tahun ke depan, atau
16 dengan menggunakan perbedaan waktu yg disajikan dalam data warehouse seperti, hari, minggu, bulan. Dalam setiap lingkungan baik operasional maupun data warehouse. Memiliki time horizon atau batas waktu. Batas waktu pada data warehouse lebih lama daripada sistem operasional. Karena perbedaan batas waktu tersebut, maka data warehouse mempunyai lebih banyak histori daripada lingkungan lainnya. Gambar 2.4 menjelaskan perbedaan data operasional dan data warehouse dari segi time variant.
Gambar 2.4 Perbedaan time variant antara Data di Data Operasional dan Data di Data Warehouse (Inmon, 2005:32)
2.1.9. Keuntungan Data Warehouse Menurut Connolly & Begg (2010:1198), keberhasilan implementasi data warehouse dapat membawa manfaat besar bagi perusahaan yakni: 1. Potensi tingginya pengembalian investasi Sebuah organisasi harus berkomitmen pada sejumlah besar sumber daya untuk memastikan keberhasilan pelaksanaan sebuah data warehouse dalam biaya yang bervariasi dari £50.000 sampai lebih dari £10 juta. Namun, sebuah studi oleh International Data Corporation (IDC) pada tahun 1996 melaporkan bahwa rata-rata tiga tahun pengembalian atas investasi (ROI)
17 dalam data warehouse mencapai 401%, dengan lebih dari 90% dari perusahaan yang disurvei mencapai lebih dari 40% ROI, setengah perusahaan mencapai lebih dari 160% ROI, dan seperempat dengan lebih dari 600% ROI (IDC, 1996). 2. Keunggulan kompetitif Dengan besar pengembalian atas investasi (ROI) bagi perusahaan yang telah berhasil menerapkan data warehouse adalah bukti keunggulan kompetitif yang sangat besar pada teknologi ini. Keunggulan kompetitif diperoleh dengan memungkinkan pengambil keputusan dapat mengakses data yang dapat memberikan informasi yang sebelumnya tidak tersedia, tidak diketahui, dan belum dimanfaatkan, misalnya pelanggan, tren, dan kebutuhan. 3. Meningkatkan produktifitas pengambil keputusan dalam organisasi Data warehouse dapat meningkatkan produktivitas perusahaan pembuat keputusan dengan menciptakan database yang terintegrasi, konsisten, subject oriented, data historis. Data warehouse mengintegrasikan data dari beberapa sistem yang tidak kompatibel ke dalam satu bentuk yang konsisten dari organisasi. Dengan mengubah data menjadi informasi yang berarti, data warehouse memungkinkan pembuat keputusan untuk melakukan analisis yang lebih substantif, akurat, dan konsisten.
2.1.10. Hubungan dan Perbedaan Sistem OLTP Data Warehouse Menurut Connolly & Begg (2010:1198), sebuah DBMS dibangun untuk Online Transaction Processing (OLTP) umumnya dianggap tidak cocok untuk data warehouse. Hal ini disebabkan karena setiap sistem dirancang memiliki perbedaan persyaratan konsep. Sebagai contoh, sistem OLTP dirancang untuk
18 memaksimalkan kapasitas pemrosesan transaksi, sedangkan data warehouse dirancang untuk mendukung ad hoc pemrosesan query. Tabel 2.1 akan menjelaskan dengan detil perbedaan antara OLTP (Online Transaction Processing) dan data warehouse. Tabel 2.1 Perbedaan sistem OLTP dan Sistem Data Warehouse (Connolly & Begg, 2010:1199).
Karateristik
Sistem OLTP
Tujuan utama Mendukung proses operasional Umur data Saat ini Latensi data Real time
Glanularitas data Proses data
Laporan
Users
Data yang detil Tingkat arus data yang tinggi pada transaksi, pola yang terprediksi dari data insert, updates, delete dan query Terprediksi, satu dimensi, laporan yang tetap dan statis Melayani sejumlah pengguna operasional yang banyak
Sistem Data warehouse Mendukung proses analisa Historikal Tergantung pada panjang siklus untuk suplement data ke data warehouse Data yang detil, ringkasan data yang ringan dan berat. Tingkat arus data yang rendah atau sedang pada transaksi, pola yang tidak terprediksi dari data query-nya. Tidak terprediksi, multidimensional, laporan yang menarik Melayani pengguna managerial yang sedikit
Menurut Connolly & Begg (2010:1199), meskipun OLTP sistem dan gudang data yang memiliki karakteristik yang berbeda dan dibangun dengan tujuan yang berbeda dalam pikiran, sistem ini sangat erat kaitannya dalam sistem OLTP menyediakan sumber data untuk gudang. Masalah utama dari hubungan ini adalah bahwa data yang dimiliki oleh sistem OLTP dapat menjadi tidak konsisten, terfragmentasi, dan dapat berubah, yang mengandung
19 entri duplikat atau hilang. Dengan demikian, data operasional harus 'dibersihkan' sebelum dapat digunakan dalam data warehouse.
2.1.11. Arsitektur Data Warehouse Dalam perancangan data warehouse diperlukan proses, tools, teknologi terkait dengan data warehouse. Arsitektur data warehouse, seperti berikut:
Gambar 2.5 Gambaran Arsitektur Data Warehouse (Connolly & Begg, 2010:1203)
Komponen-komponen yang terdapat di dalam arsitektur data warehouse adalah: 1. Operational Data Sumber-sumber data yang ada di data warehouse disediakan: • Mainframe data operasional ada pada generasi pertama database hierarki dan database jaringan.
20 • Data departemental disimpan di berbagai macam file, seperti: VSAM, RMS dan relational DBMS seperti Informix dan Oracle. • Data pribadi disimpan di dalam workstation dan private server. • Sistem eksternal seperti internet, database komersial, atau database yang berhubungan dengan organisasi dari supplier atau konsumen.
2. Operational Data Store Sebuah operational data store (ODS) adalah sebuah data warehouse dari data operasional dan saling terintegrasi yang digunakan untuk analisis. ODS biasanya melakukan penstrukturan dan penyediaan data seperti halnya sebuah data warehouse, tetapi sebenarnya bertindak secara sederhana sebagai suatu tempat penampungan sementara sebelum data akan dipindahkan ke warehouse. Membangun sebuah operational data store dapat membantu dalam pembangunan sebuah data warehouse, karena ODS menyediakan data yang sudah di ekstrak dari sumber dan sudah di bersihkan. Ini dapat diartikan bahwa pekerjaan yang tersisa untuk mengintegrasikan dan merestrukturisasi data warehouse disederhanakan.
3. Load Manager Load manager atau biasa disebut komponen fronted, melakukan sebuah operasi terkait dengan ekstraksi dan pemuatan data ke dalam warehouse. Data mungkin diekstrak secara langsung dari sumber data atau dari operational data store.
21 Operasi dilakukan oleh manajer, dapat mencakup sebuah transformasi sederhana dari sebuah data, yang bertujuan untuk mempersiapkan data untuk masuk ke dalam warehouse. Ukuran dan kompleksitas komponen ini akan bervariasi antara data warehouse dan dapat dibangun dengan menggunakan kombinasi vendor data loading tools dan custom built program.
4. Warehouse Manager Warehouse manager melakukan semua operasi yang berhubungan dengan
pengelolaan
data
di
dalam
warehouse.
Komponen
dikonstruksikan dengan menggunakan vendor data management custom
built
program.
Operasi–operasi
yang
dilakukan
ini dan
dengan
menggunakan warehouse manager adalah: • Analisis data untuk memastikan konsistensi. • Transformasi dan penggabungan dari sumber data, dari tempat penyimpanan sementara ke dalam tabel di dalam data warehouse. • Membuat indeks-indeks dan view berdasarkan tabel. • Melakukan denormalisasi (jika diperlukan). • Melakukan aggregation (jika diperlukan). • Backup dan archive data.
5. Query Manager Query Manager yang juga disebut komponen back end, melakukan semua opearsi yang berhubungan dengan pengelolaan user queries. Komponen ini dibangun dengan menggunakan vendor user-end data acces
22 tools, data warehouse monitoring, fasilitas database, dan custom built program. Kompleksitas dari query manager ini ditentukan oleh fasilitas yang disediakan oleh end user access tools dan database. Operasi yang dilakukan oleh komponen ini termasuk mengarahkan query ke tabel yang tepat dan penjadwalan eksekusi query. Dalam beberapa kasus, manager query juga mengasilkan profil permintaan untuk memungkinkan manajer warehouse untuk menentukan indeks dan agregasi yang sesuai.
6. Detailed Data Area dari data warehouse ini menyimpan semua detail data di dalam skema database. Kebanyakan kasus yang ada, detail data tidak di simpan secara online, tetapi dibuat melalui agregasi data pada tingkatan detail berikutnya.
7. Lightly dan Highly Summarized Data Area ini menyimpan semua lightly dan highly summarized data yang dihasilkan oleh warehouse manager. Area dari data warehouse ini adalah sebuah tempat untuk menampung sementara sebelum dilakukannya perubahan secara berkelanjutan untuk merespon perubahan profil query. Tujuannya adalah untuk mempercepat pencapaian query. Biaya operasi ini akan meningkat berhubungan dengan proses peringkasan data. Ini dapat diseimbangkan dengan menghapus keperluan secara terus-menerus untuk melakukan operasi ringkasan dalam menjawab query user. Ringkasan
23 data akan terus di-update ketika terdapat data baru yang terisi ke dalam warehouse.
8. Archive / Backup Data Area dari data warehouse ini menyimpan semua detail dan ringkasan data yang bertujuan untuk melakukan archiving dan backup. Meskipun data ringkasan di generate dari detail data, itu memungkinkan untuk backup ringkasan data secara online, jika data ini disimpan melebihi waktu/periode penyimpanan untuk detail data. Data dipindahkan ke penyimpanan archive seperti magnetic tape atau optical drive.
9. Metadata Area dari warehouse ini menyimpan sebuah definisi metadata (data dari data), yang digunakan oleh semua proses didalam warehouse. Tujuan digunakannya metadata adalah untuk: • Ekstraksi dan proses loading metadata digunakan untuk memetakan sumber data ke dalam tampilan yang umum dari data dalam warehouse. • Proses
pengelolaan
warehouse,
metadata
digunakan
untuk
mengotomatisasikan pembuatan tabel ringkasan. • Proses pengelolaan query, metadata digunakan untuk mengarahkan suatu query dengan sumber data yang tepat.
10. End-User Access Tools Tujuan dari data warehousing adalah untuk menghasilkan sebuah informasi untuk bisnis user dalam strategi pembuatan keputusan. Para user
24 ini berhubungan dengan data warehouse menggunakan end-user access tools. Ada lima kategori utama dari end-user access tools: • Reporting and query tools Reporting tools meliputi production reporting tools dan writers. Production reporting tools digunakan untuk menghasilkan laporan operasional regular atau mendukung high-volume batch job,
seperti
pesanan pelanggan/faktur dan pembayaran staf. Report writer adalah dekstop tools yang dirancang untuk end-user. Query tools data warehouse dirancang untuk menerima SQL dalam proses query data yang tersimpan didalam data warehouse. • Application development tools Aplikasi yang sesuai dengan kebutuhan user, yang dirancang secara ramah untuk sisi client server. Beberapa aplikasi terintegrasi dengan OLAP tools dan dapat mengakses semua sistem basis data utama, seperti Oracle, Sybase, Infomix. • Executive information system (EIS) tools. EIS, yang sering disebut sebagai everybody’s information system, yang sebenarnya dibangun untuk mendukung high-level pembuatan keputusan yang stategis. Namun akhirnya meluas dan mendukung semua tingkat manajemen. EIS yang terisolasi dengan mainframe memungkinkan user untuk membuat aplikasi pendukung pengambilan keputusan untuk menyediakan data organisasi dan mengakses ke sumber data eksternal. • Online analytical processing (OLAP) tools OLAP berbasis pada konsep database multidimensi dan memperbolehkan user untuk menganalisis data dengan menggunakan sebuah view yang
25 kompleks dan multidimensional. Tools ini juga didukung oleh multidimensional database (MDDB), atau oleh database relasional yang dirancang untuk mendapatkan multidimensional queries. • Data mining tools Data mining adalah sebuah proses menemukan korelasi, pola dan arah baru yang mempunyai arti dengan mining sejumlah besar data dengan menggunakan teknik statistik, matematika dan artificial intelligence. Data mining memiliki potensi untuk menggantikan kemampuan OLAP tools.
2.1.12. Struktur Data Warehouse Menurut Inmon (2005:34), struktur data warehouse dapat digambarkan seperti pada gambar 2.6.
Gambar 2.6 Struktur pada Data Warehouse (Inmon, 2005:34)
Dimana Inmon (2005:34) menyatakan bahwa terdapat beberapa level detail dalam data warehouse. Level detail dalam data warehouse terdiri dari
26 tingkat older level of detail, current level of detail, level of lightly summarized data, dan level of highly summarized data. Alur data ke dalam data warehouse dimulai dari data operasional. Dimana ketika usia data di data warehouse sudah tua atau lama maka data akan di transfer dari current detail ke older detail. Kemudian data diringkas dan ditransfer dari current detail menuju lightly summarized data, kemudian dari lightly summarized data menuju highly summarized data.
2.1.13. Data Flow dalam Data Warehouse Menurut Connolly & Begg (2005:1161), aliran data atau data flow dalam data
warehouse
berfokus pada lima
pokok yakni, inflow,
upflow,
downflow,outflow, dan metaflow. • Inflow adalah aliran data yang berkaitan dengan ekstrasi, cleansing, dan loading data dari sumber data ke dalam data warehouse. • Upflow adalah aliran data yang berkaitan dengan proses menambah nilai di data warehouse dengan proses meringkas, mengemas, dan mendistribusikan data. • Downflow adalah
aliran data yang berkaitan dengan proses seperti
pengarsipan data dan juga back-up data di data warehouse. • Outflow adalah aliran data yang berkaitan dengan proses seperti membuat data yang disediakan untuk atau akan dipakai oleh end user. • Metaflow adalah proses yang berkaitan dengan pengelolahan metadata.
27
Gambar 2.7 Alur Informasi dari Data Warehouse (Connolly & Begg, 2005:1162)
2.1.14. Fungsional dari Data Warehouse Menurut Elmasri & Navathe (2004:902), data warehouse menyediakan fungsionalitas seperti: •
Roll-up Data diringkas dengan meningkatnya generalisasi. Contoh weekly menjadi quarterly menjadi annually.
•
Drill-down Meningkatkan level dari kerincian. Merupakan kebalikan dari roll-up.
•
Pivot Melakukan metode tabulasi silang.
•
Slice and Dice Melakukan operasi proyeksi pada dimensi.
28 •
Sorting Mengurutkan data sesuai dengan nilai ordinal.
•
Selection Data tersedia dengan jarak dan nilai.
•
Derrived Attributes Atribut dihitung dengan operasi pada nilai-nilai yang disimpan dan diturunkan.
2.1.15. Data Model pada Data Warehouse Menurut Inmon (2005:81-91), ada tiga level dari data model, yakni: high-level modeling (atau disebut juga entity relationship diagram atau ERD), midlevel modeling (atau disebut juga data item set atau DIS), low level modeling (atau disebut juga physical model). 1. High – Level Modeling Tingkat tertinggi dalam model terdiri dari entitas dan hubungan (relationships). Entitas dijelaskan dengan simbol oval. Sedangkan hubungan antar entitas disimbolkan dengan gambar panah. Arah dan jumlah kepala panah menunjukan kardinalitas hubungan. Entitas yang ditampilkan ditingkat ERD memiliki tingkat tertinggi dari abstraksi. Ruang lingkup integrasi (scope of integration) berisi entitasentitas apa saja yang masuk dalam ruang lingkup model. Ruang lingkup integrasi mendefinisikan batas-batas dari model data dan harus ditetapkan sebelum proses pemodelan dimulai. Ruang lingkup telah disepakati oleh pembuat model, manajemen, dan pengguna akhir dari sistem. Jika ruang lingkup tidak ditentukan, ada kemungkinan besar bahwa proses pemodelan
29 akan terus terjadi. Definisi ruang lingkup integrasi harus ditulis lebih dari lima halaman dan dalam bahasa dimengerti untuk pelaku bisnis.
Gambar 2.8 Contoh Entity Relationship Diagram (Inmon, 2005:82)
2. Mid – Level Modeling Setelah tingkat tinggi data model dibuat, tingkat berikutnya adalah mendirikan data model tingkat menengah, atau DIS. Untuk setiap subjek utama, atau entitas, yang diidentifikasi dalam model data tingkat tinggi, model tingkat menengah dibuat. Setiap subjek dikembangkan menjadi model sendiri tingkat menengahnya.
Gambar 2.9 Hubungan ERD dan DIS (Inmon, 2005:85)
30 Empat konstruksi dasar yang ditemukan pada model tingkat menengah: • A primary grouping of data —pengelompokan utama hanya ada satu dan sekali saja untuk setiap area subjek utama. Didalamnya terdapat atribut yang hanya ada sekali untuk setiap area subjek utama. Seperti dengan semua kelompok data, pengelompokan utama berisi atribut dan kunci (key) untuk setiap area subjek utama. • A secondary grouping of data—pengelompokan sekunder memegang atribut data yang bisa ada beberapa kali untuk setiap subjek utama. Pengelompokan ini ditujukan dengan garis yang berasal dari pengelompokan utama. • A connector—ini merupakan simbol hubungan data antara subjek utama. Konektor berkaitan dengan data dari satu keompok ke yang lain. Suatu hubungan diindentifikasikan pada hasil tingkat ERD dalam DIS. • “Type of” data —data ini ditunjukan dengan garis yang mengarah ke kanan dari pengelompokan data. Pengelompokan data ke kiri adalah supertype. Sedangkan ke kanan adalah subtype.
Gambar 2.10 Komponen pada Midlevel Data Model (Inmon, 2005:86)
31 3. Low – Level Modeling (Model Data Fisik) Model data fisik dibuat dari perluasan model data tingkat menengah dengan menambahkan kunci dan karakteristik fisik dari model. Pada poin ini, model data fisik tampak seperti serangkaian tabel, kadang–kadang bisa disebut dengan tabel relasional. Dalam pembuatan data warehouse, langkah pertama yang dilakukan dalam desain ini adalah menentukan glanularity dan juga partisi datanya.
2.1.16. Model Dimensional Data Warehouse Menurut Connolly & Begg (2010:1227), model dimensional merupakan teknik rancangan logikal yang bertujuan untuk menampilkan data dalam bentuk standar dan intuitif yang memperbolehkan akses dengan performa yang tinggi. Model dimensional menggunakan konsep model hubungan antar entity (ER) dengan beberapa batasan yang penting. Menurut Kimball & Ross (2002:399), model dimensional telah terbukti sebagai suatu model yang mudah di mengerti, mudah diprediksi, dapat di perpanjang, dan sangat tahan terhadap serangan ad hoc dari sekelompok komunitas pengguna bisnis karena memiliki sifat yang simetris. Model dimensi biasanya merupakan dasar dari kinerja tambahan DBMS seperti pendekatan powerful indexing dan agregasi. Model dimensi juga menjadi dasar logis untuk semua sistem OLAP. Connolly & Begg (2010:1227), membagi model dimensi menjadi 3 macam, yakni:
32 1. Star Schema Menurut Connolly & Begg (2010:1227), star schema adalah sebuah struktur logis yang memiliki tabel fakta yang berisi data faktual ditengah, dan dikelilingi oleh tabel dimensi yang berisi data referensi (yang dapat di denormalisasi). Hal senada juga dituturkan oleh Inmon (2005:360), struktur star join data disebut demikian karena representasinya berbentuk bintang dengan pusat dan struktur luar oleh beberapa data. Dimana pusat data disebut tabel fakta. Tabel fakta adalah struktur yang berisi kejadian banyak data. Sekitar tabel fakta disebut dimensi yang menggambarkan salah satu aspek penting dari tabel fakta. Menurut Rabuzin dalam jurnalnya (2012:122), sebuah data warehouse merupakan jenis khusus dari database yang tidak dirancang sesuai dengan form normal dan/atau prinsip pemodelan ER(A), namun data yang dikumpulkan dan terintegrasi dari berbagai sumber, diorganisir dalam struktur khusus yang disebut skema bintang (star schema). Dalam star schema beberapa tabel dimensi (dengan banyak atribut yang digunakan untuk menganalisis data) biasanya terhubung ke tabel fakta tunggal yang berisi data numerik yang akan dianalisis. Star Schema dapat digunakan untuk mempercepat performa query dengan melakukan denormalisasi informasi ke dalam tabel dimensi tunggal. Contoh yang diberikan oleh Connolly & Begg (2010:1228), terdapat berbagai macam tabel dimensi (seperti Property ForSale, Branch, ClientBuyer, Staff, dan Owner) berisi data lokasi seperti (city, region, dan country) dimana data tersebut diulang disetiap tabel dimensi.
33
Gambar 2.11 Contoh Star Schema (Connolly & Begg, 2010:1228) 2. Snowflake Schema Menurut Inmon (2005:361), berdasarkan aturan, dalam star join terdapat satu tabel fakta. Tetapi banyak lebih dari 1 tabel fakta dapat dikombinasikan dalam desain database untuk menciptakan struktur komposit/gabungan yang disebut struktur snowflake. Menurut Chandra dalam jurnalnya (2010:589) snowflake merupakan variasi lain dari star schema dimana tabel dimensi dari star schema mengalami normalisasi sehingga dapat diorganisasikan menjadi suatu hirarki. Sedangkan menurut Connolly & Begg (2010:1229), snowflake schema adalah sebuah variasi dari star
schema
dimana
tabel
dimensinya
tidak
berisi
data
yang
didenormalisasi. Dalam snowflake schema, tabel dimensi diperbolehkan untuk mempunyai tabel dimensi. Contohnya “kita dapat menormalisasikan data lokasi seperti atribut city, region, dan country dalam tabel dimensi Branch untuk menciptakan dua buah tabel dimensi baru yang dinamai city dan region. Oleh karena itu, data lokasi pada tabel dimensi seperti
34 PropertyForSale, ClientBuyer, Staff, dan Owner akan dihapus, lalu tabel dimensi baru, city dan region akan digunakan bersama sama oleh tabel tersebut.
Gambar 2.12 Contoh Snowflake Schema (Connolly & Begg, 2010:1229) 3. Starflake Schema Menurut Connolly & Begg (2010:1230), starflake schema adalah sebuah struktur hibrida atau gabungan dari campuran star schema dan snowflake schema. Dan skema database yang paling sesuai adalah skema yang menggunakan campuran skema denormalisasi star dan normalisasi snowflake. Karena kombinasi ini terdapat beberapa dimensi dapat digunakan bersama sama pada kebutuhan yang berbeda.
2.1.17. Perbandingan Model Dimensional dan Model Data Entity Relationship (ER) Menurut Connolly & Begg (2010:1230), model dimensional biasanya digunakan untuk mendesain komponen database dalam data warehouse sedangkan model entity relationship secara tradisional digunakan untuk menggambarkan database pada sistem Online Transaction Processing (OLTP).
35 Model entity relationship (ER) adalah teknik untuk mengidentifikasi hubungan antar entitas. Sasaran utama dari pemodelan ER ini adalah untuk menghilangkan redudansi dari data. Hal ini sangat berguna pada proses transaksi karena dalam transaksi harus dibuat sederhana dan deterministik. Contohnya, transaksi untuk memperbarui alamat client biasanya diakses hanya ke satu tabel dan dengan menggunakan indeks primary key yakni ClientNo. Namun untuk membuat proses transaksi yang efisien dalam database memerlukan tabel yang tidak sedikit. Seperti stok, pelanggan, faktur dan lain– lain. Model ER dapat memiliki ratusan entitas logis dimana dapat memetakan ratusan tabel fisik. Tetapi pemodelan ER tidak mendukung data warehouse yang memerlukan pengambilan data yang intuitif dan performa tinggi. Kunci untuk memahami hubungan antara model dimensional dan model entity-relationship adalah bahwa model ER tunggal biasanya terbagi menjadi beberapa model dimensional. Lalu model dimensional terkait melalui tabel dimensi (shared).
2.1.18. Keuntungan Model Dimensional dalam Data Warehouse Menurut Connolly & Begg (2010:1230), baik menggunakan skema star, snowflake, dan starflake, model dimensional memiliki keuntungan penting dalam lingkungan data warehouse seperti: 1. Efisiensi Dasar struktur database yakni menyediakan akses yang lebih efisien untuk data dengan berbagai tools seperti penulisan laporan dan tools query. 2. Kemampuan untuk menangani kebutuhan perubahan
36 Skema bintang dapat beradaptasi dengan perubahan kebutuhan pengguna, karena semua dimensi memiliki sifat ekuivalen dalam hal menyediakan akses ke tabel fakta. Sehingga desain multidimensional lebih mampu mendukung ad hoc query pengguna. 3. Ekstensibilitas Model dimensi dapat diperluas, misalnya perubahan khas yang harus didukung oleh model dimensional meliputi: • Penambahan tabel-tabel fakta baru, selama tabel tersebut konsisten dengan dasar granularity tabel fakta yang ada, • penambahan dimensi baru, selama ada atribut nilai tunggal dimensi yang ditetapkan untuk setiap record fakta yang ada, • penambahan atribut dimensi baru, dan • memecahkan records dimensi yang ada ke tingkat granularity yang lebih rendah dari dari titik tertentu. 4. Kemampuan untuk model situasi bisnis pada umumya Semakin banyak pendekatan standar untuk menangani situasi pemodelan yang umum dalam dunia bisnis. Masing-masing situasi dipahami dengan baik dengan alternatif yang secara khusus dapat terprogram dalam penulis laporan, alat query, dan user interface lainnya, misalnya, perlahan-lahan merubah dimensi di mana 'konstanta' dimensi seperti branch atau staff benar-benar berkembang secara perlahan dan asynchronously. 5. Predictable query processing Aplikasi data warehouse yang menggunakan metode drill down akan menambahkan atribut tambahan dimensi dari dalam skema bintang tunggal. Aplikasi ini akan menghubungkan tabel fakta yang terpisah bersama-sama
37 melalui dimensi terkait. Meskipun secara keseluruhan skema bintang dalam model dimensi di perusahaan terlihat kompleks, pemrosesan query sangat mudah diprediksi karena terletak pada tingkat terendah, setiap tabel fakta harus di query secara independen.
2.1.19. Metadata dalam Data Warehouse Menurut Inmon (2005:500), metadata adalah data tentang data, deskripsi struktur, konten, kunci (keys), indeks dan lain sebagainya dari data. Menurut Inmon (2005:103), metadata berperan seperti indeks konten dari data warehouse. Metadata melacak (tracking) terhadap apa yang ada di data warehouse. Biasanya, acuan dibuatnya metadata berasal dari: 1. Struktur data yang diketahui programmer, 2. struktur data yang diketahui analis DSS, 3. sumber data dalam data warehouse, 4. transformasi data saat melewati data warehouse, 5. data model, 6. hubungan antara data model dengan data warehouse, dan 7. sejarah dari proses ekstraksi.
2.1.20. Granularity dalam Data Warehouse Menurut Inmon (2005:41), sebuah granularity merujuk pada level detail atau ringkasan dari suatu unit data di dalam data warehouse. Semakin detail data tersebut, maka akan semakin rendah level dari granularity-nya, sebaliknya apabila detail data nya rendah, maka level granularity-nya akan semakin tinggi. Contohnya, sebuah transaksi yang simpel akan ada pada level
38 granularity yang rendah. Ringkasan dari semua transaksi dalam waktu sebulan akan berada pada level granularity yang tinggi. Hal senada juga dituturkan oleh Connolly & Begg (2010:649), granularity adalah ukuran dari item data sebagai sebuah unit of protection dari concurrency control protocol. Inmon (2005:41), menambahkan granularity adalah masalah yang paling penting dalam lingkungan data warehouse, karena sangat berpengaruh pada volume data yang berada di dalam data warehouse dan jenis query-nya. Volume data dalam data warehouse dibandingkan dengan tingkat detail dari query. Tingkat yang lebih rendah dari granularity dan lebih fleksibel maka query dapat dikeluarkan. Semakin tinggi tingkat granularity, permasalahan dapat dikurangi.
2.1.21. Tipe–Tipe Data Warehouse Menurut Inmon (2005:193), data warehouse terbagi menjadi 2 macam, yakni : 1. Data Warehouse Terpusat Menurut Inmon (2005:193), banyak organisasi membangun dan memelihara lingkungan data warehouse yang terpusat. Hal ini disebabkan karena: •
Data pada data warehouse mengintegrasi perusahaan dan gambaran terintegrasi digunakan hanya pada kantor pusat.
•
Perusahaan menjalankan sebuah model bisnis yang terpusat.
•
Volume data dalam data warehouse seperti sebuah penyimpanan tunggal yang terpusat.
39 •
Sekalipun data dapat diintegrasikan, lokal data diedarkan melalui banyak local sites, maka akan mempersulit pengaksesan.
2. Data Warehouse Terdistribusi Menurut Inmon (2005:193), ada tiga jenis data warehouse terdistribusi, yakni: • Bisnis didistribusikan secara geografis dan lini produk yang berbeda. Dalam kasus ini, kita mengenal data warehouse lokal dan data warehouse global. Data warehouse lokal menjelaskan data dan proses di situs remote, dan data warehouse global merupakan bagian dari bisnis yang terintegrasi di seluruh bisnis. • Lingkungan data warehouse akan memegang banyak data lalu volume data tersebut akan didistribusikan ke beberapa prosesor. Logikanya ada satu data warehouse tunggal, tetapi secara fisik ada banyak data warehouse yang semuanya terkait tetapi berada pada prosesor yang terpisah. Konfigurasi ini dapat disebut teknologi data warehouse terdistribusi. • Pertumbuhan lingkungan data warehouse terjadi dengan tidak terkordinasi. Kurangnya koordinasi pada pertumbuhan data warehouse biasanya terjadi akibat perbedaan politik dan organisasi. Kasus ini bisa disebut perkembangan secara independen sebuah data warehouse terdistribusi.
2.1.22. Business Dimensional Lifecycle Road Map Menurut Kimball & Ross (2010:96), pendekatan siklus hidup Kimball merupakan pendekatan dalam membangun data warehouse. Diagram ini merupakan suatu pedoman atau jalan yang menggambarkan urutan tugas yang
40 dibutuhkan untuk menciptakan desain, pengembangan, dan implementasi yang efektif.
Gambar 2.13 The Kimball Lifecycle diagram (Kimball & Ross, 2010:97)
Kimball & Ross (2010:96) membagi urutan tugas tersebut menjadi 6 langkah, yakni: 1. Program/Project Planning and Management Menurut Kimball & Ross (2010:98), kotak pertama pada roadmap yang berfokus untuk mendapatkan program/proyek yang diluncurkan, termasuk scoping, justification, dan staffing. Sepanjang siklus hidup (Lifecycle) tersebut, program yang sedang berjalan dan tugas manajemen proyek tetap di jalur kegiatan. Menurut Kimball & Ross (2002:334) di buku lain menambahkan, perencanaan proyek dapat terbagi menjadi 5 tugas, yakni: 1.1 Assessing Readiness Tahap ini dilakukan sebelum melakukan investasi pada data warehouse dimana dilakukan analisa untuk menilai kesiapan organisasi
41 dalam membangun sebuah data warehouse. Kimball & Ross (2002:334) mengatakan terdapat 5 indikator sebuah keberhasilan data warehouse, yakni: • Sebuah data warehouse harus memiliki sponsor bisnis yang kuat. • Sebuah data warehouse harus mempunyai motivasi kuat dan menarik dalam membangun data warehouse. • Menilai suatu kesiapan layak atau tidak. • Keseimbangan hubungan diantara bisnis dan IT. • Budaya analisis dalam suatu perusahaan. Apakah analisis tersebut dibuat berdasarkan fakta dan angka atau hanya secara perasaan atau intuisi, bukti anekdot. 1.2 Scoping Penetapan ruang lingkup dalam data warehouse harus membutuhkan gabungan dari organisasi IT dan juga manajemen bisnisnya. Dimana ruang lingkup dari data warehouse harus memberikan nilai bagi organisasi dan dapat dikelola. 1.3 Justification Pembenaran ini dimaksudkan adalah sebuah pembenaran dalam melakukan kesiapan serta scoping dalam perencanaan estimasi manfaat dan biaya data warehouse. Dimana IT biasanya yang bertanggung jawab dalam menurunkan biaya dengan memperkirakan perangkat keras dan lunak yang dibutuhkan. Perlu diketahui data warehouse berkembang dengan pesat, jadi harus memastikan estimasi perkembangan jangka pendek.
42 1.4 Staffing Data warehouse membutuhkan integrasi dari tim yang mendukung antara melakukan bisnis dan IT. Pemilihan sumber daya dalam penugasan bergantung pada besarnya proyek, ruang lingkup, serta ketersediaan individu, kemampuan dan pengalaman. Dari sisi bisnis, usaha yang akan dilakukan adalah: usaha sponsor, kepemimpinan, bisnis pengguna. Straddlers ini didapatkan dari sumber daya teknis yang memahami sumber daya bisnis atau bisnis yang mengerti teknologi: bisnis analis sistem, pakar bisnis materi pelajaran, analitik pengembang aplikasi, data-data gudang. 1.5 Developing and Maintaining the Project Plan Mengembangkan sebuah project data warehouse harus melibatkan semua tugas untuk mengimplementasikan data warehouse. Proyek data warehouse menuntuk komunikasi yang luas. Selama fase perencanaan proyek, disarankan seorang manajer proyek untuk membentuk matrik komunikasi untuk menggambarkan dan membantu memastikan bahwa strategi komunikasi dijalankan.
2. Business Requirements Menurut Kimball & Ross (2010:98), memunculkan kebutuhan bisnis adalah tugas kunci dalam lifecycle Kimball karena temuan ini mendorong keputusan yang paling upstream dan downstream. Persyaratan dikumpulkan untuk menentukan faktor-faktor kunci yang berdampak bisnis dengan berfokus pada apa yang pengguna bisnis lakukan hari ini (atau ingin dilakukan di masa depan), daripada meminta "apa yang Anda inginkan dalam
data
warehouse?".
Peluang
utama
di
seluruh
perusahaan
43 diidentifikasi, diprioritaskan berdasarkan nilai bisnis dan kelayakan, dan kemudian persyaratan yang rinci berkumpul untuk iterasi pertama dari DW/pengembangan sistem BI. Menurut Kimball & Ross (2002:342) di buku lain menambahkan, business requirement dapat terbagi menjadi 3 tugas, yakni: 2.1 Requirements Preplanning Sebelum mengumpulkan kebutuhan pengguna bisnis, sebaiknya dilakukan langkah-langkah persiapan sebagai berikut: 1. Choose the Forum Persyaratan dikumpulkan pada saat pertemuan dengan perwakilan pengguna bisnis sementara dan pada saat diskusi dengan narasumber dan ahli materi pelajaran. Pendekatan dual-cabang memberi kita wawasan tentang kebutuhan bisnis dalam hubungannya dengan realitas data. 2. Identify and Prepare the Requirements Team Mengidentifikasikan dan menyiapkan anggota dari tim proyek yang terlibat. 3. Select, Schedule, and Prepare Business Representative Penjadwalan perwakilan bisnis dapat menjadi tugas persyaratan yang paling berat. Anda harus berbicara dengan pengusaha yang mewakili wawasan horisontal di seluruh organisasi.
2.2 Collecting the Business Requirements 1. Launch Penetapan apa yang ingin disampaikan saat melakukan wawancara, dan harus fokus pada tujuan proyek.
44 2. Interview Flow Tujuan dari wawancara adalah untuk mendapatkan pengguna bisnis untuk berbicara tentang apa yang mereka lakukan dan mengapa mereka melakukannya. Kami meminta masing-masing diwawancarai tentang dampak peningkatan akses ke informasi. 3. Wrap-Up Menarik kesimpulan dari tiap individu tentang kriteria keberhasilan untuk melakukan proyek. 4. Conducting Data-Centric Interviews Tujuannya untuk menilai bahwa data inti yang diperlukan sudah ada. Sebuah data yang lengkap akan terjadi selama proses permodelan dimensi. 2.3 Postcollection Documentation and Follow-Up Mendokumentasikan apa yang didengar, ada 2 tingkatan dari dokumentasi, menulis setiap wawancara individu dan mencari dokumen. 1. Prioritization and Consensus Dokumen apa yang anda dengar. Ada dua tingkat dokumentasi yang biasanya hasil dari proses persyaratan. • Yang pertama adalah untuk menulis setiap wawancara individu. • Tingkat kedua dari dokumentasi adalah dokumen temuan konsolidasi.
3. Technology Track Menurut Kimball & Ross (2010:98), lingkungan DW (data warehouse)/BI mewajibkan integrasi dari berbagai teknologi, data stores, dan metadata yang terkait. Trek teknologi dimulai dengan desain sistem
45 arsitektur untuk membuat shopping list dari kemampuan yang dibutuhkan, dilanjutkan dengan pemilihan dan pemasangan produk yang memenuhi kebutuhan-kebutuhan arsitektur. Menurut Kimball & Ross (2002:347) di buku lain menambahkan, technology track dapat terbagi menjadi 2 tugas, yakni: 3.1 Technical Architecture Design Eight-Step Process for Creating the Technical Architecture: 1. Establish an Architecture Task Force Membuat sebuah small task pada desain arsitektur, biasanya antara arsitek teknis dengan data staging designer
dan developer aplikasi
analitik. 2. Collect Architecture-Related Requirements Arsitekur dibuat untuk mendukung kebutuhan nilai bisnis yang tinggi. Yang menjadi fokus utama adalah untuk mengungkap implikasi arsitektur yang berhubungan dengan kebutuhan kritis bisnis. Untuk meningkatkan kebutuhan bisnis proses definisi, melakukan wawancara tambahan dalam organisasi TI. 3. Document Architecture Requirements Mendokumentasikan hasil dari pengumpulan requirements. 4. Develop a High-Legel Architectural Model Merumuskan
model
untuk
mendukung
kebutuhkan
identifikasi.
Kebutuhan penting dalam arsitektur model seperti data staging, data access, metadata, dan infrastruktur. 5. Design and Specify the Subsystems Mendesain secara spesifik sebuah subsistem.
46 6. Determine Architecture Implementation Phases Menyediakan
elemen
arsiktetur
yang
cukup
untuk
mendukung
mebutuhan kebutuhan end-to-end dari iterasi awal proyek. 7. Document the Technical Architecture Mendokumentasikan
arsitektur
teknis,
termasuk
semua
tahapan
pelaksanaan yang direncanakan. Dokumen rencana teknis arsitektur harus mencakup detail yang memadai sehingga profesional terampil dapat dilanjutkan dengan pembangunan kerangka. 8. Review and Finalize the Technical Architecture Rencana arsitektur harus dikomunikasikan, untuk tim proyek, rekan IT, sponsor bisnis. 3.2 Product Selection and Installation Memilih produk yang sesuai dengan rencana untuk memberikan fungsi yang diperlukan. Seperti: • Memahami proses pembelian perusahaan • Mengembangkan metrik evaluasi produk • Melakukan riset pasar • Pilihan sempit ke daftar pendek dan melakukan evaluasi rinci • Melakukan prototipe, jika perlu • Pilih produk, instalasi, dan bernegosiasi
4. Data Track Menurut Kimball & Ross (2010:98), data track dimulai dengan desain model target dimensi untuk menangani kebutuhan bisnis, dengan tetap memperhatikan realitas data yang mendasarinya. Model dimensi dikonversi
47 menjadi desain fisik di mana kinerja strategi tuning dipertimbangkan, kemudian di-extract, transform, dan load (ETL) sistem desain dan tantangan development yang ditangani. Menurut Kimball & Ross (2002:347) di buku lain menambahkan, technology track dapat terbagi menjadi 3 tugas, yakni: 4.1 Dimensional Modeling Dalam membangun model dimensional, Kimball & Ross (2010:210), melakukan pendekatan yang disebut “Nine–Step Methodology”, yakni: 1. Choose the process / memilih proses Menentukan konten yang berhubungan dengan aktifitas operasional. Dimana proses bisnis subyek area penting yang harus dibuat pertama kali. Suatu proses yang dipilih harus sejajar antara pertanyaan bisnis yang penting dengan kemudahan mengakses dari ekstraksi data. 2. Choose the grain / memilih grain Memilih grain berarti menentukan dengan baik apa yang menjadi fakta dalam tabel yang direpresentasikan. Setelah itu maka dapat menentukan tabel-tabel dimensi yang berhubungan dengan tabel fakta tersebut.
3. Identify
and
conform
the
dimensions/mendefinisikan
dan
menyesuaikan dimensi Dimensi merupakan sumber dari query constraints dan row header dari suatu laporan. Mereka membawa kamus perusahaan kepada user. Sebuah set arsitektur yang baik dari dimensi membuat sebuah model menjadi lebih mudah dipahami dan mudah digunakan. 4. Choose the facts / menentukan tabel fakta
48 Grain dari tabel fakta dapat menentukan fakta-fakta yang dapat digunakan dalam data mart. Semua fakta harus diekspresikan sesuai dengan level tingkatan pada grain. Untuk memilih fakta perlu diketahui informasi apa saja yang dibutuhkan oleh pengguna dalam kaitannya dengan proses bisnis. 5. Store precalculations in the fact table / menyimpan prekalkukasi dalam tabel fakta Setelah fakta telah dipilih, maka masing-masing dari fakta tersebut harus dikaji ulang atau diuji kembali untuk menentukan apakah ada peluang untuk melakukan pre-kalkulasi. Fakta hasil dari kalkulasi sebaiknya disimpan dalam tabel fakta, karena ini dapat meningkatkan performansi dalam memberikan hasil query. 6. Round out the dimension tables / melengkapi tabel dimensi Dalam step ini, kita kembali ke tabel dimensi dan menambahkan deskripsi informasi pada tabel dimensi. Informasi tersebut harus intuitif dan dapat dipahami oleh para pengguna. 7. Choose the duration of the database / memilih durasi dari database Mengukur dan menentukan durasi data yang akan dimasukkan ke dalam data warehouse sesuai dengan kebutuhan perusahaan. Karena tabel fakta yang sangat besar dapat meningkatkan masalah yang ada di dalam data warehouse. Hal ini harus dilakukan supaya data yang akan dianalisis dapat dengan cepat dan sesuai dengan waktu yang ditentukan yang ada di dalam data warehouse.
49 8. Determine the need to track slowly changing dimensions / melacak perubahan dimensi secara perlahan Kimball & Ross (2010:25) menyatakan, selama 30 tahun lebih Kimball menemukan 3 alasan dasar kenapa data warehouse berubah, yang ia sebut menjadi type 1, 2, dan 3, yakni: • Type 1 – Atribut pada dimensi yang di ganti (overwrite). • Type 2 – Atribut pada dimensi berubah, sehingga menyebabkan adanya record baru didalam dimensi (add new dimension record). • Type 3 - Atribut pada dimensi berubah, menyebabkan atribut alternatif yang akan dibuat secara simultan akan diakses secara bersamaan dalam sebuah dimensi yang sama (add a new field). 9. Decide the physical design / memilih desain fisik. Pada step, sebuah desain logis telah selesai dibuat. Kemudian menganalisis isu-isu yang akan terjadi pada saat membangun model desain fisik. 4.2 Physical Design Model dimensi yang dikembangkan pada bagian sebelumnya perlu diterjemahkan ke dalam desain fisik. Dalam pemodelan dimensi, desain secara fisik dan logis memiliki kemiripan yang sangat dekat. Model fisik akan berbeda dari model logis dalam hal rincian tertentu untuk database fisik, termasuk nama kolom fisik, tipe data, deklarasi kunci. • Aggregation Strategy Pertama memikirkan tentang pola akses pengguna bisnis, kedua menilai distribusi dari statistik data.
50 • Initial Indexing Strategy Dimensi tabel akan memiliki indeks yang unik pada primary key tunggalkolom. Kunci utama dari tabel fakta hampir selalu merupakan subset dari kunci asing. Biasanya menempatkan indeks tunggal digabungkan pada dimensi primer dari tabel fakta. Selain itu, setelah tombol tanggal di posisi pertama mempercepat proses loading data dimana data incremental berkelompok menurut tanggal. Tabel fakta besar biasanya yang dipartisi menurut tanggal, dengan data tersegmentasi berdasarkan bulan, kwartal, atau tahun ke partisi terpisah penyimpanan sementara yang muncul kepada user, karena sebuah tabel tunggal. Keuntungan dari partisi menurut tanggal adalah: • Query akan tampil lebih baik karena mereka hanya mengakses partisi yang diperlukan untuk menyelesaikan query. • Partisi juga dapat diarsipkan dengan mudah. 4.3 Data Staging Design and Development Pada tahap data staging and development terdapat proses ETL. Dimana dalam jurnalnya, menurut Halenar (2012:2) arsitektur ETL umumnya merupakan sebuah data warehouse yang real time, yang terdiri dari berbagai tipe sumber database termasuk alat ekstraksi, yang mendorong data diekstraksi ke temporary store. Kemudian mempersiapkan data untuk proses transformasi menjadi fungsi transformasi sehingga data siap digunakan dengan format yang sesuai. Transformasi berjalan dalam DPA (data processing area) dimana data diubah dan dibersihkan dan setelah itu data diekspor oleh fungsi transformasi.
51 Proses ETL menurut Darudiato (2008:62), data dari basis data operasional
dan
sumber
eksternal
diekstrak,
kemudian
untuk
meminimalisasi eror data tersebut dibersihkan dan mengisi informasi yang kurang jika dimungkinkan. Setelah itu ditransformasi untuk memperbaiki ketidak-cocokan
semantik.
Proses
loading
data
terdiri
dari
mematerialisasikan view dan menyimpannya dalam warehouse. • Dimension Table Staging Karena dimensi harus sesuai dan dapat digunakan kembali di seluruh model dimensi, biasanya hal itu adalah tanggung jawab otoritas lebih terpusat. Kewenangan dimensi bertanggung jawab untuk mendefinisikan, menjaga, dan penerbitan dimensi tertentu untuk mart data yang sesuai. Dimensi dapat diproses secara bersamaan. Namun, semua dimensi yang terlibat dalam skema harus dipublikasikan sebelum pementasan data fakta. Langkah-langkahnya: mengesktrak data dari sumber dimensi operasional, lalu membersihkan nilai-nilai atribut yang tidak konsisten, tidak valid, dan data yang hilang. Dan mengelola surrogate key. Lalu membangun sebuah dimensi dari data yang sudah direvisi. • Fact Table Staging Mengekstrak data, memperbarui, memisahkan data fakta, mengubah data, mengganti key dengan surrogate key, menambahkan key tambahan, membangun tabel agregasi, bulk data, alert user.
52 5. Business Intelligence Track Menurut Kimball & Ross (2010:98), ketika beberapa anggota proyek tenggelam dalam teknologi dan data, yang lain fokus pada mengidentifikasi dan membangun berbagai aplikasi BI, termasuk laporan standar, query parameter, dashboard, scorecard, model analitik, dan aplikasi data mining, bersama dengan interface navigasi yang terkait. Menurut Kimball & Ross (2002:362) di buku lain menambahkan, business intelligence track dapat terbagi menjadi 2 tugas, yakni: • Analytic Application Spesification Sebelum merancang aplikasi maka harus menetapkan standar dari aplikasi tersebut, seperti tampilan menu dan tampilan output yang konsisten. Menggunakan standar, kita tentukan setiap template aplikasi, menangkap informasi yang memadai tentang tata letak, variabel input, perhitungan, dan istirahat sehingga baik pengembang aplikasi dan perwakilan bisnis berbagi pemahaman yang sama. Selama kegiatan spesifikasi aplikasi, kita juga harus memberikan pertimbangan kepada organisasi aplikasi. Kita perlu mengidentifikasi jalur navigasi terstruktur untuk mengakses aplikasi, yang mencerminkan pengguna cara berpikir kita tentang bisnis mereka. • Analytic Application Development Pengembangan aplikasi dapat dimulai setelah desain database telah selesai, kegiatan ini tidak dapat diselesaikan sampai data stabil.
53 6. Deployment, Maintetance, and Growth Iterasi deployed memasuki fase maintenance, sementara pertumbuhan (growth) menunjukkan dengan arrow back ke perencanaan proyek untuk iterasi berikutnya dari data warehouse. Pada fase maintenance and growth tim proyek memfokuskan
pada persyaratan yang akan dihadapi,
penyampaian yang signifikan dan / atau risiko dalam usaha penerapan. Oleh karena itu dilakukan support, education, technical support dan program support.
2.1.23. Activity Diagram Untuk penggambaran proses bisnis menggunakan acitivy diagram. Dijelaskan oleh Satzinger, et al (2005:147), activity diagram adalah tipe dari work flow diagram yang menjabarkan aktivitas-aktivitas dari pengguna (user) dan alurnya secara berurutan. Dimana workflow adalah langkah-langkah untuk memproses transaksi bisnis secara berurutan. Berikut ini simbol-simbol yang digunakan dalam activity diagram: Tabel 2.2 Simbol-Simbol pada Activity Diagram NO
GAMBAR
NAMA
KETERANGAN Memperlihatkan bagaimana masing-
1
Activity
masing
kelas
antarmuka
saling
berinteraksi satu sama lain
2
Action
3
Initial Node
State dari sistem yang mencerminkan eksekusi dari suatu aksi Bagaimana diawali
objek
dibentuk
atau
54 4
Activity
Bagaimana
Final Node
dihancurkan
Fork Node
5
objek
dibentuk
dan
Satu aliran yang pada tahap tertentu berubah menjadi beberapa aliran Hubungan dimana perubahan yang terjadi pada suatu elemen mandiri
Dependency (independent)
6
akan
mempegaruhi
elemen yang bergantung padanya elemen yang tidak mandiri
Gambar 2.14 Contoh Activity Diagram yang Digambarkan oleh Satzinger, et al (2005:147)
2.1.24. Back-up Dalam diktat Advanced Database yang dibuat oleh Software Laboratory Center Bina Nusantara University (2012:43) dikatakan bahwa back-up adalah salinan dari sebuah data yang digunakan untuk men-restore dan recover data setelah terjadi kesalahan dalam sistem. Berikut ini jenis–jenis metode back-up:
55 •
Full Sebuah back-up lengkap yang berisi semua data dalam database tertentu atau set filegroups atau file, dan juga log yang memungkinkan untuk di-restore.
•
Differential Sebuah back-up dari semua file dalam database. Back-up ini hanya berisi data tambahan yang dimodifikasi dari back-up database yang paling terbaru dari setiap file.
•
Partial Back-up ini dirancang untuk memberikan fleksibilitas yang lebih untuk membuat back-up database yang mengandung beberapa filegroups read-only dengan model restore yang sederhana.
•
File Hanya mem-back-up beberapa file saja, tidak keseluruhan database.
•
Transaction Log Hanya mem-back-up modifikasi yang dibuat pada database.
•
Copy Only Biasanya, mengambil perubahan back-up database dan mempengaruhi saat di-restore.
2.1.25. Security Untuk memastikan dan menjaga keamanan data warehouse dari jangkauan orang yang tidak berwenang menggunakanannya diperlukan proses autentifikasi dan pembagian mengenai hak pengaksesan data (otoritas). Dikatakan oleh Conolly & Begg (2005:547) autentifikasi adalah sebuah
56 mekanisme yang menentukan apakah seorang pengguna merupakan yang pihak sah untuk mengkalim kepemilikan account. Sedangkan masih menurut Conolly & Begg (2005:546) otorisasi adalah pemberian hak atau hak istimewa yang memungkinkan subjek untuk memiliki akses yang sah ke sistem atau objek suatu sistem.
2.1.26. Analisis Kapasitas Media Penyimpanan Salah satu aspek penting dalam pengolahan data yang perlu dipertimbangkan adalah media penyimpanan. Pertumbuhan data baik dalam database ataupun data warehouse dipengaruhi oleh transaksi sehari-hari yang terjadi pada OLTP. Agar media penyimpanan dapat menampung pertumbuhan data yang terus-menerus meningkat maka diperlukan analisis kapasitas media penyimpanan. Rumus
yang
akan
digunakan
untuk
perhitungan
kebutuhan
penyimpanan record dalam SQL Server 2008 yang dijelaskan dalam situs resmi Microsoft (MSDN) adalah sebagai berikut: 1. Num_Row = jumlah baris / jumlah record. 2. Num_Col = jumlah kolom dalam tabel. 3. Fixed_Data_Size = jumlah bytes yang dibutuhkan oleh semua kolom yang mempunyai tipe data dengan ukuran yang pasti. 4. Num_Variable_Cols = jumlah kolom yang mempunyai tipe data dengan ukuran tidak pasti, seperti varchar, nvarchar, varbinary. 5. Max_Var_Size = ukuran bytes terbesar dari semua kolom yang mempunyai tipe data dengan ukuran tidak pasti. 6. Null_Bitmap = bit status null kolom = 2 + ((num_col+7)/8).
57 7. Variable_Data_Size = jumlah bytes yang dibutuhkan untuk semua kolom variabel = 2 + (num_variable_cols x 2) + max_var_size. 8. Row_Size = fixed_data_size + null_bitmap + 4. 9. Rows_Per_Page = 8096 / (row_size + 2). 10. Num_Of_Pages = num_row / rows_per_page. 11. Heap_Size (Bytes) = 8192 x num_of_pages. 12. Heap_Size (Kbytes) = num_of_bytes / 1024. 13. Heap_Size (Mbytes) = num_of_kbytes / 1024. Analisis kapasitas media penyimpanan pada data warehouse untuk perhitungan fakta adalah sebagai berikut: Rn = R x (n + (1+ i ) n ) Keterangan : n = Tahun keR = Jumlah record I = Presentase pertumbuhan record per tahun Perhitungan untuk dimensi yang mengalami pertumbuhan data adalah sebagai berikut: Rn = R x (1+ i ) n Keterangan : n = Tahun keR = Jumlah record I = Presentase pertumbuhan record per tahun 2.1.27
Apakah real time data warehousing dilakukan dalam data warehouse? Menurut Inmon (2005:487) mengatakan real time pada data
warehouse paling baik dilakukan di lingkungan Operation Data Store. Secara
58 fisik data operasional terpisah dari lingkungan data warehouse. Meskipun data warehouse dapat dilakukan secara real time, namun data yang berada di data warehouse hanya berupa data operasional yang memiliki periode yang lambat setiap harinya. Pembuatan proses real time diluar data warehouse adalah strategi yang salah. Dalam artikelnya Becker (2009:4) menjelaskan dalam menentukan lama proses ETL perlu dilakukan wawancara dengan pengguna bisnis (business user) seberapa real time data yang mereka inginkan. Terdapat 3 kategori real time, yakni: 1. Instantaneous (instan) berarti data yang terlihat di layar pengguna akhir mewakili keadaan sebenarnya dari data operasional. Setiap perubahan yang terjadi pada data operasional akan langsung direspon oleh data warehouse. 2. Frequently (sering) berarti data yang terlihat di layar pengguna akhir diperbarui berkali-kali setiap harinya. Namun tidak menjamin data yang ada pada saat ini real time. 3. Daily (harian) berarti data yang terlihat di layar pengguna akhir berlaku pada rekonsiliasi dari data operasional pada suatu periode (harian, mingguan, bulanan). 2.1.28
Fact Finding Menurut Connoly & Begg (2005:317), ada beberapa teknik dalam
melakukan fact finding, yaitu : •
Examining documentation Biasanya berguna ketika ingin mencoba untuk melihat apa yang dibutuhkan sebuah database. Dan juga harus mencari dokumen yang
59 berhubungan dengan masalah, jadi dengan adanya
examining
documentation kita dapat mempercepat mengenai pemahaman sistem. •
Interviewing Merupakan metode yang paling sering digunakan dan paling berguna karena dapat melakukan wawancara dengan setiap individu. Dimana dalam wawancara membutuhkan skill komunikasi yang bagus untuk dapat berjalan efektif.
•
Observing the Enterprise in Operation Observasi merupakan teknik yang paling efektif untuk memahami sebuah sistem. Teknik ini biasanya berguna ketika ada sebuah data yang valid dan penjelasan yang baik dari end user. Untuk menentukan observasi berjalan dengan sukses kita harus mengetahui individu dan aktivitas yang akan kita observasi.
•
Research Merupakan sebuah teknik yang berguna untuk melakukan penelitian mengenai aplikasi. Jurnal, referensi buku dan internet merupakan sumber informasi yang baik. Dimana dari sumber informasi tersebut dapat digunakan sebagai landasan dalam menyelesaikan beberapa masalah.
•
Questionnaires Merupakan sebuah dokumen yang digunakan dalam mengumpulkan fakta dari banyak orang. Ketika kita akan menghadapi pengumpulan data dengan menggunakan banyak orang maka tidak ada teknik seefisien teknik kuisioner.
60 2.2. Teori – teori Khusus 2.2.1. Ritel Menurut Pujawan (2005:137), perusahaan ritel adalah mendapatkan barang–barang (merchandise) yang akan mereka jual (resale). Menurut Kotler
& Amstrong (2010:394), retailing adalah semua
kegiatan yang terlibat dalam menjual barang atau jasa langsung kepada konsumen akhir untuk penggunaan akhir mereka, bukan digunakan untuk bisnis. 2.2.2. Persediaan Barang Menurut Render & Heizer (2001: 314), perusahaan mempertahankan 4 jenis persediaan, yaitu: • Persediaan barang mentah, yaitu barang yang telah dibeli namun belum diproses. • Persediaan barang-dalam-proses, yaitu barang yang telah mengalami beberapa perubahan, tetapi belum selesai. WIP (Work in Process) ini ada karena untuk membuat produk diperlukan waktu (disebut waktu siklus). Pengurangan waktu siklus menyebabkan persediaan WIP pun berkurang. • Persediaan MRO (perlengkapan pemeliharaan/perbaikan/ operasi). MRO merupakan
persediaan
yang
dikhususkan
untuk
perlengkapan
pemeliharaan/perbaikan/operasi. MRO ini ada karena waktu dan kebutuhan untuk pemeliharaan dan perbaikan dari beberapa peralatan tidak dapat diketahui. • Persediaan barang jadi, yaitu barang yang telah selesai dan menunggu untuk dikirimkan. Barang jadi dimasukkan ke dalam persediaan karena permintaan konsumen untuk jangka waktu tertentu mungkin tidak diketahui.
61 Menurut Pujawan (2005:99), mengelola aliran materi atau produk yang tepat berarti tidak terlalu terlambat dan tidak terlalu dini, jumlahnya sesuai dengan kebutuhan, dan terkirim ke tempat yang memang membutuhkan. Kesalahan dalam meramalkan kebutuhan pelanggan, seperti memproduksi terlau banyak atau terlalu sedikit (volume errror) atau memproduksi jenis barang yang salah (mix error). Kedua–duanya menimbulkan masalah persediaan. Inti dari persediaan adalah kordinasi dan kolaborasi. 2.2.3. Pembelian Barang Menurut Render & Heizer (2001: 414), pembelian berarti perolehan barang dan jasa. Dimana tujuan dari kegiatan pembelian itu sendiri adalah: • Membantu identifikasi produk dan jasa yang dapat diperoleh secara eksternal. • Mengembangkan, mengevaluasi, dan menentukan pemasok, harga dan pengiriman yang terbaik bagi barang dan jasa tersebut. Dijelaskan dalam buku Pengantar Bisnis karya Ebert & Griffin (2006:400), pembelian adalah akuisisi bahan dan jasa yang dibutuhkan perusahaan untuk menghasilkan produknya. Menurut Pujawan (2005:141), proses pembelian bisa dilakukan melalui proses pembelian rutin atau pembelian tender. Dimana proses pembelian rutin biasanya berlaku untuk item-item yang supplier-nya sudah jelas karena ada kesepakatan jangka panjang antara supplier dengan perusahaan. Sedangkan proses tender (atau lelang) dilakukan untuk item yang supplier-nya masih harus dipilih. Pada proses bisnis PT. Central Network Indonesia, pembelian bahan kain dilakukan melalui proses pembelian tender dimana terjadi pemilihan bahan kain sesuai kebutuhan.
62 2.2.4. Penjualan Barang Menurut Yunarto (2006:78), penjualan konsinyasi atau penjualan titipan, perusahaan akan menjual barang ke customer-nya tetapi statusnya titip. Yang dimakud customer dari perusahaan ini adalah toko, distributor lain, departement store, supermarket, dan lain-lain. Perlu dicermati bahwa status barang yang dititipkan ke toko masih menjadi milik perusahaan, walaupun secara fisik barang tidak berada di dalam perusahaan. 2.2.5. Retur Barang Menurut Stevenson (2011: 537) dalam hal managing return, produk dikembalikan kepada perusahaan atau pengendali pihak ketiga untuk berbagai alasan, dan dalam berbagai kondisi. Alasan atau kondisinya adalah sebagai berikut: • Produk rusak • Produk recalled • Produk yang tidak berlaku lagi • Produk yang tidak terjual • Bagian diganti di lapangan • Barang untuk daur ulang • Limbah
