Contoh proses normalisasi relasi dari UNF – 1NF – 2NF – dan 3NF

Dalam posting tulisan tentang: “Tujuan dan Manfaat Normalisasi dalam Perancangan Database”, kita sudah mempelajari tentang: “Apa itu normalisasi” dan “Mengapa kita perlu melakukan normalisasi”. Kedua pertanyaan itu sudah terjawab dalam tulisan tersebut. 

Kemudian dalam posting tulisan tentang: “Konsep Ketergantungan Fungsional, Normalisasi, dan Identifikasi Primary Key dalam Perancangan Sistem Database”, kita sudah mempelajari suatu konsep penting yang digunakan untuk melakukan normalisasi, yaitu konsep ketergantungan fungsional yang terdiri dari ketergantungan penuh, ketergantungan parsial atau sebagian, dan ketergantungan transitif. Proses normalisasi pertama-tama dilakukan dengan mengidentifikasi adanya ketergantungan-ketergantungan tersebut dalam relasi-relasi dan kemudian menghilangkannya. Cara melakukan normalisasi, mengidentifikasi berbagai macam ketergantungan, dan menghilangkan ketergantungan pada relasi-relasi bisa dipelajari ulang dalam postingan tulisan di atas atau di link ini. Posting tulisan ini akan memberi contoh step-by-step dengan ilustrasi yang lebih aktual bagaimana melakukan normalisasi mulai dari UNF (atau Unnormalized Form) – 1NF – 2NF – dan 3NF.

Dari form tradisional ke tabel/relasi UNF

Kadang-kadang kita membuat relasi mulai dari 1NF tetapi terkadang juga dari UNF. Contoh disini akan kita mulai dari UNF saja supaya terlihat lebih lengkap. Perhatikan gambar form tradisional berikut:

Contoh form tradisional yang akan dikonversi menjadi bentuk tabel berbentuk kolom dan baris

Kasus di atas adalah mengambil contoh dari perusahaan penyewaan properti ‘DreamHome’. Kita akan menganalisa dari form tradisional yang digunakan di perusahaan ‘DreamHome’. Dari hasil observasi dan analisa terhadap form tersebut, kemudian kita konversi menjadi bentuk tabel seperti berikut:

Tabel hasil konversi dari form tradisional sebelumnya (tabel yang belum dinormalisasi)

Gambar tabel di atas tersebut adalah dalam bentuk unnormalized table, atau tabel/relasi yang belum dilakukan normalisasi. Dalam contoh tersebut, nama relasi/tabel adalah 'ClientRental'. Dan klien dengan clientNo CR76 yang bernama John Kay, sudah pernah bertransaksi dua kali dari hasil observasi form tersebut. Sehingga klien dengan clientNo CR76 yang bernama John Kay memiliki bagian yang berulang (perhatikam atribut-atribut porpertyNo, pAddress, rentStart, rentFinish, rent, ownerNo, oName) untuk klien yang sama. Sehingga data tentang clientNo dan cName terlihat kosong atau tidak dituliskan pada transaksi yang kedua, karena akan berisi data yang sama (berulang). Demikian juga untuk klien dengan clientNo CR56 yang bernama Aline Stewart. Jadi tabel tersebut disebut dalam kondisi UNF (atau unnormalized form) apabila tabel tersebut berisi satu atau lebih bagian yang berulang. Tabel semacam itu biasanya dihasilkan dari proses mengonversi form tradisional menjadi suatu tabel dalam bentuk kolom dan baris.

Dari UNF ke 1NF

Untuk mengonversi tabel dari UNF ke 1NF (normal bentuk pertama), yang perlu kita lakukan adalah: 1) menunjuk satu atau beberapa atribut untuk dijadikan sebagai ‘key’ dalam tabel UNF tersebut, 2) kemudian mengidentifikasi bagian yang berulang dalam tabel UNF tersebut, 3) dan setelah mengidentifikasi bagian yang berulang, kita perlu menghilangkan bagian yang berulang tersebut.

Untuk mengonversi tabel dari UNF menjadi 1NF, yang berarti juga menghilangkan bagian yang berulang dalam tabel UNF, ada dua cara, yaitu: 

1. Dengan mengisi data yang benar ke kolom/baris yang kosong yang berisi data yang berulang. Cara ini disebut dengan “flattening”. 
2. Memisahkan data yang berulang bersama dengan ‘copy’ atribut yang kita tunjuk sebagai ‘key’ ke relasi/tabel yang lain. 

Contoh dari cara yang pertama adalah seperti dalam gambar berikut:

UNF ke 1NF dengan menggunakan cara pertama atau "flattening"

Contoh dari cara yang kedua adalah seperti gambar dibawah ini:

UNF ke 1NF dengan cara yang kedua, memisahkan bagian yang berulang ke tabel/relasi baru beserta 'copy' dari 'key' nya

Hasil relasi dari UNF ke 1NF dengan cara yang kedua. Yang digarisbawah adalah atribut yang menjadi 'key'

Semua contoh tabel/relasi di atas adalah dalam keadaan 1NF. Jadi secara definisi, 1NF adalah relasi dimana interseksi/perpotongan antara kolom-dan-baris hanya berisi tepat satu nilai data saja.

Dari 1NF ke 2NF

Untuk mengonversi dari 1NF ke 2NF kita akan menggunakan contoh tabel/relasi ‘ClientRental’ pada gambar di atas (lihat gambar tabel 'ClientRental' di atas). Kemudian yang kita lakukan adalah mengidentifikasi semua ketergatungan fungsional (functional dependencies). Berikutnya, untuk mengonversi dari 1NF-ke-2NF, fokus perhatian kita adalah pada ada atau tidaknya ketergantungan parsial/sebagian (partial dependency). Apabila kita menemukan adanya ketergantungan parsial/sebagian (partial dependency), maka kita harus menghilangkan ketergantungan parsial/sebagian tersebut. Cara menghilangkan ‘partial dependency' adalah dengan memindahkan atribut yang bergantung secara parsial tersebut menjadi relasi yang baru beserta copy dari atribut atau determinant yang menjadi bagian dari primary key pada relasi asalnya. Bila semua relasi sudah tidak mengandung ‘partial dependency’ maka semua relasi sudah berada dalam kondisi 2NF (atau bentuk normal kedua). Selengkapnya tentang konsep ketergantungan antar atribut dalam relasi bisa dipelajari dalam posting tulisan tentang: “Konsep Ketergantungan Fungsional, Normalisasi, dan Identifikasi Primary Key dalam Perancangan Sistem Database”.

Coba perhatikan kembali gambar tabel/relasi ‘ClientRental’ di atas, dan kemudian perhatikan proses identifikasi seperti dalam gambar di bawah berikut ini:

Proses identifikasi ketergantungan fungsional (functional dependencies) pada tabel/relasi 'ClientRental'

Hasil identifikasi berbagai ketergantungan fungsional (functional dependencies) antar atribut dalam tabel/relasi 'ClientRental'

Dari hasil proses identifikasi seperti di atas kita temukan ada dua ketergantungan parsial/sebagian (partial dependency), yaitu pada fd2 dan fd3. Jadi untuk mengonversi tabel/relasi ‘ClientRental’ ke dalam bentuk relasi-relasi dalam 2NF (bentuk normal kedua), kita perlu memecah atau memindahkan atribut-atribut yang diidentifikasi dalam fd2 dan fd3 menjadi relasi/tabel baru beserta ‘copy’ dari atribut yang menjadi bagian dari ‘primary key’ dari tabel/relasi aslinya. Setelah kita pecah atau pindahkan, hasil relasi-relasinya adalah seperti dalam gambar berikut:

Gambar tabel-tabel hasil proses normalisasi 1NF ke 2NF

Gambar relasi-relasi hasil proses normalisasi 1NF ke 2NF (garisbawah adalah primary key)

Jadi setelah mengalami pemecahan/pemisahan, ketiga relasi di atas tersebut sudah dalam keadaan 2NF (bentuk normal kedua), karena tidak ada ketergantungan parsial antar atribut dalam suatu tabel/relasi. Apabila dalam tabel/relasi yang kita analisa tidak terdapat ketergantungan parsial (partial dependency) sejak awal, berarti tabel/relasi tersebut sudah berada pada keadaan 2NF.

Dari 2NF ke 3NF

Untuk mengonversi dari 2NF dari ke 3NF (bentuk normal ketiga), caranya adalah sama dengan langkah di atas (dari 1NF ke 2NF). Hanya saja yang harus kita identifikasi adalah ada atau tidaknya ketergantungan transitif (transitive dependency) antar atribut dalam suatu relasi. Kita akan analisa dan identifikasi dari ketiga tabel/relasi yang sudah berada dalam 2NF di atas, yaitu tabel/relasi ‘Client’, ‘Rental’, dan ‘PropertyOwner’. Hasil proses identifikasi adalah seperti gambar di bawah berikut:

Proses identifikasi ketergantungan fungsional pada relasi 'Client', 'Rental', dan 'PropertyOwner'

Pada fd5 dan fd6 ada tanda ‘ (fd5’ dan fd6’) yang artinya bahwa ada perubahan atribut dalam ketergantungan fungsional yang diidentifikasi oleh fd5 dan fd6. Perubahan ini disebabkan karena ada proses normalisasi pada level sebelumnya, yaitu dari 1NF ke 2NF. Dampak dari proses tersebut adalah perubahan atribut (karena atributnya dipindah ke tabel/relasi baru) yang mengalami ketergantungan fungsional yang teridentifikasi pada proses sebelumnya.

Dari hasil identifikasi di atas, ternyata kita temukan adanya ketergantungan transitif (transitive dependency), yaitu pada fd4 (perhatikan pada tabel PropertyOwner). Jadi untuk mengonversi ke keadaan 3NF, kita harus menghilangkan ketergantungan transitif (transitive dependency) tersebut. Cara menghilangkan ketergantungan transitif sama seperti langkah sebelumnya, yaitu atribut-atribut yang berada dalam ketergantungan transitif (transitive dependency) dipindahkan ke tabel/relasi yang baru beserta ‘copy’ dari atribut yang menjadi ‘determinant’ pada tabel/relasi aslinya.

Hasil dari pemecahan/pemindahan atribut yang menjadi ketergantungan transitif tersebut adalah seperti berikut di bawah ini:

Hasil pemecahan/normalisasi 2NF ke 3NF dari tabel 'PropertyOwner' menjadi tabel 'PropertyForRent' dan 'Owner'

Hasil relasi proses normalisasi 2NF ke 3NF pada relasi 'PropertyOwner' menjadi 'PropertyForRent' dan 'Owner'

Setelah semua table/relasi mengalami pemecahan dan tidak lagi ditemukan ketergantungan parsial/sebagian dan ketergantungan transitif, maka semua tabel/relasi sudah bisa dikatakan dalam keadaan 3NF (bentuk normal ketiga). Apabila sejak awal ada relasi yang tidak mengandung ketergantungan parsial maupun ketergantungan transitif, berarti tabel/relasi tersebut bisa dikatakan sudah berada dalam keadaan 3NF

Jadi hasil akhir semua tabel/relasi setelah mengalami proses normalisasi adalah seperti gambar di bawah berikut ini:

Hasil akhir tabel-tabel setelah proses normalisasi dari 1NF-2NF-dan-3NF

Hasil akhir relasi-relasi setelah proses normalisasi dari 1NF-2NF-dan-3NF (garis bawah adalah primary key)

Tahap demi tahap pemecahan tabel/relasi mulai dari 1NF-2NF-dan-3NF

Link-link terkait proses normalisasi dalam perancangan sistem basis data secara urut untuk dibaca adalah seperti berikut:

1. Tujuan dan Manfaat Normalisasi dalam Perancangan Database
2. Konsep Ketergantungan Fungsional, Normalisasi, dan Identifikasi Primary Key dalam Perancangan Sistem Database
3. Contoh proses normalisasi relasi dari UNF – 1NF – 2NF – dan 3NF
4. Kapan atau dimana normalisasi digunakan dalam perancangan sistem basis data?