Normalisasi merupakan sebuah upaya untuk memperoleh sebuah database dengan struktur yang baik dengan cara menerapkan sejumlah aturan pada setiap tabel agar ruang penyimpanan efisien. Istilah normalisasi dapat disederhanakan menjadi memecah relasi menjadi beberapa tabel untuk mendapat database yang optimal.

Istilah penting dalam teknik normalisasi

Field / atribut kunci

Setiap file selalu terdapat kunci dari file berupa satu field atau satu field yang dapat mewakili record

Candidate key

Kumpulan atribut minimal yang secara unik mengidentifikasi sebuah baris fungsinya sebagai calon primary key.

Composite key

Kunci kandidat yang berisi lebih dari satu atribut

Primary key

Candidate key yang dipilih untuk mengidentifikasi baris secara unik

Alternate key

Candidate key yang tidak dipilih sebagai primary key

Foreign key. 

Key di tabel lain yang terhubung dengan primary key pada sebuah tabel

Keterangan :

Atribut kunci : NIS 

Candidate key : NIS dan Nama 

Composit key  : Nama bisa dibagi menjadi nama depan dan nama belakang. Alamat bisa dibagi menjadi jalan, kota, propinsi 

Primary key : NIS 

Alternate key : Nama 

Foreign key : NIS pada tabel nilai merupakan foreign key

 

 

Sebuah tabel dikatakan baik (efisien) atau normal jika memenuhi 3 kriteria sbb: 

- Jika ada dekomposisi (penguraian) tabel, maka dekomposisinya  harus dijamin aman (Lossless-Join Decomposition). Artinya, setelah tabel tersebut diuraikan / didekomposisi menjadi tabel-tabel baru, tabel-tabel baru tersebut bisa menghasilkan tabel semula dengan sama persis. 

- Terpeliharanya ketergantungan fungsional pada saat perubahan data (Dependency Preservation).

- Tidak melanggar Boyce-Code Normal Form (BCNF)

 

 Syarat perlunyya normalisasi:

- Fleksibilitas

Struktur database harus menunjang semua cara untuk menampilan data, sehingga ketika user menjalankan aplikasi dan meminta sesuatu dalam datbase, database harus dapat berjlan memenuhi permintaan user.

- integritas data

Semua data dalam database yang berkaitan harus terhubung dalam suatu relationship. Sehingga ketika suatu data berubah,maka semua data yang berkaitan dengan data tersebut harus dapat berubah secara otomatis.

- Efficiency

Pada database, ukuran suatu database merupakan hal yang penting. Maka dalam database, kita harus mengurangi redudansi data yang bisa menyebabkan ukuran databse membengkak.

- Menghindari modification anomaly

Desain database yang baik menyajikan suatu keyakinan bahwa ketika user melakukan perubahan dalam database, maka tidak terjadi hal yang tidak diinginkan.

Kapan tidak memakai normalisasi

- ketika kita ingin mempertahankan kesederhanaan database, sehingga user dapat melakukan query sendiri 

- jika tidak ingin melakukan query yang rumit. normalisasi biasanya akan membuat rumit query karena melibatkan banyak tabel

- tidak selamanya normalisasi membuat baik, malah akan menyebabkan database semakin buruk

Keuntungan dari normalisasi, yaitu :

1. Meminimalkan ukuran penyimpanan yang diperlukan untuk menyimpan data.

2. Meminimalkan resiko inkonsistensi data pada basis data

3. Meminimalkan kemungkinan anomali pembaruan

4. Memaksimalkan stabilitas struktur data

 

 Dalam melakukan normalisasi, ada beberapa tahap yang harus dilakukan :

 1. Unnormalized

Pada tahap ini, kita mengambil seluruh data yang ada dan diperlukan dalam database itu sendiri. Misalnya pada contoh bon faktur di bawah ini,

Kita ambil data-data yang diperlukan pada database nantinya, sperti * Nama Supplier * Alamat Supplier * No. Telp. * No. Nota * Tanggal Transaksi * Kode Barang * Nama Barang * Harga * Quantity * Total * Subtotal * Pemberi * Penerima

 2. Normal Satu

Pada tahap ini, kita bagi seluruh data yang diperlukan menjadi beberapa bagian berdasarkan jenis data tersebut,

Supplier * Nama Supplier * Alamat * No. Telp.

Transaksi * No. Nota * Kode Barang * Tanggal Transaksi * Nama Barang * Harga Barang * Satuan * Quantity * Total * Sub Total

 3. Normal Dua

Pada tahap ini, kita bagi berdasarkan jenis dan memberikan primary key pada masing-masing tabel,

Supplier * Kode Supplier * Nama Supplier * Alamat * No. Telp.

Master Barang * Kode Barang * Nama Barang * Harga * Satuan 

Transaksi * No. Nota * Tanggal Transaksi * Kode Barang * Nama Barang * Harga * Satuan * Quantity * Pemberi * Penerima

 4. Normal Tiga

 Pada tahap ini, kita bagi menjadi lebih terperinci untuk menghindari terjadinya redudancy,

 Supplier * Tetap

 Master Barang * Tetap

 Transaksi Dibagi menjadi: Header Transaksi * No. Nota * Tanggal Transaksi * Kode Supplier * Pemberi * Penerima

Detail Transaksi * No. Nota * Kode Barang * Quantity

 

Normalisasi model data dilakukan dengan mengikuti langkah-langkah sederhana, mengubahnya agar memenuhi apa yang disebut sebagai bentuk normal pertama, kedua, lalu ketiga secara berturutan.

 

                                  

Langkah-Langkah Normalisasi

 1.Bentuk Normal Pertama ( 1NF )

Sebuah model data dikatakan memenuhi bentuk normal pertama apabila setiap atribut yang dimilikinya memiliki satu dan hanya satu nilai. Apabila ada atribut yang memiliki nilai lebih dari satu, atribut tersebut adalah kandidat untuk menjadi entitas tersendiri.

 2.Bentuk Normal Kedua ( 2NF )

Tabel 1

Tabel 2

Tabel 3

 

Sebuah model data dikatakan memenuhi bentuk normal kedua apabila ia memenuhi bentuk normal pertama dan setiap atribut non-identifier sebuah entitas bergantung sepenuhnya hanya pada semua identifier entitas tersebut.

3.Bentuk Normal Ketiga (3NF)

          

Tabel 1 dan 2 sudah memenuhi criteria bantuk 3NF, namun tidak untuk tabel 3, karena bila kita ingin merubah value bobot dari nilai, maka kita akan melakukan perubahan pada banyak record/baris yang lainnya. Sehingga pada bentuk 3NF, tabel 3 dapat dipecah lagi menjadi 2 tabel agar memenuhi kriteria bentuk 3NF.

Tabel 3a

Tabel 3b

 

FIRST NORMAL FORM ( 1NF )

Implementasi 1-NF dari table data yang belum ternormalisasi di atas adalah dengan cara mengeliminasi keberadaan repeating groups dan dekomposisi relasi menjadi dua atau lebih dengan syarat “tidak boleh ada informasi yang hilang karena proses dekomposisi” Adapun caranya adalah :

1. Membuat 3 tabel yang memiliki fungsi sebagai berikut :

• TBFaktur, berfungsi untuk menyediakan atribut-atribut yang bersifat atomic dari tiap nomor faktur (ID_Faktur), seperti : Tanggal, Nama_Pelanggan, Total_Bayar, Diskon dan Nama_Petugas
• TBProduk, berfungsi untuk menyediakan atribut-atribut yang berulang atau tidak bernilai tunggal pada tiap nomor faktur (ID_Faktur), seperti : Nama_Barang dan harga
• TBTransaksiDetail, berfungsi sebagai penghubung antara nomor faktur (ID_Faktur) dengan kode barang (ID_Barang) agar proses dekomposisi tidak menyebabkan kerusakan informasi.

2. Menentukan type data dari tiap atribut dan membuat digram relasional sebagai berikut

3. Pada table TBTransaksiDetail terdapat atribut “Harga” yang berfungsi untuk menyimpan harga per transaksi, sedangkan atribut “Harga_Default” yang terdapat pada table TBProduk adalah atribut yang berfungsi untuk menyimpan harga barang terbaru dari tiap jenis barang.Hal ini berguna untuk mengantisipasi adanya perubahan harga dari waktu ke waktu.

4. Primary key yang digunakan pada TBTransaksiDetail adalah “ID_Transaksi”. Atribut kunci tersebut merupakan candidate key yang dibentuk dari superkey hasil penggabungan 2 atribut yaitu : ID_Faktur dan ID_Barang

SECOND NORMAL FORM( 2NF )

• Suatu relasi berada dalam 2nd normal form jika dan hanya jika:
• Berada dalam bentuk first normal form (1-NF)
• Semua atribut bukan kunci memiliki dependensi sepenuhnya dengan kunci primer (Primary Key)

Jika kita lihat kembali relasi bentuk 1-NF yang telah dibuat sebelumnya, maka atribut bukan kunci pada table TBFaktur yang tidak memiliki dependensi sepenuhnya dengan primary key (ID_Faktur), yaitu : “Nama_Petugas”. Oleh sebab itu dekomposisi relasi perlu dilakukan kembali dengan cara :

1. Mengeliminasi atribut “Nama_Petugas” dari table TBFaktur
2. Membuat tabel TBPetugas, menyediakan atribut-atribut yang terkait dengan identitas dan data pelanggan

THIRD NORMAL FORM ( 3NF )

Pada Second Normal Form (2-NF) atribut yang terkait dengan “Nama_Pelanggan” tidak didekomposisi dari table TBFaktur karena atribut tersebut masih memiliki dependensi fungsional dengan primary key (ID_Faktur) karena tiap nomor faktur akan berbeda untuk tiap pembeli/pelanggan. Tetapi pada tahap 3-NF (Third Normal Form), atribut “Nama_Pelanggan” harus didekomposisi relasi karena pada tahap ini atribut bukan kunci tidak boleh ada yang berdependensi transitif dengan kunci primer.

Atribut “Nama_Pelanggan” dikatakan berdependensi transitif terhadap primary key (ID_Faktur) karena :

1. ID_Pelanggan → Nama_Pelanggan (Nama_Pelanggan berdependensi fungsional terhadap ID_Pelanggan)
2. ID_Faktur → ID_Pelanggan (ID_Pelanggan berdependensi fungsional terhadap ID_Faktur, karena tiap nomor faktur akan dikeluarkan untuk suatu ID_Pelanggan tertentu)
3. Sehingga dikatakan bahwa ID_Faktur memiliki dependensi transitif terhadap atribut Nama_Pelanggan

Model Entity Relationship merupakan suatu penyajian data dengan menggunakan Entity dan Relationship. Komponen-komponen ERD :

1.       Entitas

Entity adalah obyek yang dapat dibedakan secara nyata , benar-benar ada secara fisik (contoh : orang) atau konsepsual (contoh : perusahaan) dan tidak saling bergantung keberadaannya.

a.    Entitas kuat/strong

Entitas yang memiliki atribut kunci (key), yakni yang benar-benar dapat digunakan sebagai  pembeda.

b.    Entitas lemah/weak

Entitas yang keberadaan dari entitas tersebut tergantung dari keberadaan entitas lain, atau key-nya memiliki beberapa informasi yang mirip sehingga bersifat tidak penuh.

 

2.       Relasi

Relasi adalah hubungan yang terjadi antara satu atau lebih entitas. Derajat relasi adalah jumlah entitas yang berpartisipasi pada suatu relasi, antara lain : relasi 1 entitas/berderajat 1 (unary), relasi 2 entitas/berderajat 2 (binary). relasi 3 entitas/berderajat 3 (ternary).

 

3.       Atribut

Atribut adalah karakteristik dari/sesuatu yang dimiliki oleh entity atau relationship yang menyediakan penjelasan detail tentang entity atau relationship tersebut.

a.       Key atribut,

Atribut yang digunakan untuk menentukan suatu entity secara unik/yang dapat membedakan satu dengan yang lainnya,

b.      Partical key atribut

c.       Atribut simple

Atribut yang bernilai simple.

d.      Atribut multivalue

Atribut yang  memiliki sekelompok nilai untuk setiap entitas.

e.      Atribut composite

Atribut yang terdiri dari beberapa atribut yang lebih kecil yang mempunyai arti tertentu.

f.        Atribut derifatif

Atribut yang dihasilkan dari atribut yang lain.

 

4.       Kardinalitas

Kardinalitas adalah angka yang menjelaskan batasan jumlah keterhubungan satu entity dengan entitas lainnya.

a.       One to One

b.      One to Many

c.       Many to Many

 

 Partisipan/Modalitas

Partisipan/Modalitas menunjukkan partisipasi sebuah entitas pada suatu relasi.

a.       Total partisipan:

Semua menjadi bagian dari relasi

b.      Partical partisipan :

Tidak semua ikut dalam relasi.

Simbol Komponen ERD

 

Berikut ini contoh Entity Relationship Diagram.

 

Pada kasus ini terdapat entitas penghuni, kamar kost, dan pemilik kost.  Penghuni menyewa kamar kost yang dimiliki  oleh pemilik kost. Relasinya digambarkan sebagai berikut.

 

1 penghuni hanya  bisa menyewa 1  kamar kost, dan 1 kamar kost hanya bisa disewa oleh 1 penghuni. 1 pemilik kost memiliki banyak  kamar kost. Sehingga kardinalitasnya tampak pada gambar di bawah ini.

Untuk kelancaran penyewaan kamar kost ini, dibutuhkan identitas dari tiap penghuninya untuk didaftarkan dalam data adiministrasi kost. Identitas dari si  penghuni ini merupakan atribut dari entitas penghuni tersebut. Identitas yang diperlukan dari si penghuni ini ialah nama, tempat, tanggal lahir pekerjaan, dan nomor handphone. Setiap penghuni bisa saja memiliki lebih dari 1 nomor handphone, sehingga no handphone digolongkan sebagai atribut multivalue.

 

Kost ini terdiri atas 3 lantai yang memiliki berbagai tipe kamar sesuai dengan fasilitas yang ada di dalamnya. Oleh karena itu kamar kost di kostan ini memiliki harga yang bervariasi. Setiap kamar diberi nomor sebagai identitas kamar tersebut. Atribut harga digolongkan sebagai atribut derifative, karena ia muncul dari atribut tipe kamar.

 

Pemilik kost memiliki atribut berupa nama, no handphone, dan alamat. No handphone digambarkan sebagai atribut multivalue karena bisa saja si pemilik kost memiliki no handphone lebih dari satu, dan alamat digambarkan sebagai atribut composite karena memiliki atribut lain berupa jalan, kelurahan,  dan kecamatan.

 

Setiap penghuni yang menyewa kamar kost tersebut dicatat tanggal penyewaannya untuk kepentingan pembayaran. Dalam kost ini memiliki peraturan dimana jika ada penghuni yang terlambat membayar kamar kost (lebih dari 1 minggu) maka ia dikenai denda, sehingga denda dikategorikan sebagai atribut derifative. Selain itu jika ada teman, keluarga, atau relasi yang bermalam dikenai biaya charge.

Berikut ini diagram lengkap dari contoh Entity Relationship pada kasus ini.