ABSTRAK
Sebagai salah satu upaya pengendalian susut non teknis di PT. PLN (Persero) Area Kuala Kapuas, bagian Transaksi Energi melakukan monitoring pelanggan Pascabayar dan Prabayar secara rutin. Monitoring yang dilakukan selama ini dilakukan secara manual dan tidak ada filterisasi untuk data yang sudah diperiksa sehingga pemeriksaan kadang dilakukan berulang kali. Pemakaian tenaga listrik yang tidak normal selama ini dipantau secara manual menggunakan perangkat pengolah kata seperti Microsoft Excel. Data yang harus diperiksa setiap bulan sangat banyak sehingga akan memerlukan waktu yang lama untuk memeriksa.
PT. PLN (Persero) Area Kuala Kapuas terdiri dari 6 rayon, dimana tiap rayon juga bertanggung jawab untuk melakukan monitoring pelanggan di wilayahnya. Mengingat bahwa petugas yang menggunakan sistem monitoring bukan hanya petugas lapangan melainkan juga petugas yang berada di kantor maka sistem ini menerapkan manajemen transaksi yang melayani multiuser.
Sistem yang multiuser ini mengharuskan adanya sebuah penanganan transaksi ketika satu atau beberapa user akan write dan atau read data secara bersamaan. Hal ini dilakukan untuk menghindari masalah proses konkuren seperti diantaranya The Lost Update Problem, The Uncommited Dependency (Dirty Read) Problemdan The Inconsistent Analysis Problem. Sehingga diperlukan manajemen transaksi untuk mengatur kelancaran dari tiap action yang dilakukan oleh user sistem terhadap data. Metode two phase locking yang digunakan akan memberikan lock bagi tiap transaksi yang akan mengakses data, baik read atau write data. Sehingga tiap transaksi akan dibuat menunggu sampe lock dilepaskan untuk dapat mengubah data.
ABSTRACT
As one of the efforts to control non-technical losses in PT. PLN (Persero) Area Kuala Kapuas, division of Energy Transactions do monitoring of postpaid and prepaid customers regularly. The monitoring that have been conducted so far done manually and there is no filter for data that have been checked so that the examination is sometimes performed repeatedly. The unnormal Electricity consumption so far being monitored manually using word processing tools such as Microsoft Excel. There is thousands ofrecords should be checked every month and took so long to be checked.
PT. PLN (Persero) Area Kuala Kapuas consists of 6 rayons (small area), each rayon is also being responsible for monitoring customers in their areas. Considering that personnel using this monitoring system is not only the field officers but also officers who were in office then it will implementing transaction management that serves multiuser.
This multiuser system requires a transaction handling when one or several users conduct write or read data simultaneously. This is done to avoid problems such as concurrent processes including The Lost Update Problem, The Uncommited Dependency (Dirty Read) Problem, and The Inconsistent Analysis Problem. So, this transaction management is needed to make sure transaction occurs in a good manner for every actions performed by the user towards data. Two phase locking method will provide a lock for each transaction that access the data, either read or write data. So that each transaction will be made to wait until the lock is released by the former transaction to be able to change the data.
SISTEM MONITORING PELANGGAN PASCABAYAR DAN PRABAYAR TIDAK BELI TOKEN MENERAPKAN MANAJEMEN TRANSAKSI
MENGGUNAKAN METODE TWO PHASE LOCKING (Studi Kasus : PT. PLN (Persero) Area Kuala Kapuas)
SKRIPSI
Diajukan Untuk Memenuhi Salah Satu Sayarat
Memperoleh Gelar Sarjana Komputer
Program Studi Teknik Informatika
Oleh:
Ni Putu Novita Puspa Dewi
125314140
PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS SANATA DHARMA YOGYAKARTA
MONITORING SYSTEM OF POSTPAID AND TBT PREPAID
CUSTOMERS IMPLEMENTS TRANSACTION MANAGEMENT USING METHOD TWO PHASE LOCKING
(Case Study : State Electricity Company District Kuala Kapuas) A Final Project
Presented as Partial Fulfillment of The Requirements
To Obtain Sarjana Komputer Degree
In Informatics Engineering Study Program
By :
Ni Putu Novita Puspa Dewi
125314140
INFORMATICS ENGINEERING STUDY PROGRAM FACULTY OF SCIENCE AND TECHNOLOGY
SANATA DHARMA UNIVERSITY YOGYAKARTA
HALAMAN PERSEMBAHAN
“Never regret for a thing that you never fight for it”
Tugas akhir ini Penulis persembahkan kepada:
Mama yang tiap kali nelpon selalu kirim gambar kebaya, nanya kapan lulus, kapan wisuda, skripsi sampe mana?
Papa yang tiap kali ditelpon bilang ga sabar pengen pake jas (ngefek buat wisuda) dan selalu kasih support untuk ga menunda tugas akhir.
Budhi dan Widya (partner hidup di jogja) yang selalu jadi bulan-bulanan dan ocehan , spesial buat Budhi yang udah bantu buat digram,edit tulisan,dsb.
PERNYATAAN KEASLIAN KARYA
Saya menyatakan dengan sesungguhnya bahwa skripsi yang saya tulis ini tidak memuat karya atau bagian karya orang lain, kecuali yang telah disebutkan dalam
LEMBAR PERNYATAAN PERSETUJUANPUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS
Yang bertanda tangan dibawah ini, saya mahasiswa Universitas Sanata Dharma :
Nama : Ni Putu Novita Puspa Dewi
NIM : 125314140
Demi pengembangan ilmu pengetahuan, Saya memberikan kepada Perpustakaan Universitas Sanata Dharma karya ilmiah Saya yang berjudul:
SISTEM MONITORING PELANGGAN PASACBAYAR DAN PRABAYAR TIDAK BELI TOKEN MENERAPKAN MANAJEMEN TRANSAKSI
MENGGUNAKAN METODE TWO PHASE LOCKING
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 mempublikasikan di Internet atau media lain untuk kepentingan akademis tanpa perlu meminta ijin dari saya maupun memberikan royalti kepada saya selama tetap mencantumkan nama saya sebagai penulis.
Demikian pernyataan ini saya buat dengan sebenarnya.
ABSTRAK
Sebagai salah satu upaya pengendalian susut non teknis di PT. PLN (Persero) Area Kuala Kapuas, bagian Transaksi Energi melakukan monitoring pelanggan Pascabayar dan Prabayar secara rutin. Monitoring yang dilakukan selama ini dilakukan secara manual dan tidak ada filterisasi untuk data yang sudah diperiksa sehingga pemeriksaan kadang dilakukan berulang kali. Pemakaian tenaga listrik yang tidak normal selama ini dipantau secara manual menggunakan perangkat pengolah kata seperti Microsoft Excel. Data yang harus diperiksa setiap bulan sangat banyak sehingga akan memerlukan waktu yang lama untuk memeriksa.
PT. PLN (Persero) Area Kuala Kapuas terdiri dari 6 rayon, dimana tiap rayon juga bertanggung jawab untuk melakukan monitoring pelanggan di wilayahnya. Mengingat bahwa petugas yang menggunakan sistem monitoring bukan hanya petugas lapangan melainkan juga petugas yang berada di kantor maka sistem ini menerapkan manajemen transaksi yang melayani multiuser.
ABSTRACT
As one of the efforts to control non-technical losses in PT. PLN (Persero) Area Kuala Kapuas, division of Energy Transactions do monitoring of postpaid and prepaid customers regularly. The monitoring that have been conducted so far done manually and there is no filter for data that have been checked so that the examination is sometimes performed repeatedly. The unnormal Electricity consumption so far being monitored manually using word processing tools such as Microsoft Excel. There is thousands ofrecords should be checked every month and took so long to be checked.
PT. PLN (Persero) Area Kuala Kapuas consists of 6 rayons (small area), each rayon is also being responsible for monitoring customers in their areas. Considering that personnel using this monitoring system is not only the field officers but also officers who were in office then it will implementing transaction management that serves multiuser.
KATA PENGANTAR
Puji dan syukur Penulis panjatkan kepada Tuhan Yang Maha Esa atas karunia yang diberikan-Nya. Sehingga Penulis dapat menyelesaikan skripsi dengan tepat waktu. Penulisan skripsi ini tidak lepas dari peran pentingnya berbagai pihak, sehingga dalam kesempatan ini penulis dengan kerendahan hati mengucapkan terimakasih kepada semua pihak yang teah memberikan dukungan baik secara langsung maupun tidak langsung kepada penulis dalam penyelesaian skripsi hingga selesai. Pada penulisan skripsi ini saya ucapkan terimakasih kepada:
1. Drs. Johanes Eka Priyatma, M.Sc., Ph.D. selaku Rektor dan dosen pembimbing akademik Penulis.
2. JB. Budi Darmawan, S.T., M.Sc selaku dosen pembimbing tugas akhir Penulis yang telah bersedia memberikan pengorbanan waktu dan tenaga dan pikiran untuk membimbing dengan sabar dalam penyusunan tugas akhir ini. Terima kasih atas petunjuk, arahan, dan saran yang telah diberikan kepada Penulis.
3. A.M Polina, S.Kom, M.Sc dan P.H Prima Rosa, M.Sc selaku dosen penguji yang telah memberikan saran dan masukan pada saat ujian untuk memperbaiki kesalahan dalam penulisan skripsi ini.
4. Dr. Anastasia Rita Widiarti, selaku Kaprodi Teknik Informatika yang selama pengambilan tugas akhir ini secara rutin melakukan pertemuan untuk memberikan support bagi mahasiswa yang sedang dalam tahap penyelesaian tugas akhir.
5. Dosen dan staff FST yang selama ini telah banyak memberikan bantuan dan bimbingan selama Penulis berkuliah di USD.
6. PT. PLN (Area) Kuala Kapuas yang telah membantu Penulis mulai dari proses pengambilan data hingga uji coba sistem.
8. Adik-adik Penulis, widya, wira, budhi yang selalu memberikan support yang menjadi motivasi bagi Penulis.
9. Teman-teman tercinta yang selalu memberikan dukungan dan motivasi dalam mengerjakan skripsi “Agustin, Monica, Riya, Eric, Bagus, Candra, Vitto, Bany, Lukas, Tegar, Andre” dan seluruh teman-temanTeknik Informatika angkatan 2012 yang selalu berjuang bersama dan saling menginspirasi.
10. Kepada Radha dan Stifanny terima kasih atas support dan bantuan yang telah diberikan.
11. Keluarga besar Narayana Smrti Ashram yang menjadi tempat suka dan duka Penulis selama tinggal di Jogja. Buat dana keli dasa, terima kasih support dan masukan yang telah diberikan kepada Penulis.
12. Semua pihak baik secara langsung maupun tidak langsung yang telah membantu dalam mengerjakan penyelesaian tugas akhir ini.
DAFTAR ISI
HALAMAN JUDUL ... i
HALAMAN PERSETUJUAN PEMBIMBING .... Error! Bookmark not defined. HALAMAN PENGESAHAN ... Error! Bookmark not defined. HALAMAN PERSEMBAHAN ... v
PERNYATAAN KEASLIAN KARYA ... vi
LEMBAR PERNYATAAN PERSETUJUANPUBLIKASI ... vii
ABSTRAK ... viii
ABSTRACT ... ix
KATA PENGANTAR ... x
DAFTAR ISI ... xii
DAFTAR GAMBAR ... xvii
DAFTAR TABEL ... xxv
BAB I PENDAHULUAN ... 1
1.1. Latar Belakang ... 1
1.2. Rumusan Masalah ... 4
1.3. Tujuan ... 4
1.4. Batasan Masalah ... 5
1.5. Metodologi Penelitian ... 5
1.6. Sistematika Penulisan ... 7
BAB II LANDASAN TEORI ... 9
2.1. Sistem Monitoring ... 9
2.2. Basis Data ... 9
2.2.1. Pengertian Basis Data ... 9
2.2.2. Sistem Basis Data ... 10
2.2.3. Batasan Aturan Basis Data ... 10
2.2.4. Entity-Relationship Modelling (E-R Modelling) ... 13
2.3. Use Case Diagram ... 22
2.4. Class Diagram ... 23
2.5. Activity Diagram ... 24
2.6. Oracle ... 25
2.6.1. Penjelasan Tentang SQL ... 25
2.6.2. Data Definition Language (DDL) ... 26
2.6.3. Data Manipulation Language (DML) ... 27
2.6.4. Stored Procedure ... 28
2.6.5. Stored Function ... 29
2.7. Java & JSP ... 30
2.8. Semantic-UI ... 33
BAB III ANALISI DAN PERANCANGAN ... 34
3.1. Analisis Sistem ... 34
3.1.1. Gambaran Umum Sistem Lama ... 34
3.1.2. Gambaran Umum Sistem Baru ... 34
3.1.3. Orang yang Terlibat Dalam Sistem ... 35
3.1.4. Batasan Sistem Monitoring Pelanggan Pasca Bayar dan Prabayar . 36 3.2. Perancangan Sistem ... 37
3.2.1. Deskripsi Rinci Kebutuhan Sistem ... 37
3.2.2. Use Case Diagram ... 41
3.2.3. Definisi aktor ... 55
3.2.4. Definisi Use Case ... 55
3.2.5. Skenario Use Case ... 65
3.2.6. Activity Diagram ... 115
3.2.7. Diagram Sekuensial ... 135
3.2.8. Diagram Kelas ... 154
3.3. Perancangan Basis Data ... 155
3.3.1 Desain Konseptual Basis Data ... 155
3.3.2. Desain Logikal Basis Data ... 156
BAB IV IMPLEMENTASI SISTEM ... 160
4.1. Sistem Monitoring Pelanggan Pascabayar dan Prabayar Tidak Beli Token ... ...160
4.2. Spesifikasi Software dan Hardware yang Digunakan ... 166
4.2.1. Spesifikasi Software ... 166
4.2.2. Spesifikasi Hardware ... 166
4.3. Implementasi Stored Procedure dan Function ... 167
4.3.1. Implementasi Stored Procedure untuk Proses Upload Data Monitor Pascabayar ... 167
4.3.2. Implementasi Stored Procedure untuk Proses Upload Data Monitor Prabayar ... 169
4.3.3. Implementasi Stored Procedure Untuk Proses Approve Data Hasil MonitorPascabayar ... 171
4.3.4. Implementasi Stored Procedure Untuk Proses Approve Data Hasil Monitoring Prabayar ... 174
4.3.5. Implementasi Stored Procedure Untuk Proses Pembatalan Status Monitor Pascabayar ... 176
4.3.6. Implementasi Stored Procedure Untuk Proses Pembatalan Status Monitor Prabayar ... 178
4.3.7. Implementasi Stored Procedure Untuk Proses Pembatalan Status Approve Pascabayar ... 180
4.3.8. Implementasi Stored Procedure Untuk Proses Pembatalan Status Approve Prabayar ... 182
4.3.9. Implementasi Function ... 184
4.4. Implementasi Program ... 189
4.4.1. Proses Login User ... 189
4.4.2. Proses Tambah User ... 189
4.4.3. Proses Edit Data User ... 190
4.4.4. Proses Monitoring Prabayar dan Pascabayar ... 190
4.4.5. Proses Menyimpan Gambar ... 190
4.4.6. Proses Approve Prabayar dan Pascabayar ... 191
4.4.8. Proses Pembatalan Status Approve Prabayar dan Pascabayar ... 192
4.4.9. Proses Copy Status Bulan Terakhir ... 192
4.4.10. Proses Cetak Report Monitoring Pelanggan Kwh0 ... 193
4.4.11. Proses Cetak Report Monitoring Pelanggan Kwh Maks ... 193
4.4.12. Proses Cetak Report Monitoring Pelanggan TBT ... 193
4.4.13. Proses Cetak Report Rekomendasi Monitoring Pelanggan Kwh Maks Naik Daya ... 193
4.4.14. Proses Lihat Versi Monitoring ... 194
4.5. Implementasi Kelas... 195
4.6. Implementasi Basis Data ... 195
4.7. Implementasi Antar Muka ... 196
4.8. Implementasi User Interface ... 208
4.8.1. Login Operator dan Administrator ... 208
4.8.2. Halaman Utama Administrator Tingkat Area ... 209
4.8.3. Halaman Utama Administrator Tingkat Rayon ... 212
4.8.4. Halaman Utama Operator Tingkat Area dan Rayon ... 212
4.8.5. Halaman Tambah User... 213
4.8.6. Lihat Data Monitoring ... 216
4.8.7. Upload data dan ubah data monitoring ... 221
4.8.8. Lihat Data Approve ... 225
4.8.9. Approve Dan Batalkan Status Monitoring ... 229
4.8.10. Lihat Detail Approve dan Pembatalan Status Approve ... 230
4.8.11. Lihat Detail Pelanggan ... 232
4.8.12. Dasboard ... 233
4.8.13. Cetak Laporan ... 234
BAB V ANALISA HASIL PENGUJIAN ... 240
5.1. Analisa Perangkat Lunak ... 240
5.2. Analisa Hasil Uji Coba Terhadap Program ... 241
5.2.1. Pengujian Kasus The Lost of Update Problem ... 241
5.2.3. Pengujian Kasus The Inconsistent Analysis Problem ... 277
5.3. Analisa Hasil Uji Coba Terhadap Pengguna ... 278
5.3.1. Form Kuesioner ... 278
5.3.2. Hasil dan Pembahasan ... 279
BAB VI KESIMPULAN DAN SARAN ... 288
6.1. Kesimpulan ... 288
6.2. Saran ... 289
DAFTAR PUSTAKA ... 290
Lampiran ... 292
A. Lampiran Program ... 293
B. Lampiran User Interface ... 336
C. Lampiran Diagram Kelas ... 341
DAFTAR GAMBAR
Gambar 1. 1 Grafik Pelanggan Monitoring Pascabayar Juni 2014 (sumber :
Data DPM PT.PLN (Persero) Area Kuala Kapuas Juni 2014). ... 2
Gambar 1. 2Grafik Pelanggan Monitoring Prabayar Juni 2015 (sumber : Data TBT PT.PLN (Persero) Area Kuala Kapuas Juni 2015). ... 3
Gambar 2. 1Representasi Diagram dari Entity Type Staff dan Branch(Connolly and Beg, 2002) ... 14
Gambar 2. 2Representasi Diagram dari Entity Branch Has Staff Relationship Type(Connolly and Beg, 2002) ... 14
Gambar 2. 3Representasi Diagram dari Entity Staff dan Branch ... 15
Gambar 2. 4Diagram Transisi Transaksi (Connolly and Beg, 2002) ... 17
Gambar 2. 5Mencegah Lost Update Problem menggunakan 2PL (Connolly and Beg, 2002) ... 19
Gambar 2. 6Mencegah Uncommited Dependency Problem using 2PL(Connolly and Beg,2002) ... 20
Gambar 2. 7Mencegah Inconsistent Analysis Problem using 2PL(Connolly and Beg,2002) ... 21
Gambar 2. 8Daur hidup JSP ... 31
Gambar 3. 1 Use case diagram untuk aktor operator area dan rayon ... 42
Gambar 3. 2 Use case diagram untuk aktor admin area dan rayon ... 43
Gambar 3. 3 Use case diagram package kelola monitoring pelanggan kwh 0 untuk aktor admin area ... 44
Gambar 3. 4 Use case diagram package kelola monitoring pelanggan kwh maks untuk aktor admin area ... 44
Gambar 3. 5 Use case diagram package kelola monitoring pelanggan TBTuntuk aktor admin area ... 45
Gambar 3. 6 Use case diagram package kelola monitoring pelanggan kwh 0 untuk aktor operator area ... 45
Gambar 3. 8 Use case diagram package kelola monitoring pelanggan TBTuntuk
aktor operator area ... 46
Gambar 3. 9 Use case diagram package kelola monitoring pelanggan kWh 0 untuk aktor operator dan admin rayon ... 47
Gambar 3. 10 Use case diagram package kelola monitoring pelanggan kWh maksuntuk aktor operator dan admin rayon ... 47
Gambar 3. 11 Use case diagram package kelola monitoring pelanggan TBT untuk aktor operator dan admin rayon ... 48
Gambar 3. 12 Use case diagram package kelola approve pelanggan kWh 0 untuk aktor admin area ... 49
Gambar 3. 13 Use case diagram package kelola approve pelanggan kWh maks untuk aktor admin area ... 50
Gambar 3. 14 Use case diagram package kelola approve pelanggan TBT untuk aktor admin area ... 51
Gambar 3. 15 Use case diagram packageapprove pelanggan kwh 0 untuk aktor admin rayon ... 52
Gambar 3. 16Use case diagram package approve pelanggan kwh maks untuk aktor admin rayon ... 52
Gambar 3. 17 Use case diagram package approve pelanggan TBT untuk aktor admin rayon ... 53
Gambar 3. 18 Use case diagram package kelola user untuk admin area ... 53
Gambar 3. 19 Use case diagram package kelola laporan untuk admin area ... 54
Gambar 3. 20 Use case diagram package lihat data untuk user admin area dan admin rayon ... 54
Gambar 3. 21 Activity diagram untuk use ase login user admin ... 115
Gambar 3. 22 Activity diagram untuk use ase login user operator ... 116
Gambar 3. 23 Activity Diagram dari use case tambah user ... 116
Gambar 3. 24 Activity diagram dari ubah data user ... 117
Gambar 3. 25 Activity diagram dari use case lihat data belum monitoring untuk pelanggan kwh 0 ... 118
Gambar 3. 26 Activity diagram dari use case lihat data belum monitoring untuk pelanggan kwh Maks ... 118
Gambar 3. 27 Activity diagram dari use case lihat data belum monitoring untuk pelanggan TBT ... 118
Gambar 3. 28 Activity diagram dari use case lihat data sudah monitoring untuk pelanggan kwh 0 ... 119
Gambar 3. 29 Activity diagram dari use case lihat data sudah monitoring untuk pelanggan kwh Maks ... 119
Gambar 3. 31 Activity diagram dari use case lihat data sudah approve untuk
pelanggan kwh 0 ... 120
Gambar 3. 32 Activity diagram dari use case lihat data sudah approve untuk pelanggan kwh maks ... 120
Gambar 3. 33 Activity diagram dari use case lihat data sudah approve untuk pelanggan TBT ... 120
Gambar 3. 34 Activity diagram dari use case lihat data belum approve untuk pelanggan kwh 0 ... 121
Gambar 3. 35 Activity diagram dari use case lihat data belum approve untuk pelanggan kwh maks ... 121
Gambar 3. 36 Activity diagram dari use case lihat data belum approve untuk pelanggan TBT ... 121
Gambar 3. 37 Activity diagramdari use case cek approve per-bulan untuk pelanggan kwh maks ... 122
Gambar 3. 38 Activity diagram dari use case cek approve per-bulan untuk pelanggan TBT ... 122
Gambar 3. 39 Activity diagram dari use case cek approve per-bulan untuk pelanggan kwh 0 ... 123
Gambar 3. 40 Activity diagram dari use case cek monitor per-bulan untuk pelanggan kwh 0 ... 123
Gambar 3. 41 Activity diagram dari use case cek monitor per-bulan untuk pelanggan kwh maks ... 124
Gambar 3. 42 Activity diagram dari use case cek monitor per-bulan untuk pelanggan TBT ... 124
Gambar 3. 43 Activity diagram dari use case upload data hasil monitor ... 125
Gambar 3. 44 Activity diagram dari use case ubah data hasil monitor ... 126
Gambar 3. 45 Activity diagram dari use case batalkan status monitor ... 127
Gambar 3. 46 Activity diagram dari use case batalkan status approve... 128
Gambar 3. 47 Activity diagram dari use case approve data hasil monitor (diasumsikan pelanggan kwh 0, kwh maks, dan TBT memiliki langkah yang sama) ... 129
Gambar 3. 48 Activity diagram dari use case lihat versi sebelum dari data hasil monitor ... 130
Gambar 3. 49 Activity diagram dari use case lihat history monitoring dari data hasil monitor ... 130
Gambar 3. 50 Activity diagram dari use case copy status bulan terakhir (diasumsikan pelanggan kwh 0, kwh maks, dan TBT memiliki langkah copy status yang sama) ... 131
Gambar 3. 52 Activity diagram dari use case cetak laporan untuk pelanggan kwh maks ... 132 Gambar 3. 53 Activity diagram dari use case cetak laporan untuk pelanggan TBT
... 133 Gambar 3. 54 Activity diagram dari use case cetak laporan untuk pelanggan
naik daya ... 133 Gambar 3. 55 Activity diagram dari use case tampilkan data yang sama pelanggan kwh 0 ... 134 Gambar 3. 56 Activity diagram dari use case tampilkan data yang sama pelanggan kwh maks ... 134 Gambar 3. 57 Activity diagram dari use case tampilkan data yang sama pelanggan TBT ... 134 Gambar 3. 58 Activity diagram dari use case lihat detail pelanggan ... 135 Gambar 3. 59 Diagram sekuensial untuk login admin ... 136 Gambar 3. 60 Diagram sekuensial untuk login operator ... 136 Gambar 3. 61 Diagram Sekuensial untuk use case tambah user ... 137 Gambar 3. 62 Diagram sekuensial untuk use case edit data user ... 138 Gambar 3. 63 Diagram sekeunsial untuk use case lihat daftar Kwh 0 belum cek
... 139 Gambar 3. 64 Diagram sekeunsial untuk use case lihat daftar kwh maks
belum cek ... 139 Gambar 3. 65 Diagram sekuensial untuk use case lihat daftar TBT sudah cek .. 140 Gambar 3. 66 Diagram sekuensial untuk use case lihat daftar kwh 0 sudah cek 140 Gambar 3. 67 Diagram sekuensial untuk use case lihat daftar kwh maks
sudah cek ... 141 Gambar 3. 68 Diagram sekuensial untuk use case lihat data kwh maks
cek perbulan ... 141 Gambar 3. 69 Diagram sekuensial untuk use case lihat data kwh 0 cek perbulan
... 142 Gambar 3. 70 Diagram sekuensial untuk use case lihat data TBT cek perbulan 142 Gambar 3. 71 Diagram sekuensial untuk use case lihat data kwh 0 cek approve
perbulan ... 143 Gambar 3. 72 Diagram sekuensial untuk use case lihat data kwh maks cek
approve perbulan ... 143 Gambar 3. 73 Diagram sekuensial untuk use case lihat data tbt cek approve
perbulan ... 144 Gambar 3. 74 Diagram sekuensial untuk use case lihat Data TBT lihat yang sama
... 144 Gambar 3. 75 Diagram sekuensial untuk use case lihat data kwh 0 cek
Gambar 3. 76 Diagram sekuensial untuk use case lihat data data kwh maks cek data yang sama ... 145 Gambar 3. 77 Diagram sekuensial untuk use case lihat versi sebelum data
monitoring pelanggan kwh 0 (kwh maks dan TBT sama) ... 146 Gambar 3. 78 Diagram sekuensial untuk use case lihat history monitoring
pelanggan kwh 0 (kwh maks dan TBT sama) ... 146 Gambar 3. 79 Diagram sekuensial untuk use case proses approve pelanggan kwh
0 (kwh maks dan TBT sama) ... 147 Gambar 3. 80 Diagram sekuensial untuk use case pembatalan status monitoring
pelanggan kwh 0 (kwh maks dan TBT sama) ... 148 Gambar 3. 81 Diagram sekuensial untuk use case pembatalan status approve .. 148 Gambar 3. 82 Diagram sekuensial untuk use case upload data monitoring
pelanggan kwh 0 (kwh maks dan TBT sama) ... 149 Gambar 3. 83 Diagram sekuensial untuk use case proses ubah data monitoring
pelanggan kwh 0 (kwh maks dan TBT sama) ... 150 Gambar 3. 84 Diagram sekuensial untuk use case proses copy status pelanggan
kwh maks (kwh 0 dan TBT sama) ... 151 Gambar 3. 85 Diagram sekuensial untuk use case cetak laporan monitoring kwh 0
... 151 Gambar 3. 86 Diagram sekuensial untuk use case cetak laporan monitoring
kwh maks ... 152 Gambar 3. 87 Diagram sekuensial untuk use case cetak laporan monitoring TBT
... 152 Gambar 3. 88 Diagram sekuensial untuk use case laporan rekomendasi
monitoring naik daya pelanggan kwh maks ... 153 Gambar 3. 89 Diagram Kelas ... 154 Gambar 3. 90 Desain konseptual basis data dari sistem ... 155 Gambar 3. 91 Desain logikal basis data dari sistem ... 156
Gambar 4. 11 Impelementasi function tambah_idapp_pasca ... 188 Gambar 4. 12 Implementasi function tambah_idapp_prabayar ... 189 Gambar 4. 13 Interface halaman Home Sistem ... 208 Gambar 4. 14 Interface menu login operator ... 209 Gambar 4. 15 Interface menu login admin ... 209 Gambar 4. 16 Interface halaman Utama Admin Area ... 210 Gambar 4. 17 Menu Lihat Data ... 210 Gambar 4. 18 Menu Monitoring ... 210 Gambar 4. 19 Menu Approve ... 211 Gambar 4. 20 Menu Cetak Laporan ... 211 Gambar 4. 21 Panel Logout ... 212 Gambar 4. 22 Halaman utama admin tingkat rayon ... 212 Gambar 4. 23 Halaman utama operator tingkat rayon dan area... 213 Gambar 4. 24 Halaman daftar user login ... 214 Gambar 4. 25 Halaman tambah user login ... 214 Gambar 4. 26 Halaman cari data user ... 215 Gambar 4. 27 Halaman edit data user ... 215 Gambar 4. 28 Halaman lihat daftar kwh 0 sudah cek (halaman kwh maks sama)
... 216 Gambar 4. 29 Halaman lihat daftar kwh 0 belum cek (halaman kwh maks sama)
... 217 Gambar 4. 30 Halaman cari data monitoring perbulan ... 217 Gambar 4. 31 Halaman daftar monitoring kwh 0 cek perbulan ... 217 Gambar 4. 32 Halaman daftar TBT sudah cek... 218 Gambar 4. 33 Halaman daftar TBT belum cek ... 218 Gambar 4. 34 Halaman daftar TBT cek perbulan ... 218 Gambar 4. 35 Halaman kwh 0 sudah cek untuk user admin dan operator rayon 219 Gambar 4. 36 Halaman kwh 0 belum cek untuk user admin dan operator rayon 219 Gambar 4. 37 Halaman kwh 0 cek perbulan untuk user admin dan operator rayon
Gambar 4. 48 Halaman lihat daftar approve perbulan untuk admin area ... 226 Gambar 4. 49 Halaman lihat daftar approve cek semua untuk admin area ... 226 Gambar 4. 50 Halaman cek data yang sama ... 227 Gambar 4. 51 Halaman lihat data approve per-unitup ... 227 Gambar 4. 52 Halaman lihat daftar sudah approve untuk user admin rayon ... 228 Gambar 4. 53 Halaman lihat daftar belumapprove untuk user admin rayon ... 228 Gambar 4. 54 Halaman lihat daftar cek approve perbulan untuk user admin rayon
... 229 Gambar 4. 55 Halaman approve data dan pembatalan status monitoring pelanggan kwh 0 ... 230 Gambar 4. 56 Halaman detail approve data pelanggan ... 231 Gambar 4. 57 Halaman liat detail versi sebelum ... 231 Gambar 4. 58 Halaman history monitoring ... 232 Gambar 4. 59 Halaman pencarian detail pelanggan ... 232 Gambar 4. 60 Halaman detail pelanggan ... 233 Gambar 4. 61 Interface Laporan Monitoring Kwh 0 ... 234 Gambar 4. 62 Halaman cetak laporan monitoring kwh 0 ... 234 Gambar 4. 63 Halaman daftar pelanggan monitoring perbulan yang akan dicetak
... 235 Gambar 4. 64 Preview dari cetak laporan monitoring kwh 0 gambar 4.63 ... 235 Gambar 4. 65 Halaman daftar pelanggan monitoring ... 236 Gambar 4. 66 Preview dari cetak laporan monitoring kwh 0 dari
gambar 4.65 ... 236 Gambar 4. 67 Halaman cetak blangko monitoring kwh maks naik daya ... 237 Gambar 4. 68 Halaman daftar pelanggan monitoring kwh maks naik daya ... 237 Gambar 4. 69 Preview cetak dari gambar 4.67 ... 238 Gambar 4. 70 Halaman daftar pelanggan monitoring kwh maks naik daya ... 238 Gambar 4. 71 Preview cetak laporan rekomendasi monitoring dari gambar 4.70
... 239
Gambar 5. 1 Alur proses monitoring pelanggan ... 242 Gambar 5. 2 Diagram simulasi percobaan 1 ... 243 Gambar 5. 3 Data pelanggan kwh 0 belum apporve (transaksi 1) ... 244 Gambar 5. 4 Data pelanggan kwh 0 sudah cek (transaksi 2) ... 245 Gambar 5. 5 Halaman lihat detail pelanggan untuk proses approve (transaksi 1)
... 245 Gambar 5. 6 Halaman isian untuk ubah data monitoring pelanggan (transaksi 2)
Gambar 5. 7 Prosedur approve_pascabayar dengan DBMS_LOCK.SLEEP selama 20 detik ... 247 Gambar 5. 8 transaksi 1 akan klik tombol APPROVE untuk melakukan approve
pada data tersebut ... 247 Gambar 5. 9 Transaksi 2 mengubah data koordinat, verifikasi, tanggal monitor,
dan keadaan MCB pada data pelanggan diatas ... 248 Gambar 5. 10 Transaksi 1 sukses ... 249 Gambar 5. 11 Transaksi 2 gagal ... 250 Gambar 5. 12 Kutipan fungsi tambah_idmon_pasca jika v_status_app tidak null
maka idmon = null ... 250 Gambar 5. 13 Daftar pelanggan kwh 0 sudah cek dimana status monitor idpel
225000006829 berubah menjadi sudah approve ... 251 Gambar 5. 14 Transaksi 1 yang akan approve data ... 252 Gambar 5. 15 Transaksi 2 yang akan mengubah data yang akan diapprove oleh
transaksi 1 ... 252 Gambar 5. 16 Klausa FOR UPDATE OF dihapus,delay diset 20 detik ... 253 Gambar 5. 17 Transaksi 2 berhasil melakukan ubah data... 253 Gambar 5. 18 Transaksi ubah data berhasil dilakukan ... 254 Gambar 5. 19 Detail monitoring telah diubah (transaksi 2) ... 254 Gambar 5. 20 Data history monitoring yang menjadi tidak konsisten ... 255 Gambar 5. 21 Detail approve transaksi 1 telah berubah, idmon versi sebelum
seharusnya 161029-124151-10899-MON ... 255 Gambar 5. 22 Diagram simulasi percobaan 2 ... 256 Gambar 5. 23 Daftar pelanggan kwh 0 belum approve ... 258 Gambar 5. 24 Halaman detail approve pelanggan pada transaksi 1 ... 258 Gambar 5. 25 Transaksi 2 yang akan approve data pelanggan diatas... 259 Gambar 5. 26 Transaksi 1 berhasil dilakukan, status monitoring pelanggan
menjadi null ... 259 Gambar 5. 27 Transaksi 2 gagal dilakukan sehingga harus rollback ... 260 Gambar 5. 28 Data pelanggan 225000060981 berstatus belum monitoring ... 260 Gambar 5. 29 Transaksi 1 yang akan melakukan pembatalan monitoring ... 262 Gambar 5. 30 Transaksi 2 yang akan melakukan approve monitoring ... 262 Gambar 5. 31 kutipan stored procedure batal_monitor_pasca dimana delay diset
20 detik, klausa FOR UPDATE OF ditutup ... 262 Gambar 5. 32 Transaksi 2berhasil dilakukan, status approve bernilai null ... 263 Gambar 5. 33 Transaksi 1 berhasil, karena status approve yang dibaca sebelum
Gambar 5. 34 Pada daftar pelanggan sudah approve, data pelanggan memiliki status approve dengan tanda silang, ini terjadi karena syarat status monitor tidak sama dengan null tidak terpenuhi... 264 Gambar 5. 35 Pada data history monitoring pelanggan tersebut, referensi idmon
versi sebelum menjadi tidak konsisten. Ada 2 record yang memiliki versi sebelum yang sama. ... 265 Gambar 5. 36Status monitoring pelanggan dengan idpel 225000020504 untuk
blth 201401 adalah null sedangkan status approve adalah YES. ... 265
DAFTAR TABEL
Tabel 2. 1 Notasi Use Case ... 23 Tabel 2. 2 Notasi class diagram ... 24 Tabel 2. 3Notasi activity diagram ... 24
Tabel 3. 23 Skenario use case Lihat daftar per-bulan TBT area ... 77 Tabel 3. 24 Skenario use case Lihat daftar per-bulan TBT rayon ... 78 Tabel 3. 25 Skenario use case Lihat daftar belum cek per-bulan kwh maks
area ... 78 Tabel 3. 26 Skenario use case Lihat daftar belum cek per-bulan kwh
Tabel 3. 61 Skenario Use Case Copy Status Bulan Terakhir TBT ... 105 Tabel 3. 62 Skenario use case lihat versi sebelum data pelanggan kwh maks ... 106 Tabel 3. 63 Skenario use case lihat versi sebelum data pelanggan kwh 0 ... 107 Tabel 3. 64 Skenario use case lihat versi sebelum data pelanggan TBT ... 107 Tabel 3. 65 Skenario Use Case lihat history monitoring pelanggan TBT ... 108 Tabel 3. 66 Skenario Use Case lihat history monitoring pelanggan kwh 0 ... 108 Tabel 3. 67 Skenario Use Case lihat history monitoring pelanggan kwh maks.. 109 Tabel 3. 68 Skenario use case cetak laporan kwh 0 1 bulan ... 109 Tabel 3. 69 Skenario use case cetak laporan kwh 0 beberapa bulan ... 110 Tabel 3. 70 Skenario use case cetak laporan kwh maks 1 bulan ... 111 Tabel 3. 71 Skenario use case cetak laporan kwh maks beberapa bulan ... 111 Tabel 3. 72 Skenario use case cetak laporan TBT 1 bulan ... 112 Tabel 3. 73 Skenario use case cetak laporan TBT beberapa bulan ... 113 Tabel 3. 74 Skenario use case cetak laporan rekomendasi monitoring naik daya
pelanggan kwh maks ... 113 Tabel 3. 75 Skenario use case cetak laporan rekomendasi monitoring naik daya
pelanggan kwh maks beberapa bulan ... 114 Tabel 3. 76 Tabel Data_Penduduk ... 157 Tabel 3. 77 Tabel Produk ... 157 Tabel 3. 78 Tabel Pelanggan ... 157 Tabel 3. 79 Tabel USER_LOGIN ... 157 Tabel 3. 80 Tabel KODE_UNIT ... 158 Tabel 3. 81 Tabel DLPD_PRABAYAR ... 158 Tabel 3. 82 Tabel DLPD_PRABAYAR ... 158 Tabel 3. 83 Tabel RECORD_MONITORING_PRABAYAR ... 158 Tabel 3. 84 Tabel MONITORING_PASCABAYAR ... 159
Tabel 4. 1Tabel Implementasi Kelas ... 195 Tabel 4. 2 Tabel Implementasi Basis Data ... 195 Tabel 4. 3 Tabel Implementasi User Interface ... 196
Tabel 5. 1 Proses yang terjadi saat approve data pelanggan dan ubah data
pelanggan (subbab 5.2.1) ... 266 Tabel 5. 2 Proses yang terjadi saat pembatalan status monitoring data pelanggan
Tabel 5. 3 Proses yang terjadi saat approve data pelanggan dan ubah data
pelanggan tanpa protokol 2PL (subbab 5.2.1) ... 270 Tabel 5. 4 Proses yang terjadi saat batalkan status monitoring dan approve tanpa
BAB I
PENDAHULUAN
1.1. Latar Belakang
Pengendalian susut merupakan salah satu upaya penekanan jumlah susut energi listrik yang disalurkan ke pelanggan. Pengendalian susut energi listrik dibedakan menjadi 2 yaitu secara teknis dan nonteknis. Pengendalian susut teknis berkaitan dengan usaha-usaha pemeliharaan dan pengawasan di pembangkit listrik, sedangkan pengendalian susut non teknis berkaitan dengan administrasi, manajemen kWh Meter, dan penanganan pencurian tenaga listrik.
Berdasarkan hasil pengamatan yang dilakukan oleh Penulis di PT. PLN (Persero) Area Kuala Kapuas khususnya di bagian Transaksi Energi, diketahui bahwa bagian Transaksi Energi memastikan daya 20 Kwh dari pembangkit didistribusikan ke pelanggan dalam bentuk listrik bertegangan 220 V. Untuk melakukan Pelanggaran Penggunaan Tenaga Listrik (P2TL) lebih mudah dilakukan pada tegangan 220V (oleh pelanggan atau oknum tertentu). Untuk menghindari kerugian akibat pelanggaran diatas maka perlu dilakukan monitoring untuk pelanggan pasca bayar dan prabayar. Monitoring pemakaian tenaga listrik oleh pelanggan merupakan salah satu bagian dari usaha pengendalian susut non teknis. Pelanggan yang perlu dimonitor adalah pelanggan pasca bayar kWh 0 dan kWh Maks ; dan pelanggan prabayar yang tidak beli token lebih dari 3 bulan.
Gambar 1. 1Grafik Pelanggan Monitoring Pascabayar Juni 2014 (sumber: Data
DPM PT.PLN (Persero) Area Kuala Kapuas Juni 2014)
Masalah yang ditemukan Penulis adalah monitoring yang dilakukan selama ini dilakukan secara manual dan tidak adafilterisasi untuk data yang sudah diperiksa sehingga pemeriksaan kadang dilakukan berulang kali. Pemakaian tenaga listrik yang tidak normal selama ini dipantau secara manual menggunakan perangkat pengolah kata seperti Microsoft Excel. Data berupa daftar pelanggan yang akan dimonitoring dalam bentuk tabel akan dicetak dan kemudian dibawa untuk diisi oleh petugas lapangan melakukan survei ke tempat pelanggan. Untuk membantu petugas baik di kantor maupun di lapangan dalam hal collecting data monitoringhingga proses persetujuan (approval).
PT. PLN (Persero) Area Kuala Kapuas terdiri dari 6 rayon, dimana tiap rayon juga bertanggung jawab untuk melakukan monitoring pelanggan di wilayahnya. Mengingat bahwa petugas yang menggunakan sistem monitoring bukan hanya petugas lapangan melainkan juga petugas yang berada di kantor maka sistem ini menerapkan manajemen transaksi yang melayani multiuser. Ketika ada dua petugas lapangan ingin mengupload data hasil monitoring pada pelanggan yang sama secara bersamaan atau ketika akan petugas di kantor akan melakukan pengecekkan dan proses approval monitoring pada data pelanggan yang sama dengan pengaturan proses transaksi yang menerapkan 2PL (2 Phase
22500 22510 22520 22530 22540 22550
Ju
Pelanggan Monitoring Pascabayar Juni 2014
Locking), maka proses update database dapat dilakukan dengan benar dan masalah lost update problem dapat diatasi, sehingga data hasil monitoring lebih akurat dan dapat dipertanggung-jawabkan.
Gambar 1. 2Grafik Pelanggan Monitoring Prabayar Juni 2015 (sumber: Data TBT
PT.PLN (Persero) Area Kuala Kapuas Juni 2015).
Sistem yang multiuser ini mengharuskan adanya sebuah penanganan transaksi ketika satu atau beberapa user akan write dan atau read data secara bersamaan. Hal ini dilakukan untuk menghindari masalah proses konkuren diantaranyaThe Lost Update Problem, The Uncommited Dependency (Dirty Read) Problem, dan The Inconsistent Analysis Problem. Sehingga diperlukan manajemen transaksiuntuk mengatur kelancaran dari tiap action yang dilakukan oleh user sistem terhadap data. Untuk menjawab permasalah yang telah dipaparkan di atas maka Penulis akan membuat Sistem Monitoring Pelanggan Pascabayar dan Prabayar Tidak Beli Token Menerapkan Manajemen Transaksi Menggunakan MetodeTwo Phase Locking.
839
22500 22510 22520 22530 22540 22550
1.2. Rumusan Masalah
Rumusan masalah yang ingin dijawab dalam karya tulis ini adalah sebagai berikut:
1. Bagaimana membangun sistem monitoring yang dapat menyimpan dokumentasi data monitoring dan approval yang dilakukan petugas serta membuat report rekomendasi monitoring naik daya bagi pelanggan kWh maks dengan menerapkan manajemen transaksi dengan menggunakan metode two phase locking?
2. Bagaimana implementasi uji coba sistem ini mampu secara efisien membantu PT. PLN (Persero) Area Kuala Kapuas dan sejauh mana sistem mudah digunakan oleh user?
1.3. Tujuan
Tujuan dari sistem yang akan dibuat ini adalah sebagai berikut:
1. Membangun Sistem Monitoring Pelanggan Pascabayar dan Prabayar yang dapat memudahkan proses monitoring dan approval pelanggan dengan menerapkan manajemen transaksi dengan protokol two phase locking. 2. Membantu menghindari kesalahan yang disebabkan karena human error
dan mempercepat proses monitoring pelanggan kWh 0, kWh Maks, dan tidak beli token di atas 3 bulan yang dilakukan oleh petugas di kantor maupun di lapangan dibandingkan dengan proses manual.
3. Membuat dokumentasi dan pertanggung-jawaban yang jelas terhadap tindakan monitoring pelanggan yang dilakukan oleh petugas monitoring baik di kantor dan di lapangan.
1.4. Batasan Masalah
Sistem yang akan dibangun memiliki batasan sebagai berikut:
1. Data pelanggan monitoring kWh Maks, kWh 0, dan pelanggan tidak beli token lebih dari 3 bulan merupakan data yang didapatkan dari Sistem Informasi lain diluar Sistem Monitoring yang akan dibangun ini.
2. Ketentuan monitoring seperti alur dan data-data yang ingin didapatkan ketika monitoring ditentukan oleh PT. PLN (Persero) Area Kuala Kapuas selaku pihak yang mengerti proses bisnis dalam masalah ini.
3. Pelanggan yang perlu dimonitor adalah pelanggan pasca bayar kWh 0 dan kWh Maks ; dan pelanggan prabayar yang tidak beli token lebih dari 3 bulan.
4. Aturan untuk menentukan pelanggan naik daya yang harus dimonitoring pada pelanggan kWh Maks telah ditentukan sesuai dengan best practice dan petunjuk teknis oleh PT. PLN (Persero) Area Kuala Kapuas.
5. Terjadinya penurunan susut yang ditargetkan oleh PT. PLN (Persero) Area
Kuala Kapuas bukan serta merta terjadi hanya karena
diimplementasikannya Sistem Monitoring ini.
6. Sistem Monitoring yang dibangun ini dibatasi hanya untuk keperluan monitoring pelanggan pada bagian Transaksi Energi di PT. PLN (Persero) Area Kuala Kapuas.
7. Sistem Monitoring ini dibuat dengan menggunakan bahasa pemrogaman JAVAdan JSP serta menggunakan database Oracle Enterprise Edition10g dengan pertimbangan diperlukan storage yang lebih besar untuk menyimpan dan mengelola data pelanggan monitoring.
1.5. Metodologi Penelitian
Dalam menganalisa masalah Penulis menggunakan metode-metode penelitian yang dibagi menjadi 3 tahap sebagai berikut :
1. Survei dan Pengumpulan Data
- Wawancara
Merupakan suatu pengumpulan data yang dilakukan dengan cara tanya jawab atau dialog secara langsung dengan pihak PT. PLN (Persero) Area Kuala Kapuas terutama di Bagian Transaksi Energi mengenai proses bisnis dan kesulitan yang dihadapi dalam proses bisnis tersebut.
- Dokumentasi
Merupakan suatu cara pengumpulan data yang dilakukan dengan mengumpulkan dokumen maupun data pelanggan berkaitan dengan penggunaan tenaga listrik dalam selama jangka waktu tertentu yang didapat dari Bagian Transaksi Energi di PT. PLN (Persero) Area Kuala Kapuas.
- Pengamatan
Merupakan suatu cara pengumpulan data yang dilakukan dengan pengamata dan pencatatan langsung maupun tidak langsung terhadap objek yang dibahas. Disini penulis mengamati bagaimana proses monitoring penggunaan listrik pelanggan baik di lapangan maupun tidak (di kantor).
2. Pengembangan Sistem
Pengembangan sistem informasi menggunakan metode FAST (Framework for the Application of Systems Thinking) menurut Whitten (2001) yang fasenya meliputi :
1. Definisi lingkup masalah.
Pada fase ini dilakukan definisi ruang lingkup masalah dengan melakukan pengamatan dan wawancara kepada pihak Transaksi Energi mengenai pengelolaan data-data pelanggan monitoring beserta prosesnya dan permasalahan yang dihadapi untuk menentukan ruang lingkup masalah.
2. Analisa masalah
3. Analisa Kebutuhan
Pada fase ini dilakukan analisa kebutuhan-kebutuhan pengguna, untuk mencari tahu apa yang mereka perlukan atau inginkan dari sistem baru. Dimulai dengan mendeskripsikan calon pengguna sistem informasi kemudian digambarkan dalam bentuk use-case.
4. Desain logikal
Pada fase ini akan dilakukan desain secara logical. Desain logical dari sistem informasi ini meliputi desain basis data mengunakan Entity Relation diagram, diagram konteks, diagram berjenjang dan diagram arus data.
5. Desain fisikal
Pada fase ini hal yang dilakukan adalah membangun sistem secara fisik berdasarkan teknologi yang digunakan, desain arsitektur dan desain antarmuka pengguna (user interface).
6. Konstruksi dan Pengujian
Pada fase ini dilakukan pembuatan sistem sesuai dengan desain yang sudah dibuat sebelumnya dan pengujian sistem monitoring pelanggan ini terhadap pengguna sistem yaitu karyawan dan staff Transaksi Energi.
3. Survei Pengunaan Sistem Monitoring
Uji coba sistem ini dilakukan untuk mengetahui sejauh mana dapat membantu dalam memberikan informasi tentang ketersediaan, riwayat, laporan dan membantu proses monitoring pelanggan dengan menerapkan manajemen transaksidengan menggunakan kuesioner.
1.6. Sistematika Penulisan
Sistematika penulisan dibagi menjadi 6 Bab yang terdiri atas:
BAB I Pendahuluan
BAB II Landasan Teori
Berisi teori-teori yang digunakan sebagai dasar untuk mengembangkan sistem monitoring pelanggan ini meliputi sistem monitoring, definisi Basis Data, Entity-Relationship Modelling, Use Case Diagram, Manajemen transaksi , JAVA, JSP, Semantic-UI dan Oracle 10g.
BAB III Analisa Dan Perancangan Sistem
Berisi tentang analisa sistem meliputi gambaran umum sistem, use case diagram,pemodelan sistem dalam bentuk diagram konteks, diagram berjenjang, diagram aliran data, pemodelan data yang terdiri dari entity relationship diagram. Desain sistem yang meliputi desain antarmuka dan desain basisdata terdiri dari desain logikal basis data dan desain fisikal basis data
BAB IV Implementasi Sistem
Berisi tentang penjelasan implementasi monitoring pelanggan yang meliputi struktur menu system, tampilan program, implementasi stored procedure, dan function, serta method yang dijalankan dalam program.
BAB V Analisa Hasil
Berisi tentang analisa dari hasil implementasi sistem yang telah dibangun, hasil pengujian stored procedure yang menerapkan method two phase locking dalam manajemen transaksi , dan membahas kelebihan dan kekurangan yang ada pada sistem. Bab ini juga membahas hasil uji coba sistem terhadap petugas di lapangan maupun non lapangan yang menjadi user dari sistem ini. BAB VI Penutup
BAB II
LANDASAN TEORI
2.1. Sistem Monitoring
Secara harafiah sistem monitoring terdiri dari 2 (dua) kata yaitu „sistem‟ dan „monitoring‟. Menurut Jogiyanto (2005) , sistem adalah suatu jaringan kerja dari prosedur-prosedur yang saling berhubungan, berkumpul bersama-sama untuk melakukan suatu kegiatan atau untuk menyelesaikan suatu sasaran tertentu. Sistem mempunyai karakteristik atau sifat-sifat tertentu, yaitu : Komponen Sistem, Batasan Sistem, Lingkungan Luar Sistem, Penghubung Sistem, Masukan Sistem, Keluaran Sistem, Pengolahan Sistem, dan Sasaran Sistem (Sutanta, 2009).
Menurut Cassely dan Kumar (1987) monitoring merupakan program yang terintegrasi, bagian penting dipraktek manajemen yang baik dan arena itu merupakan bagian integral di manajemen sehari-hari. Sedangkan menurut Calyton dan Petry (1983) monitoring sebagai suatu proses mengukur, mencatat, mengumpulkan, memproses dan mengkomunikasikan informasi untuk membantu pengambilan keputusan manajemen program/proyek.
Sistem monitoring adalah suatu jaringan kerja dari prosedur yang saling berhubungan yang dapat mencatat, mengukur, mengumpulkan, memproses, melakukan pengawasan, dan mengkomunikasiskan informasi dari tiap bagian yang diawasi sehingga dapat membantu pengambilan keputusan manajemen program/proyek dalam sebuah perusahaan atau organisasi.
2.2. Basis Data
Berikut ini merupakan penjelasan mengenai teori tentang Basis Data: 2.2.1. Pengertian Basis Data
Korth, dan S.Sudarshan (2001) mendefinisikan basis data sebagai sekumpulan data yang saling berhubungan dan menjadi bagian dari DBMS.
2.2.2. Sistem Basis Data
Sistem basis data berbeda dengan basis data, sistem basis data memiliki ruang lingkup yang leboh luas karena terdiri dari kumpulan beberapa basis data baik yang terhubung maupun tidak terhubung secara langsung dalam suatu sistem, tetapi secara keseluruhan mempunyai hubungan sebagai sebuah sistem dengan didukung oleh komponen lainnya. Istilah sistem basis data dapat didefiniskan sebagai sekumpulan subsistem yang terdiri atas basis data dengan para pemakai yang menggunakan basis data secara bersama-sama, personal-personal yang merancang dan mengelola basis data, teknik-teknik untuk merancang dan mengelola basis data, serta sistem komputer untuk mendukungnya (Martin, 1975).
2.2.3. Batasan Aturan Basis Data
Dalam perancangan dan penyusunan basis data dikenal adanya beberapa batasan aturan yang haris ditaati. Batasan aturan tersebut diperlukan agar file-file basis data yang disusun dapat menenuhi batasan/kriteria sebagaimana definisi basis data yang dijelaskan sebelumnya. Menurut James Martin (1975), batasan aturan tersebut berhubungan dengan lima aspek penting dalam basis data, yaitu:
1. Kerangkapan data (data redudancy) 2. Inkonsistensi data (data inconsistency) 3. Data terisolasi (data isolation)
4. Kemananan data (data security) 5. Integritas data (data integrity)
Abraham Silberschatz, Henry f.Korth, dan S.Sudarshan (2001) menyatakan bahwa basis data yang benar mampu mengatasi semua permasalahan yang terkait dengan batasan aturan di atas.
1. Kerangkapan data (data redudancy)
1. Pemborosan media penyimpanan basis data 2. Biaya penyimpanan yang semakin besar
3. Kesulitan atau in-efisiensi dalam pengolahan data 4. Pemborosan waktu dalam pengolahan data
5. Resiko yang semakin besar kemungkinan munculnya inkonsistensi data. 2. Inkonsistensi data (data inconsistency)
Inkonsisten data (data inconsistency) atau data tidak konsisten adalah munculnya data yang tidak konsisten pada medan/kolom yang sama dalam satu atau beberapa file data yang dihubungkan/direlasikan (Sutanta, 2011). Inkonsistensi data ini dapat terjadi diakibatkan oleh (Sutanta, 2004):
1. Proses pemasukan data (data entry) yang tidak benar 2. Proses pembaruan data (update) yang tidak benar 3. Pengendalian sistem yang tidak baik/terkontrol
Menurut Edhy Sutanta dalam bukunya yang berjudul Basis Data dalam Tinjaun Konseptual (2004) penyebab utama munculnya data yang tidak konsisten adalah akibat munculnya kerangkapan data dalam file. Oleh karena itu, contoh inkonsistensi data ini juga dapat berlaku pada file yang mengalami kerangkapan data. Basis data yang baik haruslah terbebas dari inkonsistensi data karena akan berakibat kesalahan fatal pada informasi yang dihasilkan dari pengolahan data dalam basis data yang tidak dapat merepresentasikan fakta yang ada.
3. Data Terisolasi (Data Isolation)
1. Tidak adanya kemungkinan untuk menghubungkan antar data dalam file. 2. Tidak adanya standarisasi data (berkaitan dengan domain/format data,
meliputi tipe dan ukuran data).
4. Keamanan Data (Data Security)
Kemananan data (data security) merupakan aspek penting dalam basis data. Prinsip keamanan dalam basis data adalah bahwa data-data dalam basis data merupakan sumber informasi yang bersifat sangat penting dan rahasia (Sutanta, 2011). Sehingga perlu untuk menjaga data-data dari kerusakan dan kehilangan yang dapat merusak data. Aspek keamanan basis data meliputi (Martin, 1975):
1. Recovery, adalah suatu proses menggunakan kembali basis data dan media penyimpanan cadangan untuk mengembalikan data pada kondisi yang benar karena terjadi kerusakan/kehilangan data akibat kerusakan media penyimpanan, program aplikasi, OS, basis data, hardware, dll.
2. Integrity, adalah dengan unjuk kerja sistemuntuk dapat menjaga data-data dalam basis data agar selalu berada dalam kondisi yang benar (tipe dan ukuran datanya), up to date (sesuai dengan kondisi aktual), konsisten, dan selalu tersedia.
3. Concurency, berkaitan dengan mekanisme pengendalian basis data saat digunakan oleh beberapa pemakai secara bersamaan agar terhindar dari kesalahan akibat beberapa transaksi berbeda dilakukan secara bersamaan. 4. Privacy, yaitu dimaksudkan sebagai pembatasan kewenangan akses data
dalam basis data dari penggunaan oleh pengguna yang tidak berwewenang dan pengubahan yang tidak dikehendaki.
5. Security, adalah suatu mekanisme system utnuk mencegah dan melindungi basis data kehilangan akibat kerusakan pada fisik media penyimpanan, kebakaran, banjir, badai, huru-hara, dll.
5. Integritas Data (Data Integrity)
basis data selalu berada dalam kondisi yang benar (tipe dan ukuran datanya), up to date (sesuai dengan kondisi aktual), konsisten, dan selalu tersedia (current). Hal ini merupakan aspek kritis dalam manajemen basis data (Martin, 1975).
2.2.4. Entity-Relationship Modelling (E-R Modelling)
Entity Relationship Modelling E-R Modelling merupakan suatu model data yang dikembangkan berdasarkan obyek. E-R Modelling digunakkan untuk menjelaskan hubungan antar data dalam basis data kepada pengguna secara logic. E-R Modelling didasarkan pada suatu persepsi bahawa real world terdiri atas obyek-obyek dasar yang mempunyai hubungan/kerelasian antarobyek-obyek dasar tersebut (Martin, 1975). E-R Modelling digambarkan dalam bentuk diagram yang disebut diagram E-R (E-R Diagram/E-R_D). Untuk menggambarkan E-R_D digunakan simbol-simbol grafis tertentu.
Penggunaan E-R Modelling relatif mudah dipahami, bahkan oleh para pengguna yang awam. Bagi perancang/analis sistem, E-R_D berguna untuk memodel-kan sistem yang nantinya basis datanya akan dikembangkan. Model ini juga membantu perancang/analis sistem pada saat melakukan analisis dan perancangan basis data karena model ini dapat menunjukkan macam data yang dibutuhkan dan kerelasian antardata di dalamnya. Bagi pengguna, model ini sangat membantu dalam hal pemahaman model sistem dan rancangan basis data yang akan dikembangkan oleh perancang/analis sistem (Sutanta, 2004).
2.2.4.1. Tipe Entitas (Entity Type)
Gambar 2. 1Representasi Diagram dari Entity Type Staff dan Branch(Connolly
and Beg, 2002)
2.2.4.2. Tipe Relasi (Relationship Type)
Tipe Relasi (Relationship Type)ialah sekumpulan entitas (entity) yang mempunyai hubungan dan memiliki arti (Connolly and Beg, 2002) ditunjukkan secara lebih jelas pada gambar 2.2 berikut ini:
Gambar 2. 2Representasi Diagram dari Entity Branch Has Staff Relationship Type(Connolly and Beg, 2002)
2.2.4.3. Atribut (Attributes)
1. Simple Attribute dan Composite Attribute
Simple attribute adalah attribute yang terdiri dari komponen tunggal dimana attribute tersebut tidak dapat dibagi ke dalam komponen yang lebih kecil. Simple attribute juga dapat disebut dengan atomic attribute. Contoh dari simple attribute adalah position dan salary dari staff entity. Composite attribute adalah attribute yang terdiri dari banyak komponen dimana beberapa attribute tersebut dapat dibagi kedalam komponen yang lebih kecil. Contoh dari composite attribute adalah address dari branch entity yang dapat dibagi menjadi street, city, dan postcode.
2. Single-Valued Attribute dan Multi-Valued Attribute
Single-valued attribute adalah attribute yang memiliki satu nilai pada setiap entity. Contoh dari single-valued attribute adalah branch_No dari branch entity. Multi-valued attribute adalah attribute yang memiliki beberapa nilai pada setiap entity. Contoh dari multi-valued attribute adalah tel_No dari branch entity.
3.Derived Attribute
Derived Attribute adalah atribut yang nilai-nilainya diperoleh dari hasil perhitungan atau dapat diturunkan dari atribut lain yang berhubungan. Contoh dari derived attribute adalah duration dari lease entity dimana diperoleh dari perhitungan rent_Start dan rent_Finish.
2.2.4.4. Kunci (Keys)
Menurut Connolly dan Begg (2002) jenis – jenis kunci adalah sebagai berikut (ilustrasi untuk memperjelas dijelaskan pada gambar 2.3) :
1. Candidate key, jumlah minimal dari attribute yang secara unik mengidentifikasi setiap peristiwa dalam entity
2. Primary key, candidate key yang terpilih secara unik mengidentifikasi setiap peristiwa dalam entity
2. Alternate key, candidate key yang tidak terpilih menjadi primary key 3. Composite key, candidate key yang terdiri dari dua atau lebih attribute 4. Foreign key, atribut sebuah entity yang menggabungkan diri ke entity lain
2.2.5. Manajemen Transaksi
Transaksi adalah sebuah tindakan atau serangkaian tindakan, dilakukan olehuser atau program aplikasi, yang membaca atau mengubah isi dari basis data(Connolly and Beg, 2002). Terdapat 4 hal dasar yang harus dimiliki semua transaksi, yaitu:
1. Atomicity
Sebuah transaksi adalah sebuah unit yang tidak dapat dibagi lagi sehingga dapatmelakukan seluruhnya atau tidak melakukan apapun. Ini merupakan tanggung jawab dari subsistem recovery dari DBMS untuk memastikan ke-„atom‟-annya.
2. Consistency
Sebuah transaksi harus mentransformasikan satu keadaan konsisten ke keadaan konsisten lainnya. Ini merupakan tanggung jawab dari DBMS dan pengembang aplikasi untuk memastikan kekonsistenannya.
3. Isolation
Transaksi secara bebas mengeksekusi yang lainnya. Dengan kata lain, sebagian transaksi yang tidak lengkap akan mengakibatkan transaksi yang lain menjadi tidak visible.Ini merupakan tanggung jawab dari subsistem concurrency control untuk memastikan isolasi.
4. Durability
dengan sukses, maka efeknya tetap bertahan bahkan jika sistem mengalami crash sebelum semua perubahannya direfleksikan pada disk. Ini merupakan tanggung jawab dari recovery subsistem untuk memastikan durability.
Gambar 2. 4Diagram Transisi Transaksi (Connolly and Beg, 2002)
Berdasarkan Gambar 2.4 dalam diagram transisi tersebut terdapat 5 keadaan yaitu: 1. ACTIVE (aktif)
2. PARTIALLY COMMITTED (sebagian dilaksanakan)
Terjadi setelah perintah terakhir dieksekusi
Pada saat ini, mungkin ditemukan transaksi melanggar serializability atau melanggar integrity constraint, maka transaksi harus dibatalkan. Transaksi demikian akan menuju FAILED (keadaan gagal) dan harus dibatalkan
Jika transaksi sukses, beberapa update dapat disimpan secara aman dan transaksi menuju ke keadaan COMMITTED.
3. COMMITTED (dilaksanakan) 4. FAILED (gagal)
Terjadi jika transakasi tidak dapat dilaksanakan atau transaksi dibatalkan pada saat ACTIVE (keadan aktif).
Kondisi ini terjadi jika user membatalkan transaksi atau protocol concurrency control membatalkan transaksi untuk memastikan serialibility.
2.2.5.1. Metode Locking
Locking adalah sebuah prosedur yang digunakan untuk melakukan kontrol pada akses bersama pada data. Pada saat satu transaksi melakukan akses ke dalam database, sebuah lock akan menyebabkan pelarangan akses ke dalam transaksi untuk mencegah hasil yang tidak konsisten. Terdapat 2 jenis lock, yaitu Shared Lock, dan Exclusive Lock. Jika sebuah transaksi memiliki shared lock padasebuah data item, maka transaksi tersebut dapat melakukan pembacaan terhadap sebuah item
tetapi tidak dapat melakukan update. Sedangkan jika sebuah transaksi yang memiliki
Exclusivelock pada sebuah data item dapat melakukan pembacaan maupun update
item tersebut.
2.2.5.2. Two Phase Locking (2PL)
Transaksi dapat dilakukan menggunakan protokol 2PL jika semua operasilocking mendahului operasi yang tidak terkunci dalam transaksi tersebut.Protokol 2PL memiliki 2 fase, yaitu (Connolly and Beg,2002):
a. Growing phase : jika transaksi sudah mendapatkan semua lock, maka tidak boleh melepas lock.
b. Shrinking phase : jika transaksi sudah melepaskan lock, maka tidak dapat mendapatkan lock baru.
Beberapa masalah yang disebabkan oleh proses yang konkurenseperti dibawah ini bisa ditangani dengan menerapkan protokoltwo phase locking(2PL)(Connolly and Beg,2002):
a. The Lost Update Problem, merupakan kejadian dimana data transaksi yang telah diupdate dibaca oleh transaksi yang lain kemudian di update lagi.
b. The Uncommited Dependency (Dirty Read) Problem, merupakan kejadian dimana data transaksi yang dilakukan dibaca oleh transaksi yang lain, lalu dibatalkan tanpa adanya penyimpanan terlebih dahulu oleh transaksi yang pertama sehingga menyebabkan data yang tidak benar.
melakukan perubahan dan transaksi yang kedua melakukan analisis sehingga data yang diperoleh menjadi tidak konsisten.
2.2.5.3. Contoh Penangangan Masalah Concurrency Control
Di bawah ini merupakan contoh-contoh untuk menangani masalah concurrency control :
Gambar 2. 5Mencegah Lost Update Problem menggunakan 2PL(Connolly and
Beg, 2002)
Keterangan :
Untuk mencegah terjadinya masalah hilangnya data yang diubah, maka : pertama-tama T2 meminta exclusive lock pada balₓ Setelah itu T2 dapat melakukanproses baca nilai balₓ, menambahnya dengan nilai 100, dan menuliskan nilai baru dari balₓ tersebut kedalam basis data.
Gambar 2. 6Mencegah Uncommited Dependency Problem using 2PL(Connolly
and Beg,2002)
Keterangan :
Untuk mencegah terjadinya masalah ketergantungan transaksi yang belum dilaksanakan, maka : pertama-tama T4 meminta suatu exclusive lock pada balx. Setelah itu, T4 dapat melakukan proses baca nilai balx dari dalam basis data, menambahnya dengan nilai 100, dan menuliskan nilai baru balx tersebut ke dalam basis data. Rollback dieksekusi, peng-update-an pada transaksi T4 tidak jadi dilakukan dan nilai dalam basis data dikembalikan ke kondisi semula yaitu 100.
Gambar 2. 7Mencegah Inconsistent Analysis Problem using 2PL(Connolly and
Beg,2002)
Keterangan :
Untuk mencegah terjadinya masalah analisis yang tidak konsisten , maka : T5 mengawali meminta suatu exclusive lock pada balx. T5 juga meminta suatu exclusive lock pada baly. Saat T6 ingin membaca nilai balx, ia harus menunggu sampai lock dilepaskan oleh T5. Hal ini terjadi saat T5 melaksanakan operasi commit atau unlockbalx, barulah T6 dapat membaca nilai balx(Connolly and Beg, 2002). Untuk mengatasi masalah di atas, mesin basis data Oracle mempunyai kemampuan mendukung transaksi dengan metode 2PL yang dapat menjamin konsistensi data.
2.2.5.4. Perintah For Update
Penguncian record dalam database dapat dilakukan dengan perintah for update dalam kueri(OracleInc, 2004).
Sintak yang digunakan :
2.3. Use Case Diagram
Pembuatan use case diagram yang sesungguhnya merupakan deskripsi peringkat tinggi bagaimana perangkat lunak (aplikasi) akan digunakan oleh penggunanya. Selanjutnya use case diagram tidak hanya sangat penting pada tahap analisis, tetapi juga sangat penting untuk perancangan (design), untuk mencari (mencoba menemukan) kelas-kelas yang terlibat dalam aplikasi, dan untuk melakukan pengujian (testing).
Membuat use case diagram yang komprehensif merupakan hal yang sangat penting dilakukan pada tahap analisis. Dengan menggunakan usecase diagram, akan didapatkan banyak informasi yang sangat penting yang berkaitan dengan aturan-aturan bisnis yang coba kita tangkap. Dalam hal ini, setiap objek yang berinteraksi dengan sistem/perangkat lunak (misalnya orang, suatu perangkat keras, sistem lain, dan sebagainya) merupakan actor untuk sistem perangkat lunak, use case merupakan deskripsi lengkap tentang bagaimana sistem/perangkat lunak berperilaku untk para aktornya. Dengan demikian use case diagram merupakan deskripsi lengkap tentang interaksi yang terjadi antara para actor dengan sistem/perangkat lunak yang sedang dikembangkan.
Saat akan mengembangkan use case diagram, hal yang pertama kali dilakukan adalah mengenali actor untuk sistem/aplikasi yang sedang dikembangkan. Dalam hal ini, ada beberapa karakteristik untuk para actor, yaitu actor ada di luar sistem yang sedang dikembangkan dan actor berinteraksi dengan sistem yang sedang dikembangkan (Adi Nugroho, 2009). Rosa A. S dan M. Salahuddin (2013) mengungkapkan bahwa Use case atau diagram use case
<<include>>
Notasi yang digunakan dalam Use Caseadalah seperti yang disajikan dalam tabel 4.1 berikut ini:
Tabel 2. 1 Notasi Use Case
No Notasi Keterangan
1 Gambar di samping adalah notasi untuk aktor. Aktor menggambarkan segala pengguna software aplikasi (user).
2
interaction. Interaction digunakan untuk
menunjukkan baik aliran pesan atau informasi antar objek.
4
Gambar di samping adalah notasi untuk
package. Package adalah mekanisme
pengelompokan yang digunakan untuk menandakan pengelompokan elemen-elemen model.
5
Extend adalah Relasi usecase tambahan kesebuah usecase dimana use case yang ditambahkan dapat berdiri sendiri walau tanpa use case tambahan itu.
6
Include adalah relasi usecase tambahan
ke sebuah usecase dimana use case yang ditambahkanmemerlukan usecase ini untuk menjalankan fungsinya.
2.4. Class Diagram
Tabel 2. 2 Notasi class diagram (Rosa A.S dan M. Shalahuddin ,2014)
Nama Simbol Simbol Deskripsi
Package Package merupakan
sebuah bungkusan dari satu atau lebih kelas
Kelas Kelas pada struktur
sistem.
Asosiasi/
association
Relasi antarkelas dengan makna umum, asosiasi biasanya juga disertai dengan multiplicity asosiasi berarah/
directed association
Relasi antar kelas dengan makna kelas yang satu digunakan oleh kelas lain, asosiasi juga biasanya disertai dengan multiplicity
2.5. Activity Diagram
Activity diagram menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Rosa A.S & M. Shalahuddin (2010:134) menyatakan bahwa activity diagram menggambarkan workflow (aliran kerja) atau aktivitas dari sebuah sistem, proses bisnis atau menu yang ada diperangkat lunak.
2.6. Oracle
Oracle Corporation (Oracle Corp) memberikan definisi-definisi sendiri
tentang basis data relasional, yaitu kumpulan relations. Sebuah relation adalahsebuah
two-dimensional table. Lebih tepatnya adalah kumpulan tabel dan obyek-obyek non
tabel yang dikelompokan berdasarkan pemakai (OracleInc, 2004).
Sifat-sifat basis data relasional:
1. Bisa diakses lewat bahasa pemrograman tingkat tinggi, SQL (Structured Query Language).
2. Memiliki sekumpulan tabel tanpa pointer fisik (Oracle melanggar perintah ini dengan tipe REF).
3. Memakai sekumpulan operasi set. 2.6.1. Penjelasan Tentang SQL
SQL (Structured Query Language) adalah bahasa standar yang digunakan untuk memperoleh dan memanipulasi data dari basis data relasional. SQL merupakan bahasa nonprosedural yang mendefinisikan apa yang harus dilakukan oleh sebuah basis data relasional, yang kemudian akan mengimplementasikan perintah SQL tersebut.
