[basis.data|akuntansi|lab.software|pert.12]

Basis data secara fisik dibuat dalam bentuk tabel-tabel. Tabel tersebut berasal dari analisis baik lewat Entity Relationship Diagram (ERD) maupun Diagram Alir Data (DAD). Beberapa kampus menerapkan ERD yang merupakan perancangan basis data secara konseptual dilanjutkan dengan mengkonversi ERD menjadi struktur penyimpanan logika (logical structured record). Caranya dengan menggunakan prosedur sebagai berikut:

• Konversi multivalued menjadi satu tabel tambahan (tabel detail) dari relasi Many-to-Many
• Konversi entity komposit menjadi tabel lookup baru
• Konversi entitas lemah (weak entity) menjadi satu tabel baru

Sementara itu yang menggunakan DFD harus menjabarkan tabel yang ada setelah itu dilakukan proses normalisasi untuk menghindari anomali-anomali yang terjadi (insert, update, dan delete). Tetapi ERD pun tetap sebaiknya melakukan proses normalisasi file untuk memperkokoh hasil rancangan.

Format Normalisasi

Ada beragam format penulisan normalisasi file. Salah satu format yang cukup baik adalah format yang ditawarkan oleh Elmasri dkk dengan menggunakan bagan yang berisi judul tabel dan atribut-atributnya. Untuk atribut kunci ditandai dengan menggunakan garis bawah. Simbol panah menunjukan Functional Dependency (FD).

Beberapa kampus menggunakan format tabel seperti class diagram tanpa operation/method dengan nama tabel serta atributnya menyusun ke bawah. Foreign key akan mengarah panahnya ke relasi tabel yang dimaksud. Jika primary key ditandai dengan satu *, foreign key ditandai dengan **.

Kedua cara di atas memiliki kesulitan dalam penggambarannya (dengan visio ataupun insert shape pada MS Word). Namun ada cara lain yang tanpa bagan yaitu dengan menggunakan teks langsung. Formatnya adalah:

• <nama_tabel> = @<primary_key> + <field_1> + <field_2> + … atau:
• <nama_tabel>(<primary_key>,<field_1>,<field_2>, …)

Dari sisi pengetikan sepertinya lebih mudah walaupun butuh penjelasan dengan kata-kata untuk foreign key-nya. Berikut adalah contohnya.

Contoh Normalisasi

Dikenal biasanya ada tiga bentuk normalisasi unnormalized, 1^st Normal Form, 2^nd Normal Form, dan 3^rd Normal Form. Ada BCNF dan Normal kelima tetapi sangat jarang dijumpai di lapangan. Misalkan ada bentuk di bawah ini, yaitu suatu struk transaksi penjualan. Bagaimana normalisasinya?

Unnormalized Form

Unnormalized Form (UNF) paling mudah membuatnya karena hanya mendata field-field yang ada saja. Untuk yang berulang/multi-valued dengan mengisi tanda kurung kurawal saja (bagian detil). Jadi UNF transaksi di atas kira-kira sebagai berikut:

• Penjualan = KdPenjualan + KdPelanggan + namaPelanggan + Alamat + Kontak + Total + {KdBarang + nama +harga + Jumlah}

  Atau:

• Penjualan (KdPenjualan, KdPelanggan, namaPelanggan, Alamat, Kontak, Total, {KdBarang, nama, harga, Jumlah})

Tentu saja untuk implementasi, UNF tidak bisa dibuat tabel, kecuali DBMS khusus berbasis object (atau XML).

First Normal Form

Bentuk 1^st Normal Form (1NF) memiliki ciri tidak adanya redundansi dan multi-value. Dalam 1NF tidak ada field yang merupakan hasil kalkulasi (Calculated Field) yang tidak disimpan di basis data. Selain itu Candidate Key diperkenalkan di sini. Kunci kandidat diperoleh dengan meliha ketergantungan fungsional antara satu field dengan field lainnya, misalnya namaPelanggan, Alamat, dan Kontak dengan KdPelanggan dipilih KdPelanggan sebagai kunci kandidat.

Karena fokus 1^st NF adalah menghilangkan multi-valued field (juga nested relation) maka kunci komposit dibentuk gabungan KdPenjualan dan KdBarang sehingga tidak ada multi-value pada barang yang dijual. Tabel penjualan di bawah ini sudah cukup menghindari multi-value pada suatu field.

• Penjualan (KdPenjualan, KdBarang, nama, harga, Total, KdPelanggan, namaPelanggan, Alamat, Kontak)

Di sini Jumlah dihilangkan karena merupakan hasil kalkulasi dan tidak diinput ke basis data, sementara Total walaupun hasil kalkulasi tetapi tersimpan di basis data.

“Relation should have no multivalued attributes or nested relations.”

Second Normal Form

Bentuk normal kedua (2NF) mengharuskan dalam satu tabel memiliki ketergantungan fungsional secara penuh (Fully Functional Dependency). Dengan kata lain pada bentuk 2NF tidak diperbolehkan satu field secara fungsional bergantung pada salah satu kunci komposit. Dalam contoh ini: nama dan harga barang bergantung ke KdBarang dan tidak ke KdPenjualan, Total ke KdPenjualan tapi tidak ke KdBarang. Oleh karena itu perlu dibentuk tabel baru untuk mengakomodir hal tersebut.

• Penjualan = @KdPenjualan + KdPelanggan + namaPelanggan + Alamat + Kontak + Total
• DetilPenjualan = @KdPenjualan + @KdBarang
• Barang = @KdBarang + nama + harga

Perhatikan di sini tidak ada atribut (di tabel Penjualan) yang bergantung ke salah satu kunci komposit (terhadap KdPenjualan saja atau KdBarang saja).

“For relations where primary key contains multiple attributes, no nonkey attribute should be functionally dependent on a part of the primary key.”

Third Normal Form

Biasanya transaksi sampai di normal ketiga yang mensyaratkan tidak boleh ada transitive dependency dimana satu field non-key bergantung dengan yang lain. Contohnya adalah namaPelanggan (juga alamat dan kontak) yang ternyata bergantung dengan KdPelanggan. Untuk mengingatnya, istilah “transitive” berasal dari kata transfer, yakni mentransfer dari primary key (KdPenjualan) ke namaPelanggan, Alamat, dan Kontak lewat KdPelanggan.

• Pelanggan (KdPelanggan, namaPelanggan, Alamat, Kontak)
• Penjualan (KdPenjualan, KdPelanggan, Total)
• DetilPenjualan (KdPenjualan, KdBarang)
• Barang (KdBarang, nama, harga)

Tampak seluruh field/atribut bergantung ke kunci masing-masing tabel. Aturan untuk 3NF adalah:

“Relation should not have a nonkey attribute functionally determined by another nonkey attribute (or by a set of nonkey attributes). That is, there should be no transitive dependency of a non-key attribute on the primary key.”

Sekian, semoga bermanfaat.

Reference:

Elmasri, R & Navathe. “Fundamentals of Database”. USA: Pearson. 2004