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.
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.
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
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
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
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.
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.
Mari kita lihat perbedaan tiap bentuk.
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 | ❌ | ❌ | ✅ |
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
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)
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)
Tabel CourseDetails (BCNF)
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!
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:
3NF mencakup 2NF dan 1NF. Gambar oleh Penulis
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
Tabel 2: Instructor
Tabel 3: Enrollments
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
Tabel Courses
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:
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.
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
Tabel Courses
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)
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:
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:
Berikut tampilannya:
Tabel courses yang direvisi (BCNF)
Tabel CourseDetails (BCNF)
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!