ACC: ขั้นพื้นฐานของ Normalization ฐานข้อมูล

การแปลบทความ การแปลบทความ
หมายเลขบทความ (Article ID): 100139 - ผลิตภัณฑ์ที่เกี่ยวข้องในบทความนี้
ฝึกหัด: ต้องทราบของอินเทอร์เฟซสำหรับผู้ใช้บนคอมพิวเตอร์เครื่องเดียวที่ผู้ใช้

ขยายทั้งหมด | ยุบทั้งหมด

เนื้อหาบนหน้านี้

สรุป

บทความนี้อธิบายถึงขั้นพื้นฐานของคำศัพท์เฉพาะทาง normalization ฐานข้อมูล ความเข้าใจเกี่ยวกับคำศัพท์นี้พื้นฐานจะเป็นประโยชน์เมื่อ discussing การออกแบบของฐานข้อมูลที่เกี่ยว

หมายเหตุ:: Microsoft ยังมีเว็บคาสต์ที่กล่าวถึงขั้นพื้นฐานของ normalization ฐานข้อมูล เมื่อต้องการดูเว็บคาสต์นี้ โปรดเยี่ยมชมเว็บไซต์ต่อไปนี้ของ Microsoft:
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1
หมายเหตุ:: เมื่อต้องการดูรายละเอียดนี้สำหรับ Microsoft Access 2000 โปรดดูบทความในฐานความรู้ของ Microsoft ต่อไปนี้:
209534ACC2000: ขั้นพื้นฐานของ Normalization ฐานข้อมูล

ข้อมูลเพิ่มเติม

คำอธิบายของ Normalization

normalization คือ กระบวนการจัดระเบียบข้อมูลในฐานข้อมูล ซึ่งรวมถึงการสร้างตาราง และการกำหนดความสัมพันธ์ระหว่างตารางต่าง ๆ ตามกฎที่มีการออกแบบมา เพื่อป้องกันข้อมูล และ เพื่อทำให้ฐานข้อมูลความยืดหยุ่นมากขึ้น โดยการกำจัดปัจจัยสองทั้งการ: สำรองและการอ้างอิงที่ไม่สอดคล้องกัน

ข้อมูลที่ซ้ำซ้อน wastes เนื้อที่ว่างบนดิสก์ และสร้างปัญหาในการบำรุงรักษา ถ้าต้องถูกเปลี่ยนแปลงข้อมูลที่มีอยู่ในสถานที่หนึ่ง ข้อมูลต้องเปลี่ยนในแน่นอนแบบเดียวกันในตำแหน่งที่ตั้งทั้งหมด การเปลี่ยนแปลงที่อยู่ของลูกค้าจะง่ายกว่ามากจะใช้ถ้าข้อมูลที่เก็บอยู่ในตารางลูกค้าและ nowhere อื่นในฐานข้อมูลเท่านั้น

ขึ้นต่อเป็น "ไม่สอดคล้องกัน" คืออะไร ขณะที่อยู่ intuitive สำหรับผู้ใช้ในการค้นหาในตารางลูกค้าสำหรับอยู่ของลูกค้าเฉพาะราย ดังกล่าวอาจไม่ทำควรมีหาเงินเดือนของพนักงานที่เรียกบนลูกค้าเท่านั้น เงินเดือนของพนักงานที่เกี่ยวข้อง กับ หรือขึ้น พนักงาน และซึ่ง ควรจะย้ายไปยังตารางพนักงาน การอ้างอิงที่ไม่สอดคล้องกันสามารถทำข้อมูลยากต่อการเข้าถึง เส้นทางการค้นหาข้อมูลอาจหายไป หรือใช้งานไม่ได้

กฎบางอย่างสำหรับ normalization ฐานข้อมูลได้ แต่ละกฎจะเรียกว่า "ปกติฟอร์ม ถ้ามีการตรวจสอบกฎแรก ฐานข้อมูล said อยู่ใน "แรกปกติฟอร์ม ถ้ามีการตรวจสอบกฎที่สามเป็นอันดับแรก ฐานข้อมูลจะถือเป็นใน "สามปกติฟอร์ม แม้ว่า normalization ระดับอื่น ๆ จะเป็นไปได้ ฟอร์มปกติที่สามจะถือเป็นระดับสูงสุดจำเป็นสำหรับโปรแกรมประยุกต์ที่มากที่สุด

ตามที่ มีหลายอย่างเป็นทางกฎและข้อกำหนด สถานการณ์โลกจริงไม่อนุญาตสำหรับความสอดคล้องที่สมบูรณ์แบบ โดยทั่วไป normalization ต้องตารางเพิ่มเติมของคุณ และลูกค้าบางพบนี้ cumbersome ถ้าคุณตัดสินใจ violate กฎที่สามเป็นอันดับแรกของ normalization อย่างใดอย่างหนึ่ง การตรวจสอบให้แน่ใจว่า โปรแกรมประยุกต์ของคุณ anticipates ปัญหาที่อาจเกิด เช่นข้อมูลที่ซ้ำซ้อนและการอ้างอิงที่ไม่สอดคล้องกัน

หมายเหตุ:: คำอธิบายต่อไปนี้การรวมตัวอย่าง

ฟอร์มปกติแรก

  • การตัดออกกลุ่มที่มีการทำซ้ำในแต่ละตาราง
  • สร้างตารางที่แยกต่างหากสำหรับแต่ละชุดของข้อมูลที่เกี่ยวข้อง
  • ระบุแต่ละชุดของข้อมูลที่เกี่ยวข้องกับคีย์หลัก
อย่าใช้หลายฟิลด์ในตารางเดียวในการเก็บข้อมูลที่คล้ายกัน ตัวอย่างเช่น การติดตามสินค้าในสต็อกที่อาจมาจากแหล่งที่เป็นไปได้สอง เรกคอร์ดในสินค้าคงคลังอาจประกอบด้วยเขตข้อมูลสำหรับผู้ขายรหัส 1 และ 2 รหัสของผู้ขาย

แต่เกิดอะไรขึ้นเมื่อคุณเพิ่มผู้จัดจำหน่ายที่สาม การเพิ่มเขตข้อมูลไม่มีคำตอบ ต้องการแก้ไขโปรแกรมและตาราง และให้เหมาะสมไม่อย่างกับหมายเลขแบบไดนามิกของผู้จัดจำหน่าย แทน วางข้อมูลผู้จัดจำหน่ายทั้งหมดในตารางที่แยกต่างหากที่เรียกว่าผู้ขาย จากสินค้าคงคลังในการเชื่อมโยงกับผู้จัดจำหน่าย ด้วยคีย์การหมายเลขสินค้า หรือผู้จัดจำหน่ายไปยังสินค้าคงคลัง โดยใช้คีย์การโค้ดผู้จัดจำหน่าย

ฟอร์มปกติที่สอง

  • สร้างตารางที่แยกต่างหากสำหรับชุดของค่าที่นำไปใช้กับหลายระเบียน
  • การเชื่อมโยงกับตารางเหล่านี้ โดยใช้คีย์ที่ต่างประเทศ
เร็กคอร์ดที่ไม่ควรขึ้นกับบนสิ่งอื่นที่ไม่ใช่คีย์หลักของตาราง (ประกอบแป้น ถ้าจำเป็น) ให้พิจารณาตัวอย่างเช่น ที่อยู่ของลูกค้าในระบบการลงบัญชี ที่อยู่ถูกต้อง ตามตารางลูกค้า แต่ยัง ตามตารางใบสั่ง จัดส่ง ใบส่งของ บัญชีลูกหนี้ และคอลเลกชัน แทนการจัดเก็บอยู่ของลูกค้าเป็นรายการแยกต่างหากในแต่ละตารางเหล่านี้ เก็บในเดียว ในตารางลูกค้าหรือ ในตารางที่อยู่ที่แยกต่างหาก

ฟอร์มปกติที่สาม

  • การตัดออกเขตข้อมูลที่ไม่ขึ้นคีย์
Values in a record that are not part of that record's key do not belong in the table. In general, any time the contents of a group of fields may apply to more than a single record in the table, consider placing those fields in a separate table.

For example, in an Employee Recruitment table, a candidate's university name and address may be included. But you need a complete list of universities for group mailings. If university information is stored in the Candidates table, there is no way to list universities with no current candidates. Create a separate Universities table and link it to the Candidates table with a university code key.

EXCEPTION: Adhering to the third normal form, while theoretically desirable, is not always practical. If you have a Customers table and you want to eliminate all possible interfield dependencies, you must create separate tables for cities, ZIP codes, sales representatives, customer classes, and any other factor that may be duplicated in multiple records. In theory, normalization is worth pursuing; however, many small tables may degrade performance or exceed open file and memory capacities.

It may be more feasible to apply third normal form only to data that changes frequently. If some dependent fields remain, design your application to require the user to verify all related fields when any one is changed.

Other Normalization Forms

Fourth normal form, also called Boyce Codd Normal Form (BCNF), and fifth normal form do exist, but are rarely considered in practical design. Disregarding these rules may result in less than perfect database design, but should not affect functionality.
               **********************************
                 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. First Normal Form: NO REPEATING GROUPS

    Tables should have only two dimensions. Since one student has several classes, these classes should be listed in a separate table. Fields Class1, Class2, & Class3 in the above record are indications of design trouble.

    Spreadsheets often use the third dimension, but tables should not. Another way to look at this problem: with a one-to-many relationship, do not put the one side and the many side in the same table. Instead, create another table in first normal form by eliminating the repeating group (Class#), as shown below:
           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. Second Normal Form: ELIMINATE REDUNDANT DATA

    Note the multiple Class# values for each Student# value in the above table. Class# is not functionally dependent on Student# (primary key), so this relationship is not in second normal form.

    The following two tables demonstrate second normal form:
        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. Third Normal Form: ELIMINATE DATA NOT DEPENDENT ON KEY

    In the last example, Adv-Room (the advisor's office number) is functionally dependent on the Advisor attribute. The solution is to move that attribute from the Students table to the Faculty table, as shown below:
        Students:   Student#    Advisor
                    -------------------
                    1022        Jones
                    4123        Smith
    
        Faculty:    Name    Room    Dept
                    --------------------
                    Jones   412     42
                    Smith   216     42
    					

ข้อมูลอ้างอิง

For additional information about designing a database, click the article number below to view the article in the Microsoft Knowledge Base:
234208ACC2000: "Understanding Relational Database Design" Document Available in Download Center
"FoxPro 2 A Developer's Guide," Hamilton M. Ahlo Jr. et al., pages 220-225, M & T Books, 1991

"Using Access for Windows," Roger Jennings, pages 799-800, Que Corporation, 1993

คุณสมบัติ

หมายเลขบทความ (Article ID): 100139 - รีวิวครั้งสุดท้าย: 6 มกราคม 2554 - Revision: 2.0
ใช้กับ
  • Microsoft Access 1.0 Standard Edition
  • Microsoft Access 1.1 Standard Edition
  • Microsoft Access 2.0 Standard Edition
  • Microsoft Access 97 Standard Edition
Keywords: 
kbinfo kbusage kbmt KB100139 KbMtth
แปลโดยคอมพิวเตอร์
ข้อมูลสำคัญ: บทความนี้แปลโดยซอฟต์แวร์การแปลด้วยคอมพิวเตอร์ของ Microsoft แทนที่จะเป็นนักแปลที่เป็นบุคคล Microsoft มีบทความที่แปลโดยนักแปลและบทความที่แปลด้วยคอมพิวเตอร์ เพื่อให้คุณสามารถเข้าถึงบทความทั้งหมดในฐานความรู้ของเรา ในภาษาของคุณเอง อย่างไรก็ตาม บทความที่แปลด้วยคอมพิวเตอร์นั้นอาจมีข้อบกพร่อง โดยอาจมีข้อผิดพลาดในคำศัพท์ รูปแบบการใช้ภาษาและไวยากรณ์ เช่นเดียวกับกรณีที่ชาวต่างชาติพูดผิดเมื่อพูดภาษาของคุณ Microsoft ไม่มีส่วนรับผิดชอบต่อความคลาดเคลื่อน ความผิดพลาดหรือความเสียหายที่เกิดจากการแปลเนื้อหาผิดพลาด หรือการใช้บทแปลของลูกค้า และ Microsoft มีการปรับปรุงซอฟต์แวร์การแปลด้วยคอมพิวเตอร์อยู่เป็นประจำ
ต่อไปนี้เป็นฉบับภาษาอังกฤษของบทความนี้:100139
การปฏิเสธความรับผิดชอบในเนื้อหาของ KB ที่จะไม่มีการปรับปรุงอีกต่อไป
บทความนี้กล่าวถึงผลิตภัณฑ์ที่ Microsoft ไม่มีการสนับสนุนอีกต่อไป เนื้อหาของบทความจึงมีการนำเสนอ "ตามลักษณะที่เป็น" และจะไม่มีการปรับปรุงข้อมูลอีก

ให้ข้อเสนอแนะ

 

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