i
PEMBANGUNAN GUDANG DATA TRANSAKSI PENJUALAN DI TOKO BUKU AB
SKRIPSI
Diajukan Untuk Memenuhi Salah Satu Syarat Memperoleh Gelar Sarjana Komputer
Program Studi Teknik Informatika
Oleh :
Monica Susi Diatma Sari NIM : 115314061
PROGRAM STUDI TEKNIK INFORMATIKA JURUSAN TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS SANATA DHARMA YOGYAKARTA
ii
THE DATA WAREHOUSE DEVELOPMENT OF SALES TRANSACTIONS IN AB BOOKSTORE
A THESIS
Presented as Partial Fulfillment of the Requirements to Obtain the Sarjana Komputer Degree in Informatics Engineering Study Program
By :
Monica Susi Diatma Sari 115314061
INFORMATICS ENGINEERING STUDY PROGRAM DEPARTMENT OF INFORMATICS ENGINEERING
FACULTY OF SCIENCE AND TECHNOLOGY SANATA DHARMA UNIVERSITY
iii
HALAMAN PERSETUJUAN SKRIPSI
PEMBANGUNAN GUDANG DATA TRANSAKSI PENJUALAN DI TOKO BUKU AB
Oleh :
Monica Susi Diatma Sari NIM : 115314061
Telah disetujui oleh:
Pembimbing
iv
HALAMAN PENGESAHAN SKRIPSI PEMBANGUNAN GUDANG DATA TRANSAKSI PENJUALAN DI TOKO BUKU AB
Dipersiapkan dan ditulis oleh: Monica Susi Diatma Sari
115314061
Telah dipertahankan di depan Panitia Penguji Pada tanggal : 10 Januari 2017
Dan dinyatakan memenuhi syarat
Susunan Panitia Penguji
Nama Lengkap Tanda Tangan
Ketua : Drs. Haris Sriwindono, M.Kom. ……….
Sekretaris : JB. Budi Darmawan, S.T., M.Sc. ……….
Anggota : Paulina Heruningsih Prima Rosa, S.Si., M.Sc. ……….
Yogyakarta, Januari 2017
Fakultas Sains dan Teknologi
Universitas Sanata Dharma
Dekan,
v
vi
PERNYATAAN KEASLIAN KARYA
Saya menyatakan dengan sesungguhnya bahwa di dalam skripsi yang saya tulis ini tidak dimuat karya atau bagian karya orang lain, kecuali yang telah disebutkan dalam kutipan dan daftar pustaka, sebagaimana layaknya karya ilmiah.
Yogyakarta, 10 Januari 2017 Penulis
vii
LEMBAR PERNYATAAN PERSETUJUAN
PUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS
Yang bertanda tangan di bawah ini, saya mahasiswa Universitas Sanata Dharma : Nama : Monica Susi Diatma Sari
Nomor Mahasiswa : 115314061
Demi pengembangan ilmu pengetahuan, saya memberikan kepada Perpustakaan Universitas Sanata Dharma karya ilmiah saya yang berjudul :
PEMBANGUNAN GUDANG DATA TRANSAKSI PENJUALAN DI TOKO BUKU AB
beserta perangkat yang diperlukan (bila ada). Dengan demikian saya memberikan kepada Perpustakaan Universitas Sanata Dharma hak untuk menyimpan, mengalihkan dalam bentuk media lain, mengelolanya dalam bentuk pangkalan data, mendistribusikan secara terbatas, dan mempublikasikannya di Internet atau media lain untuk kepentingan akademis tanpa perlu meminta izin dari saya maupun memberikan royalti kepada saya selama tetap mencantumkan nama saya sebagai penulis.
Demikian pernyataan ini saya buat dengan sebenarnya. Dibuat di Yogyakarta
Pada tanggal : Januari 2017
Yang menyatakan
viii ABSTRAK
Perkembangan zaman semakin pesat, begitu juga dengan perkembangan teknologi. Salah satu perkembangan teknologi yang dapat dirasakan semakin berkembang adalah teknologi informasi terutama mengenai teknologi penyimpanan data. Gudang data merupakan sekumpulan data yang terintegrasi, basis data berorientasi subyek yang dibangun untuk mendukung fungsi sistem pengambilan keputusan.
Dalam tugas akhir ini teknologi gudang data digunakan untuk mengintegrasikan data transaksi penjualan yang terdapat di Toko Buku AB. Pembangunan gudang data sendiri digunakan untuk membantu Kepala Toko dalam melakukan pemantauan transaksi penjualan yang terjadi, serta menentukan barang dan kategori yang harus dipesan ke supplier dan penerbit. Gudang data yang terbentuk selanjutnya diproses menjadi database Online Analytical Processing (OLAP) menggunakan Kettle Pentaho dan model dimensional menggunakan Star Schema. Dari gudang data yang sudah terbentuk dapat dihitung jumlah penjualan setiap tahun, berdasar beberapa dimensi yaitu waktu, kategori, topik, penerbit, supplier, dan barang.
Pembangunan gudang data transaksi penjualan ini dievaluasi oleh Kepala Toko Buku AB. Hasil evaluasi menunjukkan bahwa menurut kepala toko, sistem ini telah memenuhi keinginan pengguna dan dapat digunakan untuk membantu dalam memantau data jumlah penjualan berdasarkan barang, supplier dan penerbit.
ix ABSTRACT
Technological development lasts as fast as time goes by. One of the technological developments that can be felt increasing rapidly is information technology, especially information regarding data warehouse technology. A data warehouse is a set of integrated data, subject oriented database which is built to support the function of decision making system.
In this final project, data warehouse technology is used to integrated the sales transaction data in AB Book store. The building of data warehouse is used to help the Chairman of the store in observing the sales transaction and determine the items and the categories that should be ordered to the suppliers and publishers. The data warehouse then processed to be database Online Analytical Processing (OLAP) by using Kettle Pentaho and Star Schema dimensional model. Using the formed data warehouse, the amount of the annual sales can be counted based on several dimensions namely time, categories, topics, publishers, suppliers, and goods.
The building of this sales transaction data warehouse was evaluted by the chairman of AB Bookstore. The evaluation result shows that according to the chairman this system has fulfilled the whises of the users and can be used help in observing data on sales amount based on the goods, suppliers, and publishers.
x
KATA PENGANTAR
Puji syukur kepada Allah Bapa, Bunda Maria dan Tuhan Yesus, karena berkat rahmat dan karunia-Nya penulis dapat menyelesaikan penulisan skripsi ini. Banyak proses yang harus dilewati penulis dalam penyusunan skripsi ini baik segala hambatan dan keceriaan agar skripsi ini dapat disusun dengan baik.
Dalam penulisan skripsi ini tidak lepas dari bantuan berbagai pihak. Untuk itu penulis ingin menyampaikan ucapan terima kasih yang sebesar-besarnya kepada semua pihak yang telah membantu penulis selama proses penyusunan skripsi. Penulis mengucapkan terima kasih yang sebesar-besarnya kepada:
1. Bapak Sudi Mungkasi, S.Si., Math.SC., Ph.D.
Selaku Dekan Fakultas Sains dan Teknologi Universitas Sanata Dharma. 2. Ibu Dr. Anastasia Rita Widiarti, S.Si., M.Kom.
Selaku Kepala Program Studi Teknik Informatika Fakultas Sains dan Teknologi Universitas Sanata Dharma.
3. Ibu Paulina Heruningsih Prima Rosa, S.Si., M.Sc.
Selaku Dosen Pembimbing skripsi. Terima kasih banyak Bu Rosa atas waktu, perhatian, kesabaran, cinta kasih, saran, kritik, dan pemikiran sehingga penulis dapat menyelesaikan skripsi.
4. Bapak Drs. Haris Sriwindono, M.Kom.
Selaku dosen penguji. Terima kasih atas segala saran dan kritik yang diberikan untuk lebih menyempurnakan skripsi ini.
5. Bapak JB. Budi Darmawan, S.T., M.Sc.
Selaku dosen penguji. Terima kasih atas segala saran dan kritik yang diberikan untuk lebih menyempurnakan skripsi ini.
6. Bapak Puspaningtyas Sanjoyo Adi, M.T.
xi 7. Ibu Ridowati Gunawan, S.Kom., M.T.
Terima kasih atas waktu, dukungan, solusi dalam menyelesaikan skripsi. 8. Mas Yanuar dan Mbak Yuvita (mb yupi) yang selalu memberikan bantuan
kepada penulis dalam penyelesaian skripsi.
9. Segenap dosen dan karyawan Universitas Sanata Dharma yang telah membantu selama penyelesaian skripsi ini.
10.Bapakku Antonius Sarina dan Ibuku Christiana Sri Suyatmi tercinta atas segala kasih, kekuatan, kesabaran, perhatian, semangat, dukungan serta doa yang telah diberikan kepada Penulis.
11.Kakakku Veronika Tina Ariatmi dan Franciska Williasari tersayang atas segala doa dan dukungan yang diberikan kepada Penulis.
12.Simbok Kedah dan keluarga atas semua kasih sayang, doa, dan bantuan yang diberikan dari masa kecilku sampai saat ini.
13.Keponakanku William Adrian dan Fideliya Athania untuk keceriaan, tangis yang selalu membangunkan dari tidur, dan semangat yang diberikan kepada Penulis.
14.Keluarga Simbah Kakung Somo Pawiro, serta Simbah Pawiro Suwiryo atas segala dukungan dan doa yang diberikan kepada Penulis.
15.Eyang Kakung, terima kasih atas segala bantuan, semangat dan motivasi yang diberikan kepada Penulis.
16.Bu Rusmini dan Mb Sinta atas bantuan yang diberikan kepada Penulis. 17.Cornellis Hutomo Suryolaksono (mas tomi) atas segala bantuan dan
referensi yang tak terhingga diberikan kepada Penulis.
18.Maria Yosephine Dwi Unceniana Fernandez (mbak manez) atas segala bantuan dan referensi yang tak terhingga diberikan kepada Penulis.
19.D. Ronny Dwiharyanto (mas ronny) atas segala bantuan dan referensi yang tak terhingga diberikan kepada Penulis.
20.Setiawan Wasito (mas wawan) atas segala bantuan dan referensi yang tak terhingga diberikan kepada Penulis.
xii
22.Julius Anggit Dwiantoro, Petrus Indra Wijayanto, Isidorus Cahyo Adi Prasetyo, Gilang Abi Saputro, dan Bimo Santoso Aji atas bantuan, curhat, dukungan, waktu yang diberikan kepada Penulis.
23.Teman-teman TI 2011. Meity, Karmelia, Ari, Beni (benpras), Bulan, Drajad, Dhiah (bu haji), Winda, Priska, Bee, Agung, Febri, Dyah Utami, Bayu (pak polisi), Widi, Dion (pakdhe), Ria, Sisil, Rosi, Danik, Elsa (amoypocari), Lukas, Bayu (gendhut), Aan, Whisnu, Marlina, Steve, Tungky. Terima kasih atas kebersamaan dan persahabatan selama ini. 24.Mb Intan dan Mb Sita atas kebersamaan dan persahabatan ini.
25.Brigita Cintya (dik tya), Monica Rintan, Mb Dea, Iin, Ni Putu, Riyadhalah, Tri Pina, Lukas Bayu atas dukungan dan bantuan yang diberikan kepada Penulis.
26.Teman-teman bimbingan skripsi Bu Rosa atas dukungan, bantuan, doa yang telah diberikan kepada Penulis.
27.Yosephine Rheni dan Natalia Merry atas persahabatan yang tulus, bantuan, semangat yang diberikan kepada Penulis.
28.Yuni Br Tarigan dan Mersy Cahyati, kebersamaan dikost “Asri” tercinta, bantuan, curhat, suka duka dan dukungan, yang diberikan kepada Penulis. 29.Ibu Edy, selaku pemilik kost Asri atas doa dan izin telah diberikan
kenyamanan tempat tinggal selama kuliah kepada Penulis.
30.Teman-teman kost “Asri” : Mb Devi Mb Tia Mb Tata (alumni kost asri), Zena, Enda, Ipen, Oi, Savent, Gege, Angel, Putri, atas segala dukungan dan suka duka yang diberikan kepada Penulis.
31.Semua teman dan sahabat yang tak dapat penulis sebutkan satu per satu, terima kasih atas doa dan dukungannya semoga selalu mendapatkan karunia dari Tuhan.
Penulis menyadari bahwa masih banyak kekurangan yang terdapat dalam penyusunan skripsi ini, akan tetapi penulis berharap agar skripsi ini dapat bermanfaat bagi penulis maupun pembaca sekalian.
xiii DAFTAR ISI
HALAMAN JUDUL ... i
HALAMAN JUDUL INGGRIS ... ii
HALAMAN PERSETUJUAN ... iii
HALAMAN PENGESAHAN ... iv
HALAMAN PERSEMBAHAN ... v
PERNYATAAN KEASLIAN KARYA ... vi
HALAMAN PERSETUJUAN PUBLIKASI KARYA ILMIAH ... vii
ABSTRAK ... viii
ABSTRACT ... ix
KATA PENGANTAR ... x
DAFTAR ISI ... xiii
DAFTAR GAMBAR ... xviii
DAFTAR TABEL ... xxiv
BAB I PENDAHULUAN ... 1
1.1. Latar Belakang ... 1
1.2. Rumusan Masalah ... 2
1.3. Tujuan Penelitian... 2
xiv
1.5. Metodologi Penelitian ... 3
1.6. Sistematika Penulisan ... 4
BAB II LANDASAN TEORI ... 6
2.1. Konsep Dasar Data Warehouse ... 6
2.1.1. Pengertian Data ... 6
2.1.2. Pengertian Gudang Data... 6
2.1.3. Karakteristik Gudang Data ... 7
2.1.4. Arsitektur Gudang Data ... 8
2.1.5. Metadata ... 11
2.1.6. Denormalisasi ... 11
2.1.7. Manfaat Gudang Data ... 12
2.1.8. Langkah Pembuatan Gudang Data ... 13
2.2. Extract, Transform, dan Load ... 14
2.2.1. Pengertian ETL ... 14
2.2.2. Proses dalam Extract, Transform, Load ... 14
2.3. Model Data Multidimensi ... 15
2.3.1. Model Dimensional ... 15
2.3.2. Skema Bintang ... 16
2.3.3. Kelebihan Menggunakan Skema Bintang ... 17
2.3.4. Kekurangan Menggunakan Skema Bintang ... 18
2.3.5. Skema Butiran Salju (Snowflake) ... 19
2.3.6. Kelebihan Menggunakan Skema Snowflake ... 20
xv
2.3.8. Cube, Dimension, Measure, dan Member ... 21
2.3.9. Surrogate Key ... 21
2.4. Online Analytical Processing ... 22
2.4.1. Pengertian Online Analytical Processing (OLAP)... 22
2.4.2. Online Transaction Processing (OLTP) ... 22
2.4.3. Perbedaan OLTP dan OLAP ... 23
2.5. Pentaho Data Integration (Kettle) ... 24
2.5.1. Pengertian Pentaho ... 24
2.5.2. Kettle ... 24
2.6. Mondrian ... 28
BAB III ANALISIS DAN PERANCANGAN ... 29
3.1. Identifikasi Masalah dan Analisis Kebutuhan ... 29
3.2. Pemrosesan Awal ... 31
3.2.1 Struktur Tabel Basis Data Toko Buku AB ... 31
3.2.2 Restrukturisasi Tabel ... 40
3.2.3 Pembersihan Data ... 48
3.2.4 Transformasi Data ... 48
3.3. Analisis Kebutuhan Gudang Data ... 49
3.3.1 Use Case ... 49
3.3.2 Narasi Use Case ... 50
3.4. Pembuatan Gudang Data ... 52
3.4.1 Membaca data legacy ... 52
xvi
3.4.3 Memecah gudang data ke dalam dimensi dan tabel fakta ... 58
3.5. Rancangan MDX Kueri untuk Cube Fact_Penjualan ... 62
3.6. Perancangan Antar Muka ... 62
BAB IV IMPLEMENTASI ... 65
4.1. Implementasi Arsitektur Gudang Data ... 65
4.2. Langkah Pembuatan Gudang Data ... 66
4.2.1 Membaca Data Legacy ... 66
4.2.2 Memindahkan Data ke Server Gudang Data ... 66
4.3. Memecah Gudang Data dalam Tabel Dimensi dan Tabel Fakta ... 81
4.3.1 Tabel Dimensi `dim_barang` ... 81
4.3.2 Tabel Dimensi `dim_penerbit` ... 84
4.3.3 Tabel Dimensi `dim_kategori` ... 87
4.3.4 Tabel Dimensi `dim_supplier` ... 89
4.3.5 Tabel Dimensi `dim_topik` ... 92
4.3.6 Tabel Dimensi `dim_waktu`... 95
4.3.7 Tabel Fakta `faktaku` ... 96
4.3.8 Job Transformasi Data ... 102
4.4. Pembentukan Skema Bintang Penjualan ... 104
4.4.1 Cube Penjualan ... 104
4.4.2 Skema MDX ... 107
4.5. Implementasi Antar Muka Pengguna ... 110
4.5.1 Halaman Login ... 110
xvii
BAB V ANALISIS HASIL ... 115
5.1 Penyelesaian Rumusan Masalah ... 115
5.2 Pengujian Cube ... 117
5.3 Kelebihan dan Kekurangan Sistem ... 125
BAB VI PENUTUP ... 127
6.1 Kesimpulan... 127
6.2 Saran ... 127
DAFTAR PUSTAKA ... 129
LAMPIRAN ... 131
LAMPIRAN 1 OLAP ... 132
LAMPIRAN 2 RESTRUKTURISASI TABEL ... 143
xviii
DAFTAR GAMBAR
Gambar 2.1 Arsitektur Data Warehouse ... 8
Gambar 2.2 Arsitektur Gudang Data ... 11
Gambar 2.3 Sistem Kerja Data Warehouse ... 15
Gambar 2.4 Contoh Star Schema ... 17
Gambar 2.5 Contoh Snowflake Schema... 20
Gambar 3.1 Struktur Tabel Basis Data Toko Buku AB ... 32
Gambar 3.2 Tabel data_barang ... 32
Gambar 3.3 Tabel data_beli ... 33
Gambar 3.4 Tabel data_jual ... 33
Gambar 3.5 Tabel detail_jual ... 34
Gambar 3.6 Tabel detail_beli ... 34
Gambar 3.7 Tabel supplier ... 35
Gambar 3.8 Tabel penerbit ... 35
Gambar 3.9 Tabel produk ... 36
Gambar 3.10 Tabel topik ... 36
Gambar 3.11 ER Diagram ... 37
Gambar 3.12 Database Logical Design ... 37
Gambar 3.13 Tabel data_barang ... 42
Gambar 3.14 Tabel data_beli ... 42
Gambar 3.15 Tabel data_jual ... 43
Gambar 3.16 Tabel detail_jual ... 43
Gambar 3.17 Tabel detail_beli ... 44
Gambar 3.18 Tabel supplier ... 45
Gambar 3.19 Tabel penerbit ... 45
Gambar 3.20 Tabel produk ... 46
Gambar 3.21 Tabel topik ... 46
Gambar 3.22 Hasil Restrukturisasi Basis Data monica_skripsi ... 48
xix
Gambar 3.24 Proses Pemindahan Tabel ms_barang ... 53
Gambar 3.25 Proses Pemindahan Tabel ms_penerbit ... 54
Gambar 3.26 Proses Pemindahan Tabel ms_kategori ... 55
Gambar 3.27 Proses Pemindahan Tabel ms_supplier ... 56
Gambar 3.28 Proses Pemindahan Tabel ms_topik ... 56
Gambar 3.29 Proses Pemindahan Tabel ms_transaksi ... 57
Gambar 3.30 Pembentukan dimensi barang ... 58
Gambar 3.31 Pembentukan dimensi penerbit ... 59
Gambar 3.32 Pembentukan dimensi produk ... 59
Gambar 3.33 Pembentukan dimensi supplier ... 60
Gambar 3.34 Pembentukan dimensi topik ... 60
Gambar 3.35 Tabel Fakta Faktaku ... 61
Gambar 3.36 Struktur MDX Kueri Untuk Laporan Transaksi Penjualan ... 62
Gambar 3.37 Halaman Login ... 63
Gambar 3.38 Halaman Home ... 63
Gambar 3.39 Halaman Transaksi Penjualan ... 64
Gambar 4.1 Arsitektur Gudang Data ... 65
Gambar 4.2 ms_transaksi.ktr ... 67
Gambar 4.3 Langkah Select Data ... 68
Gambar 4.4 Memilih Field Yang Digunakan ... 69
Gambar 4.5 Langkah Insert/Update ms_transaksi ... 69
Gambar 4.6 Output ms_transaksi ... 70
Gambar 4.7 ms_barang.ktr ... 70
Gambar 4.8 Langkah Select Data Barang ... 71
Gambar 4.9 Memilih Field Yang Digunakan ... 71
Gambar 4.10 Langkah Insert/Update ms_barang ... 72
Gambar 4.11 Output ms_barang ... 72
Gambar 4.12 ms_kategori.ktr ... 73
Gambar 4.13 Langkah Select Data Kategori ... 73
Gambar 4.14 Memilih Field Yang Digunakan ... 73
xx
Gambar 4.16 Output ms_kategori ... 74
Gambar 4.17 ms_topik.ktr ... 75
Gambar 4.18 Langkah Select Data Topik ... 75
Gambar 4.19 Memilih Field Yang Digunakan ... 75
Gambar 4.20 Langkah Insert/Update ms_topik ... 76
Gambar 4.21 Output ms_topik ... 76
Gambar 4.22 ms_penerbit.ktr ... 77
Gambar 4.23 Langkah Select Data Penerbit ... 77
Gambar 4.24 Memilih Field Yang Digunakan ... 77
Gambar 4.25 Langkah Insert/Update ms_penerbit... 78
Gambar 4.26 Output ms_penerbit ... 78
Gambar 4.27 ms_supplier.ktr ... 79
Gambar 4.28 Langkah Select Data Supplier ... 79
Gambar 4.29 Langkah Memilih Field ... 79
Gambar 4.30 Langkah Insert/Update ms_supplier ... 80
Gambar 4.31 Output ms_supplier ... 80
Gambar 4.32 Proses Pembuatan Dimensi dim_barang ... 81
Gambar 4.33 Langkah Select Data Barang dari ms_barang ... 82
Gambar 4.34 Preview Data ms_barang ... 82
Gambar 4.35 Langkah Membuat Surrogate Key Pada dim_barang ... 83
Gambar 4.36 Langkah Memilih Data pada Dim_Barang ... 83
Gambar 4.37 Tabel Dim_Barang ... 84
Gambar 4.38 Proses Pembuatan Dimensi dim_penerbit ... 84
Gambar 4.39 Langkah Select Data Penerbit dari ms_penerbit ... 85
Gambar 4.40 Preview Data ms_penerbit ... 85
Gambar 4.41 Langkah Membuat Surrogate Key pada dim_penerbit ... 86
Gambar 4.42 Langkah Memilih Data Pada Dim_Penerbit... 86
Gambar 4.43 Tabel dim_penerbit ... 87
Gambar 4.44 Proses Pembuatan Dimensi dim_kategori ... 87
Gambar 4.45 Langkah Select Data Kategori dari ms_kategori ... 87
xxi
Gambar 4.47 Langkah Membuat Surrogate Key Pada dim_kategori ... 88
Gambar 4.48 Langkah Memilih Data Pada Dim_Kategori ... 89
Gambar 4.49 Tabel dim_kategori ... 89
Gambar 4.50 Proses Pembuatan Dimensi dim_supplier ... 89
Gambar 4.51 Langkah Select Data Supplier dari ms_supplier ... 90
Gambar 4.52 Preview Data ms_supplier ... 90
Gambar 4.53 Langkah Membuat Surrogate Key Pada dim_supplier ... 91
Gambar 4.54 Langkah Memilih Data Pada Dim_Supplier ... 91
Gambar 4.55 Tabel Dim_Supplier ... 92
Gambar 4.56 Proses Pembuatan Dimensi dim_topik ... 92
Gambar 4.57 Langkah Select Data Topik dari ms_topik ... 92
Gambar 4.58 Preview Data ms_topik... 93
Gambar 4.59 Langkah Membuat Surrogate Key Pada dim_topik ... 93
Gambar 4.60 Langkah Memilih Data Pada Dim_Topik ... 94
Gambar 4.61 Tabel Dim_Topik ... 94
Gambar 4.62 Proses Pembuatan Dimensi dim_waktu ... 95
Gambar 4.63 Tabel dim_waktu ... 95
Gambar 4.64 Proses Pembuatan Tabel Fakta `faktaku` ... 96
Gambar 4.65 Langkah Select Data ms_transaksi ... 96
Gambar 4.66 Preview Data ms_transaksi... 97
Gambar 4.67 Langkah Menyamakan Data Dari Tabel Master Barang Dengan Data Dimensi Barang ... 97
Gambar 4.68 Langkah Menyamakan Data Dari Tabel Master Penerbit Dengan Data Dimensi Penerbit ... 98
Gambar 4.69 Langkah Menyamakan Data Dari Tabel Master Kategori Dengan Data Dimensi Kategori ... 98
Gambar 4.70 Langkah Menyamakan Data Dari Tabel Master Topik Dengan Data Dimensi Topik ... 99
xxii
Gambar 4.72 Langkah Menyamakan Data Dari Tabel Master Transaksi Dengan Data Dimensi Waktu ... 100 Gambar 4.73 Langkah Memilih Data Yang Diperlukan Untuk Membuat Tabel
xxiii
xxiv
DAFTAR TABEL
Tabel 2.1 Perbedaan OLTP dengan OLAP ... 23 Tabel 3.1 Contoh Transaksi Penjualan ... 30 Tabel 3.2 Tabel Barang_Komplit ... 38 Tabel 3.3 Tabel Kategori_Komplit ... 38 Tabel 3.4 Tabel Topik_Komplit ... 39 Tabel 3.5 Tabel Penerbit_Komplit ... 39 Tabel 3.6 Tabel Supplier_Komplit ... 39 Tabel 3.7 Tabel Transaksi_Komplit ... 40 Tabel 3.8 Tabel Detail_penjualan ... 40 Tabel 3.9 Deskripsi Diagram Use Case ... 49 Tabel 3.10 Narasi Use Case Login ... 50 Tabel 3.11 Narasi Use Case Melihat Laporan Transaksi Penjualan... 51 Tabel 3.12 Tabel ms_barang ... 54 Tabel 3.13 Tabel ms_penerbit ... 54 Tabel 3.14 Tabel ms_kategori ... 55 Tabel 3.15 Tabel ms_supplier ... 56 Tabel 3.16 Tabel ms_topik ... 57 Tabel 3.17 Tabel ms_transaksi ... 58 Tabel 4.1 Tabel Tools Kettle Yang Digunakan ... 67 Tabel 4.2 Deskripsi Skema MDX... 107 Tabel 4.3 Definisi Skema skripsi_monic.xml ... 108 Tabel 4.4 Source Code untuk Halaman Login (login.php) ... 111 Tabel 4.5 Source Code untuk Halaman Laporan Transaksi Penjualan ... 113
BAB I PENDAHULUAN
1.1. Latar Belakang
Toko buku AB merupakan salah satu cabang dari perusahaan percetakan dan penerbitan buku AB. Toko buku AB memberikan pelayanan seperti ritel umum, yaitu penjualan barang atau jasa kepada masyarakat salah satu diantaranya adalah transaksi penjualan. Transaksi penjualan merupakan kegiatan yang dilakukan perusahaan untuk menjual barang secara tunai maupun kredit.
Transaksi penjualan membutuhkan media penyimpanan data yang besar selain untuk menyimpan data transaksi, toko juga melakukan pembuatan laporan bulanan. Jika kepala toko buku berganti maka data dari tahun sebelumnya tidak dapat dilihat kembali karena bentuk penyimpanan data yang terbatas. Selain itu kepala toko buku membuat sendiri laporan transaksi penjualan dengan cara memindahkan berapa banyaknya total penjualan yang telah didapatkan ke dalam perhitungan excel. Transaksi penjualan meliputi semua barang, supplier, penerbit, topik, kategori, waktu serta jumlah penjualan dari waktu ke waktu. Hal ini membuat data mengenai banyaknya jumlah penjualan di toko buku menjadi tidak mudah dipantau dan mengakibatkan tidak efektifitasnya waktu serta keakuratan dalam pengambilan keputusan untuk melakukan pemantauan seluruh transaksi penjualan yang terjadi serta menentukan barang, kategori yang harus dipesan ke supplier dan penerbit.
dan diintegrasikan dalam bentuk multidimensi salah satunya menggunakan online analytical processing (OLAP). OLAP adalah teknologi untuk menjawab kebutuhan analitik, dimana OLAP mengandung dua tipe dasar yaitu measure dan dimensi.
Berdasarkan uraian di atas penulis melihat kesempatan untuk membangun gudang data yang akan digunakan untuk keperluan database Online Analytical Processing (OLAP) yang mencakup dimensi waktu (tahun, bulan, dan kuartal), supplier, penerbit, barang, kategori, topik dan measure berupa total penjualan.
1.2. Rumusan Masalah
1. Bagaimana membangun gudang data untuk keperluan database Online Analytical Processing (OLAP) yang dapat digunakan untuk memperoleh informasi transaksi penjualan di toko buku AB?
2. Apakah hasil OLAP tersebut dapat membantu pihak toko buku AB dalam memantau data jumlah penjualan berdasar dimensi waktu (tahun, bulan, dan kuartal), supplier, penerbit, barang, kategori, dan topik?
1.3. Tujuan Penelitian
Tujuan penelitian pada tugas akhir ini adalah :
1. Membangun gudang data untuk keperluan OLAP yang dapat digunakan untuk proses analisis pada transaksi penjualan, menyediakan penyimpanan data yang baik, tidak mudah hilang, serta memberikan informasi untuk membantu kepala toko dalam pembuatan laporan setiap bulannya.
1.4. Batasan Masalah
Batasan masalah dari pembangunan gudang data transaksi penjualan toko buku adalah sebagai berikut:
1. Data yang dipakai dalam pembuatan pembangunan gudang data hanya memakai data dari transaksi penjualan saja dan tidak memasukkan data bagian pembelian.
2. Data transaksi penjualan adalah semua rekapitulasi transaksi penjualan buku yang ada di toko buku untuk tahun 2013 dan 2014. 3. Dimensi yang dipakai adalah barang, waktu, supplier, penerbit, topik
dan kategori.
4. Pembangunan gudang data yang dibuat hanya dapat menampilkan measure jumlah_penjualan saja.
5. Implementasi dengan menggunakan Kettle (Pentaho Data Integration), Schema-workbench, dan Mondrian.
1.5. Metodologi Penelitian
Metodologi yang digunakan dalam pembuatan gudang data adalah : 1. Studi Pustaka
Mempelajari bahan-bahan terkait yang digunakan untuk mengerjakan skripsi.
2. Identifikasi Masalah
Melakukan wawancara kepada pihak yang terkait, untuk mendapatkan informasi kebutuhan yang diperlukan.
3. Mengumpulkan dan menganalisis sumber data
Mengumpulkan dan menganalisis data yang digunakan. 4. Melakukan Restrukturisasi Tabel
5. Pembersihan (Cleaning Data)
Data yang diperoleh kemudian dipersiapkan untuk proses pembuatan gudang data, yang dilakukan pertama adalah pembersihan. Informasi yang tidak dibutuhkan akan dihapus untuk mempercepat pemrosesan. 6. Transformasi Data
Pada tahap ini dilakukan ekstraksi data dan menyesuaikan data ke dalam gudang data.
7. Pembuatan Gudang Data
Setelah data ditransformasikan, data dari sumber dipindahkan ke gudang data. Pembuatan sistem Online Analytical Pprocessing (OLAP) dilakukan dengan cara:
a. Memecah gudang data dalam tabel dimensi dan tabel fakta. b. Pembuatan cube menggunakan skema multidimensi yaitu skema
bintang.
8. Uji Coba Pengguna dan Evaluasi
1.6. Sistematika Penulisan
Sistematika penulisan dibagi menjadi beberapa bab, diantaranya: a. Bab I : PENDAHULUAN
Pada bab ini membahas tentang latar belakang masalah, rumusan masalah, tujuan penelitian, batasan masalah, metodologi penelitian, sistematika penulisan.
b. Bab II : LANDASAN TEORI
Bab ini membahas sekilas tentang gudang data dan juga teori-teori lain yang mendukung dalam pembangunan gudang data.
c. Bab III : ANALISIS DAN PERANCANGAN Bab ini berisi analisis dan perancangan gudang data. d. Bab IV : IMPLEMENTASI
e. Bab V : ANALISIS HASIL
Bab ini berisi tentang pembahasan gudang data yang telah dibangun.
f. Bab VI : PENUTUP
BAB II
LANDASAN TEORI
2.1. Konsep Dasar Data Warehouse 2.1.1. Pengertian Data
Menurut Inmon (2002),
“Data adalah kumpulan fakta, konsep, atau instruksi dalam sebuah media penyimpanan untuk komunikasi, pengambilan, dan pengolahan yang bertujuan untuk penyediaan informasi yang dapat dipahami oleh manusia”.
2.1.2. Pengertian Gudang Data
Gudang data memiliki banyak pengertian, berikut ini merupakan pengertian dari beberapa ahli, diantaranya:
Menurut Inmon (2005),
“Gudang data adalah koleksi data yang mempunyai sifat berorientasi subyek, terintegrasi, time-variant, tidak mengalami perubahan dan memiliki rentang waktu tertentu yang mendukung pengambilan keputusan dari pihak manajemen”.
Menurut Kimball dan Caserta (2004),
“Gudang data adalah suatu sistem yang dapat mengekstrak, membersihkan, menyesuaikan, dan memberikan sumber data ke dalam data dimensi serta mendukung dan mengimplementasikan kueri dan analisis yang bertujuan untuk pengambilan keputusan”.
Berdasarkan tiga pengertian diatas maka dapat ditarik kesimpulan bahwa gudang data adalah sekumpulan data yang dapat mendukung proses pengambilan keputusan dalam suatu organisasi.
2.1.3. Karakteristik Gudang Data
Menurut Jiawei Han dan Micheline Kamber (2006) terdapat empat karakteristik data warehouse, diantaranya :
1. Subject-oriented
Sebuah gudang data dibangun berdasarkan kebutuhan subject utama seperti customer, supplier, produk dan penjualan. Sebuah gudang data fokus pada pemodelan dan analisis data untuk pengambilan keputusan.
2. Integrated
Sebuah gudang data dibangun dengan mengintegrasikan bermacam sumber heterogen seperti relational databases, flat files, dan catatan transaksi online. Pembersihan data dan teknik integrasi digunakan untuk memastikan konsistensi penamaan, struktur, atribut measure dan sebagainya.
3. Time-variant
Data disimpan untuk menyediakan informasi dari tahun sebelumnya (seperti 5-10 tahun yang lalu). Batasan waktu untuk gudang data akan lebih lama pada database operasional. 4. Nonvolatile
Gudang data secara fisik terpisah dari penyimpanan data. Proses update tidak terjadi pada lingkungan gudang data. Sebuah gudang data tidak memerlukan proses transaksi, recovery, dan mekanisme control concurrency. Hanya dua operasi saat pengaksesan data yaitu initial loading of data dan access of data.
2.1.4. Arsitektur Gudang Data
Gudang data sering mengadopsi beberapa arsitektur, diantaranya yaitu three-tier seperti gambar 2.1 menurut Jiawei Han dan Micheline Kamber (2006):
Gambar 2.1 Arsitektur Data Warehouse (Sumber : Jiawei Han dan Micheline Kamber. 2006)
a. Data warehouse server
profil yang disediakan oleh konsultan eksternal). Tools dan utilities menghasilkan data extraction, cleaning, dan transformation (misalnya, untuk menggabungkan data yang sama dari sumber yang berbeda ke dalam format yang terpadu), seperti fungsi load dan refresh untuk update ke dalam gudang data. Data yang diambil menggunakan antar-muka program aplikasi yang dikenal sebagai gateway. Sebuah gateway di dukung oleh DBMS yang mendasari dan memungkinkan program klien untuk menghasilkan kode sql yang akan dieksekusi di server.
b. OLAP Server
Merupakan tingkatan menengah dalam arsitektural gudang data. Biasanya diimplementasikan baik menggunakan model relasional OLAP (ROLAP) yaitu perpanjangan dari relasional DBMS yang memetakan operasi pada data multidimensi pada operasi relasional standar, atau model multidimensional OLAP (MOLAP) yaitu server yang mempunyai tugas yang khusus untuk mengarahkan implementasi multidimensi data dan operasi.
c. F ront End Client Layer
Merupakan tingkatan atas pada arsitektural gudang data. Berisikan tool kueri, alat analisis, dan tool data mining (contoh, trend analysis, prediksi dan sebagainya).
Berdasarkan sudut pandang arsitektur gudang data diatas, terdapat tiga model gudang data, diantaranya:
1. The Enterprise Warehouse
menyediakan integrasi data yang luas. Mengandung data yang detail, seperti ringkasan data dan ukurannya besar. Enterprise warehouse biasanya di implementasikan di traditional mainframes, computer superservers atau platform arsitektur pararel.
2. The Data Mart
Data mart mengandung bagian dari data perusahaan yang besar yang bernilai bagi grup tertentu. Data mart biasanya di implementasikan pada low-cost departmental server. Untuk implementasi putaran dari data mart lebih ke minggu. Dimana untuk sumber data, data mart dapat dikategorikan independent atau dependent.
3. The Virtual Warehouse
Virtual warehouse adalah kumpulan view dari seluruh operasional database. Untuk efisiensi proses kueri, hanya beberapa view yang ditampilkan. Virtual database warehouse dibangun tetapi membutuhkan kapasitas yang besar.
Menurut Poe (1996), arsitektur adalah kumpulan aturan atau struktur yang memberikan kerangka untuk keseluruhan rancangan pada suatu sistem atau produk. Arsitektur data menyediakan kerangka dengan mengidentifikasi dan memahami bagaiman data akan dipindahkan melalui sistem dan digunakan di dalam perusahaan. Arsitektur data dalam gudang data memiliki komponen utama yaitu basis data yang hanya dapat dibaca ( read-only database). Karakteristik arsitektur menurut Poe (1956) adalah:
1. Data diambil dari sistem asal seperti sistem informasi yang ada, database, dan file.
System) seperti oracle, Ms SQL Server, IBM DB2, Sybase dan masih banyak yang lain.
3. Gudang data adalah jenis basis data reaad-only atau hanya dapat dibaca yang diperuntukkan dalam pengambilan keputusan.
4. User mengakses gudang data melalui front-end tool atau aplikasi.
Gambar 2.2 Arsitektur Gudang Data (Sumber : Vidette Poe. 1956) 2.1.5. Metadata
Metadata adalah data mengenai data. Metadata memberikan peranan yang penting untuk keefektifan penggunaan gudang data karena akan mempermudah end user dalam melakukan analisis dan menghemat waktu. Metadata bertindak seperti indek mengenai isi dari gudang data.
2.1.6. Denormalisasi
Keuntungan melakukan proses denormalisasi yaitu :
1. Mengurangi jumlah relasi yang terjadi antar tabel-tabel yang harus mengalami proses pada waktu pencarian sehingga akan meningkatkan kecepatan proses kueri data. 2. Membuat struktur fisik database agar mudah dipahami
menurut model dimensi dari pengguna. Struktur tabel yang dibuat sesuai dengan kebutuhan pengguna memungkinkan terjadinya akses langsung yang sekali lagi akan meningkatkan performance.
Kelemahan dalam melakukan denormalisasi adalah :
1. Proses denormalisasi secara tidak langsung akan membuat redudansi data.
2. Pada proses denormalisasi memerlukan alokasi penyimpanan yang besar.
2.1.7. Manfaat Gudang Data
Ada empat manfaat yang bisa dilakukan dengan adanya gudang data, yaitu:
1. Pembuatan Laporan
Pembuatan laporan merupakan salah satu kegunaan gudang data yang paling umum dilakukan. Dengan menggunakan kueri sederhana didapatkan laporan perbulan, pertahun atau jangka waktu kapanpun yang diinginkan.
2. On-Line Analytical Processing (OLAP)
menggunakan fungsi yang berbeda. Fasilitas lain yang ada pada software OLAP adalah fasilitas rool-up dan drill-down. Drill-down adalah kemampuan untuk melihat detail dari suatu informasi dan rool-up adalah kebalikannya.
3. Data Mining
Data mining merupakan proses untuk menggali (mining) pengetahuan dan informasi baru dari data yang berjumlah banyak pada gudang data, dengan menggunakan kecerdasan buatan (Artificial Intelegence), statistik dan matematika. Data mining merupakan teknologi yang diharapkan menjembatani komunikasi antara data dan pemakainya.
4. Proses Informasi Executive
Gudang data dapat membuat ringkasan informasi yang penting dengan tujuan membuat keputusan bisnis, tanpa harus menjelajahi keseluruhan data. Dengan menggunakan gudang data segala laporan telah diringkas dan dapat pula mengetahui segala rinciannya secara lengkap, sehingga mempermudah proses pengambilan keputusan. Informasi dan data pada laporan gudang data menjadi target informative bagi user.
2.1.8. Langkah Pembuatan Gudang Data
Langkah-langkah yang digunakan saat melakukan pembuatan gudang data sebagai berikut:
1. Membaca data legacy
Memperhatikan bagian-bagian data yang perlu untuk dibersihkan
2. Memindahkan data dari sumber ke server gudang data
3. Memecah gudang data dalam tabel fakta dan tabel dimensi Tabel fakta dan tabel dimensi disusun menurut kebutuhan subyek.
2.2. Extract, Transform, dan Load 2.2.1. Pengertian ETL
Menurut Songini (2004) Extract, transform, load adalah salah satu proses dalam data warehouse yang melibatkan pembacaan data dari sumbernya, pembersihan dan penyesuaian format tersebut, dan penulisan data tersebut ke dalam ruang penyimpanan untuk digunakan lebih lanjut.
2.2.2. Proses dalam Extract, Transform, Load
Menurut Pusadan (2013) Proses ETL berfungsi untuk mengekstrak dan mengintegrasikan data dari berbagai sumber ke dalam data warehouse dalam selang waktu tertentu. Berikut mekanisme ETL:
a. Extraction adalah suatu proses yang mengidentifikasikan seluruh sumber data yang relevan dan kemudian mengambil data dari sumber-sumber data tersebut.
b. Transform adalah suatu proses yang memiliki peran dalam melakukan perubahan dan integrasi skema serta struktur yang berbeda ke dalam skema dan struktur yang telah didefinisikan sebelumnya oleh data warehouse.
c. Loading adalah suatu proses pemindahan data secara fisik dari sistem operasional ke dalam data warehouse.
Membaca dari dan mengirim data ke berbagai sumber (file teks, excel, database relational, dan sebagainya)
Mampu menyesuaikan atau transformasi data
Memiliki informasi metadata pada setiap perjalanan transformasi
Memiliki audit log yang baik
Dapat ditingkatkan performanya dengan scale up dan scale out
Mudah diimplementasikan.
Secara singkat dari proses ETL dapat dilihat pada gambar 2.3:
Gambar 2.3 Sistem Kerja Data Warehouse (Sumber : Han dan Kamber. 2001)
2.3. Model Data Multidimensi 2.3.1. Model Dimensional
tabel dimensi. Berikut ini penjelasan dari beberapa ahli mengenai tabel fakta dan tabel dimensi.
Menurut Connolly dan Begg, tabel fakta merupakan sebuah tabel yang memiliki sebuah composite primary key dimana tabel tersebut akan membentuk sebuah model dimensional.
Menurut Poe, Klaver, dan Brobst, tabel fakta disebut juga dengan tabel major, yang terdiri dari data sebenarnya dari suatu bisnis dan biasanya menggunakan pengukuran angka dan bisa terdiri dari banyak baris dan kolom.
Tabel dimensi disebut juga dengan tabel minor, lebih kecil dari tabel fakta dan menyimpan penjelasan data yang mencerminkan dimensi-dimensi dari suatu bisnis.
Tabel dimensi merupakan sekumpulan dari tabel-tabel yang lebih kecil yang memiliki sebuah primary key sederhana yang merespon secara benar terhadap salah satu dari composite key yang ada dari tabel fakta.
Susunan tabel fakta dan tabel dimensi memiliki standar perancangan atau skema karena terbukti meningkatkan peforma dan kemudahan dalam penerjemahan ke sistem OLAP. Model dimensional yang sering digunakan adalah skema bintang (star schema) dan skema butiran salju (snowflake).
2.3.2. Skema Bintang
Pengertian skema bintang menurut Connolly (2010), adalah model data dimensional yang mempunyai sebuah tabel fakta yang berisi data fakta ditengah dan dikelilingi oleh tabel-tabel dimensi yang terdiri dari data referensi (yang biasanya dapat di denormalisasi). Skema bintang mengambil karakteristik dari data fakta yang di-generate oleh event yang terjadi dimasa lampau.
menggunakan beberapa tabel dan hubungan antar tabel yang jelas. Skema bintang akan menghasilkan waktu respon yang cepat dalam kueri data dibandingkan dengan proses transaksional yang menggunakan struktur normalisasi dan memudahkan end user untuk memahami struktur basisdata pada gudang data yang dirancang.
Gambar 2.4 Contoh Star Schema (Sumber: Connolly dan Begg. 2010)
2.3.3. Kelebihan Menggunakan Skema Bintang
Skema bintang memiliki beberapa kelebihan, diantaranya yaitu :
1. Efisiensi (Efficiency)
Struktur basis data yang konsisten sehingga lebih efisiensi dalam akses data dengan menggunakan alat untuk menampilkan data seperti laporan tertulis dan kueri.
karena semua tabel dimensi memiliki kesamaan hal memberikan akses ke tabel fakta.
3. Extensibility
Model dimensional dapat dikembangkan, misalnya menambahkan tabel fakta selama data masih konsisten, kemudian menambahkan dimensi baru selama ada nilai tunggal dari dimensi tersebut yang mendefinisikan untuk setiap record tabel fakta yang ada, menambahkan atribut pada dimensi baru dan memecah record tabel dimensi yang ada menjadi level atau tingkat yang lebih rendah dari level sebelumnya.
4. Kemampuan untuk menggambarkan situasi bisnis (Ability to model common business situations), pendekatan standar untuk menangani situasi pemodelan dalam dunia bisnis, dimana dalam situasi ini memiliki perangkat program yang dapat secara khusus menspesifikasikan ke dalam penulisan laporan kueri dan antar pengguna yang lainnya.
5. Proses kueri yang dapat diprediksi (Predictable query processing), aplikasi gudang data yang mencari data dari level dibawahnya akan dengan mudah menambah jumlah atribut pada tabel dimensi dari skema bintang. Aplikasi yang mencari data dari level yang setara akan menghubungkan tabel fakta yang terpisah melalui tabel dimensi yang dapat diakses bersama.
6. End-user dapat menyesuaikan cara berfikir dan menggunakan data.
7. Lebih mudah dipahami
2.3.4. Kekurangan Menggunakan Skema Bintang
1. Pada penyimpanan atau memory, skema bintang membutuhkan ukuran penyimpanan yang relatif besar. 2. Dalam melakukan perawatan (maintenance) dan update
lebih sulit, karena tabel yang tidak normal.
3. Long time loading dimension table, dalam loading pada tabel dimensi dibutuhkan waktu yang cukup lama, ketika data yang dimiliki rendah dalam integritas dan nilai dalam replika tinggi maka waktu untuk melakukan loading menjadi meningkat.
4. Skema bintang tidak fleksibel dalam hal kebutuhan analisis, seperti model data yang dinormalisasi (jika data yang dibutuhkan melakukan normalisasi). Skema bintang dibangun hanya untuk kebutuhan data tertentu, sehingga tidak benar-benar memungkinkan analisis yang lebih kompleks.
5. Skema bintang tidak memiliki relasi many-to-many.
2.3.5. Skema Butiran Salju (Snowflake)
Menurut Connoly (2002), skema butiran salju (Snowflake Schema) merupakan bentuk lain dari skema bintang dimana data dalam tabel dimensi belum dinormalisasi.
Ciri-ciri dari skema butiran salju adalah :
1. Tabel dimensi dinormalisasi dengan dekomposisi pada level atribut.
2. Setiap dimensi mempunyai satu kunci (key) untuk setiap level pada hirarki dimensi.
Gambar 2.5 Contoh Snowflake Schema (Sumber: Connolly dan Begg. 2010)
2.3.6. Kelebihan Menggunakan Skema Snowflake
Kelebihan menggunakan skema butiran salju (snowflake) adalah :
1. Kecepatan memindahkan data dari data OLTP ke dalam metadata.
2. Sebagai kebutuhan dari alat pengambil keputusan tingkat tinggi dimana dengan tipe yang seperti ini seluruh struktur dapat digunakan sepenuhnya.
2.3.7. Kekurangan Menggunakan Skema Snowflake
1. Cenderung lebih sulit dipahami karena kompleksitasnya dimana tabel-tabel dimensi skema snowflake merupakan normalisasi dari beberapa tabel yang berhubungan.
2. Memiliki masalah besar dalam hal (performance) atau kinerja untuk melakukan kueri, hal ini disebabkan karena semakin banyaknya join antar tabel-tabel yang dilakukan dalam skema snowflake maka semakin lambat kinerja yang dilakukan.
2.3.8. Cube, Dimension, Measure, dan Member
Pengertian dari dimension, measure dan member menurut phi integration yaitu:
Cube adalah struktur multi dimensi konseptual, terdiri dari dimension dan measure dan biasanya mencakup pandangan bisnis tertentu seperti penjualan.
Dimension atau dimensi adalah struktur view atau sudut pandang yang menyusun cube. Dimensi dapat terdiri dari berbagai level.
Measure adalah nilai pengukuran.
Member adalah isi atau anggota dari suatu dimensional / measure tertentu.
2.3.9. Surrogate Key
2.4. Online Analytical Processing
2.4.1. Pengertian Online Analytical Processing (OLAP)
Pengertian OLAP menurut Connoly dan Begg (2005) Online Analytical Processing (OLAP) “ is the dynamic synthesis, analysis, and consolidation of large volumes”. Dimana OLAP merupakan gabungan yang dinamis, analisis dan konsolidasi dari data yang berukuran besar.
Selain Connolly dan Begg, OLAP menurut Codd et al (1995)OLAP adalah istilah untuk menggambarkan teknologi yang menggunakan tampilan data multidimensi yang memberikan akses yang cepat untuk informasi strategis dalam melakukan analisis.
Berdasarkan pengertian OLAP menurut ahli-ahli diatas dapat disimpulkan bahwa OLAP adalah perpaduan dinamis analisis dan gabungan dari data multidimensi yang mempunyai jumlah data yang besar yang memungkinkan teknologi dapat memberikan informasi yang cepat guna dalam melakukan analisis.
2.4.2. Online Transaction Processing (OLTP)
Online Transaction Processing (OLTP) adalah jenis sistem informasi yang mengutamakan proses transaksi, berurusan dengan data operasional, diidentifikasikan dengan jumlah transaksi yang besar. Pada database OLTP berisikan informasi sehari-hari yang dibutuhkan oleh sebuah organisasi untuk menjalankan sebuah bisnis. OLTP difokuskan pada insert, update, delete data secara real time dimana pada database OLTP tidak boleh ada gangguan dalam sistem atau operasional tidak bisa berjalan dengan baik. Sistem informasi yang dapat dikategorikan pada OLTP diantaranya adalah :
Enterprise Resource Planning (ERP) seperti SAP, Microsoft Dynamics.
2.4.3. Perbedaan OLTP dan OLAP
Beberapa perbedaan antara sistem OLTP atau On-line Transaction Processing System dengan OLAP yaitu, OLTP merupakan sistem database online operasional yang digunakan untuk melakukan sebuah transaksi online yang dilakukan dalam hari ke hari dimana di dalam OLTP terjadi proses kueri. Sedangkan gudang data menyediakan kepada user atau ahli sebuah aturan dari analisis data dan pembuatan keputusan. Sistem ini dikenal dengan Online Analytical Processing atau OLAP. Berikut ini perbedaan sistem OLTP dan OLAP menurut Jiawei Han dan Kamber.
Tabel 2.1 Perbedaan OLTP dengan OLAP
OLTP OLAP
Karakterikstik Proses operasional Pemrosesan informasi
Orientasi Transaksi Analisis
Pengguna DBA, database
profesional
Para ahli (manager,analis)
Fungsi Operasi sehari-hari Informasi yang lama yang
dibutuhkan untuk
mendukung pengambilan keputusan.
Desain Database Berdasar ER relasi entitas, berorientasi pada aplikasi
Berdasarkan star/snowflake, berorientasi subjek
Data Data yang digunakan
data sekarang, data terjamin pada masalah up-to-date
Summarization Data primitif, sangat detail
Penggabungan, peringkasan
View (Gambaran) Detail, relasi datar Summarized (peringkasan), multidimensional
Unit Kerja Pendek, simple
transaksi
Komplek kueri
Akses Read/write Hanya dapat read
Fokus Data masuk Infromasi keluar
Operasi Index/hash pada
primary key
Kebanyakan scan
Jumlah data yang diakses Puluhan Jutaan
Jumlah pengguna Ribuan Ratusan
Ukuran database 100 MB hingga GB 100 GB hingga mencapai TB
Prioritas Performa tinggi,
ketersediaan tinggi
Fleksibilitas tinggi, otonomi pengguna akhir
Metrik Melalui Transaksi Melalui kueri, waktu respon
2.5. Pentaho Data Integration (Kettle) 2.5.1. Pengertian Pentaho
Menurut Phi-Integration.com, Pentaho merupakan sebuah perusahaan yang menawarkan produk business intelligence (BI) yang menyediakan data integrasi, pelayanan OLAP, pelaporan atau reporting, dashboarding, data mining dan kemampuan ETL atau extract transfrom load pada Kettle.
2.5.2. Kettle
salah satu bagian dari aplikasi BI Pentaho, yang dikenal dengan Pentaho Data Integration (PDI). Kettle memiliki banyak komponen-komponen penting dalam membangun sebuah gudang data, diantaranya yaitu :
1. Step adalah blok bangunan inti dari transformation. Masing-masing step memiliki fungsi dan tugas tertentu, diantaranya : - JobSteps : step yang berjalan secara sekuensial dan lebih
berpusat pada control flow secara keseluruhan dari tugas ETL.
- Transformation steps : step yang berjalan secara paralel dan lebih menitik beratkan pada input/output data.
2. Transformation adalah komponen kettle yang menangani proses manipulasi aliran data. Semua proses ETL dilakukan dalam transformation. Dalam sebuah transformation terdapat satu atau banyak step. Transformation menjalankan semua step secara pararel dan transformation selalu memiliki step awal dan step akhir dalam bentuk table output. Simbol transformation dalam Spoon adalah:
3. Job adalah komponen dari kettle yang menangani kontrol atas aliran tugas (flow controll). Job terdiri dari satu atau lebih job entry yang dijalankan dalam urutan tertentu.
Lingkungan kerja spoon terdiri dari beberapa bagian, diantaranya :
a) Pulldown Menu
Koleksi menu dari spoon yang terintegrasi dalam satu toolbar.
b) Welcome Screen
Adalah halaman pembuka kettle yang berisi informasi mengenai situs Pentaho.
c) Toolbar
Terdiri dari job, transformation toolbar. d) Panel Execution Result, terdiri dari :
☞ Execution History, data history eksekusi. ☞ Logging, berisi detail dari eksekusi job,
transformation.
☞ Job Metrics, berisi detail dari step-step yang telah dieksekusi.
☞ Step Metrics, berisi detail jumlah pembacaan data (write, update, delete, dll), per satuan waktu detik dari step-step yang telah dieksekusi.
☞ Performance Graphs, adalah tampilan grafis dari pembacaan data dari Step Metrics.
6. Kitchen, adalah command line tool yang khusus digunakan untuk menjalankan job. Umumnya dijalankan pada saat otomatisasi terjadwal (scheduled automation). Dipaketkan dengan nama file pan.bat batch script) dan pan.sh (BASH shell script).
7. Carte, merupakan cluster web server yang digunakan untuk mengeksekusi job / transformation terutama digunakan untuk meningkatkan pedorma ETL dengan pembagian load kerja pada beberapa node Carte (master dan slave) dalam lingkungan cluster kettle.
Semua aplikasi tersebut dijalankan melalui shell atau batch script yang saling berkaitan. Fitur-fitur di dalam kettle diantaranya: - Memiliki utilitas grafik yang dapat digunakan untuk merancang
control flow umum maupun data flow.
- Multi platform, karena dikembangkan di atas java yang dimana java berjalan di banyak platform sistem operasi.
- Bersifat concurrent yaitu pada setiap row-row data diambil oleh step yang akan diserahkan secara paralel.
- Scalable, dapat beradaptasi dengan penambahan kapasitas memori RAM maupun storage.
- Koleksi step transformasi dan job cukup banyak.
- Extensible, kita dapat membuat step transformasi dan job baru dengan sistem plugin.
2.6. Mondrian
BAB III
ANALISIS DAN PERANCANGAN
3.1. Identifikasi Masalah dan Analisis Kebutuhan
Tabel 3.1 Contoh Transaksi Penjualan
Supplier No.Nota Kd.Brg Judul Pengarang Qty Jual
ANDI - PBR 12304 10136 BAHANA MEI 2014
ANDI
OFFSET 1
ANDI STAR CONCAT 12313 10178 BUKU 40 PL @10 FLOWERY ECER 3
ANDISTAR JOGJA 12291 10232 BUKU TULIS SIDU 38 2
ANDISTAR JOGJA 12289 10232 BUKU TULIS SIDU 38 2
CV.TIRO
INTERNATIONAL 12301 8460 RAUTAN R 620-2 2
DIVA PRESS 12301 8593 PERCOBAAN SAINS SEDERHANA UNTUK ANAK 1
MITRA NUGRAHA 12292 9734 DIARY DUS MKY TG YH64K-YS0567/990/B002 3
MITRA NUGRAHA 12295 9639 BPN DISNEY ISI 48 T48D/M/KT 3
3.2. Pemrosesan Awal
Setelah melakukan identifikasi masalah dan analisis kebutuhan, ditemukan bahwa struktur data yang ada dalam sistem belum memenuhi kaidah basis data relasional yang baik dan benar, dimana basis data relasional berisi data dalam bentuk tabel-tabel yang saling berhubungan, maka dari itu dilakukan pemrosesan awal terlebih dahulu berupa:
1) Struktur tabel basis data dari toko buku AB 2) Perancangan basis data
3) Restrukturisasi tabel 4) Pembersihan data 5) Transformasi data
6) Analisis kebutuhan gudang data
Dalam melakukan restrukturisasi tabel, dilakukan pengambilan data terlebih dahulu dengan menggunakan kettle pentaho, data yang digunakan berbentuk .sql, penggunaan kettle digunakan hanya untuk memudahkan dalam pemindahan data saja. Berikut ini merupakan bagian yang akan menguraikan lebih rinci proses dari tahap-tahap yang telah dijelaskan diatas.
3.2.1 Struktur Tabel Basis Data Toko Buku AB
Gambar 3.1 Struktur Tabel Basis Data Toko Buku AB
Gambar 3.1 merupakan struktur tabel basis data dari toko buku AB. Tabel yang berada pada toko buku AB terdiri dari 39 tabel dan dari semua tabel tersebut hanya digunakan 9 tabel, yaitu :
1) Tabel data_barang
Gambar 3.2 Tabel data_barang
2) Tabel data_beli
Gambar 3.3 Tabel data_beli
Pada gambar 3.3 merupakan data dari tabel yang bernama data_beli. Pada tabel ini terdiri dari kolom Nomor_Beli, Nomor_Nota, Tanggal_Beli, ID_Supplier, Tipe_Beli, Tempo, dan Tgl_Jatuh_Tempo.
3) Tabel data_jual
Gambar 3.4 Tabel data_jual
4) Tabel detail_jual
Gambar 3.5 Tabel detail_jual
Pada gambar 3.5 merupakan data dari tabel yang bernama detail_jual. Pada tabel ini terdiri dari kolom Nomor_Jual, Kode_Barang, N_User, Qty_Barang, H_Jual, dan Disc_Jual.
5) Tabel detail_beli
Gambar 3.6 Tabel detail_beli
6) Tabel supplier
Gambar 3.7 Tabel supplier
Pada gambar 3.7 merupakan data dari tabel yang bernama supplier. Pada tabel ini terdiri dari kolom ID_Supplier, Nama, Alamat, dan Kota.
7) Tabel penerbit
Gambar 3.8 Tabel penerbit
8) Tabel produk
Gambar 3.9 Tabel produk
Pada gambar 3.9 merupakan data dari tabel yang bernama produk. Pada tabel ini terdiri dari kolom Produk_ID, Keterangan, Tgl_Input, dan Tgl_Edit.
9) Tabel topik
Gambar 3.10 Tabel topik
Pada gambar 3.10 merupakan data dari tabel yang bernama topik. Pada tabel ini terdiri dari kolom Topik_ID, Keterangan, Tgl_Input, dan Tgl_Edit.
3.2.1 Perancangan Basis Data
sesuai dengan kaidah basis data relasional. Berikut ini merupakan tahapan dalam perancangan basis data.
1. Perancangan Basis Data Konseptual
TOPIK_KOMPLIT ID_TOPIK {PK} NAMA_TOPIK SUPPLIER_KOMPLIT ID_SUPPLIER {PK} NAMA_SUPPLIER PENERBIT_KOMPLIT ID_PENERBIT {PK} NAMA_PENERBIT KATEGORI_KOMPLIT ID_KATEGORI {PK} NAMA_KATEGORI TRANSAKSI_KOMPLIT ID_TRANSAKSI {PK} NOMOR_NOTA TGL_JUAL JUMLAH_PENJUALAN DETAIL_PENJUALAN JUMLAH_PENJUALAN PUNYA PUNYA PU N YA PUNYA PU N YA 1..1 1..1 1..1 1 ..1 1..* 1..* 1..* 1. .* 1..* 1..* BARANG_KOMPLIT ID_BARANG {PK} NAMA_BARANG
Gambar 3.11 ER Diagram
2. Perancangan Data Logikal TOPIK_KOMPLIT ID_TOPIK {PK} NAMA_TOPIK SUPPLIER_KOMPLIT ID_SUPPLIER {PK} NAMA_SUPPLIER PENERBIT_KOMPLIT ID_PENERBIT {PK} NAMA_PENERBIT BARANG_KOMPLIT ID_BARANG {PK} NAMA_BARANG ID_PENERBIT {FK} ID_TOPIK {FK} ID_KATEGORI {FK} ID_SUPPLIER {FK} KATEGORI_KOMPLIT ID_KATEGORI {PK} NAMA_KATEGORI TRANSAKSI_KOMPLIT ID_TRANSAKSI {PK} NOMOR_NOTA TGL_JUAL JUMLAH_PENJUALAN DETAIL_PENJUALAN ID_BARANG {FK} JUMLAH_PENJUALAN ID_TRANSAKSI {FK} PUNYA PUNYA PU N YA PUNYA PU N YA 1..1 1..1 1..1 1 ..1 1..* 1..* 1..* 1 ..* 1..* 1..*
3. Perancangan Data Fisikal
a. Tabel Barang_Komplit
Tabel 3.2 Tabel Barang_Komplit
Nama Field Tipe Keterangan
ID_BARANG int (11) Primary Key untuk tabel Barang.
NAMA_BARANG varchar(80) Field untuk nama barang.
ID_PENERBIT int (11) Foreign key untuk menghubungkan ke tabel Penerbit.
ID_TOPIK int (11) Foreign key untuk menghubungkan ke tabel Topik.
ID_KATEGORI int (11) Foreign key untuk menghubungkan ke tabel Kategori.
ID_SUPPLIER int (11) Foreign key untuk menghubungkan ke tabel Supplier.
b. Tabel Kategori_Komplit
Tabel 3.3 Tabel Kategori_Komplit
Nama Field Tipe Keterangan
ID_KATEGORI int (11) Primary Key untuk tabel Kategori.
c. Tabel Topik_Komplit
Tabel 3.4 Tabel Topik_Komplit
Nama Field Tipe Keterangan
ID_TOPIK int (11) Primary Key untuk tabel Topik.
NAMA_TOPIK varchar(25) Field untuk nama Topik.
d. Tabel Penerbit_Komplit
Tabel 3.5 Tabel Penerbit_Komplit
Nama Field Tipe Keterangan
ID_PENERBIT int (11) Primary Key untuk tabel Penerbit.
NAMA_PENERBIT varchar(25) Field untuk nama Penerbit.
e. Tabel Supplier_Komplit
Tabel 3.6 Tabel Supplier_Komplit
Nama Field Tipe Keterangan
ID_SUPPLIER int (11) Primary Key untuk tabel Supplier.
f. Tabel Transaksi_Komplit
Tabel 3.7 Tabel Transaksi_Komplit
Nama Field Tipe Keterangan
ID_TRANSAKSI int (11) Primary Key untuk tabel Transaksi.
NOMOR_NOTA int (11) Field untuk nomor_nota.
TGL_JUAL int (11) Field untuk tgl_jual.
JUMLAH_PENJUALAN int (11) Field untuk Jumlah_Penjualan.
g. Tabel Detail_Penjualan
Tabel 3.8 Tabel Detail_penjualan Nama Field
Tipe Keterangan
ID_BARANG int (11) Foreign key untuk menghubungkan ke tabel Barang.
JUMLAH_PENJUALAN int (11) Field untuk Jumlah_Penjualan.
ID_TRANSAKSI int (11) Foreign key untuk menghubungkan ke tabel Id_Transaksi.
3.2.2 Restrukturisasi Tabel
Restrukturisasi tabel dibuat karena adanya beberapa kendala, diantaranya yaitu :
contohnya yaitu satu id_barang dimiliki oleh banyak id_supplier sehingga membuat administrator toko buku mengalami kendala.
2. Terjadinya duplikasi data pada semua tabel yang menghambat proses transaksi penjualan di toko buku AB. Dari alasan tersebut, maka dilakukan restrukturisasi tabel guna untuk memperbaiki relasi tabel-tabel di toko buku AB, dan untuk memudahkan didalam melakukan pembuatan gudang data. Bagian berikut ini akan menguraikan lebih rinci proses-proses restrukturisasi tabel :
1. Membaca relasi data dari transaksi penjualan.
2. Memperbaiki relasi database pada tabel-tabel yang belum benar dengan cara melakukan restrukturisasi.
3.2.1.1 Membaca relasi data dari transaksi penjualan
Pada bagian ini, membaca relasi data sangatlah penting. Relasi data dibutuhkan untuk mengetahui hubungan antar tabel dalam basis data. Tabel basis data dari toko buku tidaklah semua diambil, hanya tabel yang berkaitan dengan transaksi penjualan saja dan beberapa tabel yang dibuat guna untuk memperbaiki relasi antara tabel satu dengan tabel yang lain sehingga transaksi penjualan pada tabel 3.1 dapat sesuai dengan perancangan yang diharapkan dan mempermudah untuk proses pembuatan gudang data selanjutnya.
1) Tabel data_barang
Gambar 3.13 Tabel data_barang
Gambar 3.13 adalah tabel data_barang yang digunakan untuk membuat tabel barang. Pada tabel data_barang ini terdapat beberapa kolom data, tetapi hanya ada lima kolom data yang digunakan, yaitu: Kode_Barang, Produk_ID, Topik_ID, ID_Penerbit, dan Judul_Buku.
2) Tabel data_beli
Gambar 3.14 Tabel data_beli
3) Tabel data_jual
Gambar 3.15 Tabel data_jual
Gambar 3.15 adalah tabel data_jual. Pada tabel data_jual terdapat beberapa kolom data, tetapi hanya tiga kolom data yang digunakan, yaitu: Nomor_Jual, Tanggal_Jual dan Total_Qty_Brg. Nomor_Jual, Tanggal_Jual dan Total_Qty_Brg ini digunakan untuk mendapatkan kode barang yang sesuai dengan nomor jual. Untuk lebih rincinya, dapat dilihat pada bagian lampiran mengenai restrukturisasi tabel di pembentukan tabel Data Detail Jual.
4) Tabel detail_jual
Gambar 3.16 Tabel detail_jual
Qty_Barang berfungsi untuk menghubungkan nomor_jual yang ada pada data_jual. Untuk lebih rincinya, dapat dilihat pada bagian lampiran mengenai restrukturisasi tabel di pembentukan tabel Data Detail Jual.
5) Tabel detail_beli
Gambar 3.17 Tabel detail_beli
Gambar 3.17 adalah tabel detail_jual. Pada tabel detail_beli terdapat beberapa kolom data tetapi hanya tiga kolom data yang digunakan, yaitu: Nomor_Beli, Kode_Barang. Data Nomor_Beli, dan Kode_Barang berfungsi untuk menghubungkan Kode_Barang yang berada di tabel data_barang, dan Nomor_Beli di tabel data_beli. Untuk lebih rincinya, dapat dilihat pada bagian lampiran mengenai restrukturisasi tabel di pembentukan tabel Tampung Supplier Barang.
Gambar 3.18 Tabel supplier
Gambar 3.18 adalah tabel supplier. Pada tabel supplier, terdapat beberapa kolom data tetapi hanya dua kolom data yang digunakan, yaitu: ID_Supplier, dan Nama. ID_Supplier, dan Nama. ID_Supplier sendiri digunakan untuk banyak tabel, salah satu kegunaannya yaitu untuk mendapatkan data barang yang sesuai dengan data supplier. Tabel supplier ini akan digunakan di tabel: data_beli,
transaksi, tampung supplier barang,
tampung_barang_supplier, barang_jadi, sementara transaksi dan tabel woo. Untuk lebih rincinya, dapat dilihat pada bagian lampiran mengenai restrukturisasi tabel.
7) Tabel penerbit
Gambar 3.19 Tabel penerbit
Tabel penerbit digunakan dalam proses restrukturisasi tabel. Untuk lebih rincinya, dapat dilihat pada bagian lampiran mengenai restrukturisasi tabel di pembentukan tabel penerbit.
8) Tabel produk
Gambar 3.20 Tabel produk
Gambar 3.20 adalah tabel produk. Pada tabel produk, terdapat beberapa kolom data tetapi hanya dua kolom data yang digunakan, yaitu: Produk_ID, dan Keterangan. Tabel produk sendiri akan digunakan dalam proses restrukturisasi tabel di bagian pembentukan tabel produk.
9) Tabel topik
Gambar 3.21 Tabel topik
digunakan, yaitu: Topik_ID, dan Keterangan. Tabel topik sendiri akan digunakan dalam proses restrukturisasi tabel di bagian pembentukan tabel topik.
3.2.1.2 Memperbaiki relasi database pada tabel-tabel yang belum benar dengan cara melakukan restrukturisasi.
Dalam melakukan proses restrukturisasi tabel, dilakukan proses import dari database toko menuju ke database data_jadi_monsi dengan menggunakan kettle. Kettle disini hanya untuk memudahkan di dalam pengambilan data saja. Tabel yang digunakan yaitu :
1) barang 2) topik 3) produk 4) penerbit 5) supplier 6) data_beli 7) detail_beli 8) data_jual 9) data_detail_jual
10)tampung supplier barang 11)transaksi
12)tampung_barang_supplier_monsi 13)barang_jadi
14)sementara transaksi 15)woo
Setelah mengambil dan membuat tabel-tabel diatas, kemudian dilakukan penyederhanaan tabel, yaitu mengambil tabel-tabel dengan data yang akan diperlukan, kemudian dilakukan import data ke database yang bernama monica_skripsi dimana di dalam database tersebut sudah sesuai dengan basis data relasional seperti perancangan basis data yang dijelaskan sebelumnya. Hasil tabel di database monica_skripsi dapat dilihat pada gambar berikut :
Gambar 3.22 Hasil Restrukturisasi Basis Data monica_skripsi
3.2.3 Pembersihan Data
Setelah tahap restrukturisasi selasai, kemudian dilakukan proses pembersihan guna untuk mendapatkan data yang konsisten dan relevan. Tahap ini bertujuan agar di dalam pemrosesan data, dapat berlangsung dengan cepat, sebagai contoh ada data transaksi yang null atau tidak adanya data yang berkaitan dengan tabel yang lain maka dilakukan pembersihan data.
Transformasi dilakukan untuk mengubah format lama menjadi format baru yang digunakan untuk format gudang data. Sebagai contoh atribut pada barang terdapat ID BARANG, NAMA BARANG maka pada proses transformasi ini atribut akan diubah menjadi ID_BARANG, NAMA_BARANG. Proses ini bertujuan untuk memudahkan dalam pengimplementasian di gudang data.
3.3. Analisis Kebutuhan Gudang Data 3.3.1 Use Case
Diagram use case ini menggambarkan kebutuhan admin dari Kepala toko buku, dari gudang data yang akan dibangun. Pada gambar 3.23 menerangkan gambar use case untuk gudang data transaksi penjualan.
Gambar 3.23 Diagram Use Case
Dari diagram use case diatas, dapat di deskripsikan sebagai berikut :
Tabel 3.9 Deskripsi Diagram Use Case Admin Kepala
Toko
OLAP
Melihat Laporan
Kode Use Case
Nama Use Case Deskripsi Aktor
US001 Login
Use case ini mejelaskan proses dimana admin kepala toko melakukan login sebelum masuk ke sistem. Untuk dapat masuk ke sistem, kepala toko harus memasukkan username dan password terlebih dahulu.
Admin Kepala Toko US002 Melihat laporan transaksi penjualan
Use case ini berfungsi untuk melihat hasil pembangunan gudang data transaksi penjualan.
Admin Kepala Toko
3.3.2 Narasi Use Case
1) Narasi Use Case Login Kepala Admin Tabel 3.10 Narasi Use Case Login Kode Use case US001
Nama Use case Login
Aktor Admin Kepala Toko
Deskripsi Use Case Use case ini mejelaskan proses dimana admin kepala toko melakukan login sebelum masuk ke sistem. Untuk dapat masuk ke sistem, kepala toko harus memasukkan username dan password terlebih dahulu
Trigger -
Kegiatan Aktor Respon Sistem
1. Sistem menampilkan halaman utama
2. Kepala admin mengklik menu “LOGIN”
3. Sistem menampilkan halaman login
Langkah umum 4. Kepala admin memasukkan username dan password
5. Sistem mengecek username dan password sesuai dengan database 6. menampilkan halaman utama
admin kepala toko Langkah Alternati
