IMPLEMENTASI TRANSACTION MANAGEMENT
PADA DATABASE SISTEM INVENTORY
(Studi Kasus : PT. Mega Andalan Kalasan)
Tugas Akhir
Diajukan untuk Memenuhi Salah Satu Syarat Memperoleh Gelar Sarjana Teknik
Jurusan Teknik Informatika
Oleh:
Caecilia Ika Wahyu A NIM : 025314070
PROGRAM STUDI TEKNIK INFORMATIKA JURUSAN TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS SANATA DHARMA YOGYAKARTA
A Thesis
Presented as Partial Fulfillment of the Requirements To Obtain the Sarjana Teknik Degree
In Informatics Engineering
By:
Caecilia Ika Wahyu A. Student Number : 025314070
INFORMATICS ENGINEERING STUDY PROGRAM
DEPARTMENT OF INFORMATICS ENGINEERING
FACULTY OF SCIENCE AND TECHNOLOGY
SANATA DHARMA UNIVERSITY
YOGYAKARTA
2007
PERNYATAAN
Dengan ini saya sebagai penulis tugas akhir menyatakan dengan
sesungguhnya bahwa skripsi yang saya tulis ini tidak memuat karya atau bagian
karya orang lain, kecuali pemikiran, metode atau hasil penelitian orang lain yang
diambil disebutkan dengan jelas sebagai acuan.
Yogyakarta, 20 September 2007
(Caecilia Ika Wahyu)
HALAMAN PERSEMBAHAN
Skripsi ini Kupersembahkan unt uk :
Yesus Kristus dan Bunda Maria y ang selalu mengasihi dan membimbing ak u dalam setiap perjalanan hidupk u
Almarhum Ay ahk u y ang telah memberik an pendampingan dari ak u k ecil hingga Dewasa.
Ibuk u atas Cinta dan perhatianny a y ang diberik an k epadak u Semenjak Kecil Hingga Dewasa
Adik k u y ang menjadi semangat hidupk u di perantauan.
Seseorang y ang selalu ada untuk k u baik dalam suk a maupun duk a
Dan Seluruh Sahabat-sahabatk u y ang memberik an k asih dan persahabatan y ang indah
HALAMAN MOTTO
Kita patut dan layak berusaha tapi hanya Tuhan
yang menentukan
Semua kehendak-NYA indah pada waktunya
ABSTRAKSI
Setiap ada penambahan dan pengurangan data stok material pada
database sistem inventory Raw Material pada Unit Komponen Logam yang dimiliki oleh PT. Mega Andalan Kalasan seringkali terjadi ketidak konsistenan
data dikarenakan data tersebut digunakan oleh banyak pengguna secara hampir
bersamaan.
Oleh karenanya diperlukan teknologi Transaction Management untuk
melakukan pengelolaan transaksi, sehingga transaksi yang berlangsung dapat
dilaksanakan dengan baik dan database dapat terjaga konsistensinya. Teknologi
ini diimplementasikan dengan menggunakan bahasa pemrograman SQL pada
mesin DBMS SQLServer 2000.
Hasilnya adalah transaksi-transaksi tersebut dapat berjalan berurutan dan
saling menunggu, sehingga konsistensi basis data dapat terjaga namun pada
implementasi ini masih memiliki kelemahan yaitu tidak adanya peringatan pada
user apabila transaksi-transaksi saling bertabrakan dan terjadi kegagalan proses
sehingga memerlukan pengulangan eksekusi terhadap transaksi tersebut.
ABSTRACT
Every addition and reduction of data stock from material table in system
database inventory Raw Material at Unit Komponen Logam has owned by PT.
Mega Andalan Kalasan often happen inconsistency data because of the data used
by lot of users at the same time.
For the reason needed transaction management technology to manage
transaction, so that transaction goes on can be executed better. This technology is
implemented by SQL programming language in DBMS SQL Server 2000.
The result is that transaction can wait succesively and awaiting each other,
so that database consistency can awake, but in this implementation still have
weakness that is commemoration inexistence for user. If transaction is collision on
each other and happened failure of process and needing to restart that transaction.
KATA PENGANTAR
Puji dan syukur penulis haturkan kepada Tuhan Yang Maha Kuasa, karena
dengan rahmat-Nya penulis dapat menyelesaikan Laporan Tugas Akhir ini dengan
baik. Penulisan tugas Akhir ini ditujukan untuk memenuhi salah satu syarat
memperoleh gelar Sarjana Teknik Jurusan Teknik Informatika.
Penulis juga mengucapkan banyak terima kasih kepada pihak-pihak yang
telah membantu dalam menyelesaikan penulisan tugas akhir ini baik dalam
memberikan bimbingan, kritik maupun saran antara lain kepada :
1. Ir. Gregorius Heliarko SJ, SS, BST, MA, M.Sc., selaku Dekan Fakultas
Sains dan Teknologi Universitas Sanata Dharma.
2. Ibu Agnes Maria Polina, S.Kom, M.Sc. selaku Ketua Jurusan Teknik
Informatika Universitas Sanata Dharma.
3. Bapak JB. Budi Darmawan, S.T., M.Sc. selaku dosen pembimbing Tugas
Akhir yang telah banyak membantu dan memberikan bimbingan kepada
penulis.
4. Ibu Ridowati Gunawan, Pak Wawan, Pak Yudi, Pak Wisnu Selaku dosen
Penguji TA.
5. Seluruh Dosen Universitas Sanata Dharma, khususnya Dosen Teknik
Informatika, yang telah mengajarkan banyak ilmu kepada penulis.
6. Ibu Natasya (Kepala IT PT MAK), Mas Arief, Mas Santo (Staff IT PT
MAK), terimakasih atas bantuannya selama melakukan penelitian dan
pengambilan data contoh di PT. Mega Andalan Kalasan.
7. Bapak Nur Haryanto,S.T. selaku pembimbing Tugas Akhir di bagian IT
PT Mega Andalan Kalasan..
8. Ibunda penulis atas doa, semangat, dan dukungan selama penulis
mengerjakan Laporan Tugas Akhir.
9. Gwendy yang telah memberikan semangat kepada penulis untuk
menyelesaikan Laporan Tugas Akhir ini.
10.Adeku Dwi yang telah memberikan dukungan dan dorongan serta
semangat untuk menyelesaikan Tugas Akhir ini.
11.Sahabat-sahabat yang telah banyak membantu, Yudho, Anahoy, Che, Tere,
Nur, Dian terima kasih atas semuanya.
12.Rekan- Rekan dari Dria Manunggal, terimakasih atas pinjaman Internet
gratisnya.
13.Rekan-rekan Teknik Informatika, khususnya angkatan 2002 yang selama
ini membantu, mendukung dan mendorong penulis untuk menyelesaikan
laporan tugas akhir ini.
14.Teman-teman kos Caritas, ad’ Dwi Moon, ad’ Siska Cemplux, Kak Enink,
Monic, Siska Doraemon, Fanny, Angga, Siska Klaten, Putri, Vuri,
Anggun, Kak Desi, Mbak Diah, Viche, Kak Susan, Kak Ina terima kasih
atas dukungan dan persahabatan kalian.
15.Pihak-pihak lain yang tidak dapat penulis sebutkan satu per satu yang telah
banyak membantu penulis dalam menyelesaikan laporan tugas akhir ini.
Akhir kata, penulis berharap semua pihak dapat memberikan kritik dan
saran yang membangun di masa mendatang. Semoga laporan tugas akhir yang
sederhana dan jauh dari sempurna ini dapat memberi manfaat bagi semua pihak
yang membutuhkan.
Yogyakarta, September 2007
Penulis
DAFTAR ISI
HALAMAN JUDUL ………. ii
HALAMAN PERSETUJUAN ……….. iii
HALAMAN PENGESAHAN ……….. iv
HALAMAN PERNYATAAN KEASLIAN KARYA ……….. v
HALAMAN PERSEMBAHAN ……… vi
4.6 Kekurangan Sistem ……….. 63
BAB V PENUTUP ……….. 64
5. 1 Kesimpulan ……….… 64
5.2 Saran ………..…. 64
DAFTAR PUSTAKA ……….… 65
DAFTAR GAMBAR
Gambar 2.1 Diagram transisi keadaan sebuah transaksi ………... 11
Gambar 3.1 Use Case Diagram ……….. 35
Gambar 3.2 Context Diagram ………. 36
Gambar 3.3 Diagram Berjenjang ... 37
Gambar 3.4 Diagram Berjenjang lanjutan …..……… 38
Gambar 3.5 Diagram Berjenjang lanjutan …..……… 39
Gambar 3.6 Overview Diagram Level 0 ………….……….. 40
Gambar 3.7 Overview Diagram Level 1 Proses 3 ….……… 41
Gambar 3.8 Overview Diagram Level 1 Proses 4 ……… 41
Gambar 3.9 Overview Diagram Level 1 Proses 5 ………. 42
Gambar 3.10 Overview Diagram Level 1 Proses 6 ………. 43
Gambar 3.11 Overview Diagram Level 1 Proses 7 ………. 43
Gambar 3.12 Overview Diagram Level 1 Proses 8 ……….……... 44
Gambar 3.13 Overview Diagram Level 1 Proses 9 ……….... 44
Gambar 3.14 Overview Diagram Level 1 Proses 10 ……….. 45
Gambar 3.15 Entity Relationship Diagram ……… 46
Gambar 3.16 Logical Database Design ………..……… 47
Gambar 4.1 Store Procedure Pemakaian Material ... 54
Gambar 4.1 Store Procedure Penerimaan Material……… 57
Gambar 4.3 Perintah Delay Untuk Memberi Jeda Waktu ……… 59
Gambar 4.4 Perintah Eksekusi Store Procedure Pemakaian Material ……….. 60
Gambar 4.5 Contoh Transaksi Berhasil Dilaksanakan …….. ……….. 61
Gambar 4.6 Data Material Yang Stoknya Telah Berubah ...…….……… 61
Gambar 4.7 Contoh Transaksi Yang Digagalkan ...………….………... 62
Gambar 4.8 Data Stock Material Yang Hanya Diubah Oleh Transaksi
Pemakaian Material …....……... 63
DAFTAR TABEL
Tabel 2.1 Tabel Contoh Masalah Hilangnya Data ………. 14
Tabel 2.2 Tabel Contoh Transaksi Yang Belum Dilaksanakan ... 16
Tabel 2.3 Tabel Contoh Analisis Yang Tidak Konsisten ... 18
Tabel 3.1 Tabel Material ……..……… 48
Tabel 3.2 Tabel Group Head ……..………. 48
Tabel 3.3 Tabel Gudang .……… 49
Tabel 3.4 Tabel Vendor ……….……… 49
Tabel 3.5 Tabel Penerimaan ...……….……… 50
Tabel 3.6 Tabel Detail Penerimaan Material ..……… 50
Tabel 3.7 Tabel Pemakaian Material ………. 51
Tabel 3.8 Tabel NTAG Out ...………..……….. 52
Tabel 3.9 Tabel NTAG In ....……… 52
Tabel 3.10 Tabel NTAG In .……… 52
BAB I
PENDAHULUAN
1.1Latar Belakang Masalah
Dunia teknologi informasi berkembang dengan pesat, dimana
perkembangan teknologi informasi ini sesuai dengan kebutuhan akan
pemecahan permasalahan mengenai berbagai kendala yang dihadapi dalam
sebuah perusahaan. Permasalahan-permasalahan yang dihadapi misalnya tidak
konsistennya database, kehilangan data saat data tersebut diubah yang
mengakibatkan informasi yang diberikan menjadi tidak sesuai.
Dengan adanya teknologi sistem informasi serta manajemen basis data
yang baik diharapkan permasalahan-permasalahan tersebut dapat diselesaikan
dengan baik sehingga menghasilkan informasi yang tepat, cepat dan akurat.
PT Mega Andalan Kalasan merupakan sebuah perusahaan yang bergerak
dalam bidang produksi peralatan rumah sakit. Di dalam usahanya untuk
memenuhi kebutuhan produksi, perusahaan ini memerlukan sistem informasi
inventory yang baik dan handal terutama pada unit komponen logam untuk
database sistem inventoryraw material. Namun yang terjadi pada unit tersebut
adalah beberapa informasi yang dibutuhkan oleh pengguna sering tidak akurat
sehingga menghambat kinerja pengguna. Oleh karenanya diterapkan
Transaction Management pada database sistem inventory untuk mengatasi permasalahan tersebut, sehingga database tersebut dapat mempertahankan
kosistensinya, yang diharapkan mampu memberikan informasi yang sesuai
kepada pengguna.
1.2Rumusan masalah
Dari latar belakang masalah di atas maka dapat dirumuskan sebagai
berikut:
Bagaimana menerapkan transaction management pada database sistem
inventory dengan data contoh yang diambil dari Gudang Raw Material Komponen Logam PT. Mega Andalan Kalasan.
1.3Batasan Masalah
Dalam mengimplementasikan sistem inventory ini terdapat berbagai
batasan sebagai berikut :
1. Data contoh yang diambil adalah data dari sistem inventory gudang
Raw Material unit Komponen Logam yang dimiliki oleh PT. Mega
Andalan Kalasan.
2. Tidak membahas mengenai Sistem Informasi dan hanya berfokus
pada penerapan Transaction Management dengan menggunakan
Store procedure.
3. Tidak membahas mengenai keamanan jaringan.
4. Implementasi sistem ini menggunakan bahasa pemrograman SQL
pada mesin DBMS SQL Server.2000.
1.4Tujuan Penelitian
Adapun tujuan dari penulisan tugas akhir ini adalah untuk menerapkan
Transaction Management pada database sistem inventory dengan
menggunakan store procedure. Sehingga dapat membantu staf gudang Raw
Material unit Komponen Logam di PT Mega Andalan Kalasan dalam
mengatasi permasalahan hilangnya data yang diubah dan untuk menjaga
konsistensi basis data pada sistem inventory, dengan menggunakan bahasa
pemrograman SQL dalam database SQL Server 2000.
1.5Manfaat Penelitian
Manfaat penelitian yang dilakukan adalah untuk menerapkan prinsip
Transaction Management pada database sistem inventory. Sehingga dapat membantu staf gudang Raw Material unit Komponen Logam di PT Mega
Andalan Kalasan dalam mengatasi permasalahan hilangnya data yang diubah
dan untuk menjaga konsistensi basis data pada sistem inventory.
1.6Metodologi Penelitian
Metode pengumpulan data untuk mengembangkan sistem inventory pada
Tugas Akhir adalah metodologi terstruktur (Whitten, J.L., Bentley, L.D.,
Alat dan teknik yang digunakan dalam penelitian ini adalah :
1. Studi Literatur
Mempelajari bahan-bahan tertulis baik berupa buku ataupun makalah
yang berkaitan dengan prinsip Transaction Management pada
database dan bahasa pemrograman SQL pada DBMS SQL Server
2000yang akan digunakan dalam mengembangkan sistem.
2. Wawancara
Teknik pengumpulan data yang dilakukan dengan cara tanya jawab
dan bertatap muka langsung dengan nara sumber yaitu dalam hal ini
adalah staf unit IT pada PT. Mega Andalan Kalasan untuk
mendapatkan informasi mengenai Sistem informasi inventori Raw
Material unit Komponen Logam yang dimiliki oleh PT. Mega Andalan
Kalasan.
3. Survei dan pengambilan data contoh di PT. Mega Andalan Kalasan
Melakukan survei dan pengambilan data contoh pada unit Komponen
Logam dengan data contoh adalah data gudang Raw Material yang
dimiliki oleh PT. Mega Andalan Kalasan.
4. Analisa dan perancangan sistem
Analisa dan perancangan system yang digunakan adalah metode
terstruktur menurut Jeffrey L.Whitten antara lain :
1. Pemodelan persyaratan sistem menggunakan use case diagram
Diagram ini menggambarkan interaksi antara sistem dengan sistem
eksternal dan pengguna.
2. Pemodelan proses
Pemodelan proses meliputi pembuatan diagram konteks, diagram
dekomposisi, overview diagram.
3. Pemodelan data
Pemodelan database dengan menggunakan Entity Relationship
diagram
4. Desain menu pengguna sistem
Desain menu pengguna sistem meliputi desain masukkan dan
keluaran dari sistem yang akan dibuat.
5. Analisis dan evaluasi program
1.7Sistematika Penulisan Bab I. Pendahuluan
Pada bab ini akan menjelaskan mengenai latar belakang masalah,rumusan
masalah, batasan masalah, tujuan penelitian, metodologi penelitian, dan
sistematika penulisan
Bab II. Landasan Teori
Dalam bab ini akan menjelaskan dasar teori mengenai konsep sistem
informasi dan transaction management pada database yang akan menjadi
acuan bagi penulisan skripsi.
Bab III. Analisa dan Perancangan Sistem
Pada bab ini berisi pembahasan, analisa sistem, dan perancangan desain
Bab IV. Implementasi Sistem dan Analisa Hasil
Pada bab ini berisi mengenai implementasi dan analisa hasil dari
penerapan Transaction management pada database sistem inventory.
Bab VI. Kesimpulan dan Saran
Pada bab ini menjelaskan tentang kesimpulan yang diambil dari penulisan
tugas akhir ini serta saran yang diberikan
BAB II
LANDASAN TEORI
2.1 Sistem, Informasi, dan Sistem Informasi 2.1.1 Sistem
Sistem adalah kumpulan dari elemen-elemen yang berinteraksi untuk
mencapai suatu tujuan tertentu (Jogiyanto, 1999). Definisi tersebut lebih
dapat diterima, karena pada kenyataannya suatu sistem terdiri dari
beberapa elemen atau subsistem. Elemen-elemen tersebut tidak dapat
berdiri sendiri-sendiri dalam suatu sistem tetapi harus saling berinteraksi
dan saling berhubungan untuk membentuk satu kesatuan sehingga tujuan
sistem dapat tercapai. Maka suatu sistem harus mempunyai tujuan tertentu
agar elemen masukan, elemen pengolah dan elemen keluaran dapat
ditentukan dengan tepat.
2.1.2 Informasi
Informasi adalah data yang diolah menjadi bentuk yang lebih berguna
dan lebih berarti bagi yang menerimanya ( Jogiyanto, 1999). Informasi
sangat penting dalam suatu organisasi. Suatu sistem yang kurang
mendapatkan informasi akan menjadi kecil dan akhirnya akan habis.
Informasi-informasi yang diperoleh dari suatu sistem dapat digunakan
dalam pengambilan sebuah keputusan serta dalam melakukan tindakan
selanjutnya, sehingga dibutuhkan informasi yang akurat, tepat pada
waktunya dan bermanfaat bagi penggunanya. Selain itu informasi harus
memiliki nilai informasi yang dapat ditentukan oleh dua hal yaitu manfaat
dan biaya mendapatkannya. Suatu informasi dikatakan bernilai jika
manfaatnya lebih efektif dibandingkan dengan biaya untuk mendapatkan
informasi tersebut. Suatu informasi yang diperoleh mungkin memiliki
beberapa kegunaaan sehingga digunakan tidak hanya oleh satu pihak saja
di dalam suatu organisasi melainkan digunakan bersama-sama.
2.1.3 Sistem Informasi
Sistem informasi adalah suatu sistem di dalam suatu organisasi yang
mempertemukan kebutuhan pengolahan transaksi harian, mendukung
operasi, bersifat manajerial dan kegiatan strategi dari suatu organisasi dan
menyediakan pihak luar tertentu dengan laporan-laporan yang diperlukan
(Robert A. Leitch dan K. Roscoe Davis, 1993).
2.2 Basis Data
Basis data atau database adalah kumpulan data yang diatur dan
diorganisasikan dalam suatu cara yang sistematis, untuk mengurangi
duplikasi data dan memberikan fasilitas pada sejumlah pengguna pada
beberapa aplikasi. Sedangkan DBMS (Database Management System)
adalah suatu cara yang paling efisien untuk mengelola atau memproses
database.
data yang saling berelasi dan set program untuk mengakses (mengambil,
mengubah, menambah) data tersebut
2.3 Transaction Management
Transaction Management pada basis data memiliki fungsi agar basis data dapat diandalkan atau dipercaya. Yang termasuk di dalamnya adalah
transaction support, concurrency control, dan database recovery.
Transaction support adalah jaminan yang diberikan oleh DBMS supaya
empat sifat penting dari transaksi yaitu atomicity, consistency, isolation,
dan durability dalam mempertahankan data saat menghadapai akses yang konkuren dan kegagalan sistem dapat dipertahankan.
2.3. 1 Transaction Support
Transaksi adalah sebuah tindakan atau serangkaian tindakan yang
dilakukan oleh pengguna tunggal atau program aplikasi yang membaca
atau mengubah isi dari basis data (Connoly, T., Begg, C., 2005).
Transaksi adalah suatu unit kerja logis pada basis data yang dapat
berupa satu program utuh, sebagian dari program atau suatu perintah
tunggal seperti perintah INSERT atau UPDATE dalam perintah SQL.
Sebuah transaksi sebaiknya selalu mentransformasikan basis data dari satu
keadaaan konsisten ke keadaan konsisten yang lain, meskipun konsistensi
Sebuah transaksi dapat mempunyai satu atau dua hasil, jika sukses
seluruhnya, transaksi dapat dikatakan telah dilakukan (commited) dan
database mencapai suatu keadaan konsisten yang baru, Sebaliknya jika
gagal, transaksi akan dibatalkan. Jika transaksi dibatalkan, maka basis data
harus dikembalikan ke keadaan konsisten seperti sebelum transaksi
tersebut dimulai. Transaksi tersebut disebut rolled back atau undone.
Sebuah transaksi yang telah dilakukan (commited transaction) tidak
dapat dibatalkan. Jika diputuskan transaksi yang telah dilakukan memiliki
suatu kesalahan maka harus dilakukan transaksi pengganti (compensating
transaction) untuk mengembalikan pengaruhnya.
Pernyataan BEGIN TRANSACTION, COMMIT dan ROLLBACK
adalah pernyataan dari Data Manipulation Language (DML) yang memiki
fungsi untuk membatasi transaksi-transaksi. Jika pernyataan tersebut tidak
digunakan maka transaksi dianggap sebagai transaksi tunggal (single
transaction) dimana dianggap COMMIT saat program selesai dijalankan
dengan benar, dan ROLLBACK jika gagal.
Diagram transisi keadaan sebuah transaksi dapat dilihat seperti berikut :
Gambar 2.1 Diagram transisi keadaan sebuah transaksi
Ada lima keadaan di dalam transaksi antara lain :
1. ACTIVE (aktif).
2. PARTIALLY COMMITED (sebagian dilaksanakan) kondisi ini terjadi setelah statement terakhir dieksekusi. Pada saat ini ada kemungkinan
ditemukan bahwa transaksi melanggar serializability atau melanggar
integrity constraint, maka transaksi harus dibatalkan, dengan demikian
transaksi tersebut akan menuju keadaan gagal (failed state) dan harus
dibatalkan. Jika transaksi sukses, maka beberapa perubahan ( update)
dapat disimpan secara aman dan transaksi menuju ke keadaan
COMMITED.
3. COMMITED (dilaksanakan).
4. FAILED (gagal) keadaan ini terjadi jika transaksi tidak dapat
dilaksanakan atau transaksi dibatalkan pada saat keadaan aktif (active
state), hal ini disebabkan karena pembatalan transaksi oleh user atau
concurency control protocol membatalkan transaksi untuk memastikan
5. ABORTED (dibatalkan).
Ada empat hal yang harus dimiliki semua transaksi, yang disebut sifat
ACID yaitu :
1. Atomicity yaitu sebuah transaksi adalah suatu unit yang tidak dapat dibagi, yaitu dilakukan secara menyeluruh atau tidak sama sekali. Hal
ini dijamin oleh DBMS pada sub sistem recovery.
2. Consistency yaitu sebuah transaksi harus mengubah basis data dari
satu keadaan konsisten (consistent state) ke keadaan konsisten lain.
Consistency menjadi tanggung jawab bersama antara DBMS dan
pengembang program aplikasi.
3. Isolation adalah keadaan dimana transaksi-transaksi melakukan eksekusi secara bebas atau tidak tergantung satu sama lain. Sehingga
apabila ada efek yang timbul dari sebuah transaksi yang belum selesai
sebaiknya tidak perlu diketahui transaksi lain.
4. Durability adalah hasil dari suatu transaksi yang sukses dicatat secara permanen dalam basis data dan tidak boleh hilang oleh suatu kesalahan
apapun.
2.3.2 Concurrency Control
Concurrency control adalah proses pengelolaan operasi-operasi yang berjalan bersama pada database tanpa mengganggu satu sama lain
(Connoly, T., Begg, C., 2005) . Tujuan dari concurrency control adalah
untuk menjadualkan transaksi sedemikian rupa dalam suatu cara sehingga
menghindari gangguan satu sama lain. Hal ini dibutuhkan karena dalam
transaksi mungkin terjadi masalah-masalah seperti masalah hilangnya data
yang diubah, masalah pembacaan yang salah dan masalah analisa yang
tidak konsisten.
a. Masalah hilangnya data yang diubah (the lost update problem)
Masalah hilangnya data yang diubah atau the lost update problem
adalah suatu operasi update yang sukses oleh seorang user dan dapat
dikesampingkan oleh user yang lain. Contohnya dapat dilihat pada
tabel 2.1 contoh masalah hilangnya data
Waktu T1 T2 balx
t1 Begin transaction 100
t2 Begin transaction Read (balx) 100
t3 Read (balx) balx = balx + 100 100
t4 balx = balx -10 Write (balx) 200
t5 Write (balx) commit 90
t6 commit 90
t1 : transaksi T2 dimulai
t2 : transaksi t1 dimulai, pada saat yang hampir bersamaan T2
membaca balance yang isinya adalah £100.
t3 : transaksi T1 membaca balance yang berisi £100. Pada saat
yang hampir bersamaan T2 menambah balance dengan £100
dan menyimpannya dalam balx, sehingga balx menjadi £200,
namun karena T2 belum memberikan perintah write balx, maka
T2 masih mengenal balx sebesar £ 100.
t4 : transaksi T1 mengurangi balance sebesar £10 dan
menyimpannya dalam balx , sehingga balx menjadi £90. Pada
saat yang hampir bersamaan T2 melaksanakan instruksi write
balx, sehingga balx sekarang berisi £200
t5 : transaksi T1 melaksanakan instruksi write balx yang berisi £90.
Pada saat yang bersamaan T2 menyatakan transaksinya commit
atau telah dilakukan, jadi nilai balx yang commit adalah £90.
t6 : transaksi T1 menyatakan transaksinya commit atau telah
dilakukan, jadi nilai balx yang telah commit adalah£90.
Dari contoh tersebut tampak bahwa nasabah menderita kerugian
£100. Untuk itu diperlukan solusi untuk mencegah hilangnya
perubahan data dengan melarang transaksi T1 membaca nilai balx,
sampai transaksi T2 selesai melakukan perubahan data.
b. Masalah transaksi yang belum dilaksanakan (the uncommitted
dependency problem) atau masalah pembacaan yang salah (the dirty read problem)
Permasalahan ini terjadi jika saat suatu transaksi diijinkan membaca
hasil suatu transaksi lain sebelum transaksi lain tersebut selesai
tabel 2.2 contoh masalah transaksi yang belum dilaksanakan
Waktu T3 T4 balx
t1 Begin transaction 100
t2 Read (balx) 100
t2 : transaksi T4 membaca balance yang isinya adalah £100.
t3 : transaksi T4 menambah balance dengan £100.
t4 : transaksi T3 baru dimulai. Transaksi T4 menyimpan hasil
perhitungan tadi sehingga balx menjadi £200.
t5 : transaksi T3 membaca balx yang bernilai £200. Transaksi T4
tidak melakukan proses apapun.
t6 : transaksi T3 melakukan pengurangan terhadap balx yang
diketahuinya bernilai £200 dengan £10. Pada saat yang sama
transaksi T4 membatalkan perubahan yang terakhir dilakukannya
yaitu mengubah balx yang berisi £100 menjadi £200 sekaligus
mengakhiri prosesnya, sehingga balx berisi £100 lagi tanpa
diketahui transaksi T3.
t7 : melalui instruksi write balx , transaksi T3 menyimpan hasil
pengurangan pada balx tadi sehingga balx berisi £190.
t8 : T3 menyatakan transaksinya commit.
Dari contoh tersebut tampak bahwa nilai balx yang dibaca transaksi
T3 adalah salah (£190) seharusnya £90. Nilai balx yang salah
tersebut disebut dirty data. T3 membaca nilai yang belum selesai
diproses oleh T4 oleh karenanya terjadi kesalahan pembacaan. Untuk
mengatasinya maka T3 dicegah untuk tidak membaca nilai balx
sampai didapatkan hasil yang pasti dari T4 baik karena commit
ataupun abort.
c. Masalah analisis yang tidak konsisten (the inconsistent analysis
problem)
Problem ini terjadi ketika transaksi pertama membaca beberapa
nilai dari basis data tetapi transaksi kedua mengubah nilai-nilai
tersebut selama proses transaksi pertama belum selesai. Contohnya
dapat dilihat pada tabel 2.3.
tabel 2.3 contoh analisis yang tidak konsisten
t3 : Transaksi membaca nilai balx yang berisi £100, demikian pula
transaksi T6 juga membaca nilai balx yang berisi £100.
t4 : Tansaksi T5 mengurangi balx dengan nilai £10, sedangkan
transaksi T6 melakukan penjumlahan variabel sum dengan nilai
balx , dimana balx yang dikenalnya beisi £100, padahal balx
seharusnya bernilai £90.
t5 : Transaksi T5 menyimpan hasil perhitungan balx yang berisi
£90. Transaksi T6 membaca baly yang berisi £50. Pada saat ini
nilai balx yang diketahui transaksi T5 dan T6 sudah berbeda,
T5 mengetahui nilai balx= £90 sedangkan T6 mengetahui nilai
balx = £100. Sedangkan variabel sum seharusnya berisi £90
bukan £100
t6 : Transaksi T5 membaca balz berisi £25, sedangkan transaksi T6
menjumlahkan nilai sum sebelumnya yang berisi £100,
(seharusnya yang benar berisi £90) dengan nilai dari baly
sebesar £50 sehingga mendapatkan sum bernilai £150
(seharusnya bernilai £140).
t7 : Transaksi T5 menambahkan balz dengan £10, sedangkan
transaksi T6 tidak melakukan apapun.
t8 : Transaksi T5 menyimpan hasil perhitungan sebelumnya yaitu
balz = £35, dan transaksi T6 tidak melakukan apapun.
t9 : Transaksi T5 selesai ditandai dengan commit. Transaksi T6
membaca balz yang sudah ditambah £10 oleh transaksi T5
sehingga balz = 35.
t10 : Transaksi T6 menjumlahkan variabel sum dengan nilai dari
balz sehingga nilai sum menjadi 185.
t11 : Transaksi T6 menuliskan data sum sehingga data sum
menjadi 185.
t12 : Transaksi T6 selesai ditandai dengan commit.
Pada saat T4, transaksi T5 mengurangi balx dengan nilai £10 jadi
transaksi T6 melakukan penjumlahan variabel sum dengan nilai balx
pada saat t4 maka nilai balx yang dikenalnya masih berisi £100. Jadi
sehurusnya proses (read balx) dilakukan setelah transaksi T5
menyelesaikan perubahannya. Sehingga transaksi T6 juga mengalami
kekeliruan pada saat t6 karena nilai sum saat itu diketahui bernilai
£100 akibat dari transaksi T6 pada saat t4. Untuk menghindarinya
transaksi T6 dicegah untuk membaca balx sampai t9 saat transaksi T5
telah menyelesaikan perubahannya.
2.3.2.1Serializability dan Recoverability
Serializability merupakan suatu cara untuk memaksimalkan
concurrency dalam sIstem, sehingga DBMS multi-user dapat memproses
transaksi secara bersama-sama tanpa gangguan. Serializability memiliki
tujuan untuk mendapatkan nonserial schedule yang mengijinkan
transaksi-transaksi mengeksekusi secara bersama-sama tanpa gangguan satu sama
lain sehingga akan menghasilkan basis data yang sama hasilnya seperti
jika diproses secara serial. Dalam serializability urutan operasi baca dan
tulis menjadi penting karena :
1. Jika dua transaksi hanya baca data saja, maka mereka tidak
akan menimbulkan konfik, dan urutan menjadi tidak penting.
2. Jika dua transaksi mempunyai baik baca maupun tulis pada
data yang berbeda, keduanya tidak akan menimbulkan konflik
dan urutan menjadi hal yang tidak penting.
3. Jika suatu transaksi melakukan tulis data dan transaksi lain
melakukan baca data atau tulis data pada saat yang sama, maka
urutan eksekusi menjadi penting.
Serializability identik dengan penjadwalan yang memelihara kekonsistenan basis data, dengan mengasumsikan bahwa tak ada transaksi-
transaksi dalam penjadwalan tersebut yang gagal. Sehingga diperlukan
recoverability transaksi-transaksi dalam sutu penjadwalan, jika suatu transaksi gagal, dibutuhkan untuk dapat mengembalikan pengaruh
transaksi ke keadaan semula.
Recoverable schedule adalah suatu penjadwalan dimana untuk setiap pasang transaksi Ti dan Tj., jika Tj membaca sebuah item data yang
sebelumnya ditulis oleh Ti, maka operasi commit dari Ti yang telah
dilaksanakan diperlukan sebelum operasi commit dari Tj.
2.3.2.2Metode Penguncian (Locking Methods)
Penguncian atau locking adalah suatu prosedur yang digunakan
untuk mengendalikan akses yang bersamaan pada suatu data. Saat sebuah
transaksi sedang mengakses database, suatu kunci atau lock boleh
menolak akses dari transaksi lain untuk mencegah hasil yang tidak benar.
Locking mempunya sifat dasar yaitu sebuah transaksi harus dinyatakan
sebagai shared untuk proses baca (read) dan sepenuhnya terkunci
melakukan lock bersama secara serentak pada saat yang sama. Sedangkan
exclusive lock tidak memperbolehkan transaksi-transaksi yang lain dapat membaca atau mengubah item data apabila sebuah transaksi sedang
melakukan exclusive lock.
2.3.2.3Deadlock
Deadlock adalah suatu jalan buntu yang disebabkan oleh dua atau lebih transaksi yang mana masing-masing transaksi sama-sama menunggu
locks dilepaskan oleh transaksi lain yang sedang menggunakannya. Jika
sekali deadlock terjadi, transaksi-transaksi yang terlibat tak dapat
menyelesaikan problemnya, oleh karena itu DBMS harus mengenali
deadlock yang terjadi dan mematahkannya. Oleh karenanya DBMS harus membatalkan satu atau lebih transaksi, dalam hal ini termasuk
membatalkan semua perubahan yang telah dilakukan oleh transaksi
dibatalkan.
2.3.2.4Metode Penandaan Waktu (Timestamping)
Timestamp adalah suatu pengenal unik yang dibuat oleh
menunjukkan waktu dimulainya suatu transaksi. Timestamp dapat dibuat
dengan menggunakan sistem clock atau jam pada saat transaksi dimulai,
atau lebih umum dengan cara menaikkan counter waktu setiap saat
transaksi baru dimulai.
Timestamping adalah suatu concurency control protocol yang mengurutkan transaksi-transaksi dalam suatu cara sedemikian rupa yaitu
apabila terjadi konflik maka transaksi yang lebih dulu atau transaksi
dengan timestamp yang lebih kecil akan mendapatkan prioritas.
Dengan timestamping, jika sebuah transaksi mencoba untk
membaca atau menulis suatu data, maka baca atau tulis data tersebut hanya
diijinkan diproses jika perubahan terakhir dari data tersebut telah
dilakukan oleh transaksi sebelumnya. Jika tidak, maka transaksi yang
meminta baca atau tulis tersebut akan diulang dan diberikan timestamp
yang baru untuk mencegah transaksi tersebut diulang terus menerus.
2.3.2.5Granularity Dari Data Item
Granularity adalah ukuran dari data item yang dipilih sebagai unit
proteksi dari protocol concurrency control.
2.3.3 Database Recovery
Database recovery merupakan proses yang mengembalikan kondisi database ke kondisi yang benarpada saat terjadi kegagalan proses.
2.3.3.1Kebutuhan Recovery
Penyimpanan data pada umumnya terdiri dari empat jenis yaitu main
memory, magnetic disk, magnetic tape dan optical disk. Main memory
nonvolatile. Main memory juga sebagai primary storage sedangkan disk
dan tape merupakan secondary memori. Stable storage menggambarkan
informasi yang direplikasi di dalam beberapa nonvolatile media storage
dengan independent failure mode, yang biasanya menggunakan RAID
(Redundant Array of Independent Disk).
Ada banyak tipe failure yang dapat mempengaruhi proses database,
sehingga setiap jenis kegagalan memiliki alasan yang berbeda-beda.
Beberapa diantaranya disebabkan oleh main memory saja, sementara yang
lain termasuk penyimpanan non-volatile (secondary).
Penyebab failure diantaranya seperti berikut :
1. System crash yang disebabkan oleh hardware atau software
yang error, sehingga data di memori utama hilang.
2. Media failure, seperti head yang crash atau media yang tidak dapat dibaca, akibatnya kehilangan data pada bagian dari
penyimpanan secondary.
3. Application Software error, seperti error logika pada program
yang mengakses database, sehingga menyebabkan satu atau
lebih transaksi gagal.
4. Natural physical disaster, seperti kebakaran dan bencana alam.
5. Kerusakan atau kecelakaan yang tidak disengaja pada data atau
fasilitas oleh operator atau user.
6. Sabotase atau korupsi yang disengaja atau kerusakan dari data,
baik hardware atau software.
Apapun penyebab kegagalannya , ada dua efek prinsip yang perlu
diperhatikan, yaitu kehilangan memori utama, termasuk database
buffer dan kehilangan copy disk dari database. Oleh karena banyaknya kemungkinan terjadinya kegagalan pada memori utama maupun pada
disk maka perlu adanya recovery terhadap basis data.
2.3.3.2Transaction and Recovery
Transaksi adalah basic unit untuk recovery dalam system database.
Role dari recovery manager adalah harus menjamin dua dari empat ACID
yaitu atomicity dan durability jika terjadi failure.
Recovery manager harus memastikan bahwa recovery dari kegagalan,
pengaruhnya akan keseluruhan transaksi yang merekam database secara
permanent atau tidak mempengaruhi sama sekali.
2.3.3.3Recovery Facilities
DBMS pada umumnya menyediakan fasilitas untuk recovery antara lain :
1. Mekanisme backup. Mekanisme ini adalah dengan membuat
salinan database atau backup secara periodik.
2. Fasilitas Logging. Mekanismenya adalah dengan membuat catatan
terhadap keadaan tertentu dari transaksi dan perubahan database.
Log file mencatat record-record transaksi yang mengidentifikasi
awal atau akhir dari transaksi baik setelah dan sesudah image dari
database yang terdiri dari data transaction record dan checkpoint record. Transaction record berisi identitas transaksi, tipe data dari
log record, identitas dari data item yang dipengaruhi oleh aksi dari
database, nilai sebelum perubahan atau before- image data item,
nilai setelah perubahan atau after-image dari data item, informasi
management log.
3. A checkpoint facility melakukan update terhadap database
sehingga kemajuannya dibuat permanen.
4. Recovery Manager adalah dengan membuat sistem untuk
kondisi yang konsisten dapat digunakan teknik- teknik seperti berikut ini :
1. Deferred Update atau penundaan update. Mekanismenya adalah
dengan melakukan write hanya pada log saja dan log record
digunakan untuk menentukan apakah transaksi perlu untuk di redo,
tetapi tidak memerlukan undo write lagi.
2. Immediate Update atau segera melakukan update. Mekanismenya
adalah dengan membuat update pada basis datanya setelah log
record ditulis.
Alternatif teknik recovery yang lain adalah dengan menggunakan shadow paging
2.3.3.5Advanced Transaction Models
Advanced transaction models digunakan untuk transaksi yang
menggunakan aplikasi database yang lebih kompleks. Seperti yang
digunakan untuk Computer-Aided-Design, Computer Aided Manufacture
dan Computer Aided Software Engineering.
Yang termasuk dalam advanced transaction models antara lain :
1. Nested Transaction Model
Nested transaction model adalah sebuah transaksi yang dilihat
sebagai kumpulan subtask yang saling berelasi atau subtransaction,
setiap subtask mungkin juga berisi subtransaction. Nested
transaction model memiliki beberapa keuntungan seperti :
modularitas, sangat baiknya level dari granularity dari concurrency
control dan recovery, intra transaction parallelism dan intra transaction recovery.
2. Sagas
Sagas adalah urutan dari (flat) transaksi yang dapat meninggalkan transaksi yang lain.
3. Multilevel transaction
2.4 Pemodelan Data
Pemodelan data adalah sebuah teknik untuk mengorganisasikan dan
mendokumentasikan data dari system (Whitten, J.L., Bentley, L.D.,
Barlow, V.M., 2004). Pada pemodelan data dibagi menjadi tiga tahap yaitu
tahap conceptual design, logical design, physical design.
2.4.1 Conceptual Design
Pada tahap conceptual design ini menggambarkan isi dari basis data
sebelum data diimplementasikan pada sistem informasi yang
sesungguhnya serta tidak mempertimbangkan efisiensi program-program
yang memanfaatkan data tersebut. Pada tahap ini menghasilkan conceptual
schema yang mengacu pada suatu conceptual model yaitu Entity Relationship Model.
2.4.2 Logical Design
Pada tahap logical design ini dilakukan penterjemahan dari conceptual
schema ke model data yang sesuai dengan DBMS yang akan digunakan. Pada tahap ini menghasilkan logical schema basis data yang mengacu pada
suatu logical data model yaitu Relational Model.
Terdapat dua langkah utama dalam logical design yaitu :
1. Restrukturisasi ER Diagram
Pada restrukturisasi ER Diagram ini melakukan beberapa
tahapan yaitu analisa redundansi, menghilangkan generalisasi,
memecah atau menyatukan entitas-entitas dan relasi-relasi serta
menetapkan kata kunci atau primary key
2. Mengubah dari ER Diagram ke Relational model.
2.4.3 Physical Design
Pada tahap physical design ini logical schema dilengkapi dengan
detail-detail implementasi secara fisik sesuai dengan DBMS yang
digunakan.
2.5 Pemodelan Proses
Pemodelan proses adalah sebuah teknik yang digunakan untuk
mengelola dan mendokumentasikan proses sistem. Salah satu model
proses yang digunakan adalah DFD atau Data Flow Diagram. Data flow
Diagram merupakan model proses yang digunakan untuk menggambarkan aliran data melalui sebuah sistem dan tugas atau pengolahan yang
dilakukan oleh sistem. Data flow diagram menggambarkan penyimpanan
data dan proses yang mentransformasikan data yang menunjukkan
2.6 SQL Server 2000
SQL Server adalah satu produk DBMS yang dibuat oleh Microsoft
yang memiliki keunggulan-keunggulan dalam pengelolaan database. SQL
adalah sebuah databasae relasional yang dirancang untuk mendukung
aplikasi dengan arsitektur client/server, dimana database terdapat pada
komputer pusat yang disebut server, dan informasi digunakan
bersama-sama oleh beberapa pengguna yang menjalankan aplikasi di dalam
komputer lokalnya yang disebut client (Ramalho, José, 2001).
2.6.1 Trigger
Trigger adalah prosedur tersimpan yang secara otomatis dijalankan
apabila data di dalam tabel berubah karena eksekusi perintah SQL
INSERT, UPDATE, atau DELETE (Ramalho, José, 2001). Salah satu dari penggunaannya yang paling umum adalah untuk menerapkan pembatasan
yang lebih kompleks dari yang telah diijinkan melalui pembatasan cek,
2.6.2 Store Procedure
Store procedure merupakan sekumpulan perintah-perintah SQL yang tersimpan dengan nama tertentu dan diproses sebagai sebuah kesatuan
(Arief, M Rudyanto,2006)
2.6.3 Isolation Level
Isolation level mengontrol tingkat dimana transaksi tertentu terbuka terhadap tindakan transaksi lain yang melakukan eksekusi secara konkuren
(Ramakrishnan, R., Gehrke, J.,2003 ). Dengan memilih satu dari empat
kemungkinan pengaturan level isolasi, pengguna dapat memperoleh
konkurensi lebih besar yang mengakibatkan peningkatan paparan transaksi
pada perubahan uncommited transaksi lain. Pilihan level isolasinya
diantaranya Serializable, Repeatable Read,Read Commited,Read
Uncommited
Serializable merupakan tingkat isolasi tertinggi karena level isolasi ini menjamin bahwa transaksi hanya membaca perubahan yang dibuat oleh
transaksi yang telah commit. Serta menempatkan lock pada kelompok data
, mencegah pengguna lain untuk meng-update atau menambah data sampai
transaksi selesai. Serializable memiliki pengaturan yang sama dengan
pengaturan HOLDLOCK pada semua tabel dalam semua pernyataan
SELECT dalam sebuah transaksi.
Repeatable Read menempatkan lock pada semua kumpulan data yang
kolom phantom yang baru dapat dimasukkan ke dalam kumpulan data oleh user yang lain dan termasuk pembacaan yang berikutnya pada transaksi
yang berlangsung.
Read Uncommitted merupakan level isolasi yang
mengimplementasikan pembacaan kotor (dirty read) atau penguncian level
isolasinya adalah nol, dimana tidak memperoleh share lock sebelum
membaca objek. Dan tidak ada exclusive lock yang dipertahankan. Jika
opsi ini digunakan, ada kemungkinan untuk membaca transaksi yang
belum commit atau data yang kotor (dirty data), nilai-nilai yang terdapat
dalam data dapat diubah dan baris-baris dapat kelihatan atau hilang di
dalam kumpulan data sebelum transaksi berakhir. Opsi ini memiliki efek
yang sama dengan pengaturan NOLOCK pada semua tabel dalam semua
pernyataan SELECT dalam sebuah transaksi.
Read COMMITTED secara spesifik share lock ditahan ketika data
sedang dibaca untuk mencegah pembacaan yang salah (dirty read), tetapi
data dapat diubah sebelum transaksi berakhir, hasilnya dalam data yang
nonrepeatable reads atau phantom. Opsi ini merupakan opsi default dalam SQL Server.
BAB III
ANALISIS DAN PERANCANGAN SISTEM
3.1 Analisis Sistem
3.1.1 Gambaran Umum Sistem Yang Akan Dibuat
Sistem yang diusulkan adalah suatu sistem informasi berbasis client
server seperti yang sudah dimiliki oleh PT Mega AndalanKalasan yang
dapat mendukung kegiatan pencatatan pemasukkan dan pengeluaran
material pada gudang unit Raw Material Komponen Logam di PT Mega
Andalan Kalasan.
Sistem Informasi ini dibuat supaya operator gudang dapat
memasukkan data transaksi material dengan lebih detail dan lebih cepat.
Selain itu Kepala Unit dapat melihat langsung data stok material melalui
laporan- laporan yang telah disediakan.
Sistem informasi ini diharapkan dapat mengatasi permasalahan yang
dihadapi oleh PT Mega Andalan kalasan mengenai kehilangan data,
karena pada sistem ini diterapkan transaction management untuk menjaga
kondisi basis data tetap konsisten. Selain itu sistem yang baru ini
melakukan pemrosesan data langsung pada sistem basis data yang terdapat
pada komputer server dengan menggunakan metode store procedure.
Tujuannya adalah agar mempercepat jalannya proses perhitungan pada
aplikasi dan untuk menjalankan perintah-perintah yang mendukung
transaction management sehingga diperoleh hasil basis data yang tetap
konsisten sehingga data yang dihasilkan dapat dipercaya. Sistem ini juga
dilengkapi dengan peringatan-peringatan jika terjadi kegagalan pada saat
pemprosesan data.
Pada sistem inventori raw material KL ini menerapkan pula isolation
level Serializable yang diharapkan data lebih konsisten karena data hanya
dapat diubah oleh user yang memiliki exclusive lock. Namun user yang
lain masih dapat membaca data yang sama. Sehingga diharapkan sistem
yang ini dapat mendukung untuk penggunaan multi user.
3.1.2.1 Proses Pengumpulan Kebutuhan
Pihak yang terlibat atau menggunakan system informasi tersebut antara
lain :
1. Admin
2. Operator Gudang
3. Kepala Unit
3.1.2.2 Use Case Diagram
Use case diagram dari system yang baru dapat dilihat pada gambar 4.1
Update Data Group Head
Update Data Detil Gudang
Update Data Vendor
Update Data Material
Pengolahan Data Penerimaan Material
Pengolahan Data Pemakaian Material
Laporan Login Admin
Operator Gudang
Ubah Password
Kepala Unit
LogOut
3.1.2.3 Pemodelan Proses (Data Flow Diagram) Context Diagram
Gambar 3.2 Context diagram
Gambar 3.3 Diagram berjenjang
Diagram berjenjang
(Decomposition Diagram)
Lanjutan
Gambar 3.4 Diagram berjenjang lanjutan
Diagram berjenjang
(Decomposition Diagram)
Lanjutan
Gambar 3.5 Diagram berjenjang lanjutan
Overview Diagram Level 0 D8 Data Penerimaan Material
Data material
Data penerimaan material, sisa stok
Data NTAG Out,sisa stok
Data pemakaian material, sisa stok Validasi login
Data penerimaan material, data pemakaian material,sisa stock
Laporan pemakaian material, laporan penerimaan material, laporan stock Material
Data Penerimaan
material
Gambar 3.6 Overview diagram level 0
Overview Diagram Level 1 Proses 3
Data Group Head Data Group Head
Kode Group Head
Gambar 3.7 Overview diagram level 1 proses 3
Overview Diagram Level 1 Proses 4
Overview Diagram Level 1 Proses 5
Gambar 3.9 Overview diagram level 1 proses 5
Overview Diagram Level 1 Proses 6
Gambar 3.10 Overview diagram level 1 proses 6
Overview Diagram Level 1 Proses 7
Overview Diagram Level 1 Proses 8
Gambar 3.12 Overview diagram level 1 proses 8
Overview Diagram Level 1 Proses 9
Gambar 3.13 Overview diagram level 1 proses 9
Overview Diagram Level 1 Proses 10
3.1.2.4 Pemodelan Data (Conceptual Database Design) Entity Relationship Diagram (ERD)
Gambar 3.15 Entity Relationship Diagram
3.2
Perancangan Sistem
3.2.1
Desain Database
Gambar 3.16 Logical design database
3.2.2 Desain Tabel
Berikut ini merupakan desain tabel yang digunakan :
1. Tabel Material
Primary Key : Kode Material
Secondary Key : GH
Kode Material char 6 Identitas Material
Spesifikasi Varchar 50 Nama Material dalam bahasa
Indonesia
Panjang numeric 9(18,3) Panjang masing-masing
material
Lebar numeric 9(18,3) Lebar masing-masing material
Tebal numeric 9(18,3) Tebal masing-masing material
Diameter Luar
numeric 9(18,3) Diameter luar masing-masing
material Diameter
Dalam
numeric 9(18,3) Diameter dalam
masing-masing material
Stock numeric 9(18,3) Jumlah stok
Stock Min numeric 9(18,3) Jumlah stok minimum
Satuan Varchar 6 Satuan jumlah tiap material
Tanggal Update
Smalldatetime 4 Tanggal sewaktu memasukkan
data
2. Tabel Group Head Primary Key : GH
Tabel 3.2 Group Head
Field
NamaGH Varchar 50 Keterangan tiap identitas group
Head
3. Tabel Gudang
KodeGudang Char 2 Identitas gudang
NamaGudang Varchar 50 Nama gudang tempat penyimpanan
material
4. Tabel Vendor
Primary Key : Kode Vendor
Tabel 3.4 Vendor
Kode Vendor Char 2 Identitas Vendor
NamaVendor Varchar 50 Nama Vendor
Alamat Varchar 150 Alamat Vendor
Telepon Varchar 50 No telepon vendor
Sertifikasi Varchar 50 Sertifikasi vendor
Kontak Varchar 50 Nama kontak yang dapat
5. Tabel Penerimaan Primary Key : Nomor GR
Secondary Key : Kode Vendor
Tabel 3.5 Penerimaan Material
Field Name Data Type Field
Size
Description
NomorGR Varchar 15 Identitas Data Penerimaan
Material
Tgldatang smalldatetime 4 Tanggal sewaktu material
datang
NomorOP varchar 8 Nomor Order Pembelian
KodeVendor Char 2 Identitas Vendor
6. Tabel Detail Penerimaan Material Primary Key : Nomor GR
Tabel 3.6 Detail Penerimaan Material
Field Name Data
Type
Field Size
Description
Nomor GR Int 4 Identitas pemakaian material
Kode Material
Varchar 6 Identitas material
QTY Numeric 9 Jumlah Material yang Datang
Harga money 8 Harga material per satuan
Total Harga Numeric 17 Total Harga Material yang datang
Keterangan Varchar 125 Keterangan mengenai penerimaan
material
7. Tabel Pemakaian Material Primary Key : No_id_pemakaian
Secondary Key : Kode Material, Nomor GR, Kode Vendor
Tabel 3.7 Pemakaian Material
Int 4 Identitas pemakaian material
Nomor GR Varchar 15 Identitas detail pemakaian
material
Tanggal Pakai Smalldatetime 4 Tanggal sewaktu memasukkan
data
Kode Material Varchar 6 Identitas material
Tanggal Datang
Smalldatetime 4 Tanggal sewaktu material
datang
Nomor OP varchar 12 Nomor Order Pembelian
Kode Vendor Varchar 2 Identitas Vendor
PDMM Numeric 9(18,3) Jumlah pemakaian dalam mili
meter
QTY Numeric 9(18,3) Jumlah material yang
dibutuhkan
Total pakai Numeric 9(18,3) Jumlah pemakaian total
Harga Money 8 Harga satuan material yang
dipakai
Keperluan Varchar 50 Keterangan mengenai
8. Tabel NTAG Out
Primary Key : NO NTAG
Secondary Key : No_id_Pemakaian, Gudang Tujuan
Tabel 3.8 NTAG Out
Field Name Data Type Field
Size
Description
Tanggal Smalldatetime 4 Tanggal sewaktu
memasukkan data
No NTAG Varchar 12 Identitas NTAG Out
No_id_Pemakaian varchar 6 Identitas pemakaian
material
Gudang Tujuan Char 2 Identitas Gudang
9. Tabel NTAG In
Primary Key : NO NTAG
Secondary Key: Nomor GR, Gudang Asal
Tabel 3.9 NTAG IN
Field Name Data Type Field
Size
Description
Tanggal Smalldatetime 4 Tanggal sewaktu memasukkan
data
No NTAG Varchar 12 Identitas NTAG In
NomorGR varchar 15 Identitas penerimaan material
Gudang Asal
Char 2 Identitas gudang
BAB I V
IMPLEMENTASI SISTEM DAN ANALISA HASIL
4.1Karakteristik Sistem
Pada sistem inventori gudang Komponen Logam di PT. Mega Andalan
Kalasan terdapat pengguna sistem yaitu Kepala unit dan operator gudang
dimana user Kepala unit dapat melihat data laporan pemakaian material serta
laporan - laporan yang lain yang berkaitan dengan stok raw material yang
terdapat pada gudang KL. Sedangkan user operator gudang dapat melakukan
pengolahan data yang terdapat di dalam sistem.
Untuk Menjaga data Stok di material tetap konsisten maka pada aplikasi
Sistem inventori Raw Material KL ditambahkan dengan store procedure yang
memiliki fungsi transaction management dimana store procedure ini berguna
untuk menjaga konsistensi data material terutama pada menu penambahan
data pemakaian material dan menu penambahan data penerimaan material.
4.2Kebutuhan Sistem
Untuk melakukan pengujian transaction management pada sistem,
dibutuhkan beberapa sistem penunjang, antara lain :
Server
1. Sistem operasi windows 2000 server atau windows 2003 server
2. DBMS SQL Server 2000
Client
1. Sistem operasi windows 98 atau windows 2000 atau windows XP
4.3Aplikasi Yang Digunakan
Dalam proses implementasi untuk transaction management digunakan
mesin DBMS SQL Server 2000 untuk menyimpan tabel yang diperlukan dan
sekaligus untuk melakukan penulisan store procedure yang memiliki fungsi
transaction management. Store procedure yang dibuat memiliki isolation level
Serializable.
4.3.1 Store Procedure untuk pemakaian material
Dalam sistem ini terdapat store procedure yang digunakan untuk
menambahkan data pemakaian material yang didalamnya terdapat fungsi
transaction management yang berguna untuk menjaga data stok di tabel
material dalam database sistem inventory Raw Material Gudang
Komponen Logam. Store Procedurenya dapat dilihat seperti pada gambar
4.1.
--SP_pemakaian_stock
CREATE procedure sp_pemakaian_stock
@KodeMaterial varchar(6), @Tanggal smalldatetime, @Keperluan varchar(125), @NoGR varchar(15), @PDMM numeric(9), @QTY numeric(9)
as
declare @Loop int,@Loop1 int, @stock numeric, @No_Id_Pemakaian int,
@TotalPakai numeric(9),@Panjang numeric(9) ,@tgldatang
smalldatetime,@NoOP varchar(12),@Koven char(2),@Harga money
set Xact_abort on
set transaction isolation level serializable
begin transaction
select @No_Id_Pemakaian=max(No_Id_Pemakaian)+1 from PemakaianMaterial select Kodematerial from Material
select @tgldatang=p.TglDatang, @NoOP=p.NomorOP, @Koven=p.KodeVendor, @Harga=dp.Harga from penerimaanmaterial p,detailpenerimaanmaterial dp where dp.KodeMaterial=@KodeMaterial and dp.NoGR = @NoGR and p.NoGR=dp.NoGR
set @Loop = 0
while @Loop < 100000 Begin
set @Loop = @Loop+1 end
update Material set Stock = Stock where Kodematerial = @KodeMaterial
select @stock = Stock, @Panjang = Panjang from material where KodeMaterial = @KodeMaterial
set @TotalPakai = ((@PDMM*@QTY)/@Panjang) If @stock <= @TotalPakai or @TotalPakai <= 0
begin
raiserror ('Data stock material tidak mencukupi',16,1) end
else
begin
Update material
set Stock = @stock - @TotalPakai, TanggalUpdate = @Tanggal where KodeMaterial=@KodeMaterial
insert into PemakaianMaterial(No_Id_Pemakaian,KodeMaterial,
TanggalPakai,tgldatang,KodeVendor,NomorOP,NoGR,Harga, Keperluan,PDMM, QTY, TotalPakai)
values (@No_id_Pemakaian,@KodeMaterial, @Tanggal,@tgldatang,
@Koven, @NoOP,@NoGR ,@Harga ,@Keperluan,@PDMM,
@QTY,@TotalPakai) if @@error <> 0 begin
rollback transaction
raiserror ('Data tidak bisa disimpan',16,1) end
end
commit transaction
Dari gambar 4.1 dapat dilihat bagaimana transaction management
diterapkan dengan menggunakan perintah yang dicetak tebal. Perintah Set
Xact_abort on berfungsi untuk melakukan pembatalan transaksi apabila
terjadi kegagalan. Sedangkan perintah untuk Transaction managementnya
adalah Set transacton isolation level serializable , dan untuk memulai
transaksi digunakan perintah Begin transaction serta untuk mengakhirinya
digunakan perintah commit Transaction. Untuk melakukan penguncian
pada tabel material adalah dengan melakukan update pada kolom dan baris
yang akan diubah yaitu kolom stok dengan kode material tertentu.
Perintahnya adalah Update Material set stock =stock where Kodematerial
= @Kodematerial. Dengan melakukan perintah ini maka kolom tersebut
akan diunci sehingga apabila ada transaksi lain yang akan mengubah
kolom tersebut tidak akan diijinkan sampai transaksi yang telah
mendapatkan kunci selesai melakukan perubahan data. Untuk mengubah
data material digunakan perintah berikut :
Update material
set Stock = @stock - @TotalPakai, TanggalUpdate = @Tanggal where KodeMaterial=@KodeMaterial
4.3.2 Store Procedure untuk penerimaan material
Dalam sistem ini juga terdapat store procedure yang digunakan untuk
menambahkan data material yang masuk dalam store procedure ini juga
terdapat fungsi transaction management yang berguna untuk menjaga data
stok di material. Store Procedurenya dapat dilihat seperti pada gambar 4.2.
--SP_tambah_stock
CREATE procedure SP_Tambah_stock
@NoGR varchar(15), @QTY numeric,@Harga numeric,@Keterangan varchar, @Tanggal smalldatetime,
@NoOP varchar(8),@KodeVendor varchar(2) , @KodeMaterial varchar(6) --, as
declare @stock numeric, @mLoop int
set xact_abort on
Set Transaction isolation level serializable begin transaction
select Stock from Material
select NoGR from PenerimaanMaterial
select NoGR, KodeMaterial from DetailPenerimaanMaterial
select @stock = stock from Material where kodematerial=@KodeMaterial SET @mLoop = 0
BEGIN
WHILE @mLoop <100000 SET @mLoop = @mLoop + 1 END
update material set Stock=Stock where KodeMaterial=@KodeMaterial
select @stock = stock from material where kodematerial = @KodeMaterial begin
update material set stock=stock+@QTY, TanggalUpdate=@Tanggal where KodeMaterial=@KodeMaterial
insert into penerimaanmaterial
(NoGR,TglDatang,NomorOP,KodeVendor)
values(@NoGR,@Tanggal,@NoOP,@KodeVendor)
insert into detailpenerimaanMaterial
(NoGR,KodeMaterial,QTY,Harga,Keterangan)
values(@NoGR,@KodeMaterial,@QTY,@Harga,@keterangan) if @@error <> 0
begin
rollback transaction
raiserror ('Data tidak bisa disimpan',16,1) end
end
commit transaction
Gambar 4.2 Store procedure penerimaan material
Sama dengan yang dilakukan pada transaksi pemakaian material pada
