Kursus
Normalisasi adalah salah satu konsep paling mendasar dalam desain database relasional. Dalam panduan ini, saya membahas setiap bentuk normal (dari 1NF hingga 5NF) dengan contoh dunia nyata, sehingga Anda dapat menerapkan prinsip-prinsip ini pada database Anda sendiri. Baik Anda ingin menjadi data scientist maupun data engineer, memahami normalisasi itu penting.
Ringkasan
- Normalisasi mengatur tabel database relasional untuk menghilangkan redundansi dan menjaga integritas data
- 1NF: Setiap sel menyimpan satu nilai atomik; setiap baris dapat diidentifikasi secara unik
- 2NF: Hilangkan ketergantungan parsial—kolom non-kunci harus bergantung pada seluruh kunci utama
- 3NF: Hilangkan ketergantungan transitif—kolom non-kunci hanya bergantung pada kunci utama, bukan pada kolom non-kunci lain
- BCNF, 4NF, 5NF: Menangani ketergantungan fungsional, multi-nilai, dan join untuk skema yang kompleks
- Kebanyakan database produksi hanya perlu dinormalisasi hingga 3NF; bentuk yang lebih tinggi berlaku untuk kasus penggunaan khusus
Apa itu Normalisasi dalam SQL?
Normalisasi, dalam konteks ini, adalah proses mengatur data di dalam database (database relasional) untuk menghilangkan anomali data, seperti redundansi.
Secara sederhana, ini melibatkan pemecahan sebuah tabel besar dan kompleks menjadi tabel-tabel yang lebih kecil dan sederhana sambil mempertahankan hubungan data.
Normalisasi umumnya digunakan saat menangani dataset besar.
Mari kita lihat secara singkat beberapa skenario di mana normalisasi sering digunakan.
Integritas data
Bayangkan sebuah database yang berisi informasi pelanggan. Tanpa normalisasi, jika seorang pelanggan mengubah usianya, kita harus memperbaruinya di banyak tempat, yang meningkatkan risiko inkonsistensi. Dengan menormalisasi data, kita dapat memiliki tabel terpisah yang ditautkan oleh pengenal unik yang memastikan data tetap akurat dan konsisten.
Query yang efisien
Pertimbangkan sebuah database kompleks dengan banyak tabel terkait yang menyimpan informasi berlebih. Dalam skenario ini, query yang melibatkan join menjadi lebih rumit dan membutuhkan banyak sumber daya. Normalisasi akan membantu menyederhanakan query dengan memecah data ke dalam tabel yang lebih kecil, dengan tiap tabel hanya berisi informasi relevan, sehingga mengurangi kebutuhan join yang kompleks.
Optimasi penyimpanan
Masalah besar dengan data yang redundan adalah memakan ruang penyimpanan yang tidak perlu. Misalnya, jika kita menyimpan detail produk yang sama di setiap catatan pesanan, itu menyebabkan duplikasi. Dengan normalisasi, Anda dapat menghilangkan redundansi dengan membagi data ke dalam tabel terpisah.
Mengapa Normalisasi dalam SQL Penting?
Normalisasi memainkan peran krusial dalam desain database. Berikut beberapa alasannya:
- Mengurangi redundansi:Redundansi terjadi ketika informasi yang sama disimpan berulang kali, dan cara yang baik untuk menghindarinya adalah dengan memecah data ke dalam tabel yang lebih kecil.
- Meningkatkan kinerja query: Anda dapat mengeksekusi query lebih cepat pada tabel yang lebih kecil yang telah dinormalisasi.
- Meminimalkan anomali pembaruan: Dengan tabel yang dinormalisasi, Anda dapat memperbarui data dengan mudah tanpa memengaruhi catatan lain.
- Meningkatkan integritas data: Memastikan data tetap konsisten dan akurat.
Apa yang Menyebabkan Perlunya Normalisasi?
Jika sebuah tabel tidak dinormalisasi dengan baik dan memiliki redundansi data, itu tidak hanya akan memakan ruang penyimpanan ekstra tetapi juga menyulitkan penanganan dan pembaruan database.
Ada beberapa faktor yang mendorong kebutuhan normalisasi, mulai dari redundansi data (seperti dibahas di atas) hingga kesulitan mengelola relasi. Mari langsung masuk:
- Anomali penyisipan, penghapusan, dan pembaruan: Setiap bentuk perubahan pada tabel dapat menimbulkan kesalahan atau inkonsistensi pada tabel lain jika tidak ditangani dengan hati-hati. Perubahan ini bisa berupa menambahkan data baru ke database, memperbarui data, atau menghapus catatan, yang dapat menyebabkan hilangnya data yang tidak diinginkan.
- Kesulitan mengelola relasi: Menjaga relasi yang kompleks menjadi lebih menantang dalam struktur yang tidak dinormalisasi.
- Faktor lain yang mendorong kebutuhan normalisasi adalah ketergantungan parsial dan ketergantungan transitif, di mana ketergantungan parsial dapat menyebabkan redundansi data dan anomali pembaruan, dan ketergantungan transitif dapat menyebabkan anomali data. Kita akan melihat bagaimana ketergantungan ini dapat ditangani untuk memastikan normalisasi database pada bagian berikutnya.
Berbagai Jenis Normalisasi Database
Sejauh ini, kita telah melihat apa itu normalisasi dalam SQL, mengapa normalisasi dalam SQL penting, dan apa yang menyebabkan perlunya normalisasi. Normalisasi database hadir dalam berbagai bentuk, masing-masing dengan tingkat pengorganisasian data yang meningkat.
Di bagian ini, kita akan membahas singkat level-level normalisasi yang berbeda dan kemudian mengeksplorasinya lebih dalam pada bagian berikutnya.

Gambar oleh Penulis
Perbandingan cepat bentuk normal
| Bentuk Normal | Persyaratan | Apa yang Dihilangkan |
|---|---|---|
| 1NF | Nilai atomik di setiap sel; baris unik | Grup berulang dan sel multi-nilai |
| 2NF | Tidak ada ketergantungan parsial pada kunci komposit | Redundansi dari relasi kunci parsial |
| 3NF | Tidak ada ketergantungan transitif | Ketergantungan tidak langsung antar kolom non-kunci |
| BCNF | Setiap determinan adalah kunci kandidat | Anomali yang terlewat oleh 3NF |
| 4NF | Tidak ada ketergantungan multi-nilai | Atribut multi-nilai yang independen |
| 5NF | Tidak ada ketergantungan join | Redundansi dari dekomposisi tabel yang merugi |
First Normal Form (1NF)
Level normalisasi ini memastikan setiap kolom dalam data Anda hanya berisi nilai yang atomik. Nilai atomik di sini berarti setiap entri dalam kolom tidak dapat dibagi lagi. Ibaratnya, setiap sel dalam spreadsheet harus menyimpan satu potong informasi saja. 1NF memastikan atomisitas data, dengan setiap sel kolom hanya berisi satu nilai dan setiap kolom memiliki nama yang unik.
Second Normal Form (2NF)
Menghilangkan ketergantungan parsial dengan memastikan bahwa atribut non-kunci hanya bergantung pada kunci utama. Intinya, harus ada hubungan langsung antara setiap kolom dan kunci utama, bukan antara kolom lainnya.
Third Normal Form (3NF)
Menghapus ketergantungan transitif dengan memastikan atribut non-kunci hanya bergantung pada kunci utama. Level normalisasi ini dibangun di atas 2NF.
Boyce-Codd Normal Form (BCNF)
Ini adalah versi 3NF yang lebih ketat yang menangani anomali tambahan. Pada level normalisasi ini, setiap determinan adalah kunci kandidat.
Fourth Normal Form (4NF)
Ini adalah level normalisasi yang dibangun di atas BCNF dengan menangani ketergantungan multi-nilai.
Fifth Normal Form (5NF)
5NF adalah level normalisasi tertinggi yang menangani ketergantungan join. Ini digunakan dalam skenario tertentu untuk semakin meminimalkan redundansi dengan memecah sebuah tabel menjadi tabel yang lebih kecil.
Normalisasi Database dengan Contoh Dunia Nyata
Kita telah menyoroti semua level normalisasi data. Mari kita jelajahi masing-masing secara lebih mendalam dengan contoh dan penjelasan.
Normalisasi First Normal Form (1NF)
1NF memastikan bahwa setiap sel kolom hanya berisi nilai atomik. Bayangkan database perpustakaan dengan tabel yang menyimpan informasi buku (title, author, genre, dan borrowed_by). Jika tabel tidak dinormalisasi, borrowed_by bisa berisi daftar nama peminjam yang dipisahkan koma. Ini melanggar 1NF, karena satu sel menyimpan banyak nilai. Tabel di bawah ini merupakan representasi yang baik dari tabel yang melanggar 1NF, seperti yang dijelaskan sebelumnya.
title | author | genre | borrowed_by |
To Kill a Mockingbird | Harper Lee | Fiksi | John Doe, Jane Doe, James Brown |
The Lord of the Rings | J. R. R. Tolkien | Fantasi | Emily Garcia, David Lee |
Harry Potter and the Sorcerer’s Stone | J.K. Rowling | Fantasi | Michael Chen |
Solusinya?
Dalam 1NF, kita membuat tabel terpisah untuk peminjam dan menautkannya ke tabel buku. Tabel-tabel ini bisa ditautkan menggunakan foreign key di tabel peminjam atau tabel penghubung terpisah. Pendekatan foreign key di tabel borrowers melibatkan penambahan kolom foreign key ke tabel peminjam yang mereferensikan kunci utama tabel buku. Ini akan menegakkan relasi antartabel, memastikan konsistensi data.
Representasinya dapat Anda lihat di bawah:
Berikut SQL untuk membuat tabel yang dinormalisasi ini:
CREATE TABLE books (
book_id INT PRIMARY KEY,
title VARCHAR(255),
author VARCHAR(100),
genre VARCHAR(50)
);
CREATE TABLE borrowers (
borrower_id INT PRIMARY KEY,
name VARCHAR(100),
book_id INT,
FOREIGN KEY (book_id) REFERENCES books(book_id)
);Tabel Books
book_id (PK) | title | author | genre |
1 | To Kill a Mockingbird | Harper Lee | Fiksi |
2 | The Lord of the Rings | J. R. R. Tolkien | Fantasi |
3 | Harry Potter and the Sorcerer’s Stone | J.K. Rowling | Fantasi |
Tabel Borrowers
borrower_id (PK) | name | book_id (FK) |
1 | John Doe | 1 |
2 | Jane Doe | 1 |
3 | James Brown | 1 |
4 | Emily Garcia | 2 |
5 | David Lee | 2 |
6 | Michael Chen | 3 |
Second Normal Form (2NF)
Level normalisasi ini, seperti yang telah dijelaskan, dibangun di atas 1NF dengan memastikan tidak ada ketergantungan parsial pada kunci utama. Sederhananya, semua atribut non-kunci harus bergantung pada seluruh kunci utama dan bukan hanya sebagian darinya.
Dari 1NF yang telah diterapkan, kita sudah memiliki dua tabel terpisah (silakan lihat bagian 1NF).
Sekarang, misalkan kita ingin menautkan tabel-tabel ini untuk mencatat peminjaman. Pendekatan awal mungkin dengan menambahkan kolom borrower_id ke tabel books, seperti di bawah ini:
book_id (PK) | title | author | genre | borrower_id (FK) |
1 | To Kill a Mockingbird | Harper Lee | Fiksi | 1 |
2 | The Lord of the Rings | J. R. R. Tolkien | Fantasi | NULL |
3 | Harry Potter and the Sorcerer’s Stone | J.K. Rowling | Fantasi | 6 |
Ini tampak seperti solusi, tetapi melanggar 2NF karena borrower_id hanya sebagian bergantung pada book_id. Sebuah buku bisa memiliki banyak peminjam, tetapi satu borrower_id hanya bisa ditautkan ke satu buku dalam struktur ini. Ini menciptakan ketergantungan parsial.
Solusinya?
Kita perlu mewujudkan relasi many-to-many antara buku dan peminjam untuk mencapai 2NF. Ini dapat dilakukan dengan memperkenalkan tabel terpisah:
Tabel Book_borrowings
| borrowing_id (PK) | book_id (FK) | borrower_id (FK) | borrowed_date |
|---|---|---|---|
| 1 | 1 | 1 | 2024-05-04 |
| 2 | 2 | 4 | 2024-05-04 |
| 3 | 3 | 6 | 2024-05-04 |
Tabel ini membentuk relasi yang jelas antara buku dan peminjam. book_id dan borrower_id bertindak sebagai foreign key, mereferensikan kunci utama di tabel masing-masing. Pendekatan ini memastikan borrower_id bergantung pada seluruh kunci utama (book_id) dari tabel buku, sehingga memenuhi 2NF.
Third Normal Form (3NF)
3NF dibangun di atas 2NF dengan menghilangkan ketergantungan transitif. Ketergantungan transitif terjadi ketika atribut non-kunci bergantung pada atribut non-kunci lain yang pada gilirannya bergantung pada kunci utama. Ini pada dasarnya mengacu pada hukum transitif.
Dari 2NF yang sudah diterapkan, ada tiga tabel dalam database perpustakaan kita:
Tabel Books
book_id (PK) | title | author | genre |
1 | To Kill a Mockingbird | Harper Lee | Fiksi |
2 | The Lord of the Rings | J. R. R. Tolkien | Fantasi |
3 | Harry Potter and the Sorcerer’s Stone | J.K. Rowling | Fantasi |
Tabel Borrowers
borrower_id (PK) | name | book_id (FK) |
1 | John Doe | 1 |
2 | Jane Doe | 1 |
3 | James Brown | 1 |
4 | Emily Garcia | 2 |
5 | David Lee | 2 |
6 | Michael Chen | 3 |
Tabel Book_borrowings
borrowing_id (PK) | book_id (FK) | borrower_id (FK) | borrowed_date |
1 | 1 | 1 | 2024-05-04 |
2 | 2 | 4 | 2024-05-04 |
3 | 3 | 6 | 2024-05-04 |
Struktur 2NF terlihat efisien, tetapi mungkin ada ketergantungan tersembunyi. Bayangkan kita menambahkan kolom due_date ke tabel books. Ini tampak logis pada pandangan pertama, tetapi akan membuat ketergantungan transitif di mana:
- Kolom due_date bergantung pada borrowing_id (atribut non-kunci) dari tabel book_borrowings.
- borrowing_id pada gilirannya bergantung pada book_id (kunci utama) dari tabel books.
Implikasinya adalah due_date bergantung pada atribut non-kunci perantara (borrowing_id) alih-alih langsung bergantung pada kunci utama (book_id). Ini melanggar 3NF.
Solusinya?
Kita dapat memindahkan kolom due_date ke tabel yang paling tepat dengan memperbarui tabel book_borrowings agar menyertakan kolom due_date dan returned_date.
Berikut tabel yang diperbarui:
borrowing_id (PK) | book_id (FK) | borrower_id (FK) | borrowed_date | due_date |
1 | 1 | 1 | 2024-05-04 | 2024-05-20 |
2 | 2 | 4 | 2024-05-04 | 2024-05-18 |
3 | 3 | 6 | 2024-05-04 | 2024-05-10 |
Dengan menempatkan kolom due_date di tabel book_borrowing, kita berhasil menghilangkan ketergantungan transitif.
Artinya due_date kini langsung bergantung pada hubungan gabungan antara book_id dan borrower_id. Dalam konteks ini, book_id dan borrower_id bertindak sebagai foreign key komposit, yang bersama-sama membentuk kunci utama tabel book_borrowings.
Boyce-Codd Normal Form (BCNF)
BCNF didasarkan pada ketergantungan fungsional yang mempertimbangkan semua kunci kandidat dalam sebuah relasi.
Ketergantungan fungsional (FD) mendefinisikan hubungan antar atribut dalam sebuah database relasional. FD menyatakan bahwa nilai satu kolom menentukan nilai kolom terkait lainnya. FD sangat penting karena memandu proses normalisasi dengan mengidentifikasi ketergantungan dan memastikan data didistribusikan secara tepat di seluruh tabel.
BCNF adalah versi 3NF yang lebih ketat. Ini memastikan bahwa setiap determinan (sekumpulan atribut yang mengidentifikasi baris secara unik) dalam sebuah tabel adalah kunci kandidat (sekumpulan atribut minimal yang mengidentifikasi baris secara unik). Intinya, semua determinan harus dapat berfungsi sebagai kunci utama.
Ini memastikan bahwa setiap ketergantungan fungsional (FD) memiliki superkey sebagai determinant. Dengan kata lain, jika X —> Y (X menentukan Y) berlaku, X harus menjadi kunci kandidat (superkey) dari relasi. Harap dicatat bahwa X dan Y adalah kolom dalam sebuah tabel data.
Sebagai kelanjutan dari 3NF, kita memiliki tiga tabel:
Tabel Books
book_id (PK) | title | author | genre |
1 | To Kill a Mockingbird | Harper Lee | Fiksi |
2 | The Lord of the Rings | J. R. R. Tolkien | Fantasi |
3 | Harry Potter and the Sorcerer’s Stone | J.K. Rowling | Fantasi |
Tabel Borrowers
borrower_id (PK) | name | book_id (FK) |
1 | John Doe | 1 |
2 | Jane Doe | 1 |
3 | James Brown | 1 |
4 | Emily Garcia | 2 |
5 | David Lee | 2 |
6 | Michael Chen | 3 |
Tabel Book_borrowings
borrowing_id (PK) | book_id (FK) | borrower_id (FK) | borrowed_date | due_date |
1 | 1 | 1 | 2024-05-04 | 2024-05-20 |
2 | 2 | 4 | 2024-05-04 | 2024-05-18 |
3 | 3 | 6 | 2024-05-04 | 2024-05-10 |
Meski struktur 3NF sudah baik, mungkin ada determinan tersembunyi di tabel book_borrowings. Dengan asumsi satu peminjam tidak bisa meminjam buku yang sama dua kali secara bersamaan, kombinasi book_id dan borrower_id secara bersama-sama mengidentifikasi catatan peminjaman secara unik.
Struktur ini melanggar BCNF karena himpunan gabungan (book_id dan borrower_id) bukan kunci utama tabel (yang hanya borrowing_id).
Solusinya?
Untuk mencapai BCNF, kita bisa memecah tabel book_borrowings menjadi dua tabel terpisah atau menjadikan himpunan atribut gabungan sebagai kunci utama.
- Pendekatan 1 (memecah tabel): Dalam pendekatan ini, kita akan memecah tabel book_borrowings menjadi tabel terpisah:
- Sebuah tabel dengan borrowing_id sebagai kunci utama, borrowed_date, due_date, dan returned_date.
- Tabel terpisah lain untuk menautkan buku dan peminjam, dengan book_id sebagai foreign key, borrower_id sebagai foreign key, dan kemungkinan atribut tambahan khusus peristiwa peminjaman.
- Pendekatan 2 (menjadikan atribut gabungan sebagai kunci utama): Kita dapat mempertimbangkan menjadikan book_id dan borrower_id sebagai kunci utama komposit untuk mengidentifikasi catatan peminjaman secara unik. Masalah pendekatan ini adalah tidak akan berfungsi jika seorang peminjam dapat meminjam buku yang sama beberapa kali.
Pada akhirnya, pilihan Anda bergantung pada kebutuhan data spesifik dan bagaimana Anda ingin memodelkan relasi peminjaman.
Fourth Normal Form (4NF)
4NF menangani ketergantungan multi-nilai. Ketergantungan multi-nilai ada ketika satu atribut dapat memiliki banyak atribut bergantung, dan atribut-atribut bergantung ini independen dari kunci utama. Ini cukup kompleks, tetapi kita akan mengeksplorasinya lebih jauh dengan contoh.
Contoh perpustakaan yang kita gunakan sepanjang penjelasan ini tidak berlaku pada level normalisasi ini. 4NF biasanya diterapkan pada situasi di mana satu atribut mungkin memiliki banyak atribut bergantung yang tidak langsung terkait dengan kunci utama.
Mari gunakan skenario lain. Bayangkan sebuah database yang menyimpan informasi tentang publikasi. Kita akan mempertimbangkan tabel “Publications” dengan kolom title, author, publication_year, dan keywords.
publication_id (PK) | title | author | publication_year | keywords |
1 | To Kill a Mockingbird | Harper Lee | 1960 | Coming-of-Age, Legal |
2 | The Lord of the Rings | J. R. R. Tolkien | 1954 | Fantasy, Epic, Adventure |
3 | Pride and Prejudice | Jane Austen | 1813 | Romance, Social Commentary |
Struktur tabel di atas melanggar 4NF karena:
- Kolom keywords memiliki ketergantungan multi-nilai pada kunci utama publication_id. Artinya, sebuah publikasi dapat memiliki banyak kata kunci, dan kata kunci ini independen dari pengenal unik publikasi.
Solusinya?
Kita dapat membuat tabel terpisah.
Tabel Publication_keywords
publication_id (FK) | keyword |
1 | Coming-of-Age |
1 | Legal |
2 | Fantasy |
2 | Epic |
2 | Adventure |
3 | Romance |
3 | Social Commentary |
Tabel yang baru dibuat (Publication_keywords) membentuk relasi many-to-many antara publikasi dan kata kunci. Setiap publikasi dapat memiliki banyak kata kunci yang ditautkan melalui publication_id, yang merupakan foreign key, dan setiap kata kunci dapat dikaitkan dengan banyak publikasi.
Dengan ini, kita berhasil menghilangkan ketergantungan multi-nilai dan mencapai 4NF.
Fifth Normal Form (5NF)
5NF adalah bentuk normalisasi paling kompleks yang menghilangkan ketergantungan join. Ini adalah situasi ketika data perlu dijoin dari beberapa tabel untuk menjawab query tertentu, bahkan saat tabel-tabel tersebut sudah berada pada 4NF.
Secara sederhana, 5NF memastikan tidak ada informasi tambahan yang dapat diturunkan dengan menggabungkan tabel-tabel yang tidak tersedia di tabel terpisahnya.
Ketergantungan join lebih jarang terjadi ketika tabel sudah dinormalisasi (di 3NF atau 4NF), karenanya sulit membuat contoh 5NF yang jelas dan lugas.
Namun, mari lihat skenario di mana 5NF mungkin relevan:
Bayangkan database universitas dengan tabel “Courses” dan “Enrollments” yang sudah dinormalisasi.
Tabel Courses
course_id (PK) | course_name | department |
101 | Introduction to Programming | Ilmu Komputer |
202 | Data Structures and Algorithms | Ilmu Komputer |
301 | Web Development I | Ilmu Komputer |
401 | Artificial Intelligence | Ilmu Komputer |
Tabel Enrollments
enrollment_id (PK) | student_id (FK) | course_id (FK) | grade |
1 | 12345 | 101 | A |
2 | 12345 | 202 | B |
3 | 56789 | 301 | A- |
4 | 56789 | 401 | B+ |
Dengan asumsi tabel-tabel ini sudah pada 3NF atau 4NF, ketergantungan join mungkin ada tergantung bagaimana data disimpan. Misalnya, sebuah mata kuliah memiliki prasyarat yang disimpan di dalam tabel “Courses” sebagai kolom “prerequisite_course_id”.
Ini tampak efisien pada pandangan pertama. Namun, pertimbangkan query yang perlu mengambil mata kuliah yang diambil seorang mahasiswa dan prasyaratnya masing-masing. Dalam skenario ini, Anda perlu menggabungkan tabel “Courses” dan “Enrollments”, lalu mungkin menggabungkan tabel “Courses” lagi untuk mengambil informasi prasyarat.
Solusinya?
Untuk berpotensi menghilangkan ketergantungan join dan mencapai 5NF, kita bisa memperkenalkan tabel “Course Prerequisites” terpisah:
Tabel Course_prerequisite
course_id (FK) | prerequisite_course_id (FK) |
202 | 101 |
301 | NULL |
401 | 202 |
Pendekatan ini memisahkan informasi prasyarat dan memungkinkan pengambilan mata kuliah yang diambil dan prasyaratnya secara efisien dalam satu join antara tabel “Enrollments” dan “Course_prerequisites”.
Catatan: Kita berasumsi seorang mahasiswa hanya memiliki satu prasyarat per mata kuliah.
5NF adalah tipe normalisasi yang sangat kompleks dan jarang, sehingga bagi pemula Anda mungkin belum menemukan penerapannya. Namun, ini akan menambah pengetahuan dan membuat Anda siap saat menemui database yang kompleks.
Normalisasi vs. Denormalisasi
Meskipun normalisasi mengurangi redundansi dan meningkatkan integritas data, ada kasus di mana denormalisasi adalah pilihan yang lebih baik. Denormalisasi secara sengaja memperkenalkan redundansi untuk meningkatkan performa baca untuk beban kerja tertentu.
| Kriteria | Normalisasi | Denormalisasi |
|---|---|---|
| Tujuan | Mengurangi redundansi dan anomali | Meningkatkan performa baca/query |
| Terbaik untuk | Sistem OLTP (transaksi) | Sistem OLAP (analitik, pelaporan) |
| Kecepatan tulis | Lebih cepat (perbarui di satu tempat) | Lebih lambat (perbarui di banyak tempat) |
| Kecepatan baca | Bisa lebih lambat (butuh lebih banyak join) | Lebih cepat (butuh lebih sedikit join) |
| Integritas data | Lebih tinggi | Lebih rendah (risiko inkonsistensi) |
| Penyimpanan | Lebih sedikit (tanpa data duplikat) | Lebih banyak (data duplikat yang disengaja) |
Dalam praktiknya, sebagian besar database produksi menggunakan kombinasi kedua pendekatan ini. Mulailah dengan skema yang sepenuhnya dinormalisasi, lalu lakukan denormalisasi secara selektif pada tabel di mana performa query menuntutnya.
Bangun Keterampilan SQL Anda
Jika Anda membaca sampai sini, selamat telah bertahan hingga akhir. Kita telah menjelajahi apa itu normalisasi dalam SQL, mengapa normalisasi dalam SQL penting, apa yang menyebabkan perlunya normalisasi, dan berbagai jenis normalisasi database. Skenario yang digunakan untuk menjelaskan berbagai jenis normalisasi bertujuan agar Anda benar-benar memahami dan dapat menerapkan pengetahuan ini dalam perjalanan belajar Anda.
Normalisasi adalah keterampilan mendasar bagi siapa pun yang memulai karier di jalur terkait data. Dengan memahami prinsip-prinsip ini, Anda kini siap membangun database yang efisien dan tertata dengan baik.
Pembelajaran sangat penting di dunia data, dan untuk meningkatkan keterampilan SQL Anda, kami memiliki beberapa sumber untuk Anda.
FAQ
Apa itu normalisasi dalam DBMS?
Normalisasi database adalah teknik untuk merancang skema database relasional secara optimal. Ini melibatkan pembagian tabel menjadi sub-tabel yang lebih kecil dan menyimpan pointer ke data alih-alih mereplikasi data.
Mengapa normalisasi itu penting?
Normalisasi membantu mencegah redundansi data, meningkatkan integritas data, dan menyederhanakan manipulasi data di dalam database.
Apakah saya perlu menormalisasi database hingga 5NF?
Tidak selalu. Normalisasi 3NF atau 4NF sering kali sudah cukup untuk sebagian besar database. 5NF adalah bentuk paling ketat dan mungkin bermanfaat untuk database kompleks dengan pola query tertentu.
Bagaimana cara memutuskan apakah saya perlu menormalisasi hingga 5NF?
Analisis dengan cermat query dan model data Anda. Jika Anda sering perlu menggabungkan banyak tabel untuk mengambil informasi yang secara teori dapat diturunkan dari tabel-tabel terpisah itu sendiri, maka 5NF mungkin layak dipertimbangkan. Namun, selalu pertimbangkan kompleksitas dibandingkan potensi peningkatan performa. Anda dapat merujuk bagian 5NF, di mana digunakan skenario kasus untuk pemahaman lebih lanjut.
Apa perbedaan antara normalisasi dan denormalisasi?
Normalisasi menata database untuk mengurangi redundansi dengan memecah data menjadi tabel-tabel yang lebih kecil dan saling terkait. Denormalisasi kebalikannya: secara sengaja memperkenalkan redundansi untuk meningkatkan performa baca. Kebanyakan database produksi memulai dengan normalisasi lalu melakukan denormalisasi secara selektif untuk beban kerja yang banyak query seperti pelaporan dan analitik.
Bentuk normal apa yang paling umum digunakan dalam praktik?
Third Normal Form (3NF) adalah level normalisasi yang paling banyak digunakan dalam database produksi. Ini menghilangkan redundansi dari ketergantungan parsial dan transitif sekaligus menjaga skema tetap praktis. Bentuk normal yang lebih tinggi seperti BCNF, 4NF, dan 5NF lebih jarang digunakan dan biasanya hanya pada skenario khusus dengan relasi data yang kompleks.
Profesional data dan penulis berpengalaman yang bersemangat memberdayakan calon ahli di bidang data.

