Senin, 02 Juli 2012

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

0 komentar:

Posting Komentar