Tujuan dan Manfaat Normalisasi dalam Perancangan Database

Apakah yang dimaksud dengan normalisasi dalam perancangan basis data (database design)? 

Kata ‘normal’ menurut kamus besar bahasa Indonesia artinya adalah: menurut aturan atau menurut pola yang umum; sesuai dan tidak menyimpang dari suatu norma atau kaidah; sesuai dengan keadaan yang biasa; tanpa cacat; tidak ada kelainan. Dengan kata lain, ‘normal’ adalah keadaan yang baik, standar, dan menjadi acuan. Sedangkan kebalikannya, berarti ada suatu keadaan yang tidak baik, cacat, atau jelek, yang bisa dikatakan sebagai ‘tidak normal’. Jadi normalisasi dalam pengertian umum adalah proses untuk menormalkan sesuatu atau menjadikan normal sesuatu yang tidak normal. Atau dengan kata lain, adalah suatu proses untuk mengubah dari yang tidak normal atau jelek menjadi normal atau baik. 

Dalam perancangan basis data (atau database design), pengertian normalisasi kurang lebih adalah sama dengan pengertian umum di atas, hanya saja konteksnya adalah lebih spesifik, yaitu konteks tentang relasi-relasi atau tabel-tabel dalam database. [Baca juga: Siklus Hidup Pengembangan Sistem Basis Data]

Jadi normalisasi dalam perancangan basis data (database design) adalah proses dan/atau teknik untuk membuat relasi-relasi atau tabel-tabel yang baik (atau yang cocok atau yang standar atau menjadi acuan atau yang terdesain dengan baik, dsb) dalam database yang akan digunakan untuk mendukung data requirement dalam suatu perusahaan.

Karena itu, dalam perancangan sistem basis data, relasi-relasi (atau tabel-tabel) yang normal (atau baik) tentu memiliki ciri-ciri supaya bisa dikatakan normal atau baik. Relasi-relasi yang baik tersebut akan memiliki beberapa ciri-ciri seperti berikut:
  • Memiliki jumlah atribut (atau kolom atau field) yang minimal yang digunakan dalam mendukung data requirement suatu perusahaan
  • Memiliki atribut-atribut yang memiliki asosiasi atau relationship atau kaitan/hubungan yang dekat antar atribut dalam relasi tersebut.
  • Redundancy yang minimal,  yang berarti bahwa masing-masing atribut hanya perlu disajikan satu kali saja, kecuali hanya pada atribut-atribut yang akan digunakan sebagai foreign keys (kunci asing), karena atribut-atribut yang digunakan sebagai foreign keys (kunci asing) akan digunakan untuk menghubungkan antar relasi dalam database.
Di dalam posting tulisan tentang: "Konsep Ketergantungan Fungsional, Normalisasi, dan Identifikasi Primary Key dalam Perancangan Sistem Database" , sudah disebutkan bahwa secara teori, bentuk normal suatu relasi bisa sampai ke tingkat lima 5NF, yaitu 1NF – 2NF – 3NF/BCNF – 4NF – 5NF. Tetapi secara praktik dalam dunia nyata, relasi dalam suatu database sudah dibilang baik kalau sudah mencapai 3NF (bentuk normal ketiga). Gambar tingkatan normalisasi bisa dilihat seperti gambar di bawah ini.
Tingkatan Normalisasi



Mengapa perlu dilakukan normalisasi dalam merancang relasi-relasi dalam sistem basis data?
Tadi diatas sudah dikatakan bahwa normalisasi adalah proses untuk membuat relasi-relasi yang baik atau normal. Dan tentu saja, relasi-relasi yang normal akan memiliki manfaat dan juga bisa terhindar dari beberapa problem yang biasanya terjadi pada relasi yang tidak normal. Berikut dibawah ini adalah bagaimana normalisasi memberi manfaat dan bisa mengatasi problem-problem yang biasanya terjadi pada relasi-relasi yang tidak dinormalisasi.

Manfaat yang diperoleh dengan memiliki relasi-relasi yang baik (atau normal) adalah: 1) database akan mudah untuk diakses dan dikelola, 2) akan menghemat space/ruang dalam komputer karena update data yang disimpan dalam database dilakukan dengan operasi yang minimum dan menghindari reduncancy data, dan ini juga berarti menghemat ‘cost’, 3) menghindari problem-problem update anomalies terhadap data yang disimpan dalam database sehingga terhindar dari inkonsistensi data.

Meskipun salah satu maksud normalisasi adalah menghilangkan data redundancy, tetapi tentu saja dalam basis data relasional tetap mengandung data redundancy dalam bentuk copy dari primary keys (kunci utama) atau candidate keys (kunci kandidat) yang akan berfungsi sebagai foreign keys (kunci asing) untuk menjadi penghubung antar relasi dalam database/basis data. 

Ilustrasi tentang data redundancy dan problem-problem yang terkait dengan anomali-anomali ketika update data

Berikut dibawah ini, adalah ilustrasi terkait dengan data redundancy dengan membandingkan relasi ‘Staff’ dan ‘Branch’ dengan relasi ‘StaffBranch’.


Relasi 'StaffBranch'
Relasi ‘StaffBranch’ di atas diilustrasikan sebagai alternatif dari relasi ‘Staff’ dan ‘Branch’. Jadi relasi-relasi diatas adalah:
Catatan: atribut dengan garis-bawah adalah primary key.

Pada relasi ‘StaffBranch’ terdapat redundancy data; yaitu tentang detil/alamat (lihat: atribut bAddress) dari suatu cabang selalu diulang untuk setiap anggota staff yang terletak di cabang/branch tersebut. 

Sebaliknya, detil/alamat cabang/branch hanya muncul satu kali saja pada relasi ‘Branch’, dan hanya nomor cabang (branchNo) diulang pada relasi ‘Staff’ untuk menyatakan dimana lokasi setiap anggota staff. Relasi –relasi yang memiliki data yang redundan akan berpotensi mengalami apa yang disebut dengan update anomalies. Update anomalies terdiri dari tiga jenis anomali, yaitu 1) insertion anomaly atau anomali ketika insert data, 2) deletion anomaly atau anomali ketika delete data, 3) modification anomaly atau anomali ketika memodifikasi atau mengubah data.

Anomali pada insert data

Ada dua jenis untuk anomali terhadap insert data. Coba mari kita perhatikan relasi ‘StaffBranch’
  • Untuk memasukkan atau insert detil dari setiap anggota baru dari staff ke relasi ‘StaffBranch’, kita pasti memasukkan detil cabang (lihat: atribut bAddress) dimana staff tersebut berada. Contohnya, untuk memasukkan atau insert detil staff baru yang berada di lokasi cabang nomor B007, kita pasti menginputkan detil/alamat yang benar tentang cabang nomor B007 (lihat: atribut bAddress) supaya detil/alamat selalu konsisten untuk semua nilai cabang B007 di semua tuple/baris lainnya di relasi ‘StaffBranch’. Sehingga pada relasi ‘StaffBranch’ ada potensi terjadi inkonsistensi data, karena detil/alamat yang benar harus selalu diinputkan berulang-ulang. Sebaliknya, dalam relasi ‘Staff’ dan ‘Branch’ (perhatikan gambar relasi tentang relasi ‘Staff’ dan ‘Branch’) detil/alamat dari cabang nomor B007 hanya disimpan dalam satu tuple/baris dalam database yaitu di dalam relasi ‘Branch’, dan dengan demikian akan terhindar dari potensi inkonsistensi data, karena tidak akan diinputkan berulang-ulang ketika data baru tentang anggota staff diinputkan.
  • Misalkan ada cabang baru, sehingga kita perlu memasukkan/insert data tentang detil/alamat dari cabang yang baru, tetapi karena masih baru cabang ini masih belum punya anggota staff untuk diinputkan pada relasi ‘StaffBranch’, sehingga kita pasti akan memasukkan/insert ‘nulls’ pada atribut-atribut yang berkaitan dengan staff seperti ‘staffNo’, dsb. Tetapi sayangnya, karena atribut ‘staffNo’ adalah primary key pada relasi ‘StaffBranch’, maka ketika memasukkan ‘nulls’ pada ‘staffNo’ akan menyalahi integrity entitas, dan itu tidak diperbolehkan. Jadi kita tidak bisa memasukkan tuple/baris baru yang hanya berisi cabang baru ke relasi ‘StaffBranch’ dengan nilai ‘null’ pada atribut ‘staffNo’. Tetapi sebaliknya, dengan desain relasi ‘Staff’ dan ‘Branch’ yang terpisah (perhatikan gambar pada relasi-relasi ‘Staff’ dan ‘Branch’) akan menghindarkan kita dari problem seperti ini, karena detil/alamat tentang cabang (yaitu atribut bAddress) dimasukkan ke relasi ‘Branch’ yang berarti terpisah dari detil-detil yang terkait dengan staff. Sehingga detil-detil tentang staff hanya dimasukkan pada relasi ‘Staff’.
Anomali pada delete data

Apabila kita menghapus satu tuple/baris dari relasi ‘StaffBranch’ , misalkan saja tuple/baris ini berisi anggota terakhir atau satu-satunya dari staff yang berada di suatu cabang, maka detil/alamat dari cabang tersebut juga ikut hilang dari database. Contohnya, apabila kita menghapus tuple/baris untuk staff nomor SA9 (Mary Howe) dari relasi ‘StaffBranch’, maka detil yang terkait dengan cabang nomor B007 akan juga hilang dari database. Sebaliknya, pada desain relasi ‘Staff’ dan ‘Branch’ (perhatikan gambar pada relasi-relasi ‘Staff’ dan ‘Branch’), problem seperti ini akan terhindarkan, karena data tentang cabang disimpan terpisah dari data staff dan hanya atribut ‘branchNo’ yang akan menghubungkan kedua relasi itu. Bila kita menghapus tuple/baris untuk staff nomor SA9 dari relasi ‘Staff’, detil/alamat pada cabang nomor B007 yang disimpan di relasi ‘Branch’ tetap tak berdampak.

Anomali terhadap perubahan/modifikasi atau update

Apabila kita ingin mengubah data pada salah satu atribut dari cabang tertentu pada relasi ‘StaffBranch’, contohnya, alamat untuk cabang nomor B003, kita harus mengubah semua tuple/baris dari staff yang berlokasi di cabang tersebut satu per satu. Bila perubahan ini tidak dilakukan pada semua tuple/baris yang seharusnya diubah pada relasi ‘StaffBranch’, database akan berisi data yang inkonsisten. Pada contoh ini, cabang nomor B003 mungkin muncul dengan alamat yang berbeda-beda pada beberapa tuple/baris yang lainnya. Tetapi sebaliknya, bila kita mengacu pada relasi-relasi ‘Staff’ dan ‘Branch’ (perhatikan gambar pada relasi-relasi ‘Staff’ dan ‘Branch’), hal ini tidak akan terjadi.

Contoh-contoh di atas mengilustrasikan bahwa relasi-relasi ‘Staff’ dan ‘Branch’ memiliki sifat-sifat yang lebih diinginkan bila dibandingkan dengan relasi ‘StaffBranch’. Ini menunjukkan bahwa meskipun relasi ‘StaffBranch’ sangat rentan terhadap berbagai update anomalies, namun kita bisa menghindari anomali-anomali tersebut dengan memecah/menguraikan relasi awal/asli nya, yaitu ‘StaffBranch’, menjadi relasi ‘Staff’ dan ‘Branch’.

Kategori: , , ,

2 comments:

Subscribe to: Post Comments (Atom)