Apa itu Normalisasi dalam SQL?

Normalisasi, dalam konteks ini, adalah proses pengorganisasian data dalam basis data ( basis data relasional ) untuk menghilangkan anomali data, seperti redundansi.

Dalam istilah yang lebih sederhana, ini melibatkan pemecahan tabel yang besar dan kompleks menjadi tabel yang lebih kecil dan lebih sederhana dengan tetap menjaga hubungan data.

Normalisasi umumnya digunakan saat menangani kumpulan data besar.

Mari kita lihat sekilas beberapa skenario di mana normalisasi sering digunakan.

Integritas data

Bayangkan sebuah basis data yang berisi informasi pelanggan. Tanpa normalisasi, jika pelanggan mengubah usianya, kami perlu memperbaruinya di beberapa tempat, yang akan meningkatkan risiko ketidakkonsistenan. Dengan menormalkan data, kami dapat memiliki tabel terpisah yang ditautkan dengan pengenal unik yang akan memastikan bahwa data tetap akurat dan konsisten.

Permintaan efisiensi

Mari kita pertimbangkan database yang kompleks dengan beberapa tabel terkait yang menyimpan informasi yang redundan. Dalam skenario ini, kueri yang melibatkan penggabungan menjadi lebih rumit dan membutuhkan banyak sumber daya. Normalisasi akan membantu menyederhanakan kueri dengan memecah data menjadi tabel yang lebih kecil, dengan setiap tabel hanya berisi informasi yang relevan, sehingga mengurangi kebutuhan akan penggabungan yang kompleks.

Optimasi penyimpanan

Masalah utama dengan data yang redundan adalah data tersebut menempati ruang penyimpanan yang tidak diperlukan. Misalnya, jika kita menyimpan detail produk yang sama di setiap catatan pesanan, hal itu menyebabkan duplikasi. Dengan normalisasi, Anda dapat menghilangkan redundansi dengan membagi data ke dalam tabel terpisah.

Mengapa Normalisasi dalam SQL Penting?

Normalisasi memegang peranan penting dalam desain basis data. Berikut ini beberapa alasan mengapa hal ini penting:

• Mengurangi redundansi: Redundansi terjadi ketika informasi yang sama disimpan beberapa kali, dan cara yang baik untuk menghindarinya adalah dengan membagi data ke dalam tabel yang lebih kecil.
• Meningkatkan kinerja kueri: Anda dapat melakukan eksekusi kueri yang lebih cepat pada tabel yang lebih kecil yang telah mengalami normalisasi.
• Meminimalkan anomali pembaruan: Dengan tabel yang dinormalisasi, Anda dapat dengan mudah memperbarui data tanpa memengaruhi rekaman lainnya.
• Meningkatkan integritas data: Memastikan bahwa data tetap konsisten dan akurat.

Apa yang Menyebabkan Perlunya Normalisasi?

Jika suatu tabel tidak dinormalisasi dengan benar dan memiliki redundansi data, hal itu tidak hanya akan menghabiskan ruang penyimpanan data ekstra tetapi juga akan mempersulit penanganan dan pembaruan basis data.

Ada beberapa faktor yang mendorong perlunya normalisasi, mulai dari redundansi data (seperti yang dibahas di atas) hingga kesulitan mengelola hubungan. Mari kita bahas secara langsung:

• Anomali penyisipan, penghapusan, dan pembaruan: Segala bentuk perubahan dalam tabel dapat menyebabkan kesalahan atau ketidakkonsistenan pada tabel lain jika tidak ditangani dengan hati-hati. Perubahan ini dapat berupa penambahan data baru ke dalam basis data, pembaruan data, atau penghapusan catatan, yang dapat menyebabkan hilangnya data yang tidak diinginkan.
• Kesulitan dalam mengelola hubungan: Menjadi lebih menantang untuk mempertahankan hubungan yang kompleks dalam struktur yang tidak dinormalisasi.
• Faktor lain yang mendorong perlunya normalisasi adalah dependensi parsial dan dependensi transitif , di mana dependensi parsial dapat menyebabkan redundansi data dan anomali pembaruan, dan dependensi transitif dapat menyebabkan anomali data. Kita akan melihat bagaimana dependensi ini dapat ditangani untuk memastikan normalisasi basis data di bagian selanjutnya.

Berbagai Jenis Normalisasi Basis Data

Sejauh ini, kita telah melihat apa itu normalisasi dalam SQL , mengapa normalisasi dalam SQL penting, dan apa yang menyebabkan perlunya normalisasi. Normalisasi basis data hadir dalam berbagai bentuk , masing-masing dengan tingkat organisasi data yang semakin meningkat.

Di bagian ini, kita akan membahas secara singkat berbagai tingkat normalisasi dan kemudian menjelajahinya lebih dalam di bagian berikutnya.

Bentuk Normal Pertama (1NF)

Tingkat normalisasi ini memastikan bahwa setiap kolom dalam data Anda hanya berisi nilai atomik. Nilai atomik dalam konteks ini berarti bahwa setiap entri dalam kolom tidak dapat dibagi. Ini seperti mengatakan bahwa setiap sel dalam spreadsheet hanya boleh memuat satu informasi. 1NF memastikan sifat atomik data, dengan setiap sel kolom hanya berisi satu nilai dan setiap kolom memiliki nama yang unik.

Bentuk Normal Kedua (2NF)

Menghilangkan ketergantungan parsial dengan memastikan bahwa atribut non-kunci hanya bergantung pada kunci utama. Artinya, pada dasarnya, harus ada hubungan langsung antara setiap kolom dan kunci utama, dan bukan antara kolom lainnya.

Bentuk Normal Ketiga (3NF)

Menghilangkan ketergantungan transitif dengan memastikan bahwa atribut non-kunci hanya bergantung pada kunci utama. Tingkat normalisasi ini dibangun di atas 2NF.

Bentuk Normal Boyce-Codd (BCNF)

Ini adalah versi 3NF yang lebih ketat yang membahas anomali tambahan. Pada tingkat normalisasi ini, setiap determinan adalah kunci kandidat.

Bentuk Normal Keempat (4NF)

Ini adalah tingkat normalisasi yang dibangun pada BCNF dengan menangani dependensi multi-nilai.

Bentuk Normal Kelima (5NF)

5NF adalah level normalisasi tertinggi yang menangani ketergantungan gabungan. Level ini digunakan dalam skenario tertentu untuk lebih meminimalkan redundansi dengan memecah tabel menjadi tabel-tabel yang lebih kecil.

Normalisasi Basis Data dengan Contoh Dunia Nyata

Kami telah menyoroti semua level normalisasi data. Mari kita bahas masing-masing secara lebih mendalam dengan contoh dan penjelasan.

Bentuk Normal Pertama (1NF) Normalisasi

1NF memastikan bahwa setiap sel kolom hanya berisi nilai atomik. Bayangkan sebuah basis data perpustakaan dengan tabel yang menyimpan informasi buku (judul, penulis, genre, dan borrowed_by). Jika tabel tidak dinormalisasi, borrowed_by dapat berisi daftar nama peminjam yang dipisahkan dengan koma. Ini melanggar 1NF, karena satu sel berisi beberapa nilai. Tabel di bawah ini merupakan representasi yang baik dari tabel yang melanggar 1NF, seperti yang dijelaskan sebelumnya.

Solusinya?

Dalam 1NF, kami membuat tabel terpisah untuk peminjam dan menautkannya ke tabel buku. Tabel-tabel ini dapat ditautkan menggunakan kunci asing di tabel peminjam atau tabel penghubung terpisah. Pendekatan kunci asing dalam tabel peminjam melibatkan penambahan kolom kunci asing ke tabel peminjam yang merujuk ke kunci utama tabel buku. Ini akan menegakkan hubungan antara tabel, memastikan konsistensi data.

Anda dapat menemukan representasinya di bawah ini:

Meja buku

Tabel peminjam

Bentuk Normal Kedua (2NF)

Tingkat normalisasi ini, sebagaimana telah dijelaskan, dibangun di atas 1NF dengan memastikan tidak ada ketergantungan parsial pada kunci utama. Dalam istilah yang lebih sederhana, semua atribut yang bukan kunci harus bergantung pada seluruh kunci utama dan bukan hanya sebagian saja.

Dari 1NF yang diimplementasikan, kita sudah memiliki dua tabel terpisah (Anda dapat memeriksa bagian 1NF).

Sekarang, katakanlah kita ingin menautkan tabel-tabel ini untuk mencatat peminjaman. Pendekatan awal mungkin cukup dengan menambahkan kolom borrower_id ke tabel books , seperti yang ditunjukkan di bawah ini:

Ini mungkin tampak seperti solusi, tetapi melanggar 2NF karena id_peminjam hanya bergantung sebagian pada id_buku. Sebuah buku dapat memiliki beberapa peminjam, tetapi satu id_peminjam hanya dapat ditautkan ke satu buku dalam struktur ini. Ini menciptakan ketergantungan sebagian.

Solusinya?

Kita perlu mencapai hubungan many-to-many antara buku dan peminjam untuk mencapai 2NF. Hal ini dapat dilakukan dengan memperkenalkan tabel terpisah:

Tabel peminjaman buku

Tabel ini menetapkan hubungan yang jelas antara buku dan peminjam. book_id dan borrower_id bertindak sebagai kunci asing, yang merujuk ke kunci utama dalam tabel masing-masing. Pendekatan ini memastikan bahwa borrower_id bergantung pada seluruh kunci utama (book_id) dari tabel books, yang mematuhi 2NF.

Bentuk Normal Ketiga (3NF)

3NF dibangun di atas 2NF dengan menghilangkan ketergantungan transitif. Ketergantungan transitif terjadi ketika atribut non-kunci bergantung pada atribut non-kunci lainnya, yang pada gilirannya bergantung pada kunci utama. Pada dasarnya, maknanya diambil dari hukum transitif.

Dari 2NF yang sudah kita terapkan, ada tiga tabel di database perpustakaan kita:

Meja buku

Tabel peminjam

Tabel peminjaman buku

Struktur 2NF terlihat efisien, tetapi mungkin ada ketergantungan tersembunyi. Bayangkan kita menambahkan kolom due_date ke tabel buku. Ini mungkin tampak logis pada pandangan pertama, tetapi ini akan menciptakan 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) pada tabel books.

Implikasinya adalah bahwa due_date bergantung pada atribut non-kunci perantara (borrowing_id) dan bukan bergantung langsung pada kunci utama (book_id). Hal ini melanggar 3NF.

Solusinya?

Kita dapat memindahkan kolom due_date ke tabel yang paling sesuai dengan memperbarui tabel book_borrowings agar menyertakan kolom due_date dan returning_date.

Berikut adalah tabel yang diperbarui:

Dengan menempatkan kolom due_date dalam tabel book_borrowing, kita telah berhasil menghilangkan ketergantungan transitif.

Artinya, due_date sekarang bergantung langsung pada hubungan gabungan antara book_id dan borrower_id. Dalam konteks ini, book_id dan borrower_id bertindak sebagai kunci asing gabungan, yang bersama-sama membentuk kunci utama tabel book_borrowings.

Bentuk Normal Boyce-Codd (BCNF)

BCNF didasarkan pada dependensi fungsional yang mempertimbangkan semua kunci kandidat dalam suatu hubungan.

Ketergantungan fungsional (FD) mendefinisikan hubungan antara atribut dalam basis data 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 dengan tepat di seluruh tabel.

BCNF adalah versi 3NF yang lebih ketat. BCNF memastikan bahwa setiap determinan (seperangkat atribut yang mengidentifikasi baris secara unik) dalam tabel adalah kunci kandidat (seperangkat atribut minimal yang mengidentifikasi baris secara unik). Inti dari BCNF adalah bahwa semua determinan harus dapat berfungsi sebagai kunci utama.

Ini memastikan bahwa setiap ketergantungan fungsional (FD) memiliki superkey sebagai penentunya. Dengan kata lain, jika X —> Y (X menentukan Y) berlaku, X harus menjadi kunci kandidat (superkey) dari relasi tersebut. Harap perhatikan bahwa X dan Y adalah kolom dalam tabel data.

Sebagai pengembangan dari 3NF, kami memiliki tiga tabel:

Meja buku

Tabel peminjam

Tabel peminjaman buku

Meskipun struktur 3NF sudah bagus, mungkin ada determinan tersembunyi dalam tabel book_borrowings. Dengan asumsi satu peminjam tidak dapat meminjam buku yang sama dua kali secara bersamaan, kombinasi book_id dan borrower_id bersama-sama mengidentifikasi catatan peminjaman secara unik.

Struktur ini melanggar BCNF karena kumpulan gabungan (book_id dan borrower_id) bukan kunci utama tabel (yang hanya borrowing_id).

Solusinya?

Untuk mencapai BCNF, kita dapat menguraikan tabel book_borrowings menjadi dua tabel terpisah atau menjadikan set atribut gabungan sebagai kunci utama.

1. Pendekatan 1 (menguraikan tabel): Dalam pendekatan ini, kita akan menguraikan tabel book_borrowings ke dalam tabel-tabel terpisah:

• • Tabel dengan borrowing_id sebagai kunci utama, borrowed_date, due_date, dan returns_date.
  • Tabel terpisah lainnya untuk menghubungkan buku dan peminjam, dengan book_id sebagai kunci asing, borrower_id sebagai kunci asing, dan kemungkinan atribut tambahan yang khusus untuk peristiwa peminjaman.

2. Pendekatan 2 (jadikan kumpulan atribut gabungan sebagai kunci utama): Kita dapat mempertimbangkan untuk menjadikan book_id dan borrower_id sebagai kunci utama gabungan untuk mengidentifikasi catatan peminjaman secara unik. Masalah dengan pendekatan ini adalah pendekatan ini tidak akan berfungsi jika peminjam dapat meminjam buku yang sama beberapa kali.

Pada akhirnya, pilihan Anda di antara opsi-opsi ini bergantung pada kebutuhan data spesifik Anda dan bagaimana Anda ingin memodelkan hubungan peminjaman.