ACC: Database normalisasi dasar-dasar

Artikel ini menjelaskan dasar-dasar terminologi normalisasi database. A pemahaman dasar terminologi ini sangat membantu ketika mendiskusikan desain database relasional.

CATATAN: Microsoft juga menawarkan sebuah WebCast yang membahas dasar-dasar normalisasi database. Untuk melihat WebCast ini, kunjungi Web site Microsoft berikut:CATATAN: Untuk melihat informasi ini untuk Microsoft Access 2000, silakan lihat artikel berikut pada Basis Pengetahuan Microsoft:

Deskripsi normalisasi

Normalisasi adalah proses pengorganisasian data dalam database. Ini termasuk menciptakan tabel dan menjalin hubungan antara orang-orang Tabel menurut aturan dirancang baik untuk melindungi data dan membuat database yang lebih fleksibel dengan menghilangkan dua faktor: redundansi dan dependensi tidak konsisten.

Data berlebihan boros ruang disk dan menciptakan masalah pemeliharaan. Jika data yang ada di lebih dari satu tempat harus berubah, data harus berubah dalam cara yang sama di semua lokasi. Pelanggan perubahan alamat jauh lebih mudah untuk menerapkan jika data yang disimpan hanya dalam tabel pelanggan dan tempat lain di dalam database.

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

Ada beberapa aturan untuk database normalisasi. Setiap aturan yang disebut "bentuk normal." Jika aturan pertama diamati, database berkata dalam "bentuk normal yang pertama". Jika aturan pertama tiga diamati, database dianggap berada di "ketiga bentuk normal." Meskipun lain tingkat normalisasi mungkin, ketiga bentuk normal dianggap tingkat tertinggi untuk sebagian besar aplikasi.

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

CATATAN: Deskripsi berikut termasuk contoh.

Bentuk Normal pertama

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

Tidak menggunakan beberapa bidang dalam sebuah tabel tunggal untuk menyimpan data yang sama. Sebagai contoh, untuk melacak persediaan barang yang mungkin datang dari dua mungkin sumber, catatan persediaan yang mungkin berisi bidang untuk Vendor Kode 1 dan Vendor kode 2.

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

Bentuk Normal kedua

• Membuat tabel terpisah untuk set nilai yang berlaku ke beberapa Catatan.
• Tabel ini berhubungan dengan kunci asing.

Catatan seharusnya tidak bergantung pada apa pun selain meja primary key (senyawa kunci, jika diperlukan). Sebagai contoh, pertimbangkan pelanggan alamat di sistem akuntansi. Alamat yang diperlukan oleh Tabel pelanggan, tetapi juga oleh account pesanan, pengiriman, faktur, Piutang, dan koleksi tabel. Alih-alih menyimpan pelanggan alamat sebagai entri terpisah dalam masing-masing tabel, menyimpannya dalam satu tempat, baik dalam tabel pelanggan atau di meja alamat terpisah.

Ketiga bentuk Normal

• 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 kali isi sekelompok bidang mungkin berlaku untuk lebih dari satu catatan data dalam tabel, mempertimbangkan menempatkan bidang didalam table yang terpisah.

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

PENGECUALIAN: Mengikuti ketiga bentuk yang biasa, sementara secara teoritis diinginkan, 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, penjualan perwakilan, pelanggan kelas, dan faktor lain yang mungkin digandakan dalam beberapa catatan. Secara teori, normalisasi adalah pantas mengejar; Namun, banyak meja kecil dapat menurunkan kinerja atau melebihi kapasitas file dan memori yang terbuka.

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

Bentuk normalisasi

Bentuk normal keempat, juga disebut Boyce Codd Normal bentuk (BCNF), dan bentuk normal kelima ada, tapi jarang dianggap sebagai praktis desain. Mengabaikan aturan-aturan ini mungkin mengakibatkan kurang dari sempurna database desain, tetapi seharusnya tidak akan mempengaruhi fungsi.

1. Bentuk Normal pertama: Tidak mengulangi kelompok
   
   Meja seharusnya hanya dua dimensi. Sejak satu siswa memiliki beberapa kelas, kelas-kelas ini harus tercantum dalam terpisah tabel. Bidang Class1, Class2, & Class3 dalam catatan di atas adalah indikasi masalah desain.
   
   Spreadsheet sering menggunakan dimensi ketiga, tetapi tidak boleh tabel. Cara lain untuk melihat masalah ini: dengan satu-ke-banyak hubungan, tidak menaruh satu sisi dan sisi banyak yang sama tabel. Sebaliknya, membuat meja lain dalam bentuk normal pertama oleh menghilangkan kelompok berulang (kelas #), seperti yang ditunjukkan di bawah ini:

          Student#   Advisor   Adv-Room    Class#
          ---------------------------------------
          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
   					

2. Bentuk Normal kedua: Menghilangkan BERLEBIHAN DATA
   
   Perhatikan beberapa kelas # nilai untuk setiap siswa # nilai dalam di atas meja. Kelas # bukanlah fungsional tergantung pada siswa # (primary key), sehingga hubungan ini tidak dalam bentuk normal yang kedua.
   
   Dua tabel berikut menunjukkan bentuk normal kedua:

       Students:   Student#    Advisor   Adv-Room
                   ------------------------------
                   1022        Jones       412
                   4123        Smith       216
   
       Registration:   Student#    Class#
                       ------------------
                       1022        101-07
                       1022        143-01
                       1022        159-02
                       4123        201-01
                       4123        211-02
                       4123        214-01
   					

3. Ketiga bentuk Normal: Menghilangkan DATA tidak tergantung pada kunci
   
   Dalam terakhir contoh, Adv kamar (nomor kantor penasihat) adalah fungsional bergantung pada atribut penasihat. Solusinya adalah untuk bergerak bahwa atribut dari siswa meja ke meja fakultas, seperti yang ditunjukkan di bawah ini:

       Students:   Student#    Advisor
                   -------------------
                   1022        Jones
                   4123        Smith
   
       Faculty:    Name    Room    Dept
                   --------------------
                   Jones   412     42
                   Smith   216     42
   					

Untuk informasi tambahan tentang merancang database, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:"FoxPro 2 A Developer's Guide," Hamilton M. Ahlo Jr. et al., halaman 220-225, M & T buku, 1991

"Menggunakan akses untuk Windows," Roger Jennings, halaman 799-800, Que Corporation, 1993