การทำให้ฐานข้อมูลเป็นรูปแบบมาตรฐาน (Database normalization)คือกระบวนการจัดโครงสร้างฐานข้อมูลเชิงสัมพันธ์ให้สอดคล้องกับรูปแบบมาตรฐานต่างๆเพื่อลดความซ้ำซ้อนของข้อมูลและปรับปรุงความสมบูรณ์ของข้อมูล กระบวนการ นี้ ได้รับการเสนอครั้งแรกโดยนักวิทยาศาสตร์คอมพิวเตอร์ชาวอังกฤษเอ็ดการ์ เอฟ. คอดด์ในฐานะส่วนหนึ่งของแบบจำลองเชิงสัมพันธ์ ของเขา

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

วัตถุประสงค์พื้นฐานของรูปแบบปกติแรกที่กำหนดโดย Codd ในปี 1970 คือการอนุญาตให้สอบถามและจัดการข้อมูลโดยใช้ "ภาษาย่อยข้อมูลสากล" ที่มีพื้นฐานมาจากตรรกะลำดับที่หนึ่ง^{[ 1 ]}ตัวอย่างของภาษาดังกล่าวคือSQLแม้ว่า Codd จะมองว่า SQL มีข้อบกพร่องร้ายแรงก็ตาม^{[ 2 ]}

Codd ได้ระบุวัตถุประสงค์ของการทำให้เป็นรูปแบบปกติมากกว่า 1NF (รูปแบบปกติแรก) ไว้ดังนี้:

1. เพื่อปลดแอกชุดความสัมพันธ์จากการพึ่งพาการแทรก การอัปเดต และการลบที่ไม่พึงประสงค์
2. เพื่อลดความจำเป็นในการปรับโครงสร้างชุดความสัมพันธ์เมื่อมีการนำข้อมูลประเภทใหม่เข้ามาใช้ และเพื่อยืดอายุการใช้งานของโปรแกรมแอปพลิเคชันให้ยาวนานขึ้น
3. เพื่อทำให้แบบจำลองเชิงสัมพันธ์นั้นให้ข้อมูลที่เป็นประโยชน์ต่อผู้ใช้มากขึ้น
4. เพื่อให้การรวบรวมความสัมพันธ์เป็นกลางต่อสถิติการค้นหา ซึ่งสถิติเหล่านี้อาจเปลี่ยนแปลงไปตามกาลเวลา

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

ความผิดปกติในการแทรก

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

อัปเดตความผิดปกติ

ข้อมูลเดียวกันสามารถแสดงได้ในหลายแถว ดังนั้นการอัปเดตความสัมพันธ์อาจส่งผลให้เกิดความไม่สอดคล้องกันทางตรรกะ ตัวอย่างเช่น แต่ละระเบียนในความสัมพันธ์ "ทักษะของพนักงาน" อาจประกอบด้วยรหัสพนักงาน ที่อยู่พนักงาน และทักษะ ดังนั้นการเปลี่ยนแปลงที่อยู่ของพนักงานคนใดคนหนึ่งอาจต้องนำไปใช้กับหลายระเบียน (หนึ่งระเบียนสำหรับแต่ละทักษะ) หากการอัปเดตสำเร็จเพียงบางส่วน – ที่อยู่ของพนักงานได้รับการอัปเดตในบางระเบียน แต่ไม่ใช่ทุกระเบียน – ความสัมพันธ์ก็จะอยู่ในสถานะที่ไม่สอดคล้องกัน โดยเฉพาะอย่างยิ่ง ความสัมพันธ์จะให้คำตอบที่ขัดแย้งกันเกี่ยวกับที่อยู่ของพนักงานคนนี้

ความผิดปกติในการลบ

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

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

ความสัมพันธ์แบบมาตรฐาน และความสัมพันธ์ระหว่างความสัมพันธ์แบบมาตรฐานหนึ่งกับอีกความสัมพันธ์แบบมาตรฐานหนึ่ง สะท้อนให้เห็นถึงแนวคิดในโลกแห่งความเป็นจริงและความสัมพันธ์ระหว่างกัน

Codd ได้นำเสนอแนวคิดเรื่องการทำให้เป็นมาตรฐานและสิ่งที่ปัจจุบันรู้จักกันในชื่อรูปแบบมาตรฐานแรก (1NF) ในปี พ.ศ. 2513 ^{[ 4 ]} Codd ได้กำหนดรูปแบบมาตรฐานที่สอง (2NF) และรูปแบบมาตรฐานที่สาม (3NF) ในปี พ.ศ. 2514 ^{[ 5 ]}และ Codd กับRaymond F. Boyceได้กำหนดรูปแบบมาตรฐาน Boyce–Codd (BCNF) ในปี พ.ศ. 2517 ^{[ 6 ]}

โรนัลด์ เฟกินได้นำเสนอรูปแบบปกติที่สี่ (4NF) ในปี 1977 และรูปแบบปกติที่ห้า (5NF) ในปี 1979 ส่วนคริสโตเฟอร์ เจ. เดทได้นำเสนอรูปแบบปกติที่หก (6NF) ในปี 2003

โดยทั่วไปแล้ว ความสัมพันธ์ของฐานข้อมูลเชิงสัมพันธ์มักถูกอธิบายว่า "เป็นปกติ" หากตรงตามมาตรฐานรูปแบบปกติที่สาม^{[ 7 ]}ความสัมพันธ์ 3NF ส่วนใหญ่ไม่มีความผิดปกติในการแทรก การอัปเดต และการลบ

รูปแบบมาตรฐาน (จากรูปแบบที่เป็นมาตรฐานน้อยที่สุดไปจนถึงรูปแบบที่เป็นมาตรฐานมากที่สุด) มีดังนี้:

ข้อจำกัด(คำอธิบายอย่างไม่เป็นทางการในวงเล็บ)	UNF (1970)	1NF (1970)	2NF (1971)	3NF (1971)	EKNF (1982)	บีซีเอ็นเอฟ(1974)	4NF (1977)	อีทีเอ็นเอฟ(2012)	5NF (1979)	ดีเคเอ็นเอฟ(1981)	6NF (2003)
แถวที่ไม่ซ้ำกัน (ไม่มีระเบียนซ้ำ) [ 4 ]
คอลัมน์สเกลาร์ (คอลัมน์ไม่สามารถมีความสัมพันธ์หรือค่าประกอบได้) [ 5 ]
คุณลักษณะที่ไม่ใช่หลักทุกรายการมีการพึ่งพาเชิงฟังก์ชัน อย่างสมบูรณ์ กับคีย์ผู้สมัคร แต่ละรายการ (คุณลักษณะขึ้นอยู่กับคีย์ทั้งหมด ) [ 5 ]
การพึ่งพาเชิงฟังก์ชันที่ไม่สำคัญทุกรายการจะเริ่มต้นด้วยซูเปอร์คีย์หรือสิ้นสุดด้วยแอตทริบิวต์หลัก (แอตทริบิวต์ขึ้นอยู่กับคีย์ผู้สมัครเท่านั้น ) [ 5 ]
ความสัมพันธ์เชิงฟังก์ชันที่ไม่ธรรมดาทุกความสัมพันธ์จะเริ่มต้นด้วยซูเปอร์คีย์หรือลงท้ายด้วยแอตทริบิวต์ไพรม์พื้นฐาน (รูปแบบที่เข้มงวดกว่าของ 3NF)											—ไม่มีข้อมูล
ความสัมพันธ์เชิงฟังก์ชันที่ไม่ธรรมดาทุกความสัมพันธ์จะเริ่มต้นด้วยซูเปอร์คีย์ (รูปแบบที่เข้มงวดกว่าของ 3NF)											—ไม่มีข้อมูล
ความสัมพันธ์แบบหลายค่าที่ไม่ธรรมดาทุก ความสัมพันธ์ เริ่มต้นด้วยซูเปอร์คีย์											—ไม่มีข้อมูล
การพึ่งพาการเข้าร่วมทุกรายการจะมีส่วนประกอบซูเปอร์คีย์[ 8 ]											—ไม่มีข้อมูล
การเชื่อมต่อแบบพึ่งพาแต่ละรายการจะมีเฉพาะส่วนประกอบซูเปอร์คีย์เท่านั้น											—ไม่มีข้อมูล
ข้อจำกัดทุกข้อล้วนเป็นผลมาจากข้อจำกัดของโดเมนและข้อจำกัดหลัก
ความสัมพันธ์แบบ join dependency ทุกอย่างนั้นไม่สำคัญ

การทำให้เป็นรูปแบบปกติ (Normalization) เป็นเทคนิคการออกแบบฐานข้อมูล ซึ่งใช้ในการออกแบบ ตาราง ฐานข้อมูลเชิงสัมพันธ์จนถึงรูปแบบปกติที่สูงขึ้น^{[ 9 ]}กระบวนการนี้เป็นไปอย่างต่อเนื่อง และจะไม่สามารถบรรลุระดับการทำให้เป็นรูปแบบปกติของฐานข้อมูลที่สูงขึ้นได้ เว้นแต่จะบรรลุระดับก่อนหน้าแล้ว^{[ 10 ]}

นั่นหมายความว่า หากเรามีข้อมูลในรูปแบบที่ไม่เป็นมาตรฐาน (มาตรฐานน้อยที่สุด) และต้องการบรรลุระดับมาตรฐานสูงสุด ขั้นตอนแรกคือการทำให้ข้อมูลเป็นไปตามรูปแบบมาตรฐานที่หนึ่งขั้นตอนที่สองคือการทำให้ข้อมูลเป็นไปตามรูปแบบมาตรฐานที่สองและดำเนินการต่อไปตามลำดับที่กล่าวมาข้างต้น จนกว่าข้อมูลจะเป็นไปตาม รูป แบบ มาตรฐานที่หก

อย่างไรก็ตาม รูปแบบปกติที่เกินกว่า4NFส่วนใหญ่เป็นที่สนใจในเชิงวิชาการ เนื่องจากปัญหาที่รูปแบบเหล่านี้มีไว้เพื่อแก้ไขนั้นแทบจะไม่ปรากฏในการปฏิบัติจริง^{[ 11 ]}

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

ให้มีตารางฐานข้อมูลที่มีโครงสร้างดังต่อไปนี้ ซึ่งอธิบายถึงหนังสือเล่มหนึ่ง: ^{[ 10 ]}

ในตัวอย่างนี้ สมมติว่าหนังสือแต่ละเล่มมีผู้เขียนเพียงคนเดียว

ตารางที่สอดคล้องกับแบบจำลองเชิงสัมพันธ์จะมีคีย์หลักซึ่งระบุแถวแต่ละแถวได้อย่างไม่ซ้ำกัน ในตัวอย่างของเรา คีย์หลักเป็นคีย์ผสมของ{Title, Format}ซึ่งแสดงโดยการขีดเส้นใต้:

ในรูปแบบปกติแรกฟิลด์แต่ละฟิลด์จะมีค่าเดียว ฟิลด์ไม่สามารถมีชุดค่าหรือเรคอร์ดซ้อนกันได้หัวข้อ มีชุดค่าของหัวข้อ ซึ่งหมายความว่าไม่เป็นไปตามข้อกำหนด เพื่อแก้ปัญหานี้ หัวข้อจะถูกแยกออกมาเป็นตาราง หัวข้อแยกต่างหาก: ^{[ 10 ]}

แทนที่จะมีตารางเดียวในรูปแบบที่ไม่เป็นมาตรฐานตอนนี้มีสองตารางที่สอดคล้องกับรูปแบบมาตรฐานที่ 1 (1NF)

โปรดจำไว้ว่า ตาราง Bookด้านล่างมีคีย์ผสมคือ{Title, Format}ซึ่งจะไม่ตรงตามเงื่อนไข 2NF หากเซตย่อยบางส่วนของคีย์นั้นเป็นดีเทอร์มิแนนต์ ในขั้นตอนนี้ของการออกแบบคีย์ ดัง กล่าวยังไม่ได้ถูกกำหนดให้เป็นคีย์หลักดังนั้นจึงเรียกว่าคีย์ผู้สมัครพิจารณาตารางต่อไปนี้:

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

เพื่อให้ตารางนี้เป็นมาตรฐาน ให้กำหนดให้{Title}เป็นคีย์หลัก (คีย์ผู้สมัคร) แบบง่าย เพื่อให้แอตทริบิวต์ที่ไม่ใช่คีย์ผู้สมัครทั้งหมดขึ้นอยู่กับคีย์ผู้สมัครทั้งหมด และย้ายPrice ไป ไว้ในตารางแยกต่างหาก เพื่อรักษาความสัมพันธ์กับFormatไว้:

ขณะนี้ทั้ง ตาราง มูลค่าหนังสือและ ตาราง ราคาเป็นไปตามรูปแบบ 2NFแล้ว

ตารางBookยังคงมีการพึ่งพาเชิงฟังก์ชันแบบส่งต่อ ({Author Nationality} ขึ้นอยู่กับ {Author} ซึ่งขึ้นอยู่กับ {Title}) การละเมิดที่คล้ายกันนี้เกิดขึ้นกับตาราง Publisher ({Publisher Country} ขึ้นอยู่กับ {Publisher} ซึ่งขึ้นอยู่กับ {Title}) และตาราง Genre ({Genre Name} ขึ้นอยู่กับ {Genre ID} ซึ่งขึ้นอยู่กับ {Title}) ดังนั้น ตาราง Bookจึงไม่อยู่ในรูปแบบ 3NF เพื่อแก้ไขปัญหานี้ เราสามารถแยก {Author Nationality}, {Publisher Country} และ {Genre Name} ไปไว้ในตารางของตนเอง ซึ่งจะช่วยขจัดความสัมพันธ์เชิงฟังก์ชันแบบส่งต่อได้

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

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

เนื่องจากโครงสร้างตารางนี้ประกอบด้วยคีย์หลักแบบผสมจึงไม่มีแอตทริบิวต์ที่ไม่ใช่คีย์ และอยู่ในรูปแบบ BCNF อยู่แล้ว (และด้วยเหตุนี้จึงตรงตาม มาตรฐาน รูปแบบปกติ ก่อนหน้าทั้งหมด ) อย่างไรก็ตาม สมมติว่าหนังสือที่มีอยู่ทั้งหมดมีให้เลือกในแต่ละพื้นที่ชื่อเรื่องจึงไม่ได้ผูกติดกับสถานที่ ใดสถานที่หนึ่งอย่างชัดเจน ดังนั้นตารางจึงไม่ตรงตามมาตรฐาน 4NF

นั่นหมายความว่า เพื่อให้สอดคล้องกับรูปแบบปกติลำดับที่สี่ตารางนี้จำเป็นต้องถูกแยกย่อยด้วยเช่นกัน:

ตอนนี้ ทุกระเบียนถูกระบุอย่างชัดเจนด้วยซูเปอร์คีย์แล้วดังนั้น4NF จึง เป็นไปตามเงื่อนไข

สมมติว่าผู้รับสิทธิ์แฟรนไชส์สามารถสั่งซื้อหนังสือจากซัพพลายเออร์ที่แตกต่างกันได้ และให้ความสัมพันธ์นี้อยู่ภายใต้ข้อจำกัดต่อไปนี้ด้วย:

• หากซัพพลายเออร์ รายใดรายหนึ่ง จัดหาสินค้าที่มีชื่อเรื่อง ตามที่กำหนด
• และกรรมสิทธิ์จะถูกส่งมอบให้กับผู้รับสิทธิ์แฟรนไชส์
• และผู้รับสิทธิ์แฟรนไชส์ได้รับการจัดหาสินค้าจากซัพพลายเออร์
• จากนั้นผู้จัดจำหน่ายจะมอบกรรมสิทธิ์ให้กับผู้รับแฟรนไชส์^{​​[ 12 ]}

ตารางนี้อยู่ในรูปแบบ 4NFแต่รหัสซัพพลายเออร์เท่ากับผลรวมของการฉายภาพ: {{Supplier ID, Title}, {Title, Franchisee ID}, {Franchisee ID, Supplier ID}}ไม่มีส่วนประกอบใดของความสัมพันธ์แบบรวมนั้นเป็นซูเปอร์คีย์ (ซูเปอร์คีย์เดียวคือส่วนหัวทั้งหมด) ดังนั้นตารางจึงไม่ตรงตามมาตรฐานETNFและสามารถแยกย่อยเพิ่มเติมได้: ^{[ 12 ]}

การสลายตัวทำให้เกิดการปฏิบัติตามมาตรฐาน ETNF

ในการตรวจสอบว่าตารางใดไม่เป็นไปตามรูปแบบ5NFนั้น โดยปกติแล้วจำเป็นต้องตรวจสอบข้อมูลอย่างละเอียด สมมติว่าเรามีตารางจากตัวอย่าง 4NFที่มีการแก้ไขข้อมูลเล็กน้อย แล้วมาตรวจสอบกันว่ามันเป็นไปตามรูปแบบ5NF หรือไม่:

การแยกตารางนี้ออกเป็นส่วนย่อยจะช่วยลดความซ้ำซ้อน ทำให้ได้ตารางสองตารางดังต่อไปนี้:

การค้นหาข้อมูลโดยใช้ตารางเหล่านี้จะส่งคืนข้อมูลดังต่อไปนี้:

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

ผลลัพธ์ของการ JOIN จะเป็นอย่างไร? จริงๆ แล้วไม่สามารถรวมตารางทั้งสามนี้ได้ นั่นหมายความว่าไม่สามารถแยกข้อมูลFranchiseee – Book – Location ออก โดยไม่สูญเสียข้อมูลได้ ดังนั้นตารางจึงตรงตามเงื่อนไข5NF อยู่ แล้ว

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

คำสั่ง JOIN จะให้ผลลัพธ์ตามที่คาดหวังไว้:

CJ Dateได้โต้แย้งว่าฐานข้อมูลในรูปแบบ 5NF เท่านั้นที่ "เป็นมาตรฐาน" อย่างแท้จริง^{[ 13 ]}

ลองมาดู ตาราง Bookจากตัวอย่างก่อนหน้านี้ และตรวจสอบดูว่ามันตรงตามมาตรฐานรูปแบบโดเมนคีย์หรือไม่ :

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

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

กล่าวอีกนัยหนึ่งคือ ไม่มีอะไรขัดขวางไม่ให้เราใส่คำว่า "หนา" สำหรับหนังสือที่มีเพียง 50 หน้า ซึ่งจะทำให้ตารางนั้นขัดกับหลักการ DKNF

เพื่อแก้ไขปัญหานี้ จึงมีการสร้างตารางที่เก็บค่าแบบแจงนับซึ่งกำหนดความหนาและลบคอลัมน์นั้นออกจากตารางเดิม:

ด้วยวิธีนี้ การละเมิดความสมบูรณ์ของโดเมนจึงหมดไป และตารางจะอยู่ในรูปแบบ DKNF

การทำให้เป็นมาตรฐานไม่ได้ป้องกันกรณีผลลัพธ์ที่เป็นไปไม่ได้/ขัดแย้ง/คาดเดาไม่ได้ทั้งหมด ในตัวอย่างนี้ การกำหนดค่าหน้าขั้นต่ำ/สูงสุดเป็น 1/350 และ 200/999,999,999,999 จะนำไปสู่ผลลัพธ์ที่คาดเดาไม่ได้ ดังนั้นจึงควรระบุและใช้เฉพาะค่าหน้าขั้นต่ำเท่านั้น

คำจำกัดความที่เรียบง่ายและเข้าใจง่ายของรูปแบบปกติลำดับที่หกคือ"ตารางอยู่ใน รูปแบบปกติ ลำดับที่หกเมื่อแถวนั้นมีคีย์หลักและแอตทริบิวต์อื่นไม่เกินหนึ่งรายการ " ^{[ 14 ]}

นั่นหมายความว่า ตัวอย่างเช่น ตาราง Publisherที่ออกแบบขณะสร้าง 1NF :

จำเป็นต้องแยกย่อยออกเป็นสองตารางเพิ่มเติม:

ข้อเสียที่เห็นได้ชัดของ 6NF คือจำนวนตารางที่เพิ่มขึ้นอย่างมากในการแสดงข้อมูลเกี่ยวกับเอนทิตีเดียว หากตารางใน 5NF มีคอลัมน์คีย์หลักหนึ่งคอลัมน์และแอตทริบิวต์ N รายการ การแสดงข้อมูลเดียวกันใน 6NF จะต้องใช้ตาราง N รายการ การอัปเดตหลายฟิลด์ในเรคอร์ดเชิงแนวคิดเดียวจะต้องอัปเดตในหลายตาราง และการแทรกและการลบก็จะต้องดำเนินการในหลายตารางเช่นกัน ด้วยเหตุนี้ ในฐานข้อมูลที่ออกแบบมาเพื่อรองรับ ความต้องการ การประมวลผลธุรกรรมออนไลน์ (OLTP) จึงไม่ควรใช้ 6NF

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

อย่างไรก็ตาม ในทุกกรณีเหล่านี้ นักออกแบบฐานข้อมูลไม่จำเป็นต้องทำการทำให้เป็นมาตรฐาน 6NF ด้วยตนเองโดยการสร้างตารางแยกต่างหาก ระบบจัดการฐานข้อมูลบางระบบที่เชี่ยวชาญด้านคลังข้อมูล เช่นSybase IQจะใช้การจัดเก็บแบบคอลัมน์เป็นค่าเริ่มต้น แต่นักออกแบบยังคงเห็นเพียงตารางหลายคอลัมน์เดียว ระบบจัดการฐานข้อมูลอื่นๆ เช่น Microsoft SQL Server 2012 และเวอร์ชันต่อมา อนุญาตให้คุณระบุ "ดัชนีคอลัมน์สโตร์" สำหรับตารางเฉพาะ^{[ 15 ]}

• การลดความปกติ
• การปรับโครงสร้างฐานข้อมูลใหม่
• การแยกส่วนการเข้าร่วมแบบไม่สูญเสียข้อมูล

• Date, CJ (1999), An Introduction to Database Systems (ฉบับที่ 8). Addison-Wesley Longman. ISBN 0-321-19784-4.
• Kent, W. (1983) คู่มือฉบับย่อเกี่ยวกับรูปแบบปกติห้าแบบในทฤษฎีฐานข้อมูลเชิงสัมพันธ์ , Communications of the ACM, เล่มที่ 26, หน้า 120–125
• H.-J. Schek, P. Pistor โครงสร้างข้อมูลสำหรับระบบการจัดการฐานข้อมูลและการค้นหาข้อมูลแบบบูรณาการ

• Kent, William (กุมภาพันธ์ 1983). "คู่มือฉบับย่อสำหรับรูปแบบปกติห้าแบบในทฤษฎีฐานข้อมูลเชิงสัมพันธ์" . Communications of the ACM . 26 (2): 120– 125. doi : 10.1145/358024.358054 . S2CID  9195704 .
• หลักการพื้นฐานของการทำให้ฐานข้อมูลเป็นรูปแบบมาตรฐาน (Database Normalization Basics) เก็บถาวรเมื่อวันที่ 5 กุมภาพันธ์ 2550 ที่Wayback Machineโดย Mike Chapple (About.com)
• บทนำเกี่ยวกับการทำให้ฐานข้อมูลเป็นมาตรฐาน (Database Normalization) เก็บถาวรเมื่อวันที่ 28 กันยายน 2011 ที่Wayback Machine ส่วน ที่2 เก็บถาวรเมื่อวันที่ 8 กรกฎาคม 2011 ที่Wayback Machine
• บทนำสู่การทำให้ฐานข้อมูลเป็นมาตรฐานโดย ไมค์ ฮิลลีเยอร์
• บทความแนะนำเกี่ยวกับรูปแบบปกติ 3 รูปแบบแรกโดย เฟรด คูลสัน
• คำอธิบายพื้นฐานเกี่ยวกับการทำให้ฐานข้อมูลเป็นมาตรฐานโดย Microsoft
• การทำให้เป็นรูปแบบมาตรฐานในระบบจัดการฐานข้อมูล โดย Chaitanya (beginnersbook.com)
• คู่มือทีละขั้นตอนสำหรับการทำให้ฐานข้อมูลเป็นรูปแบบมาตรฐาน (Database Normalization)
• ETNF – Essential tuple normal form เก็บถาวรเมื่อวันที่ 6 มีนาคม 2016 ที่Wayback Machine