Data​ ​Dictionary​ ​คือ​อะไร​:​ ​ตัวอย่าง​พจนานุกรม​ข้อมูล​สำหรับ​รายงาน​โครง​งาน

Data Dictionary หรือพจนานุกรมข้อมูล คือเอกสารที่อธิบายโครงสร้างและความหมายของข้อมูล เพื่อให้ผู้วิเคราะห์ ผู้พัฒนา และผู้ใช้ข้อมูลเข้าใจตรงกัน ในโครงงานฐานข้อมูล มักจัดทำเป็นตารางอธิบายแต่ละฟิลด์ เช่น ชื่อ ชนิดข้อมูล การยอมรับค่าว่าง และกฎที่ข้อมูลต้องปฏิบัติตาม แนวทางของ U.S. Geological Survey เน้นทั้งคำจำกัดความ โครงสร้าง และกฎทางธุรกิจ จึงไม่ควรเขียนเพียงชื่อคอลัมน์กับชนิดข้อมูล [1]

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

Data Dictionary มีประโยชน์อย่างไร

สมมติทีมหนึ่งใช้ชื่อ due_on แทน “วันครบกำหนดคืน” แต่ผู้ทำรายงานเข้าใจว่าเป็น “วันที่คืนจริง” แม้ทั้งสองฝ่ายเลือกชนิด date เหมือนกัน ผลสรุปจำนวนรายการเกินกำหนดก็อาจผิดได้ ปัญหานี้เกิดจากความหมายไม่ตรงกัน ไม่ใช่ไวยากรณ์ฐานข้อมูล

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

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

Data Dictionary ต่างจาก ER Diagram และ DFD อย่างไร

เอกสารทั้งสามมีหน้าที่ต่างกันและใช้ประกอบกันได้

เริ่มจาก ER Diagram และความสัมพันธ์ของข้อมูล เพื่อเห็นภาพโครงสร้าง แล้วเขียนคำอธิบายรายฟิลด์ ส่วน DFD และ Context Diagram ใช้อธิบายการไหลของข้อมูล ไม่ควรนำลูกศรใน DFD ไปตีความเป็น Foreign Key โดยตรง

ตารางพจนานุกรมข้อมูลควรมีอะไรบ้าง

ส่วนประกอบที่เหมาะกับรายงานโครงงานทั่วไป ได้แก่ ชื่อตารางและวัตถุประสงค์ ชื่อฟิลด์ ความหมาย ชนิดและขนาดข้อมูล การยอมรับ NULL คีย์และตารางที่อ้างถึง ค่าเริ่มต้น ชุดค่าที่อนุญาต หน่วย และกฎตรวจสอบ เลือกให้ตรงกับระบบจริง ไม่จำเป็นต้องมีคอลัมน์ที่ไม่มีข้อมูลอธิบาย [1]

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

หากตารางกว้างเกินอ่านบนหน้ากระดาษ สามารถแยกตารางสรุปฟิลด์ออกจากรายการกฎใต้ตารางได้ สิ่งที่ต้องรักษาคือความเชื่อมโยงระหว่างชื่อฟิลด์กับกฎของฟิลด์นั้น

ตัวอย่าง Data Dictionary: ตารางรายการยืมอุปกรณ์

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

ขอบเขตนี้เป็นข้อมูลการยืมหลังส่งมอบอุปกรณ์ แยกจากตัวอย่าง “คำขอและการพิจารณา” ในบทความ Use Case และ DFD รายการที่ถูกปฏิเสธจึงไม่ควรถูกบันทึกเป็นการยืมในตารางนี้

กฎของตัวอย่างนี้ ต้องเขียนกำกับตารางให้ครบ:

• loan_id เป็น Primary Key; วิธีสร้างรหัสต้องระบุในแบบออกแบบจริง ตัวอย่างนี้ยังไม่กำหนดระบบสร้างเลขอัตโนมัติ
• borrower_id เป็น Foreign Key อ้างถึง borrowers.borrower_id และ equipment_id อ้างถึง equipment.equipment_id โดยคอลัมน์ปลายทางเป็น Primary Key ของตารางนั้น
• due_on >= borrowed_on เพราะไม่อนุญาตให้กำหนดวันคืนก่อนวันยืม
• returned_on อาจเป็น NULL; เมื่อมีค่า ต้องเป็นวันเดียวกับหรือหลัง borrowed_on
• ตัวอย่างนี้ไม่กำหนดค่าเริ่มต้นให้ฟิลด์ใด และไม่ใช้วันที่สมมติเช่น 1900-01-01 แทนการยังไม่คืน

PostgreSQL ใช้ NOT NULL, PRIMARY KEY, FOREIGN KEY และ CHECK เพื่อบังคับข้อกำหนดเหล่านี้ได้ ชนิดข้อมูลอย่างเดียวไม่เพียงพอ เช่น date ยอมให้เก็บวันก่อนวันยืมได้ถ้าไม่มีกฎเพิ่มเติม [2]

ภาพที่ 1: การเชื่อมฟิลด์ loans.due_on กับความหมาย ชนิดข้อมูล และกฎตรวจสอบในระบบยืมอุปกรณ์สมมติ ผู้เขียนจัดทำภาพเพื่ออธิบายตัวอย่าง โดยประยุกต์แนวทางเอกสารข้อมูล [1] และข้อกำหนดฐานข้อมูล [2]

ตัวอย่างคำจำกัดความแบบละเอียดของ due_on

ฟิลด์นี้ใช้หน่วยเป็น วันตามปฏิทิน ตัวอย่างค่า 2026-10-09 เขียนแบบปี-เดือน-วัน ค.ศ. เพื่อให้เอกสารอ่านตรงกัน ไม่ได้หมายความว่าฐานข้อมูลเก็บเป็นข้อความหรือว่าฟิลด์นี้มีเขตเวลา หากระบบคิดค่าปรับเป็นรายชั่วโมง ต้องทบทวนแบบจำลองเวลาเพิ่มเติม

เมื่อเลื่อนกำหนดคืน ค่า due_on อาจเปลี่ยนตามสิทธิ์และกระบวนการที่ทีมกำหนด หากต้องตรวจย้อนหลังว่าใครเลื่อนจากวันใดเป็นวันใด ต้องออกแบบประวัติการเปลี่ยนแปลงเพิ่ม ตารางตัวอย่างนี้ยังไม่มีประวัติดังกล่าว

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

ข้อผิดพลาดที่พบบ่อยในการเขียนพจนานุกรมข้อมูล

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

คิดว่า Foreign Key บังคับว่าต้องมีค่าเสมอ: Foreign Key ตรวจความสัมพันธ์กับข้อมูลปลายทาง แต่ถ้าต้องการให้กรอกค่าจำเป็นต้องกำหนด NOT NULL ด้วย ขณะที่ Primary Key มีเงื่อนไขไม่ซ้ำและไม่เป็น NULL อยู่แล้ว [2] อ่านเพิ่มเติมได้ใน Primary Key และ Foreign Key

มีเอกสารแต่ไม่มีการบังคับกฎ: ข้อความ “วันคืนต้องไม่ก่อนวันยืม” ไม่ทำให้ฐานข้อมูลปฏิเสธค่าผิดเอง ต้องตรวจว่าแอปและฐานข้อมูลนำข้อกำหนดไปใช้จริง พร้อมทดสอบข้อมูลที่ควรผ่านและไม่ผ่าน

คัดลอกชนิดข้อมูลจากตัวอย่างโดยไม่ดูระบบจริง: ชื่อชนิดข้อมูลและความยาวต้องตรงกับฐานข้อมูลที่เลือก หากใช้ระบบอื่นต้องตรวจเอกสารของระบบนั้น และปรับชื่อคีย์ให้ตรงกับ ER Diagram รวมถึงไฟล์สร้างตาราง

สร้าง Data Dictionary จากฐานข้อมูลอัตโนมัติได้ไหม

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

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

การนำไปใช้ในรายงานโครงงาน

ในส่วนทฤษฎีที่เกี่ยวข้อง ให้อธิบายความหมายและประโยชน์ด้วยถ้อยคำของตนเอง พร้อมอ้างถึงแหล่งต้นทาง ในส่วนออกแบบระบบ ให้แสดงพจนานุกรมข้อมูลของโครงงานจริงและชี้ว่าฟิลด์สัมพันธ์กับ ER Diagram อย่างไร ส่วนผลการพัฒนาและทดสอบควรแสดงเฉพาะสิ่งที่ได้ตรวจจริง ตำแหน่งบทให้ยึดคู่มือของสถานศึกษา

ตัวอย่างประโยคสำหรับปรับใช้คือ “โครงงานจัดทำพจนานุกรมข้อมูลเพื่อกำหนดความหมาย ชนิดข้อมูล และข้อกำหนดของแต่ละฟิลด์ให้สอดคล้องกับแบบจำลองฐานข้อมูล โดยประยุกต์แนวทางการอธิบายข้อมูลของ USGS [1]” จากนั้นตามด้วยตารางของตนเอง ไม่ควรคัดลอกตาราง loans ไปใช้กับระบบที่มีขอบเขตต่างกันโดยไม่ปรับแก้

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

Waihaus Studio. (2026, 2 ตุลาคม). Data Dictionary คืออะไร: ตัวอย่างพจนานุกรมข้อมูลสำหรับรายงานโครงงาน. บทความบนเว็บไซต์ Waihaus

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

คำถามที่พบบ่อยเกี่ยวกับ Data Dictionary

Data Dictionary ต้องทำทุกตารางไหม

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

พจนานุกรมข้อมูลจำเป็นต้องเป็นไฟล์ Excel หรือไม่

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

ใช้ AI ช่วยเขียนพจนานุกรมข้อมูลได้ไหม

ใช้ช่วยร่างจาก schema ได้ แต่ต้องตรวจชื่อฟิลด์ คีย์ ความสัมพันธ์ และคำจำกัดความกับข้อกำหนดจริง โดยเฉพาะความหมายที่ AI อนุมานจากชื่อ เช่น created_at ไม่ได้แปลว่าเวลาที่อนุมัติรายการเสมอไป

เอกสารอ้างอิง

[1] U.S. Geological Survey. (2025, 27 กุมภาพันธ์). Data Dictionaries. แนวทางการจัดทำพจนานุกรมข้อมูลของ USGS (วันที่ปรับปรุงที่ระบุบนหน้าเว็บ; สืบค้น 2 ตุลาคม 2026)

[2] PostgreSQL Global Development Group. (ม.ป.ป.). 5.5. Constraints. PostgreSQL 18 Documentation. ข้อกำหนดของคอลัมน์และตารางใน PostgreSQL (สืบค้น 2 ตุลาคม 2026)

[3] PostgreSQL Global Development Group. (ม.ป.ป.). Chapter 35. The Information Schema. PostgreSQL 18 Documentation. ข้อมูลโครงสร้างฐานข้อมูลผ่าน Information Schema (สืบค้น 2 ตุลาคม 2026)

เมื่อเปลี่ยนแบบออกแบบให้เป็นระบบใช้งานจริง บริการพัฒนา Web Application ของ Waihaus สามารถใช้เอกสารข้อมูลร่วมกับขอบเขตงานและเกณฑ์ตรวจรับ เพื่อให้ทีมคุยเรื่องข้อมูลได้ตรงกันตั้งแต่ต้น