Penerapan Normalisasi pada Jual Beli

March 30, 2009 at 2:58 am 2 comments

Membaca artikel ini dengan online diblog ini bisa atau didownload saja.

Ciplus punya toko dengan nama Ciplus Elektronik Center, selama ini dalam melakukan transasi di toko Ciplus beserta karyawannya melakukannya secara manual, menggunakan nota yang ditulis dengan tangan, di paraf dan dikeluarkanlah barang yang dibeli konsumen. Semakin lama toko Ciplus semakin maju, semakin berkembang, semakin banyak konsumen, semakin banyak karyawan, semakin banyak pula transaski yang dilakukan. Lama-lama Ciplus stress dengan begitu banyaknya administrasi yang harus dilakukan. Kadang Ciplus kesulitan dalam membutuhkan data

  1. Berapa Sih stok AC LG Split ½ PK yang ada sekarang ?
  2. Berapa sih pendapatan 1 bulan terakhir ini ?
  3. Berapa sih keuntungannya dalam 1 bulan ini ?
  4. Apa saja yang perlu dibeli lagi ? alias harus kulakan apalagi ?
  5. Barang apa sih yang paling laku ?

Dan seabreg pertanyaan itu terkumpul setiap saat di benak Ciplus, sayangnya Ciplus tidak bisa mendapatkan jawabannya dalam waktu cepat. Kadang Ciplus harus meminta karyawannya untuk menghitungkan. Bahkan Ciplus sendiri yang harus menghitungnya. Lama-lama Ciplus merasa lelah, Capeeeek dechhhh. Banyak duit tapi capek. Wah punya harta kok ndak bisa menikmati. Wah sungguh malang nasibku. Ciplus Ciplus????? Oh Tuhan tolonglah hambamu ini. Ciplus adalah saudagar kaya alumni D3 komputer. Masa CIplus ndak bisa, mulailah Ciplus berfikir wah aku harus bikin program database nih, aku sangat butuh database. Mulailah Ciplus berfikir untuk merancang database. Wah harus dimulai dari mana ya? Oh ya mulai dahulu dari documen-dokumen yang ada. Si Ciplus pun mengambil contoh faktur pembelian dan penjualan seperti berikut :

PT SANTA PURI FAKTUR PEMBELIAN BARANG

Jalan Senopati 11

Yogyakarta

Kode Supplier : G01 Tanggal : 07/02/2008

Nama Supplier : Gobel Nustra Nomor : B001

Kode

Nama Barang

Qty

Harga

Jumlah

A01

AC LG SPLIT ½ PK

10

2.000.000

20.000.000

A02

AC LG SPLIT 1 PK

10

3.000.000

30.000.000

A03

AC LG SPLIT 2 PK

5

4.000.000

20.000.000

Total Faktur

70.000.000

SANTA ELECTRA FAKTUR PEMBELIAN BARANG

Jalan Kenangan 11

Jakarta

Kode Supplier : G02 Tanggal : 08/02/2008

Nama Supplier : Santa Electra Nomor : B005

Kode

Nama Barang

Qty

Harga

Jumlah

A01

AC LG SPLIT 1/2 PK

40

2000000

800000000

A02

AC LG SLIPT 1 PK

10

1500000

15000000

A03

AC LG SPLIT 2 PK

5

4000000

20000000

Total

835000000

Sedangkan untuk contoh faktur penjualannya seperti berikut :

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 Tanggal kelihatan 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 :

        jual2

        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):

        image008

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

        jual3

        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 :

        jual1

        Ciplus mencoba untuk menyajikan datanya senjadi seperti berikut :

        jual4

        Sampai disini Ciplus berhenti dulu, dah capek mikirnya. Masih ada lagi yang perlu dipikirkan, yaitu mikirin bikin laporannya. Santai dulu ah

        Entry filed under: Database. Tags: .

        TRIK MENGERJAKAN SKILL EXAM JENI 3 Login di jual beli

        2 Comments Add your own

        • 1. CahKbm  |  May 7, 2009 at 2:51 am

          Siip Mas bagi-bagi ilmunya, yakin bermanfaat

          Reply
        • 2. Login di jual beli « Jingklak’s Weblog  |  May 14, 2009 at 8:55 am

          […] ini ada kelanjutan dari artikel saya sebelumnya,  database juga sudah saya sertakan yang sudah dalam bentuk jadi sehingga anda bisa langsung […]

          Reply

        Leave a Reply

        Fill in your details below or click an icon to log in:

        WordPress.com Logo

        You are commenting using your WordPress.com account. Log Out / Change )

        Twitter picture

        You are commenting using your Twitter account. Log Out / Change )

        Facebook photo

        You are commenting using your Facebook account. Log Out / Change )

        Google+ photo

        You are commenting using your Google+ account. Log Out / Change )

        Connecting to %s

        Trackback this post  |  Subscribe to the comments via RSS Feed


        March 2009
        M T W T F S S
        « Feb   May »
         1
        2345678
        9101112131415
        16171819202122
        23242526272829
        3031  

        %d bloggers like this: