BAB 2 LANDASAN TEORI
2.1
Definisi Data Warehouse Definisi data warehouse dapat berbeda-beda namun tetap mempunyai makna utama yang sama. Berikut ini adalah beberapa pandangan para ahli mengenai definisi data warehouse. Menurut Inmon(2002, p31), sebuah data warehouse adalah sebuah koleksi data yang mempunyai karakteristik subject-oriented, integrated, nonvolatile, dan time variant, yang dapat mendukung keputusan di tingkat manajemen suatu organisasi. Sedangkan menurut Poe et al.(1998, p6), sebuah data warehouse adalah sebuah database analitis yang hanya dapat dibaca dan digunakan sebagai dasar untuk sebuah sistem pendukung keputusan.
2.2
Karakteristik Data Warehouse Seperti yang telah disebutkan di atas, sebuah data warehouse mempunyai karakteristik subject-oriented, integrated, nonvolatile, dan time variant (Inmon, 2002, p31).
2.2.1
Subject Oriented Data warehouse didesain untuk membantu kita menganalisis data. Data warehouse berorientasi kepada beberapa area subjek utama dari
6
7 perusahaan yang telah didefinisikan dalam high level corporate data model. Area subjek tersebut meliputi: y
Konsumen.
y
Produk.
y
Transaksi atau aktivitas.
y
Polis.
y
Klaim.
y
Rekening. Tiap area subjek secara fisik diimplementasikan sebagai sebuah
rangkaian dari tabel-tabel yang berhubungan dalam data warehouse. Sebuah area subjek dapat terdiri dari 10, 100 tabel secara fisik, atau bahkan lebih, yang kesemuanya saling berhubungan (Lane, 2002, p1-2; Inmon, 2002, p36). Data warehouse berbeda dari sistem database operasional dalam banyak hal. Salah satu dari perbedaan utama diantara kedua sistem ini adalah data yang dikumpulkan dari tiap-tiap sistem. Dalam sistem operasional atau Online Transaction Processing (OLTP) systems, data disebut dengan operational data dan secara konstan berada dalam keadaan yang terus berubah, sementara itu dalam data warehouse, data biasanya disebut sebagai decision support data dan secara tetap relatif statis. Tabel di bawah ini menyebutkan perbedaan-perbedaan utama diantara operational data dalam OLTP systems dan decision support data dalam data warehouse.
8 Tabel 2.1 Perbedaan Operational Data dengan DSS Data (Sumber: Bain et al., 2001, p15) Operational Data
Decision Support Data
Application-oriented: data berguna Subject-oriented: data berguna bagi bagi
proses atau fungsionalitas subjek tertentu dari bisnis, seperti
bisnis tertentu.
rekening
konsumen,
konsumen,
dan
informasi sebagainya.
Denormalisasi data 1 record dapat mencakup keseluruhan proses bisnis. Detailed data.
Summarized atau refined data dengan perhitungan kompleks.
Struktur biasanya statis.
Strukturnya dinamis dimana data cubes
baru
dapat
dibuat
jika
diperlukan. Cubes yang telah ada juga
dapat
diperluas,
dengan
menambahkan, baik dimensions baru atau dimension levels baru. Sasarannya adalah data-entry people. Sasarannya Datanya terstruktur, sehingga data keputusan
adalah pada
semua
pembuat tingkat.
entry cepat dan akurat, membantu Struktur data didesain sedemikian sebanyak mungkin data entry person. rupa sehingga analisis dapat dibuat pada tingkat yang berbeda dan area yang berbeda dalam sebuah bisnis. Volatile (dapat diubah).
Non-volatile (tidak dapat diubah setelah dimasukkan).
Kebutuhan-kebutuhan biasanya
Kebutuhan-kebutuhan belum
sudah diketahui sebelum desain dari
seluruhnya dimengerti sebelum
sistem.
desain dari sistem.
Mengikuti classical development life Seluruh life cycle berbeda, dimana cycle dimana sebuah perulangan dari kita mengambil sebuah struktur data
9 desain
diselesaikan
melalui dari aplikasi yang telah ada dan
normalisasi data, dan pengecekan membuat desain yang siap untuk kebutuhan pengguna.
analisis. Sedikit perputaran yang terlibat karena definisi sistem dari user telah diselesaikan.
Performa
sangat
penting
karena Permasalahan performa lebih sedikit,
kemungkinan banyak pengguna yang karena jumlah orang yang jauh lebih berbarengan mengakses data yang kecil diharapkan mengakses data sama.
secara bersamaan, jadi tidak ada permasalahan
concurrency
yang
harus dikhawatirkan. Transaction-driven.
Analysis-driven.
Harus benar-benar tersedia bagi para Tidak mempunyai tingkat end-user (backup dan recovery sudah ketersediaan kebutuhan yang sama dengan baik direncanakan).
tinggi dan rencana untuk backup dan recovery lebih sedikit.
Biasanya diambil dalam bentuk units Biasanya
diambil
dalam
bentuk
atau records pada waktu kapanpun kumpulan records. Ini mengantar yang
diberikan.
Ini
mengantar kepada pemrosesan sejumlah data
kepada pemrosesan sejumlah data yang
besar
dalam
satu
kali
yang sedikit dalam segala proses pemrosesan. yang diberikan (transaksi). Menggambarkan keadaan sekarang.
Menggambarkan
keadaan
dalam
waktu yang panjang (historis). Ketika
diadministrasi,
diatur secara keseluruhan.
biasanya Biasanya diatur dalam potonganpotongan, atau kumpulan-kumpulan yang lebih kecil.
10 2.2.2
Integrated Integrasi sangat berkaitan erat dengan orientasi subjek. Data warehouse harus meletakkan data dari sumber-sumber yang berbeda ke dalam sebuah format yang konsisten. Hal ini dapat memecahkan masalah seperti
konflik
penamaan
dan
inkonsistensi
diantara
unit-unit
pengukuran. Ketika masalah ini terpecahkan, hal ini dapat disebut sebagai integrated (Lane, 2002, p1-2).
2.2.3
Nonvolatile Nonvolatile berarti bahwa data seharusnya tidak berubah ketika masuk ke dalam data warehouse. Hal ini logis karena tujuan dari sebuah data warehouse adalah memungkinkan kita untuk menganalisis apa yang sudah terjadi (Lane, 2002, p1-3).
2.2.4
Time Variant Dalam upaya untuk menemukan tren dalam dunia bisnis, para analis membutuhkan sejumlah data yang besar. Ini sangat banyak berlawanan dengan OLTP systems, dimana kebutuhan performa menuntut data historis untuk dipindahkan ke dalam sebuah arsip. Perubahan setiap waktu dari fokus sebuah data warehouse itulah yang dimaksud dengan time variant (Lane, 2002, p1-3).
11 2.3
Struktur Data Warehouse Sebuah data warehouse mempunyai sebuah struktur yang unik. Struktur data warehouse tersebut terdiri dari current dan older operational data yang dikombinasikan dengan tingkat summarizations yang bermacam-macam dan detailed vantage points. Dalam buku Inmon dan Hackathorn’s “Using Data Warehouse”, mereka menggambarkan data warehouse data sebagai “data yang menjangkau sebuah spektrum waktu dan mungkin banyak terdapat hubungan data diantara dua tabel atau lebih.” Sebuah data warehouse diatur dengan data yang terdiri dari area bisnis utama, seperti: konsumen, produk, vendor, dan aktivitas. Tipe-tipe data yang mungkin disimpan dalam sebuah data warehouse adalah older detail data, current detail data, lightly summarized data, dan highly summarized data.
2.3.1
Older Detail Data Older detail data menggambarkan data yang tidak baru saja diterima, mungkin sudah berusia 10 tahun atau lebih. Data ini sangat besar dan sering disimpan dalam tempat penyimpanan yang besar, seperti tape, bahkan disk storage yang lebih mahal dapat digunakan. Tingkat detilnya konsisten dengan current detail data, tetapi berkaitan dengan rentang waktu yang lebih panjang, older detail data secara khusus dipindahkan ke sebuah media penyimpanan alternatif yang lebih murah (http://www2.sas.com/proceedings/sugi23/Advtutor/p41.pdf, p1).
12 2.3.2
Current Detail Data Current detail data menggambarkan data yang baru saja diterima dan selalu mempunyai rentang waktu yang lebih pendek dibandingkan dengan older detail data. Meskipun current detail data dapat sangat besar, tetapi data tersebut hampir selalu disimpan dalam disk untuk membolehkan akses yang lebih cepat. (http://www2.sas.com/proceedings/sugi23/Advtutor/p41.pdf, p1)
2.3.3
Lightly Summarized Data Lightly summarized data menggambarkan data yang disaring dari older detail data dan current detail data. Data ini di-summarize berdasarkan beberapa unit waktu dan selalu berada dalam disk. (http://www2.sas.com/proceedings/sugi23/Advtutor/p41.pdf, p1)
2.3.4
Highly Summarized Data Highly summarized data menggambarkan data yang disaring dari lightly summarized data. Data ini selalu padat dan dapat dengan mudah diakses, serta selalu berada dalam disk. (http://www2.sas.com/proceedings/sugi23/Advtutor/p41.pdf, p1)
2.3.5
Metadata Sebuah komponen terakhir dari data warehouse adalah metadata. Metadata
digambarkan
sebagai
data
tentang
data.
Metadata
menghasilkan informasi tentang struktur dari sebuah data warehouse dan
13 juga berbagai algoritma yang digunakan dalam data summarizations. Metadata menghasilkan sebuah gambaran deskriptif atau ”cetak biru” tentang bagaimana data dipetakan dari tingkat operasional ke tingkat data warehouse. (http://www2.sas.com/proceedings/sugi23/Advtutor/p41.pdf, p1)
Gambar 2.1 Struktur Data dalam Data Warehouse (Sumber: Inmon, 2002, p36)
2.4
Anatomi Data Warehouse Arsitektur data warehouse pada awalnya dibuat berdasarkan konsep bahwa proses data warehousing adalah mengambil data dari bermacam-macam sumber dan memindahkannya ke dalam sebuah pusat tempat penyimpanan data yang besar. Jadi, konsep ini sebenarnya lebih cenderung ke sebuah lingkungan
14 mainframe yang terpusat. Kemudian, dengan adanya teknologi client / server, memungkinkan data warehouse untuk diterapkan ke dalam berbagai cara yang berbeda agar dapat menyimpan kebutuhan pemakai sistem secara lebih proporsional. Dengan demikian, terdapat 3 anatomi dari arsitektur data warehouse yang dapat diterapkan dalam suatu organisasi, yaitu data warehouse fungsional, data warehouse terpusat, dan data warehouse terdistribusi (Ken Orr Institute).
2.4.1
Data Warehouse Fungsional Data warehouse fungsional adalah sebuah data warehouse yang mengambil data dari sistem operasional terdekat. Tiap data warehouse fungsional melayani kelompok yang berbeda dan terpisah, area fungsional yang berbeda dan terpisah, unit geografis yang berbeda dan terpisah, atau kelompok pemasaran produk yang berbeda dan terpisah. Sistem ini dapat memberikan solusi yang mudah untuk dibangun, karena hanya membutuhkan investasi yang relatif rendah dan dapat memberikan sebuah kemampuan sistem pengumpulan data yang terbatas kepada kelompok pengguna. Penerapan data warehouse ini dapat menyebabkan konsistensi data di luar lingkungan fungsi bisnis dapat berkurang bahkan menghilang. Konsistensi data organisasi tidak dapat dijamin lagi jika pendekatan ini ruang lingkupnya diperbesar menjadi ruang lingkup perusahaan dari ruang lingkup sebelumnya, yaitu lingkungan fungsional (http://www.kenorrinst.com/dwpaper.html).
15
Gambar 2.2 Data Warehouse Fungsional (Sumber: http://helical.ns.ca/documents/papers/hharchive.php)
2.4.2
Data Warehouse Terpusat Data warehouse terpusat merupakan sebuah database yang diciptakan dari data operasional yang diekstrak menjadi sebuah enterprise data model yang tunggal dan konsisten untuk memastikan konsistensi dari decision-support data yang melintasi organisasi. Gaya komputerisasinya meliputi semua sistem informasi yang ditempatkan dan diatur dari sebuah lokasi fisik yang tunggal. Data warehouse terpusat merupakan pendekatan yang paling banyak dipakai. Hal ini disebabkan karena sebagian besar pengguna terbiasa dengan lingkungan mainframe yang terpusat. Data diambil dari seluruh sistem operasional untuk kemudian disimpan di dalam pusat
16 tempat penyimpanan data. Data yang telah terkumpul tersebut dapat dipergunakan oleh para pengguna untuk membangun data warehouse fungsional masing-masing. Kelebihan pendekatan ini dibanding dengan data warehouse fungsional
adalah
datanya
benar-benar
terpadu.
Pendekatan
ini
mewajibkan para pihak pemasok data untuk terus mengirimkan datanya tepat pada waktunya agar tetap konsisten dengan pemasok data lainnya. Selain itu, para pengguna hanya dapat mengambil data dari pusat tempat penyimpanannya saja dan tidak dapat berhubungan dengan pemasok datanya sendiri secara langsung. Karena biaya pemeliharaan yang tinggi dan waktu yang lama untuk membangun sistem pengumpulan datanya, pendekatan ini kemudian banyak ditinggalkan. (http://www.kenorrinst.com/dwpaper.html)
17
Gambar 2.3 Data Warehouse Terpusat (Sumber: http://www.dmreview.com/article_sub.cfm?articleId=917)
2.4.3
Data Warehouse Terdistribusi Data warehouse terdistribusi adalah sebuah remote data source dimana para pengguna dapat melakukan query atau akses melalui sebuah central gateway yang menghasilkan sebuah logical view dari data organisasi dalam bentuk-bentuk yang dapat dimengerti oleh para pengguna. Gateway tersebut menguraikan dan mendistribusikan queries secara real time ke remote data sources dan mengembalikan hasil kepada para pengguna. Data warehouse terdistribusi dikembangkan berdasarkan konsep data warehouse gateway yang memungkinkan para pengguna untuk dapat langsung berhubungan, baik dengan sumber data maupun dengan
18 pusat penyimpanan data lainnya. View dari data kepada para pengguna adalah berupa gambaran logis karena data tersebut dari berbagai sumber yang berbeda. Pendekatan ini memanfaatkan keunggulan teknologi client / server untuk dapat mengambil data dari berbagai sumber. Pendekatan ini memungkinkan tiap departemen atau divisi untuk dapat membangun tempat penyimpanan data fungsionalnya masing-masing, bahkan juga sistem
operasionalnya
dan
memadukan
bagian-bagian
dengan
kemampuan teknologi client / server. Pendekatan ini memakan biaya yang sangat besar karena tiap sistem penyimpanan data fungsional dan sistem operasionalnya dikelola secara terpisah. Selain itu, data harus disinkronisasikan untuk memelihara keterpaduannya agar dapat berguna bagi organisasi. Pendekatan ini akan menjadi sangat efektif jika data sudah tersedia dalam bentuk yang konsisten dan para pengguna dapat menambahkan data tersebut dengan informasi yang baru jika ingin membangun view yang baru atas informasi (http://www.kenorrinst.com/dwpaper.html).
19
Gambar 2.4 Data Warehouse Terdistribusi (Sumber: http://www.phptr.com/articles/article.asp?p=101396&seqNum=2)
2.5
Kegunaan Data Warehouse Perusahaan membangun data warehouse untuk membantu mereka membuat keputusan dan dapat menggunakan informasi yang terdapat dalam data warehouse untuk melihat tren, pola, dan hubungannya. Sekali perusahaan membangun data warehouse, pimpinan perusahaan mempunyai sebuah sumber yang konsisten untuk enterprisewide data yang memungkinkan untuk jawaban yang cepat untuk queries. Tahap analisis dalam membangun sebuah data warehouse mungkin menemukan business intelligence yang sebelumnya tidak diketahui yang dapat memungkinkan untuk keputusan yang lebih baik.
20 Pertama dan terutama, membangun sebuah data warehouse dapat memberikan sebuah keuntungan strategis kepada perusahaan dalam suatu kompetisi dunia usaha. Keuntungan ini dapat datang dari beberapa sumber (Microsoft SQL Server 7.0 Data Warehousing Training Kit, 2000, Lesson 2): y
Kemampuan untuk mengakses enterprisewide data.
y
Kemampuan untuk mempunyai data yang konsisten.
y
Kemampuan untuk melakukan analisis secara cepat.
y
Pengenalan redundansi dari usaha-usaha yang telah dilakukan.
y
Penemuan celah dalam pengetahuan bisnis atau proses-proses bisnis.
y
Mengurangi biaya-biaya administrasi.
y
Memberikan kuasa kepada semua anggota perusahaan dengan menyediakan informasi yang diperlukan mereka secara efektif.
2.6
Metode Analisis Perancangan Data Warehouse Pada proses perancangan data warehouse, terdapat 2 kegiatan yang dapat dilakukan secara bersamaan, yaitu analisis decision supports system dan melakukan summarize decision source system. Objek analisis decision support system adalah pemahaman terhadap kebutuhan akan informasi untuk membuat keputusan secara detil. Analisis ini menggunakan pendekatan top-down untuk menentukan bentuk strategi yang akan digunakan pada data warehouse. Hasil dari analisis ini digunakan sebagai acuan dalam pembuatan data warehouse, biasanya dalam bentuk queries atau laporanlaporan.
21 Summarize decision source system adalah kegiatan survei terhadap seluruh sistem informasi, termasuk yang terjadi sekarang maupun sumber data yang potensial bagi data warehouse. Kegiatan ini menggunakan aspek bottom-up untuk melakukan identifikasi dan inventarisasi secara lengkap terhadap sumbersumber data secara keseluruhan, dapat dilakukan secara internal dan eksternal (http://www.ibm.com/developerworks/db2/library/techarticle/dm-0507gong/).
2.7
Perancangan Data Warehouse dengan Skema Bintang Tujuan dari sebuah data warehouse sering dicapai dengan menggunakan sebuah desain database yang dinamakan dengan sebuah skema bintang. Menurut Poe et al.(1998, p191) sebuah desain skema bintang adalah sebuah struktur sederhana dengan tabel-tabel yang relatif sedikit dan hubungan antar tabel didefinisikan dengan jelas. Desain database ini, dibandingkan dengan struktur normalisasi
yang
digunakan
untuk
transaction-processing
databases,
menghasilkan waktu respon query yang cepat dan sebuah skema sederhana yang dengan mudah dapat dimengerti oleh para analis dan end users, bahkan untuk mereka yang tidak terbiasa dengan struktur database.
2.7.1 Keuntungan Menggunakan Skema Bintang Menggunakan sebuah skema bintang atau sebuah desain database relasional yang lebih tradisional adalah hal yang terbaik untuk membuat keputusan sebelum memulai data modelling dan desain database secara fisikal. Dalam kedua hal tersebut, kita akan meningkatkan performa dari database melalui denormalisasi dan partitioning data. Bagaimanapun
22 juga, menggunakan sebuah skema bintang menghasilkan beberapa keuntungan yang tidak dimiliki oleh sebuah struktur relasional pada umumnya. Skema bintang sering digunakan untuk desain data warehouse database karena (Poe et al., 1998, p192): y
Membuat sebuah desain database yang menghasilkan waktu respon yang cepat.
y
Memungkinkan database optimizers untuk bekerja dengan sebuah desain database yang lebih sederhana agar dapat menghasilkan rencana pelaksanaan yang lebih baik.
y
Paralel dalam desain database, bagaimana end users mengingat dan menggunakan data.
y
Mempermudah pengertian dan navigasi dari metadata untuk para pengembang dan end users.
y
Memperluas pilihan-pilihan dari front-end data access tools, sebagaimana beberapa produk membutuhkan sebuah desain skema bintang.
2.7.2
Perancangan Skema Bintang Sebuah skema bintang mengandung dua tipe tabel: tabel fakta dan tabel dimensi. Tabel fakta, kadang disebut dengan tabel mayor, mengandung kuantitatif atau data faktual mengenai sebuah bisnis – informasi yang di-query. Informasi ini seringkali berupa pengukuran numerik dan dapat terdiri dari banyak kolom dan jutaan baris. Tabel dimensi, kadang disebut dengan tabel minor, lebih kecil dan memegang
23 data deskriptif yang menggambarkan dimensi-dimensi dari sebuah bisnis. SQL queries kemudian menggunakan predefined dan user-defined join paths diantara tabel-tabel fakta dan tabel-tabel dimensi, dengan batasanbatasan pada data untuk mengembalikan informasi yang dipilih. Sebuah skema well-thought out menghasilkan tabel-tabel dimensi yang mengizinkan pengguna untuk menjelajah sebuah database agar menjadi terbiasa dengan informasi yang terdapat di dalamnya. Pengguna tersebut dapat kemudian menuliskan batasan-batasan untuk queries sehingga hanya informasi yang memenuhi batasan-batasan tersebut saja yang dikembalikan dari database (Poe et al., 1998, p192).
2.7.3
Skema Bintang Sederhana Setiap tabel harus mempunyai sebuah primary key, yang mana adalah sebuah kolom atau sekelompok kolom yang isinya secara unik mengidentifikasi tiap baris. Dalam sebuah skema bintang sederhana, primary key untuk tabel fakta terbentuk dari satu atau lebih foreign keys; sebuah foreign key adalah sebuah kolom dalam satu tabel yang nilainya didefinisikan oleh primary key dalam tabel lain. Ketika sebuah database dibuat, perintah-perintah SQL yang digunakan untuk membuat tabel-tabel akan menandakan kolom-kolom yang akan membentuk primary dan foreign keys (Poe, et al., 1998, p193). Gambar 2.5 menggambarkan hubungan antara tabel fakta dan tabel-tabel dimensi. Gambar ini mempunyai sebuah tabel fakta dan tiga tabel dimensi. Tabel fakta tersebut mempunyai sebuah primary key yang
24 dibentuk dari tiga foreign keys: Key1, Key2, dan Key3, dimana tiap-tiap key tersebut merupakan primary key dari sebuah tabel dimensi. Hubungan many-to-one terdapat di antara foreign keys dalam tabel fakta dengan primary keys yang ditunjuk dalam tabel-tabel dimensi.
Gambar 2.5 Hubungan antara Tabel Fakta dengan Tabel Dimensi dalam Skema Bintang Sederhana (Sumber: Poe et al., 1998, p195).
2.7.4
Skema Bintang dengan Banyak Tabel Fakta Implementasi
database
yang
lebih
rumit
membutuhkan
penggunaan banyak tabel fakta. Dalam beberapa hal, terdapat banyak tabel fakta karena mereka mengandung fakta-fakta yang tidak berhubungan atau karena periode waktu load yang berbeda. Dalam hal yang lain, terdapat banyak tabel fakta karena mereka meningkatkan performa. Sebagai contoh, banyak tabel fakta sering digunakan untuk memegang bermacam-macam tingkat dari data agregasi, secara khusus ketika jumlah dari agregasi besar. Membuat tabel-tabel berbeda untuk tingkat agregasi yang berbeda adalah sebuah teknik desain umum untuk
25 sebuah data warehouse database sehingga setiap permintaan tunggal untuk sebuah tabel dengan ukuran yang pantas (Poe et al., 1998, p195196). Gambar 2.6 menggambarkan contoh sales database dengan sebuah tabel fakta tambahan untuk penjualan tahun sebelumnya.
Gambar 2.6 Contoh Skema Bintang dengan Banyak Tabel Fakta (Sumber: Poe et al., 1998, p196)
Penggunaan
lain
dari
sebuah
tabel
fakta
adalah
untuk
mendefinisikan sebuah hubungan many-to-many antara dimensi-dimensi tertentu dari bisnis; tipe tabel seperti ini dikenal sebagai sebuah tabel asosiasi. Sebagai contoh, dalam sales database, tiap produk dipunyai oleh satu atau lebih kelompok, dan tiap kelompok mengandung banyak produk.
Sebuah
hubungan
many-to-many
digambarkan
dengan
26 membangun sebuah tabel fakta yang menggambarkan kombinasi yang mungkin dari produk dan kelompok. Dalam cara yang lain, sebuah tabel fakta yang baru dibuat untuk menggabungkan sebuah hubungan many-tomany diantara dimensi-dimensi yang berbeda sebagaimana digambarkan dalam Gambar 2.7 (Poe et al., 1998, p196-197).
Gambar 2.7 Skema Bintang dengan Tabel Fakta sebagai Tabel Asosiasi (Sumber: Poe et al., 1998, p197)
2.7.5
Skema Bintang Majemuk Dalam sebuah skema bintang majemuk, tabel fakta mempunyai sebuah kumpulan foreign keys yang menunjuk tabel-tabel dimensi, dan sebuah primary key, yang dibentuk dari satu atau lebih kolom yang menghasilkan sebuah identifier unik untuk tiap baris. Primary key dan foreign keys tersebut tidak serupa dalam sebuah skema bintang majemuk.
27 Ini yang membedakan sebuah skema bintang majemuk dengan sebuah skema bintang tunggal (Poe et al., 1998, p199-200). Gambar 2.8 menggambarkan hubungan antara tabel fakta dan tabel-tabel dimensi dalam sebuah skema bintang majemuk. Dalam tabel fakta tersebut, foreign keys adalah Fkey1, Fkey2, dan Fkey3, dimana tiaptiapnya merupakan primary key dalam sebuah tabel dimensi. Tidak seperti skema bintang sederhana, kolom-kolom ini tidak membentuk primary key dalam tabel fakta. Melainkan, kedua kolom yaitu Key1 dan Key2, yang tidak menunjuk ke tabel dimensi manapun, dan Fkey1 digunakan untuk membentuk primary key. Primary key dapat dibentuk dari segala kombinasi dari foreign key dan key columns yang lain dalam sebuah skema bintang majemuk.
Gambar 2.8 Desain Skema Bintang Majemuk (Sumber: Poe et al., 1998, p200)
2.7.6
Skema Snowflake Beriringan dengan peningkatan data access tools, jarak antara end user dengan struktur database fisikal meningkat. Ini menghasilkan
28 fleksibilitas yang lebih dalam desain fisikal. Satu variasi dari sebuah skema bintang adalah untuk menyimpan semua informasi dimensional dalam bentuk normal ke-tiga, sementara tetap dengan struktur tabel fakta yang sama. Tipe skema bintang ini adalah kadang disebut dengan skema snowflake. Dua alasan umum untuk ketertarikan terhadap variasi ini adalah (1) munculnya advance decision support tools yang dapat secara penuh memanfaatkan struktur ini, dan (2) banyak sistem informasi organisasi merasa lebih nyaman dengan sebuah desain dalam bentuk normal ke-tiga. Harus diperhatikan bahwa jika para pengguna akan bekerja secara langsung dengan struktur tabel fisikal, jumlah tabel harus dibatasi untuk meminimalisasi kekacauan (Poe et al., 1998, p198). Gambar 2.9 menunjukkan struktur skema snowflake. Dalam contoh ini, terdapat sembilan tabel dimensi yang terpisah.
Gambar 2.9 Skema Snowflake (Sumber: Poe et al., 1998, p199)
29 Sebuah tabel dimensi juga dapat mengandung sebuah foreign key yang menunjuk primary key dalam tabel dimensi lain. Tabel dimensi yang ditunjuk kadang disebut dengan tabel dimensi sekunder. Gambar 2.10 meliputi dua tabel dimensi sekunder, District dan Region, yang mendefinisikan ID codes yang digunakan dalam Market Table. Outboard tables juga dapat dirangkai bersama untuk menghasilkan sebuah hirarki dari tabel-tabel dimensi yang diatur dalam sebuah desain database yang lebih dinormalisasi. Sebuah desain yang dinormalisasi mengurangi ukuran dari tabel-tabel dimensi, tetapi mengurangi performa dan keuntungan kemampuan penggunaan yang diturunkan dari sebuah desain skema bintang murni (Poe et al., 1998, p197).
Gambar 2.10 Contoh Outboard Tables (Sumber: Poe et al., 1998, p198)
2.7.7
Agregasi Agregasi adalah proses mengakumulasi data fakta sepanjang atribut-atribut yang telah didefinisikan terlebih dahulu (Poe et al., 1998, p204). Misalnya, kita dapat membuat sebuah summary dari penjualan
30 melalui daerah dan departemen dengan mengakumulasi penjualan dari toko dan tingkat detil item. Dalam konteks desain database, kita harus membuat keputusan mengenai pembuatan agregat selama proses transformasi data dan me-load data yang telah dikalkulasikan terlebih dahulu ke dalam data warehouse. Faktor utama yang mendorong pembuatan prestored aggregates adalah untuk: y
Meningkatkan performa end-user query.
y
Mengurangi jumlah total dari perputaran CPU yang digunakan. Merupakan hal yang tidak masuk akal untuk melakukan
penyimpanan sebuah agregat spesifik awal yang memakan waktu selama dua jam jika hal ini diminta oleh satu pengguna setiap satu tahun sekali. Di lain pihak, jika agregat yang sama diminta oleh 300 pengguna dalam tiap hari, proses ini dapat membuat efek yang merugikan bagi sistem operasional. Dalam hal ini, prestored aggregates harus dijamin. Kita seharusnya membuat prestored aggregate sekali selama proses transformasi data dan me-load-nya ke dalam database. Merupakan hal yang tidak perlu untuk melakukan penyimpanan agregasi awal pada tiap kombinasi dari atribut-atribut. Untuk menentukan apa yang lebih dahulu disimpan dalam data warehouse, kita perlu untuk mempertimbangkan tidak hanya frekuensi dari akses end-user tetapi juga potensial pengurangan dalam jumlah total baris. Peringkasan data hanya pada tingkat tertentu saja disebut sebagai sparse aggregation. Pemilihan summary tables juga akan dipengaruhi oleh pola akses yang diminta dari
31 end users. Dengan memilih tingkat agregasi yang tepat, optimasi performa query dan disk tempat penyimpanan dalam data warehouse akan terjadi. Satu konsep final yang harus dicatat adalah bahwa ketika me-load sebuah data warehouse, kita tetap perlu untuk menggunakan teknik klasik database seperti physical table partitioning. Hal ini menjadi sangat penting sehubungan dengan data warehouses yang mempunyai ratusan gigabytes dari data.
2.7.8
Denormalisasi Denormalisasi adalah proses mengkombinasikan tabel-tabel dalam cara yang teliti dan bijaksana untuk meningkatkan performa (Poe et al., 1998, p207). Ini merupakan proses yang benar-benar melanggar aturan dari bentuk normal ke-tiga. Alasan utama untuk melakukan ini adalah: y
Untuk mengurangi jumlah joins yang harus diproses dalam average queries, dengan demikian dapat meningkatkan performa database.
y
Untuk memetakan struktur database fisikal lebih dekat lagi kepada user’s dimensional business model. Menyusun tabel-tabel di sepanjang garis dari bagaimana para pengguna akan melakukan pertanyaan akan menghasilkan kesempatan untuk memperbaiki jalur akses umum yang mana akan meningkatkan performa lagi.
32 2.8
Asuransi Sebuah pengertian dari resiko adalah dasar dari asuransi. Resiko berkaitan dengan ketidakpastian dari kehilangan, atau tidak mendapatkan, sesuatu dari nilai (biasanya mengenai uang). Resiko terjadi karena variasi dari akibat atau hasil dalam banyak situasi dan kondisi (Bickelhaupt, 1979, p5). Contoh resiko terdapat di mana-mana, dari yang tidak dapat dihindarkan sampai dengan yang diasumsikan dengan pilihan. Keberadaan manusia itu sendiri menciptakan resiko, di mana ketika kematian, penyakit, kecelakaan, atau pengangguran terjadi. Contoh dari resiko dengan pilihan akan menjadi pembentukan dari segala bentuk perusahaan, seperti pengeboran sebuah sumur minyak yang baru, atau menginvestasi uang dalam real estate. Tentu saja, siapapun yang mempunyai properti secara otomatis memperkirakan resiko, seperti bahaya kebakaran, angin ribut, pencurian, atau penuntutan perkara liabilitas. Ketidakmampuan untuk memprediksi kapan atau jika bahaya-bahaya ini akan menyebabkan kehilangan adalah sebuah resiko yang diperoleh oleh para pemilik properti dengan kepemilikan mereka tersebut (Bickelhaupt, 1979, p5).
2.8.1
Pengertian Asuransi Menurut UU No.2 / 1992 pasal 1 ayat 1, asuransi atau pertanggungan adalah perjanjian antara dua pihak atau lebih, dengan mana pihak penanggung mengikatkan diri kepada tertanggung, dengan menerima premi asuransi, untuk memberikan penggantian kepada tertanggung karena kerugian, kerusakan atau kehilangan keuntungan yang diharapkan, atau tanggung jawab hukum kepada pihak ketiga yang
33 mungkin akan diderita tertanggung, yang timbul dari suatu peristiwa yang tidak pasti, atau untuk memberikan suatu pembayaran yang didasarkan atas meninggal atau hidupnya seseorang yang dipertanggungkan (Sekretariat Dewan Asuransi Indonesia, 2004, p2). Menurut Pasal 246 KUHD, asuransi atau pertanggungan adalah suatu perjanjian di mana pihak tertanggung mengikatkan diri dengan pihak penanggung, dengan menerima suatu premi karena suatu kerugian, kerusakan, atau kehilangan keuntungan yang diharapkan, yang mungkin terjadi karena suatu peristiwa yang tidak menentu (Hukum & Asuransi 110, p30)
2.8.2
Asuransi Kendaraan Bermotor Asuransi kendaraan bermotor menjamin kerugian atas kendaraan bermotor karena kecelakaan, niat jahat orang lain, pencurian, kebakaran, dan tanggung jawab hukum kepada pihak ketiga akibat pemakaian kendaraan bermotor tersebut. (http://www.tokiomarine.co.id/ins_auto_in.htm)
2.8.3
Polis Polis bukanlah perjanjian asuransi tetapi sebagai tanda bukti adanya perjanjian asuransi (evidence of insurance contract) (Widya Dharma Artha, p6).
34 Pasal 255 KUHD mengatakan: “Suatu perjanjian pertanggungan harus dibuat secara tertulis dalam suatu akta yang disebut dengan polis” (Widya Dharma Artha, p6). Polis ikhtisar adalah bentuk polis dimana bagian-bagian yang berbeda dari dokumen tersebut dipisah dari satu dan yang lainnya dan informasi tertentu yang berkaitan dengan perjanjian itu dirinci dalam halaman khusus yang disebut ikhtisar / schedule (Widya Dharma Artha, p6). Endorsement adalah dokumen yang dipakai untuk melakukan perubahan-perubahan atas polis yang bersangkutan, misalnya perubahan nilai pertanggungan, cover, premi, objek pertanggungan, dan sebagainya (Widya Dharma Artha, p8).
2.8.4 Underwriting Prinsip insurable interest, utmost good faith, proximate cause, indemnity, subrogasi, dan kontribusi, serta prinsip asuransi lainnya, insurable risks dan fungsi pengalihan resiko dari asuransi maupun reasuransi mempunyai implikasi bagi proses underwriting dan akseptasi resiko asuransi (Widya Dharma Artha, p13).
2.8.4.1 Underwriter Bila suatu resiko ditawarkan kepada asuradur, seseorang yang mewakilinya melakukan assesment resiko dan memutuskan apakah dapat diterima atau tidak. Jika tidak dapat diterima, ia
35 menetapkan suku premi, terms & conditions yang akan diberlakukan. Di Lloyds, slip yang bersangkutan distempel dan ditandatangani di bagian bawah untuk menunjukkan persentase pertanggungan yang diterima atas nama sindikat. Oleh karena itu, istilah underwriter – orang yang menandatangani di bagian bawah – dalam hal ini menunjukkan persetujuannya atas terms yang tercantum dalam slip. Proses melakukan assessment atas terms & conditions yang akan diberlakukan dalam kontrak asuransi dikenal dengan istilah underwriting (Widya Dharma Artha, p13).
2.8.4.2 Peranan Underwriter Underwriter harus berusaha mengatur terms & conditions serta premi cover yang bersangkutan sesuai dengan tingkat resiko, baik dari segi frekuensi maupun severity. Terms dan premi harus equitable dengan apa yang diberikan kepada para tertanggung lain untuk jenis pertanggungan yang sama, harus reasonable agar perusahaan dapat memperoleh bisnis baru, dan harus dapat memberikan profit yang wajar. Agar dapat menetapkan terms & conditions, seorang underwriter melakukan assessment atas dua aspek hazards, yaitu physical & moral hazards (Widya Dharma Artha, p13).
36 2.8.4.3 Physical Hazards Physical hazards berkaitan dengan aspek fisik dari objek pertanggungan yang dapat mempengaruhi terjadinya dan atau besarnya kerugian. Pengetahuan tentang aspek fisik ini dapat diperoleh
underwriter
melalui
fakta-fakta
material
yang
disampaikan berdasarkan prinsip utmost good faith, melalui informasi lebih lanjut yang diperoleh oleh surveyor asuransi, atau melalui pengetahuan underwriter sendiri mengenai jenis usaha (trade), proses, dan sebagainya yang diperoleh dari pengalaman bertahun-tahun (Widya Dharma Artha, p13). Kadang-kadang perlu bagi seorang underwriter untuk mempertimbangkan physical hazards dalam dua tahap (Widya Dharma Artha, p14): 1. Aspek apa dari resiko yang mungkin menyebabkan terjadinya peristiwa yang diasuransikan → inception risks. 2. Jika peristiwa yang diasuransikan terjadi, aspek apa dari resiko yang mungkin mengakibatkan kerugian menjadi lebih parah. Pendekatan ini khususnya membantu dalam hal asuransi kebakaran dan harta benda lainnya, karena faktor-faktor ini relevan dalam rating dan underwriter dapat juga memberikan rekomendasi untuk memperbaiki keadaan resiko. Inception risks dapat dikurangi melalui good management atau good housekeeping.
37 Aspek severity dapat dikendalikan dengan membuat segregasi atau kompartimensasi sehingga bagian yang berbahaya dari suatu resiko dipisahkan dari bagian-bagian lain / sumbersumber kerugian. Dalam tahap pertama kita berhubungan dengan loss prevention, sedangkan dalam tahap kedua kita berhubungan dengan loss control (Widya Dharma Artha, p14). Physical hazards dalam kaitannya dengan asuransi kendaraan bermotor (Widya Dharma Artha, p14): y
Penggunaan kendaraan di daerah sangat padat lalu lintas menambah kemungkinan terjadinya kecelakaan.
y
Penggunaan kendaraan untuk jenis-jenis usaha tertentu yang berarti berada di jalan raya hampir sepanjang hari, misalnya taksi.
y
Jenis kendaraan yang biaya perbaikannya sangat mahal, misalnya: Mercedez, Roll Royce, BMW, dan sebagainya.
y
Pengemudi di bawah usia 25 tahun, mobil balap.
2.8.4.4 Moral Hazards Moral hazards berkaitan dengan sikap, sifat, dan tingkah laku manusia dalam asuransi, ini terutama adalah pihak tertanggung, karyawan tertanggung, dan masyarakat. Moral hazards dari masyarakat umum semakin penting dalam meng-assess moral hazards.
38 Moral hazards sama pentingnya dengan physical hazards dalam mempengaruhi kerugian (Widya Dharma Artha, p16).
2.8.4.4.1 Tertanggung Prinsip insurable interest akan memungkinkan underwriter kepentingan calon tertanggung atas objek pertanggungan. Bentuk-bentuk tertentu dari insurable interest membawa pengalaman klaim yang abnormal, umumnya berkaitan dengan usaha tertanggung (professional artist, bookmakers, money lenders, licensed trade, biasanya membawa bad moral hazards untuk jenis-jenis asuransi tertentu). Contoh bad moral hazards yang sangat serius dari tertanggung adalah seseorang yang mengajukan klaim palsu atau jumlahnya sangat berlebihan. Contoh lain, menyampaikan atau memberikan keterangan yang tidak benar, sengaja atau tidak, pada waktu akan melakukan penutupan. Contoh yang paling umum mengenai poor moral hazards
adalah
mengambil
carelessness,
langkah-langkah
tertanggung yang
wajar
tidak untuk
mencegah kerugian atau kerusakan harta bendanya, dan untuk keselamatan atas karyawannya atau orang lain.
39 Ini bisa terjadi karena tekanan bisnis atau internal atau ketidaktahuan. Cara yang dapat dilakukan dalam ini ialah memperbaiki moral hazard dengan mendidik tertanggung tentang adanya bahaya potensial serta bagaimana menguranginya. Kadang-kadang
sulit
membedakan
antara
physical hazard dan moral hazard. Misalnya sport car, kendaraan jenis ini pernah dianggap sebagai poor physical
hazard;
mobil
itu
sendiri
tidak
bisa
menimbulkan kecelakaan lebih banyak dari sedan biasa; bagaimana mengemudikannya, itulah hazard. Adakalanya, adanya poor physical hazard, misalnya kondisi kerja yang tidak aman, adalah akibat poor moral hazard pada awalnya. Sebagai contoh, dalam merencanakan suatu pabrik atau mengawasi operasinya, kondisi tidak aman itu dibiarkan ada walaupun sebenarnya dapat diadakan kondisi yang lebih aman (Widya Dharma Artha, p16).
2.8.4.4.2 Karyawan Jika hubungan majikan-karyawan jelek atau tingkat
upah
sangat
rendah
akan
sedikit
sekali
kemungkinannya karyawan didorong untuk bekerja hatihati. Dalam hal ekstrim kemungkinan terjadi sabotase,
40 vandalisme, dan sebagainya (Widya Dharma Artha, p17).
2.8.4.4.3 Masyarakat Sikap masyarakat luas dapat mempengaruhi terjadinya klaim. Bisa timbul vandalisme, sengaja membakar, dan sebagainya (Widya Dharma Artha, p17).
2.8.4.4.4 Surveyor Proposal form atau slip broker hanya dapat memberikan informasi tertentu, oleh karena itu dalam praktek dilakukan survei atas premises. Surveyor akan mempersiapkan laporan, denah dari premises yang memberikan gambaran mengenai berbagai aspek fisik dari resiko. Ia memberikan rekomendasi untuk perbaikan resiko. Penerimaan atas permintaan pertanggungan dapat diterima
dengan
syarat
tertanggung
melakukan
rekomendasi dimaksud. Laporan survei atas resiko harta benda (property risk) memuat estimasi kerugian maksimum yang mungkin terjadi (Maximum Probable Loss / MPL) atau disebut juga Estimated Maximum Loss (EML), yang digunakan untuk menetapkan proporsi resiko yang dapat diterima. Laporan survei dapat juga
41 memuat rate of premium yang dapat diaplikasikan (Widya Dharma Artha, p17).
2.8.5
Klaim Individu tertanggung yang telah menderita kerugian dan ingin menerima pembayaran harus memberitahukan perusahaan asuransi mereka melalui sebuah proses yang dinamakan klaim. Kontrak asuransi selalu berisi sebuah kondisi bahwa pihak tertanggung harus memberikan bukti kerugian agar dapat dibayarkan oleh pihak penanggung. Sebuah klaim dimulai ketika seseorang yang menderita kerugian melengkapi dan menandatangani sebuah statement yang menggambarkan apa yang terjadi yang menyebabkan kerugian (Microsoft Encarta Encyclopedia, 2002, Insurance).
2.8.5.1 Prosedur Klaim Dalam melakukan proses klaim terdapat beberapa prosedur yang harus dilakukan, yaitu (Widya Dharma Artha, p29):
2.8.5.1.1 Kewajiban Tertanggung y
Implied: bertindak seakan-akan tidak diasuransikan, mengambil semua langkah yang sewajarnya untuk memperkecil kerugiannya. Memberikan kebebasan
42 atau tidak menghalangi kepolisian atau pemadam kebakaran. y
Express:
memberitahukan
segera
kepada
penanggung, memberikan keterangan yang lengkap. Biasanya penanggung mengirimkan claim form kepada
tertanggung
untuk
dilengkapi,
untuk
memperoleh keterangan tentang: tertanggung, tempat kerugian, sifat kerugian, waktu terjadinya kerugian, dan keterangan mengenai asuransi lain, bila ada. y
Pembuktian tentang kerugian (proof of loss) Menjadi beban tertanggung untuk membuktikan: y
Adanya kerugian yang disebabkan oleh peristiwa yang dipertanggungkan.
y
Besarnya kerugian, dalam hal liability claims, penanggung mengambil alih negosiasi sehingga tertanggung tidak concern dengan jumlah klaim. Bila penanggung mengatakan klaim di-exclude oleh
polis,
ia
(penanggung)
harus
membuktikannya (Widya Dharma Artha, p29).
2.8.5.1.2 Hak Tertanggung y
Bila
tertanggung
kewajibannya,
ia
telah berhak
memenuhi untuk
semua
memperoleh
pembayaran penuh sesuai dengan persyaratan polis.
43 y
Pembayaran harus segera dilakukan tanpa menunggu recovery
melalui
subrogasi
atau
kontribusi
berdasarkan market agreement (Widya Dharma Artha, p29).
2.8.5.1.3 Kewajiban Penanggung y
Menghormati
hak
dari
tertanggung
sepanjang
tertanggung telah memenuhi kewajibannya (Widya Dharma Artha, p29).
2.8.5.1.4 Hak dari Penanggung y
Bersama-sama dengan tertanggung, menyelamatkan benda pertanggungan, ini biasanya dilakukan melalui loss adjusters.
y
Memasuki tempat kerja tertanggung, dan menguasai benda-benda
untuk
tujuan
yang
wajar
tanpa
mengakui liabilitasnya atas klaim, sehingga dapat melakukan investigasi klaim secepatnya (Widya Dharma Artha, p30).
2.8.5.2 Claim Form Claim form merupakan formulir standar yang digunakan oleh penanggung untuk mengumpulkan informasi yang relevan bagi assessment claims.
44 Secara
umum
berisi
pertanyaan
yang
detil
dari
tertanggung, harta benda yang diperlukan ialah untuk menilai apakah kerugian dijamin oleh polis dan bila ya, seberapa besar kerugian yang terjadi (Widya Dharma Artha, p30).
2.8.5.3 Penelitian Klaim Bila jumlah klaim kecil, penanggung melunasi setelah claim form diisi dan dilengkapi dengan bukti mengenai harga dan biaya perbaikan. Pada klaim kerusakan kendaraan bermotor, penanggung mengirimkan teknisinya atau montir untuk meneliti kerusakan dan menyepakati terus dengan bengkel. Prosedur ini juga berlaku dalam claim engineering. Dalam klaim asuransi harta benda, lazim menunjuk loss adjuster untuk melakukan investigasi klaim serta memberikan rekomendasi mengenai penyelesaiannya (Widya Dharma Artha, p30).
