รูปแบบไฟล์ใหม่ 6NF จุดประกายการถกเถียงเรื่องการแลกเปลี่ยนข้อมูล Bitemporal และความแม่นยำของ Timestamp

รูปแบบการแลกเปลี่ยนข้อมูลใหม่ที่เรียกว่า 6NF ได้เกิดขึ้น ซึ่งออกแบบมาโดยเฉพาะสำหรับ data warehouses และระบบรายงาน รูปแบบนี้มีเป้าหมายที่จะแทนที่รูปแบบแบบลำดับชั้นที่ซับซ้อนอย่าง XBRL, XML, JSON และ YAML ด้วยโครงสร้างที่เรียบง่ายกว่าและเป็นมิตรกับฐานข้อมูล อย่างไรก็ตาม รูปแบบนี้ได้จุดประกายการอภิปรายอย่างมีนัยสำคัญในชุมชนเทคนิคเกี่ยวกับตัวเลือกการออกแบบและการประยุกต์ใช้จริง

คุณสมบัติหลักของรูปแบบ 6NF :

• โครงสร้างแบบเรียบง่ายที่เข้ากันได้กับฐานข้อมูล (ไม่มี objects หรือ arrays ซ้อนกัน)
• ความเข้ากันได้แบบ bitemporal ด้วย timestamps ของ valid_from และ recorded_at
• มาตรฐานเวลา UTC พร้อมส่วนต่อท้าย 'Z' (เช่น 2023-01-01T12:00:00Z)
• ใช้ Crockford's Base32-encoded UUIDv7 สำหรับตัวระบุ
• ใช้รูปแบบ Snake_case สำหรับตัวระบุ
• คำหลักที่คำนึงถึงตัวพิมพ์ใหญ่เล็ก (ตัวพิมพ์ใหญ่) และตัวระบุ (ตัวพิมพ์เล็ก)
• การเข้ารหัส UTF-8

ข้อกังวลเรื่องความแม่นยำของ Timestamp แบ่งความเห็น

รูปแบบ 6NF กำหนดให้ข้อมูลทั้งหมดต้องมี timestamps ทั้ง valid_from และ recorded_at ในรูปแบบ UTC วิธีการ bitemporal นี้ได้สร้างการถกเถียงในหมู่นักพัฒนาเกี่ยวกับว่าความแม่นยำเช่นนี้จำเป็นเสมอหรือไม่ บางคนโต้แย้งว่าสถานการณ์ทางธุรกิจหลายอย่างต้องการเพียงความแม่นยำระดับวันที่มากกว่า timestamps ที่แน่นอน

จากประสบการณ์ของผม valid_from เป็นวันที่เสมอ (ไม่มีเวลา ไม่มี timezone) นั่นคือวิธีที่มันถูกรายงานในเอกสาร (เช่น ช่วงระยะเวลาที่สัญญามีผลบังคับใช้)

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

การขาดหายไปของวันที่สิ้นสุดสร้างคำถามในการนำไปใช้

ข้อกังวลทางเทคนิคที่สำคัญได้เกิดขึ้นเกี่ยวกับการจัดการความถูกต้องตามเวลาของรูปแบบ รูปแบบ 6NF มี timestamps ของ valid_from แต่ขาดฟิลด์ valid_to ที่สอดคล้องกัน ตัวเลือกการออกแบบนี้ได้ทำให้เกิดคำถามเกี่ยวกับวิธีที่ระบบจัดการการอัปเดตข้อมูล การลบ และช่วงระยะเวลาที่มีผลบังคับใช้

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

องค์ประกอบไวยากรณ์ของรูปแบบ:

• ENTITY - กำหนดเอนทิตีข้อมูลหลักพร้อม UUIDs
• REFERENCE - สร้างข้อมูลอ้างอิงพร้อมตัวระบุ
• ATTRIBUTE_OF - เชื่อมโยงแอตทริบิวต์กับเอนทิตีพร้อมการประทับเวลา
• ATTRIBUTE_REF_OF - อ้างอิงแอตทริบิวต์ระหว่างเอนทิตี
• STRUCT_OF - จัดกลุ่มแอตทริบิวต์หลายตัวที่มีบริบททางเวลาร่วมกัน
• RELATIONSHIP - กำหนดการเชื่อมต่อระหว่างเอนทิตี

ปรัชญาการทำ Normalization พบกับแนวโน้มข้อมูลสมัยใหม่

การเน้นของรูปแบบนี้ในการทำ sixth normal form normalization ขัดแย้งกับแนวโน้มอุตสาหกรรมปัจจุบันที่มุ่งไปสู่โครงสร้างข้อมูลแบบ denormalized และ nested ผลิตภัณฑ์ data warehouse สมัยใหม่ได้เพิ่มการสนับสนุนสำหรับการประมวลผลข้อมูล JSON แบบ nested โดยตรงมากขึ้น แทนที่จะทำให้เรียบเป็นตารางที่ normalized

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

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

อ้างอิง: 6NF File Format