Mengenali Bentuk Normal Kedua atau Second Normal Form (2NF) di Sebuah Tabel

Setelah sebuah tabel memenuh syarat bentuk normal pertama, proses selanjutnya adalah memastikan tabel itu memenuhi syarat bentuk normal kedua atau second normal form (2NF). Bentuk normal kedua menjadikan sebuah rancangan tabel menjadi semakin efisen dan tentu saja memori penyimpanan menjadi semakin kecil.
Sebuah tabel telah memenuhi syarat bentuk normal kedua jika:

Tabel telah memenuhi syarat bentuk normal pertama, data yang tidak langsung tergantung pada primary key dibuatkan tabel baru yang sesuai dengan syarat bentuk normal pertama.

Sebuah tabel harus berisi data yang mewakili entitas tunggal. Dengan demikian, dalam sebuah tabel, tidak ada record/baris yang menjadi bagian dari entitas lain. Bila di dalam tabel itu ada yang menjadi bagian dari entitas lain, maka kita harus membuat tabel untuk entitas lain itu. Tabel untuk entitas lain ini kemudian digunakan sebagai referensi pada tabel yang menjadi entitas tunggal.

Mengidentifikasi entitas

Pada Gambar 1 tblBioDataSebelum2NF telah memenuhi syarat bentuk normal pertama. Tabel itu mempunyai kolom Bagian, yang digunakan untuk menunjukkan nama bagian, divisi, department, seksi, atau semacam itu. Dalam form/tabel Bio Data pegawai, nama/kolom Bagian (atau Departemen) ini akan selalu ada, tidak mungkin tidak ada. Jadi, dapat dikatakan, kolom ini sama pentingnya dengan kolom Nama Lengkap pegawai. Dalam konteks ini, nama Bagian adalah entitas lain yang seharusnya berdiri sendiri dalam sebuah tabel lain. Karena, sebuah divisi, departemen atau bagian dalam sebuah perusahaan pasti mempunyai berbagai macam atribut yang melekat pada dirinya. Atribut itu misalnya nama kepala divisi/departemen/bagian, deskripsi ringkas, nomor telp ekstension, nama bagian yang lebih tinggi dalam mana kita harus melapor dan bertanggung jawab, dan lain sebagainya.

Gambar 1 Datasheet view dari tblBioDataSebelum2NF yang memerlukan normalisasi karena ada entitas lain (kolom Bagian)

Pada Gambar 1, kolom Bagian tersimpan sebagai nama bagian (bukan kode bagian). Bila ada sebuah bagian berganti nama, maka nama bagian di atas harus diganti secara manual satu per satu. Hal ini akan menimbulkan masalah, karena pergantian nama bagian yang dilakukan secara manual bisa mengakibatkan kesalahan. Misalkan, nama bagian HRD berganti nama menjadi Personalia. Contoh lainnya, pegawai bernama Rosalyna berganti bagian karena dimutasi, dari Cabang Bandung menjadi Marketing dan Sales. Selan itu, cara manual seperti ini juga memakan waktu.

Untuk meminimalkan kesalahan yang mungkin terjadi, kita harus membuat sebuah tabel lain yang digunakan untuk menyimpan data Bagian. Tabel lain ini menjadi entitas tunggal untuk nama bagian dari si pegawai bekerja.

Untuk membuat tabel Bagian, ikuti langkah berikut ini:

1. Klik Create >> Tables >> Table Design
2. Isikan data berikut ini:
   
   1. Field Name= nomorBagian
      
      1. Data Type= AutoNumber
      2. Description= Nomor Bagian/Departemen
      3. Caption= Nomor Bagian
   2. Field Name= namaBagian
      
      1. Data Type= ShortText
      2. Description= Nama Bagian/Departemen
      3. Field Size= 50
      4. Caption= Nama Bagian/Departemen
3. Atur field nomorBagian sebagai Primary Key
4. Simpanlah tabel ini dengan nama tblBagian

Kita dapat menambahkan berbagai macam field dan properti yang sesuai pada tabel tblBagian. Jadi, silakan menambah field yang diperlukan pada tabel ini. Bila tblBagian diisi dengan data, Datasheet View dapat dilihat di Gambar 2 (tabel sebelah kanan) di bawah ini.

Gambar 2 Datasheet view dari tblBioDataSetelah2NF setelah pemecahan entitas lain pada kolom Bagian

Gambar 2 di atas sekaligus juga menjelaskan tblBioDataSebelum2NF yang telah mengalami proses normalisasi bentuk normal kedua (2NF) menjadi tabel tblBioDataSetelah2NF, di mana kolom bagian telah berganti menjadi angka-angka yang menunjukkan nomor bagian yang ada di tabel tblBagian.

Apakah kita perlu melakukan normalisasi kedua atau tetap menyatu (denormalisasi)?

Secara umum, kita harus memastikan bahwa sebuah tabel telah memenuhi syarat bentuk normal kedua untuk meningkatkan efisiensi database yang dikembangkan. Tetapi, adakalanya, kita tidak melakukan hal itu. Atau dengan kata lain, kita justru melakukan denormalisasi.

Ada berbagai macam situasi di mana kita memilih untuk melakukan normalisasi kedua (bentuk normal kedua) atau membiarkan sebuah field tetap menyatu pada sebuah tabel. Intinya, dengan menggunakan salah satu cara, efisiensi database tercapai dan kinerja meningkat. Berikut ini adalah beberapa contoh kasus.

Sebuah tabel biodata pegawai seperti yang telah kita desain pasti mempunya sekelompok field yang berhubungan dengan alamat. Alamat itu sendiri terdiri dari nomor rumah, nama jalan, nama kelurahan, nama kecamatan, kode pos, provinsi. Bisa jadi, dengan hanya menggunakan field kode pos saja, kita dapat mengetahui kelurahan/desa dari sebuah alamat beserta nama kota/kabupaten dan provinsi. Artinya, dengan melakukan normalisasi, kita bisa menghilangkan desa/kelurahan, kota/kabupaten, dan provinsi sekaligus. Untuk mencapai hal ini, kita harus membuat tabel yang berisi kode pos di seluruh Indonesia. Nah pertanyaannya, perlukah kita membuat tabel kode pos seluruh Indonesia?

Jika bekerja di instansi pemerintahan yang jangkauannya sampai ke tingkat desa, hal ini mungkin perlu karena dengan menggunakan satu database, kita bisa langsung mengetahui kode pos, desa/kelurahan, kota/kabupaten, dan provinsi sekaligus.

Tetapi, jika bekerja di sebuah perusahaan yang hanya mempunyai kurang dari 5 kantor, jumlah pegawai tidak lebih dari 200 orang, dan tidak menyebar ke seluruh penjuru pulau misalnya, maka membuat tabel tersendiri yang digunakan untuk menuliskan kode pos, desa/kelurahan, kota/kabupaten, dan provinsi sekaligus rasanya tidak perlu. Pada kasus ini, kita tidak perlu membuat tabel kode pos tersendiri, tetapi dapat menyatukan field yang berkaitan dengan desa/kelurahan, kota/kabupaten, dan provinsi pada satu tabel yang sama.

Jadi, pertimbangkanlah dengan matang terlebih dahulu untuk melakukan normalisasi bentuk kedua.