สรุป Database บทที่ 1–6 + Lab

Database System Environment

ผู้ใช้ไม่แตะข้อมูลตรง ๆ ทุกอย่างวิ่งผ่าน DBMS

4 ลักษณะเด่นของ Database Technology จุดสอบ

1. Self-describing catalog เก็บ meta-data (คำอธิบายฐานข้อมูล) ทำให้ DBMS ใช้กับหลายฐานข้อมูลได้
2. Program-data independence แก้โครงสร้างการเก็บได้โดยไม่ต้องแก้โปรแกรม
3. Data abstraction ใช้ data model ซ่อนรายละเอียดการเก็บ ให้ผู้ใช้เห็นภาพเชิงแนวคิด
4. Multiple views ผู้ใช้แต่ละกลุ่มเห็นมุมมองต่างกัน เช่น Transcript view กับ Prerequisite view ที่ได้จากตารางชุดเดียวกัน

ประโยชน์เพิ่มเติม 12 ข้อ

Redundancy แบบควบคุม vs ไม่ควบคุม

GRADE_REPORT ที่ใส่ StudentName ซ้ำไว้ (ข้อมูลจริง: เลข 17 = Smith)

Actors on the scene

• DBA ดูแลระบบ ติดตั้ง ปรับแต่งประสิทธิภาพ backup ความปลอดภัย
• Database designer วิเคราะห์ความต้องการข้อมูล ออกแบบตาราง ความสัมพันธ์ และกฎ
• End users แบ่งเป็น Casual, Naïve/parametric และ Sophisticated
• System analysts & application programmers

เมื่อไหร่ ไม่ ควรใช้ DBMS

• ต้นทุนเริ่มต้นสูง และมี overhead จาก security, concurrency, recovery, integrity
• ระบบเรียบง่าย นิยามชัด และไม่น่าจะเปลี่ยน
• มีข้อกำหนด real-time เข้มงวดจน overhead ของ DBMS รับไม่ได้
• ไม่มีผู้ใช้หลายคนเข้าถึงพร้อมกัน
• DBMS ไม่พอ เมื่อข้อมูลซับซ้อนเกินกว่าที่ model รองรับ หรือต้องการ operation พิเศษ

Data Models

Data model คือชุดแนวคิดที่ใช้อธิบาย โครงสร้าง และ constraints ของฐานข้อมูล ส่วน operations คือการ retrieve และ update

Pavement Improvement
├ Reconstruction
├ Maintenance
│  ├ Routine
│  ├ Corrective
│  └ Preventive
└ Rehabilitation

Joint Seal ─┐
            ├→ Asphalt
Patching ───┘   Sealant

Schema vs Instance จุดสอบ

Schema diagram แสดงแค่ชื่อตารางกับชื่อคอลัมน์ ในตารางจริง ชื่อตาราง = Entity, หัวคอลัมน์ = Attribute, แถว = Tuple (instance)

Three-Schema Architecture จุดสอบ

DBMS Languages

Data Dictionary เก็บ metadata ได้แก่ schema, storage definition, integrity constraints (domain, referential integrity, assertions) และ authorization

ตัวอย่าง Data Dictionary

Utilities และการจำแนก DBMS

Utilities ได้แก่ loading, backup, reorganize, report generation, performance monitoring, sorting และ compression
การจำแนก DBMS: ตาม model (Traditional = Relational/Network/Hierarchical, Emerging = OO/OR), single-user หรือ multi-user, centralized หรือ distributed

Main Phases of Database Design จุดสอบ

ขาข้างหนึ่งทำ Functional requirements ไปเป็น Transaction spec แล้วต่อเป็น Application program design ขั้น Conceptual ยัง DBMS-independent ส่วนตั้งแต่ Logical ลงไปเป็น DBMS-specific

สัญลักษณ์ ER (Chen notation) จุดสอบ

ประเภท Attribute

Key อาจเป็น composite เช่น VehicleTag = (Number, State) และ entity หนึ่งมีได้หลาย key เช่น CAR มีทั้ง VIN และ VehicleTag ส่วน {PreviousDegrees(College, Year, Degree)} คือ composite ที่เป็น multivalued ด้วย
Entity type = กลุ่ม entity ที่มี attribute ชุดเดียวกัน ส่วน Entity set = entity ทั้งหมดที่มีอยู่จริง ณ ตอนนั้น

Degree ของ Relationship

Roles คือป้ายบนเส้นที่บอกบทบาท เช่น supervisor/supervisee หรือ manager/worker จะใส่หรือไม่ใส่ก็ได้ แต่จำเป็นมากใน recursive
Relationship มี attribute ได้ เช่น depositor(access_date), Works_on(Hours), ร้านค้า–ใช้–บัตรเครดิต(จำนวนเงิน, วันที่)

Cardinality ratio ดูจาก mapping จริง จุดสอบ

Cardinality = จำนวน สูงสุด ที่ entity หนึ่งเข้าร่วม relationship ได้ ส่วน Participation = จำนวน ต่ำสุด ถ้า "ทุกตัวต้องมี" เป็น total (เส้นคู่ หรือเรียกว่า existence dependency) ถ้า "บางตัว" เป็น partial

Weak Entity

• ไม่มี key เป็นของตัวเอง
• ระบุตัวตนด้วย partial key + PK ของ owner
• เชื่อมกับ owner ผ่าน identifying relationship (double diamond) แบบ 1:N และฝั่ง weak เป็น total
• เช่น DEPENDENT ของ EMPLOYEE, BANK-BRANCH ของ BANK
• ใน ER จะไม่เขียน PK ของ owner ลงใน weak entity เพราะมันอยู่ใน relationship อยู่แล้ว

วาด ER 6 ขั้น จุดสอบ

ตัวอย่างการอ่านจากสไลด์: "อย่างน้อย ทุก Project ต้องถูกควบคุมได้ มากสุดเพียง 1 Department" ได้ PROJECT เป็น total และ cardinality N:1

COMPANY ER Diagram (ตัวอย่างหลักที่ใช้ทั้งบท 3 และบท 4)

Requirement: แผนกมีผู้จัดการ 1 คน (เก็บ start date) และมีได้หลาย location แผนกควบคุมหลายโปรเจกต์ พนักงานสังกัด 1 แผนกแต่ทำได้หลายโปรเจกต์ (เก็บชั่วโมง) มี supervisor และอาจมี dependents หลายคน

ผลลัพธ์สุดท้ายของ COMPANY จุดสอบ

Number_of_employees เป็น derived จึงไม่มีในตารางใดเลย เพราะคำนวณด้วย COUNT ได้

Guidelines 4 ข้อของตารางที่ดี

1. ความหมายชัด หนึ่งแถวแทน 1 entity หรือ 1 เหตุการณ์ ไม่เอาหลาย entity มาปนในตารางเดียว และอ้างถึงกันด้วย FK เท่านั้น
2. ไม่มี anomaly ทั้ง insert, delete และ update
3. NULL น้อยที่สุด NULL เกิดได้ 3 แบบคือ not applicable, unknown และ unavailable ถ้าคอลัมน์ไหน NULL เยอะให้แยกออกเป็นตารางใหม่
4. ไม่มี spurious tuples แยกตารางแล้วต้อง join กลับได้ข้อมูลเดิม (lossless) ห้ามเสียคุณสมบัตินี้ ส่วน dependency preservation ยอมเสียได้บางกรณี

ตัวอย่างตารางที่ไม่ดี: ใส่ Phone No หลายเบอร์ในช่องเดียว และเอาชื่อแผนกมาปนกับข้อมูลพนักงาน

Anomalies จุดสอบ

EMP_PROJ(Ssn, Pnumber, Hours, Ename, Pname, Plocation)

Anomaly ไม่ได้เกิดจาก SQL แต่เกิดจากการออกแบบตาราง

Functional Dependency

X → Y อ่านว่า "X กำหนด Y" ถ้า t1[X] = t2[X] แล้วต้องได้ t1[Y] = t2[Y] เสมอ FD มาจาก business rule ของโลกจริง ไม่ใช่ดูจากข้อมูลไม่กี่แถว และถ้า K เป็น key แล้ว K → ทุก attribute

F⁺ = FD ทุกตัวที่อนุมานได้จาก F ส่วน X⁺ = attribute ทุกตัวที่ X กำหนดได้ ถ้า X⁺ ครอบคลุมทุกคอลัมน์ X เป็น superkey ถ้าตัดอะไรออกไม่ได้อีกแล้ว X คือ candidate key
Minimal cover: RHS มีตัวเดียว, ไม่มี FD ซ้ำซ้อน, LHS ไม่มีตัวเกิน

ลองหา Closure แบบฝึก 2

R(A,B,C,D,E), F = {A→B, B→C, AC→D, D→E}

A เป็น superkey และเป็น candidate key ส่วน AC ก็เป็น superkey แต่ไม่ใช่ candidate key เพราะ C เกินมา

Keys และ Prime attribute

บันได Normal Form จุดสอบ

งานจริงทำถึง 3NF หรือ BCNF ก็พอ ส่วน Denormalization คือการรวมตารางกลับเพื่อประสิทธิภาพ แลกกับการยอมคุมความซ้ำซ้อนเอง

→ 2NF

EMP_PROJ(SSN, PNumber, EName, Hours, PName, PLocation)

• SSN → EName (partial)
• PNumber → PName, PLocation (partial)
• {SSN, PNumber} → Hours (full)

แยกเป็น

→ 3NF

EMP_DEPT(SSN, EName, BDate, Address, DNumber, DName, Dmgr_ssn)

• SSN → …, DNumber
• DNumber → DName, Dmgr_ssn ทำให้เกิด transitive

แยกเป็น

→ BCNF

ลงทะเบียน(StudentID, CourseID, Advisor)

• {StudentID, CourseID} → Advisor
• Advisor → CourseID แต่ Advisor ไม่ใช่ superkey

แยกเป็น

TEACH(Student, Course, Instructor) ก็เป็นแบบเดียวกัน คือผ่าน 3NF แต่ไม่ผ่าน BCNF

ทดสอบ Lossless Join ด้วย Matrix (Chase)

แถว = ตารางย่อย, คอลัมน์ = attribute ถ้าตารางย่อยมี attribute นั้นใส่ a ถ้าไม่มีใส่ b แล้วไล่ใช้ FD ทีละตัว แถวไหนที่ LHS เท่ากันให้ทำ RHS ให้เท่ากัน ถ้าสุดท้ายมีแถวที่เป็น a ครบทุกช่อง แปลว่า Lossless

R1 = EMP(SSN, ENAME), R2 = PROJECT(PNUMBER, PNAME, PLOCATION), R3 = WORKS_ON(SSN, PNUMBER, HOURS)

SSN→ENAME (R1 กับ R3 มี SSN เท่ากัน) ทำให้ R3.ENAME เป็น a2 ส่วน PNUMBER→PNAME, PLOC (R2 กับ R3) ทำให้ R3 ได้ a4 และ a5 ผลคือ R3 เป็น a ครบทุกช่อง จึง Lossless
ถ้าแยกเป็น EMP_LOCS(ENAME, PLOCATION) กับ EMP_PROJ1(…) matrix จะไม่เปลี่ยนเลย จึงเป็น Lossy และเกิด spurious tuples

ทางลัด: แยกเป็น 2 ตาราง

{R1, R2} เป็น lossless เมื่อ

(R1 ∩ R2) → (R1 − R2)
หรือ
(R1 ∩ R2) → (R2 − R1)

หมายถึงคอลัมน์ที่ใช้ร่วมกันต้องเป็น key ของตารางใดตารางหนึ่ง
แบบฝึก 4: R(A,B,C), F={A→B} แยกเป็น R1(A,B), R2(A,C) จะได้ R1∩R2 = A และ A→B = R1−R2 จึงเป็น Lossless

คุณสมบัติที่ต้องเช็กหลังแยกตาราง

Attribute preservation, Dependency preservation และ Lossless join

Dangling tuple

แถวที่หาคู่ไม่เจอจะหายไปจาก INNER/NATURAL JOIN ถ้าอยากเก็บไว้ต้องใช้ OUTER JOIN (LEFT/RIGHT/FULL) ซึ่งช่องที่ไม่มีคู่จะเป็น NULL

4NF: Multivalued Dependency

พื้นฐาน

• Closure property ผลลัพธ์ของทุก operator ยังเป็น relation จึงซ้อนกันได้
• Degree = จำนวน attribute, Cardinality = จำนวน tuple
• Relation ไม่มีลำดับแถว ไม่มีลำดับคอลัมน์ และไม่มี tuple ซ้ำ
• แต่ละ tuple คือประโยคที่เป็นจริงของ predicate (Intension = รูปแบบของประโยค, Extension = ชุดประโยคที่จริง ณ ตอนนั้น)
• Closed World Assumption ถ้า tuple ไม่อยู่ในตาราง แปลว่าฐานข้อมูลไม่รับรองว่าจริง

ข้อมูลตัวอย่างที่ใช้ทั้งบท

COURSE มี C1 Database, C2 HCI, C3 Op Systems และ C4 Programming

SUMMARIZE BY vs PER จุดสอบ

คุณสมบัติของ JOIN

r ⋈ r = r ถ้า attribute เหมือนกันทั้งหมด JOIN จะกลายเป็น ∩ ถ้าไม่มี attribute ร่วมเลยจะกลายเป็น × (TIMES) และ JOIN เป็น commutative กับ associative ทำให้ DBMS สลับลำดับเพื่อ optimize ได้

RA ↔ Tutorial D ↔ SQL

SQL ยอมให้มีแถวซ้ำได้ แต่ relation ในทางทฤษฎีเป็นเซต จึงไม่มีแถวซ้ำ

สูตรแก้โจทย์ RA: เลือกแถว → เชื่อม → คำนวณ → เลือกคอลัมน์

โจทย์: หารหัส ชื่อ และคะแนนของคนที่สอบ C1 ได้ตั้งแต่ 50 ขึ้นไป

π StudentId, Name, Mark ( IS_CALLED ⋈ σ CourseId='C1' ∧ Mark≥50 (EXAM_MARK) )

ขั้นตอนตามสไลด์: (1) หาตารางที่มีคอลัมน์ที่ต้องใช้ (2) σ (3) ⋈ (4) EXTEND หรือ aggregate (5) π (6) ตรวจ heading ก่อนทำ ∪ หรือ − แล้วเขียนจากวงเล็บในสุดออกมา

Constraint เขียนแบบ RA ได้ เช่น IS_EMPTY(EXAM_MARK WHERE Mark < 0 OR Mark > 100) ส่วน KEY ใช้กันค่าซ้ำ และ FOREIGN KEY ใช้รักษาการอ้างอิงให้ถูกต้อง

เปิด phpMyAdmin ผ่าน XAMPP (macOS)

phpMyAdmin เป็นแค่ หน้าจอ (interface) สำหรับ MySQL/MariaDB ไม่ใช่ตัวฐานข้อมูล เข้าได้ที่ http://localhost/phpmyadmin

ช่องในฟอร์มสร้างคอลัมน์

หน้า Structure ใช้ Change แก้คอลัมน์, Drop ลบ และ Add column after … เพิ่มคอลัมน์ต่อท้ายคอลัมน์ที่เลือก

DDL ที่ใช้ในแท็บ SQL

CREATE DATABASE IF NOT EXISTS BonusSuki
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_general_ci;

CREATE TABLE Member_test(
  member_id INT NOT NULL AUTO_INCREMENT,
  full_name VARCHAR(100) NOT NULL,
  phone VARCHAR(20) NOT NULL,
  joined_at DATE NOT NULL,
  PRIMARY KEY (member_id)
) ENGINE=InnoDB;

ALTER TABLE member_test ADD COLUMN email VARCHAR(150) NULL;
ALTER TABLE member_test MODIFY COLUMN phone VARCHAR(25) NOT NULL;
ALTER TABLE member_test RENAME COLUMN full_name TO member_name;
ALTER TABLE member_test DROP COLUMN email;
DROP DATABASE IF EXISTS BonusSuki;

ลำดับ clause ของ SELECT จุดสอบ

INSERT 7 แบบ

INSERT INTO Products (ProductName, Price, Stock, Category)
VALUES (N'ปากกา', 15.00, 100, N'เครื่องเขียน');      -- 1 แถว
VALUES (…), (…), (…);                                   -- หลายแถว
(ProductName, Price) VALUES (N'แฟ้ม', 25.00);           -- บางคอลัมน์
VALUES (N'ไม้บรรทัด', 12.00, DEFAULT);                  -- ใช้ค่า default
VALUES (N'สินค้าใหม่', 99.00, 5, NULL);                 -- NULL ไม่ใส่ ''
VALUES (N'ชุดปากกา', 15.00 * 3, 20);                    -- คำนวณ → 45.00
INSERT INTO BudgetProducts (ProductName, Price)
SELECT ProductName, Price FROM Products WHERE Price < 20;

เช็ก 4 ข้อ: (1) ลำดับและจำนวนค่าต้องตรงกับคอลัมน์ (2) type, NOT NULL และ UNIQUE (3) รันซ้ำจะได้แถวซ้ำ (4) SELECT ตรวจหลังเพิ่ม
ถ้าไม่ระบุ Stock จะได้ 0, Category ได้ NULL, CreatedAt ได้เวลาปัจจุบัน และ ID รันเลขเอง

UPDATE / DELETE ⚠

UPDATE Products SET Price = 18.00 WHERE ProductID = 1;
SET Stock = Stock - 3 WHERE ProductID = 1 AND Stock >= 3;
SET Price = ROUND(Price * 0.90, 2) WHERE Category='เครื่องเขียน' AND Price >= 10;
SET Price = CASE ProductID WHEN 1 THEN 18 WHEN 2 THEN 12 ELSE Price END
UPDATE Products p JOIN PriceUpdates u ON p.ProductID=u.ProductID
  SET p.Price = u.NewPrice;

DELETE FROM Products WHERE ProductID IN (2, 3);
WHERE Price BETWEEN 8 AND 10;           -- รวมค่าขอบ
WHERE Price <= 15 ORDER BY ProductID LIMIT 1;
DELETE u FROM PriceUpdates u JOIN Products p … WHERE p.Stock <= 40;
DELETE FROM PriceUpdates WHERE NOT EXISTS
  (SELECT 1 FROM Products WHERE Products.ProductID = PriceUpdates.ProductID);

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

คิดแบบ System Analyst

ปัญหา 3 ข้อในหน้าร้าน

1. ทอนเงินผิด ยอด 317.79 รับเงิน 500 ระบบทอน 182.25 ทั้งที่ต้องเป็น 182.21 จึงต้องใช้ Decimal ทศนิยม 2 ตำแหน่ง
2. ใช้โปรผิดเงื่อนไข ลูกค้ามา 2 คนแต่กดโปร "มา 4 จ่าย 3" ได้ จึงต้องบังคับใส่ headcount แล้ว block โปรที่ไม่เข้าเงื่อนไข
3. เปิดโต๊ะซ้อน โต๊ะที่กำลังใช้อยู่ต้องถูก hard lock สถานะมี 3 สี: เขียว = ว่าง, แดง = กำลังทาน, เหลือง = รอเช็คบิล

โมดูลใน TOR

โต๊ะ · Billing (ซุปพิเศษ +49/หม้อ, เงินสด และ Dynamic QR มาตรฐาน EMVCo) · Promotion engine (กฎ stacking) · CRM (บังคับแค่ชื่อกับเบอร์ 10 หลักที่ห้ามซ้ำ แต้มคิดหลังหักส่วนลดเมื่อปิดบิล) · Inventory (BOM ตัดสต็อกตามสูตร, COGS แบบ FIFO หรือ Moving Average, ของเสีย, re-order point) · HR/Payroll (Full-time หรือ Part-time, OT 1.5 เท่า และ 2 เท่าในวันหยุด, ต้อง approve ก่อนจ่าย) · Expense · P&L

Revenue − COGS = Gross Profit
Gross Profit − OPEX = Net Profit

NFR: ACID, audit log (void bill, เปิดลิ้นชักโดยไม่มีการขาย), offline + sync, RBAC 3 ระดับ (ผู้จัดการ ห้ามเห็นเงินเดือน คนอื่น), PDPA และ password hashing

ER สุกี้โบนัส (Lab drawio)

* ในรูปขีดเส้นใต้ PK ของ Product เป็น Table_ID ซึ่งน่าจะตั้งชื่อผิด และควรเป็น Product_ID