BAB 4 IMPLEMENTASI DAN EVALUASI
4.1 Sistem Yang Diusulkan Berdasarkan hasil analisis sistem yang sedang berjalan pada Bab 3, sistem yang diusulkan dapat dibuat seperti pada Gambar 4.1 berikut ini :
Gambar 4.1 Diagram Konteks
72
73
Gambar 4.2 Diagram Nol
74
Dengan melihat permasalahan yang ada pada PT Toko Gunung Agung Tbk yang telah dibahas pada bab sebelumnya, maka penulis mengusulkan untuk membentuk sistem basis data yang terintegrasi dan terancang dengan baik. Sistem tersebut ditujukan agar informasi yang ada bersifat akurat dalam pencatatan persediaan barang serta proses lain yang berkaitan dengan persediaan barang tersebut. Untuk membantu memecahkan permasalahan pada sistem basis data yang dihadapi PT Toko Gunung A gung Tbk, penulis melakukan perancangan basis data yang terdiri dari 3 (tiga) tahapan yang disesuaikan dengan kebutuhan informasi pada PT Toko Gunung Agung Tbk. Adapun ketiga peracangan basis data tersebut sebagai berikut : 1. Perancangan Basis Data Konseptual 2. Perancangan Basis Data Logikal 3. Perancangan Basis Data Fisikal Dari permasalahan sistem yang ada, maka penulis merancang sistem basis data terdistribusi persediaan yang pada penggunaannya diharapkan dapat berprilaku seperti halnya sistem yang tidak terdistribusi. Satu hal yang penting adalah perbedaan antara sistem basis data terdistribusi dengan akses data secara remote (yang sering kali disebut sebagai sistem pengolahan terdistribusi atau sistem jaringan). Pada sistem akses data remote, pengguna dapat beroperasi pada data yang letaknya berjauhan secara simultan, namun dalam permasalahan ini pengguna harus menyadari dimana lokasi data yang diakses. Sebaliknya, pada sistem basis data terdistribusi hal tersebut bersifat transparan.
75 Distribution database management system yang akan dirancang adalah tipe distribusi secara geografis dan administrasinya terpisah. Sistem ini mempunyai sebuah jaringan interkoneksi sebagai sarana tukar menukar informasi terdistribusi yang akan dibangun. Sistem basis data terdistribusi berisi kumpulan site yang mengeksekusi transaksi lokal (mengakses data pada satu site) dan transaksi global (mengakses data pada site berbeda) Dalam aplikasi PT Toko Gunung Agung Tbk terdapat 32 cabang, namun untuk pertama kali diimplementasikan pada 5 (lima) cabang di daerah yg berbeda yaitu Jakarta, Bandung, Semarang, Cirebon dan Bali. M asing – masing dengan record persediaan yang dilayani oleh masing – masing cabang. Pada hal ini dapat dirasakan secara langsung bentuk terdistribusi data yang sesuai dengan lokasi yang sering mengolah data. Namun, dengan berbagai pelayanan yang salah satunya pelayanan antar cabang, maka harus dimungkinkan bahwa pada staff
divisi
general affair dari Jakarta dapat melakukan pemakaian pada cabang di Atrium atau sebaliknya melalui jaringan internet dari beberapa cabang.
4.2
Perancangan Sistem Basis Data Konseptual Proses membangun sebuah rancangan informasi yang digunakan dalam suatu perusahaan yang bebas dari pertimbangan fisikal. Perancangan ini melibatkan pembuatan suatu model data konseptual dari bagian perusahaan dimana penulis tertarik pada permodelan datanya. M odel data dibuat dengan menggunakan informasi yang didokumentasikan dalam penspesifikasian kebutuhan user. Perancangan basis data konseptual secara keseluruhan bebas dari rincian
76 implemantasi seperti software DBM S sasaran, program aplikasi, bahasa pemrograman, hardware platform, pertimbangan fisikal lainnya. Langkah-langkah dalam perancangan basis data konseptual : 1. M engidentifikasikan tipe entiti 2. M engidentifikasikan tipe relasional 3. M engidentifikasikan dan menghubungakan atribut dengan tipe entiti atau relasi 4. M engidentifikasikan domain atribut 5. M enentukan atribut candidate key dan primary key 6. Validasi model konseptual terhadap transaksi user
4.2.1
Mengidentifikasikan Tipe Entiti Berikut ini merupakan tabel yang menjelaskan entiti-entiti yang digunakan dalam perancangan, antara lain: Tabel 4.1 Kamus Data Entitas NAMA
KETERANGAN
ALIAS
KEMUNCULAN
ENTITAS GAPembelian
yang Pembelian
Merupakan
entitas
menyimpan
informasi
yang
berhubungan
dengan
setiap
pembelian yang dikeluarkan oleh suatu pusat.
On Demand
77
NAMA
KETERANGAN
ALIAS
KEMUNCULAN
ENTITAS GAPengiriman
Merupakan
entitas
menyimpan
informasi
yang Pengiriman
On Demand
yang
berhubungan dengan informasi pengiriman barang dari pusat ke cabang dan sebaliknya. GARetur
Merupakan
entitas
menyimpan
informasi
berhubungan
yang Retur
On Demand
yang dengan
pengembalian
barang
ke
supplier. GAItemBarang
Merupakan
entitas
menyimpan
informasi
yang ItemBarang
Harian
yang
berhubungan dengan item barang yang ada GAStock
yang Stock
Merupakan
entitas
menyimpan
informasi
yang
berhubungan
dengan
stock
Merupakan
entitas
yang Supplier
menyimpan
informasi
Harian
barang yang ada
GASupplier
yang
berhubungan dengan supplier
On Demand
78 NAMA
KETERANGAN
ALIAS
KEMUNCULAN
ENTITAS GACa bang
Merupakan
entitas
menyimpan
informasi
berhubungan
dengan
yang Cabang
On Demand
yang cabang-
cabang yang ada GAPenerimaan
Merupakan
entitas
menyimpan
informasi
yang Penerimaan
On Demand
yang
berhubungan dengan penerimaan barang GAUser
Merupakan
entitas
menyimpan
informasi
yang User
On Demand
yang
berhubungan dengan pemakai aplikasi Back-Office GAKaryawan
Merupakan
entitas
menyimpan
informasi
yang Karyawan
Bulan
yang
berhubungan dengan karyawan GAPermintaan
Merupakan
entitas
menyimpan
informasi
yang Permintaan yang
berhubungan dengan permintaan akan barang dari pusat.
On Demand
79
NAMA
KETERANGAN
ALIAS
KEMUNCULAN
ENTITAS GADepartemen
Merupakan
entitas
menyimpan
informasi
yang Departemen
On Demand
yang
berhubungan dengan departemen dari pusat maupun cabang yang dimiliki PT Toko Gunung Agung T bk. GAPemakaian
Merupakan
entitas
menyimpan
informasi
yang Pemakaian
On Demand
yang
berhubungan dengan permintaan akan barang dari pusat.
4.2.1.1
Mengidentifikasikan Tipe Relasi Tujuan dari tahapan ini adalah untuk mengidentifikasikan hubungan antara entiti-entiti yang telah diidentifikasikan. Langkah-langkah dalam mengidentifikasikan tipe relasi : 1. M enggunakan Entity Relationship (ER) Diagram 2. M enentukan pembatas multiplicity dari tipe relasi
80 4.2.1.1.1
Menggunakan Entity Relationship (ER) Diagram Berikut ini ERD konseptual yang memuat nama entitas beserta dengan hubungannya (relationship) adalah seperti terlihat pada Gambar 4.3 dibawah ini:
81
Ba gia n dari
Ba gia n dari
me mpun yai
Bag ian d ari
Bagi an da ri
Bag ian d ari
mene mpati
mel akuka n
Ba gia n dari
Bag ian d ari
mempu nyai
memp unya i
Gambar 4.3 Entity Relationship (ER) Diagram Persediaan Barang Pakai pada Divisi General Affair PT Toko Gunung Agung Tbk
82
4.2.1.1.2
Mengidentifikasikan Atribut Untuk Tiap Entiti dan Menentukan Domain Atribut Tujuan dari tahapan ini adalah untuk mengidentifikasikan dan menghubungkan atribut dengan tipe entiti atau hubungan seperti terlihat pada Lampiran A (Tabel 4.2).
4.2.1.1.3
Menentukan Pembatas Multiplicity dari Tipe relasi Setelah
ditentukan
Entity
Relationship
(ER)
Diagram
Konseptual, maka langkah selanjutnya adalah menentukan batas multiplicity (batasan tipe relasi) dari masing-masing entiti sesuai relasinya dengan entiti yang lain seperti terlihat pada Lampiran B (Tabel 4.3).
4.2.1.2
Menentukan Atribut Candidat Key dan Primary Key Berikut ini merupakan penentuan atribut candidate dan primary key dari setiap entiti yang ada seperti terlihat pada Tabel 4.4 di bawah ini : Tabel 4.4 Identifikasi Candidate dan Primary Key
Entity GAPembelian
Candidate Key Kode_Pembelian
Primary Key Kode_Pembelian
No_Faktur GAPengiriman
Kode_Pengiriman
Kode_Pengiriman
GARetur
Kode_Retur
Kode_Retur
83 Entity
Candidate Key
Primary Key
GAItemBarang
Kode_ItemBarang
Kode_ItemBarang
GAStock
Kode_Stock
Kode_Stock
GASupplier
Kode_Supplier
Kode_Supplier
Kode_pos No_Ijin_Usaha GACabang
Kode_Cabang
Kode_Cabang
Kode_Pos Kode_Distrik GAPenerimaan
Kode_Penerimaan
Kode_Pembayaran
GAUser
Kode_User
Kode_User
GAKaryawan
Kode_Karyawan
Kode_Karyawan
Kode_Pos GAPermintaan
Kode_Permintaan
Kode_Permintaan
GaDepartemen
Kode_Departemen
Kode_Departemen
GAPemakaian
Kode_Pemakaian
Kode_Pemakaian
84
4.2.1.3
Mempertimbangkan Penggunaan Konsep Model Enhanced Berdasarkan fact finding (Bab 3) saat mempelajari dokumen bahwa transaksi ada dua jenis yakni transaksi permintaan dan transaksi pembelian. Kedua entiti ini mempunyai hubungan M andatory Or, seperti terlihat pada Gambar 4.4 :
B agian dari
m elakukan B agian dari
mem punyai
B agian dari
Bagian dari
Bagi an dari
B agian dari
menem pati
Generalisasi
B agian dari
melakukan
mem punyai
mem punyai
Gambar 4.4a Revisi ERD dengan Penambahan S pesialisasi /
85 Transaksi pada Gambar 4.4a ternyata mengandung konsep model enhanced sehingga rancangan berubah menjadi seperti pada Gambar 4.4b di bawah ini :
Gambar 4.4b Gambar Hubungan Mandatory OR
Sistem model enhanced kemudian divalidasi dengan transaksi, dan akan terlihat pada Gambar 4.5 di bawah ini :
86
Gambar 4.5 Model Konseptual Sistem Basis Data Terdistribusi Pada Persediaan Barang Pakai Divisi General Affair PT Toko Gunung Agung Tbk.
87 4.2.1.4
4.2.2
Validasi Model Konseptual Data Lokal Terhadap Transaksi User (A)
M enampilkan detail barang yang disediakan oleh supplier.
(B)
M enampilkan detail barang dari suatu pembelian.
(C)
M enampilkan detail barang dari suatu permintaan.
(D)
M enampilkan detail barang dari suatu pengiriman.
(E)
M enampilkan detail barang yang di retur.
(F)
M enampilkan supplier yang memasok suatu pembelian.
(G)
M enampilkan karyawan yang melakukan retur item barang.
(H)
M enampilkan karyawan yang melakukan permintaan.
(I)
M enampilkan karyawan yang melakukan penerimaan.
(J)
M enampilkan karyawan yang melakukan pembelian.
(K)
M enampilkan detail penerimaan barang berdasarkan pembelian.
(L)
M enampilkan retur berdasarkan permintaan.
(M )
M enampilkan pengiriman berdasaran permintaan.
(N)
M enampilkan karyawan yang melakukan pengiriman
(O)
M enampilkan detail pemakaian berdasarkan item barang
(P)
M enampilkan detail pemakaian berdasarkan departemen
Perancangan Basis Data Logikal Berdasarkan hasil rancangan konseptual Gambar 4.5, dilakukan rancangan logikal seperti terlihat pada Lampiran C, yaitu :
88 4.2.2.1
Menghilangkan Fitur Tidak Kompatibel M emperbaiki model data konseptual lokal untuk menghilangkan fitur-fitur yang tidak kompatibel dengan model relasional.
4.2.2.1.1
Menghilangkan Many – to – Many (*:*) Binary Relationship Types Bila dalam model konseptual masih terdapat hubungan many – to – Many (*:*) binary relationship type, maka harus diubah menjadi hubungan one – to – many (1:*) dengan penambahan entiti baru. (Lihat pada Lampiran C)
4.2.2.1.2
Menghilangkan tipe relasi many-to-many (*:*) rekursif Pada model konseptual, terdapat relasi many-to-many (*:*) rekursif diubah menjadi kompatibel seperti terlihat pada Lampiran C Gambar 4.6 :
4.2.2.1.3
Menghilangkan tipe relasi yang kompleks Pada model konseptual tidak terdapat tipe relasi yang kompleks.
4.2.2.1.4
Menghilangkan atribut multi-valued Pada model konseptual terdapat atribut multi-valued, dan diubah kompatibel seperti terlihat pada Lampiran C Gambar 4.7b, Gambar 4.8b, dan Gambar 4.9b.
89 4.2.2.1.5
Strong and Weak Entity Types
4.2.2.1.5.1
Strong Entity Types Untuk setiap strong entity di dalam model data, buat sebuah relasi yang mengandung semua atribut sederhana entitas tersebut. (Lihat pada Lampiran C).
4.2.2.1.5.2
Weak Entity Types Untuk setiap weak entity didalam model data, buat sebuah relasi yang memasukkan semua atribut sederhana pada entitas tersebut. Primary key weak entity merupakan turunan parsial atau keseluruhan dari setiap pemilik entitas dan oleh karena itu identifikasi primary key weak entity tidak bisa dibuat sampai semua relasi pemilik entitas telah di petakan. (Lihat pada Lampiran C).
4.2.2.1.6
S tructural Constraints
4.2.2.1.6.1
One – to – Many (1:*) Binary Relationship Types Untuk masing-masing one - to – many binary relationship types, ‘dalam satu sisi’ menjadi entiti induk dan entity yang lain menjadi entiti anak. Untuk merepresentasikannya, tindakan primary key induk ke entiti anak sebagai foreign key. (Lihat pada Lampiran C)
90 4.2.2.1.6.2
One – to One (1:1) Binary Relationship Types Berdasarkan hasil fact finding (BAB 3) bahwa relasi ini memiliki jenis Mandatory satu sisi (Lihat pada Lampiran C).
4.2.2.2
Validasi Model dengan Normalisasi Proses normalisasi data dimaksudkan untuk menghilangkan redudansi semaksimal mungkin dan meningkatkan kemudahan operasi untuk mengubah, menghapus, dan memasukkan data pada suatu basis data. Pada waktu menghilangkan feature yang tidak kompatibel dengan model relasional, tabel sudah berada dalam bentuk normalisasi pertama (menghilangkan repeating group) yang dapat dilihat pada model data logikal lokal, dan untuk jelasnya akan dibuat normalisasi dari tahapan bentuk normal kedua yakni menghilangkan partial dependency dan membuat lebih dahulu bentuk normal ketiga yakni menghilangkan transitive dependency.
Adapun
langkah-langkah normalisasi yang
dilakukan seperti terlihat pada Lampiran C.
4.2.2.3
Menentukan Relasi untuk Model Logikal Global M enggabungkan logikal lokal global data model ke dalam model global. Pada langkah ini penulis membangun sebuah global logikal data model dengan menggabungkan bersama – sama antara logikal lokal data model untuk masing – masing tabel. Setelah digabungkan diperlukan untuk validasi dari model global, yang pertama dimulai dari normalisasi dan kedua mulai mendeskripsikan transaksi pada semua view.
91 GAHeader_Pembelian Penggabungan
data
CabangHeader_Pembelian
dengan
PusatHeader_Pembelian seperti berikut :
GADetail_Pembelian Penggabungan
data
CabangDetail_Pembelian
PusatDetail_Pembelian seperti berikut :
dengan
92
GAHeader_Retur Penggabungan data CabangHeader_Retur dengan PusatHeader_Retur seperti berikut :
GADetail_Retur Penggabungan data CabangDetail_Retur dengan PusatDetail_Retur seperti berikut :
93 GAHeader_Pengiriman Penggabungan
data
CabangHeader_Pengiriman
PusatHeader_Pengiriman seperti berikut :
GADetail_Pengiriman Penggabungan data CabangDetail_Pengiriman dengan PusatDetail_Pengiriman seperti berikut :
dengan
94 GAItemBarang Penggabungan data CabangItemBarang dengan PusatItemBarang seperti berikut :
GAHeader_S tock Penggabungan data CabangHeader_Stock dengan PusatHeader_Stock seperti berikut :
95 GADetail_Stock Penggabungan data CabangDetail_Stock dengan PusatDetail_Stock seperti berikut :
GAS upplier Penggabungan data CabangSupplier dengan PusatSupplier seperti berikut :
96 GACabang Penggabungan data Cabang dengan PusatCabang seperti berikut :
GAHeader_Penerimaan Penggabungan data CabangHeader_Penerimaan dengan PusatHeader_Penerimaan seperti berikut :
97 GADetail_Penerimaan Penggabungan data CabangDetail_Penerimaan dengan PusatDetail_Penerimaan seperti berikut :
GAUser Penggabungan data CabangUser dengan PusatUser seperti berikut :
98 GAKaryawan Penggabungan data CabangKaryawan dengan PusatKaryawan seperti berikut :
GAHeader_Permintaan Penggabungan
data
CabangHeader_Permintaan
PusatHeader_Permintaan seperti berikut :
dengan
99 GADetail_Permintaan Penggabungan
data
CabangDetail_Permintaan
dengan
PusatDetail_Permintaan seperti berikut :
GADepartemen Penggabungan data CabangDepartemen dengan PusatDepartemen seperti berikut :
100
GAHeader_Pemakaian Penggabungan
data
CabangHeader_Pemakaian
dengan
PusatHeader_Pemakaian seperti berikut :
GADetail_Pemakaian Penggabungan
data
CabangDetail_Pemakaian
PusatDetail_Pemakaian seperti berikut :
dengan
101 Pembayaran_S upplier Penggabungan
data
CabangPembayaran_Supplier
dengan
PusatPembayaran_Transaksi seperti berikut :
ContactPerson_Supplier Penggabungan
data
Cabang_ContactPerson_Supplier
Pusat_ContactPerson_Supplier seperti berikut :
dengan
102
ContactPerson_Cabang Penggabungan
data
CabangContactPerson_Cabang
dengan
PusatContactPerson_Cabang seperti berikut :
ContactPerson_Karyawan Penggabungan
data
CabangContactPerson_Karyawan
PusatContactPerson_Karyawan seperti berikut :
dengan
103
Alamat_Karyawan Penggabungan
data
CabangAlamat_Karyawan
dengan
PusatAlamat_Karyawan seperti berikut :
Pengawasan Penggabungan data CabangPengawasan dengan PusatPengawasan seperti berikut :
104 4.2.2.4
Validasi Relasi terhadap Transaksi user Semua transaksi user
seperti yang didefinisikan pada tahap
konseptual, diperiksa kembali terhadap relasi yang ada untuk memastikan bahwa relasi sudah benar dan dapat memenuhi transaksi yang dibutuhkan oleh user.
4.2.2.4.1
Mendefinisikan Kendala Integrity Terdapat 5 tipe dari kendala integrity antara lain :
4.2.2.4.1.1
Required Data Beberapa atribut tertentu dari entiti atau relasi harus selalu mengandung nilai valid, dengan kata lain atribut tidak boleh mengandung nilai null. Constraint ini telah di lakukan pada saat kamus atribut.
4.2.2.4.1.2
Attribute Domain Constraint Setiap atribut mempunyai domain sendiri yaitu sekumpulan nilai yang sah untuk suatu atribut (tipe data dan panjang). Constraint ini telah ditentukan dalam tabel domain atribut.
4.2.2.4.1.3
Entiti Integrity Entiti integrity dimaksudkan untuk mengecek primary key dari suatu entiti agar tidak boleh mengandung nilai null. Constraint ini telah ditentukan dalam kamus data atribut.
105 4.2.2.4.1.4
Referential Integrity Referential Integrity dimaksudkan untuk mengecek foreign key yang menghubungkan setiap tuple di dalam relasi anak kepada tuple dalam relasi induk yang mengandung nilai primary key yang cocok. (Lihat pada Lampiran C).
4.2.3
Perancangan Basis Data Fisikal Proses menghasilkan sebuah deskripsi atau gambar implementasi basis data pada media penyimpanan yang menggambarkan hubungan dasar, organisasi data, dan indeks-indeks yang memungkinkan pengaksesan data yang efisien. Pada umumnya, tujuan utama dari perancangan basis data fisikal adalah menjelaskan bagaimana kita bermaksud untuk mengimplemantsikan perancangan basis data logikal secara fisik. Pada perancangan basis data fisikal terdapat pembahasan perancangan database design language (DBDL) untuk setiap entiti, perancangan constraint setiap
entiti, analisis transaksi, pembuatan indeks, serta perancangan
mekanisme keamanan data.
4.2.3.1
Menerjemahkan Model Logikal Dalam DBMS Bertujuan untuk membuat suatu skema basis data relasional dari model data logikal yang dapat diimplementasikan ke DBM S yang dituju.
106
4.2.3.1.1
Pemilihan DBMS Berikut ini karakteristik DBM S SQL 2005 yang digunakan dalam desain fisikal ini. Tabel 4.7 Karakteristik SQL 2000 SQL 2000 Enterprise Edition
Tipe DBM S
Transactional relational database server
Kebutuhan Piranti Keras
Processor : Intel Pentium4 2 GHz M emory : 256 M B RAM Hard disk space : 160 M B
Kebutuhan Piranti Lunak
Windows XP (Lebih baik XP2)
Portability
Dapat berjalan diatas berbagai macam O S
Open Source
Bersifat Open Source
Multiuser
Dapat digunakan oleh banyak user pada waktu yang bersamaan
Security
M empunyai beberapa lapisan keamanan seperti User Permission and Password ter-enkripsi
Scalability & Limits
Dapat menangani jumlah record lebih dari 50 juta dan jumlah tabel 60 ribu
Graphical user interface
Dapat menggunakan software sebagai user interface dengan user sehingga memudahkan penggunaannya.
107 4.2.3.1.2
Merancang Relasi Dasar Tujuan dari tahap ini adalah untuk merepresentasikan relasi dasar yang diidentifikasi pada model data logikal global ke dalam sasaran DBM S dengan menggunakan DBDL (Database Design Language). DBDL yang digunakan seperti pada Lampiran D.
4.2.3.1.3
Representasi Data 1) Tabel 4.8 Representasi Data Tabel GAHeader_Transaksi_ Pembelian
Kode_Pembeli
Status
Diskon
an
Tanggal
No_Faktur
PPN
Kode_Supplier
Net_To
_Faktur
BL0811-0001
SD
10.00
11/11/08
tal BL0811-
0
GA0001
0001 BL0811-0002
BD
5.00
11/11/08
0
BL0811-
0
GA0001
0002 BL0811-0003
SR
2.50
11/01/08
220000
100000 00
BL0811-
1
GA0002
500000
0
GA0004
200000
0003 BL0811-0004
CL
0
11/04/08
BL08110004
2) Tabel 4.9 Representasi Data Tabel GADetail_Transaksi_ Pembelian Kode_Pembelian
Kode_ItemBarang
Jumlah_Pembelian
Harga_Beli
BL0811-0001
GB00005
10
10250
BL0811-0001
GB00010
2
125000
BL0811-0001
GB00210
1
50500
BL0811-0002
GB00222
2
1230000
108 3) Tabel 4.10 Representasi Data Tabel GAHeader_Pengiriman Kode_Pengiriman
Status
Tanggal_Kirim
Kode_Permintaan
KR0811-0001
SR
11/03/08
RQ0811-0010
KR0811-0002
BR
11/03/08
RQ0811-0011
KR0811-0003
SD
11/04/08
RQ0811-0022
KR0811-0004
SR
11/04/08
RQ0811-0025
4) Tabel 4.11 Representasi Data Tabel GADetail_Pengiriman Kode_Pengiriman
Kode_ItemBarang
Jumlah_Pengiriman
KR0811-0001
GB00010
10
KR0811-0001
GB00015
2
KR0811-0002
GB00005
2
KR0811-0002
GB00001
10
5) Tabel 4.12 Representasi Data Tabel GAHeader_Retur Kode_Retur
Status
Tanggal_Retur
Kode_Supplier
Kode_Pembelian
RT0811-0001
SR
10/11/08
GP0010
BL0811-0002
RT0811-0002
BR
10/11/08
GP0015
BL0811-0003
RT0811-0003
SR
15/11/08
GP0021
BL0811-0001
RT0811-0004
SR
17/11/08
GP0011
BL0811-0004
109 6) Tabel 4.13 Representasi Data Tabel GADetail_Retur Kode_Retur
Jumlah_Retur
Kode_Pengiriman
Kode_ItemBarang
RT0811-0003
1
KR08-11-0004
GB00001
RT0811-0003
2
KR08-11-0004
GB00010
RT0811-0003
2
KR08-11-0004
GB00100
RT0811-0004
2
KR08-11-0008
GB00120
7) Tabel 4.14 Representasi Data Tabel GAItemBarang Kode_ItemBarang
Deskripsi_ItemBarang
PPN
Harga_B
Supplier_Discount
Min_Stock
eli GB00001
USB 2.0 KINGSTON
0
180000
5.00
5
GB00002
BOLPOINT
FABER
0
12300
1.25
10
LASERJET
1
3250000
10.00
1
0
10500
5.00
10
CASTLE GB00003
PRINTER HP 10560
GB00004
KLIP JOYKO 2.5ML
8) Tabel 4.15 Representasi Data Tabel GAHeader_S tock Kode_Stock
Tanggal
Status
Tgl_Mutasi
Kode_Cabang
GS00001
12/04/08
AWL
30/04/08
02
GS00005
14/05/08
TRN
31/05/08
06
GS00007
25/06/08
NTI
30/06/08
08
GS00009
10/09/08
NTO
31/09/08
06
110 9)
Tabel 4.16 Representasi Data Tabel GADetail_S tock
Kode_Stock
Kode_ItemBarang
Masuk
Keluar
Sisa
GS00001
GB00004
100
20
80
GS00005
GB00004
100
50
130
GS00007
GB00004
50
0
180
GS00009
GB00004
0
120
60
10) Tabel 4.17 Representasi Data Tabel GAS upplier Kode
Nama_Su
Jenis_
_Sup
pplier
Supply
Alamat
Kode
Kot
No_Ijin
_Pos
a
_Usaha
NPWP
10640
Jaka
00591/1.
2.005.6
rta
824.51
21.4.05
PK
Tgl_
Recom
Tgl_E
P
Masu
mende
valua
plier
k
GP00
Ahmad
01
Latif
BMS
JL. BUKIT PAKAR TIMUR II
1
16/01/
d 0
2004
si 31/10/ 2008
6
NO.109 GP00
Bersaudar
02
a Inti
MBING I
Corpora
NO.24
GP00
Betawinas
BMS
MS
03
JL.PULOKA
PELIKAN
10440
Jaka
2410611
1.482.8
rta
/01-12
28.9-
10110
Jaka
7310903
1.248.1
rta
PBX91
73.5-
BINTARO Central
04
Anugerah
BMS
JL CIPINANG
Distribusi
MUARA
ndo
RAYA NO.11
19/04/
0
2001
31/10/ 2008
423
3/19
GP00
1
1
20/09/
0
1997
31/10/ 2008
541 10210
Jaka
111ERP
1.710.8
rta
11
80.4011
0
08/07/ 1999
0
31/10/ 2008
111
11) Tabel 4.18 Representasi Data Tabel GACabang Kode
Deskrip
Tanggal
_Cab
si_Caba
_Buka
ang
ng
01
NPWP
PKP
Alamat
Kota
Kod
Propin
Nama
e_Po
si
_Distr
s
Pusat
9/21/200
01.316.91
0
2.3-
0
ik
Jl. Kwitang
Jakart
1042
DKI
DIST
Raya No. 6
a
0
Jakarta
RIK
054.000 02
Kwitang
5/1/1998
06 03
Kwitng
6/9/1999
38
00
01.316.91 0
Jl. Kwitang
Jakart
1042
DKI
DIST
2.3-05
Raya No. 6
a
0
Jakarta
RIK 1
01.316.91 0
Jl. Kwitang
Jakart
1042
DKI
DIST
2.3-05
Raya No.
a
0
Jakarta
RIK 1
Jl.
Jakart
1213
DKI
DIST
Bulungan
a
0
Jakarta
RIK 2
38 04
Blok M
10/11/20
01.316.91
Plaza
00
2.3-05
0
12) Tabel 4.19 Representasi Data Tabel GAHeader_Penerimaan Kode_Penerimaan TP00001
Deskripsi_Penerimaan Penerimaan barang dari
Tanggal_Penerimaan
Kode_Karyawan
03/03/2008
02-100002
supplier TP00002
Penerimaan barang dari pusat
15/06/2008
02-100002
TP00003
Penerimaan barang dari pusat
18/09/2008
01-100001
TP00004
Penerimaan barang dari
27/11/2008
01-100006
supplier
112 13) Tabel 4.20 Representasi Data Tabel GADetail_Penerimaan Kode_Penerimaan
Kode_Pembelian
Kode_ItemBarang
Jumlah Penerimaan
TP00001
BL0811-0001
GB00001
10
TP00002
BL0811-0002
GB00001
2
TP00003
BL0811-0003
GB00002
1
TP00004
BL0811-0004
GB00005
2
14) Tabel 4.21 Representasi Data Tabel GAUser Kode_User
Password
Sec_Level
Kode_Karyawan
00001
Pas1
1
02-100001
00002
Pas2
1
02-200001
00003
Pas3
2
02-100002
00004
Pas4
3
02-100003
15) Tabel 4.22 Representasi Data Tabel GAKaryawan Kode_Karyawan
Nama_Karyawan
Tgl_Masuk
Kode_Cabang
02-100001
Topan Kurniawan
10/12/02
02
02-200001
Untung Setiawan
10/12/02
02
02-100002
Lerry Sulistiawati
10/12/02
01
02-100003
Cherya
10/12/02
01
113 16) Tabel 4.23 Representasi Data Tabel GAHeader_Permintaan Kode_Permintaan
Deskripsi
Tgl_Permintaan
Kode_Cabang
RQ0811-0001
PERMINTAAN PENGIRIMAN
11/09/08
01
RQ0811-0002
PERMINTAAN
11/09/08
02
PENGIRIMAN
ULANG RQ0811-0003
PERMINTAAN RETUR BARANG
11/12/08
01
RQ0811-0004
PERMINTAAN PEMBELIAN
11/12/08
01
17) Tabel 4.24 Representasi Data Tabel GADetail_Permintaan Kode_Permintaan
Kode_ItemBarang
Jumlah_Permintaan
RQ0811-0004
GB00005
1
RQ0811-0004
GB00100
2
RQ0811-0004
GB00201
2
RQ0811-0004
GB00222
2
18) Tabel 4.25 Representasi Data Tabel GADepartemen Kode_Depart
Deskripsi_Departe
emen
men
10
20
30
40
ATK
BARCODE
CETAKAN
KERTAS
Counter
Section
PPN
Kode_Caba ng
OTHERS
UNKN
STATIONARY
OWN
OFFICE
UNKN
EQUIPMENT
OWN
COMPUTER
UNKN
STATION
OWN
PAPER
UNKN OWN
1
03
0
02
1
01
1
06
114 19) Tabel 4.26 Representasi Data Tabel GAHeader_Pemakaian Kode_Pemakaian
Tanggal_Pemakaian
Kode_Departemen
PE00001
01/04/2008
20
PE00002
14/05/2008
10
PE00003
10/08/2008
50
PE00004
29/11/2008
20
20) Tabel 4.27 Representasi Data Tabel GADetail_Pemakaian Kode_Pemakaian
Jumlah_Pemakaian
Kode_ItemBarang
PE00001
3
GB00001
PE00002
7
GB00002
PE00003
2
GB00003
PE00004
9
GB00004
21) T Tabel 4.28 Representasi Data Tabel Pembayaran_S upplier Kode_Supplier
Cara_Bayar
Bank_Bayar
Account_Bayar
GP0001
Transfer
BCA
5298989888
GP0002
Transfer
MANDIRI
6788553333
GP0003
Kredit
BCA
5277155266
GP0004
Debit
BNI
4599981522
115 22) Tabel 4.29 Representasi Data Tabel ContactPerson_S upplier Telepon
E_Mail
Web_Site
Kode_Supplier
021-7878787
[email protected]
ahmad@lati f.co.id
GP0001
021-4603131
[email protected]
[email protected]
GP0002
021-9180721
[email protected]
[email protected]
GP0003
021-8508168
[email protected]
[email protected]
GP0004
23) Tabel 4.30 Representasi Data Tabel ContactPerson_Cabang Telepon
Email
021-0210211
[email protected]
02
021-7787881
[email protected]
03
021-6677488
[email protected]
04
021-6684999
[email protected]
05
24) Tabel
4.31
Representasi
Kode_Cabang
Data
Tabel
ContactPerson_
Karyawan Telepon
E_Mail
Kode_Cabang
0811772888
[email protected]
02
0817663889
[email protected]
03
0888993666
[email protected]
04
081663778
[email protected]
05
116 25) Tabel 4.32 Representasi Data Tabel Alamat_Karyawan Kode_Karyawan 02-100001
Alamat JL.KREKOT JAYA BLOK D NO.8
Kode_Pos
Kota
40176
Jakarta
02-200001
JL.BANYUWANGI NO.18
10889
Jakarta
02-100002
WISMA 46 KOTA BNI LT.8
13420
Jakarta
02-100003
JL.TRUNTUM VI NO.1
15466
Jakarta
26) Tabel 4.33 Representasi Data Tabel Pengawasan Kode_Karyawan
Tanggal
Hasil
02-100001
01/04/2008
Sesuai
02-200001
14/05/2008
Tidak sesuai
02-100002
10/08/2008
Tidak sesuai
02-100003
29/11/2008
Tidak sesuai
117 4.2.3.1.4
Perancangan Constraints Langkah ini bertujuan untuk merancang constraint untuk sasaran dalam DBM S. Perancangan constraints bertujuan untuk menjamin keakuratan data saat melakukan transaksi. Constraint yang digunakan seperti pada Lampiran E.
4.2.3.2
Representasi Fisikal Langkah ini bertujuan untuk menentukan organisasi file optimal untuk menyimpan relasi-relasi dasar beserta indeks-indeksnya yang diperlukan untuk mencapai performa yang dapat diterima, yaitu sebuah cara dimana relasi-relasi dan baris-baris akan disimpan pada secondary storage.
4.2.3.2.1
Analisis Transaksi Tujuan dari langkah ini adalah untuk memahami fungsionalitas dari transaksi yang akan berjalan pada basis data untuk menganalisis transaksi yang penting. Transaksi-transaksi yang terjadi sebagai berikut: (A) M enampilkan detail barang yang disediakan oleh supplier. (B) M enampilkan detail barang dari suatu pembelian. (C) M enampilkan detail barang dari suatu permintaan. (D) M enampilkan detail barang dari suatu pengiriman. (E)
M enampilkan detail barang yang di retur.
(F)
M enampilkan supplier yang memasok suatu pembelian.
(G) M enampilkan karyawan yang melakukan retur item barang.
118 (H) M enampilkan karyawan yang melakukan permintaan. (I)
M enampilkan karyawan yang melakukan penerimaan.
(J)
M enampilkan karyawan yang melakukan pembelian.
(K) M enampilkan detail penerimaan barang berdasarkan pembelian. (L)
M enampilkan retur berdasarkan permintaan.
(M ) M enampilkan pengiriman berdasaran permintaan. (N) M enampilkan karyawan yang melakukan pengiriman (O) M enampilkan detail pemakaian berdasarkan item barang (P)
M enampilkan detail pemakaian berdasarkan departemen
119 Tabel 4.34 Cross – referencing transactions and relations (A)-(D) Relasi/Transaksi
(A) I
(B)
R U D I
(C)
R U D I
(D)
R U D I
R U D
GAHeader_Pembelian
X
X X X
X
X
GADetail_Pembelian
X
X X
X
X
GAHeader_Pengiriman
X
X
X
X X X
GADetail_Pengiriman
X
X
X
X X
GAHeader_Retur
X
X
X
X
GADetail_Retur
X
X
X
X
X X
X X
X X
X X
GAHeader_Stock
X
X
X
X
GADetail_Stock
X
X
X
X
X X
X X
X
X
GACabang
X
X
X X X
X X
GAHeader_Penerimaan
X
X
X
X
GADetail_Penerimaan
X
X
X
X
X
X
GAItemBarang
GASupplier
GAUser GAKaryawan
X X X X X X X X X X
X X
X X
X X
GAHeader_Permintaan
X
X
X X X
X
GADetail_Permintaan
X
X
X X
X
GADepartemen
X
X
X X X
X X
GAHeader_Pemakaian
X
X
X
X
GADetail_Pemakaian
X
X
X
X
120 Relasi/Transaksi
(A) I
R U D I
(B) R U D I
(C) R U D I
(D) R U D
Pembayaran_Supplier
X
X
X
X
ContactPerson_Supplier
X
X
X
X
ContactPerson_Cabang
X
X
X
X
ContactPerson_Karyawan
X
X
X
X
Alamat_Karyawan
X
X
X
X
Pengawasan
X
X
X
X
I = Insert, R = Raed, U = Update, D = Delete
121 Tabel 4.35 Cross – referencing transactions and relations (E)-(H) Relasi/Transaksi
(E) I
(F)
R U D I
(G)
R U D I
(H)
R U D I
R U D
GAHeader_Pembelian
X
X X
X
X
GADetail_Pembelian
X
X X
X
X
GAHeader_Pengiriman
X
X
X
X
GADetail_Pengiriman
X
X
X
X
X X X
X
X X X
X
GADetail_Retur
X X
X
X X
X
GAItemBarang
X X
X X
X X
X X
GAHeader_Stock
X
X
X
X
GADetail_Stock
X
X
X
X
X X
X X X
X
X
GACabang
X
X
X X
X X
GAHeader_Penerimaan
X
X
X
X
GADetail_Penerimaan
X
X
X
X
X
X
GAHeader_Retur
GASupplier
GAUser GAKaryawan
X X X X X X X X X X
X X
X X X
X X
GAHeader_Permintaan
X
X
X
X X X
GADetail_Permintaan
X
X
X
X X
GADepartemen
X
X
X X
X X
GAHeader_Pemakaian
X
X
X
X
GADetail_Pemakaian
X
X
X
X
122 Relasi/Transaksi
(E) I
(F)
R U D I
(G)
R U D I
(H)
R U D I
R U D
Pembayaran_Supplier
X
X X X
X
X
ContactPerson_Supplier
X
X X X
X
X
ContactPerson_Cabang
X
X
X
X
ContactPerson_Karyawan
X
X
X X X
X X X
Alamat_Karyawan
X
X
X X X
X X X
Pengawasan
X
X
X X X
X X X
I = Insert, R = Raed, U = Update, D = Delete
123 Tabel 4.36 Cross – referencing transactions and relations (I)-(L) Relasi/Transaksi
(I) I
(J)
R U D I
(K)
R U D I
(L)
R U D I
R U D
GAHeader_Pembelian
X
X X X
X X
X
GADetail_Pembelian
X
X X
X X
X
GAHeader_Pengiriman
X
X
X
X
GADetail_Pengiriman
X
X
X
X
GAHeader_Retur
X
X
X
X X X
GADetail_Retur
X
X
X
X X X
X X
X X
X
X X
GAHeader_Stock
X
X
X
X
GADetail_Stock
X
X
X
X
GASupplier
X
X X
X
X
X X
X
X X
X X
GAHeader_Penerimaan
X
X
X
X
GADetail_Penerimaan
X
X
X
X
GAItemBarang
GACabang
GAUser GAKaryawan
X X X X X X X X X X X X X X X X X X
X X
X X
X X
GAHeader_Permintaan
X
X
X
X X X
GADetail_Permintaan
X
X
X
X X
X X
X X
X X
X X
X X X
X
X X X
X
X X
X
X X
X
GADepartemen GAHeader_Pemakaian GADetail_Pemakaian
124 Relasi/Transaksi
(I) I
(J)
R U D I
R U D I
(K) R U D I
(L) R U D
Pembayaran_Supplier
X
X
X
X
ContactPerson_Supplier
X
X
X
X
ContactPerson_Cabang
X
X
X
X
ContactPerson_Karyawan X X X
X X X
X
X
Alamat_Karyawan
X X X
X X X
X
X
Pengawasan
X X X
X X X
X
X
I = Insert, R = Raed, U = Update, D = Delete
125 Tabel 4.37 Cross – referencing transactions and relations (M)-(P) Relasi/Transaksi
(M) I
(N)
R U D I
(O)
R U D I
(P)
R U D I
R U D
GAHeader_Pembelian
X
X X X
X
X
GADetail_Pembelian
X
X X
X
X
X X X
X X
X
X
X X
X X
X
X
GAHeader_Retur
X
X
X
X
GADetail_Retur
X
X
X
X
X X
X X
X X
X X
GAHeader_Stock
X
X
X
X
GADetail_Stock
X
X
X
X
GASupplier
X
X
X
X
X X
X X
X X
X X
GAHeader_Penerimaan
X
X
X
X
GADetail_Penerimaan
X
X
X
X
GAHeader_Pengiriman GADetail_Pengiriman
GAItemBarang
GACabang
GAUser
X X X X X X X X X X X X X X X X
GAKaryawan
X X
X X
X X
X X
GAHeader_Permintaan
X X
X
X
X
GADetail_Permintaan
X X
X
X
X
GADepartemen
X X
X X
X X
X X
GAHeader_Pemakaian
X
X
X X X
X X X
GADetail_Pemakaian
X
X
X X
X X
126 Relasi/Transaksi
(M) I
(N)
R U D I
R U D I
(O) R U D I
(P) R U D
Pembayaran_Supplier
X
X
X
X
ContactPerson_Supplier
X
X
X
X
ContactPerson_Cabang
X
X
X
X
ContactPerson_Karyawan
X
X X X
X
X
Alamat_Karyawan
X
X X X
X
X
Pengawasan
X
X X X
X
X
I = Insert, R = Raed, U = Update, D = Delete
127 4.2.3.2.2
Pemilihan Organisasi File Tahap ini bertujuan untuk menentukan organisasi file yang efisien untuk setiap relasi dasar. Jenis organisasi file yang digunakan adalah clusters. Pada sistem file komputer, clusters adalah alokasi disk space untuk file dan direktori. Selain itu, clusters juga digunakan untuk mengurangi overhead saat mengatur struktur data pada disk, sistem file tidak dialokasikan individu, tapi berdekatan dengan kelompok sektor, yang disebut clusters. Disk menggunakan 512 byte sektor, 512 byte clusters berisi 1 sektor, 4 kb clusters berisi 8 sektor. Clusters adalah jumlah terkecil pada disk space yang dapat dialokasikan untuk menahan file. M engirim file kecil pada sistem file dengan clusters berukuran besar akan membuat pemborosan disk space, seperti pemborosan disk space yang disebut slack space. Clusters berukuran kecil bila dibandingkan dengan clusters berukuran sedang akan mengakibatkan pemborosan space per file secara statistik yang akan mengurangi setengah dari ukuran clusters; untuk ukuran clusters yang besar,
pemborosan
space
akan
menjadi
lebih
besar.
Walau
bagaimanapun, ukuran clusters yang lebih besar mengurangi fragmentasi, yang mungkin meningkatkan kecepatan membaca dan menulis secara keseluruhan. Rata-rata ukuran jenis clusters mulai dari 1 sektor (512 byte) hingga 128 sektor (64 kb).
128 4.2.3.2.3
Pembuatan Indeks Setiap Entiti Tujuan dari langkah ini adalah untuk meningkatkan performa dari sistem. Penggunaan indeks dapat terlihat pada Lampiran G (Tabel 4.38).
4.2.3.2.4
Sintaks SQL – Data Manipulation Language Tahap
ini dilakukan
untuk
memanggil data-data yang
terkandung dalam database. Adapun sintaks SQL yang digunakan sebagai berikut : 1. Sintaks untuk menampilkan data log in SELECT
kode_User,
password,
nama_Karyawan,
sec_Level
FROM GAUser a, GAKaryawan b WHERE b.kode_Karyawan = a.kode_Karyawan 2. Sintaks untuk menampilkan data permintaan SELECT kode_Permintaan [Kode Permintaan], t gl_Permintaan [Tanggal
Permintaan],
status
FROM
GAHeader_Permintaan
WHERE month(tgl_Permintaan) = '" & M onth(Today) & "' 3. Sintaks untuk menampilkan data stock SELECT deskripsi_ItemBarang, kode_Stock [Kode Stock Barang], tanggal [Tanggal Stock], status [Status], masuk [Barang M asuk], keluar [Barang Keluar], sisa [Barang Keluar], t gl_M utasi [Tanggal M utasi]
FROM
GADetail_Stock
GAHeader_Stock
a,
c
b.kode_ItemBarang
WHERE
GAItemBarang
a.kode_ItemBarang and c.kode_Stock = a.kode_Stock
b, =
129 4. Sintaks untuk menampilkan data supplier SELECT kode_Supplier [Kode Supplier], nama_Supplier [Nama Supplier], jenis_Supply [Jenis Supply], alamat [Alamat], kode_Pos [Kode Pos], kota [Kota], telepon [Telepon], E_M ail [Email], Web_Site [Website], no_Ijin_Usaha [No Ijin Usaha], NPWP, PKP, tgl_M asuk [Tanggal M asuk], Recommended, t gl_Evaluasi [Tanggal Evaluasi]
FROM
GASupplier
a,
ContactPerson_Supplier
b
WHERE a.Kode_Supplier = b.Kode_Supplier 5. Sintaks untuk menampilkan data user SELECT
kode_User
[Kode User],
Karyawan], Sec_Level [Security
nama_karyawan
[Nama
Level] FROM GAUser a,
GAKaryawan b WHERE a.kode_Karyawan = b.kode_Karyawan 6. Sintaks untuk menampilkan data departemen SELECT
kode_Departemen
deskripsi_Departemen
[Nama
[Kode
Departemen],
Departemen], Counter
[Nama
Counter],Section [Nama Section], PPN, deskripsi_Cabang FROM GADepartemen
a,
GACabang b
where
b.kode_Cabang =
a.kode_Cabang 7. Sintaks untuk menampilkan data karyawan SELECT kode_Karyawan [Kode Karyawan], nama_karyawan [Nama Karyawan], deskripsi_Cabang, tgl_M asuk [Tanggal M asuk] FROM GAKaryawan a, GACabang b where b.kode_Cabang = a.kode_Cabang
130 8. Sintaks untuk menampilkan data cabang SELECT kode_Cabang [Kode Cabang], deskripsi_Cabang [Nama Cabang], tanggal_Buka [Tanggal Buka], NPWP, PKP, Alamat, Kota, kode_Pos [Kode Pos], Propinsi, nama_Distrik [Nama Distrik] FROM GACabang 9. Sintaks untuk menampilkan data retur SELECT a.kode_Retur [Kode Retur], kode_ItemBarang [Kode Item Barang], status , jumlah_retur [Jumlah] FROM GAHeader_Retur a,GADetail_Retur b WHERE a.kode_Retur = b.kode_Retur
4.2.3.2.5
Estimasi Disk Space Langkah ini bertujuan untuk memperkirakan kebutuhan disk space yang akan diperlukan oleh database.
Estimasi kebutuhan ini
dilakukan dengan menghitung besar kapasitas disk yang terpakai untuk setiap tabel atau entiti dengan atribut-atribut yang ada didalamnya serta tipe data yang digunakan, antara lain (dapat dilihat pada Lampiran H) :
4.2.3.2.6
Merancang Mekanisme Keamanan Langkah ini bertujuan untuk mendesain ukuran keamanan untuk basis data sebagaimana telah ditentukan oleh user. Ada dua tipe didalam sistem keamanan basis data ini, yaitu : 1. Kemanan sistem, yaitu untuk menangani akses dan penggunaan basis data pada tingkat sistem. Implementasinya adalah dengan menggunakan id dan password.
131 2. Keamanan data, yaitu untuk menangani akses dan penggunaan objek-objek basis data dan aksi-aksi yang bisa dilakukan user terhadap objek-objek tersebut. Implementasinya adalah dengan mekanisme authorization, yaitu mekanisme yang membatasi hakhak akses admin terhadap tabel-tabel di database seperti terlihat di bawah ini. Tabel 4.66 Merancang Mekanisme Keamanan User Tabel
User
Admin
I
R
U
D
I
R
U
D
GAHeader_Pembelian
X
X
X
X
X
X
X
X
GADetail_Pembelian
X
X
X
X
X
X
X
X
GAHeader_Pengiriman
X
X
X
X
X
X
X
X
GADetail_Pengiriman
X
X
X
X
X
X
X
X
GAHeader_Retur
X
X
X
X
X
X
X
X
GADetail_Retur
X
X
X
X
X
X
X
X
GAItemBarang
X
X
X
X
GAHeader_Stock
X
X
X
X
GADetail_Stock
X
X
X
X
GASupplier
X
X
X
X
GACabang
X
X
X
X
GAHeader_Penerimaan
X
X
X
X
X
X
X
X
GADetail_Penerimaan
X
X
X
X
X
X
X
X
X
X
X
X
GAUser
132 User Tabel
User I
R
U
Admin D
GAKaryawan
I
R
U
D
X
X
X
X
GAHeader_Permintaan
X
X
X
X
X
X
X
X
GADetail_Permintaan
X
X
X
X
X
X
X
X
X
X
X
X
GADepartemen GAHeader_Pemakaian
X
X
X
X
X
X
X
X
GADetail_Pemakaian
X
X
X
X
X
X
X
X
Pembayaran_Supplier
X
X
X
X
ContactPerson_Supplier
X
X
X
X
ContactPerson_Cabang
X
X
X
X
ContactPerson_Karyawan
X
X
X
X
Alamat_Karyawan
X
X
X
X
Pengawasan
X
X
X
X
Sintaks untuk implementasi authorization-nya adalah sebagai berikut : •
GAHeader_Pembelian GRANT ALL PRIVILEGES ON GAHeader_Pembelian TO admin GRANT ALL PRIVILEGES ON GAHeader_Pembelian TO user
•
GADetail_Pembelian GRANT ALL PRIVILEGES ON GADetail_Pembelian TO admin GRANT ALL PRIVILEGES ON GADetail_Pembelian TO user
133 •
GAHeader_Pengiriman GRANT ALL PRIVILEGES ON GAHeader_Pengiriman TO admin GRANT ALL PRIVILEGES ON GAHeader_Pengiriman TO user
•
GADetail_Pengiriman GRANT ALL PRIVILEGES ON GADetail_Pengiriman TO admin GRANT ALL PRIVILEGES ON GADetail_Pengiriman TO user
•
GAHeader_Retur GRANT ALL PRIVILEGES ON GAHeader_Retur TO admin GRANT ALL PRIVILEGES ON GAHeader_Retur TO user
•
GADetail_Retur GRANT ALL PRIVILEGES ON GADetail_Retur TO admin GRANT ALL PRIVILEGES ON GADetail_Retur TO user
•
GAItemBarang GRANT ALL PRIVILEGES ON GAItemBarang TO admin
•
GAHeader_Stock GRANT ALL PRIVILEGES ON GAHeader_Stock TO admin
•
GADetail_Stock GRANT ALL PRIVILEGES ON GADetail_Stock TO admin
•
GASupplier GRANT ALL PRIVILEGES ON GASupplier TO admin
134 •
GACabang GRANT ALL PRIVILEGES ON GACabang TO admin
•
GAHeader_Penerimaan GRANT ALL PRIVILEGES ON GAHeader_Penerimaan TO admin GRANT ALL PRIVILEGES ON GAHeader_Penerimaan TO user
•
GADetail_Penerimaan GRANT ALL PRIVILEGES ON GADetail_Penerimaan TO admin GRANT ALL PRIVILEGES ON GADetail_Penerimaan TO user
•
GAUser GRANT ALL PRIVILEGES ON GAUser TO admin
•
GAKaryawan GRANT ALL PRIVILEGES ON GAKaryawan TO admin
•
GAHeader_Permintaan GRANT ALL PRIVILEGES ON GAHeader_Permintaan TO admin GRANT ALL PRIVILEGES ON GAHeader_Permintaan TO user
•
GADetail_Permintaan GRANT ALL PRIVILEGES ON GADetail_Permintaan TO admin GRANT ALL PRIVILEGES ON GADetailPermintaan TO user
135 •
GADepartemen GRANT ALL PRIVILEGE ON GADepartemen TO admin
•
GAHeader_Pemakaian GRANT ALL PRIVILEGES ON GAHeader_Pemakaian TO admin GRANT ALL PRIVILEGES ON GAHeader_Pemakaian TO user
•
GADetail_Pemakaian GRANT ALL PRIVILEGES ON GADetail_Pemakaian TO admin GRANT ALL PRIVILEGES ON GADetail_Pemakaian TO user
•
Pembayaran_Supplier GRANT ALL PRIVILEGES ON Pembayaran_Supplier TO admin
•
ContactPerson_Supplier GRANT ALL PRIVILEGES ON ContactPerson_Supplier TO admin
•
ContactPerson _Cabang GRANT ALL PRIVILEGES ON ContactPerson _Cabang TO admin
•
ContactPerson _Karyawan GRANT ALL PRIVILEGES ON ContactPerson _Karyawan TO admin
136 •
Alamat_Karyawan GRANT ALL PRIVILEGES ON Alamat _Karyawan TO admin
•
Pengawasan GRANT ALL PRIVILEGES ON Pengawasan TO admin
4.2.3.2.7
Encryption Semua informasi yang dapat dibaca oleh kita, secara umum dikatakan sebagai plaintext atau cleartext. Apabila suatu informasi diubah sehingga orang lain tidak membaca informasi tersebut, maka dapat dikatakan bahwa informasi tersebut telah dilakukan proses enkripsi, dan hasil dari proses enkripsi disebut dengan ciphertext. Untuk mengembalikan hasil dari proses enkripsi, maka kita harus melakukan proses yang disebut dengan deskripsi, yaitu mengembalikan text enkripsi menjadi plaintext atau cleartext. Salah satu fungsi sederhana yang digunakan dalam enkripsi adalah pemetaan (n+2) dimana n merupakan numur huruf. Berikut contoh penggunaan fungsi : Kalimat asli : KEAMANAN DATA Hasil
: M GCOCPCP FCVC Sedangkan deskripsi mengandung invers dari fungsi pemetaan
yang digunakan yaitu (n-2).
137 4.2.3.2.8
Denormalization Denormalisasi adalah sesuatu yang berhubungan dengan perbaikan dari hubungan skema yang ada. Suatu hubungan bisa dikatakan denormalisasi apabila terdapat dua hubungan yang digabung menjadi satu
hubungan,
dan
hubungan
baru
tersebut
masih
dinormalisasi tetapi berisi lebih banyak null dibandingkan relasi yang asli. Ada beberapa pendapat yang menghubungkan denormalisasi sebagai fungsi perbaikan.
4.2.3.2.8.1
Menggabungkan relasi one-to-one (1…1) M emeriksa kembali hubungan
one
to
one untuk
menentukan efek penggabungan hubungan-hubungan menjadi satu hubungan. GAKaryawan Æ GAUser
138 4.2.3.2.8.2
Mengurangi join duplikasi atribut non key pada relasi one-tomany (1…*) M engurangi atau mengilangkan gabungan yang sering atau query kritis, berdasarkan keuntungan yang mungkin dihasilkan pada satu penggadaan atau banyak atribut non-key pada gabungan parent dihubungan child pada sebuah hubungan 1 : *.
4.2.3.2.8.3
Mengurangi join duplikasi aribut FK pada relasi one-to-many (1…*) Berdasarkan keuntungan yang mungkin dihasilkan pada sebuah penggandaan atau lebih pada sebuah hubungan atribut foreign key.
Melakukan
Gambar 4.18 Pengurangan join duplikasi atribut FK pada relasi one-tomany (1…*)
139
4.2.3.2.8.4
Mengurangi duplikasi atribut pada relasi many-to-many (*…*) Hubungan *:* dapat dihasilkan dengan menggabungkan tiga hubungan : dua hubungan didapat dari entiti awan dan hubungan baru diperkenalkan kembali anatara hubungan entiti.
4.2.3.2.8.5
Memperkenalkan Repeating Group Repeating group dikeluarkan dari model data logical sebagai hasil keperluan semua entity menjadi form normal pertama. Repeating group dipisahkan menjadi sebua hubungan baru, hubungan 1:* dengan hubungan awal.
140 4.2.3.2.8.6
Menggabungkan tabel look up dengan hubungan dasar Tabel ini merupakan kasus khusus hubungan 1:*. Secara tipikal, tabel look up menghasilkan sebuah kode dan sebuah deskripsi.
4.2.3.2.8.7
Membuat tabel extract Teknik
yang
paling
sering
digunakan
untuk
menghasilkan tabel extract adalah dengan membuat dan mempopulasikan tabel ketika sistem sedang berjalan.
4.2.3.2.8.8
View Pada tahap ini, view dibuat untuk memungkinkan setiap pengguna memiliki tampilan database tersendiri dengan manfaat sebagai berikut : •
M engurangi kerumitan
•
M enyediakan tingkatan keamanan
•
M enyediakan mekanisme untuk mengubah tampilan database
•
M enampilkan struktur database yang konsisten dan tidak berubah walaupun database asal di ubah.
Adapun sintaks view yang digunakan dapat dilihat pada Lampiran I:
141 4.3
Perancangan Sistem
4.3.1
Perancangan Sistem Basis Data Terdistribusi Secara umum, suatu basis data terdistribusi dapat dilihat pada gambar 4.18. Pada gambar tersebut ditunjukkan bahwa pada satu basis data dengan basis data yang lainnya pada jarak yang berjauhan dan dapat terjadi pula bahwa lebih dari dua basis data berada pada lokasi yang sama bahkan pada mesin yang sama menggunakan multi basis data. Dalam membangun Sistem Basis Data persediaan barang, kami merancang Sistem Basis Data PT Toko Gunung A gung Tbk terdistribusi. Rancangan ini dibuat berdasarkan kondisi lapangan adanya pertukaran data antara kantor pusat dengan cabang – cabangnya, atau antara divisi dengan divisi lainnya diluar kota. Data lokal dapat dikelola pada masing – masing site, namun bila diperlukan suatu site dapat mengakses data yang lain yang memerlukan pengaturan batasan wewenang akses yang berlaku. Hal ini seperti terlihat pada Gambar 4.19 :
142
Gambar 4.19 S istem Basis Data Terdistribusi
Berikut ini adalah contoh syntax singkat sistem distribusi data : <WebM ethod()> Public Function viewBarang () As Data.Dataset dim xKoneksi as New SqlConnection("") dim xadapter as new SqlDataAdapter ("Select * from GABarang", xKoneksi) dim xset as New Data.DataSet xadapater.Fill(xset, "Barang") Retur xset End Function
143 4.3.2
Arsitektur Perancangan Multiple Prosesor Shared nothing sebagai proses paralel mencakup multiple processor architecture, yang masing – masing bagian processor merupakan sistem yang lengkap dengan memori sendiri dan disk storage (lihat Gambar 4.20). Arsitektur ini berukuran lebih besar dari pada shared memory dan share disk dan dapat dengan mudah mendukung sebuah processor yang besar, selain itu performance yang optimal ketika ada permintaan data pada penyimpanan lokal.
Gambar 4.20 Shared Nothing
4.4
Perancangan Aplikasi Untuk merancang aplikasi yang diinginkan, diperlukan beberapa langkah yang harus dilakukan, diantaranya adalah melakukan perancangan layar, perancangan program, dan menggambar serta menjelaskan State Transition Diagram (STD).
144 4.4.1
Perancangan S truktur Menu Perancangan
Struktur
M enu
dapat
dilihat
pada
gambar I NP UT
U BAH B A RA N G C AR I
H A P US
I NP UT
U BAH CA B A N G C AR I
H A P US
I NP UT
U BAH D E P A RT E M E N C AR I
H A P US
I NP UT
U BAH M A ST ER
K A RY A W A N C AR I
H A P US
I NP UT
U BAH ST O C K A D M IN
C AR I
H A P US
I NP UT
U BAH S U P P LI E R C AR I
H A P US
I NP UT
L O G IN
M A NA G E R
U BAH US E R C AR I
H A P US
D IS T RI B U S I
I NP UT
P E M A K A IA N
I NP UT
P E M B E LI A N
I NP UT
P E NE R IM A A N
I NP UT
P E RM I NT A A N
I NP UT
RE T UR
I NP UT
D A F T A R S T O CK
C AR I
S UR A T DI S T RI B U S I
C AR I
T RA NS A K S I
KAR YAW AN
S U R A T P E M B E LI A N
C AR I
S U RA T P E NE RI M A A N
C AR I
S U RA T R E T UR
C AR I
L A P O R A N D IS T R IB US I
C AR I
LA P O RA N P E M B E L IA N
C AR I
L A P O RA N P E N E R IM A A N
C AR I
S UR A T & L A P OR A N
L A P O RA N R E T U R
C AR I
U BA H PASS WO R D
U BAH
Gambar 4.21 Perancangan S truktur Menu
berikut
:
145 4.4.2
State Transition Diagram (S TD) State Transition Diagram (STD) merupakan suatu diagram yang menjelaskan tentang alur dari aksi dan reaksi. Penulis menggunakan diagram STD ini untuk memberikan gambaran tentang reaksi yang akan diberikan oleh sistem yang penulis rancang ketika menerima aksi dari pengguna. Berikut adalah STD yang merupakan gambaran tentang alur dari aplikasi jika dijalankan :
Gambar 4.22 S tate Transition Diagram pada Menu Log In
Gambar 4.23 S tate Transition Diagram pada Menu Log Out
146
Gambar 4.24 S tate Transition Diagram pada Menu Utama
147
Gambar 4.25 S tate Transition Diagram pada Menu Master
148
Gambar 4.26 S tate Transition Diagram pada Menu Master Barang
Gambar 4.27 S tate Transition Diagram pada Menu Master Cabang
149
Gambar 4.28 S tate Transition Diagram pada Menu Master Departemen
Gambar 4.29 S tate Transition Diagram pada Menu Master Karyawan
150
Gambar 4.30 S tate Transition Diagram pada Menu Master S tock
Gambar 4.31 S tate Transition Diagram pada Menu Master S upplier
151
Gambar 4.32 S tate Transition Diagram pada Menu Master User
Gambar 4.33 S tate Transition Diagram pada Menu Surat dan Laporan
152
Gambar 4.34 S tate Transition Diagram pada Menu Transaksi
153
Gambar 4.35 S tate Transition Diagram pada Menu Transaksi Distribusi
Gambar 4.36 S tate Transition Diagram pada Menu Transaksi Pemakaian
154
Gambar 4.37 S tate Transition Diagram pada Menu Transaksi Pembelian
Gambar 4.38 S tate Transition Diagram pada Menu Transaksi Penerimaan
155
Gambar 4.39 S tate Transition Diagram pada Menu Transaksi Permintaan
Gambar 4.40 S tate Transition Diagram pada Menu Transaksi Retur
156 4.4.3
Perancangan Input dan Output
4.4.3.1
Perancangan Input Berikut ini merupakan perancangan input secara keseluruhan pada aplikasi yang dibuat, antara lain : Rancangan Halaman Log In Halaman log in digunakan untuk menampilkan halaman menu utama yang aktif. Semua pengguna diharuskan untuk memasukkan data yang diperlukan terlebih dahulu.
Halaman Log In
X
USER ID
PASSWORD
LOG IN
Gambar 4.41 Rancangan Layar Log In
157 Rancangan Menu Utama Pada halaman menu utama menampilkan menu pilihan yang tersedia untuk pengguna. M enu utama yang aktif untuk pengguna dibedakan menjadi 3 bagian antara lain : 1. Admin : semua menu dapat diakses 2. M anager : semua master, transaksi permintaan, surat & laporan, ubah password, log in, log out dapat diakses. 3. Karyawan : semua transaksi kecuali permintaan, ubah password, log in, log out, keluar dapat diakses.
Gambar 4.42 Rancangan Layar Menu Utama
158 Rancangan Halaman Master Barang Halaman M aster Barang menampilkan data barang yang tersedia pada Divisi General Affair pada PT TOKO GUNUNG AGUNG TBK. Pada halaman ini admin atau pun manager dapat menambahkan item barang baru, mengubah data item barang, menghapus data item barang yang telah disimpan sebelumnya.
Gambar 4.43 Rancangan Layar Master Barang
159 Rancangan Halaman Master Cabang Halaman M aster Cabang menampilkan data cabang yang dimiliki oleh PT TOKO GUNUNG AGUNG TBK. Pada halaman ini admin atau pun manager dapat menambahkan data cabang baru yang dimiliki, mengubah data cabang dan menghapus data cabang yang telah disimpan sebelumnya.
Gambar 4.44 Rancangan Layar Master Cabang
160 Rancangan Halaman Master Departemen Halaman M aster Departemen menampilkan data departemen yang ada pada setiap kantor PT TOKO GUNUNG AGUNG TBK baik cabang maupun pusat. Pada halaman ini admin atau manager dapat memasukkan departemen baru yang dimiliki oleh setiap kantor, mengubah data departemen dan menghapus data departemen yang telah disimpan sebelumnya.
Gambar 4.45 Rancangan Layar Master Departemen
161 Rancangan Halaman Master Karyawan Halaman M aster Karyawan menampilkan data karyawan yang bekerja pada PT TOKO GUNUNG AGUNG TBK baik yang di kantor pusat maupun kantor cabang. Pada halaman ini, admin atau pun manager dapat menambahkan data karyawan baru yang bekerja pada PT TOKO GUNUNG AGUNG TBK, mengubah data karyawan dan menghapus data karyawan yang telah disimpan sebelumnya.
Gambar 4.46 Rancangan Layar Master Karyawan
162 Rancangan Halaman Master S tock Halaman M aster Stock menampilkan data stock barang yang terdapat pada divisi General Affair pada PT TOKO GUNUNG AGUNG TBK baik yang di kantor pusat maupun di kantor cabang. Pada halaman ini, admin atau pun manager dapat menambahkan data stock baru yang dimiliki, mengubah data stock dan menghapus data stock yang telah disimpan sebelumnya.
Gambar 4.47 Rancangan Layar Master S tock
163 Rancangan Halaman Master Supplier Halaman M aster Supplier menampilkan data supplier yang bekerja sama dengan PT TOKO GUNUNG AGUNG TBK. Pada halaman ini, admin atau pun manager dapat menambahkan data supplier baru yang bekerja sama dengan PT TOKO GUNUNG AGUNG Tbk, menambahkan data supplier dan menghapus data supplier yang telah disimpan sebelumnya.
Gambar 4.48 Rancangan Layar Master S upplier
164 Rancangan Halaman Master User Halaman M aster User menampilkan data user yang menggunakan program Sistem Basis Data Terdistibusi General Affair pada PT TOKO GUNUNG AGUNG Tbk ini. Pada halaman ini, admin mau pun manager dapat menambahkan data user baru yang menggunakan program ini, mengubah data user dan menghapus data user yang telah disimpan sebelumnya.
Gambar 4.49 Rancangan Layar Master User
165 Rancangan Halaman Transaksi Distribusi Halaman Transaksi Distribusi / Pengiriman mencatat setiap data yang diperlukan untuk melakukan transaksi distribusi / pengiriman barang ke cabang. Admin maupun karyawan dapat menyimpan data transaksi distribusi / pengiriman yang telah dilakukan pada halaman ini.
Gambar 4.50 Rancangan Layar Transaksi Distribusi
166 Rancangan Halaman Transaksi Pemakaian Halaman Transaksi Pemakaian mencatat setiap data yang dibutuhkan untuk melakukan transaksi pemakaian barang. Pada halaman ini, admin mau pun karyawan dapat menyimpan data tersebut.
Gambar 4.51 Rancangan Layar Transaksi Pemakaian
167 Rancangan Halaman Transaksi Pembelian Halaman Transaksi Pembelian mencatat setiap data yang dibutuhkan untuk melakukan transaksi pembelian barang. Admin mau pun karyawan dapat menyimpan data pembelian barang tersebut di halaman ini.
Gambar 4.52 Rancangan Layar Transaksi Pembelian
168 Rancangan Halaman Transaksi Penerimaan Halaman Transaksi Penerimaan mencatat setiap data yang diperlukan untuk melakukan transaksi penerimaan barang baik yang dikirimkan oleh cabang mau pun oleh supplier. Pada halaman ini, admin maupun karyawan dapat menyimpan data tersebut.
Gambar 4.53 Rancangan Layar Transaksi Penerimaan
169 Rancangan Halaman Transaksi Permintaan Halaman Transaksi Permintaan mencatat data pembelian yang diajukan permohonannya untuk membeli barang. Permintaan ini memiliki data yang diperoleh dari cabang. Pada halaman ini, admin atau pun manager dapat meng-approve permintaan ini sehingga dapat dilanjutkan ke transaksi pembelian.
Gambar 4.54 Rancangan Layar Transaksi Pembelian
170 Rancangan Halaman Transaksi Retur Halaman Transaksi Retur mencatat data retur barang yang dibutuhkan untuk melakukan transaksi retur ke supplier. Admin ataupun karyawan dapat menyimpan data retur tersebut di halaman ini.
Gambar 4.55 Rancangan Layar Transaksi Retur
171 Rancangan Halaman Ubah Password Halaman ini digunakan untuk mengubah password yang dimiliki oleh user. Halaman ini dapat digunakan oleh semua pengguna sistem ini yang telah memiliki user ID Halaman Ubah Password
X
PASSWOR D LAMA PASSWOR D BARU
U LAN GI PASSWOR D BARU
SI MPAN
BAT AL
Gambar 4.56 Rancangan Layar Ubah Password
172 Rancangan Halaman S urat dan Laporan Halaman ini digunakan untuk mencari data yang nantinya akan di tampilkan berupa surat dan laporan yang akan di cetak. Halaman Surat da n Laporan
X
JENIS SURAT
V
NO SURAT
V
T ANGGAL AWAL
01 Januari 20 09
V
T ANGGAL AKHIR
01 Januari 20 09
V
CET AK
Gambar 4.57 Rancangan Layar S urat dan Laporan
173 4.4.3.2
Perancangan Output Berikut ini merupakan perancangan output secara keseluruhan pada aplikasi yang dibuat, antara lain : Rancangan Daftar S tock Barang Daftar stock barang menampilkan data stock barang yang terdapat pada divisi General Affair PT TOKO GUNUNG AGUNG TBK.
Gambar 4.58 Rancangan Layar Daftar S tock barang
174 Rancangan Surat Distribusi Barang Surat distribusi barang menampilkan data yang dibutuhkan untuk melakukan transaksi distibusi barang. Surat distribusi ini dapat ditampilkan oleh semua pengguna.
Gambar 4.59 Rancangan Layar S urat Distribusi Barang
175 Rancangan Surat Pembelian Barang Surat pembelian barang menampilkan data yang dibutuhkan untuk melakukan transaksi distibusi barang. Surat pembelian ini dapat ditampilkan oleh semua pengguna.
Gambar 4.60 Rancangan Layar S urat Pembelian Barang
176 Rancangan Surat Penerimaan Barang Surat
penerimaan
barang
menampilkan
data
yang
dibutuhkan untuk melakukan transaksi distibusi barang. Surat penerimaan ini dapat ditampilkan oleh semua pengguna.
Gambar 4.61 Rancangan Layar S urat Penerimaan Barang
177 Rancangan Surat Retur Barang Surat retur barang menampilkan data yang dibutuhkan untuk melakukan transaksi distibusi barang. Surat retur ini dapat ditampilkan oleh semua pengguna.
Gambar 4.62 Rancangan Layar S urat Retur Barang
178 Rancangan Laporan Distrisbusi Barang Laporan Distribusi Barang menampilkan data transaksi distribusi barang yang terjadi pada periode yang telah ditentukan.
Gambar 4.63 Rancangan Layar Laporan Distrisbusi Barang
179 Rancangan Laporan Pembelian Barang Laporan Pembelian Barang menampilkan data transaksi distribusi barang yang terjadi pada periode yang telah ditentukan. Laporan ini dapat ditampilkan oleh semua pengguna.
Gambar 4.64 Rancangan Layar Laporan Pembelian Barang
180 Rancangan Laporan Penerimaan Barang Laporan Penerimaan Barang menampilkan data transaksi distribusi barang yang terjadi pada periode yang telah ditentukan. Laporan ini dapat ditampilkan oleh semua pengguna.
Gambar 4.65 Rancangan Layar Laporan Penerimaan Barang
181 Rancangan Laporan Retur Barang Laporan Retur Barang menampilkan data transaksi distribusi barang yang terjadi pada periode yang telah ditentukan. Laporan ini dapat ditampilkan oleh semua pengguna.
Gambar 4.66 Rancangan Layar Laporan Retur Barang
4.4.2
S pesifikasi Proses Untuk spesifikasi proses pada tiap menu, dapat dilihat pada Lampiran F.
182 4.5
Implementasi Dalam mengimplementasikan rancangan sistem database terdistribusi pada PT Toko Gunung Agung Tbk, penulis menggunakan beberapa alat bantu berupa perangkat keras dan perangkat lunak, berikut akan ditampilkan spesifikasinya.
4.5.1
S pesifikasi Perangkat Keras Berikut ini adalah spesifikasi perangkat keras yang disarankan : 1. Client − Processor Pentium IV − Harddisk 80 Gb 7200 Rpm − M emory 512 M b RAM − M onitor − Network (Kabel, Hub, Switch, dll) − Keyboard − M ouse − Printer
2. Server − Processor
Intel Core 2 Duo
− Harddisk
160 Gb 7200 Rpm
− M emory
1 Gb RAM
− M onitor − Network (Kabel, Hub, Switch, dll)
183 − Keyboard − M ouse
4.5.2
S pesifikasi Perangkat Lunak Berikut ini spesifikasi perangkat lunak yang dibutuhkan untuk mengoperasikan sistem aplikasi database ini : 1. Server Sistem Operasi (OS), SQL server 2000 sebagai back end database. 2. Client Sistem Operasi (OS) menggunakan windows XP2, SQL Client connectivity 2000. 3. Developer Visual Basic .NET 2005, Crystal Report 10.
4.5.3
Jadwal Implementasi Berikut ini adalah tabel yang menggambarkan jadwal implementasi terhadap aplikasi sistem basis data yang diusulkan :
N o
Task Name
1
Interview
2
Analisis Sistem yang Berjalan P erancang an Konseptu al P erancang an
3
4
Start
Finis h
17/0 8/08 26/0 8/08
25/0 8/08 21/0 9/08
22/0 9/08
30/0 9/08
01/1 0/08
24/1 0/08
Aug 2008 1 2 7 4
Sep 08 1
8 1 5
Oct 08 2 2
2 9
7 1 4
Nov 08 2 1
2 4 1 8 1
Dec 08 1 2 8 5
2 9 1 6
Jan 09 2 3
3 0
6 1 3
184 Logikal 5 6
7 8 9 1 0
P erancang an Fisikal P erancang an Aplikasi P emrogra man Testing Implemen tasi P elatihan P engguna
25/1 0/08 15/1 1/08
14/1 1/08 20/1 1/08
21/1 0/08 17/1 2/08 26/1 2/09 04/0 1/09
16/1 2/08 25/1 2/09 03/0 1/09 10/0 1/09
Gambar 4.67 Jadwal Implementasi
Implementasi Sistem Basis Data Penerapan sistem basis data dimulai dari suatu kebutuhan informasi yang tersedia untuk operasi bisnis. Oleh sebab itu penerapan sistem baru harus mampu mendukung kebutuhan informasi saat melakukan transaksi dalam bisnis PT Toko Gunung Agung Tbk, dalam menjamin kelengkapan informasi dilakukan prosedur seperti gambar 4.68. •
Pengembangan Lingkungan pengembangan menyajikan lahirnya sistem informasi. Dalam lingkungan pengembangan, semua objek basis data pada awalnya dibuat, script dikembangkan, relasi dibentuk, dan aplikasi dikembangkan. Tidak ada batas waktu pengembangan, selain bergantung pada batasan terhadap kejadian yang penting dan batas waktu yang harus ditemukan dalam rencana perancangan.
185 •
Tes Selama pengujian, basis data dan antarmuka aplikasi basis data diuji dalam keseluruhan kemampuan dan ketelitian. Basis data juga diuji dalam kinerja, terutama jika basis data tersebut merupakan kunci yang berhubungan dengan pelanggan ketika kebutuhan sistem sudah dibentuk.
•
Produksi Produksi adalah titik dimana basis data dan aplikasi yang dibuat tersedia bagi pengguna akhir. Tugas riil terpenuhi di lingkungan produksi yang secara langsung mempengaruhi cara bisnis beroperasi. Pemakai riil bekerja dengan data riil, dan interfacing dengan pelanggan riil.
Gambar 4.68 S iklus Hidup Basis Data
186 4.5.4
Kebutuhan Personil (Brainware) Untuk dapat mengimplementasikan sistem database terdistribusi pada PT Gunung Agung Tbk yang dirancang dibutuhkan spesifikasi brainware sebagai berikut : ¾ Database Administrator (DBA), yaitu orang yang bertanggung jawab untuk mengorganisasikan dan memelihara database ¾ Personil entry data dalam setiap bagian adalah seseorang yang bertanggung jawab untuk maintenance data seperti addition, update, deletion ¾ Technical support adalah seseorang yang bertugas untuk membangun, merawat, dan mengembangkan jaringan, dalam hal ini harus mampu mengatasi masalah – masalah yang berhubungan dengan jaringan ¾ EDP (Entry Data Processing) adalah seseorang yang bertugas atas segala hal yang berhubungan dengan software maupun hardware dan bertanggung jawab terhadap kelangsungan pemrosesan data.
4.5.5
Petunjuk Pemakaian Sistem Pada sub bab ini akan dijelaskan mengenai cara penggunaan program yang akan diterapkan pada PT Toko Gunung Agung Tbk.
187 HALAMAN LOG IN Halaman log in menampilkan data yang diperlukan untuk membuka akses pengguna. Pada halaman log in ini data pengguna akan divalidasikan sehingga menu yang aktif antara pengguna yang satu dengan yang lainnya berbeda sesuai dengan hak akses yang diberikan kepada masing - masing pengguna. Tampilan halaman log in sebagai berikut :
Gambar 4.69 Tampilan Halaman Log In
188 HALAMAN UBAH PASS WORD Halaman ubah password digunakan untuk pengguna yang telah melakukan log in yang ingin mengubah data password dirinya sendiri. Pada halaman ini terdapat tombol “SIM PAN” untuk memanggil fungsi agar data yang telah diubah disimpan ke dalam data yang bersangkutan sesuai dengan yang dimasukkan. Tampilan halaman ubah password sebagai berikut :
Gambar 4.70 Halaman Ubah Password
189 HALAMAN MAS TER BARANG Halaman master barang digunakan untuk menampilkan data barang yang terdapat pada General Affair PT TOKO GUNUNG AGUNG Tbk. Pengguna yang memiliki akses untuk halaman master barang ini dapat menambahkan data barang baru yang ingin dimasukkan ke dalam data yang bersangkutan. Selain itu, pengguna dapat mengubah data barang yang telah ada sebelumnya dan menghapus data barang yang tidak diperlukan lagi. Tampilan halaman master barang sebagai berikut :
Gambar 4.71 Halaman Master Barang
190 HALAMAN MAS TER CABANG Halaman master cabang digunakan untuk menampilkan data yang berhubungan dengan cabang yang dimiliki oleh PT TOKO GUNUNG AGUNG Tbk. Pada halaman master cabang ini, pengguna yang memiliki akses dapat menambahkan data cabang baru, mengubah data cabang yang telah disimpan sebelumnya sesuai dengan kebutuhan dan menghapus data cabang yang tidak diperlukan lagi. Tampilan halaman master cabang sebagai berikut :
Gambar 4.72 Halaman Master Cabang
191 HALAMAN MAS TER DEPARTEMEN Halaman master departemen digunakan untuk menampilkan data yang berhubungan dengan departemen yang dimiliki oleh setiap kantor baik pusat maupun cabang PT TOKO GUNUNG AGUNG Tbk. Di dalam master departemen ini, terdapat fungsi untuk menambahkan data departemen baru yang ingin disimpan informasi, mengubah data departemen yang telah tersimpan sebelumnya dan menghapus data departemen yang tidak dibutuhkan lagi. Tampilan halaman master departemen sebagai berikut :
Gambar 4.73 Halaman Master Departemen
192 HALAMAN MAS TER KARYAWAN Halaman master karyawan digunakan untuk menampilkan biodata karyawan yang bekerja pada PT TOKO GUNUNG AGUNG Tbk di tiap masing – masing kantor. Halaman master karyawan ini oleh pengguna yang mempunyai akses untuk halaman ini dapat ditambahkan datanya sesuai dengan yang dibutuhkan, diubah data sebelumnya dan dihapus datanya yang sudah tidak diperlukan lagi. Tampilan halaman master karyawan sebagai berikut :
Gambar 4.74 Halaman Master Karyawan
193 HALAMAN MAS TER S UPPLIER Halaman master supplier digunakan untuk menampilkan informasi yang berhubungan dengan supplier – supplier yang bekerja sama dengan PT TOKO GUNUNG AGUNG Tbk. Pengguna yang memiliki akses halaman ini dapat menambahkan data supplier baru yang bekerja sama dengan perusahaan, mengubah data yang sebelumnya telah disimpan sesuai dengan kebutuhannya dan juga dapat menghapus data supplier yang tidak diperlukan lagi. Tampilan halaman master supplier sebagai berikut :
Gambar 4.75 Halaman Master S upplier
194 HALAMAN MAS TER S TOCK Halaman master stock digunakan untuk menampilkan data stock barang pakai yang berada pada General Affair. Pada halaman ini dapat menambahkan data stock baru, mengubah data yang telah ada dan menghapus data yang tidak diperlukan. Tampilan halaman master stock sebagai berikut :
Gambar 4.76 Halaman Master S tock
195 HALAMAN MAS TER US ER Halaman master user digunakan untuk menampilkan data pengguna yang berhak menggunakan sistem ini. Data yang ada pada halaman ini dapat ditambahkan, diubah dan dihapus sesuai dengan kebutuhan. Tampilan halaman master user sebagai berikut :
Gambar 4.77 Halaman Master User
196 HALAMAN TRANS AKS I DIS TRIBUS I Halaman transaksi distribusi digunakan untuk mencatat informasi yang dibutuhkan pada proses transaksi distribusi. Selain itu, pada halaman ini ditampilkan data – data transaksi distribusi yang telah dilakukan pada bulan dimana pengguna mengaksesnya. Halaman ini juga menampilkan surat distirbusi yang dapat dicetak sebagai surat pengiriman kepada cabang tujuan. Tampilan halaman transaksi distirbusi sebagai berikut :
Gambar 4.78 Halaman Transaksi Distribusi
197 HALAMAN TRANS AKS I PEMAKAIAN Halaman transaksi pemakaian digunakan untuk mencatat informasi yang dibutuhkan pada saat sebuah departemen memberikan permohonan pemakaian barang kepada general affair. Pada halaman ini, terdapat juga fasilitas untuk mengubah status pembelian yang sudah realisasi menjadi closed sehinggan barang. Perubahan status ini menjelaskan bahwa barang tersebut sudah masuk ke dalam stock sehingga terjadi update stock barang. Tampilan halaman transaksi pemakaian sebagai berikut :
Gambar 4.79 Halaman Transaksi Pemakaian
198 HALAMAN TRANS AKS I PEMBELIAN Halaman transaksi pembelian digunakan untuk mencatat informasi yang dibutuhkan pada proses pembelian. Tampilan transaksi pembelian sebagai berikut :
Gambar 4.80 Halaman Transaksi Pembelian
199 HALAMAN TRANS AKS I PENERIMAAN Halaman transaksi penerimaan digunakan untuk mencatat informasi mengenai barang yang diterima. Pada halaman ini dibedakan antara penerimaan dari supplier dan dari cabang yang mengirim. Pada penerimaan dari supplier dibedakan lagi penerimaan barang dari pembelian yang barangnya belum data atau penerimaan barang dari retur barang. Tampilan halaamn transaksi penerimaan sebagai berikut :
Gambar 4.81 Halaman Transaksi Penerimaan
200 HALAMAN TRANS AKS I PERMINTAAN Halaman master permintaan digunakan untuk menampilkan data pembelian yang berstatus belum diproses dan sedang diproses. Status yang seperti itu masuk ke dalam permintaan. Halaman ini hanya dapat diakses oleh menager. Tampilan transaksi permintaan sebagai berikut :
Gambar 4.82 Halaman Transaksi Permintaan
201 HALAMAN TRANS AKS I RETUR Halaman master retur mencatat informasi yang dibutuhkan untuk melakukan proses retur. Selain itu, pada halaman ini ditampilkan data retur yang telah dilakukan pada bulan dimana mengakses sistem ini. Tampilan halaman transaksi retur sebagai berikut :
Gambar 4.83 Halaman Transaksi Retur
202 HALAMAN S URAT & LAPORAN Halaman surat dan laporan menampilkan pilihan – pilihan yang ingin ditampilkan oleh pengguna baik itu surat maupun laporan. Tampilan halaman surat & laporan sebagai berikut :
Gambar 4.84 Halaman S urat & Laporan
203 Tampilan Halaman Laporan Distribusi Barang :
Gambar 4.85 Halaman Laporan Distribusi Barang
204 Tampilan Halaman Laporan Pembelian Barang :
Gambar 4.86 Halaman Laporan Pembelian Barang
205 Tampilan Laporan Stock Barang :
Gambar 4.87 Laporan S tock Barang
206 Tampilan Halaman Surat Distribusi :
Gambar 4.88 Halaman S urat Distribusi Barang
207 Tampilan Halaman Surat Penerimaan Barang :
Gambar 4.89 Halaman S urat Penerimaan Barang
208 Tampilan Halaman Surat Retur Barang :
Gambar 4.90 Halaman S urat Retur Barang
209 4.5.6
Respon Perusahaan Terhadap Implementasi Sistem Setelah basis data baru ini diterapkan pada PT Gunung Agung Tbk, maka didapatkan sebuah hasil dari 30 kuis ioner yang dibagikan kepada pihak karyawan perusahaan. Dari tanggapan-tanggapan tersebut, dapat disimpulkan bahwa basis data ini membantu perusahaan dalam melakukan aktivitas seharihari. Kesimpulan yang dapat ditarik dari kuisioner : 1. Tampilan User - Friendly Persentase Jawaban User Tidak Bagus
Sangat Bagus Cukup Bagus Tidak Bagus
10% Cukup Bagus
Sangat Bagus 50%
40% Gambar 4.91 Tampilan User-Friendly
Sebanyak 50% user menjawab bahwa tampilan dari aplikasi ini sudah Userfriendly, karena mereka pada umumnya telah menemukan kemudahan dalam memakai aplikasi ini, seperti perintah-perintah untuk menjalankan operasi. Sebesar 40 % lainnya mengatakan aplikasi ini cukup user-friendly, tetapi terkadang mereka masih menemukan kesulitan dalam menggunakannya, sehingga masih butuh waktu untuk mempelajari sistem baru ini. Sedangkan
210 sisanya 10 % masih menemukan kesulitan karena pengetahuan tentang teknologi informasi masih kurang sehingga butuh pelatihan lebih lanjut.
2. Memiliki informasi yang lengkap dalam memenuhi kebutuhan pemakai.
Persentase Jawaban User
Tidak Lengkap 7% Cukup Lengkap 37%
Lengkap Cukup Lengkap Tidak Lengkap
Lengkap 56%
Gambar 4.92 Evaluasi Perolehan Informasi
Sebanyak 56% user menjawab bahwa informasi yang diberikan sudah memenuhi kebutuhan dan lengkap. Sebanyak 37% user menjawab bahwa informasi yang diberikan cukup lengkap, tapi terkadang mereka sering menemukan kesulitan dalam mengakses informasi tersebut, sedangkan user yang mengatakan informasi masih tidak lengkap sebanyak 7 %.
211 3. Penerapan aplikasi sistem basis data Persentase Jawaban User Sangat Membantu Cukup Membantu Tidak Membantu 3% Cukup Membantu 47%
Tidak Membantu
Sangat Membantu 50%
Gambar 4.93 Evaluasi Manfaat Dari Aplikasi
Sebanyak 50% user menjawab aplikasi ini sangat membantu, sehingga dapat disimpulkan bahwa aplikasi sistem basis data ini secara keseluruhan sangat membantu user dalam kegiatan sehari-hari.
4. Pelatihan penerapan aplikasi Persentase Jawaban User Sangat Diperlukan Diperlukan Tidak Diperlukan
Tidak Diperlukan
10% Sangat Diperlukan Diperlukan
50%
40% Gambar 4.94 Evaluasi Kebutuhan Pelatihan Aplikasi
212 Sebanyak 50% user menjawab pelatihan untuk penggunaan aplikasi ini sangat diperlukan sehingga dapat disimpulkan bahwa kebutuhan pelatihan aplikasi sistem basis data terdistribusi ini bagi user secara keseluruhan sangat diperlukan user untuk menggunakan aplikasi ini dengan baik.
4.5.7
Evaluasi Sistem Pada tahap ini sistem basis data yang telah dirancang akan diuji dan dievaluasi. Berikut ini adalah beberapa aspek yang dievaluasi beserta hasil dari evaluasi tersebut. Tabel 4.67 Tabel evaluasi perubahan sistem Sebelum Penerapan Sistem M embutuhkan
waktu
yang
Sistem Baru lebih M embutuhkan waktu yang sangat
banyak untuk mengetahui sisa barang singkat tanpa harus menghubungi karena harus
menghubungi pihak pihak gudang terlebih dahulu.
gudang terlebih dahulu. M embutuhkan banyak
untuk
tempat
yang
menyimpan
lebih Tidak lagi memakan tempat karena berkas disimpan dalam komputer
transaksi dan data lainnya Data tidak cocok dan kurang akurat
Data menjadi lebih akurat karena sekali mengupdate data, data yang terkait secara otomotis akan ikut terupdate
213
Sebelum Penerapan Sistem
Sesudah Penerapan Sistem
Data yang tersedia sulit menunjukkan Data menjadi lebih real time karena data yang up to date akibat dari menggunakan sistem basis data yang penyimpanan
data pada beberapa terintegrasi.
tempat. Keamanan data kurang terjaga karena Adanya resiko data hilang akibat data dimasukkan dalam file cabinet
gangguan pada hardware, sehingga
sehingga mudah terjadi kerusakan perlu diterapkan sistem backup dan kertas akibat gangguan alam atau recovery pada data binatang
4.5.7.1
Kepuasan User Setelah basis data baru ini diterapkan pada PT Gunung A gung Tbk, maka dilakukanlah wawancara dengan staf IT yang menggunakan aplikasi tersebut. Dari hasil wawancara tersebut dapat disimpulkan bahwa basis data dan apliaksi ini berhasil membantu mereka menjalankan tugasnya masingmasing.
4.5.7.2
Integritas Integritas ini adalah untuk memastikan bahwa setiap kolom yang berupa key pada relasi telah memiliki data yang unik, dan setiap relasi sudah memiliki primary key. Sehingga user tidak dapat memberikan nilai
214 null pada field tersebut. Setiap data yang dimasukkan oleh user, dipastikan sesuai dengan tipe data pada field dalam relasi tersebut. Hasil dari evaluasi integritas ini menunjukkan bahwa dari semua tabel yang telah dilakukan pengujian, semuanya telah memenuhi aturan.
Primary Key (Entity Integrity) Evaluasi entity integrity dimaksudkan untuk menguji apakah setiap tabel yang diuji pada primary key tidak diperbolehkan ’NULL’ dan untuk yang strong entity tidak diperbolehkan memiliki dua (2) record yang sama pada primary key. Hasil dari evaluasi entity integrity menunjukkan bahwa dari semua tabel yang telah dilakukan pengujian, kesemuanya telah memenuhi aturan.
Foreign key (Referential Integrity) Evaluasi referential integrity dimaksudkan untuk menguji apakah setiap tabel yang diuji telah dapat merujuk ke tabel lain yang saling berhubungan. Hasil dari evaluasi referential integrity menunjukkan bahwa dari semua tabel yang telah dilakukan pengujian, kesemuanya telah memenuhi aturan.
Domain Integrity Evaluasi domain integrity dimaksudkan untuk menguji apakah atribut yang diuji telah sesuai dengan domain yang dimaksudkan.
215 Hasil dari evaluasi domain integrity menunjukkan bahwa semua tabel yang telah dilakukan pengujian, domain integrity-nya telah tepat, hal ini dibuktikan dengan mencoba memasukkan data dengan tipe dan panjang yang berbeda maka data tersebut tidak dapat masuk ke basis data.
4.5.7.3
Security Pada tahap ini dilakukan pengujian terhadap keamanan basis data. Rancangan aplikasi dimulai dengan memasukkan user tiap karyawan dan juga passoword, sehingga pihak lain yang tidak berkepentingan tidak berhak untuk membuka dan melihat data perusahaan tersebut. Selain kemanan pada aplikasi juga terdapat keamanan pada DBM S yang secara langsung sudah didapat karena menggunakan SQL, dalam bentuk GRANT (hak akses). Hasil dari evaluasi ini, bila user id dan password sesuai, maka user baru dapat memasuki sistem. Hal ini membuktikan bahwa keamanan terhadap aplikasi sudah terbukti.
4.5.7.4
Concurrency DBM S harus menyediakan mekanisme untuk memastikan database secara benar pada saat banyak user yang mengupdate secara bersamaan. Akses secara benar relatif mudah apabila user hanya membaca. Tetapi akan menjadi masalah apabila dua atau lebih user mengakses database secara bersamaan dan salah satu dari mereka mengupdate data maka akan menghasilkan data yang tidak konsisten.
216 Hasil dari evaluasi dari sistem ini, data baru yang akan dimasukkan atau dihapus akan secara langsung mengubah database, sehingga database yang di update selalu up to date.
4.5.7.5
Back Up dan Recovery Sebuah DBM S sebaiknya menyediakan fasilitas back up untuk membantu recovery akan kesalahan pada database. Amat disarankan untuk membuat cadangan back up database dan log file pada jarak waktu tertentu dan dapat dipastikan cadangan tersimpan pada lokasi yang aman. Untuk mengantisipasi terjadinya kerusakan ataupun kehilangan data pada basis data yang disebabkan oleh kecelakaan – kecelakaan tak terduga yang mungkin saja terjadi setiap saat, maka data harus di back up yang dilakukan oleh pegawai Divisi General Affair PT Toko Gunung Agung Tbk. Hasil dari evaluasi adalah database pada PT Toko Gunung A gung Tbk telah memiliki back up dengan perincian sebagai berikut :
Tabel 4.68 Media Back Up Tabel
M edia Back Up
Waktu Back Up
GAKaryawan GASupplier GAUser GACabang GADepartemen
CD RW
Satu bulan sekali
217 Tabel GAItemBarang
M edia Back Up
Waktu Back Up
CD RW
Seminggu sekali
CD RW
Tiap hari pukul
GAStock GAPembelian GAPermintaan GAPemakaian
17.00 CD RW
Dua minggu Sekali
CD RW
Satu minggu sekali
GAPengiriman GAPembayaran GARetur