Introduction to Database Systems
ฐานข้อมูลคืออะไร ทำไมต้องมี DBMS แทนการเก็บไฟล์ธรรมดา สามระดับของการมองข้อมูล และส่วนประกอบภายในของ DBMS
วิดีโอที่อาจารย์ให้ดูก่อนเรียนบทนี้:
1.1ฐานข้อมูลคืออะไร
Database (ฐานข้อมูล) คือ ชุดข้อมูลขนาดใหญ่ที่เชื่อมโยงกัน ซึ่งจำลอง “องค์กรในโลกจริง” เอาไว้ สิ่งที่มันจำลองมีสองอย่างคือ
- Entities — สิ่งของหรือคนที่เราสนใจ เช่น นักศึกษา รายวิชา อาจารย์
- Relationships — ความสัมพันธ์ระหว่างสิ่งเหล่านั้น เช่น “นักศึกษาลงทะเบียนรายวิชา”
DBMS (Database Management System) คือ ซอฟต์แวร์ ที่ออกแบบมาเพื่อเก็บและจัดการฐานข้อมูล ประกอบด้วย
- ชุดข้อมูลที่สัมพันธ์กัน (collection of interrelated data)
- ชุดโปรแกรมสำหรับเข้าถึงข้อมูลนั้น (set of programs to access the data)
- สภาพแวดล้อมที่ทั้ง convenient และ efficient ในการใช้งาน
ตัวอย่างการใช้งานจริง
| ระบบ | ใช้ฐานข้อมูลทำอะไร |
|---|---|
| ธนาคาร | ธุรกรรม (transactions) โอน/ฝาก/ถอน |
| สายการบิน | การจอง ตารางบิน |
| มหาวิทยาลัย | ลงทะเบียน เกรด ทรานสคริปต์ |
| ร้านค้าออนไลน์ | ติดตามคำสั่งซื้อ ระบบแนะนำสินค้า |
| การผลิต | สายการผลิต สต๊อก ซัพพลายเชน |
| ทรัพยากรบุคคล | ประวัติพนักงาน เงินเดือน ภาษี |
1.2ทำไมไม่เก็บเป็นไฟล์ธรรมดา
สมัยก่อน แอปพลิเคชันฐานข้อมูลถูกเขียนทับบน file system โดยตรง ลองนึกภาพสถานการณ์นี้: บริษัทหนึ่งมีข้อมูลพนักงาน แผนก สินค้า ยอดขาย รวม 500 GB · พนักงานหลายคนเข้าถึงพร้อมกัน · ต้องตอบคำถามเกี่ยวกับข้อมูลได้เร็ว · การแก้ไขของผู้ใช้แต่ละคนต้องสอดคล้องกัน · บางส่วนของข้อมูลต้องจำกัดสิทธิ์การเข้าถึง
ถ้าเก็บเป็นไฟล์ จะเจอปัญหาทันที: เราไม่มี RAM 500 GB ให้โหลดทั้งหมด · ต้องเขียนโปรแกรมพิเศษสำหรับทุกคำถามที่ผู้ใช้อยากรู้ · โปรแกรมเหล่านั้นซับซ้อนเพราะข้อมูลมหาศาล · ระบบปฏิบัติการให้แค่รหัสผ่านเป็นกลไกความปลอดภัย ซึ่งยืดหยุ่นไม่พอ
7 ข้อเสียของการใช้ file system เก็บข้อมูล
ข้อนี้ออกสอบบ่อยมาก ทั้งแบบให้ระบุชื่อปัญหา และแบบให้ยกตัวอย่าง — ท่องให้ครบ
| ปัญหา | อธิบาย + ตัวอย่าง |
|---|---|
| 1. Data redundancy & inconsistency ข้อมูลซ้ำซ้อนและขัดแย้ง |
ไฟล์หลายรูปแบบ ข้อมูลชุดเดียวกันถูกเก็บซ้ำในหลายไฟล์ พอแก้ที่หนึ่งแต่ลืมอีกที่ ข้อมูลก็ขัดแย้งกันทันที |
| 2. Difficulty in accessing data เข้าถึงข้อมูลยาก |
ทุกคำถามใหม่ = ต้องเขียนโปรแกรมใหม่ 1 ตัว · อยากรู้ “นักศึกษาที่ GPA > 3.5 ในสาขา CoE” ก็ต้องให้โปรแกรมเมอร์เขียนให้ |
| 3. Data isolation ข้อมูลกระจัดกระจาย |
อยู่คนละไฟล์ คนละฟอร์แมต เขียนโปรแกรมดึงมารวมกันยาก |
| 4. Integrity problems ความถูกต้องของข้อมูล |
กฎอย่าง “ยอดเงินต้องมากกว่า 0” ถูก ฝังอยู่ในโค้ดโปรแกรม แทนที่จะประกาศไว้ชัดเจน → เพิ่มกฎใหม่หรือแก้กฎเดิมยากมาก ต้องไล่แก้ทุกโปรแกรม |
| 5. Atomicity of updates ทำครึ่ง ๆ กลาง ๆ ไม่ได้ |
ระบบล่มระหว่างอัปเดต → ข้อมูลค้างอยู่ในสถานะไม่สมบูรณ์ · การโอนเงินต้องสำเร็จทั้งหมดหรือไม่เกิดขึ้นเลย |
| 6. Concurrent access anomalies เข้าถึงพร้อมกันแล้วเพี้ยน |
ต้องให้เข้าพร้อมกันได้เพื่อประสิทธิภาพ แต่ถ้าไม่ควบคุมจะเกิดข้อมูลผิด · สองคนอ่านยอด 100 พร้อมกัน แล้วต่างคนต่างถอน 50 → ควรเหลือ 0 แต่กลับเหลือ 50 |
| 7. Security problems ความปลอดภัย |
ให้ผู้ใช้เห็นข้อมูลบางส่วนแต่ไม่ใช่ทั้งหมดได้ยาก เช่น อยากให้ฝ่ายบุคคลเห็นเงินเดือน แต่อาจารย์ทั่วไปไม่เห็น |
ทำไมถึงควรใช้ DBMS (7 ข้อดี)
เขียน query สั้น ๆ แทนการเขียนโปรแกรมทั้งตัว
DBMS ให้มุมมองข้อมูลแบบนามธรรม โค้ดแอปไม่ต้องรู้ว่าเก็บลงดิสก์ยังไง
มีเทคนิคซับซ้อน (index, buffer, optimizer) ในการอ่านเขียนข้อมูลให้เร็ว
ผู้ใช้รู้สึกเหมือนใช้คนเดียว ทั้งที่มีคนอื่นใช้พร้อมกัน
ปกป้องผู้ใช้จากผลของระบบล่ม
รวมศูนย์การดูแลข้อมูล ปรับจูนการจัดเก็บได้ทีเดียว
บังคับ integrity constraint และควบคุมสิทธิ์ว่าใครเห็นอะไรได้
1.3Levels of Abstraction — 3 ระดับของการมองข้อมูล
DBMS ซ่อนความซับซ้อนไว้เป็นชั้น ๆ ทำให้แต่ละคนมองข้อมูลชุดเดียวกันในระดับที่เหมาะกับงานตัวเอง · 3 ระดับนี้ต้องท่องชื่อและหน้าที่ให้ได้ เรียงจากใกล้ผู้ใช้ที่สุด ลงไปหาใกล้ดิสก์ที่สุด:
| ระดับ | ใครมองระดับนี้ | เห็นอะไร |
|---|---|---|
| View level (external / user) |
ผู้ใช้ปลายทาง · แต่ละแผนก | เห็นเฉพาะส่วนที่เกี่ยวกับตัวเอง — เจ้าหน้าที่ทะเบียนเห็นชื่อกับเกรด แต่ไม่เห็นเงินเดือนอาจารย์ · ฐานข้อมูลเดียวมี view ได้หลายอัน อันละมุมมอง |
| Logical level (conceptual) |
ผู้ออกแบบฐานข้อมูล · โปรแกรมเมอร์ | เห็นตารางทั้งหมด คอลัมน์ ชนิดข้อมูล และความสัมพันธ์ระหว่างตาราง —
เช่น instructor(ID, name, dept_name, salary) · แอปพลิเคชันผูกกับระดับนี้ |
| Physical level (internal) |
DBMS · ผู้ดูแลระบบ | เห็นว่าข้อมูลถูกเก็บเป็นไฟล์อะไร เรียง block ยังไง ใช้ index แบบไหน บีบอัดหรือเปล่า — รายละเอียดที่ไม่มีใครนอกจาก DBMS ต้องรู้ |
คำว่า schema = “คำอธิบายโครงสร้าง” ของระดับนั้น ๆ →
physical schema = โครงสร้างระดับกายภาพ · logical schema = โครงสร้างระดับตรรกะ (ตารางและความสัมพันธ์)
สองคำนี้จะโผล่ทันทีในเรื่อง data independence ข้างล่าง
เช่น DBA เพิ่ม index หรือย้ายไฟล์ไปดิสก์ตัวใหม่เพื่อให้เร็วขึ้น — โปรแกรมที่เขียน SELECT * FROM instructor ไว้ ยังทำงานได้เหมือนเดิมไม่ต้องแก้แม้แต่บรรทัดเดียว เพราะแอปพลิเคชันผูกอยู่กับ logical schema ไม่ใช่ physical
โดยทั่วไป อินเทอร์เฟซระหว่างแต่ละชั้นต้องนิยามให้ชัด เพื่อให้การเปลี่ยนแปลงในส่วนหนึ่งไม่กระทบส่วนอื่น
Instances และ Schemas
เปรียบเทียบกับภาษาโปรแกรม: schema เหมือน type ส่วน instance เหมือน value ของตัวแปร
| คำศัพท์ | ความหมาย | เปลี่ยนบ่อยไหม |
|---|---|---|
| Logical schema | โครงสร้างเชิงตรรกะโดยรวมของฐานข้อมูล เช่น “ฐานข้อมูลนี้เก็บข้อมูลลูกค้า บัญชี และความสัมพันธ์ระหว่างทั้งสอง” | นาน ๆ ครั้ง |
| Physical schema | โครงสร้างเชิงกายภาพโดยรวม — เก็บลงดิสก์ยังไง | นาน ๆ ครั้ง |
| Instance | เนื้อหาจริงของฐานข้อมูล ณ เวลาหนึ่ง ๆ | ตลอดเวลา |
→ instance เปลี่ยน · schema ไม่เปลี่ยน เพราะโครงสร้างคอลัมน์ยังเหมือนเดิมทุกประการ มีแค่เนื้อข้อมูลที่เพิ่มขึ้น
1.4Data Models
Data model คือชุดของโครงสร้างเชิงแนวคิดระดับสูงที่ใช้อธิบายข้อมูล โดยซ่อนรายละเอียดการจัดเก็บระดับล่างเอาไว้ DBMS ให้ผู้ใช้นิยามข้อมูลที่จะเก็บในรูปของ data model
| Model | รายละเอียด |
|---|---|
| Relational | ที่ DBMS ส่วนใหญ่ในปัจจุบันใช้ · โครงสร้างหลักคือ relation = เซตของ record = ตารางที่มีแถวและคอลัมน์ |
| Entity-Relationship | ใช้สำหรับออกแบบฐานข้อมูลเป็นหลัก (เรียนในบทที่ 11–12) |
| Object-based | Object-oriented และ Object-relational |
| Semistructured | XML |
| NoSQL | Document · Key-Value · Column-Family · Graph |
| รุ่นเก่า | Network model · Hierarchical model |
ทุก relation มี schema ที่บอกว่ามีคอลัมน์อะไรบ้าง — ระบุชื่อ relation, ชื่อของแต่ละ field (หรือ attribute/column) และชนิดข้อมูลของแต่ละ field ส่วน integrity constraints คือเงื่อนไขที่ record ใน relation ต้องเป็นจริงเสมอ เช่น กำหนดว่านักศึกษาทุกคนต้องมีรหัสไม่ซ้ำ ความสามารถในการระบุความไม่ซ้ำแบบนี้ ช่วยให้เราอธิบายข้อมูลได้แม่นยำขึ้น
DDL และ DML
CREATE TABLE instructor (
ID CHAR(5),
name VARCHAR(20),
dept_name VARCHAR(20),
salary NUMERIC(8,2)
);
DDL compiler จะสร้าง table template เก็บไว้ใน data dictionary ซึ่งบรรจุ metadata (ข้อมูลเกี่ยวกับข้อมูล) ได้แก่ database schema · integrity constraints (เช่น primary key ที่บอกว่า ID ระบุอาจารย์ได้ไม่ซ้ำ) · authorization (ใครเข้าถึงอะไรได้)
SELECT name FROM instructor WHERE salary > 90000;
DML หรือที่เรียกว่า query language แบ่งเป็นสองกลุ่ม
- Pure — ใช้พิสูจน์คุณสมบัติเชิงทฤษฎีและใช้ในการ optimize ได้แก่ relational algebra, tuple relational calculus, domain relational calculus
- Commercial — ใช้ในระบบจริง SQL คือภาษาที่ใช้แพร่หลายที่สุด
SQL ไม่ใช่ภาษาที่ทำงานคำนวณซับซ้อนได้ครบทุกอย่าง จึงมักถูก ฝัง (embed) อยู่ในภาษาระดับสูงกว่า · แอปพลิเคชันเข้าถึงฐานข้อมูลผ่าน embedded SQL หรือ API อย่าง ODBC/JDBC ที่ส่ง SQL ไปให้ฐานข้อมูล
1.5ภายในเครื่องยนต์ของฐานข้อมูล
Database engine มี 3 ส่วนหลักที่ทำงานร่วมกัน
โมดูลที่เป็นตัวกลางระหว่างข้อมูลระดับล่างในดิสก์ กับโปรแกรม/query ที่ส่งเข้ามา
หน้าที่: ติดต่อกับ file manager ของ OS · จัดเก็บ/ดึง/อัปเดตข้อมูลอย่างมีประสิทธิภาพ
ประเด็นสำคัญ: storage access · file organization · indexing และ hashing
ทำงาน 3 ขั้น:
1. Parsing and translation — แปลง SQL เป็น relational algebra
2. Optimization — เลือกแผนที่ถูกที่สุด
3. Evaluation — ลงมือรัน
query เดียวกันเขียนได้หลายแบบที่สมมูลกัน และแต่ละ operation มีอัลกอริทึมให้เลือกหลายแบบ
ความต่างของต้นทุนระหว่างวิธีที่ดีกับแย่นั้นมหาศาล จึงต้องประมาณต้นทุนจากสถิติของ relation ที่ฐานข้อมูลเก็บไว้
Transaction = กลุ่มของ operation ที่ทำหน้าที่เชิงตรรกะหนึ่งอย่างให้สำเร็จ
Transaction-management component ทำให้ฐานข้อมูลอยู่ในสถานะที่ถูกต้องเสมอ แม้เกิด system failure (ไฟดับ OS crash) หรือ transaction failure
Concurrency-control manager ควบคุมการทำงานระหว่าง transaction ที่รันพร้อมกัน เพื่อรักษาความสอดคล้องของข้อมูล
หน้าที่ของ DBMS 4 กลุ่ม
- Data definition — สร้าง แก้ไข ลบนิยามที่กำหนดการจัดระเบียบข้อมูล
- Update — insert, modify, delete ข้อมูลจริง
- Retrieval — ให้ข้อมูลในรูปแบบที่ใช้ได้ทันที หรือส่งต่อให้แอปอื่นประมวลผล อาจคืนในรูปเดิมที่เก็บไว้ หรือรูปใหม่ที่ได้จากการแปลง/รวมข้อมูลเดิมก็ได้
- Administration — ลงทะเบียนและติดตามผู้ใช้ · บังคับความปลอดภัย · ติดตามประสิทธิภาพ · รักษา integrity · จัดการ concurrency control · กู้คืนข้อมูลที่เสียหายจากเหตุไม่คาดฝัน
สถาปัตยกรรมและประวัติ
สถาปัตยกรรมของระบบฐานข้อมูลได้รับอิทธิพลอย่างมากจากระบบคอมพิวเตอร์ที่มันรันอยู่: Centralized · Client-server · Parallel (multi-processor) · Distributed
Database server คือเครื่องเฉพาะทางที่เก็บฐานข้อมูลจริงและรันแต่ DBMS กับซอฟต์แวร์ที่เกี่ยวข้อง มักเป็นเครื่อง multiprocessor แรมเยอะ และใช้ RAID เป็น stable storage เพื่อกู้ข้อมูลได้เมื่อดิสก์ตัวใดตัวหนึ่งพัง
| ยุค | เหตุการณ์สำคัญ |
|---|---|
| 1950s–ต้น 1960s | ประมวลผลด้วยเทปแม่เหล็ก (เข้าถึงแบบลำดับเท่านั้น) · ป้อนข้อมูลด้วยบัตรเจาะรู |
| ปลาย 1960s–1970s | ฮาร์ดดิสก์ทำให้เข้าถึงข้อมูลโดยตรงได้ · network และ hierarchical model แพร่หลาย · Ted Codd นิยาม relational data model (ได้รางวัล ACM Turing Award) · IBM เริ่มต้นแบบ System R · UC Berkeley เริ่ม Ingres |
| 1980s | ต้นแบบกลายเป็นระบบเชิงพาณิชย์ · SQL กลายเป็นมาตรฐานอุตสาหกรรม · ระบบแบบขนานและกระจาย · object-oriented DB |
| 1990s | ระบบสนับสนุนการตัดสินใจและ data mining ขนาดใหญ่ · data warehouse ระดับหลายเทราไบต์ · e-commerce |
| ต้น 2000s | มาตรฐาน XML และ XQuery · การดูแลฐานข้อมูลอัตโนมัติ |
| 2000s เป็นต้นมา | NoSQL และ NewSQL |
key-value store และ document-oriented database ที่เร็ว ·
ไม่ต้องมี schema ตายตัว · เลี่ยง join ด้วยการเก็บข้อมูลแบบ denormalized · ออกแบบมาให้ scale แนวนอน
(join = การรวมข้อมูลจากสองตารางเข้าด้วยกันผ่าน attribute ร่วม — เรียนบทที่ 3 และ 6 ·
denormalized = ยอมเก็บข้อมูลซ้ำไว้ในที่เดียว จะได้ไม่ต้อง join แลกกับความซ้ำซ้อน)
ตัวอย่าง: MongoDB (document), Cassandra (column-family), Neo4j (graph), Redis (key-value)
เลือกใช้เมื่อ ต้องการ horizontal scalability · schema ยืดหยุ่น/เปลี่ยนบ่อย · ข้อมูลไร้โครงสร้างปริมาณมหาศาลที่ตารางแบบ relational จำลองได้ไม่ดี
RDBMS สมัยใหม่ที่พยายามรวมข้อดีสองฝั่ง: ความสามารถในการขยายและความยืดหยุ่นของ NoSQL
เข้ากับ ACID และความเข้ากันได้กับ SQL ของ RDBMS ดั้งเดิม
คุณสมบัติ: horizontal scalability · strong consistency · SQL compatibility · high performance
ตัวอย่าง: Google Spanner, CockroachDB
1.6Database Design เบื้องต้น
Database design คือกระบวนการออกแบบโครงสร้างโดยรวมของฐานข้อมูล แบ่งเป็น
- Logical design — ตัดสินใจเรื่อง schema · ต้องหา “ชุด relation schema ที่ดี” ประกอบด้วยการตัดสินใจ 2 แบบ:
- Business decision — เราควรบันทึก attribute อะไรบ้างลงฐานข้อมูล
- Computer Science decision — ควรมี relation schema อะไรบ้าง และควรกระจาย attribute ไปยัง schema ต่าง ๆ อย่างไร
- Physical design — ตัดสินใจเรื่องการวางข้อมูลจริงในระดับกายภาพ
เราต้องมีวิธีการที่รับประกันว่าทุก relation ในฐานข้อมูล “ดี” มีสองแนวทาง:
- Entity Relationship Model — จำลององค์กรเป็นชุดของ entity และ relationship แล้ววาดออกมาเป็น ER diagram (บทที่ 11–12)
- Normalization Theory — นิยามอย่างเป็นทางการว่าดีไซน์แบบไหนแย่ แล้วทดสอบหามัน (เรียนหลังมิดเทอม)
1.7สรุปบทนี้
จัดเก็บและจัดการข้อมูลจำนวนมากอย่างเป็นระเบียบและมีประสิทธิภาพ รองรับการดำเนินธุรกิจในทุกอุตสาหกรรม โดยจำลองโลกจริงผ่านความสัมพันธ์ระหว่าง entity
แก้ปัญหา redundancy, isolation และช่องโหว่ความปลอดภัย พร้อมให้ data independence, การเข้าถึงที่มีประสิทธิภาพ, การควบคุม concurrency และการกู้คืนอัตโนมัติ
physical, logical, view ทำให้แก้ระบบได้โดยไม่กระทบแอป รองรับ data independence และให้ผู้ใช้หลายกลุ่มมองข้อมูลชุดเดียวกันคนละแบบ
storage manager, query processor และ transaction manager รวมกันทำให้ได้ความสอดคล้องของข้อมูล ประสิทธิภาพที่ดี และการเข้าถึงพร้อมกันที่เชื่อถือได้