Advanced Relational Concepts & Schema Design

4.1Naming Convention — snake_case vs CamelCase

อาจารย์ตั้งกติกาของวิชานี้ไว้ชัดเจนว่าให้ใช้ snake_case พร้อมเหตุผลที่ตอบได้ในข้อสอบแนวอธิบาย

4.2Composite Attribute

Composite attribute คือ attribute ที่มีส่วนประกอบย่อยซึ่งมีความหมายในตัวเอง เช่น ที่อยู่ประกอบด้วยถนน เมือง รหัสไปรษณีย์ และประเทศ ซึ่งแต่ละส่วนอาจถูกค้นหาหรือเรียงลำดับแยกกันในแอปพลิเคชันจริง

วิธีจัดเก็บส่งผลโดยตรงต่อความสามารถในการ query — ถ้าเก็บ "123 Main St, Bangkok, 10110" เป็นช่องเดียว เราจะค้นตามเมืองไม่ได้ และเรียงตามรหัสไปรษณีย์ไม่ได้อย่างมีประสิทธิภาพ

4.3Multi-valued Attribute

Multi-valued attribute ละเมิด First Normal Form — relational model บังคับว่าค่าต้องเป็น atomic การที่พนักงานหนึ่งคนมีเบอร์โทรได้หลายเบอร์จึงเป็นโจทย์ออกแบบพื้นฐานที่ต้องแก้ให้ถูก

ทางแก้ที่ถูกคือ normalization — สร้างตารางแยกที่มี employee_id และ phone_number ซึ่งรองรับเบอร์โทรได้ไม่จำกัดต่อพนักงานหนึ่งคน

และตารางแบบนี้มักมี attribute เพิ่มเติมนอกเหนือจากความสัมพันธ์พื้นฐาน เช่น phone_type (mobile/office/home) หรือธง is_primary เพื่อรองรับความต้องการทางธุรกิจให้ครบ

4.4Integrity Constraint ที่ซับซ้อนขึ้น

เป้าหมายคือการบังคับกฎทางธุรกิจที่ระดับฐานข้อมูล ไม่ใช่ฝากไว้ในโค้ดแอปพลิเคชัน

• Domain constraint จำกัดค่าที่ยอมรับได้ เช่น เกรดต้องอยู่ใน ('A','B','C','D','F') หรืออายุนักศึกษาต้องอยู่ระหว่าง 16–100 ป้องกันการป้อนข้อมูลผิด
  ขอบเขตต้องมาจากกฎธุรกิจจริง ไม่ใช่ตัวเลขสวย ๆ — 16 = อายุขั้นต่ำที่เป็นนักศึกษาได้ · 100 = เกินนี้แทบแน่นอนว่าพิมพ์ผิด
• CHECK constraint ใช้ตรรกะทางธุรกิจ เช่น วันสิ้นสุดต้องมาหลังวันเริ่มต้น เงินเดือนต้องเป็นบวก หรือส่วนลดต้องอยู่ในช่วงที่สมเหตุสมผล

CREATE TABLE students (
    student_id      INT PRIMARY KEY,
    first_name      VARCHAR(50) NOT NULL,
    last_name       VARCHAR(50) NOT NULL,
    student_age     INT CHECK (student_age >= 16 AND student_age <= 100),
    current_grade   ENUM('A', 'B', 'C', 'D', 'F'),
    grade_point_average DECIMAL(3,2)
        CHECK (grade_point_average >= 0.0 AND grade_point_average <= 4.0),
    email_address   VARCHAR(100) CHECK (email_address LIKE '%@%.%'),
    enrollment_date DATE NOT NULL,
    graduation_date DATE,
    CONSTRAINT check_graduation_after_enrollment
        CHECK (graduation_date IS NULL OR graduation_date > enrollment_date)
);

4.5หลักการออกแบบ Schema ที่ดี

การเลือกชนิดข้อมูล

Design pattern ที่เจอบ่อย

ออกแบบเผื่อประสิทธิภาพตั้งแต่ต้น

• วางแผน index ตั้งแต่ตอนออกแบบ — ระบุว่าคอลัมน์ไหนจะถูกค้น เรียง หรือ join บ่อย (index = โครงสร้างค้นหาที่สร้างไว้ล่วงหน้า ทำให้ค้นเร็วขึ้นมากแต่ทำให้ INSERT/UPDATE ช้าลง — บทที่ 10)
• วิเคราะห์รูปแบบ query — ระบบอ่านหนักหรือเขียนหนัก มีผลต่อการตัดสินใจเรื่อง normalization และการออกแบบเชิงกายภาพ
• Denormalization มีข้อแลกเปลี่ยน — จงใจเก็บข้อมูลซ้ำไว้ในตารางเดียว (เช่น เก็บ customer_name ไว้ในตาราง orders ด้วย) เพื่อจะได้ไม่ต้อง join ตอนอ่าน · เร็วขึ้นก็จริง แต่แลกกับต้องคอยอัปเดตหลายที่ให้ตรงกัน ซึ่งคือปัญหาที่ normalization แก้ไว้ตั้งแต่แรก
• ชนิดข้อมูลที่พอดี ลดพื้นที่จัดเก็บและทำให้ memory cache ทำงานได้ผลดีขึ้น

4.6แบบฝึกหัดในคาบ — KKU Bookstore

โจทย์: นักพัฒนามือใหม่ออกแบบฐานข้อมูลร้านหนังสือ KKU ไว้แบบนี้ ให้หาข้อบกพร่อง 6 ข้อ แล้วบอกว่าเป็นปัญหาเรื่องอะไร

CREATE TABLE Customer (
    ID INT PRIMARY KEY,
    FullName VARCHAR(100),           -- "นายสมชาย ใจดี"
    CompleteAddress TEXT,            -- "123 ถ.มิตรภาพ, ขอนแก่น, 40002"
    PhoneNumbers VARCHAR(200),       -- "081-111-2222,043-333-444"
    MemberStatus VARCHAR(50),        -- พิมพ์อะไรลงไปก็ได้
    Age INT,                         -- ตอนนี้มีแถวที่ Age = 250
    RegDate VARCHAR(20)              -- "22/6/2026" เก็บเป็นข้อความ
);

CREATE TABLE customers (
    customer_id     INT PRIMARY KEY,
    name_title      VARCHAR(10),
    first_name      VARCHAR(50) NOT NULL,
    last_name       VARCHAR(50) NOT NULL,
    street_address  VARCHAR(200),
    city            VARCHAR(50),
    postal_code     VARCHAR(10),
    age             INT  CHECK (age >= 16 AND age <= 100),
    member_status   VARCHAR(10) NOT NULL DEFAULT 'regular'
                    CHECK (member_status IN ('regular','silver','gold')),
    registration_date DATE NOT NULL
);

CREATE TABLE customer_phone_numbers (
    phone_id     INT PRIMARY KEY,
    customer_id  INT NOT NULL,
    phone_number VARCHAR(20) NOT NULL,
    phone_type   VARCHAR(10) CHECK (phone_type IN ('mobile','home','office')),
    is_primary   BOOLEAN DEFAULT FALSE,
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

-- 1. แถวที่ถูกต้อง → สำเร็จ
INSERT INTO customers VALUES
 (1,'นาย','สมชาย','ใจดี','123 ถ.มิตรภาพ','ขอนแก่น','40002',
  22,'gold','2026-06-22');

-- 2. age = 250 → ต้องล้มเหลว
INSERT INTO customers VALUES
 (2,'นาง','มาลี','สุขใจ','1 ถ.ศรีจันทร์','ขอนแก่น','40000',
  250,'regular','2026-06-22');
-- CHECK constraint failed: age

-- 3. member_status = 'platinum' → ต้องล้มเหลว
INSERT INTO customers VALUES
 (3,'นาย','กฤต','ตั้งใจ','9 ถ.กลางเมือง','ขอนแก่น','40000',
  30,'platinum','2026-06-22');
-- CHECK constraint failed: member_status

4.7สรุปบทนี้

• snake_case คือมาตรฐานวิชาชีพ — เข้ากันได้ทุกระบบและไม่มีปัญหา case sensitivity
• แตก composite attribute เมื่อส่วนย่อยถูก query แยกกัน — ที่อยู่ ชื่อ ควรแยกเมื่อต้องค้นหรือเรียงทีละส่วน
• วิธีจัดเก็บกำหนดความสามารถในการ query โดยตรง — ช่องเดียวจำกัดตัวเลือกการค้นหา คอลัมน์แยกเปิดให้ query ได้ยืดหยุ่น
• เลี่ยงฝันร้ายในการดูแลรักษา — อย่าใช้ค่าคั่นจุลภาคหรือคอลัมน์จำกัดจำนวนแบบ phone_1, phone_2, phone_3
• ใช้ domain และ check constraint ให้เป็นประโยชน์ — กันอายุ เกรด วันที่ที่ไม่ถูกต้อง และรักษาความสัมพันธ์เชิงตรรกะทางธุรกิจ