Deskripsi dari dasar-dasar normalisasi database pada Access 2000

Artikel ini menjelaskan database normalisasi terminologi untuk pemula. Pemahaman dasar terminologi ini sangat membantu ketika membahas desain database relasional.

CATATAN: Microsoft juga menawarkan sebuah WebCast yang membahas dasar-dasar normalisasi database. Untuk melihat WebCast ini, kunjungi berikut Microsoft Web site: Untuk informasi tambahan tentang topik ini di versi sebelumnya akses, klik artikel berikut nomor ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:

Deskripsi normalisasi

Normalisasi adalah proses pengorganisasian data dalam database. Ini termasuk menciptakan tabel dan menjalin hubungan antara orang-orang tabel sesuai dengan aturan-aturan yang dirancang untuk melindungi data dan membuat database lebih fleksibel dengan menghilangkan redundansi dan ketergantungan yang 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. Perubahan alamat pelanggan lebih mudah untuk menerapkan jika data yang disimpan hanya dalam 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 terkait atau bergantung pada, karyawan dan dengan demikian harus pindah ke tabel karyawan. Dependensi tidak konsisten dapat membuat sulit untuk mengakses karena data path ke menemukan data mungkin hilang atau rusak.

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

Sebagai dengan banyak peraturan resmi dan spesifikasi, skenario dunia nyata melakukan tidak selalu memungkinkan untuk sempurna kepatuhan. Secara umum, normalisasi memerlukan tambahan tabel 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 berlebihan data dan dependensi tidak konsisten.

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 serupa data. 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.

Apa yang terjadi ketika Anda menambahkan vendor ketiga? Menambahkan sebuah field bukan 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 untuk beberapa catatan.
• Tabel ini berhubungan dengan kunci asing.

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

Ketiga bentuk normal

• Menghilangkan bidang yang tidak bergantung pada kunci.

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

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

PENGECUALIAN: Mengikuti ketiga bentuk normal, sementara secara teoritis diinginkan, tidak selalu praktis. Jika Anda memiliki tabel pelanggan dan Anda ingin menghilangkan semua kemungkinan interfield dependensi, Anda harus membuat tabel terpisah untuk kota, kode pos, penjualan perwakilan, 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 file terbuka dan kapasitas memori.

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

Bentuk normalisasi

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

Normalisasi contoh tabel

Langkah ini menunjukkan proses normalisasi fiktif mahasiswa meja.

1. Tabel unnormalized:
   Perkecil tabel iniPerbesar tabel ini

   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 mengulangi kelompok
   
   Tabel harus memiliki hanya dua dimensi. Sejak satu siswa memiliki beberapa kelas, ini kelas harus terdaftar dalam daftar 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 dengan hubungan satu-ke-banyak, tidak menempatkan satu sisi dan sisi banyak di meja yang sama. Sebaliknya, membuat meja lain di normal pertama formulir dengan menghilangkan kelompok berulang (kelas #), seperti yang ditunjukkan di bawah ini:
   Perkecil tabel iniPerbesar tabel 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 Normal kedua: Menghilangkan berlebihan Data
   
   Catatan beberapa kelas # nilai setiap siswa # nilai di atas meja. Kelas # bukanlah fungsional tergantung pada siswa # (primary key), jadi ini hubungan ini tidak dalam bentuk normal yang kedua.
   
   Dua tabel berikut menunjukkan bentuk normal kedua:

   Siswa

   Perkecil tabel iniPerbesar tabel ini

   Siswa #	Penasihat	ADV-kamar
   1022	Jones	412
   4123	Smith	216

   Pendaftaran

   Perkecil tabel iniPerbesar tabel ini

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

4. 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 yang atribut dari siswa meja ke meja fakultas, seperti yang ditunjukkan di bawah ini:

   Siswa

   Perkecil tabel iniPerbesar tabel ini

   Siswa #	Penasihat
   1022	Jones
   4123	Smith

   Fakultas

   Perkecil tabel iniPerbesar tabel ini

   Nama	Kamar	Dept
   Jones	412	42
   Smith	216	42

Ahlo, M. Hamilton, Randy Brown dan Peter Colclough. FoxPro 2: Pengembang panduan: Panduan ahli industri-kekuatan pemrograman. John Wiley & anak-anak, Oktober 1991. Halaman 220-225.

Jennings, Roger. Menggunakan akses 1.1 untuk Windows. Que Corporation, Juli 1993. Halaman 799-800.

Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use (http://go.microsoft.com/fwlink/?LinkId=151500) for other considerations.