Normalisasi Basis Data: 1NF, 2NF, 3NF

Membahas anomali update, ketergantungan fungsional dan proses normalisasi: first normal form, second normal form, third normal form

Daftar Isi

• Pendahuluan
• Data Ganda dan Anomali Update
  ∘ Anomali Penambahan
  ∘ Anomali Penghapusan
  ∘ Anomali Modifikasi
• Proses Normalisasi
  ∘ 1NF (First Normal Form ‘Bentuk Normal Pertama’)
  ∘ 2NF (Second Normal Form ‘Bentuk Normal Kedua’)
  ∘ 3NF (Third Normal Form ‘Bentuk Normal Ketiga’)
• Penutup
• Daftar Pustaka

Pendahuluan

Dalam siklus hidup basis data, proses desain dilakukan setelah tahap analisis kebutuhan data selesai dilakukan. Ada dua pendekatan desain basis data, yaitu:

1. Desain top-down menggunakan model entity-relationship (ER). Desain dimulai dengan mengidentifikasi entitas, dilanjutkan de­ngan relationship (hubungan) antar entitas dan kardinalitas atau multiplisitas. Setiap entitas — boleh jadi juga relationship — dilengkapi dengan atribut, primary key dan foreign key (bila ada).
2. Desain bottom-up dengan melakukan proses normalisasi. Desain dimulai dengan mengidentifikasi atribut, kemudian mengelom­pokkannya ke dalam kumpulan data untuk membentuk relasi.

Kedua pendekatan saling melengkapi. Proses desain dimulai dengan pemodelan data konseptual menggunakan model ER dilanjutkan ke tahap desain basis data logis. Pada model ER awal, normalisasi dilakukan terhadap entitas atau relationship yang memiliki data ganda. Hasil normalisasi digunakan untuk memodifikasi model ER awal sehingga diperoleh model ER akhir yang lebih baik. Pada tahap desain basis data logis, normalisasi dilakukan terhadap relasi — hasil pemetaan dari pemodelan ER — yang memiliki data ganda.

Relasi yang memiliki data ganda menimbulkan banyak masa­lah. Selain boros ruang penyimpanan, ada tiga masalah utama yang muncul, yaitu ketika: (1) menambahkan data baru, (2) mengubah dan (3) menghapus data yang ada. Ketiga masalah ini, biasa disebut anomali update, diatasi dengan normalisasi.

Sebagian pengguna basis data, praktisi, penulis, dsb. memaknai kata relasi sebagai hubungan. Secara semantik mungkin benar, namun kurang tepat kalau berkaitan dengan istilah dalam basis data relasional.

“A relation is a table with columns and rows.” (Connolly & Begg, 2015:152)
“… E.F. Codd, used the term relation as a synonym for table.”
(Coronel et.al., 2020:71)
“… in the relational model the term relation is used to refer to a table.” (Silberschatz et.al., 2020:40)

Tujuan utama normalisasi adalah mengelompokkan atribut ke dalam relasi sehingga data gandanya minimal. Konsep normalisasi dikemukakan pertama kali oleh Codd (1970) dengan memperkenal­kan 1NF (first normal form ‘bentuk normal pertama’), dilanjutkan dengan 2NF dan 3NF pada tahun 1971. Bersama Raymond F. Boyce, Codd (1974) mendefinisikan BCNF (Boyce-Codd normal form ‘bentuk normal Boyce-Codd’). Fagin (1977) memperkenalkan 4NF (fourth normal form ‘bentuk normal keempat’) dilanjutkan dengan 5NF (fifth normal form ‘bentuk normal kelima’) pada tahun 1979. Date, Darwen, dan Lorentzos (2002) mendefinisikan 6NF (sixth normal form ‘bentuk normal keenam’).

Dalam praktik, proses normalisasi sampai 3NF sudah cukup baik mengurangi data ganda. Relasi yang memenuhi 3NF, dalam banyak kasus, biasanya sudah memenuhi BCNF dan bentuk normal yang lebih tinggi. Menurut Coronel dan Morris (2019), beberapa kasus yang sangat khusus, seperti penelitian statistik, mungkin memerlukan normalisasi 4NF atau yang lebih tinggi. Bentuk normal yang lebih tinggi biasanya meningkatkan operasi join yang memperlambat kinerja tanpa ada nilai tambah apa pun dalam mengurangi data ganda.

Data Ganda dan Anomali Update

Sebagaimana telah disinggung sebelumnya, selain boros ruang penyimpanan, adanya data ganda menimbulkan tiga anomali update yaitu (1) anomali penambahan, (2) anomali penghapusan, dan (3) anomali modifikasi.

Sebagai contoh, lihat Gambar 1. Relasi PegawaiCabang be­lum normal karena ada pengulangan data yang sama pada tiga atribut terakhir, yaitu atribut NomorCabang, AlamatCabang, dan TeleponCabang. Setelah dinormalisasi, diperoleh relasi Pegawai dan relasi Cabang. Keduanya bebas dari masalah anomali update karena tidak ada data ganda.

Gambar ‎1 Relasi belum dinormalisasi (PegawaiCabang) versus
relasi yang sudah dinormalisasi (Pegawai dan Cabang)

Anomali Penambahan

Anomali penambahan terjadi ketika ada data baru ditambahkan ke dalam sebuah relasi. Lihat relasi PegawaiCabang pada Gambar 1(a). Bila ada pegawai baru yang ditempatkan di Cabang C01, maka ke dalam relasi PegawaiCabang, selain data pegawai (NIP, Nama, Alamat), data detail cabang C01 (NomorCabang, AlamatCabang, Telepon Cabang) juga harus dimasukkan dengan risiko terjadi ketidak­konsistenan data. Sebaliknya, pada relasi Pegawai pada Gambar 1(b), cukup dimasukkan data pegawai dan nomor cabang C01 tempat ia bekerja tanpa harus memasukkan detail cabang.

Bila ada cabang baru yang belum ada pegawainya, maka ke dalam relasi PegawaiCabang, data detail cabang baru (NomorCabang, AlamatCabang, TeleponCabang) dimasukkan dengan atribut pega­wai (NIP, Nama, Alamat) dikosongkan. Hal ini tak mungkin dilakukan karena NIP sebagai primary key tidak boleh kosong. Berarti data cabang baru tak dapat ditambahkan. Sebaliknya, pada relasi Cabang pada Gambar 1(c), detail cabang baru dapat ditambahkan tanpa masalah.

Anomali Penghapusan

Anomali penghapusan terjadi ketika ada data yang dihapus. Lihat relasi PegawaiCabang pada Gambar 1(a). Bila pegawai de­ngan NIP 19009 dihapus, maka data detail cabang C03 pada relasi PegawaiCabang juga ikut terhapus. Sebaliknya, penghapusan pegawai dengan NIP 19009 pada relasi Pegawai pada Gambar 1(b) tidak mengaki­bat­kan hilangnya data detail cabang C03.

Anomali Modifikasi

Anomali modifikasi terjadi ketika ada data yang diubah. Lihat relasi PegawaiCabang pada Gambar 1(a). Misalkan cabang C01 pindah alamat dan nomor teleponnya pun berubah. Pada relasi PegawaiCabang, modifikasi data harus dilakukan secara berulang ke seluruh data cabang C03 yang ada. Hal ini dapat menimbulkan ketidakkonsistenan data. Sebaliknya, modifikasi data pada relasi Cabang pada Gambar 1(c) cukup dilakukan sekali.

Proses Normalisasi

Sebagai contoh kasus proses normalisasi, lihat contoh faktur belanja pada Gambar 2. Tabel pada Gambar 3 yang berisi data faktur belanja merupakan tabel yang belum normal (UNF, unnormalized form) karena belum memenuhi karakteristik sebuah relasi. Salah satu karakteristiknya menyatakan bahwa setiap sel — yakni perpotongan baris dan kolom — harus ber­nilai tunggal. Sel pada kolom JumlahBarang, Satuan, KodeBarang, NamaBarang, HargaSatuan, JumlahHarga memiliki dua nilai.

Gambar ‎2 Faktur belanja

Gambar 3 Tabel UNF (unnormalized form ‘bentuk tidak normal’)

Gambar 4 Relasi 1NF (first normal form ‘bentuk normal pertama’)

1NF (First Normal Form ‘Bentuk Normal Pertama’)

Relasi yang memenuhi 1NF adalah relasi yang setiap perpo­tongan baris dan kolomnya berisi satu dan hanya satu nilai. Supaya bernilai tunggal, tabel UNF pada Gambar 3 dimodifikasi dengan memisahkan nilai sel yang tidak tunggal ke baris baru sehingga diperoleh relasi seperti pada Gambar 4. Perhatikan bahwa setiap perpotongan baris dan kolom­nya berisi satu dan hanya satu nilai. Ini berarti relasi tersebut telah memenuhi syarat 1NF. Dengan demikian, dari faktur belanja dipero­leh sebuah relasi 1NF yang skema relasinya sebagai berikut:

FakturBelanja (Tgl,Nama, Alamat, NoHP, NoFaktur, Jumlah, Satuan, KodeBarang, NamaBarang, HargaSatuan, Jumlah Harga, Total)

Dua atribut terakhir adalah atribut turunan dan boleh diabai­kan (boleh tidak disimpan dalam basis data). Skema relasinya men­jadi sebagai berikut:

FakturBelanja (Tgl, Nama, Alamat, NoTelepon, NoFaktur, Jumlah, Satuan, KodeBarang, NamaBarang, HargaSatuan)

2NF (Second Normal Form ‘Bentuk Normal Kedua’)

Relasi 2NF adalah relasi yang memenuhi 1NF dan setiap atribut bukan primary key memiliki ketergantungan fungsional penuh pada primary key. Jadi, ada dua hal yang berkaitan dengan relasi 2NF, yaitu primary key dan ketergantungan fungsional.

Ketergantungan Fungsional
Jika A dan B adalah atribut relasi R, maka B dinyatakan memiliki ketergantungan fungsional pada A (ditulis A → B), jika setiap nilai A berasosiasi tepat dengan satu nilai B. A dan B boleh jadi terdiri atas satu atau beberapa atribut.

Determinan ketergantungan fungsional adalah atribut atau sekum­pulan atribut yang ada pada sisi kiri anak panah.

Nama mahasiswa memiliki ketergantungan fungsional pada NIM, NIM→Nama, karena untuk satu nilai NIM hanya diperoleh satu nama. Tetapi tidak sebaliknya. NIM tidak memiliki ketergantungan fungsional pada nama karena untuk satu nama boleh jadi dimiliki oleh beberapa orang mahasiswa sehingga diperoleh beberapa NIM.

Ketergantungan fungsional penuh
Bila A dan B adalah atribut sebuah relasi, maka B dinyata­kan memiliki ketergantungan fungsional penuh pada A jika B bergantung fungsional pada A secara keseluruhan dan bukan pada sebagian dari A. A adalah primary key atribut tunggal atau primary key komposit yang merupakan gabungan dari beberapa atribut.

Karena persyaratan relasi 2NF berkaitan dengan primary key, maka harus ditentukan terlebih dahulu primary key relasi 1NF. Tidak satu pun atribut tunggal memenuhi syarat sebagai primary key. Oleh karena itu, diambil gabungan dua atribut yaitu NoFaktur + KodeBarang sebagai primary key komposit sehingga skema relasinya menjadi:

FakturBelanja (NoFaktur, KodeBarang, Tgl, Nama, Alamat, NoTelepon, Jumlah, Satuan, NamaBarang, HargaSatuan)

Selanjutnya, setiap atribut bukan primary key dicek apakah memiliki ketergantungan fungsional penuh pada keseluruhan atribut primary key atau hanya pada sebagian primary key (parsial).

Lihat Gambar 5. Ada dua kelompok atribut yang memiliki ketergan­tungan fungsional pada sebagian primary key (ketergantungan parsial). Pertama, atribut Satuan, NamaBarang, memiliki ketergan­tungan fungsional hanya pada KodeBarang; kedua, atribut Tgl, Nama, Alamat, dan NoHP memiliki ketergantungan fungsional hanya pada NoFaktur. Ini berarti relasi FakturBelanja memang belum me­menuhi 2NF.

Gambar ‎5 Diagram ketergantungan fungsional pada relasi 1NF FakturBelanja

Gambar ‎6 Relasi 2NF

Kelompok atribut yang memiliki ketergantungan fungsional parsial dipisahkan ke dalam relasi berbeda sehingga dari relasi 1NF FakturBelanja diperoleh tiga buah relasi 2NF yaitu Barang, FakturPelanggan dan DetailFaktur. Lihat Gambar 6. Semua atribut yang bukan primary key pada ketiga relasi memiliki ketergantungan fungsional penuh pada primary key.

3NF (Third Normal Form ‘Bentuk Normal Ketiga’)

Relasi 3NF adalah relasi yang memenuhi 1NF, 2NF dan atribut yang bukan primary key tidak memiliki ketergantungan transitif pada primary key.

Ketergantungan Transitif
Misal A, B, C adalah atribut sebuah relasi. Jika A → B dan B → C, maka dikatakan C memiliki ketergan­tungan transitif pada A melalui B. Dengan kata lain, ketergantungan transitif adalah keter­gantungan fungsional di antara atribut bukan primary key.

Atribut bukan primary key setiap relasi 2NF harus dicek apakah memiliki ketergantungan transitif. Lihat Gambar 6. Skema ketiga relasi adalah sebagai berikut.

Barang (KodeBarang, Satuan, NamaBarang)
DetailFaktur (KodeBarang, NoFaktur, Jumlah, HargaSatuan)
FakturPelanggan (NoFaktur, Tgl, Nama, Alamat, NoHP)

Pada relasi Barang, tidak ada ketergantungan antara atribut Satuan dengan NamaBarang. Begitu pula pada relasi DetailFaktur, tidak ada ketergantungan antara atribut Jumlah dengan HargaSatuan. Ini berarti keduanya sudah memenuhi 3NF karena tidak memiliki ketergantungan transitif. Pada relasi FakturPelanggan, atribut NoHP bernilai unik, ada ketergantungan transitif Nama dan Alamat pada NoFaktur melalui NoHP sebagai berikut:
NoFaktur → NoHP
NoHP → Nama, Alamat

Dengan demikian, relasi FakturPelanggan belum memenuhi 3NF. Lihat Gambar 7.

Gambar ‎7 Ketergantungan transitif

Gambar ‎8 Relasi 3NF

Selanjutnya, kelompok atribut yang memiliki ketergantungan transitif dipisahkan ke dalam relasi berbeda sehing­ga dari relasi 2NF FakturPelanggan diperoleh dua buah relasi 3NF yaitu relasi Faktur dan relasi Pelanggan. Lihat Gambar 8.

Gambar 9 Hasil normalisasi sampai dengan 3NF

Jadi, hasil akhir proses normalisasi data faktur belanja adalah empat buah relasi 3NF yaitu relasi Pelanggan, Faktur, DetailFaktur dan Barang. Lihat Gambar 9. Keterkaitan antar relasi dapat dilihat dari atribut foreign key yang digarisbawahi dengan garis terputus-putus merujuk ke atribut primary key yang digarisbawahi dengan garis menerus.

Penutup

Selain boros ruang penyimpanan, relasi yang memiliki data ganda menimbulkan tiga masalah utama, yaitu ketika: (1) menambahkan data baru, (2) mengubah dan (3) menghapus data yang ada. Ketiga masalah ini, biasa disebut anomali update.

Gambar 10 Proses normalisasi

Untuk mengatasi anomali update, telah dibahas bagaimana melakukan normalisasi sekurang-kurangnya sampai dengan 3NF. Secara keseluruhan, Gambar 10 menunjukkan urutan prosesnya.

Terima kasih sudah membaca. Umpan balik Anda akan sangat berharga.

Daftar Pustaka

Codd, E. F. (1970, June). A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, 13(6), pp. 377–387. doi:10.1145/362384.362685

Database Principles

Database Systems: A Practical Approach to Design, Implementation, and Management PDF eBook, Global…

Siklus Hidup Basis Data