อธิบายการทําให้เป็นมาตรฐาน
การทําให้เป็นมาตรฐานของฐานข้อมูลคือกระบวนการออกแบบที่ใช้ในการจัดระเบียบข้อมูลลงในตารางและคอลัมน์ภายในฐานข้อมูล แต่ละตารางควรประกอบด้วยข้อมูลที่เกี่ยวข้องกับเอนทิตีเฉพาะ และรวมเฉพาะข้อมูลที่สนับสนุนเอนทิตีนั้น เป้าหมายหลักของการทําให้เป็นมาตรฐานคือการลดข้อมูลที่ซ้ํากันภายในฐานข้อมูล ซึ่งช่วยป้องกันการลดประสิทธิภาพการทํางานในระหว่างการแทรกและการอัปเดต ตัวอย่างเช่น หากที่อยู่ของลูกค้าจําเป็นต้องได้รับการอัปเดต การนําการเปลี่ยนแปลงไปใช้ง่ายขึ้นหากมีการจัดเก็บที่อยู่ไว้ในตําแหน่งที่ตั้งเดียว เช่น Customers ตาราง
รูปแบบทั่วไปส่วนใหญ่ของการทําให้เป็นมาตรฐานคือฟอร์มแรก ฟอร์มที่สอง และฟอร์มปกติที่สาม
ฟอร์มปกติรูปแบบแรก
รูปแบบปกติแรกมีข้อกําหนดต่อไปนี้:
- สร้างตารางแยกต่างหากสําหรับแต่ละชุดของข้อมูลที่เกี่ยวข้อง
- กําจัดกลุ่มที่ทําซ้ําในแต่ละตาราง
- ระบุชุดข้อมูลที่เกี่ยวข้องแต่ละชุดด้วยคีย์หลัก
ในแบบจําลองนี้ คุณควรหลีกเลี่ยงการใช้คอลัมน์หลายคอลัมน์ในตารางเดียวเพื่อจัดเก็บข้อมูลที่คล้ายกัน ตัวอย่างเช่น ถ้าผลิตภัณฑ์สามารถมีหลายสี คุณไม่ควรมีหลายคอลัมน์ในแถวเดียวที่มีค่าสีที่แตกต่างกัน ตาราง ProductColorsแรกต่อไปนี้ ไม่ได้อยู่ในฟอร์มปกติแรกเนื่องจากมีค่าที่ซ้ํากันสําหรับสี สําหรับผลิตภัณฑ์ที่มีสีเดียวเท่านั้นมีพื้นที่ที่สิ้นเปลือง นอกจากนี้ หากผลิตภัณฑ์มาพร้อมสีมากกว่าสามสี จะไม่สามารถตั้งค่าจํานวนคอลัมน์สูงสุดได้ แต่เราสามารถสร้างตารางใหม่ตามที่แสดงในตารางที่สอง ProductColorได้
ฟอร์มปกติแรกกําหนดให้มีคีย์ที่ไม่ซ้ํากันสําหรับตาราง ซึ่งเป็นคอลัมน์ (หรือคอลัมน์) ที่มีค่าที่ระบุเฉพาะของแต่ละแถว ในตารางที่สอง ไม่มีคอลัมน์ใดที่เป็นค่าเฉพาะของตัวเอง แต่การรวมกันของ ProductID และ Color จะสร้างคีย์ที่ไม่ซ้ํากัน เมื่อจําเป็นต้องใช้หลายคอลัมน์เพื่อสร้างคีย์ที่ไม่ซ้ํากัน จะเรียกว่าคีย์แบบรวม
ProductColorsโต๊ะ:#C1 #B0 ProductID #C1 #B0 Color1 #C1 #B0 Color2 #C1 #B0 Color3 1 สีแดง สีเขียว เหลือง 2 เหลือง 3 น้ำเงิน สีแดง 4 น้ำเงิน 5 สีแดง ProductColorโต๊ะ:#C1 #B0 ProductID สี 1 สีแดง 1 สีเขียว 1 เหลือง 2 เหลือง 3 น้ำเงิน 3 สีแดง 4 น้ำเงิน 5 สีแดง
ตาราง ProductInfoที่สาม อยู่ในรูปแบบปกติแรกเนื่องจากแต่ละแถวอ้างอิงถึงผลิตภัณฑ์เฉพาะ ไม่มีกลุ่มการทําซ้ํา และเรามีคอลัมน์ ProductID เพื่อใช้เป็นคีย์หลัก
| #C1 #B0 ProductID | #B0 #C1 ProductName | ราคา | #B0 #C1 ProductionCountry | #C1 ShortLocation ของ #B0 |
|---|---|---|---|---|
| 1 | วิดเจ็ต | 15.95 | ประเทศสหรัฐอเมริกา | US |
| 2 | ฝอย | 41.95 | สหราชอาณาจักร | สหราชอาณาจักร |
| 3 | Glombit | 49.95 | สหราชอาณาจักร | สหราชอาณาจักร |
| 4 | สอร์ฟิน | 99.99 | สาธารณรัฐฟิลิปปินส์ | RepPhil |
| 5 | ก้านโบลท์ | 29.95 | ประเทศสหรัฐอเมริกา | US |
ฟอร์มปกติที่สอง
รูปแบบปกติที่สองมีข้อกําหนดต่อไปนี้นอกเหนือจากที่กําหนดโดยรูปแบบปกติครั้งแรก:
- หากตารางมีคีย์แบบรวม แอตทริบิวต์ทั้งหมดต้องขึ้นอยู่กับคีย์ที่สมบูรณ์และไม่ใช่แค่ส่วนหนึ่งของคีย์เท่านั้น
ฟอร์มปกติที่สองจะเกี่ยวข้องกับตารางที่มีคีย์แบบรวมเท่านั้น เช่นในตาราง ProductColorซึ่งเป็นตารางที่สอง พิจารณากรณีที่ ProductColor ตารางรวมราคาของผลิตภัณฑ์ด้วย ตารางนี้มีคีย์แบบรวมใน ProductID และ Colorเนื่องจากเฉพาะการใช้ค่าคอลัมน์ทั้งสองเท่านั้นที่เราสามารถระบุแถวได้แบบไม่ซ้ํากัน ถ้าราคาของผลิตภัณฑ์ไม่เปลี่ยนแปลงด้วยสี เราอาจเห็นข้อมูลตามที่แสดงในตารางนี้
| #C1 #B0 ProductID | สี | ราคา |
|---|---|---|
| 1 | สีแดง | 15.95 |
| 1 | สีเขียว | 15.95 |
| 1 | เหลือง | 15.95 |
| 2 | เหลือง | 41.95 |
| 3 | น้ำเงิน | 49.95 |
| 3 | สีแดง | 49.95 |
| 4 | น้ำเงิน | 99.95 |
| 5 | สีแดง | 29.95 |
ตารางนี้ไม่ได้อยู่ในรูปแบบปกติที่สอง ค่าราคาจะขึ้นอยู่กับ ProductID แต่ไม่ขึ้นอยู่กับColor มีสามแถวสําหรับ ProductID 1ดังนั้นราคาสําหรับผลิตภัณฑ์นั้นจะถูกทําซ้ําสามครั้ง ปัญหาเกี่ยวกับการละเมิดฟอร์มปกติที่สองคือถ้าเราจําเป็นต้องอัปเดตราคาเราต้องตรวจสอบให้แน่ใจว่ามีการอัปเดตทุกที่ หากเราอัปเดตราคาในแถวแรก แต่ไม่ใช่ในแถวที่สองหรือสาม เราจะพบความผิดปกติของการอัปเดต หลังจากการอัปเดต เราจะไม่สามารถกําหนดราคาที่แท้จริงสําหรับ ProductID 1ได้ โซลูชันคือการย้าย Price คอลัมน์ไปยังตารางที่มี ProductID เป็นคีย์คอลัมน์เดียวเนื่องจากเป็นคอลัมน์เดียวที่ Price ขึ้นอยู่ ตัวอย่างเช่น เราสามารถใช้ ตาราง 3 เพื่อจัดเก็บPrice
หากราคาสําหรับผลิตภัณฑ์แตกต่างกันตามสี ตารางที่สี่จะอยู่ในรูปแบบปกติที่สอง เนื่องจากราคาจะขึ้นอยู่กับทั้งสองส่วนของคีย์: ProductID และColor
ฟอร์มปกติที่สาม
โดยปกติแล้วฟอร์มปกติที่สามคือจุดมุ่งหมายสําหรับฐานข้อมูล OLTP ส่วนใหญ่ รูปแบบปกติที่สามมีข้อกําหนดต่อไปนี้นอกเหนือจากที่กําหนดโดยรูปแบบปกติที่สอง:
- คอลัมน์ที่ไม่ใช่คีย์ทั้งหมดจะขึ้นอยู่กับคีย์หลักแบบไม่จํากัด
ความสัมพันธ์แบบถ่ายทอดหมายความว่าคอลัมน์หนึ่งในตารางสัมพันธ์กับคอลัมน์อื่นผ่านคอลัมน์ที่สอง การขึ้นต่อกันหมายความว่าคอลัมน์สามารถรับค่ามาจากอีกอันหนึ่งซึ่งเป็นผลลัพธ์ของความสัมพันธ์นี้ ตัวอย่างเช่น คุณสามารถกําหนดอายุของคุณได้ตั้งแต่วันเกิด ซึ่งจะทําให้อายุของคุณขึ้นอยู่กับวันเกิดของคุณ อ้างอิงกลับไปยังตาราง ProductInfoที่สาม ตารางนี้อยู่ในรูปแบบปกติที่สอง แต่ไม่ใช่ในรูปแบบที่สาม คอลัมน์ ShortLocation จะขึ้นอยู่กับ ProductionCountry คอลัมน์ ซึ่งไม่ใช่คีย์ เช่นเดียวกับรูปแบบปกติที่สอง การละเมิดฟอร์มปกติที่สามอาจนําไปสู่การอัปเดตสิ่งผิดปกติได้ เราจะลงเอยด้วยข้อมูลที่ไม่สอดคล้องกันถ้าเราอัปเดต ShortLocation ในหนึ่งแถว แต่ไม่ได้อัปเดตในแถวทั้งหมดที่ตําแหน่งที่ตั้งนั้นเกิดขึ้น เพื่อป้องกันปัญหานี้ เราสามารถสร้างตารางแยกต่างหากเพื่อจัดเก็บชื่อประเทศ/ภูมิภาคและฟอร์มที่ถูกย่อให้สั้นลงได้
การดีนอร์มอลไลเซต
ในขณะที่รูปแบบปกติที่สามเป็นที่ต้องการทางทฤษฎี แต่ก็ไม่เป็นไปได้สําหรับข้อมูลทั้งหมดเสมอไป นอกจากนี้ ฐานข้อมูลมาตรฐานไม่ได้ให้ประสิทธิภาพที่ดีที่สุดเสมอไป ข้อมูลที่เป็นมาตรฐานมักต้องใช้การดําเนินการรวมหลายแบบเพื่อรับข้อมูลที่จําเป็นทั้งหมดที่ส่งกลับในคิวรีเดียว มีข้อดีระหว่างการปรับมาตรฐานข้อมูลเมื่อจํานวนการรวมที่จําเป็นในการแสดงผลลัพธ์คิวรีมีการใช้งาน CPU สูง และข้อมูลที่ผ่านการดีนอร์มอลไลเซชั่นที่มีการรวมน้อยลงและจําเป็นต้องมี CPU น้อยลง แต่เปิดโอกาสให้มีการอัปเดตความผิดปกติ
ข้อมูลที่ผ่านการดีนอร์มอลไลซ์สามารถมีประสิทธิภาพในการคิวรีมากขึ้น โดยเฉพาะอย่างยิ่งสําหรับการอ่านปริมาณงานหนัก เช่น คลังข้อมูล ในกรณีเหล่านั้น การมีคอลัมน์เพิ่มเติมอาจเสนอรูปแบบคิวรีที่ดีกว่าและ/หรือคิวรีแบบง่ายมากขึ้น
Schema รูปดาว
ในขณะที่การทําให้เป็นมาตรฐานส่วนใหญ่มีจุดมุ่งหมายที่ปริมาณงาน OLTP แต่คลังข้อมูลมีโครงสร้างการสร้างแบบจําลองของตัวเองซึ่งโดยทั่วไปจะเป็นแบบจําลองที่ไม่มีการนอร์มอลไลซ์ การออกแบบนี้ใช้ตารางข้อเท็จจริงเพื่อบันทึกการวัดหรือเมตริกสําหรับเหตุการณ์เฉพาะ เช่น ยอดขาย และรวมเข้ากับตารางมิติ ตารางมิติมีขนาดเล็กกว่าในแง่ของการนับจํานวนแถว แต่อาจมีคอลัมน์จํานวนมากเพื่ออธิบายข้อมูลข้อเท็จจริง ตัวอย่างของมิติ ได้แก่ สินค้าคงคลัง เวลา และภูมิศาสตร์ รูปแบบการออกแบบนี้ทําให้ฐานข้อมูลง่ายต่อการคิวรีและเพิ่มประสิทธิภาพการทํางานสําหรับปริมาณงานที่อ่าน
รูปภาพแสดงตัวอย่างของสคีมาแบบดาวที่มี FactResellerSales ตารางข้อเท็จจริงและมิติสําหรับวันที่ สกุลเงิน และผลิตภัณฑ์ ตารางข้อเท็จจริงประกอบด้วยข้อมูลที่เกี่ยวข้องกับธุรกรรมการขาย ในขณะที่มิติประกอบด้วยข้อมูลที่เกี่ยวข้องกับองค์ประกอบเฉพาะของข้อมูลการขายเท่านั้น ตัวอย่างเช่น FactResellerSales ตารางรวม เฉพาะ ProductKey เพื่อระบุว่าผลิตภัณฑ์ใดขายได้ รายละเอียดทั้งหมดเกี่ยวกับแต่ละผลิตภัณฑ์จะถูกจัดเก็บไว้ใน DimProduct ตาราง และเชื่อมโยงกับตารางข้อเท็จจริงโดยใช้ ProductKey คอลัมน์
ที่เกี่ยวข้องกับการออกแบบ Schema รูปดาวคือแบบจําลองแบบจําลองที่เพิ่มการทํานอล์วลซึ่งใช้ชุดตารางที่เป็นมาตรฐานมากขึ้นสําหรับเอนทิตี้ธุรกิจเดียว รูปภาพต่อไปนี้แสดงตัวอย่างของมิติเดียวในแบบจําลองมิติที่เพิ่มการทํานอล์กหิมะ มิติ Products จะถูกทําให้เป็นมาตรฐานและจัดเก็บไว้ในสามตาราง: DimProductCategoryและ DimProductSubcategoryDimProduct
ความแตกต่างหลักระหว่าง Schema ของดาวและแบบจําลองมิติที่เพิ่มการทํานึ่งสโนว์เฟล็กคือ มิติในแบบจําลองแบบจําลองมิติที่เพิ่มการทํานึ่งหิมะเป็นเรื่องปกติเพื่อลดความซ้ําซ้อนซึ่งช่วยประหยัดพื้นที่เก็บข้อมูล ข้อดีคือคิวรีของคุณต้องการการรวมมากขึ้น ซึ่งสามารถเพิ่มความซับซ้อนและลดประสิทธิภาพการทํางานของคุณ