Deskripsi Normalisasi

Normalisasi adalah proses pengorganisasian data dalam database. Ini termasuk menciptakan tabel dan menjalin hubungan antara tabel tersebut menurut aturan yang dirancang untuk melindungi data dan membuat database yang lebih fleksibel dengan menghilangkan redundansi dan ketergantungan yang tidak konsisten. 

Data berlebihan limbah ruang disk dan menciptakan masalah pemeliharaan. Jika data yang ada di lebih dari satu tempat yang harus berubah, data harus diubah dalam cara yang sama di semua lokasi. Perubahan alamat pelanggan jauh lebih mudah untuk menerapkan jika data tersebut tersimpan di tabel pelanggan dan tempat lain dalam database. 

Apa itu "tidak konsisten ketergantungan"? Meskipun sangat intuitif bagi pengguna untuk melihat dalam tabel pelanggan untuk alamat pelanggan tertentu, itu mungkin tidak masuk akal untuk melihat di sana untuk gaji karyawan yang panggilan pada pelanggan. Gaji karyawan berhubungan, atau tergantung pada, karyawan dan dengan demikian harus pindah ke tabel karyawan. Dependensi tidak konsisten dapat membuat data sulit untuk akses karena jalan untuk menemukan data mungkin hilang atau rusak. 

Ada beberapa aturan untuk database normalisasi. Setiap aturan disebut "bentuk normal." Jika aturan pertama diamati, database dikatakan dalam "pertama bentuk normal." Jika aturan pertama tiga diamati, database dianggap dalam "ketiga bentuk normal." Meskipun tingkat-tingkat normalisasi mungkin, bentuk normal ketiga dianggap diperlukan untuk sebagian besar aplikasi tingkat tertinggi. 

Seperti dengan banyak peraturan formal dan spesifikasi, skenario dunia nyata tidak selalu memungkinkan kepatuhan yang sempurna. Secara umum, normalisasi memerlukan tabel tambahan dan beberapa pelanggan menemukan ini rumit. Jika Anda memutuskan untuk melanggar salah satu aturan pertama tiga normalisasi, memastikan bahwa aplikasi Anda mengantisipasi setiap masalah yang dapat terjadi, seperti data yang berlebihan dan tidak konsisten dependensi. 

Penjelasan berikut termasuk contoh. 

Bentuk Normal pertama

• Menghilangkan berulang kelompok dalam tabel individu.
• Membuat tabel terpisah untuk setiap set data terkait.
• Mengidentifikasi setiap set data yang terkait dengan primary key.

Jangan gunakan beberapa bidang dalam sebuah tabel tunggal untuk menyimpan data yang sama. Misalnya, untuk melacak item persediaan yang mungkin datang dari dua sumber yang mungkin, catatan persediaan yang mungkin berisi bidang untuk Vendor kode 1 dan 2 kode Vendor. 

Apa yang terjadi ketika Anda menambahkan ketiga vendor? Menambahkan sebuah field bukanlah jawaban; ini memerlukan program dan meja modifikasi dan tidak lancar mengakomodasi sejumlah vendor yang dinamis. Sebaliknya, menempatkan semua vendor informasi dalam tabel terpisah yang disebut vendor, maka persediaan link ke vendor dengan item nomor kunci, atau vendor untuk persediaan dengan vendor kode kunci.

Bentuk kedua Normal

• Membuat tabel terpisah untuk set nilai yang berlaku untuk beberapa catatan.
• Berhubungan tabel ini dengan kunci asing.

Catatan tidak harus bergantung pada apa pun selain meja primary key (senyawa kunci, jika perlu). Sebagai contoh, perhatikan alamat pelanggan dalam sistem akuntansi. Alamat diperlukan oleh tabel pelanggan, tetapi juga oleh pesanan, pengiriman, tagihan, piutang, dan koleksi tabel. Daripada menyimpan pelanggan alamat sebagai entri terpisah dalam masing-masing tabel, menyimpannya di satu tempat, dalam tabel pelanggan atau tabel alamat terpisah.

Bentuk Normal ketiga

• Menghilangkan bidang yang tidak bergantung pada kunci.

Nilai-nilai dalam catatan yang bukan merupakan bagian dari catatan bahwa kunci tidak termasuk dalam tabel. Secara umum, setiap saat isi sekelompok bidang mungkin berlaku untuk lebih dari satu catatan data dalam tabel, mempertimbangkan menempatkan bidang tersebut didalam table yang terpisah. 

Sebagai contoh, dalam tabel perekrutan karyawan, calon Universitas nama dan alamat dapat disertakan. Tetapi Anda perlu daftar lengkap Universitas untuk kelompok surat. Jika informasi Universitas disimpan di tabel kandidat, ada cara untuk daftar Universitas dengan tidak ada kandidat yang saat ini. Membuat tabel Universitas terpisah dan link ke tabel kandidat dengan Universitas kode kunci. 

PENGECUALIAN: Mengikuti bentuk ketiga normal, sementara secara teoritis diinginkan, ini tidak selalu praktis. Jika Anda memiliki tabel pelanggan dan Anda ingin menghilangkan semua dependensi interfield mungkin, Anda harus membuat tabel terpisah untuk kota, kode pos, perwakilan penjualan, pelanggan kelas, dan faktor lainnya yang dapat digandakan dalam beberapa catatan. Dalam teori, normalisasi bernilai mengerucutkan. Namun, banyak meja kecil dapat menurunkan kinerja atau melebihi buka file dan kapasitas memori. 

Mungkin lebih layak untuk menerapkan bentuk normal ketiga hanya untuk data yang sering berubah. Jika beberapa bidang tergantung tetap, desain aplikasi Anda untuk meminta pengguna memverifikasi semua bidang terkait ketika salah satu berubah.

Bentuk normalisasi

Keempat bentuk normal, juga disebut Boyce Codd Normal formulir (BCNF), dan bentuk normal kelima ada, tetapi jarang dianggap dalam desain yang praktis. Mengabaikan aturan-aturan ini mungkin mengakibatkan desain database kurang sempurna, tetapi seharusnya tidak mempengaruhi fungsi.

Normalisasi tabel contoh

Langkah-langkah ini menunjukkan proses normalisasi tabel fiktif mahasiswa.

1. Unnormalized tabel: 
   
   
   Siswa #	Penasihat	ADV-Kamar	Class1	Class2	Class3
   1022	Jones	412	101-07	143-01	159-02
   4123	Smith	216	201-01	211-02	214-01

2. Bentuk Normal pertama: Tidak ada mengulangi kelompok
   
   Meja seharusnya hanya dua dimensi. Sejak satu siswa memiliki beberapa kelas, kelas-kelas ini harus tercantum dalam tabel terpisah. Bidang Class1, Class2, dan Class3 dalam catatan di atas adalah indikasi masalah desain. 
   
   Spreadsheet sering menggunakan dimensi ketiga, tetapi tidak boleh tabel. Cara lain untuk melihat masalah ini adalah dengan satu-ke-banyak hubungan, tidak menaruh satu sisi dan sisi yang banyak di meja yang sama. Sebaliknya, membuat meja lain pertama bentuk normal dengan menghilangkan kelompok berulang (kelas #), seperti yang ditunjukkan di bawah ini:
   
   
   Siswa #	Penasihat	ADV-Kamar	Kelas #
   1022	Jones	412	101-07
   1022	Jones	412	143-01
   1022	Jones	412	159-02
   4123	Smith	216	201-01
   4123	Smith	216	211-02
   4123	Smith	216	214-01

3. Bentuk kedua Normal: Menghapuskan berlebihan Data
   
   Perhatikan beberapa kelas # nilai untuk setiap siswa # nilai di atas meja. Kelas # ini tidak fungsional bergantung pada siswa # (primary key), sehingga hubungan ini tidak dalam bentuk kedua normal.
   
   Dua tabel berikut ini menunjukkan bentuk normal kedua: 
   
   Siswa:
   
   
   Siswa #	Penasihat	ADV-Kamar
   1022	Jones	412
   4123	Smith	216

   
   
   Pendaftaran:
   
   
   Siswa #	Kelas #
   1022	101-07
   1022	143-01
   1022	159-02
   4123	201-01
   4123	211-02
   4123	214-01

4. Bentuk Normal ketiga: Menghilangkan Data tidak tergantung pada kunci
   
   Dalam contoh terakhir, Adv-kamar (nomor kantor penasihat) fungsional bergantung pada atribut Advisor. Solusinya adalah untuk bergerak bahwa atribut dari siswa meja ke meja fakultas, seperti yang ditunjukkan di bawah ini:
   
   Siswa:
   
   
   Siswa #	Penasihat
   1022	Jones
   4123	Smith

   
   
   Fakultas:
   
   
   Nama	Kamar	Dept
   Jones	412	42
   Smith	216	42

          Demikian deskripsi Normalisasi yang sederhana semoga bermanfaat y gan ..