APA BENTUK NORMAL KETIGA? (DATABASE) - TEKNOLOGI - 2025

Bentuk normal ketiga (database) adalah teknik desain database relasional, di mana tabel berbeda yang menyusunnya tidak hanya sesuai dengan bentuk normal kedua, tetapi semua atribut atau bidangnya bergantung langsung pada kunci utama.

Saat mendesain database, tujuan utamanya adalah untuk membuat representasi data yang akurat, hubungan di antara mereka, dan batasan pada data yang relevan.

Sumber: pixabay.com

Untuk mencapai tujuan tersebut, beberapa teknik perancangan database dapat digunakan, di antaranya adalah normalisasi.

Ini adalah proses pengorganisasian data dalam database untuk menghindari redundansi dan kemungkinan anomali dalam penyisipan, pemutakhiran, atau penghapusan data, sehingga menghasilkan desain model konseptual yang sederhana dan stabil.

Ini dimulai dengan memeriksa hubungan fungsional atau ketergantungan antara atribut. Ini menjelaskan beberapa properti data atau hubungan di antara mereka.

Bentuk normal

Normalisasi menggunakan serangkaian tes, yang disebut bentuk normal, untuk membantu mengidentifikasi pengelompokan yang optimal dari atribut ini dan pada akhirnya menetapkan himpunan hubungan yang sesuai yang mendukung persyaratan data perusahaan.

Artinya, teknik normalisasi dibangun di sekitar konsep bentuk normal, yang mendefinisikan sistem batasan. Jika suatu hubungan memenuhi batasan dari bentuk normal tertentu, hubungan tersebut dikatakan dalam bentuk normal tersebut.

Bentuk normal pertama (1FN)

Sebuah tabel dikatakan dalam 1FN jika semua atribut atau field di dalamnya hanya berisi nilai unik. Artinya, setiap nilai untuk setiap atribut harus tidak dapat dibagi.

Menurut definisi, database relasional akan selalu dinormalisasi ke bentuk normal pertama, karena nilai atribut selalu bersifat atomik. Semua relasi dalam database berada dalam 1FN.

Namun, meninggalkan database seperti ini akan memicu sejumlah masalah, seperti redundansi dan kemungkinan kegagalan pemutakhiran. Bentuk normal yang lebih tinggi dikembangkan untuk memperbaiki masalah ini.

Bentuk normal kedua (2FN)

Ini berkaitan dengan menghapus dependensi melingkar dari tabel. Suatu relasi dikatakan berada dalam 2FN jika berada dalam 1FN dan selanjutnya setiap bidang atau atribut non-kunci bergantung sepenuhnya pada kunci utama, atau lebih khusus lagi, ini memastikan bahwa tabel memiliki satu tujuan.

Atribut non-kunci adalah atribut apa pun yang bukan merupakan bagian dari kunci utama untuk suatu hubungan.

Bentuk normal ketiga (3FN)

Ini berkaitan dengan menghilangkan ketergantungan transitif dari tabel. Artinya, hapus atribut non-kunci yang tidak bergantung pada kunci utama, tetapi pada atribut lain.

Ketergantungan transitif adalah jenis ketergantungan fungsional di mana nilai bidang atau atribut non-kunci ditentukan oleh nilai bidang lain yang juga bukan kunci.

Anda harus mencari nilai berulang dalam atribut non-kunci untuk memastikan bahwa atribut non-kunci ini tidak bergantung pada apa pun selain kunci utama.

Atribut dikatakan saling independen jika tidak ada satupun yang secara fungsional bergantung pada kombinasi yang lain. Kemandirian timbal balik ini memastikan bahwa atribut dapat diperbarui secara individual, tanpa bahaya memengaruhi atribut lain.

Oleh karena itu, agar relasi dalam database menjadi bentuk normal ketiga, ia harus mematuhi:

- Semua persyaratan 2FN.

- Jika ada atribut yang tidak terkait dengan kunci utama, maka harus dihapus dan ditempatkan dalam tabel terpisah, yang menghubungkan kedua tabel tersebut dengan menggunakan kunci asing. Artinya, tidak boleh ada dependensi transitif.

Contoh bentuk normal ketiga

Contoh 1

Biarkan tabel menjadi STUDENT, yang kunci utamanya adalah identifikasi siswa (STUDENT_ID) dan terdiri dari atribut berikut: STUDENT_NAME, STREET, CITY dan POST_CODE, yang memenuhi syarat menjadi 2FN.

Dalam hal ini, STREET dan CITY tidak memiliki hubungan langsung dengan kunci utama STUDENT_ID, karena keduanya tidak terkait langsung dengan siswa, tetapi bergantung sepenuhnya pada kode pos.

Karena lokasi siswa ditentukan oleh CODE_POSTAL, STREET dan CITY terkait dengan atribut ini. Karena tingkat ketergantungan kedua ini, atribut ini tidak perlu disimpan dalam tabel STUDENT.

Buat tabel baru

Misalkan terdapat beberapa siswa yang berada di kode pos yang sama, dengan tabel STUDENT memiliki jumlah record yang sangat banyak, dan harus mengganti nama jalan atau kota, maka jalan atau kota tersebut harus dicari dan diperbarui di seluruh tabel. SISWA.

Misalnya, jika Anda perlu mengubah jalan "El Limón" menjadi "El Limón II", Anda harus mencari "El Limón" di seluruh tabel STUDENT dan kemudian memperbaruinya menjadi "El Limón II".

Mencari dalam tabel besar dan memperbarui satu atau beberapa catatan akan memakan waktu lama dan karena itu memengaruhi kinerja database.

Sebagai gantinya, detail ini dapat disimpan dalam tabel terpisah (KARTU POS) yang terkait dengan tabel STUDENT menggunakan atribut POST_CODE.

Tabel POST akan memiliki catatan yang relatif lebih sedikit dan tabel POST ini hanya perlu diperbarui satu kali. Ini akan secara otomatis tercermin dalam tabel STUDENT, menyederhanakan database dan kueri. Jadi tabelnya akan menjadi 3FN:

Contoh 2

Biarkan tabel berikut digunakan dengan bidang Project_Num sebagai kunci utama dan dengan nilai berulang dalam atribut yang bukan kunci.

Nilai Telepon diulang setiap kali nama manajer diulang. Ini karena nomor telepon hanya memiliki ketergantungan tingkat kedua pada nomor proyek. Ini benar-benar tergantung pada manajer terlebih dahulu, dan ini pada gilirannya tergantung pada nomor proyek, yang membuat ketergantungan transitif.

Atribut Project_Manager tidak bisa menjadi kunci yang mungkin dalam tabel Proyek karena manajer yang sama mengelola lebih dari satu proyek. Solusi untuk ini adalah menghapus atribut dengan data berulang (Telepon), membuat tabel terpisah.

Atribut yang sesuai harus dikelompokkan bersama, membuat tabel baru untuk menyimpannya. Data dimasukkan dan diverifikasi bahwa nilai yang diulang bukan bagian dari kunci utama. Kunci utama diatur untuk setiap tabel, dan kunci asing ditambahkan jika perlu.

Untuk memenuhi bentuk normal ketiga, tabel baru (Manajer) dibuat untuk menyelesaikan masalah. Kedua tabel terkait melalui bidang Project_Manager:

Referensi

1. Teradata (2019). Bentuk Normal Pertama, Kedua, dan Ketiga. Diambil dari: docs.teradata.com.
2. Piala Tutorial (2019). Bentuk Normal Ketiga (3NF). Diambil dari: tutorialcup.com.
3. Pengembangan Database (2015). Bentuk Normal Ketiga (3NF) - Normalisasi Database Anda. Diambil dari: databasedev.co.uk.
4. Desain DB Relasional (2019). Pengantar Bentuk Normal Ketiga. Diambil dari: relationaldbdesign.com.
5. Dummies (2019). Bentuk Normal SQL Pertama, Kedua dan Ketiga. Diambil dari: dummies.com.