PENGARAHAN DAN PENGEMBANGAN ORGANISASI (KEPEMIMPINAN)

SINAR ELEKTRONIK FAKTUR PENJUALAN Jl. Pemuda 80 Kebumen, Telp 0287-3833333 Tuan :………………….. Tanggal : 08/02/2008 Nomor : P001
Kode	Nama Barang	Qty	Harga	Jumlah
A01	AC LG SPLIT ½ PK	2	2.500.000	5.000.000
A02	AC LG SPLIT 1 PK	1	3.500.000	3.500.000
Total Faktur				8.500.000

Kasir

Yuliani

Dari dua dokumen di atas terlihat ada dua transaksi yang dijalankan, yaitu transaksi pembelian barang dan kemudian transaksi penjualan barang. Untuk mengawali pekerjaan Cipluspun mulai membuat table dengan merencanakannya dengan teknik normalisasi. Dimulai dari pembelian dengan membuat tabelnya dengan bentuk tidak normal/unnormalied.

1. Step 1 bentuk unnormalized

Pada bentuk table unnormalized maka CIplus mencantumkan semua field yang ada sehingga bentuknya seperti berikut :

HTML clipboard

No Nota	Kode Supp	Nama Sup	Alamat	Telp	Kode Brg	Nama Barang	Tanggal	Qty	Harga	Jumlah	Total
B001 B005	G01 G02	GOBEL NUSANTARA SANTA ELECTRA	JAKARTA JOGJAKARTA	021888888 0274934234	A01 A02 A03 A01	AC LG SPLIT 1/2 PK AC LG SLIPT 1 PK AC LG SPLIT 2 PK AC LG SPLIT 1/2 PK	07/02/2008 08/02/2008	40 10 5 10	2000000 3000000 4000000 1500000	80000000 30000000 20000000 15000000	130000000 15000000

Dari table di atas tampak bila ada data yang double atau sama, maka datanya tidak perlu ditulis kembali.

2. Step 2 bentuk normal kesatu

Untuk menjadikan table dari table unnormalized menjadi bentuk normal kesatu dengan cara :

1.     memisahkan data pada field-field yang tepat dan bernilai atomic, artinya sudah seluruh field harus sudah merupakan field yang tidak bisa dipecahl lagi

2.     seluruh record harus lengkap

sehingga hasilnya menjadi seperti berikut :

No Nota	Kode Supp	Nama Sup	Alamat	Telp	Kode Brg	Nama Barang	Tanggal	Qty	Harga	Jumlah	Total
B001 B001 B001 B005	G01 G01 G01 G02	GOBEL NUSANTARA GOBEL NUSANTARA GOBEL NUSANTARA SANTA ELECTRA	JAKARTA JAKARTA JAKARTA JOGJAKARTA	021888888 021888888 021888888 0274934234	A01 A02 A03 A01	AC LG SPLIT 1/2 PK AC LG SLIPT 1 PK AC LG SPLIT 2 PK AC LG SPLIT 1/2 PK	07/02/2008 07/02/2008 07/02/2008 08/02/2008	40 10 5 10	2000000 3000000 4000000 1500000	80000000 30000000 20000000 15000000	130000000 130000000 130000000 15000000

Dari contoh table di atas tampaklah bahwa ada beberapa kelemahan pada table tersebut, yaitu :

1. Inserting/penyisipan

Artinya Ciplus tidak bisa memasukkan supplier baru, kalau Ciplus tidak melakukan transaksi pembelian.

2. Deleting/Penghapusan

Bila satu record dihapus maka akan menghapus data yang lain juga, contohnya bila No Nota B005 dihapus maka berakibat menghapus data supplier G02, padahal supplier tersebut masih diperlukan.

3. Updating/Pengubahan

No Nota, Kode Supplier, Nama Supplier, Alamat, Telp dan Tanggalkelihatan ditulis berulang-ulang sehingga bila terjadi perubahan nama supplier misalnya, maka harus menggantinya disemua record yang mengandung hal tersebut. Bila ada yang terlewat maka akan mengakibatkan data tidak konsisten lagi.

4. Redudancy

Field jumlah di atas merupakan field yang redundancy, karena setiap kali harga dikalikan dengan qty akan menghasilkan jumlah. Mestinya field jumlah tersebut dibuang, karena jika ada perubahan data harga atau qty maka jumlah tidak akan mengikuti. Sehingga mengakibatkan data menjadi tidak konsisten. Begitu juga Total, ini juga field yang redundancy.

3. Step 3 bentuk normal kedua

Melihat table yang ada pada bentuk normal kesatu dan melihat masalah-masalah yang ada, maka untuk menyusun table di atas menjadi table bentu normal kedua, diperlukan adanya kunci primer. Kunci primer tersebut dicari dengan mencari kebergantungan fungsional field-field lain terhadap kunci tersebut. Maka untuk menentukannya Ciplus mulai berfikir.

1. No nota bergantung kepada siapa ? tidak bergantung kepada siapa-siapa

2. Kode supplier bergantung kepada siapa ? tidak bergantung kepada siapa-siapa

3. Nama Supplier, Alamat, No telp bergantung kepada siapa ? jelas bergantung kepada Kode Supplier, berarti Kode Supplier menjadi kunci primer dalam sebuah table, misalnya nama tabelnya adalah TBSupplier

4. Kode barang bergantung kepada siapa ? tidak bergantung kepada siapa-siapa

5. Nama barang bergantung kepada siapa ? bergantung kepada Kode Brg, sehingga Kode Brg menjadi kunci primer pada table TBBarang

6. Tanggal, Qty, Harga, Jumlah, dan Total bergantung kepada siapa ? bergantung kepada No Nota, pada saat no nota tersebut dikeluarkan ya pada saat itu pula ditentukan Tanggal keluarnya nota, Quantitynya, Harga barangnya (kecuali harga barang sudah pasti tidak berubah bisa tidak bergantung pada No Nota), Jumlah, dan Total yang dikeluarkan juga saat nota dibuat.

Sehingga kalau direlasikan bentuknya menjadi seperti berikut :

Dengan pemecahan seperti di atas maka permasalahan inserting, updating, deleting sudah bisa dipecahkan, jadi Ciplus bisa memasukkan data supplier baru kapanpun tanpa harus melakukan transaksi pembelian, demikian pula untuk update dan delete.

Namun masih ada masalah pada table Nota, yaitu :

1.     Field Qty dan Harga tidak bergantung penuh kepada kunci primer No nota, ia juga bergantung fungsi terhadap kode barang, hal ini disebut dengan ketergantungan yang transitif dan haruslah dipisahkan menjadi dua table.

2.     Masih terdapat redundancy yaitu setiap kali terjadi transaksi, jika barang yang dibeli lebih dari satu, maka no nota juga harus ditulis lebih dari satu, sehingga harus dipisahkan.

Untuk lebih jelasnya pada table Nota seperti berikut :

No Nota	Kode Supp	Kode Brg	Tanggal	Qty	Harga	Jumlah	Total
B001 B001 B001 B005	G01 G01 G01 G02	A01 A02 A03 A01	07/02/2008 07/02/2008 07/02/2008 08/02/2008	40 10 5 10	2000000 3000000 4000000 1500000	80000000 30000000 20000000 15000000	130000000 130000000 130000000 15000000

Kelihatan sekali No Nota ditulis berkali-kali, ini yang disebut dengan redundancy. Untuk itu tahap merencanakan database ini belum selesai. Tampaknya Ciplus masih harus melanjutkan lagi ke tahap normal ketiga

4. Step 4 bentuk normal ketiga

Pada step 4 ini, normal ketiga mempunyai syarat bahwa setiap table tidak mempunyai field yang bergantung transitif, harus bergantung penuh pada kunci utama. Maka permasalahan pada table Nota tersebut harus harus dipecah lagi tabelnya menjadi seperti berikut (lansung ditampilkan dalam bentuk relasi di MS Access):

Dari gambar di atas bisa dilihat ada TBNota dan ada TBTranBeli, jadi jika dilihat datanya pertabel adalah seperti berikut :

Sampai tahap ini rancangan database untuk pembelian sudah jadi, namun bagaimana dengan penjualannya, apakah harus dibuat terpisah atau menjadi satu database dengan pembelian ? melihat Faktur penjualan didalamnya terdapat Kode Barang Nama Barang maka sebaiknya Databasenya menjadi satu, karena barang yang dijual ke konsumen juga barang yang dibeli dari supplier. Sehingga jika Ciplus mengacu pada langkah-langkah normalisasi tentunya hasilnya menjadi seperti berikut relasinya 

:

Ciplus mencoba untuk menyajikan datanya senjadi seperti berikut :

Daftar Pustaka :
https://jingklak.wordpress.com/2009/03/30/penerapan-normalisasi-pada-jual-beli/