gabung

Unique 1:1 Traffic Exchange

Kamis, 09 Juni 2011

kasus normalisasi

CONTOH KASUS NORMALISASI
  1. 1.     STUDI  KASUS TOKO ABC

1.Dokumen

No. Faktur :
Tanggal :
Kepada :
No.
Nama
Jumlah
Harga
Total






Total Bayar

Diskon

Jumlah Bayar
Petugas : …………………………..

2. Data Dictionary

- No.Faktur - Jumlah - Diskon
- Tanggal - Harga - Jumlah Bayar
- Kepada - Total
- Nama - Total bayar

3. Tahap Normalisasi
TAHAP-TAHAP NORMALISASI DATA
Mendasar pada faktur yang tertera di atas, maka gambaran database yang belum ternormalisasi adalah sebagai berikut :
  1. Tabel yang memiliki field dengan banyak data / tidak tungga

No_Faktur
Tanggal
Nama_pelanggan
Daftar_Belanja
05070101
29/05/07
Pitoyo
Bedak, Beras, Minyak Tanah, Buku
05070102
29/05/07
Bowo
Baby Oil, Garam, Gula, Pensil
05070103
30/05/07
Erlina
Sikat gigi, Sabun, Odol, Sampo
06070001
01/06/07
Dayat
Beras

2. Tabel dengan field yang mengalami repeating groups

No_Faktur
Tanggal
 Nama_pelanggan
Belanja1
Harga1
Belanja2
Harga2
Belanja3
Harga3
Belanja4
Harga4
05070101
29/05/07
Pitoyo
Bedak
1500
Beras
10000
Minyak Tanah
3500
Buku
2000
05070102
29/05/07
Bowo
Baby Oil
5600
Garam
2500
Gula
4000
Pensil
1500
05070103
30/05/07
Erlina
Sikat gigi
12000
Sabun
2500
Odol
13000
Sampo
16000
06070001
01/06/07
Dayat
Beras
25000






First Normal form (1-NF)
Implementasi 1-NF dari table data yang belum ternormalisasi di atas adalah dengan cara mengeliminasi keberadaan repeating groups dan dekomposisi relasi menjadi dua atau lebih dengan syarat “tidak boleh ada informasi yang hilang karena proses dekomposisi”
Adapun caranya adalah :
1. Membuat 3 tabel yang memiliki fungsi sebagai berikut :
  • TBFaktur, berfungsi untuk menyediakan atribut-atribut yang bersifat atomic dari tiap nomor faktur (ID_Faktur), seperti : Tanggal, Nama_Pelanggan, Total_Bayar, Diskon dan Nama_Petugas
  • TBProduk, berfungsi untuk menyediakan atribut-atribut yang berulang atau tidak bernilai tunggal pada tiap nomor faktur (ID_Faktur), seperti : Nama_Barang dan harga
  • TBTransaksiDetail, berfungsi sebagai penghubung antara nomor faktur (ID_Faktur) dengan kode barang (ID_Barang) agar proses dekomposisi tidak menyebabkan kerusakan informasi.
  1. Menentukan type data dari tiap atribut dan membuat digram relasional sebagai berikut
Tabel Transaksi Detail
Id_Transaksi
Id_Faktur
Id_Barang
Harga
Jumlah
01
05070101
 A01 1.500 1
01
05070101
 A02 10.000 1
01
05070101
 S02 3.500 1
01
05070101
 B01 2.000 1
02
05070102
 S01 5.600 1
02
05070102
 S03 2.500 1
02
05070102
 B02 4.000 1
02
05070102
 B03 1.500 1
03
05070103
 C01 12.000 1
03
05070103
 C02 2.500 1
03
05070103
 C03 13.000 1
03
05070103
 D02 16.000 1
04
06070001
 D03 25.000 1

Tabel Produk

Id_Barang
Nama_Barang
Harga_default
A01 Bedak 1.500
A02 Beras 10.000
S01 Baby Oil 5.600
S02 Minyak tanah 3.500
S03 Garam 2.500
B01 Buku 2.000
B02 Gula 4.000
B03 Pensil 1.500
C01 Sikat Gigi 12.000
C02 Sabun 2.500
C03 Odol 13.000
D02 Sampo 16.000
D03 Beras01 25.000

Table Faktur

Id_faktur
Tanggal
Id_Pelanggan
Nama_Pelanggan
Total_Bayar
Diskon
Id_Petugas
Nama_Petugas
05070101
29/05/07
 P01 Pitoyo 20.600 0% K01 Didin
05070102
29/05/07
 B01 Bowo 11.000 0% J01 Rina
05070103
30/05/07
 E01 Erlina 41.500 0% L02 Rudi
06070001
01/06/07
 D01 Dayat 25.000 0% X02 Amelia


3. Pada table TBTransaksiDetail terdapat atribut “Harga”yang berfungsi untuk menyimpan harga per transaksi, sedangkan atribut “Harga_Default” yang terdapat pada table TBProduk adalah atribut yang berfungsi untuk menyimpan harga barang terbaru dari tiap jenis barang.Hal ini berguna untuk mengantisipasi adanya perubahan harga barang dari waktu ke waktu.
4. Primary key yang digunakan pada TBTransaksiDetail adalah “ID_Transaksi”. Atribut kunci tersebut merupakan candidate key yang dibentuk dari superkey hasil penggabungan 2 atribut yaitu : ID_Faktur dan ID_Barang
Second Normal form (2-NF)
Suatu relasi berada dalam 2nd normal form jika dan hanya jika :
<–>Berada dalam bentuk first normal form (1-NF)
<–>Semua atribut bukan kunci memiliki dependensi sepenuhnya dengan kunci primer (Primary Key)
Jika ditelaah kembali relasi bentuk 1-NF yang telah dibuat sebelumnya, maka atribut bukan kunci pada table TBFaktur yang tidak memiliki dependensi sepenuhnya dengan primary key (ID_Faktur), yaitu : “Nama_Petugas”.
Oleh sebab itu dekomposisi relasi perlu dilakukan kembali dengan cara :
  1. Mengeliminasi atribut “Nama_Petugas” dari table TBFaktur
  2. Membuat tabel TBPetugas, menyediakan atribut-atribut yang terkait dengan identitas dan data pelanggan
Tabel Transaksi Detail
Id_Faktur
Id_Barang
Harga
Jumlah
05070101
 A01 1.500 1
05070101
 A02 10.000 1
05070101
 S02 3.500 1
05070101
 B01 2.000 1
05070102
 S01 5.600 1
05070102
 S03 2.500 1
05070102
 B02 4.000 1
05070102
 B03 1.500 1
05070103
 C01 12.000 1
05070103
 C02 2.500 1
05070103
 C03 13.000 1
05070103
 D02 16.000 1
06070001
 D03 25.000 1


Table Faktur

Id_faktur
Id_pelanggan
Nama_pelanggan
Id_petugas
tanggal
Total_bayar
Diskon
05070101
 P01 Pitoyo K01
29/05/07
 20.600 0%
05070102
 B01 Bowo J01
29/05/07
 11.000 0%
05070103
 E01 Erlina L02
30/05/07
 41.500 0%
06070001
 D01 Dayat X02
01/06/07
 25.000 0%

Table Petugas
Id_petugas
Nama_petugas
Alamat
Telp
K01 Didin Jl.aceh 12bandung 0853335555
L02 Rudi Jl.Kiircon 23bandung 0816334466
J01 Rina Jl.Buah batu 04 bandung 022778652
X02 Amelia Jl.Jakarta 45bandung 022998776









Tabel Produk

Id_Barang
Nama_Barang
Harga_default
A01 Bedak 1.500
A02 Beras 10.000
S01 Baby Oil 5.600
S02 Minyak tanah 3.500
S03 Garam 2.500
B01 Buku 2.000
B02 Gula 4.000
B03 Pensil 1.500
C01 Sikat Gigi 12.000
C02 Sabun 2.500
C03 Odol 13.000
D02 Sampo 16.000
D03 Beras01 25.000

Third Normal form (3-NF)
Pada Second Normal Form (2-NF) atribut yang terkait dengan “Nama_Pelanggan” tidak didekomposisi dari table TBFaktur karena atribut tersebut masih memiliki dependensi fungsional dengan primary key (ID_Faktur) karena tiap nomor faktur akan berbeda untuk tiap pembeli/pelanggan.
Tetapi pada tahap 3-NF (Third Normal Form), atribut “Nama_Pelanggan” harus didekomposisi relasi karena pada tahap ini atribut bukan kunci tidak boleh ada yang berdependensi transitif dengan kunci primer.
Atribut “Nama_Pelanggan” dikatakan berdependensi transitif terhadap primary key (ID_Faktur) karena :
  1. ID_Pelanggan  Nama_Pelanggan (Nama_Pelanggan berdependensi fungsional terhadap ID_Pelanggan)
  2. ID_Faktur  ID_Pelanggan (ID_Pelanggan berdependensi fungsional terhadap ID_Faktur, karena tiap nomor faktur akan dikeluarkan untuk suatu ID_Pelanggan tertentu)
  3. Sehingga dikatakan bahwa ID_Faktur memiliki dependensi transitif terhadap atribut Nama_Pelanggan
Berdasarkan analisa di atas maka diagram relational hasil penerapan Third Normal Form adalah sebagai berikut :

Tabel Transaksi Detail

Id_Faktur
Id_Barang
Harga
Jumlah
05070101
 A01 1.500 1
05070101
 A02 10.000 1
05070101
 S02 3.500 1
05070101
 B01 2.000 1
05070102
 S01 5.600 1
05070102
 S03 2.500 1
05070102
 B02 4.000 1
05070102
 B03 1.500 1
05070103
 C01 12.000 1
05070103
 C02 2.500 1
05070103
 C03 13.000 1
05070103
 D02 16.000 1
06070001
 D03 25.000 1

Table Faktur

Id_faktur
Id_pelanggan
Id_petugas
tanggal
Total_bayar
Diskon
05070101
 P01 K01
29/05/07
 20.600 0%
05070102
 B01 J01
29/05/07
 11.000 0%
05070103
 E01 L02
30/05/07
 41.500 0%
06070001
 D01 X02
01/06/07
 25.000 0%

















Table petugas
Id_petugas
Nama_petugas
Alamat
Telp
K01 Didin Jl.aceh 12bandung 0853335555
L02 Rudi Jl.Kiircon 23bandung 0816334466
J01 Rina Jl.Buah batu 04 bandung 022778652
X02 Amelia Jl.Jakarta 45bandung 022998776

Tabel produk

Id_Barang
Nama_Barang
Harga_default
A01 Bedak 1.500
A02 Beras 10.000
S01 Baby Oil 5.600
S02 Minyak tanah 3.500
S03 Garam 2.500
B01 Buku 2.000
B02 Gula 4.000
B03 Pensil 1.500
C01 Sikat Gigi 12.000
C02 Sabun 2.500
C03 Odol 13.000
D02 Sampo 16.000
D03 Beras01 25.000

Tabel pelanggan
Id_pelanggan
Nama_pelanggan
Alamat
Telp
P01 Pitoyo Jl.Cibiru 12bandung 0852222702382
B01 Bowo Jl.Ciwastra 02bandung 081395210395
E01 Erlina Jl.Stasiun lama kircon 03bandung 085722028127
D01 Dayat Jl.suci 24bandung 02233445

  1. 2.     STUDI KASUS NORMALISASI  PENJUALAN BARANG PT. ALAMANDA
Data diperoleh dari hasil survey di lapangan pada Faktur Penjualan Barang.



Membuat Bentuk Tidak Ternormalisasi
Bentuk tidak ternormalisasi dari kasus mengenai faktur penjualan barang, adalah sebagai berikut:
Nomor Faktur
Kode Pelanggan
Nama Pelanggan
Nama Barang
Kode Barang
Tanggal
Pelunasan
Jml
Harga
Total
Total Faktur
F101
P002
Ir. Anjani
B001
B002
Kulkas JVC
TV Sony
06/10/07
20/10/07
3
5
1.500.000
1.000.000
4.500.000
5.000.000
9.500.000
F106
P004
Ir. Adi Susanto
B001
B004
Kulkas JVC
TV Sharp
08/10/07
22/10/07
4
5
1.500.000
800.000
6.000.000
4.000.000
10.000.000
Bentuk Normal Pertama
Yaitu suatu tabel dikatakan dalam bentuk normal pertama hanya jika setiap kolom bernilai tunggal untuk setiap baris (Abdul kadir, 2003).
Bentuk normal pertama mempunyai cirri bahwa setiap data dibentuk dalam flat tabel (tabel datar/rata). Data dibentuk dalam satu record demi satu record dan nilai dari field-field.
Bentuk Normal Pertama dari kasus mengenai faktur penjualan barang, adalah sebagai berikut :
Nomor Faktur
Kode Pelanggan
Nama Pelanggan
Nama Barang
Kode Barang
Tanggal
Pelunasan
Jml
Harga
Total
Total Faktur
F101
P002
Ir. Anjani
B001
Kulkas JVC
06/10/07
20/10/07
3
1.500.000
4.500.000
9.500.000
F101
P002
Ir. Anjani
B002
TV Sony
06/10/07
20/10/07
5
1.000.000
4.500.000
9.500.000
F106
P004
Ir. Adi Susanto
B001
Kulkas JVC
08/10/07
22/10/07
4
1.500.000
5.000.000
10.000.000
F106
P004
Ir. Adi Susanto
B004
TV Sharp
08/10/07
22/10/07
5
800.000
4.000.000
10.000.000


Bentuk Normal Kedua
Suatu tabel berada dalam bentuk normal kedua jika :
  • Tabel berada dalam bentuk normal pertama
  • Semua kolom bukan-kunci-primer tergantung sepenuhnya terhadap kunci primer.
Tergantung sepenuhnya jika suatu kolom selalu bernilai sama untuk nilai kunci primer yang sama.
Bentuk Normal Kedua dari kasus mengenai faktur penjualan barang, adalah sebagai berikut :
Tabel Barang
Kode_Barang(*)
Nama_Barang
B001 Kulkas JVC
B002 TV Sony
B004 TV Sharp
Tabel Pelanggan
Kode_Pelaggan(*)
Nama_Pelanggan
P002 Ir. Anjani
P004 Ir. Adi Sumanto
Tabel Faktur
Nomor Faktur(*)
Kode Pelanggan(**)
Tanggal
Pelunasan
Jml
Harga
Total Faktur
F101 P001
06/10/07
20/10/07
3
1.500.000
9.500.000
F101 P001
06/10/07
20/10/07
5
1.000.000
9.500.000
F106 P004
08/10/07
22/10/07
4
1.500.000
10.000.000
F106 P004
08/10/07
22/10/07
5
800.000
10.000.000
Keterangan :
*: kunci Primer dari tabel
**:kunci tamu/foreign key

Bentuk Normal Ketiga
Suatu tabel dikatakan dalam bentuk normal ketiga, apabila :
ü  Berada dalam bentuk normal kedua,
ü  Setiap kolom bukan kunci primer yang tidak memiliki ketergantungan secara transitif terhadap kunci primer
Bentuk Normal Ketiga dari kasus mengenai faktur penjualan barang, adalah sebagai berikut :
Tabel Barang
Kode_Barang(*)
Nama_Barang
B001 Kulkas JVC
B002 TV Sony
B004 TV Sharp
Tabel Pelanggan
Kode_Pelaggan(*)
Nama_Pelanggan
P002 Ir. Anjani
P004 Ir. Adi Sumanto
Tabel Faktur
Nomor Faktur(*)
Kode Pelanggan(**)
Tanggal
Pelunasan
Total Faktur
F101 P001 06/10/07 20/10/07 9.500.000
F101 P001 06/10/07 20/10/07 9.500.000
F106 P004 08/10/07 22/10/07 10.000.000
F106 P004 08/10/07 22/10/07 10.000.000
Tabel Item Faktur
Nomor Faktur(*)
Kode Barang(**)
Jml
Harga
F101 B001 3 1.500.000
F101 B002 5 1.000.000
F106 B001 4 1.500.000
F106 B004 5    800.000


Keterangan :
*:kunci Primer dari tabel
**:kunci tamu/foreign keyilmu92.blogspot.com
Posted by at
Labels:

Tidak ada komentar:

Posting Komentar

Langganan: Posting Komentar (Atom)