Deskripsi dari dasar-dasar normalisasi database pada Access 2000

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

Untuk versi Microsoft Access 97 artikel ini, Lihat 100139.
Untuk Microsoft Access 2002 versi dari artikel ini, lihat 283878.
Perbesar semua | Perkecil semua

Pada Halaman ini

RINGKASAN

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:
http://support.Microsoft.com/servicedesks/WebCasts/wc060600/wc060600.asp?fr=1
Untuk informasi tambahan tentang topik ini di versi sebelumnya akses, klik artikel berikut nomor ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:
100139Dasar-dasar normalisasi database

INFORMASI LEBIH LANJUT

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 #PenasihatADV-kamarClass1Class2Class3
    1022Jones412101-07143-01159-02
    4123Smith216201-01211-02214-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 #PenasihatADV-kamarKelas #
    1022Jones412101-07
    1022Jones412143-01
    1022Jones412159-02
    4123Smith216201-01
    4123Smith216211-02
    4123Smith216214-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 #PenasihatADV-kamar
    1022Jones412
    4123Smith216

    Pendaftaran

    Perkecil tabel iniPerbesar tabel ini
    Siswa #Kelas #
    1022101-07
    1022143-01
    1022159-02
    4123201-01
    4123211-02
    4123214-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
    1022Jones
    4123Smith

    Fakultas

    Perkecil tabel iniPerbesar tabel ini
    NamaKamarDept
    Jones41242
    Smith21642

REFERENSI

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 for other considerations.

Properti

ID Artikel: 209534 - Kajian Terakhir: 19 September 2011 - Revisi: 2.0
Berlaku bagi:
  • Microsoft Access 2000 Standard Edition
Kata kunci: 
kbdatabase kbdesign kbinfo kbusage kbmt KB209534 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:209534

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