7

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.

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 non-

volatile. 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 Sistem Data warehouse

Tujuan utama Mendukung proses operasional

Mendukung proses analisa

Umur data Saat ini Historikal Latensi data Real time Tergantung pada panjang

siklus untuk suplement data ke data warehouse

Glanularitas data

Data yang detil Data yang detil, ringkasan data yang ringan dan berat.

Proses data Tingkat arus data yang tinggi pada transaksi, pola yang terprediksi dari data insert, updates, delete dan query

Tingkat arus data yang rendah atau sedang pada transaksi, pola yang tidak terprediksi dari data query-nya.

Laporan Terprediksi, satu dimensi, laporan yang tetap dan statis

Tidak terprediksi, multidimensional, laporan yang menarik

Users Melayani sejumlah pengguna operasional yang banyak

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 ini

dikonstruksikan dengan menggunakan vendor data management dan

custom built program. Operasi–operasi yang dilakukan 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 entitas-

entitas 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 tunggal-

kolom. 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

1

Activity

Memperlihatkan bagaimana masing-

masing kelas antarmuka saling

berinteraksi satu sama lain

2

Action State dari sistem yang mencerminkan

eksekusi dari suatu aksi

3 Initial Node Bagaimana objek dibentuk atau

diawali

54

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:

4 Activity

Final Node

Bagaimana objek dibentuk dan

dihancurkan

5 Fork Node Satu aliran yang pada tahap tertentu

berubah menjadi beberapa aliran

6

Dependency

Hubungan dimana perubahan yang

terjadi pada suatu elemen mandiri

(independent) akan mempegaruhi

elemen yang bergantung padanya

elemen yang tidak mandiri

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 ke-

R = 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 ke-

R = 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