ACC: Database normalisasi dasar-dasar

Terjemahan Artikel Terjemahan Artikel
ID Artikel: 100139 - Melihat produk di mana artikel ini berlaku.
Pemula: Memerlukan pengetahuan tentang antarmuka pengguna pada komputer pengguna tunggal.

Perbesar semua | Perkecil semua

Pada Halaman ini

RINGKASAN

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:
http://support.Microsoft.com/servicedesks/WebCasts/wc060600/wc060600.asp?fr=1
CATATAN: Untuk melihat informasi ini untuk Microsoft Access 2000, silakan lihat artikel berikut pada Basis Pengetahuan Microsoft:
209534 ACC2000: Database normalisasi dasar-dasar

INFORMASI LEBIH LANJUT

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.
               **********************************
                 Examples of Normalized Tables
               **********************************

 Normalization Examples:

 Unnormalized table:

    Student#   Advisor   Adv-Room  Class1   Class2   Class3
    -------------------------------------------------------
    1022       Jones      412      101-07   143-01   159-02
    4123       Smith      216      201-01   211-02   214-01
				
  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
    					

REFERENSI

Untuk informasi tambahan tentang merancang database, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:
234208 ACC2000: "Pemahaman desain Database relasional" dokumen tersedia di Pusat Download
"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

Properti

ID Artikel: 100139 - Kajian Terakhir: 14 September 2011 - Revisi: 2.0
Berlaku bagi:
  • Microsoft Access 1.0 Standard Edition
  • Microsoft Access 1.1 Standard Edition
  • Microsoft Access 2.0 Standard Edition
  • Microsoft Access 97 Standard Edition
Kata kunci: 
kbinfo kbusage kbmt KB100139 KbMtid
Penerjemahan Mesin
PENTING: Artikel ini diterjemahkan menggunakan perangkat lunak mesin penerjemah Microsoft dan bukan oleh seorang penerjemah. Microsoft menawarkan artikel yang diterjemahkan oleh seorang penerjemah maupun artikel yang diterjemahkan menggunakan mesin sehingga Anda akan memiliki akses ke seluruh artikel baru yang diterbitkan di Pangkalan Pengetahuan (Knowledge Base) dalam bahasa yang Anda gunakan. Namun, artikel yang diterjemahkan menggunakan mesin tidak selalu sempurna. Artikel tersebut mungkin memiliki kesalahan kosa kata, sintaksis, atau tata bahasa, hampir sama seperti orang asing yang berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab terhadap akurasi, kesalahan atau kerusakan yang disebabkan karena kesalahan penerjemahan konten atau penggunaannya oleh para pelanggan. Microsoft juga sering memperbarui perangkat lunak mesin penerjemah.
Klik disini untuk melihat versi Inggris dari artikel ini:100139
Sanggahan Konten KB yang Tidak Lagi Diperbarui
Artikel ini berisi tentang produk yang tidak lagi didukung oleh Microsoft. Oleh karena itu, artikel ini disajikan ?sebagaimana adanya? dan tidak akan diperbarui.

Berikan Masukan

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com