Program
Bayangkan bekerja dengan basis data besar yang tidak terstruktur, penuh dengan informasi berulang dan redundan. Setiap pembaruan atau penghapusan bisa menjadi bencana, berisiko menimbulkan kesalahan dan inkonsistensi. Third normal form (3NF) adalah metode normalisasi basis data yang terbukti untuk menghindari kekacauan ini. Menerapkan 3NF merapikan struktur data Anda, memastikan data efisien, terorganisasi, dan bebas dari redundansi yang tidak perlu.
Dalam artikel ini, kita akan membahas cara kerja 3NF, mengapa ini berharga, dan bagaimana Anda dapat menerapkannya. Kita juga akan membandingkan 3NF dengan bentuk lainnya dan mempelajari kapan menggunakan masing-masing. Semua orang bisa mendapatkan manfaat dari mempelajari struktur ini, tetapi pengetahuan ini sangat berharga jika Anda seorang perancang basis data atau data scientist, karena dapat sangat menyederhanakan pekerjaan Anda dan menjaga basis data tetap andal. Jika Anda tertarik pada desain basis data secara keseluruhan, lihat kursus lengkap kami Database Design.
Definisi Third Normal Form (3NF)
Third normal form adalah konsep kunci dalam normalisasi basis data yang menghapus dependensi yang tidak diinginkan. 3NF dibangun di atas first normal form (1NF) dan second normal form (2NF), artinya 3NF mewarisi aturannya: 1NF mengharuskan nilai atomik (tak terbagi) di setiap sel, dan 2NF menghapus dependensi parsial pada kunci utama komposit. 3NF melangkah lebih jauh dengan menghapus dependensi transitif, yaitu kondisi ketika atribut non-kunci bergantung secara tidak langsung pada kunci utama.
Dengan berfokus pada hal ini, 3NF memastikan setiap kolom non-kunci dalam tabel terikat langsung ke kunci utama dan tidak pada yang lain. Secara praktis, 3NF membantu meminimalkan redundansi dan menghindari anomali saat menyisipkan, memperbarui, atau menghapus data.
Pada 1970-an, Edgar F. Codd memperkenalkan 3NF untuk memformalkan kondisi guna mencapai struktur basis data yang sepenuhnya dinormalisasi. Reformulasi oleh Carlo Zaniolo beberapa tahun kemudian memberikan penjelasan yang lebih jelas tentang perbedaan antara 3NF “klasik” dan Boyce-Codd normal form (BCNF) yang lebih ketat. Jangan terlalu khawatir tentang BCNF sekarang, kita akan kembali membahasnya di bagian bawah.
Memahami Kondisi untuk Third Normal Form
Jadi, apa saja yang diperlukan untuk mencapai 3NF? Agar sebuah tabel memenuhi syarat, tabel tersebut perlu memenuhi beberapa kondisi:
- Berada dalam 2NF: Artinya data sudah atomik, tanpa grup berulang dan tanpa dependensi parsial pada kunci komposit mana pun.

3NF mencakup 2NF dan 1NF. Gambar oleh Penulis
- Tidak ada dependensi transitif: Aturan ini penting. Dalam tabel 3NF, kolom non-kunci utama mana pun harus bergantung hanya pada kunci utama, bukan secara tidak langsung melalui kolom non-kunci lainnya.
Mari kita lihat apa artinya secara praktis.
Mendekomposisi Tabel untuk Mencapai 3NF
Mari kita telusuri proses dekomposisi tabel untuk mencapai 3NF. Kita akan menggunakan beberapa data contoh dari kursus DataCamp untuk mengilustrasikan setiap langkah.
Langkah 1: Identifikasi dependensi transitif
Pertama, kita akan mencari atribut apa pun dalam tabel yang bergantung secara tidak langsung pada kunci utama. Sebagai aturan praktis, jika ada atribut yang bergantung pada sesuatu selain kunci utama, ini menunjukkan adanya dependensi transitif. Itu tanda bahwa mungkin sudah saatnya memecah tabel Anda.
Perhatikan tiga tabel di bawah ini. Manakah yang memiliki dependensi transitif?
Tabel 1: Course
| Course ID | Course Name | Difficulty |
|---|---|---|
| 201 | SQL Fundamentals | Pemula |
| 202 | Introduction to Python | Pemula |
| 203 | Understanding Data Science | Menengah |
Tabel 2: Instructor
| Instructor ID | Instructor Name | Expertise |
|---|---|---|
| 1 | Sarah Johnson | Data Science |
| 2 | Tom Williams | Machine Learning |
| 3 | Emily Brown | Python |
Tabel 3: Enrollments
| Enrollment ID | Student Name | Course ID | Course Name |
|---|---|---|---|
| 1001 | Alice Smith | 201 | SQL Fundamentals |
| 1002 | Bob Green | 202 | Introduction to Python |
| 1003 | Charlie Blue | 201 | SQL Fundamentals |
Jawabannya adalah… Tabel 3!
Dalam tabel ini, Course Name bergantung pada Course ID, tetapi tidak secara langsung pada Enrollment ID (kunci utama). Ketergantungan tidak langsung ini membuat Course Name menjadi dependensi transitif.
Langkah 2: Pisahkan data ke tabel baru
Untuk mengatasi dependensi transitif, kita akan membagi Tabel 1 menjadi dua tabel. Setiap tabel akan berfokus pada data yang bergantung secara langsung.
Tabel enrollments yang direvisi
| Enrollment ID | Student Name | Course ID |
|---|---|---|
| 1001 | Alice Smith | 201 |
| 1002 | Bob Green | 202 |
| 1003 | Charlie Blue | 201 |
Tabel Courses
| Course ID | Course Name |
|---|---|
| 201 | SQL Fundamentals |
| 202 | Introduction to Python |
Sekarang, setiap tabel hanya memuat informasi yang bergantung langsung pada kunci utamanya: Course ID kini menjadi kunci utama untuk Course Name di tabel Courses, dan Enrollment ID adalah kunci utama di tabel Enrollments.
Dengan dekomposisi ini, tabel-tabel tersebut kini memenuhi persyaratan 3NF, menghilangkan redundansi dan memastikan setiap tabel hanya menyimpan informasi yang relevan secara langsung.
Jika Anda ingin praktik langsung dan membuat basis data sendiri, lihat kursus Creating PostgreSQL Databases kami. Jika Anda sedikit lebih mahir, Anda bisa mencoba Introduction to Data Modeling in Snowflake, yang membahas konsep seperti pemodelan entitas-relasi dan dimensional.
Manfaat dan Keterbatasan Menggunakan Third Normal Form
Lalu, mengapa kita bersusah payah mencapai 3NF? Berikut manfaat utamanya:
- Integritas Data yang Lebih Baik: Dengan menghilangkan dependensi transitif, 3NF membantu memastikan bahwa pembaruan dan penghapusan tidak menyebabkan data yang bertentangan atau usang di seluruh tabel.
- Redundansi Berkurang: Redundansi yang lebih sedikit membuat basis data lebih mudah dipelihara, dan penggunaan penyimpanan berkurang.
- Pemeliharaan Data Lebih Sederhana: Menyimpan informasi serupa dalam tabel khusus memudahkan pembaruan catatan tanpa harus melacak entri yang redundan.
Meski demikian, walaupun struktur 3NF mendukung akurasi data, 3NF juga dapat menghasilkan data yang lebih tersegmen, sehingga kadang membuat kueri kompleks lebih lambat karena tambahan join antar tabel. Dalam kasus ketika kebutuhan kecepatan lebih penting daripada normalisasi, BCNF atau 4NF bisa menjadi opsi yang lebih praktis.
Perbandingan: First, Second, Third, dan Boyce-Codd Normal Forms
Mari kita lihat perbedaan tiap bentuk.
Tabel perbandingan: first, second, dan third normal forms
Berikut tabel perbandingan untuk membantu Anda memahami persyaratan 1NF, 2NF, dan 3NF.
| Fitur | 1NF | 2NF | 3NF |
|---|---|---|---|
| Data atomik | ✅ | ✅ | ✅ |
| Tidak ada dependensi parsial | ❌ | ✅ | ✅ |
| Tidak ada dependensi transitif | ❌ | ❌ | ✅ |
Third normal form vs. Boyce-Codd normal form (BCNF)
BCNF adalah bentuk 3NF yang lebih “ketat” yang lebih lanjut menghilangkan anomali yang muncul karena tumpang tindih candidate key. BCNF bisa sangat berguna dalam kasus kompleks ketika 3NF saja belum sepenuhnya menghilangkan dependensi. BCNF berlaku ketika atribut non-prime bergantung pada atribut yang merupakan bagian dari candidate key komposit. Saya tahu ini terdengar rumit, jadi mari kita uraikan dengan contoh.
Struktur saat ini (dalam 3NF)
Setelah dekomposisi untuk mencapai 3NF, kita memiliki dua tabel berikut:
Tabel Enrollments
| Enrollment ID | Student Name | Course ID |
|---|---|---|
| 1001 | Alice Smith | 201 |
| 1002 | Bob Green | 202 |
| 1003 | Charlie Blue | 201 |
Tabel Courses
| Course ID | Course Name |
|---|---|
| 201 | SQL Fundamentals |
| 202 | Introduction to Python |
Dalam struktur ini, setiap tabel berada dalam 3NF tanpa dependensi transitif, dan data dinormalisasi dengan tepat.
Memperkenalkan persyaratan baru
Sekarang, mari tambahkan atribut baru pada Courses: Classroom tempat setiap kursus diadakan. Atribut baru ini dapat menghasilkan skenario yang memerlukan BCNF.
Tabel courses yang diperbarui (3NF)
| Course ID | Course Name | Classroom |
|---|---|---|
| 201 | SQL Fundamentals | Room 101 |
| 202 | Introduction to Python | Room 102 |
| 203 | Understanding Data Science | Room 101 |
Di sini, Course ID masih menjadi kunci utama, dan semua atribut lain bergantung langsung padanya. Namun, misalkan ada aturan baru bahwa setiap ruang kelas hanya bisa menampung satu mata pelajaran pada satu waktu. Misalkan juga Course Name "SQL Fundamentals" dapat ditawarkan dengan Course ID berbeda (seperti 201, 204, dll.), jika dijadwalkan pada waktu yang berbeda. Dalam kasus itu, setiap penyelenggaraan "SQL Fundamentals" tetap berlangsung di "Room 101," terlepas dari Course ID spesifiknya. Akibatnya, Course Name juga secara unik menentukan Classroom.
Ini berarti kini kita memiliki dua candidate key:
- Course ID
- Course Name
Dengan kedua candidate key tersebut, kita sekarang memiliki masalah yang tidak ditangani oleh 3NF: Classroom bergantung pada Course Name alih-alih hanya pada Course ID.
Menerapkan BCNF
Untuk menghilangkan masalah dependensi ini, kita perlu mendekomposisi tabel Courses lebih lanjut menjadi dua tabel terpisah yang lebih selaras dengan BCNF:
- Tabel Courses yang baru, yang hanya memuat Course ID dan Course Name.
- Tabel CourseDetails, yang menyimpan relasi antara Course Name dan Classroom.
Berikut tampilannya:
Tabel courses yang direvisi (BCNF)
| Course ID | Course Name |
|---|---|
| 201 | SQL Fundamentals |
| 202 | Introduction to Python |
| 203 | Understanding Data Science |
Tabel CourseDetails (BCNF)
| Course Name | Classroom |
|---|---|
| SQL Fundamentals | Room 101 |
| Introduction to Python | Room 102 |
| Understanding Data Science | Room 101 |
Dengan struktur baru ini, setiap tabel memenuhi kondisi BCNF:
- Di tabel Courses, Course ID adalah kunci utama, dan semua atribut bergantung hanya padanya.
- Di tabel CourseDetails, Course Name adalah kunci utama, dan Classroom bergantung hanya pada Course Name.
Pengaturan ini menghapus masalah dependensi apa pun yang disebabkan oleh tumpang tindih candidate key, memastikan struktur yang dinormalisasi secara ketat.
Kesimpulan
Third normal form adalah alat berharga bagi perancang basis data yang ingin menjaga data tetap bersih, konsisten, dan bebas dari dependensi bermasalah. Dengan 3NF, integritas data meningkat, pengelolaan menjadi lebih mulus, dan redundansi berkurang. Ingat, meskipun 3NF bekerja dengan baik di sebagian besar situasi, basis data yang lebih kompleks mungkin mendapatkan manfaat dari bentuk tambahan seperti BCNF atau 4NF.
Jika Anda merasa artikel ini bermanfaat, pertimbangkan untuk melangkah lebih jauh dengan meraih SQL Associate Certification kami. Ini adalah cara yang bagus untuk memvalidasi keterampilan SQL dan manajemen basis data Anda serta menunjukkan keahlian Anda kepada calon pemberi kerja!

Saya adalah tech lead berorientasi produk yang berspesialisasi dalam mengembangkan startup tahap awal dari prototipe pertama hingga mencapai product-market fit dan seterusnya. Saya sangat penasaran dengan cara orang menggunakan teknologi, dan saya senang bekerja erat dengan para founder serta tim lintas fungsi untuk mewujudkan ide-ide berani. Saat tidak membangun produk, saya mencari inspirasi di berbagai penjuru dunia atau melepas penat di studio yoga.
Pertanyaan yang Sering Diajukan tentang Third Normal Form
Apakah 3NF dapat diterapkan pada semua jenis basis data?
Walau 3NF efektif dalam basis data relasional, 3NF tidak selalu diperlukan untuk basis data NoSQL, yang sering memprioritaskan fleksibilitas dan skalabilitas dibandingkan normalisasi yang ketat. Dalam beberapa kasus, skema terdenormalisasi mungkin lebih disukai demi kinerja, terutama saat melakukan kueri data dalam jumlah besar dengan cepat.
Apa kelemahan mematuhi 3NF secara ketat?
Kepatuhan ketat pada 3NF kadang dapat menyebabkan skema kompleks dengan banyak tabel, yang mungkin memerlukan beberapa join dalam kueri. Hal ini dapat berdampak negatif pada kinerja, terutama pada basis data besar atau sistem dengan volume transaksi tinggi. Dalam kasus seperti itu, pendekatan alternatif seperti denormalisasi atau menggunakan BCNF mungkin lebih praktis.
Bisakah 3NF diterapkan pada basis data yang sudah ada, atau saya harus mendesain ulang?
3NF tentu dapat diterapkan pada basis data yang sudah ada, meski mungkin memerlukan restrukturisasi signifikan. Proses ini, yang disebut refaktorisasi basis data, melibatkan dekomposisi tabel untuk menghilangkan redundansi dan dependensi. Bergantung pada ukuran dan kompleksitas basis data, proses ini mungkin memerlukan perencanaan dan pengujian untuk memastikan integritas data dan kinerja sistem tetap terjaga.
Alat atau teknik apa yang dapat membantu mengotomatisasi proses mencapai 3NF?
Ada beberapa alat desain basis data yang tersedia, seperti MySQL Workbench, Oracle SQL Developer, dan ER/Studio, yang membantu memvisualisasikan skema basis data dan mengidentifikasi masalah normalisasi. Beberapa alat ini dapat menyarankan atau mengotomatisasi langkah-langkah untuk mencapai 3NF, meski pengawasan manusia tetap penting untuk memastikan integritas dan konsistensi data.
Apa perbedaan antara candidate key dan primary key?
Sebuah candidate key adalah himpunan atribut minimal yang dapat mengidentifikasi setiap baris dalam tabel secara unik. Bisa ada beberapa candidate key dalam satu tabel. Primary key, di sisi lain, adalah candidate key spesifik yang dipilih perancang basis data untuk mengidentifikasi baris secara unik. Hanya satu primary key yang diperbolehkan per tabel, dan tidak boleh memiliki nilai NULL.
Mengapa kita memerlukan Boyce-Codd normal form (BCNF) jika sebuah tabel sudah berada dalam third normal form (3NF)?
BCNF lebih ketat daripada 3NF dan menangani kasus ketika dependensi ada pada candidate key. Sementara 3NF menghapus dependensi transitif, 3NF masih dapat membiarkan redundansi jika suatu ketergantungan fungsional memiliki penentu yang bukan superkey. BCNF menghilangkan hal ini dengan memastikan semua ketergantungan fungsional memiliki superkey di sisi kiri.
Bisakah sebuah tabel memiliki lebih dari satu candidate key?
Ya, sebuah tabel dapat memiliki beberapa candidate key. Setiap candidate key adalah himpunan atribut yang unik dan minimal untuk mengidentifikasi baris.
