7
BAB 2 LANDASAN TEORI
2.1
Database 2.1.1
Pengertian Database Menurut Connolly dan Begg (2005, p15), database merupakan sebuah kumpulan data yang terhubung secara logika, dan deskripsi dari data tersebut, yang didesain untuk memenuhi informasi yang dibutuhkan oleh organisasi. Menurut McLeod (2007, p124), database adalah sekumpulan seluruh sumber daya berbasis komputer milik organsasi. Dua tujuan utama dari konsep database adalah meminimalkan pengulangan data dan mencapai interdependensi data. Berdasarkan definisi tersebut, dapat disimpulkan bahwa database adalah kumpulan data yang terhubung secara logikal dan deskripsi dari data tersebut dalam sebuah sistem komputer.
2.1.2
Relational Model Menurut Connolly dan Begg (2005, p69), dalam relational model semua data terstruktur secara logika dengan relasinya (tabel). Setiap relasi mempunyai sebuah nama dan dibentuk dari atribut (kolom) dan data. Setiap tuple (baris) berisi satu nilai per atribut. Relational model terminology (Connoly dan Begg, 2005, p72) meliputi :
8
Relasi adalah sebuah tabel dengan kolom dan baris.
Atribut adalah nama kolom dari sebuah relasi.
Domain adalah himpunan nilai dari satu atau lebih atribut.
Tuple adalah baris dari sebuah relasi
Degree adalah banyaknya atribut/kolom pada tabel.
Cardinality adalah banyaknya tuple/baris pada tabel.
Relational
database
adalah
kumpulan
dari
relasi
yang
ternormalisasi dengan nama relasi yang jelas dan dapat dibedakan.
2.1.3
Entity Relationship (ER) Modeling Menurut Connolly dan Begg (2005, p342), Entity Relationship (ER) Modeling adalah pendekatan top-down untuk mendesain database yang diawali dengan mengidentifikasikan data penting yang disebut entities dan relationships di antara data-data yang harus direpresentasikan dalam model. Kemudian ditambahkan detail-detail seperti informasi yang ingin ditambahkan tentang entities dan relationship yang disebut attributes dan berbagai constraints pada entities, relationships, dan attributes.
2.2
Data Warehouse 2.2.1
Pengertian Data Warehouse Menurut Inmon (2005, p29), “A data warehouse is a subjectoriented, integrated, nonvolatile and time-variant collection of data in support of management’s decisions”, yang diartikan data warehouse
9 adalah kumpulan data yang berorientasi subyek, terintegrasi, bervariasi waktu, dan nonvolatile, yang mendukung manajemen pengambilan keputusan. Menurut Laudon (2004, p236), data warehouse adalah database yang menyimpan data penting saat ini dan historis dari kebutuhan informasi untuk manajer dalam perusahaan. Menurut Adelman dan Moss (2000, p36), data warehouse adalah sebuah lingkungan yang terdiri dari satu atau lebih database terintegrasi dan
terekonsiliasi
yang
didesain
untuk
mengantarkan
business
intelligence yang konsisten dan terekonsiliasi untuk seluruh unit bisnis dalam organisasi, untuk menjawab kebutuhan bisnis yang spesifik dan untuk mendukung tujuan strategis perusahaan. Jadi data warehouse dapat diartikan sebagai kumpulan data yang berorientasi subyek, terintegrasi, bervariasi waktu, dan nonvolatile, yang terdiri dari data saat ini dan historis, yang didesain untuk mengantarkan business intelligence yang konsisten dan terekonsiliasi, untuk menjawab kebutuhan bisnis yang spesifik dan untuk mendukung tujuan strategis perusahaan.
2.2.2
Karakteristik Data Warehouse Karakteristik dari data warehouse menurut pendapat Inmon (2005, p29-32) yaitu subject oriented, integrated, nonvolatile dan timevariant.
10 1.
Subject Oriented Sistem operasi secara klasik diorganisasikan sekitar aplikasi fungsional dari perusahaan. Untuk perusahaan asuransi, aplikasinya dapat berupa auto, health, life dan casuality. Area subyek utama dari perusahaan asuransi dapat berupa customer, policy, premium, dan claim. Untuk perusahaan, area subyek utama dapat berupa product, order, vendor, bill of material, dan raw goods. Untuk pedagang eceran, area subyek utama dapat berupa product, sale, vendor.
Gambar 2.1 Contoh Data Berorientasi Subjek ( Inmon, 2005, p30)
11 2.
Integrated Data diambil dari banyak sumber berbeda kemudian dimasukkan ke dalam data warehouse. Selama data diambil data tersebut diubah, dilakukan format kembali, diurutkan, diringkas dan seterusnya. Hasilnya, data terletak dalam data warehouse yang memiliki pandangan terpadu. Data yang dimasukkan ke dalam data warehouse dilakukan dengan berbagai cara yang tidak konsisten pada level aplikasi akan ditinggalkan. Sebagai contoh, masalah pengkodean gender, ini sedikit bermasalah apakah data dalam gudang dikodekan sebagai m/f atau 1/0. Tidak peduli bagaimana metode atau sumber aplikasi, gudang akan mengkodekan secara konsisten. Jika data aplikasi dikodekan sebagai x/y untuk gender, ini akan diubah ketika dipindahkan
ke
dalam gudang.
Pertimbangan yang sama tentang konsistensi juga diaplikasikan ke berbagai isu desain aplikasi seperti, peraturan penamaan (naming conventions), struktur kunci (key structure), pengukuran atribut (measurement of attributes) dan karakteristik fisik data (physical characteristics of data).
12
Gambar 2.2 Beberapa Isu Integrasi (Inmon, 2005, p31)
3.
Nonvolatile Data dalam lingkungan operasional di-update secara teratur,
tetapi
data
pada
data
warehouse
menunjukkan
karakteristik yang berbeda. Data pada data warehouse di-load dan diakses tetapi tidak di-update. Ketika data pada data warehouse di-load data di-load di dalam sebuah snapshot (static format). Ketika terjadi perubahan selanjutnya, snapshot record yang baru ditulis.
13
Gambar 2. 3 Isu nonvolatility(Inmon, 2005, p32)
4.
Time Variant Time-variant menyatakan bahwa setiap unit data dalam data warehouse adalah akurat pada waktu tertentu. Dalam beberapa kasus, record ditandai. Dalam kasus lain, sebuah record memiliki tanggal transaksi. Tetapi pada setiap kasus, ada beberapa bentuk penanda waktu untuk menunjukkan record tersebut akurat.
Gambar 2. 4 Isu time variancy(Inmon, 2005, p32)
14 2.2.3
Arsitektur Data Warehouse Menurut Connolly dan Begg ( 2005, p1056 - 1161), arsitektur Data Warehouse terdiri atas : 1.
Operational Data Sumber data untuk data warehouse diambil dari :
Mainframe data operasional menangani database jaringan dan hirarki generasi pertama.
Data departemen berada di sistem penyimpanan file departemental seperti VSAM, RMS, dan relational DBMS seperti Informix dan Oracle.
Data pribadi yang tersimpan dalam workstation dan server pribadi.
Sistem eksternal seperti internet, database komersial, atau database
yang
berhubungan
dengan
supplier
dan
customer. 2.
Operational Datastore Suatu operational datastore (ODS) adalah suatu media penyimpanan
dan
pengintegrasian
data
operasional
yang
digunakan untuk analisis. ODS menyediakan data dengan cara yang sama seperti data warehouse, tetapi sesungguhnya bertindak secara sederhana sebagai tempat penampungan sementara sebelum data dipindahkan ke warehouse. ODS diciptakan ketika sistem operasional ditemukan tidak mampu untuk mencapai keberhasilan sistem pelaporan. ODS
15 menyediakan manfaat yang berguna dari suatu relational database dalam mengambil keputusan yang mendukung fungsi data warehouse. 3.
Load Manager Load
Manager
melakukan
semua
operasi
yang
berhubungan dengan extract dan load data ke dalam data warehouse. Data di-extract secara langsung dari sumber data atau dari penyimpanan data operasional. Operasi yang dilakukan oleh load manager dapat meliputi perubahan bentuk yang sederhana untuk mempersiapkan data tersebut agar dapat dimasukkan ke dalam warehouse. 4.
Warehouse Manager Warehouse Manager melakukan semua operasi yang berhubungan dengan manajemen data dalam warehouse. Operasi yang dilakukan oleh warehouse manager meliputi :
Analisis data untuk memastikan konsistensi.
Perubahan bentuk dan penggabungan data sumber dari gudang penyimpanan sementara ke dalam tabel data warehouse.
5.
Membuat indeks dan mengacu pada tabel dasar.
Pembuatan denormalisasi.
Pembuatan agregasi.
Backing up dan archieving data
Query Manager
16 Query Manager melakukan semua operasi yang berkaitan dengan pengaturan user query. Komponen ini secara khusus dibangun menggunakan peralatan akses data end-user, peralatan pengontrol data warehouse, fasilitas database, dan pembangunan program. Kompleksitas query manager ditentukan oleh fasilitas yang disajikan melalui peralatan akses para end-user database. Operasi yang dilakukan komponen ini meliputi pengarahan query pada tabel yang sesuai dan penjadwalan pelaksanaan query. Terkadang query manager juga menghasilkan profil query yang mengijinkan warehouse manager menentukan kesesuaian indeks dan agregasi. 6.
Detailed Data Area ini menyimpan semua detail data di dalam skema database. Dalam banyak kasus, data yang terperinci tidaklah disimpan secara online tetapi dapat disediakan melalui agregasi data pada tingkatan detil berikutnya.
7.
Lightly and Highly Summarized Data Area ini menyimpan semua data lightly dan highly summarized (teragregasi) yang dihasilkan oleh warehouse manager. Area ini adalah tempat penampungan sementara sebelum dilakukan perubahan secara berkelanjutan untuk merespon perubahan profil query. Tujuan informasi ringkasan adalah untuk mempercepat pencapaian query. Meskipun biaya operasi akan meningkat
17 sehubungan dengan proses peringkasan data tersebut, namun ini merupakan offset untuk melaksanakan operasi ringkasan ( seperti penyortiran dan pengelompokan ) secara terus-menerus untuk menjawab user query. Data ringkasan diperbaharui secara terusmenerus ketika ada data baru terisi ke dalam warehouse. 8.
Archive or Backup Data Area ini menyimpan semua detil dan ringkasan data untuk kepentingan archiving dan backup. Walaupun ringkasan data dibangun dari detil data, akan memungkinkan untuk membuat cadangan ringkasan data secara online jika data ini ditunjukkan melebihi penyimpanan waktu untuk detil data. Data ditransfer ke arsip penyimpanan seperti magnetic tape atau optical disk.
9.
Metadata Area ini menyimpan semua definisi metadata yang digunakan oleh semua proses di dalam warehouse. Metadata digunakan untuk berbagai tujuan termasuk :
Proses extract dan load - metadata digunakan untuk memetakan sumber data ke dalam pandangan umum data dalam warehouse.
Proses manajemen warehouse - metadata digunakan untuk mengotomatisasi pembuatan tabel ringkasan.
Sebagai bagian proses manajemen query - metadata digunakan untuk mengarahkan suatu query dengan sumber data yang tepat.
18 10.
End-Users Access Tools Tujuan menyediakan
prinsip informasi
data
warehousing
kepada
para
user
adalah
untuk
bisnis
untuk
pengambilan keputusan. Para user ini berinteraksi dengan warehouse menggunakan peralatan akses end-user. Ada 5 kelompok utama dari access tools :
Sebagai alat untuk laporan dan query.
Peralatan pengembangan aplikasi.
Executive Information System (EIS).
Online Analytical Processing (OLAP).
Data mining.
Gambar 2. 5 Arsitektur Data Warehouse (Connolly dan Begg, 2005, p1157)
19 2.2.4
Anatomi Data Warehouse a.
Data Warehouse Terpusat Berdasarkan Inmon (2005, p193), sebagian besar organisasi membangun dan memelihara lingkungan data warehouse terpusat tunggal. Pengaturan ini dilakukan karena memiliki beberapa alasan yaitu: 1.
Data dalam warehouse terintegrasi antar perusahaan dan gambaran terintegrasi digunakan hanya pada kantor pusat.
2.
Perusahaan mengoperasikan sebuah model bisnis terpusat.
3.
Volume data dalam data warehouse seperti sebuah penyimpanan tunggal yang terpusat.
4.
Sekalipun data dapat diintegrasikan, jika data diedarkan melalui banyak local sites, maka akan mempersulit pengaksesan.
b.
Data Warehouse Terdistribusi Menurut Inmon (2005, p193-194), tiga tipe dari data warehouse terdistribusi : 1.
Bisnis terdistribusi secara geografis atau dibedakan menurut garis produk. Oleh karena hal tersebut, maka disebutlah data warehouse lokal dan data warehouse global. Data warehouse lokal mewakili data dan proses di lokasi yang terpencil dan data warehouse global mewakili bagian dari bisnis yang diintegrasikan melalui keseluruhan bisnis.
20 2.
Lingkungan data warehouse akan memegang banyak data dan volume data akan didistribusikan melalui beberapa prosesor. Secara logikal hanya ada satu data warehouse, tetapi secara fisikal terdapat banyak data warehouse yang semuanya mempunyai hubungan yang dekat tetapi diletakkan pada prosesor yang terpisah. Konfigurasi ini dapat
disebut
dengan
teknologi
data
warehouse
terdistribusi. 3.
Lingkungan data warehouse tumbuh dalam sebuah kebiasaan yang tidak terorganisasi. Data warehouse yang pertama
muncul,
kemudian
diikuti
yang
lainnya.
Kurangnya koordinasi dari pertumbuhan data warehouse yang berbeda biasanya menghasilkan sebuah perbedaan secara politik dan organisasi. Kasus ini dapat disebut dengan data warehouse terdistribusi yang secara bebas berkembang.
2.2.5
Struktur Data Warehouse Berdasarkan
Inmon
(2005,
p33-34),
gambar
di
bawah
menunjukkan level detil yang berbeda dalam data warehouse. Terdapat older level of detail (biasanya berganti-ganti, penyimpanan bulk), current level of detail, level of lightly summarized data (level data mart), dan level of highly summarized data. Data mengalir ke dalam data warehouse dari lingkungan operasional. Biasanya transformasi penting dari data
21 terjadi pada jalur dari level data operasional ke level data warehouse.
Gambar 2. 6 Struktur Data dalam Data Warehouse (Inmon, 2005, p34)
Sekali data disimpan, data melalui current detail ke older detail. Selama data diringkas, data melalui current detail ke lightly summrized data, kemudian dari lightly summarized data ke highly summarized data.
2.2.6
Data Warehouse Data Flows Menurut Connolly dan Begg (2005, p1162), data warehouse fokus pada manajemen lima arus data primer yaitu : 1.
Inflow adalah proses ekstraksi, pembersihan dan pengisian data dari sumber data ke dalam data warehouse.
2.
Upflow adalah penambahan nilai ke dalam data di dalam data warehouse melalui peringkasan, pemaketan, dan distribusi data.
22 3.
Downflow adalah proses mengambil dan mem-backup data dalam data warehouse.
4.
Outflow adalah proses membuat data agar tersedia bagi end-user.
5.
Metaflow adalah proses memanajemen metadata.
2.2.7 Perbandingan Data Warehouse dengan OLTP Menurut Vieira (2000, p892), sistem OLTP didesain untuk memungkinkan
konkurensi
yang
tinggi,
memungkinkan
banyak
pengguna untuk mengakses sumber data yang sama dan mengarahkan pemrosesan yang mereka inginkan. Sistem ini memungkinkan transaksi mengontrol perubahan terhadap data dalam tabel, melakukan insert, update dan delete ketika mengarahkan proses bisnis untuk diproses dalam database. Menurut Connolly dan Begg (2005, p1153), biasanya sebuah organisasi mempunyai beberapa sistem Online Transaction Processing (OLTP) yang berbeda untuk setiap proses bisnis, seperti pengawasan persediaan, pesanan pelanggan dan tingkat penjualan. Sistem ini menghasilkan data operasional yang detil, terbaru, dan selalu berubah. Sistem OLTP akan optimal jika digunakan untuk transaksi dalam jumlah besar yang dapat diramalkan, berulang, dan sering diperbaharui. Data OLTP
diorganisasikan
berdasarkan
syarat-syarat
dari
transaksi
dihubungkan dengan aplikasi bisnis dan mendukung keputusan per hari dalam sejumlah besar operasional user yang konkuren. Kontras dengan OLTP, umumnya organisasi hanya mempunyai
23 satu data warehouse yang menyimpan data secara historis, detil dan ringkasan dengan beberapa tingkatan dan sangat jarang berubah. Data warehouse didesain untuk mendukung transaksi yang tidak dapat diramalkan, dan memerlukan jawaban untuk query ad hoc, tidak terstruktur dan heuristic. Data warehouse diorganisasikan berdasarkan pada syarat-syarat query yang potensial dan mendukung keputusan strategis jangka panjang dari sejumlah kecil user tingkat manajerial. Tabel 2. 1 Perbandingan OLTP dan Data Warehouse (Connolly dan Begg, 2005, p1153)
2.2.8 Tahapan Membangun Data Warehouse Berdasarkan kutipan dalam Connolly dan Begg (2005, p11871193), metodologi yang dikemukakan oleh Kimball dalam membangun data warehouse ada 9 tahapan, dikenal dengan Nine-step Methodology. Sembilan tahapan tersebut adalah : 1. Memilih Proses (Choosing the process) Proses menunjuk pada subyek yang ada dari sebuah bagian data mart. Data mart pertama yang akan dibangun harus tepat waktu, disesuaikan dengan anggaran dan menjawab pertanyaan bisnis yang
24 banyak diutarakan. 2. Memilih Grain (Choosing the grain) Memilih grain berarti menentukan secara tepat apa yang direpresentasikan oleh record pada tabel fakta. Sebagai contoh PropertySale merepresentasikan fakta mengenai setiap penjualan properti dan menjadi tabel fakta dari skema bintang PropertySale Oleh karena itu, grain dari tabel fakta PropertySale adalah penjualan properti itu sendiri. Ketika grain dari tabel fakta dipilih, dimensi dapat diidentifikasi dari tabel fakta. Sebagai contoh Branch, Staff, Owner, ClientBuyer, PropertyForSale, dan Promotion entity akan digunakan untuk tabel dimensi pada skema bintang. Tabel dimensi Time termasuk dalam dimensi utama yang selalu ada dalam skema bintang. Memutuskan grain untuk tabel fakta juga menentukan grain untuk setiap tabel dimensi. Misalnya, grain pada tabel fakta PropertySale adalah setiap penjualan properti itu sendiri, kemudian grain pada dimensi Client adalah detil dari klien yang membeli properti. 3. Identifikasi dan Penyesuaian Dimensi (Identifying and conforming the dimensions) Dimensi menetapkan konteks pertanyaan mengenai fakta dalam tabel fakta. Kumpulan dimensi yang baik membuat data mart mudah dimengerti dan digunakan. Dimensi diidentifikasikan dengan detil untuk menjelaskan suatu hal seperti client dan properti pada
25 grain
yang
tepat.
Sebagai
contoh
dimensi
client
buyer
mendeskripsikan atribut ID, nama, tipe, kota, area dan negara. 4. Memilih Fakta (Choosing the Fact) Grain dari tabel fakta menentukan fakta yang bisa digunakan. Misalnya, grain dari tabel fakta adalah setiap penjualan properti, kemudian semua fakta numerik harus menunjuk pada penjualan ini. Fakta-fakta tersebut harus numerik dan dapat ditambah. 5. Menyimpan Pre-Calculation pada Tabel Fakta (Storing precalculation in the fact-table) Setelah fakta-fakta dipilih maka dilakukan pengkajian ulang untuk menentukan apakah ada fakta-fakta yang dapat diterapkan untuk pre-calculation (kalkulasi awal). Contoh umum dari kebutuhan untuk penyimpanan pre-calculation muncul ketika fakta berisi pernyataan untung atau rugi. Situasi ini akan meningkat ketika tabel fakta didasarkan pada invoice atau sales. 6. Rounding Out the Dimension Table Dalam langkah ini, kembali pada dimension table dan menambahkan gambaran teks terhadap dimensi yang memungkinkan. Gambaran teks harus mudah digunakan dan dimengerti oleh user. Kegunaan suatu data mart ditentukan oleh lingkup dan atribut tabel dimensi. 7. Memilih durasi dari basis data (Choosing the duration of the database) Durasi mengukur seberapa jauh waktu tabel fakta berjalan.
26 Sebagai contoh, perusahaan asuransi memiliki kebutuhan untuk menyimpan data dalam jangka waktu 5 tahun atau lebih. Tabel fakta yang sangat besar menimbulkan dua persoalan. Pertama, semakin tua umur data, akan muncul masalah pembacaan dan interpretasi file lama. Kedua, menimbulkan kemungkinan versi dimensi lama digunakan, bukan versi terbarunya. Hal ini akan dibahas lebih lanjut pada tahap delapan ” Tracking slowly changing dimensions”. 8. Melacak perubahan dari dimensi secara perlahan (Tracking slowly changing dimensions) Mengamati perubahan dari dimensi pada dimension table. Ada tiga tipe dasar dari perubahan dimensi yang perlahan, yaitu Tipe 1, di mana atribut dimensi yang diubah dituliskan ulang; Tipe 2, di mana atribut dimensi yang diubah menyebabkan pembentukan record baru; dan Tipe 3, di mana atribut dimensi yang diubah mengakibatkan sebuah atribut atau kolom alternatif dibuat, jadi antara record yang lama dan baru diakses secara bersama-sama. 9. Memutuskan prioritas dan mode dari query (Deciding the query priorities and the query modes) Mempertimbangkan pengaruh dari rancangan fisik, seperti penyortiran urutan tabel fakta pada disk dan keberadaan dari penyimpanan
awal
ringkasan
(summaries)
atau
penjumlahan
(aggregate). Selain itu, masalah administrasi, backup, kinerja indeks, dan keamanan juga merupakan faktor yang harus diperhatikan.
27 2.2.9
Dimensionality Modeling Menurut Connolly dan Begg (2005, p1183), pemodelan dimensi (dimensionality modeling) adalah teknik desain logikal yang bertujuan untuk
menampilkan
dalam
bentuk
standar
dan
intuitif
yang
memungkinkan untuk menampilkan akses tingkat tinggi. Pemodelan dimensi menggunakan konsep Entity-Relationship (ER) modeling dengan beberapa batasan penting. Setiap dimensional model (DM) dibuat dari satu tabel dengan composite primary key yang disebut tabel fakta (fact table) dan seperangkat tabel yang lebih kecil yang disebut tabel dimensi (dimension table). Setiap tabel dimensi memiliki
sebuah
primary
key
sederhana
(non-composite)
yang
berhubungan secara langsung dengan satu dari komponen dalam composite key dalam tabel fakta. Dengan kata lain, primary key dari tabel fakta dibuat dari dua atau lebih foreign key. Struktur karakteristik ‘seperti bintang’ ini disebut skema bintang (star schema atau star join). Fitur penting lain dari DM adalah seluruh key alami yang digantikan dengan surrogate key. Hal ini berarti setiap penggabungan antara tabel fakta dan tabel dimensi didasarkan pada surrogate key, bukan key alami. Setiap surrogate key harus memiliki struktur tergeneralisasi didasarkan pada integer sederhana. Kegunaan dari surrogate key memungkinkan data dalam warehouse untuk mempunyai independensi dari data yang digunakan dan dihasilkan oleh sistem OLTP. •
Skema Bintang
28 Menurut Connolly dan Begg (2005, p1183), skema bintang (star schema) adalah struktur logikal yang mempunyai sebuah tabel fakta berisi data faktual yang ditempatkan di tengah, dikelilingi oleh tabel dimensi berisi data referensi (yang dapat didenormalisasi). Skema bintang mengeksploitasi karakteristik dari data faktual di mana fakta dibuat dari peristiwa yang muncul di masa lalu dan mustahil untuk berubah, dengan mengabaikan bagaimana mereka dianalisis. Kebanyakan fakta yang digunakan dalam tabel fakta adalah angka dan additive karena aplikasi data warehouse tidak pernah diakses sebagai sebuah record tunggal, tetapi mereka diakses ratusan, ribuan bahkan jutaan record pada suatu waktu dan hal yang paling berguna untuk dilakukan dengan record
yang
begitu
banyak
tersebut
adalah
dengan
mengagregasikan mereka. Tabel dimensi, berisi deksripsi informasi berupa teks. Skema bintang dapat digunakan untuk mempercepat kinerja query dengan denormalisasi informasi ke dalam sebuah tabel dimensi. Denormalisasi tepat ketika terdapat sejumlah entity yang berhubungan dengan tabel dimensi yang sering diakses, menghindari overhead dari penggabungan tabel tambahan untuk mengakses atribut. Denormalisasi tidak tepat di mana data tambahan tidak sering diakses, karena overhead table dimensi yang diperluas tidak mungkin offset oleh berbagi perolehan dalam query.
29
Gambar 2. 7 Star Schema (Connolly dan Begg, 2005, p1184)
•
Skema Snowflake Terdapat variasi dari skema bintang yang disebut snowflake
schema,
yang
memungkinkan
dimensi
untuk
mempunyai dimensi. Snowflake schema adalah variasi dari skema bintang di mana tabel dimensi tidak berisi data yang dinormalisasi.
30
Gambar 2. 8 Snowflake Schema (Connolly dan Begg, 2005, p1185)
•
Skema Starflake Skema database yang paling tepat adalah dengan menggabungkan skema bintang yang didenormalisasi dan skema snowflake yang dinormalisasi. Kombinasi dari skema bintang dan snowflake ini disebut starflake schema.
2.2.10 Agregasi Menurut Mallach (2000, p514), agregasi adalah serangkaian elemen yang berhubungan dengan beberapa dimensi dari basis data. Toko memiliki kemungkinan diagregasikan dalam area, hari dapat diagregasi dalam minggu, bulan dan kuartal, serta produk dapat diagregasi dalam kategori.
31 2.2.11 Denormalisasi Menurut Vieira (2000, p252), normalisasi adalah suatu hal yang desainer database kadang pakai berseberangan. Ini dikembalikan kepada kepercayaan mereka dan mereka mulai menormalisasi data untuk kepentingan normalisasi daripada untuk hal yang baik untuk database mereka. Ada sejumlah hal yang perlu dipertimbangkan tentang tanggapan ini : •
Jika mendekalarasikan sebuah kolom yang dihitung atau menyimpan beberapa
data
yang
diturunkan
akan
memungkinkan
untuk
menjalankan laporan lebih efektif, kemudian seluruhnya ditempatkan kedalamnya. •
Terkadang dengan memasukkan hanya satu (atau lebih) kolom yang didenormalisasi dalam sebuah tabel, dapat mengeliminasi atau secara signifikan mengurangi sejumlah penggabungan penting untuk mengambil informasi
•
Jika menyimpan data historis, data akan semakin besar tanpa perubahan dan hanya digunakan untuk laporan. Kemudian isu integritas menjadi pertimbangan yang lebih kecil. Ketika data ditulis ke dalam area yang hanya dapat dibaca dan diverifikasi, maka secara pasti tidak akan mendapat masalah “out of sync” yaitu salah satu masalah besar dalam menempatkan normalisasi data. Pada titik ini, akan lebih baik (dan cepat) untuk “flatten”(denormalisasi) data ke dalam sejumlah tabel dan kecepatan akan meningkat.
32 •
Sejumlah tabel yang digabungkan, memudahkan pengguna yang akan membuat laporan. Pengguna akan menjadi semakin mengerti tools yang mereka gunakan. Pengguna akan datang ke DBA mereka dan menanyakan akses langsung ke dalam database untuk memungkinkan mereka membuat laporan sendiri. Untuk pengguna tersebut, database yang dinormalisasi secara tinggi dapat seperti jalur yang kompleks dan menjadi kurang berguna secara virtual. Denormalisasi data dapat membuat kemudahan bagi pengguna ini.
2.3
Produksi Menurut Wignjosoebroto (2003,p2), aktivitas produksi dinyatakan sebagai sekumpulan aktivitas yang diperlukan untuk mengubah satu kumpulan masukkan (human respurces, materials, energy, information, dll) menjadi produk keluaran (finished product atau service) yang memiliki nilai tambah. Di dalam proses produksi akan terjadi suatu proses perubahan bentuk (transformasi) dari input yang dimasukkan baik secara phisik maupun non phisik. Di sini akan terjadi pada apa yang disebut dengan pemberian nilai tambah (value added) dari input material yang diolah.
2.4
Pembelian Menurut Mulyadi (2001,p299), pembelian adalah suatu usaha pengadaan barang yang diperlukan perusahaan. Fungsi yang terkait dengan pembelian adalah : •
Fungsi Gudang
33 Bertanggung jawab untuk mengajukan permintaan pembelian sesuai dengan posisi persediaan barang yang ada di gudang dan untuk menyimpan barang yang telah diterima oleh fungsi penerimaan. •
Fungsi Pembelian Bertanggung jawab untuk memperoleh informasi mengenai harga barang. Menentukan pemasok yang dipilih dalam pengadaan barang dan mengeluarkan order pembelian kepada pemasok yang dipilih.
•
Fungsi Penerimaan Bertanggung jawab untuk melakukan pemeriksaan terhadap jenis, mutu, dan kuantitas barang yang diterima dari pemasok guna menentukan dapat atau tidaknya barang tersebut diterima oleh perusahaan. Fungsi ini juga bertanggung jawab untuk menerima barang dari pembeli yang berasal dari transaksi retur penjualan.
•
Fungsi Akuntansi Fungsi yang terkait adalah fungsi pencatatan utang dan persediaan barang. Fungsi pencatatan utang berfungsi untuk mencatat transaksi ke dalam register bukti kas keluar. Fungsi persediaan barang bertanggung jawab untuk mencatat harga produksi barang yang dibeli ke dalam kartu persediaan.
2.5
Retur Pembelian Barang yang sudah diterima dari pemasok adakalanya tidak sesuai dengan barang yang dipesan menurut surat order pembelian. Ketidaksesuaian
34 tersebut terjadi kemungkinan karena barang yang diterima tidak cocok dengan spesifikasi yang tercantum dalam surat order pembelian, barang mengalami kerusakan dalam pengiriman, atau barang diterima melewati tanggal pengiriman yang dijanjikan oleh pemasok.
2.6
Penjualan Menurut Hollander, Denna dan Cherrington (2000, p230), penjualan adalah serangkaian kegiatan yang disajikan secara bersama-sama untuk menarik minat konsumen, membantu konsumen dalam memilih barang dan jasa, mengantarkan barang dan jasa yang dipesan serta menerima pembayaran dari barang dan jasa. Menurut Mulyadi (2001, p202), kegiatan penjualan terdiri dari transaksi penjualan barang atau jasa, baik secara kredit maupun tunai. 1.
Penjualan Kredit Penjualan kredit dilaksanakan oleh perusahan dengan cara mengirimkan barang sesuai order yang diterima dari pembeli dan untuk jangka waktu tertentu perusahan mempunyai tagihan kepada pembeli tersebut. Fungsi yang terkait dengan sistem penjualan kredit adalah : •
Fungsi Penjualan Fungsi ini bertanggung jawab untuk menerima surat order dari pembeli, meng-edit order dari pelanggan untuk menambahkan informasi yang belum ada pada surat order tersebut (seperti spesifikasi barang dan rute pengiriman), meminta otorisasi kredit, menentukan tanggal pengiriman dan dari gudang mana barang
35 akan dikirim, dan mengisi surat order pengiriman. •
Fungsi Kredit Fungsi ini bertanggung jawab untuk meneliti status kredit pelanggan dan memberikan otorisasi pemberian kredit kepada pelanggan.
•
Fungsi Gudang Fungsi ini bertanggung jawab untuk menyimpan barang dan menyiapkan
barang
yang
dipesan
oleh
pelanggan
serta
menyerahkan barang ke fungsi pengiriman. •
Fungsi Pengiriman Fungsi ini bertanggung jawab untuk menyerahkan barang atas dasar surat order pengiriman yang diterimanya dari fungsi penjualan. Fungsi bertanggung jawab untuk menjamin bahwa tidak ada barang yang keluar dari perusahaan tanpa ada otorisasi dari yang berwenang.
•
Fungsi Penagihan Fungsi ini bertanggung jawab untuk membuat dan mengirimkan faktur penjualan kepada pelanggan, serta menyediakan copy faktur bagi kepentingan pencatatan transaksi penjualan oleh fungsi akuntansi.
•
Fungsi Akuntansi Fungsi ini bertanggung jawab untuk mencatat piutang yang timbul dari transaksi penjualan kredit dan membuat serta mengirimkan
36 pernyataan piutang kepada para debitur, serta membuat laporan penjualan.
2.
Penjualan Tunai Menurut Mulyadi (2001, p455), penjualan tunai dilaksanakan oleh perusahaan dengan cara mewajibkan pembeli melakukan pembayaran barang dahulu terhadap perusahaan sebelum barang diserahkan oleh perusahaan kepada pembeli. Setelah uang diterima, barang kemudian diserahkan oleh perusahaan kepada pembeli dan transaksi penjualan tersebut dicatat. Fungsi yang terkait dalam sistem penerimaan kas dari penjualan tunai : •
Fungsi Penjualan Fungsi ini bertanggung jawab untuk menerima order dari pembeli, mengisi faktur penjualan tunai dan menyerahkan faktur tersebut kepada pembeli untuk kepentingan pembayaran harga barang ke fungsi kas
•
Fungsi Kas Fungsi ini bertanggung jawab sebagai penerima kas dari pembeli.
•
Fungsi Gudang Fungsi ini bertanggung jawab untuk menyiapkan barang yang dipesan oleh pembeli, serta menyerahkan barang tersebut ke fungsi pengiriman.
•
Fungsi Pengiriman
37 Fungsi ini bertanggung jawab untuk membungkus barang dan menyerahkan barang tersebut ke pembeli. •
Fungsi Akuntansi Fungsi ini bertanggung jawab sebagai pencatat transaksi penjualan dan peneriamaan kas.
2.7
Retur Penjualan Transaksi retur penjualan terjadi jika perusahaan menerima pengembalian barang dari pelanggan.
