Pengertian, Definisi Normalisasi Data
Perancangan basis data diperlukan, agar kita bisa memiliki basis data yang kompak dan efisien dalam penggunaan ruang penyimpanan, cepat dalam pengaksesan dan mudah dalam pemanipulasian (tambah, ubah, hapus) data. Dalam merancang basis data, kita dapat melakukannya dengan :
- Menerapkan normalisasi terhadap struktur tabel yang telah diketahui.
- Langsung membuat model Entity Relationship.
a. Definisi Normalisasi
Normalisasi diartikan sebagai suatu teknik yang menstrukturkan/ mendekomposisi/ memecah data dalam cara–cara tertentu untuk mencegah timbulnya permasalahan pengolahan data dalam basis data. Permasalahan yang dimaksud adalah berkaitan dengan penyimpangan-penyimpangan (anomalies) yang terjadi akibat adanya kerangkapan data dalam relasi dan inefisiensi pengolahan.
Proses normalisasi akan menghasilkan relasi yang optimal, yaitu :
1. Memiliki struktur record yang mudah untuk dimengerti.
2. Memiliki struktur record yang sederhana dalam pemeliharaan.
3. Memiliki struktur record yang mudah untuk ditampilkan kembali untuk memenuhi kebutuhan pemakai.
4. Minimalisasi kerangkapan data guna meningkatkan kinerja sistem.
Dalam pendekatan normalisasi, perancangan basis data bertitik tolak dari situasi nyata. Ia telah memiliki item–item data yang siap ditempatkan dalam baris dan kolom pada tabel–tabel relasional. Demikian juga dengan sejumlah aturan tentang keterhubungan antara item-item data tersebut. Sementara pendekatan model data ER lebih tepat dilakukan jika yang diketahui baru prinsip sistem secara keseluruhan.
Cukup sering pendekatan ini dilakukan bersama-sama, berganti-ganti. Dari fakta yang telah kita miliki, kita lakukan normalisasi. Untuk kepentingan evaluasi dan dokumentasi, hasil normalisasi itu kita wujudkan dalam sebuah model data. Model data yang sudah jadi tersebut bisa saja dimodifikasi dengan pertimbangan tertentu. Hasil modifikasinya kemudian kita implementasikan dalam bentuk sejumlah struktur tabel dalam sebuah basis data. Struktur ini dapat kita uji kembali dengan menerapkan aturan-aturan normalisasi, hingga akhirnya kita peroleh sebuah struktur basis data yang benar-benar efektif dan efisien. Begitulah kedua pendekatan dapat saling memperkuat satu sama lain.
b. Atribut Tabel
Atribut yang sebenarnya identik dengan pemakaian istilah kolom data. Istilah atribut ini lebih umum digunakan dalam perancangan basis data, karena istilah itu lebih impresif dalam menunjukkan fungsinya sebagai pembentuk karakteristik (sifat-sifat) yang melekat pada sebuah table.
1. Atribut Sederhana (Simple Attribute) dan Atribut Komposit (Composite Attribute)
Atribut sederhana adalah atribut atonik yang tidak dapat dipilah lagi. Sementara atribut komposit merupakan atribut yang masih dapat diuraikan lagi menjadi sub-sub atribut yang masing-masing memiliki makna.
|
nim
|
nama_mhs
|
alamat_mhs
|
tgl_lahir
|
|
….
|
Andika Budi
|
Jl. Mangga IV No. 80 Semarang
50173
|
…..
|
|
….
|
Silvana Putri
|
Jl. Belimbing No. 21 Semarang
50175
|
…..
|
|
….
|
….
|
….
|
…..
|
|
alamat
|
kota
|
kode_pos
|
|
Jl. Mangga IV No. 80
|
Semarang
|
50173
|
|
Jl. Belimbing No. 21
|
Semarang
|
50175
|
|
…..
|
…..
|
….
|
Contoh pada tabel mahasiswa, atribut nama_mhs merupakan atribut sederhana. Sedangkan alamat_mhs merupakan atribut komposit, karena dapat diuraikan menjadi beberapa sub atribut seperti alamat, nama_kota dan kode_pos yang masing-masing memiliki makna.
2. Atribut BernilaiTunggal (Single Valued Attribute) dan Atribut Bernilai Banyak (Multi Valued Atrtribute)
Atribut bernilai tunggal ditujukan pada atribut–atribut yang memiliki paling banyak satu nilai untuk setiap basis data. Pada data mahasiswa, semua atribut (nim, nama_mhs, alamat_mhs dan tgl_lahir) merupakan atribut bernilai tunggal, karena atribut–atribut tersebut hanya dapat berisi 1 (satu) nilai. Jika seorang mahasiswa yang memiliki 2 (dua) tempat tinggal, maka hanya salah satu saja yang boleh diisikan ke dalam atribut alamat_mhs.
Atribut bernilai banyak ditujukan pada atribut–atribut yang dapat kita isi dengan lebih dari 1 (satu) nilai, tetapi jenisnya sama. Kita dapat menambahkan atribut hobi, pada data mahasiswa tersebut. Seorang mahasiswa ada yang mempunyai 1 hobi saja, ada juga yang mempunyai hobi banyak dan bahkan ada mahasiswa yang tidak memiliki hobi. Atribut semacam ini tergolong atribut bernilai banyak.
|
nim
|
nama_mhs
|
alamat_mhs
|
tgl_lahir
|
hobi
|
|
040001
|
…..
|
…..
|
…..
|
Membaca
Berenang
Menari
|
|
040002
|
…..
|
…..
|
…..
|
|
|
040003
|
…..
|
…..
|
…..
|
Musik
|
|
040004
|
…..
|
…..
|
…..
|
Sepak Bola
Basket
|
|
040005
|
…..
|
…..
|
…..
|
Menyanyi
|
3. Atribut Harus Bernilai (Mandatory Attribute) dan Nilai Null
Ada sejumlah atribut pada sebuah tabel yang kita tetapkan harus berisi data. Jadi nilainya tidak boleh kosong. Atribut semacam ini disebut Mandatory Attribute. Pada tabel mahasiswa, misalnya atribut nim dan nama_mhs dapat kita golongkan sebagai Mandatory Attribute, karena setiap mahasiswa yang datanya ingin disimpan ke tabel tersebut, paling tidak harus diketahui dengan pasti nim dan namanya. Sebaliknya pula atribut–atribut lain suatu tabel yang nilainya boleh dikosongkan (Non Mandatory Attribute). Nilai Null digunakan untuk menyatakan/ mengisi atribut–atribut demikian yang nilainya memang belum siap atau tidak ada.
|
nim
|
nama_mhs
|
alamat_mhs
|
tgl_lahir
|
hobi
|
|
…..
|
…..
|
…..
|
…..
|
…..
|
|
…..
|
…..
|
…..
|
…..
|
…..
|
|
…..
|
…..
|
…..
|
…..
|
…..
|
|
…..
|
…..
|
…..
|
…..
|
…..
|
4. Atribut Turunan
Atribut turunan adalah atribut yang nilai–nilainya diperbolehkan dari pengolahan atau dapat diturunkan dari atribut atau tabel lain yang berhubungan. Atribut demikian sebetulnya dapat ditiadakan dari sebuah tabel, karena nilai-nilainya bergantung pada nilai yang ada di atribut lainnya.
Penambahan atribut angkatan dan IP (Indeks Prestasi) pada tabel mahasiswa berikut merupakan contoh atribut turunan
|
nim
|
nama_mhs
|
alamat_mhs
|
tgl_lahir
|
angkatan
|
ip
|
|
040001
|
…..
|
…..
|
…..
|
2004
|
3,25
|
|
040002
|
…..
|
…..
|
…..
|
2004
|
2,85
|
|
…..
|
…..
|
…..
|
…..
|
…..
|
…..
|
|
050001
|
…..
|
…..
|
…..
|
2005
|
2,95
|
|
050002
|
…..
|
…..
|
…..
|
2005
|
3,10
|
|
…..
|
…..
|
…..
|
…..
|
…..
|
…..
|
c. Domain dan Tipe Data
- Penetapan tipe data pada setiap atribut (kolom) untuk keperluan penentuan struktur setiap tabel. Penetapan tipe data ini akan berimplikasi pada adanya batas-batas nilai yang mungkin disimpan/diisikan kesetiap atribut tersebut. Jika kita menetapkan bahwa tipe data untuk sebuah atribut adalah integer, maka kita hanya mungkin untuk menyimpan data angka yang bulat diantara –32.768 hingga 32.768. Kita tidak mungkin untuk memasukkan data diluar batas nilai tersebut, data pecahan apalagi data berupa string/text.
- Domain memiliki banyak kesamaan pengertian dengan fungsi tipe data tersebut. Akan tetapi, tipe data merujuk pada kemampuan penyimpanan data yang mungkin bagi suatu atribut secara fisik, tanpa melihat layak tidaknya data tersebut bila dilihat dari kenyataannya pemakaiannya. Sementara domain nilai lebih ditetapkan pada batas–batas nilai yang diperbolehkan bagi suatu atribut, dilihat dari kenyataanya yang ada.
- Contoh : pada tabel kuliah, ditetapkan tipe data untuk atribut sks adalah integer. Dengan begitu secara fisik kita dapat menyimpan nilai –1, 0 atau 100 untuk atribut sks. Tetapi kita mengetahui dengan pasti, bahwa nilai–nilai tersebut tidak pantas (invalid) untuk menjadi data pada atribut sks. Lalu nilai–nilai yang boleh (valid) untuk atribut sks adalah 1, 2, 3, 4 dan 6, maka dapat dikatakan, domain nilai untuk atribut sks adalah 1, 2, 3, 4 dan 6.
d. Ketergantungan Fungsional (Fungsional Dependency)
Diberikan sebuah tabel T berisi paling sedikit 2 buah atribut, yaitu A dan B. Kita dapat menyatakan notasi berikut ini :
A Ã B
Yang berarti A secara fungsional menentukan B atau B secara fungsional tergantung pada A, jika dan hanya jika setiap kumpulan baris (row) yang ada di tabel T, pasti ada 2 baris data (row) di tabel dengan nilai A yang sama, maka nilai B pasti juga sama. Definisi yang paling formal untuk itu adalah :
Diberikan 2 row r1 dan r2 dalam tabel T dimana A Ã
B.
jika r1(A) =
r2(A) maka r1(B) = r2(B)
|
|
nama_kul
|
nim
|
nama_mhs
|
indeks_nilai
|
|
row 1
|
Sistem Basis Data
|
040001
|
Santi Purnamasari
|
A
|
|
row 2
|
Sistem Basis Data
|
040002
|
Budi Setyawan
|
B
|
|
row 3
|
Struktur Data
|
040001
|
Santi Purnamasari
|
|
|
row 4
|
Struktur Data
|
040002
|
Budi Setyawan
|
|
|
row 5
|
Struktur Data
|
040003
|
Kartika Sari
|
|
|
row 6
|
Komunikasi Data
|
040001
|
Santi Purnamasari
|
B
|
|
row 7
|
Riset Operasi
|
040002
|
Budi Setyawan
|
C
|
Dengan melihat data di atas dan dengan pertimbangan intuisi kita, maka ketergantungan fungsional yang dapat kita ajukan adalah :
-
nim à nama_mhs
yang berarti bahwa atribut nama_mhs hanya tergantung pada atribut nim. Hal ini dibuktikan dari fakta : untuk setiap nilai nim yang sama maka pasti nilai nama_mhsnya juga sama.
-
nama_kul, nim à indeks_nilai
yang berarti bahwa atribut indeks_nilai tergantung pada atribut nama_kul dan nim secara bersama–sama, memang kita tidak dapat menunjukkan fakta, bahwa untuk setiap nilai nama_kul dan nim yang sama, maka nilai indeks_nilainya juga sama, karena nama_kul, nim merupakan key (sehingga bersifat unik) untuk tabel tersebut. Tetapi, ketergantungan fungsional tersebut sesuai dengan pengertian bahwa setiap indeks_nilai diperuntukkan pada mahasiswa tertentu untuk mata kuliah tertentu yang diambilnya.
Tanpa memperhatikan pengertian ketergantungan secara alamiah terhadap tabel tersebut, kita juga dapat mengajukan sejumlah ketidaktergantungan (non KF) dengan hanya melihat fakta yang ada,yaitu :
- ![]()
![]()
nama_kul
nim
nim
yang artinya atribut nim tidak tergantung pada atribut nama_kul. Buktinya terlihat pada row 1 dan row 2 : dengan nilai nama_kul yang sama, tapi nilai nimnya berbeda.
- ![]()
![]()
nim
nideks_nilai
nideks_nilai
yang artinya atribut indeks_nilai tidak bergantung pada atribut nim. Buktinya terlihat pada row 1 dan row 3 : dengan nilai nim yang sama, tapi nilai indeks_nilai berbeda.
e. Normalisasi dan KetergantunganFungsional
Dalam perspektif normalisasi, sebuah basis data dapat dikatakan baik, jika setiap tabel yang menjadi unsur pembentuk basis data tersebut juga telah berada dalam keadaan baik atau normal. Selanjutnya, sebuah tabel dapat dikategorikan baik (efisien) atau normal, jika telah memenuhi 3 (tiga) kriteria berikut :
1. Jika ada dekomposisi (penguraian) tabel, maka dekomposisinya harus dijamin aman (Lossless–Join Decomposition).
2. Terpeliharanya ketergantungan fungsional pada saat perubahan data (Dependency Preservation).
3. Tidak melanggar Boyce–Code Normal Form (BCNF)
Lossless–Join Decomposition
Dekomposisi memang merupakan upaya untuk mendapatkan tabel yang baik. Tetapi jika tidak hati-hati, upaya ini justru dapat menghasilkan kesalahan. Dekomposisi yang benar terjadi jika tabel-tabel hasil dekomposisi kita gabungkan kembali dapat menghasilkan tabel awal sebelum didekomposisi. Dekomposisi yang benar semacam ini disebut Lossless–Join Decomposition atau Lossless Decomposition (dekomposisi aman).
Di bawah ini contoh abstrak yang menghasilkan dekomposisi tidak aman (Lossy–Join Decomposition) :
Diasumsikan ada table XYZ yang didefinisikan dua buah ketergantungan fungsional X Ã Y dan Y Ã Z Kedua ketergantungan fungsional tersebut diperoleh dari pengamatan terhadap data yang kurang memadai atau karena asumsi yang kurang tepat.
Katakan isi tabel XYZ tersebut adalah sebagai berikut :
|
|
X
|
Y
|
Z
|
|
row 1
|
x1
|
10
|
z1
|
|
row 2
|
x2
|
20
|
z2
|
|
row 3
|
x3
|
30
|
z3
|
|
row 4
|
x4
|
20
|
z4
|
Memang dengan isi seperti itu, pernyataan ketergantungan fungsional yang kedua Y Ã Z tidak sepenuhnya tepat, karena pada row 2 dan row 4, dengan nilai untuk atribut Z–nya berbeda. Tetapi yang ingin ditekankan di sini adalah adanya dua buah ketergantunagn fungsional itu mendorong kita untuk mendekomposisi tabel XYZ tersebut menjadi dua buah tabel yaitu tabel XY dan YZ sebagai berikut :
|
X
|
Y
|
|
Y
|
Z
|
|
x1
|
10
|
|
10
|
z1
|
|
x2
|
20
|
|
20
|
z2
|
|
x3
|
30
|
|
30
|
z3
|
|
x4
|
20
|
|
20
|
z4
|
Jika kedua tabel diatas kita gabungkan kembali, maka hasilnya adalah :
|
X
|
Y
|
Z
|
|
x1
|
10
|
z1
|
|
x2
|
20
|
z2
|
|
x2
|
20
|
z4
|
|
x3
|
30
|
z3
|
|
x4
|
20
|
z2
|
|
x4
|
20
|
z4
|
Maka ini tentu saja berbeda dengan tabel awal (sebelum didekomposisi). Maka dekomposisi semacam ini disebut Lossy–Join Decomposition (dekomposisi tidak aman), yaitu sebuah dekomposisi yang sedapat mungkin kita hindari.
Akan tetapi jika data pada row 4 yang ada di tabel XYZ awal, kita ganti dengan data berikut :
|
x4
|
20
|
z2
|
Sehingga tabel XYZ menjadi :
|
|
X
|
Y
|
Z
|
|
Row 1
|
x1
|
10
|
z1
|
|
Row 2
|
x2
|
20
|
z2
|
|
Row 3
|
x3
|
30
|
z3
|
|
Row 4
|
x4
|
20
|
z2
|
Dengan data ditabel XYZ demikian maka kedua ketergantungan fungsional dapat dibenarkan. Tabel XYZ tersebut didekomposisikan menjadi tabel XY dan YZ sebagai berikut :
|
X
|
Y
|
|
Y
|
Z
|
|
x1
|
10
|
|
10
|
z1
|
|
x2
|
20
|
|
20
|
z2
|
|
x3
|
30
|
|
30
|
z3
|
|
x4
|
20
|
|
|
|
Kalau kedua tabel diatas digabungkan kembali maka, tabel awal XYZnya akan diperoleh kembali sehingga dekomposisi tersebut aman. Karena itulah ketergantungan fungsional pada suatu tabel harus kita tetapkan berdasarkan pengamatan yang teliti dan asumsi yang dapat dipertanggung jawabkan agar kelak hasil dekomposisi dapat dibenarkan.
Dependency Preservation
Dependency Preservation (pemeliharaan ketergantungan) merupakan kriteria kedua yang harus dapat dicapai untuk mendapatkan tabel dan basis data yang baik. Ketika kita melakukan perubahan data, maka harus bisa dijamin agar perubahan tersebut tidak menghasilkan inkonsistensi data yang mengakibatkan ketergantungan fungsional yang sudah benar menjadi tidak terpenuhi. Akan tetapi, dalam upaya untuk memelihara ketergantungan fungsional yang ada untuk tetap terpenuhi tersebut, prosesnya harus dapat dilakukan dengan efisien.
Contoh :
Tabel mahasiswa : (nim, nama_mhs, alamat_mhs, tgl_lahir) dengan ketergantungan fungsional–nya yaitu :
nim à nama_mhs, alamat_mhs, tgl_lahir
Tabel nilai : (nama_kul, nim, nama_mhs, indeks_nilai) dengan ketergantungan fungsional–nya yaitu :
nama_kul, nim Ã
indeks_nilai dan
nim à nama_mhs
Jika ada perubahan nama_mhs di tabel mahasiswa maka perubahan tersebut harus juga dilakukan di tabel nilai dan juga berlaku sebaliknya yaitu jika ada perubahan nama_mhs di tabel nilai maka perubahan tersebut harus juga dilakukan di tabel mahasiswa.
Jika hal tersebut tidak dilakukan maka data menjadi tidak konsiste dan ketergantunan fungsional menjadi tidak terpenuhi. Misalnya nilai yang nim–nya sama tetapi nama_mhs berbeda. Jika begitu, maka perubahan harus dilakukan diseluruh basis data, tetapi masalahnya perubahan itu tidak efisien dan seharusnya dihindari.
Karena itu sebaiknya agar kriteria dependency preservation dapat terpenuhi dengan meniadakan/melepaskan atribut nama_mhs dari tabel nilai (sehingga tabel nilai berisi 3 atribut, yaitu nama-kul, nim dan indeks_nilai)
Boyce Code Normal Form (BCNF)
Kriteria berikutnya untuk mendapatkan tabel yang baik adalah dengan menerapkan BCNF. Sebuah tabel dikatakan memenuhi BCNF jika untuk semua ketergantungan fungsional dengan notasi X Ã Y, maka X harus merupakan candidate key pada tabel tersebut. Jika tidak demikian, maka tabel tersebut harus didekomposisi berdasarkan ketergantungan fungsional yang ada, sedemikian hingga X menjadi candidat key dari tabel–tabel hasil dekomposisi.
Contoh tabel yang tidak memenuhi BCNF :
Ditentukan tabel A = (E, F, G, H, I) dan berlaku ketergantungan fungsional, yaitu :
E, F Ã
G, H, I
F, G Ã
H, I
Disini tabel A tidak memenuhi BCNF karena ada X yang bukan candiday key, yaitu F, G sehingga F, G Ã H, I
S edangkan E, F adalah candidat key karena E, F Ã G, H, I
Karena terdapat 2 ketergantungan fungsional maka agar tabel A tidak memenuhi BCNF maka tabel tersebut harus didekomposisikan menjadi :
A1 =
(E, F, G) dengan ketergantungan fungsional E, F Ã
G
A2 =
(F, G, H, I) dengan ketergantungan fungsional F, G Ã
H, I
f. Bentuk–Bentuk Normalisasi
Normalisasi data adalah proses yang berkaitan dengan model data relasional untuk mengorganisasi himpunan data dengan ketergantungan dan keterkaitan yang tinggi/ erat. Hasil dari proses normalisasi adalah tabel–tabel data dalam bentuk normal (normal form), yaitu tabel–tabel data yang terhindar dari :
- Pengulangan informasi.
- Potensi inkonsistensi data pada operasi pengubahan.
Bentuk Normal Tahap Pertama (1st Normal Form)
Suatu tabel memenuhi 1stNF ika dan hanya jika tabel tersebut tidak memiliki atribut bernilai banyak atau lebih dari satu atribut dengan domain nilai yang sama.
- Contoh tabel yang tidak memenuhi 1stNF
Tabel mahasiswa = (nim, nama_mhs, alamat_mhs, hobi)
|
nim
|
nama_mhs
|
alamat_mhs
|
hobi
|
|
040001
|
Sintawati
|
Tlogosari
|
Menari, Membaca
|
|
040002
|
Andika
|
Peterongan
|
Berenang
|
|
040003
|
Setiawan
|
Ngaliyan
|
Basket, Sepak Bola
|
|
040004
|
Kartika Sari
|
Banyumanik
|
Menyanyi
|
|
040005
|
AstiAnanta
|
Kaliwiru
|
Membaca, Musik, Basket
|
Atribut hobi memiliki nilai banyak dalam satu baris.
- Contoh tabel yang memenuhi 2ndNF
|
nim
|
nama_mhs
|
alamat_mhs
|
hobi
|
|
040001
|
Sintawati
|
Tlogosari
|
Menari
|
|
040001
|
Sintawati
|
Tlogosari
|
Membaca
|
|
040002
|
Andika
|
Peterongan
|
Berenang
|
|
040003
|
Setiawan
|
Ngaliyan
|
Basket
|
|
040003
|
Setiawan
|
Ngaliyan
|
Sepak Bola
|
|
040004
|
Kartika Sari
|
Banyumanik
|
Menyanyi
|
|
040005
|
AstiAnanta
|
Kaliwiru
|
Membaca
|
|
040005
|
AstiAnanta
|
Kaliwiru
|
Musik
|
|
040005
|
AstiAnanta
|
Kaliwiru
|
Basket
|
Setiap atribut hanya memiliki nilai tunggal dalam satu baris.
Bentuk Normal Tahap Kedua (2nd Normal Form)
Suatu tabel
memenuhi 2ndNF jika dan hanya jika :
1.
Tabel tersebut memenuhi 1stNF
2.
Setiap atribut yang bukan kunci utama (primary key) tergantung secara
fungsional terhadap semua atribut kunci utama dan bukan tergantung secara
fungsional hanya pada sebagian atribut kunci utama.
Contoh tabel yang tidak
memenuhi 2ndNF
Jika diketahui
tabel T = (A, B, C, D, E)
Dan berlaku
ketergantungan fungsional
A, B Ã
C, D
B Ã
E
Disini
atribut E hanya tergantung secara fungsional terhadap atribut B saja, bukan
terhadap A, B. Maka tabel tersebut tidak
memenuhi 2ndNF.
Agar tabel
tersebut dapat memenuhi 2ndNF, maka tabel tersebut didekomposisikan
menjadi dua relasi yaitu :
T1
= (A, B, C, D) dan T2 = (B, E)
Tabel T1
dan T2 secara keseluruhan memenuhi 2ndNF, karena semua
atribut bukan kunci utama tergantung secara fungsional terhadap semua atribut
kunci.
Contoh tabel yang memenuhi 2ndNF
Jika
diketahui table T = (A, B, C, D, E)
A, B dalah
kunci utama
C, D, E bukan
kunci utama
Maka harus
berlaku A,B Ã
C, D, E artinya
A, B Ã C
A, B Ã D
A, B Ã E
Catatan
:
Jika suatu tabel
memenuhi 1sfNF dan tabel tersebut memiliki tepat satu atribut yang
membentuk kunci utama, maka relasi
tersebut memenuhi 2ndNF.
Bentuk
Normal Tahap Ketiga (3rd Normal Form)
Suatu tabel
memenuhi bentuk normal 3rdNF jika dan hanya jika :
1.
Tabel tersebut memenuhi 2ndNF.
2.
Tidak ada atribut bukan kunci tergantung secara transitive pada kunci utama.
Contoh tabel yang tidak memenuhi 3rdNF
:
Diketahui tabel
T = (A, B, C, D, E) dan berlaku ketergantungan fungsional :
A, B Ã
C, D, E
C Ã
D, E
Dalam hal ini tabel
tidak memenuhi 3rdNF karena atribut D dan E yang bukan kunci
tergantung secara fungsional kepada C yang juga bukan kunci (atau dengan kata
lain D dan E tergantung secara transitive
kepada kunci utama).
Agar tabel T
diatas memenuhi 3rdNF maka harus didekomposisikan menjadi :
T1=
(A, B, C) dan T2 = ( C, D, E)
Karena
masing–masing T1 dan T2 memenuhi 3rdNF maka
keseluruhan relasi diatas memenuhi 3rdNF.
Catatan
:
Suatu tabel
yang memenuhi 2ndNF dan hanya memiliki satu atribut bukan kunci
selalu memenuhi 3rdNF.
Bentuk
Normal Tahap Keempat (4th Normal Form)
Suatu tabel
memenuhi bentuk normal 4rdNF jika dan hanya jika :
1.
Memenuhi kriteria BCNF
2.
Setiap atribut di dalamnya tidak mengalami
ketergantungan pada banyak nilai atau dengan kalimat lain, bahwa semua atribut
yang mengalami ketergantungan pada banyak nilai adalah bergantung secara
fungsional (functionally dependency)
Bentuk
Normal Tahap Kelima (5th Normal Form)
Suatu tabel
memenuhi bentuk normal 5rdNF jika dan hanya jika :
Kerelasian
antar data dalam relasi tersebut tidak dapat direkonstruksi dari struktur
relasi yang memuat atribut yang lebih sedikit.
Contoh Kasus Normalisasi
Untuk membantu
pemahaman tentang bentuk dan proses normalisasi akan diberikan contoh relasi
dalam
bentuk tidak normal dan kemudian secara bertahap diubah menjadi optimal
dalam bentuk 2ndNF atau
3rdNF.
Contoh :
Terdapat sebuah
tabel dengan komposisi sebagai berikut :
Tabel
Relasi mahasiswa dalam bentuk UnNormalized/UNF
|
nim
|
nama_mhs
|
kode_mk
|
|
61521
|
Andika
|
SDT231, KDT220, SBD211
|
|
61300
|
Sari
|
SBD211
|
|
61425
|
Dewi
|
RPL202, SDT231
|
|
61230
|
Rudi
|
SD231, RPL202
|
Catatan
:
Tabel Mahasiswa
di atas belum memenuhi kriteria 1stNF, sebab atribut kode_mk masih
memiliki nilai ganda dalam satu baris. Untuk mengkonversikan tabel mahasiswa
tersebut ke dalam bentuk 1stNF, maka kita harus menyusun kembali
baris–baris pada kode_mk, sehingga setiap baris memiliki nilai tunggal, seperti
tabel di bawah ini.
Tabel Relasi Mahasiswa dalam
bentuk 1stNF
|
nim
|
nama_mhs
|
kode_mk
|
|
61521
|
Andika
|
SDT231
|
|
61521
|
Andika
|
KDT220
|
|
61521
|
Andika
|
SBD211
|
|
61300
|
Sari
|
SBD211
|
|
61425
|
Dewi
|
RPL202
|
|
61425
|
Dewi
|
SDT231
|
|
61230
|
Rudi
|
SDT231
|
|
61230
|
Rudi
|
RPL202
|
Tabel
Mahasiswa diatas sudah memenuhi kriteria 1stNF, tetapi belum
memenuhi kriteria 2ndNF sebab atribut nim bergantung fungsional pada
nama_mhs dan atribut kode_mk juga bergantung fungsional pada nama_mhs, sehingga
tabel mahasiswa di atas perlu dipecah menjadi dua tabel agar setiap atribut
bukan primary key hanya tergantung
sepenuhnya terhadap atribut primary key
saja, seperti tabel di bawah ini.
Tabel Relasi Mahasiwa dalam
bentuk 2stNF
Tabel Mahasiswa_1 dan Tabel Mahasiswa_2
|
nim
|
nama_mhs
|
|
nama_mhs
|
kode_mk
|
|
61521
|
Andika
|
|
Andika
|
SDT231
|
|
61521
|
Andika
|
|
Andika
|
KDT220
|
|
61521
|
Andika
|
|
Andika
|
SBD211
|
|
61300
|
Sari
|
|
Sari
|
SBD211
|
|
61425
|
Dewi
|
|
Dewi
|
RPL202
|
|
61425
|
Dewi
|
|
Dewi
|
SDT231
|
|
61230
|
Rudi
|
|
Rudi
|
SDT231
|
|
61230
|
Rudi
|
|
Rudi
|
RPL202
|
Tabel
Mahasiswa_C dibawah ini akan dilakukan uji normalisasi dari bentuk normal satu
1sfNF sampai ke bentuk normal ketiga 3rdNF
Terdapat
sebuah tabel yang sudah memenuhi kriteria 1stNF dengan komposisi
sebagai berikut :
Tabel
Relasi Mahasiswa_C bentuk 1stNF
|
nim
|
nama_mhs
|
tgl_lahir
|
kuliah
|
kode_mk
|
sks
|
nilai
|
bobot
|
|
61521
|
Andika
|
12-05-85
|
Struktur Data
|
SDT231
|
3
|
B
|
3
|
|
61521
|
Andika
|
12-05-85
|
Komunikasi Data
|
KDT220
|
3
|
A
|
4
|
|
61521
|
Andika
|
12-05-85
|
Sistem Basis Data
|
SBD211
|
2
|
B
|
3
|
|
61300
|
Sari
|
14-06-86
|
Sistem Basis Data
|
SBD211
|
2
|
A
|
4
|
|
61425
|
Dewi
|
18-09-86
|
Rekayasa Perangkat Lunak
|
RPL202
|
2
|
C
|
2
|
|
61425
|
Dewi
|
18-09-86
|
Struktur Data
|
SDT231
|
3
|
B
|
3
|
|
61230
|
Rudi
|
01-12-85
|
Struktur Data
|
SDT231
|
3
|
B
|
3
|
|
61230
|
Rudi
|
01-12-85
|
Rekayasa Perangkat Lunak
|
RPL202
|
2
|
C
|
2
|
Dari tabel
relasi Mahasiswa_C di atas terdapat beberapa ketergantungan fungsional di
antara atribut–atributnya sebagai berikut :
nim Ã
nama_mhs, tgl_lahir
kode_mk Ã
kuliah, sks
nim, kode_mk Ã
nilai
nilai Ã
bobot
Tabel
Mahasiswa_C di atas belum memenuhi kriteria 2ndNF, selama terdapat
beberapa atribut seperti tgl_lahir, kuliah yang tidak memiliki ketergantungan
fungsional terhadap primary key (nim,
kode_mk).
Untuk mengkonversi
tabel tersebut menjadi 2ndNF, maka tabel Mahasiswa_C perlu dipecah
menjadi 3 tabel yaitu : tabel mahasiswa_C1 = (nim, nama_mhs,
tgl_lahir), mahasiswa_C2 = (kode_mk, kuliah, sks) dan mahasiswa_C3
= (nim, kode_mk, nilai, bobot) dengan komposisi tabel sebagai
berikut :
Tabel
Relasi Mahasiswa_C1 bentuk 2ndNF
|
Nim
|
nama_mhs
|
tgl_lahir
|
|
61521
|
Andika
|
12-05-85
|
|
61300
|
Sari
|
14-06-86
|
|
61425
|
Dewi
|
18-09-86
|
|
61230
|
Rudi
|
01-12-85
|
|
kode_mk
|
kuliah
|
sks
|
|
SDT231
|
Struktur Data
|
3
|
|
KDT220
|
Komunikasi Data
|
3
|
|
SBD211
|
Sistem Basis Data
|
2
|
|
RPL202
|
Rekayasa Perangkat
Lunak
|
2
|
|
nim
|
kode_mk
|
nilai
|
bobot
|
|
61521
|
SDT231
|
B
|
3
|
|
61521
|
KDT220
|
A
|
4
|
|
61521
|
SBD211
|
B
|
3
|
|
61300
|
SBD211
|
A
|
4
|
|
61425
|
RPL202
|
C
|
2
|
|
61425
|
SDT231
|
B
|
3
|
|
61230
|
SDT231
|
B
|
3
|
|
61230
|
RPL202
|
C
|
2
|
Tabel Mahasiswa_C1
dan Mahasiswa_C2 telah memenuhi kriteria 3rdNF, namun
tabel Mahasiswa_C3 belum memenuhi kriteria 3rdNF, selama
atribut non–key/bukan kunci nilai dan
bobot masih saling memiliki ketergantungan fungsional.
Untuk
mengkonversinya menjadi bentuk 3rdNF, maka tabel mahasiswa_C3
tersebut perlu dipecah menjadi 2 tabel yaitu :
Table
mahasiswa_C3A = (nim, kode_mk, nilai) dan Mahasiswa_C3B
= (nilai, bobot) dengan komposisi tabel sebagai berikut :
Tabel
Relasi Mahasiswa_C3A bentuk 3rdNF
|
nim
|
kode_mk
|
nilai
|
|
61521
|
SDT231
|
B
|
|
61521
|
KDT220
|
A
|
|
61521
|
SBD211
|
B
|
|
61300
|
SBD211
|
A
|
|
61425
|
RPL202
|
C
|
|
61425
|
SDT231
|
B
|
|
61230
|
SDT231
|
B
|
|
61230
|
RPL202
|
C
|
Tabel Relasi Mahasiswa_C3 bentuk
3rdNF
|
nilai
|
bobot
|
|
A
|
4
|
|
B
|
3
|
|
C
|
2
|
|
D
|
1
|
|
E
|
0
|
