Normalisasi

Tabel-tabel dalam sebuah database relational apakah yang dibuat dari ER atau pun UML, kadang kala ada beberapa masalah yang dihadapai dalam hal performan, integritas dan pengaturan. Mungkin saja sebuah database dibuat hanya dengan sebuah table yang berisi kolom. Hal ini tentu saja akan menimbul banyak redudansi data. Perubahan data dan penghapusan data juga tentu saja akan menghabiskan banyak resource.

Relasi sebuah database secara teoritis harus memenuhi normal form (bentuk normal). Setiap normal form akan merepresentasikan sekumpulan peraturan yang akan semakin ketat dengan semakin tingginya normal form. Makin tinggi normal form maka makin baik rancangan relasinya. Pada gambar berikut ini kita dapat ada enam tingkatan normal. Jika sebuah normal form yang berada di dalam maka normal form yang diluar/sebelumnya telah dipenuhi.

Pada umumnya, jika sebuah perancangan relasi sudah mencapai bentuk normal ketiga (3NF), maka masalah-masalah desain yang buruk sudah dapat diselesaikan. Untuk bentuk normal yang berada di atasnya seperti Boyce-Codd, bentuk normal keempat, kelima dan keenam hanya digunakan untuk memecahkan masalah-masalah yang jarang ditemukan. Perubahan dari satu bentuk normal ke bentuk normal berikutnya sangat mudah dimengerti secara konsep.

Bentuk Normal Pertama (1NF)

Aturan yang harus dipenuhi oleh sebuah bentuk normal pertama atau first normal form adalah :

  1. Data disimpan dalam bentuk tabel dua dimensi

  2. Semua data dalam tabel harus bersifat atomic atau single value

Contohnya, jika kita menyimpan data seorang dosen yang dilengkapi dengan kemampuan bahasa yang dikuasainya. Tabel ini juga menyimpan data dari nama dan tanggal lahir anak-anak dosen tersebut. Karena setiap dosen kemungkinan memiliki kemampuan bahasa lebih dari satu sehingga kolom bahasa menjadi tidak bersifat atomic. Contoh lainnya yang dapat kita lihat adalah pada kolom nama anak dan tanggal lahir anak, karena dosen ada kemungkinan memiliki lebih dari satu anak maka kolom nama anak juga ada kemungkinan tidak bersifat atomic. Disebabkan seorang dosen bisa jadi memiliki lebih dari satu anak maka kolom tanggal lahir anak juga ada kemungkinan tidak bersifat atomic. Untuk lebih jelasnya dapat kita lihat pada tabel berikut:

nip

nama_depan

Bahasa

nama_anak

tanggal_lahir_anak

1002

Sayed Muchallil

Indonesia, Inggris

Sayed, Syarifah

2012/04/12, 2011/02/23

1004

Tarmizi

Indonesia,Jerman

Ilyas, hendri

2004/03/07, 2008/03/13

1007

Alfian

Indonesia,Mandarin

Heni

2005/08/17

1009

Agus

Indonesia,Jepang

Abbas, Ria

2001/05/23, 2005/04/07

1010

Rahmad

Indonesia

Null

null

Ada beberapa masalah dari desain tabel di atas, yang pertama adalah pencarian data akan sedikit lama, karena jika kita mau mencari dosen yang anaknya lahir sebelum tahun 2005, maka kita harus membuat sebuah metode untuk mengekstrak data tanggal lahir tersebut. Masalah lainnya adalah akan sangat sulit menentukan tanggal lahir dari masing-masing anak, karena tidak ada ketentuan tertentu dalam input data tanggal lahir dan nama anak.

Mengatasi multivalue/composite kolom

untuk menjadikan tabel di atas ke dalam bentuk normal pertama, maka semua tabel yang bersifat non-atomic harus dijadikan bersifat atomic. Ada dua cara menangani maslah ini.

  1. Memisahkan semua kolom yang bersifat multivalue/composite menjadi atomic.

    Pemisahan kolom seperti pada tabel di bawah ini akan memisahkan kolom bahasa menjadi dua kolom, kolom anak dan tanggal lahir juga masing-masing menjadi dua kolom. Perubahan seperti ini pada dasarnya sudah memenuhi persyaratan untuk disebut bentuk normal pertama, karena non-atomic kolom sudah tidak ada lagi. Namun, pemisahan ini justru menimbulkan masalah baru.

  1. Untuk kemampuan bahasa, desain ini cuma mampu menampung kemampuan bahasa sampai dengan dua bahasa saja. Jika ada dosen yang mampu menguasai tiga bahasa maka desain tabel ini tidak akan bisa menampungnya.

  2. Untuk jumlah anak desain ini cuma mampu menampung sampai dengan dua anak saja. Jika ada dosen yang memiliki tiga anak maka desain tabel ini tidak akan bisa menampungnya.

  3. Dari segi storage atau penyimpanan tabel ini juga akan terlihat banyak data yang berisi dengan nilai null. Jika seoarang dosen hanya mampu menguasai satu bahasa dan dosen yang memiliki anak kurang dari dua.

  4. Pencarian data anak juga akan sedikit merepotkan karena kita harus membuat query ( perintah SQL ) yang lebih spesifik dan harus dimasukkan semua kolom yang dicari. Misalkan, kita akan mencari siapa saja dosen yang mampu menguasai bahasa jerman, maka query yang dibuat harus mampu mencari ke semua kolom yang mengandung bahasa, yaitu bahasa1 dan bahasa2.

nip

nama

bahasa1

bahasa2

anak1

tglLahir1

anak2

tglLahir2

1002

Muchallil

Indonesia

inggris

Sayed

2011/02/23

syarifah

2012/04/12

1004

Tarmizi

Indonesia

jerman

Ilyas

2004/03/07

hendri

2008/03/13

1007

Alfian

Indonesia

mandarin

Heni

2005/08/17

null

null

1009

Agus

Indonesia

jepang

Abbas

2001/05/23

ria

2005/04/07

1010

Rahmad

Indonesia

null

null

null

null

null

  1. Membuat tabel baru untuk semua data yang bersifat non-atomic (multivalue/composite)

    Metode ini dirasa lebih tepat karena dapat mengatasi masalah-masalah yang ditimbulkan oleh metode pertama tadi. Dengan metode ini, maka jumlah bahasa yang dikuasai oleh dosen tidak akan ada batasan, begitu juga dengan jumlah anak dan tanggal lahirnya. Kelebihan lainnya dengan metode ini adalah tidak perlunya mengisi data yang berisi null value. Tabel berikut ini akan memperlihatkan tabel-tabel yang sudah dipisahkan dari tabel di atas

Tabel Dosen

Nip

nama

1002

Muchallil

1004

Tarmizi

1007

Alfian

1009

Agus

1010

Rahmad

Tabel Bahasa

Kode

Bahasa

1

Indonesia

2

Inggris

3

Jerman

4

Mandarin

5

Jepang

Tabel Anak

Nip

anak

tglLahir

1002

Sayed

2011/02/23

1004

Ilyas

2004/03/07

1007

Heni

2005/08/17

1009

Abbas

2001/05/23

1002

syarifah

2012/04/12

1004

hendri

2008/03/13

1009

ria

2005/04/07

Pembuatan tabel seperti ini juga akan memudahkan dalam mencari nama anak karena semua nama anak terdapat dalam satu kolom.

Masalah pada Bentuk Normal Pertama (1NF)

Walaupun pada bentuk normal pertama semua data sudah bersifat atomic namun ada beberapa masalah yang harus ditangani. Misalkan tabel pemesanan di bawah ini

noPlg

nama

alamat

no_faktur

tglBeli

kodeBarang

namaBarang

harga

Pertama sekali kita akan menentukan primary key, kalau primary key hanya no pelanggan, maka data barang tidak akan akan dapat dimengerti dari kode pelanggan saja. Kita juga tidak bisa menggunakan kodeBarang saja sebagai primary key, karena kode Barang akan selalu berulang jika barang yang sama dipesan beberapa kali, sehingga akan terjadi perulangan primary key dan ini tidak akan diijinkan oleh RDBMS. Sehingga primary key yang terbaik adalah gabungan dari no Pelanggan dan kodeBarang. Dari penyelesaian di atas, timbul beberapa masalah.

  1. kita tidak dapat menambah pelanggan jika pelanggan tersebut belum membeli barang. Karena primary key yang berupa kode barang tidak dapat diisi. Sementara, sebuah primary key tidak boleh kosong.

  2. Begitu juga untuk data barang, kita tidak dapat menambah data barang jika belum ada pelanggan yang membeli barang tersebut. Karena salah satu primary key, yaitu noPelanggan belum terisi.

Masalah lain yang ditimbulkan dari bentuk normal pertama adalah dalam penghapusan data. Kita dapat melihat kembali pada tabel pemesanan di atas, jika kita hanya memiliki sebuah barang yang dibeli oleh seorang pelanggan kemudian pelanggan tersebut mengembalikan barang tersebut. Maka, kita harus menghapus record tentang pemesanan barang tersebut. Sehingga data barang yang hanya satu-satunya itu juga akan ikut terhapus.

Jika seorang pelanggan hanya pernah berbelanja satu kali dan kemudian mengembalikannya maka data tentang pelanggan itu juga akan hilang ketika record pemesanan tersebut dihapus.

Maka untukl mengatasi masalah-masalah ini maka diperlukan bentuk normal kedua.

Bentuk Normal Kedua (2NF)

adapun persyaratan untuk dilakukan perubahan menjadi bentuk normal kedua adalah :

  1. tabel sudah berada pada bentuk normal pertama

  2. semua data yang bukan primary key bergantung penuh (Functional dependency) pada seluruh primary key

Pengertian Functional Dependency

Functional Dependency adalah ketergantungan sepenuhnya untuk data yang bukan primary key terhadap primary key. Kita misalkan, pada tabel dosen di atas, setiap nama dosen akan tergantung sepenuhnya pada nip yang merupakan primary key dari tabel dosen. Atau dengan contoh lain pada tabel pelanggan seperti di bawah ini, bahwa alamat, kota, kode pos, dan no telepon serta nama pelanggan ditentukan oleh kode pelanggan. Sehingga dapat kita sebutkann bahwa no pelanggan akan menentukan nama pelanggan, alamat, kota, kode pos dan no telepon.

noPlg

nama

alamat

kota

kodePos

noTelepon

Sehingga dapat kita tuliskan

noPlg → nama, alamat, kota. KodePos, noTelepon

Functional dependency tidak harus berlaku sebaliknya. Misalkan nama seorang pelaanggan tidak akan menentukan noPlg karena ada kemungkinan beberapa pelanggan memiliki nama yang sama walupun sebenarnya orang yang berbeda.

Penggunaan Functional Dependency untuk Bentuk Normal Kedua

setelah kita menentukan functional dependency dengan tepat maka kita dapat membuat bentuk normal kedua dari tabel tersebut. Misalkan pada tabel pemesanan yang kita sebutkan di atas. Maka no Pelanggan akan menentukan nama pelanggan dan alamat. Kode barang akan menentukan nama barang dan harga barang. No faktur akan menentukan tanggal dan no pelanggan. Terakhir, kita membutuhkan tabel baru yang akan kita buat untuk pemesanan barang, untuk tabel ini maka order no faktur dan kode barang menjadi primary key dan menentukan harga total dan jumlah Maka tabelnya menjadi seperti berikut

noPlg

nama

alamat

kodeBarang

namaBarang

Harga

noFaktur

tanggalPemesanan

kodePelanggan

noFaktur

kodeBarang

Jumlah

HargaTotal

Dengan perancangan tabel seperti di atas maka beberapa masalah yang ditimbulkan pada bentuk normal pertama dapat diatasi.

  1. kita dapat memasukkan data pelanggan tanpa harus menunggu pelanggan membeli barang terlebih dahulu

  2. kita dapat memasukkan data barang tanpa harus menunggu barang tersebut dibeli atau dipesan oleh pelanggan.

  3. Penghapusan sebuah record pada tabel pemesanan tidak akan menghilangkan data pelanggan dan data barang.

  4. Perubahan data pelanggan tidak akan mempengaruhi data lainnya.

Bentuk Normal Ketiga (3NF)

adapun persyaratan untuk dilakukan perubahan menjadi bentuk normal ktiga adalah :

  1. tabel sudah berada pada bentuk normal kedua

  2. tidak adanya ketergantungan transitive (transitive dependency).

Pengertian Transitive Dependency

Secara umum dapat didefinisikan sebagai ketergantungan fungsional antara dua buah atribut yang bukan primary key atau candidate key. Ketergantungan transitif dapat terjadi jika memiliki ketergantungan fungsional seperti di bawah ini A → B, C, D, E dan C → E

kalau kita lihat pada contoh di tabel di bawah, kita dapat menyimpulkan bahwa nim akan menjadi penentu nama, ipk dan predikat karena nim adalah primary key. Walaupun predikat tergantung kepada nim, tapi sebenarnya predikat ditentukan oleh IPK, karena IPK tergantung pada nim maka secara tidak langsung predikat juga tergantung pada nim.

nim

nama

ipk

predikat

Hal di atas adalah penggambaran tentang ketergantungan transitif. Oleh karena itu, untuk merubah tabel di bawah ini menjadi bentuk normal ketiga, maka perlu dibuatkan sebuah tabel lain dengan atribut ipk dan predikat

Nim

Nama

ipk

ipk

predikat

Bentuk Normal Boyce-Codd (BCNF)

Untuk sebagian besar perancangan tabel-tabel dalam sebuah database jika sudah mencapai bentuk normal ketiga dianggap sudah cukup bagus. Namun, ada kalanya kita melihat walaupun sudah sampai bentuk normal ketiga ada beberapa anomali yang terjadi. Untuk itulah boyce-Codd, bentuk normal keempat(4NF), bentuk normal kelima (5NF) dan bentuk normal keenam (6NF) dibutuhkan.

Untuk lebih memahami tentang bentuk normal boyce-code kita akan mencoba mempelajari sebuah contoh tabel. Sebuah perusahaan ingin menambah sebuah tabel di dalam database perusahaan tersebut yang berfungsi untuk menangani atau menyimpan data tentang jadwal kerja setiap pegawai. Setiap pegawai akan bekerja selama satu sampai empat jam. Dalam setiap shift-nya seorang pegawai juga akan ditugasi untuk menjaga pos-pos tertentu misalnya gudang atau bagian front office. Hanya boleh ada satu pegawai ditiap pos untuk tiap shift.

Perkiraan tabel tambahan untuk database perusahaan di atas kira-kira seperti berikut

ID_pegawai

Tanggal

shift

pos

work_shift

Sesuai dengan aturan yang diinginkan oleh perusahaan, bahwa hanya ada satu orang untuk satu pos setiap shiftnya. Maka, ada dua kemungkinan primary key untuk tabel ini.

  1. id_pegawai+shift+pos
  2. tanggal+shift+pos

kalau kita lihat functional dependency adalah sebagai berikut

id_pegawai+shift+pos → post dan work_shift

tanggal+shift+pos → id_pegwai, work-shift?

Yang perlu diingat bahwa perancangan tabel ini sudah sesuai denga permintaan dari perusahaan tersebut bahwa hanya ada satu orang yang bertugas menjaga sebuah pos unutk setiap shift.

Tabel jadwal jaga ini sebenarnya sudah melakukan overlapping terhadap candidate key. Kita bisa melihat pada diagram functional dependency di atas bahwa kedua candidate key memiliki tanggal dan shift sehingga disebut overlapping. Bentuk normal Boyce-Codd adalah berfungsi untuk menangani masalah-masalah seperti ini. Adapun persyaratan untuk sebuah tabel atau relasi baru bisa disebut berada dalam bentuk normal Boyce-Codd adalah :

  1. tabel sudah berada dalam bentuk normal ketiga

  2. setiap atribut kunci merupakan candidate key