- Dapatkan link
- Aplikasi Lainnya
 |
Photo by Anete Lusina from Pexels
|
Normalisasi memiliki beberapa langkah dengan tujuan database makin kuat dalam format(memiliki batasan) agar terhindar dari anomali. Tahapan dari normalisasi adalah 1NF, 2NF, 3NF dan BCNF. Sebenarnya juga ada 4NF dan 5NF tetapi kasus ini jarang.
Membentuk 1NF, 2NF, 3NF dan BCNF tidak dapat dilihat per tabel tapi harus melihat dari keseluruhan fungsi tabel. Misal ingin menyimpan data customer yang melakukan persewaan rumah, maka fokus utama kita adalah pada customer yang menyewa rumah.
1 Normal Form(1NF)
Adalah sebuah tabel dengan bentuk tiap row dan kolom memiliki satu nilai saja(disebut juga sebagai flattening).
Kemudian setelah dipisah data yang berulang dipisah dalam tabel sendiri dan termasuk key yang dimiliki.
Ambil contoh seperti ini, dalam sebuah tabel sewa rumah maka seorang yang bernama eric menyewa 2 buah property sehingga dalam tabel tergambar sebagai berikut dengan judul
sewa properti
| No Cust | Nama | No Property | Alamat | Start Sewa | akhir sewa | Biaya Sewa | IDPemilik | Nama Pemilik |
| E001 | Eric | PN001, PN004 | Ngagel Jaya Tengah 73, Sutorejo Perak 3 | 12 Juni 2019, 2 Januari 2019 | 15 Juni 2019, 15 Febuari 2019 | 250K, 500k | OW001, M005 | Owen M, Margareth |
Tabel tersebut adalah sebuah bentuk Unormalized Form untuk menjadikan 1NF maka buat setiap kolom dan row memiliki 1 value saja(Flattening) sehingga menjadi seperti berikut
Sewa Properti
| No Cust | Nama | No Property | Alamat | Start Sewa | akhir sewa | Biaya Sewa | IDPemilik | Nama Pemilik |
| E001 | Eric | PN001 | Ngagel Jaya Tengah 73 | 12 Juni 2019 | 15 Juni 2019 | 250K | OW001 | Owen M |
| E001 | Eric | PN004 | Sutorejo Perak 3 | 2 Januari 2019 | 15 Febuari 2019 | 500k | M005 | Margareth |
Di sini kita melihat ada data yang berulang (Nama) data ini dipisah sehingga bentuknya menjadi seperti berikut.
Customer
| No Cust | Nama |
| E001 | Eric |
Sewa Properti
| No Cust | No Property | alamat | Start Sewa | akhir sewa | Biaya Sewa | IDPemilik | Nama Pemilik |
| E001 | PN001 | Ngagel Jaya Tengah 73 | 12 Juni 2019 | 15 Juni 2019 | 250K | OW001 | Owen M |
| E001 | PN004 | Sutorejo Perak 3 | 2 Januari 2019 | 15 Febuari 2019 | 500k | M005 | Margareth |
Inilah tabel yang memenuhi syarat 1NF
2 Normal Form(2NF)
2NF melihat pada konsep full functional dependency, jika ada sebuah partial dependency maka pindahkan atribut yang partial dependent tersebut dengan membuat tabel baru dan relasi baru.
Full fuctional dependency artinya adalah semua atribut yang bukan key bergantung pada atribut key.
Kita perhatikan tabel berikut
Customer| No Cust | Nama |
| E001 | Eric |
Sewa Properti
| No Cust | No Property | alamat | Start Sewa | akhir sewa | Biaya Sewa | IDPemilik | Nama Pemilik |
| E001 | PN001 | Ngagel Jaya Tengah 73 | 12 Juni 2019 | 15 Juni 2019 | 250K | OW001 | Owen M |
| E001 | PN004 | Sutorejo Perak 3 | 2 Januari 2019 | 15 Febuari 2019 | 500k | M005 | Margareth |
Kita lihat bahwa start sewa dan akhir sewa sangat bergantung(full dependent) pada no cust dan no property sehingga start dan akhir sewa tidak dipisahkan dari tabel sewa properti.
Bagaimana bisa? Karena tidak masuk akal bila menyimpan No Cust dan No Property tapi tidak ada start sewa atau akhir sewa. Karena tujuan adalah menyimpan data customer yang melakukan penyewaan rumah.
Kemudian bila dibalik hal ini juga tidak masuk akal, maksudnya ada start sewa dan akhir sewa tapi tidak ada property yang disewa atau customer yang menyewa
Sehingga dapat disimpulkan bahwa No Cust, No Property, Start Sewa dan Akhir Sewa adalah kunci utama dalam menyimpan data customer yang melakukan penyewaan rumah. Kemudian kita lihat lagi pada tabel sewa properti.
Sewa Properti
| No Cust | No Property | alamat | Start Sewa | akhir sewa | Biaya Sewa | IDPemilik | Nama Pemilik |
| E001 | PN001 | Ngagel Jaya Tengah 73 | 12 Juni 2019 | 15 Juni 2019 | 250K | OW001 | Owen M |
| E001 | PN004 | Sutorejo Perak 3 | 2 Januari 2019 | 15 Febuari 2019 | 500k | M005 | Margareth |
Dapat dilihat bahwa Alamat, Biaya Sewa, ID Pemilik dan Nama Pemilik hanyalah partialy dependent karena atribut tersebut hanya bergantung pada No Property dan tidak bergantung pada no customer maka buatkan tabel baru dan pisahkan.
Sehingga susunan tabel setelah dijadikan 2NF adalah sebagai berikut.
Customer
| No Cust | Nama |
| E001 | Eric |
Sewa Properti
| No Cust | No Property | Start Sewa | akhir sewa |
| E001 | PN001 | 12 Juni 2019 | 15 Juni 2019 |
| E001 | PN004 | 2 Januari 2019 | 15 Febuari 2019 |
Properti
| No Property | alamat | Biaya Sewa | IDPemilik | Nama Pemilik |
| PN001 | Ngagel Jaya Tengah 73 | 250K | OW001 | Owen M |
| PN004 | Sutorejo Perak 3 | 500k | M005 | Margareth |
Diingatkan sekali lagi membentuk 1NF, 2NF, 3NF dan BCNF tidak dapat dilihat per tabel tapi harus melihat dari keseluruhan fungsi tabel. Fungsi tabel yang ada memiliki tujuan menyimpan data customer yang melakukan persewaan rumah.
3rd Normal Form(3NF)
Perubahan dari 2NF menuju 3NF hanya perlu menghilangkan transitive dependecies.
Kita lihat pada tabel properti yang belum berbentuk 3NF
Customer
| No Cust | Nama |
| E001 | Eric |
Sewa Properti
| No Cust | No Property | Start Sewa | akhir sewa |
| E001 | PN001 | 12 Juni 2019 | 15 Juni 2019 |
| E001 | PN004 | 2 Januari 2019 | 15 Febuari 2019 |
Sewa Properti juga berbentuk 3NF karena start sewa dan akhir sewa sangat bergantung pada no customer dan no property.
Pada saat No Cust atau No property tidak ada maka row tersebut tidak bisa masuk karena kekurangan key.
Tetapi pada tabel properti, ada atribut yang tidak bergantung pada primary key No Property seperti nama pemilik. Karena atibut Nama Pemilik adalah sebuah bentuk dari transitive dependencies.
Transitive Dependencies terjadi apabila ada sebuah atribut yang non-key bergantung pada atribut lain yang juga non-key.
Coba kita lihat tabel properti
Properti
| No Property | alamat | Biaya Sewa | IDPemilik | Nama Pemilik |
| PN001 | Ngagel Jaya Tengah 73 | 250K | OW001 | Owen M |
| PN004 | Sutorejo Perak 3 | 500k | M005 | Margareth |
Alamat bergantung pada No property(Primary Key), Biaya sewa bergantung pada no property tetapi nama pemilik tidak bergantung pada No Property tetapi bergantung pada ID Pemilik.
Sedangkan ID Pemilik adalah sebuah atribut Non-Key maka dari itu dapat kita simpulkan bahwa Nama Pemilik adalah transitive dependencies.
Sehingga perlu dilakukan pemisahan pada atribut Nama Pemilik dengan membuatkan tabel baru sehingga susunan tabel menjadi
Customer| No Cust | Nama |
| E001 | Eric |
Sewa Properti
| No Cust | No Property | Start Sewa | akhir sewa |
| E001 | PN001 | 12 Juni 2019 | 15 Juni 2019 |
| E001 | PN004 | 2 Januari 2019 | 15 Febuari 2019 |
Properti Disewakan
| No Property | alamat | Biaya Sewa | IDPemilik |
| PN001 | Ngagel Jaya Tengah 73 | 250K | OW001 |
| PN004 | Sutorejo Perak 3 | 500k | M005 |
Pemilik Properti
| IDPemilik | Nama Pemilik |
| OW001 | Owen M |
| M005 | Margareth |
Maka Bentuk dari tabel kita sudah memenuhi syarat 3NF
Note tambahan mengenai transitive dependencies :
Transitive Dependencies juga disebut FFD tidak langsung.
Beberapa buku/ppt akan mengatakan bahwa transitive dependencies terbentuk dari A,B dan C yang saling berhubungan seperti A berhubungan dengan B dan B berhubungan dengan C kemudian A tidak dependen pada B dan C.
Contoh dan PPT tersebut tidak salah. Ambil contoh tabel properti yang belum kita jadikan 3NF
Properti
| No Property | alamat | Biaya Sewa | IDPemilik | Nama Pemilik |
| PN001 | Ngagel Jaya Tengah 73 | 250K | OW001 | Owen M |
| PN004 | Sutorejo Perak 3 | 500k | M005 | Margareth |
A= No Property
B= ID Pemilik
C=Nama Pemilik
A tidak bergantung pada B dan C
B bergantung pada A
sedangkan C bergantung B
C disebut transitive dependen karena bisa bergantung pada A melalui B kalau contoh di tabel kita bisa lihat bahwa Nama Pemilik bergantung pada No Property melalui ID Pemilik.
Maka untuk menjadikan 3NF maka perlu dibuatkan tabel baru untuk atribut yang transitive.
Kemudian dalam tabel bisa dilihat bahwa ID Pemilik bukanlah Key atribut dan Nama pemilik juga bukan key atribut. Jadi baik penjelasan dalam 3NF mengenai transitive dependencies(di atas) ataupun yang ada dalam PPT/buku manapun akan memiliki kesimpulan yang sama.
-------------------------------------------------------------------------------------------
1NF = Setiap Row dan kolom hanya memiliki 1 nilai saja
2NF = 1NF + Setiap non-primary-key atribut FFD terhadap primary key.
FFD = Full Functional Dependency, terjadi bila ada A dan B dalam sebuah hubungan/tabel dan B bergantung pada A saja.
3NF = 2NF + tidak ada transitive dependencies.
Transitive Dependencies juga disebut FFD tidak langsung.
-------------------------------------------------------------------------------------------
Ada juga contoh yang tidak menggunakan tabel dan field dalam database seperti yang saya gunakan seperti menentukan relational key nya dan lainnya. Secara pribadi saya lebih suka pendekatan secara praktek daripada teoritis, tapi bila ada yang membutuhkan saya letakkan di link berikut.
1. menentukan relational key dan NF tertinggi
Komentar
Posting Komentar