Contoh studi kasus normalisasi

)

1.dokumen

STUDI KASUS TOKO ABC

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 tunggal

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.

2. Menentukan type data dari tiap atribut dan membuat digram relasional sebagai berikut

Tabel TransaksiDetail

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 2^nd 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 TransaksiDetail

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 12 bandung	0853335555
L02	Rudi	Jl.Kiircon 23 bandung	0816334466
J01	Rina	Jl.Buah batu 04 bandung	022778652
X02	Amelia	Jl.Jakarta 45 bandung	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 TransaksiDetail

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 12 bandung	0853335555
L02	Rudi	Jl.Kiircon 23 bandung	0816334466
J01	Rina	Jl.Buah batu 04 bandung	022778652
X02	Amelia	Jl.Jakarta 45 bandung	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 12 bandung	0852222702382
B01	Bowo	Jl.Ciwastra 02 bandung	081395210395
E01	Erlina	Jl.Stasiun lama kircon 03 bandung	085722028127
D01	Dayat	Jl.suci 24 bandung	02233445