ส่วนที่ 2 Database Design by g4509244

VIEWS: 598 PAGES: 103

									DBMS       Database Management System




       ส่วนที่ 2 Database Design

 บทที่ 4 โมเดลจาลองความสัมพันธ์ระหว่างข้อมูล (ER-Diagram)
 บทที่ 5 รูปแบบที่เป็นบรรทัดฐาน (Normalization)
                                                                         4.2


วงจรชีวิตการพัฒนาฐานข้อมูล
Database Life Cycle : DBLC
                 วิเคราะห์ความต้องการ
                     Initial Study
    บารุงรักษา                               ออกแบบฐานข้อมูล

   Maintenance                                Database Design

    ใช้งานจริง                                สร้างฐานข้อมูล

    Operation                              Implement and Loading
                  ทดสอบระบบฐานข้อมูล
                  Testing and Evaluation
                                            Database Management System
                                                                     4.3


   Database Life Cycle :DBLC
 Database  Initial Study :วิเคราะห์ความต้องการของผู้ใช้
 Data Design :ออกแบบฐานข้อมูล (Data Driven, Joint
  Data and Function-driven)
 Implementation and Loading :สร้างเป็นฐานข้อมูล
 Testing and Evaluation :ทดสอบฐานข้อมูลที่สร้าง
 Operation :ใช้งานฐานข้อมูล
 Maintenance and Evaluation :บารุงรักษาฐานข้อมูล



                                        Database Management System
   บทที่ 4
โมเดลจาลองความสัมพันธ์ระหว่างข้อมูล
               (ER-Diagram)
                                                               4.5


Outline

 ประโยชน์ของการออกแบบฐานข้อมูล

 ขั้นตอนในการออกแบบฐานข้อมูล

 ER-Diagram

 Map   ER to Relation



                                  Database Management System
                                                                          4.6


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




                                             Database Management System
                                                                          4.7


    ขั้นตอนในการออกแบบฐานข้อมูล
                  1. Requirement Analysis

(ER-Diagram)       2. Conceptual Design      Database Designer



                     3. Logical Design
(Normalization)    4. Schema Refinement
                     5. Physical Design            DBA

                     6. Security Design
                                            7. Maintenance
                                             Database Management System
                                                                    4.8

        1. สารวจความต้องการใช้งาน
        (Requirement Analysis)
 เป็นขั้นตอนแรกที่สาคัญมากต่อระบบฐานข้อมูล
 จะรู้ความต้องการของผู้ใช้งานและระบบได้อย่างไร




                                       Database Management System
                                                                        4.9


จะรู้ความต้องการของผู้ใช้งานได้อย่างไร

 ศึกษาเอกสารที่ใช้ในระบบงานนั้นๆ
 การใช้แบบสอบถาม
 การพูดคุยกับผู้ใช้โดยตรง
 ข้อมูลที่เราจาเป็นต้องเก็บรวบรวมเพื่อนาไปใช้ในการออกแบบ
  ระบบฐานข้อมูล ประกอบด้วย
   – ข้อมูลแต่ละตัวที่จาเป็นต้องใช้ในระบบงาน(Entity)
   – รายละเอียดของข้อมูลนั้น(Attribute)
   – ความสัมพันธ์ระหว่างข้อมูลทั้งหมด(Relationship)

                                           Database Management System
                                                                         4.10


ตั้งคาถาม ถามระบบ

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




                                                Database Management System
                                                                   4.11

2. ออกแบบฐานข้อมูลระดับแนวคิด
(Conceptual Design)
 หลังจากได้ความต้องการแล้ว ก็จะทาการออกแบบเชิง
  แนวคิด(conceptual design)
 โดยใช้ตัวแบบข้อมูลเชิงแนวคิด (conceptual data
  model) เช่น ER-Model ในการออกแบบเค้าร่างเชิง
  แนวคิด
 ผู้ออกแบบฐานข้อมูลจะต้อง
       กาหนดเอนติติ้และแอตทริบิวต์
       กาหนดคอนสเตรนต์
       กาหนดความสัมพันธ์
 หลังจากได้เค้าร่างเชิงแนวคิดแล้ว ผู้วิเคราะห์ระบบจะ
  นาเค้าร่างเชิงแนวคิดไปยืนยันกับผู้ใช้ถึงความต้องการ
  ทั้งหมด เพื่อให้แน่ใจว่าไม่ได้หลงลืมความต้องการหรือ
  ข้อมูลบางส่วนไป                         Database Management System
                                                           4.12

3. ออกแบบฐานข้อมูลระดับตรรกะ
(Logical Design)
 เมื่อได้ออกแบบเค้าร่างเชิงแนวคิดที่ได้รับการ
  ยืนยันจากผู้ใช้แล้ว ก็จะจัดทาการออกแบบเชิง
  ตรรกะ (logical design) เพื่อออกแบบเค้าร่าง
  เชิงตรรกะ(logical schema) ให้เป็นไปตามตัว
  แบบข้อมูลของระบบการจัดการฐานข้อมูล
 เป็นขั้นตอนการแปลง ER-Diagram ไปเป็นตารางตาม
  Relational data Model


                                  Database Management System
                                                                     4.13

 4. ปรับโครงสร้างข้อมูล
 (Schema Refinement)
 ตารางที่ได้จากการออกแบบฐานข้อมูลในระดับ     Logical ยัง
  ไม่ใช่ตารางที่เหมาะสาหรับนาไปเก็บข้อมูลจริง เนื่องจากอาจทาให้
  เกิดความซ้าซ้อนของข้อมูล และปัญหาต่างๆ เช่น ปัญหาการเพิ่ม
  ข้อมูล(Insert Anomaly)
 ขั้นตอนนี้ เป็นการปรับโครงสร้างตาราง โดยการทา
  Normalization ซึ่งจะทาให้ได้จานวนตารางมากขึ้นกว่าเดิม
  แต่ปัญหาต่างๆจะถูกกาจัดออกไป


                                            Database Management System
                                                                         4.14

5. ออกแบบฐานข้อมูลระดับกายภาพ
(Physical Design)
 เป็นหน้าที่   DBA เพื่อให้ระบบฐานข้อมูลเกิดประสิทธิภาพมาก
  ที่สุด
 การออกแบบในระดับนี้ เกี่ยวข้องกับการสร้างอินเด็กซ์
  (Index)และการเลือกโครงสร้างข้อมูลระดับภายใน
  (Internal View) เพื่อให้สอดคล้องกับลักษณะการใช้งาน
                 ้
  ข้อมูลที่เกิดขึนบ่อยๆ เช่น สร้างอินเด็กซ์ที่คอลัมน์ซึ่งมักถูกใช้
                   ่
  กาหนดเป็นเงือนไขในการดึงข้อมูล


                                                Database Management System
                                                               4.15

6. ควบคุมการนาไปใช้
(Security Design)
                                   DBA จะ
 เป็นการกาหนดสิทธิในการใช้งานข้อมูลที่
  กาหนดขึ้นตามความเหมาะสมและความต้องการของ
  ผู้ใช้งาน




                                      Database Management System
                                                                 4.16

7. การบารุงรักษาระบบ
(Maintenance Database System)
 เป็นขั้นตอนที่มีความสาคัญกับระบบมาก
 เมื่อระบบทางานช้าลง ต้องตรวจสอบ
 เมื่อพบข้อผิดพลาดจากข้อมูลที่เก็บ
 เมื่อความต้องการของระบบหรือผู้ใช้เปลี่ยนไป
 เมื่อนโยบายขององค์กรเปลี่ยนไป
 การสารองข้อมูล เมื่อไร backup / การกู้คืนข้อมูล
 การป้องกันไวรัสทุกชนิด โจรกรรมข้อมูล



                                        Database Management System
                                                                    4.17


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



                                           Database Management System
                                                                  4.18


  Entity Relationship Data Model
 โดย ดร.ปีเตอร์ เชนน์ ราวปี ค.ศ. 1976
 ER data model จัดเป็น conceptual data model ที่ใช้ออกแบบ
  ฐานข้อมูลได้อย่างอิสระ ไม่ต้องคานึงถึงว่าจะใช้ DBMS ชนิด
  ไหน ยี่ห้ออะไร ด้วยคุณสมบัติเด่นนี้ทาให้ ER-model เป็นที่
  นิยมใข้งานกันมากในการวิเคราะห์และออกแบบฐานข้อมูล
 ผลการออกแบบด้วย ER-model สามารถแสดงด้วยรูปภาพ หรือ
  ER-Diagram
 นักวิเคราะห์และออกแบบสามารถใช้ ER-Diagram เสมือนเป็น
  เครื่องมือในการอธิบายองค์ประกอบ(Basic Structure) และ
  ข้อกาหนดเงื่อนไข(Integrity constraint) ของฐานข้อมูล
                                         Database Management System
                                                             4.19


Entity Relationship Data Model(ต่อ)
นา ER-Diagram ไปใช้ทบทวนยืนยันความเข้าใจที่
 ถูกต้องกับ user ของระบบงานได้ เพราะ ER-Diagram
 ประกอบด้วยสัญลักษณ์ที่สื่อความหมายเข้าใจได้ง่าย
เมื่อได้ ER-Diagram ที่ถูกต้องเหมาะสมกับระบบงานแล้ว
 และทราบแล้วว่าจะใช้ DBMS ชนิดใด จึงจะทาการแปลง
 (Mapping) ให้ได้เป็น Logical schema ที่ตรงกับ DBMS


                                    Database Management System
                                                      4.20


Basic Structure
องค์ประกอบของโครงสร้างข้อมูล โดย ER-
 model ประกอบด้วยโครงสร้างดังนี้
  Entity

  Relationship

  Attribute

  Primary   Key

                             Database Management System
                                                                 4.21



Entity
        ี้
 เอนติต(Entity)
  – สิ่งที่มีอยู่ในขอบเขตของระบบที่เราสนใจ อาจเป็น สิ่งของ
    คน สถานที การกระทา เหตุการณ์ โดยแต่ละเอนติตี้จะเก็บ
    เรื่องเดียวกัน
  – เช่น นักศึกษา , รถยนต์, หนังสือ, การทาผิด,
    เพลง, การเช่า ,ประวัติการทางาน, การประมูล,
    การสัมมนา, น้าตก , บ้านเช่า เป็นต้น


                                        Database Management System
                                                                                     4.22



    Attribute
 ลักษณะหรือคุณสมบัติที่นามาใช้อธิบายสิ่งต่างๆ(Entity)             และความสัมพันธ์
  ต่างๆ(Relationship) ในระบบงาน
 เช่น attribute ที่นามาอธิบาย Entity ของ ลูกค้า ในระบบงานขายสินค้า
   – ชื่อ สกุล ที่อยู่ รายได้ สถานภาพ อาชีพ
 เช่น attribute ที่นามาอธิบาย Entity ของ การลดราคา ในระบบงานแสดงสินค้า
   – ครั้งที่ วันที่เริ่มต้น วันสุดท้าย ชื่อสถานที่จัดงาน
 เช่น attribute ที่นามาอธิบาย Relationship ของซื้อสินค้า ในระบบงานขาย
  สินค้า
   – วันที่ซื้อ วันที่ต้องการส่งสินค้า จานวนที่ซื้อสินค้า
                                                            Database Management System
                                                            4.23


 Relationship

ความสัมพันธ์ระหว่าง entity ต่างๆ ซึ่งเปรียบเทียบ
  ได้กับกริยาโครงสร้างของ 1 ประโยค โดยทั่วไป
  ประกอบด้วย ประธาน กริยา กรรม
  – ประธาน และ กรรม เป็นคานาม เปรียบเป็น Entity
  – กริยาแสดงความสัมพันธ์ระหว่างประธานกับกรรม
    เปรียบเป็น Relationship
เช่น นักศึกษา 1 คน เรียนได้หลายๆวิชาใน 1เทอม
                                   Database Management System
                                                             4.24


Degree of Relationship

 Degree ของชนิดความสัมพันธ์ คือ จานวนของ
 ชนิดของ entity ที่มีส่วนร่วมในความสัมพันธ์นั้น
 – Unary (Recursive) Relationship
    ความสัมพันธ์ภายใน   entity เดียวกัน
  – Binary Relationship
    ความสัมพันธ์ระหว่าง   2 entities
  – Ternary Relationship
    ความสัมพันธ์ระหว่าง   3 entities

                                    Database Management System
                                                                       4.25


     ตัวอย่าง ของ Degree of Relationship

Unary          m                                   นักศึกษา
        พนักงาน                  หัวหน้างาน              M




               1                                    ลงทะเบียน

                                                         M




Ternary            อาจารย์                         วิชาเรียน
                      M

                                                    Binary
   วิชาเรียน   M
                   สอน       M
                                 หนังสือ
                                              Database Management System
                                                                      4.26



       Cardinality of Relationships
   จานวน entity ต่อ entity ในความสัมพันธ์


    – One to One relationship (1 to 1)
    – One to Many relationship (1 to M)
    – Many to Many relationship (M to M)


                                             Database Management System
                                             4.27


Mapping Cardinalities




   One to one       One to many
                    Database Management System
                                             4.28

Mapping Cardinalities




   Many to one      Many to many


                    Database Management System
                                                                                4.29


   One to One Relationship
 ความสัมพันธ์ที่แต่ละแถวของข้อมูลในเอนติตี้แรก สามารถจับคู่กับ
  ข้อมูลในเอนติตี้ที่สองได้เพียงแถวเดียวเท่านั้น
 เช่น ระบบข้อมูลมหาวิทยาลัย



                         1                         1
             อาจารย์            เป็นคณบดี                      คณะ
    – อาจารย์ 1 คน เป็นคณบดีได้เพียง 1 คณะ และ
                                                    ้
    – แต่ละคณะ มีอาจารย์ที่เป็นคณบดีได้คนเดียวเท่านัน



                                                       Database Management System
                                                                                       4.30


   One to Many
 ความสัมพันธ์ที่แต่ละแถวของข้อมูลในเอนติตี้แรก สามารถจับคู่กับ
  ข้อมูลในเอนติตี้ที่สองได้มากกว่าหนึ่งแถว
 เช่น ระบบสั่งซื้อสินค้าของลูกค้า



                              1                           M
                ลูกค้า                      สั่งซื้อ                ใบสั่งซื่อ
                     ่
   – ลูกค้า 1 คนสังซื้อใบสั่งซื้อได้หลายใบ และ
   – ใบสั่งซื้อแต่ละใบ ถูกสั่งซื้อจากลูกค้าเพียงคนเดียว



                                                              Database Management System
                                                                                         4.31


    Many to Many
 ความสัมพันธ์ที่แต่ละแถวของข้อมูลในเอนติตี้แรก สามารถจับคู่กับข้อมูลในเอน
  ติตี้ที่สองได้มากกว่าหนึ่งแถว
  และในทางกลับกันข้อมูลแต่ละแถวของฝั่งเอนติตี้ที่สองก็สามารถจับคู่กับข้อมูลใน
  เอนติตี้แรกได้มากกว่าหนึ่งแถว
 เช่น ระบบสั่งซื้อสินค้าของลูกค้า
                             M                              M
               สินค้า                     ถูกสังซื้อ
                                               ่                      ใบสั่งซื้อ


                                           ้
    – สินค้า 1 อย่าง ถูกสั่งซื้อตามใบสั่งซือได้หลายใบ และ
    – ใบสั่งซื้อ 1 ใบสั่งซื้อสินค้าได้หลายอย่าง
                                                                Database Management System
                                                      4.32


Primary Key

 Attributeหรือ กลุ่มของ attribute ที่แสดง
 เอกลักษณ์ของสิ่งใดสิ่งหนึ่งได้ ดังนั้นสิ่ง
 ต่างๆ จะมีค่า primary key ไม่ซ้ากันเสมอ




                             Database Management System
                                                                        4.33


  สัญลักษณ์ของ ER Model
                    สัญลักษณ์                 ความหมาย
 สี่เหลี่ยมผืนผ้า                 เอนติตี้

                                  เอนติติ้แบบอ่อน
                                  (Weak Entity)
                                  ความสัมพันธ์



ER-Model ตามแบบของ Peter Pin Shan Chen

                                               Database Management System
                                                       4.34


สัญลักษณ์ของ ER model(ต่อ)
      สัญลักษณ์              ความหมาย
                  ความสัมพันธ์แบบอ่อน
                  (Weak Relationship)
                  แอตทริบิวต์

                  แอตทริบิวต์ที่เป็น primary key




                              Database Management System
                                                        4.35


สัญลักษณ์ของ ER Model(ต่อ)
      สัญลักษณ์                   ความหมาย
                  แอตทริบิวต์ที่มีหลายค่า

                  แอตทริบิวต์ประกอบ (แอตทริบิวต์
                  ด้านบนเป็นส่วนประกอบของแอตทริบิวต์
                  ด้านล่าง)

                  Partial Key เป็น key ของ
                  weak entity ซึ่งค่า partial
                  key ซ้ากันได้
                               Database Management System
                                                                  4.36


สัญลักษณ์ของ ER model(ต่อ)
      สัญลักษณ์                        ความหมาย
                       ดีไรฟ์แอตทริบิ่วต์(derived attribute)
                       เก็บผลของการคานวณหรือแปลงค่ามาจากแอตทริ
                       บิวเดิม

                                     ี่
                       ความสัมพันธ์ทข้อมูลทุกๆแถวในเอนติติ้ E2
                       สามารถจับคู่ได้กับข้อมูลแถวใดแถวหนึ่งของ
 E1        R      E2   E1 ได้ เรียกว่า ข้อมูลใน E2 เป็น total
                       participation กับ E1



                                       Database Management System
                                                                4.37


สัญลักษณ์ของ ER model(ต่อ)
      สัญลักษณ์                     ความหมาย
                       ความสัมพันธ์ที่ข้อมูลทุกๆแถวในเอนติติ้
 E1        R      E2   E1 สามารถจับคู่ได้กับข้อมูลแถวใด
                       แถวหนึ่งของ E2 ได้เรียกว่า ข้อมูลใน
                       E2 เป็น partial
                       participation กับ E1




                                      Database Management System
                                                                           4.38


Participation Constraint
 เงื่อนไขการมีส่วนร่วม   คือ จานวนต่าสุดของ
  entity ที่อีก entityหนึ่งมีความสัมพันธ์ด้วย มี 2
  แบบคือ
  – Total Participation
        การที่     entity หนึ่งentity จะต้องมีความสัมพันธ์กับentity
             อื่นอย่างน้อยหนี่ง entity เช่น อาจารย์ทุกคนต้องสังกัด
                                                           ้
             อย่างน้อยใน หนี่งคณะ เป็นต้น การมีส่วนร่วมทังหมดจะ
                                                      ่
             แสดงด้วยเส้นคู่ทางด้านชนิดของentityทีทุกentity ใน
             ชนิดนั้นต้องเข้าร่วมในความสัมพันธ์

   อาจารย์          M      สังกัด     1        คณะ
                                                  Database Management System
                                                                     4.39


Participation Constraint(ต่อ)
 – Partial Participation
            ่
      การทีentity     หนึ่งentity มีความสัมพันธ์กับentity อื่น
       อย่างน้อยศูนย์entity คือในชนิดของentity เดียวกันอาจมี
                     ่
       บางentity ทีมีส่วนร่วมในความสัมพันธ์นั้น ในขณะที่บาง
                       ี
       entity ที่ไม่มส่วนร่วมในความสัมพันธ์นั้นเลย เช่น แผนก
       บางแผนกไม่มีพนักงานสังกัดเลย และบางแผนกอาจมี
       พนักงานสังกัดหลายคน
      การมีส่วนร่วมบางส่วนจะแสดงโดยใช้เส้นเดียวด้านชนิด
       ของentity ที่บางentityในชนิดนั้นมีส่วนร่วมใน
       ความสัมพันธ์ เช่น เส้นเดียวจากentity แผนก

 อาจารย์      M      สังกัด     1        แผนก
                                            Database Management System
                                                                       4.40


 ประเภทของ attribute
 Simple        Attribute คือ แอตทริบิวที่เก็บค่าได้เพียงค่าเดียว
  เท่านั้น เช่น รหัสลูกค้า ลูกค้า 1 คนมีรหัสลูกค้าได้หมายเลขเดียว
 Multi-valued attribute คือ แอตทริบิวต์ที่เก็บค่าได้ตั้งแต่
  1 ค่าขึ้นไป เช่น เบอร์โทรศัพท์ ของลูกค้า มีทั้งเบอร์
  บ้าน เบอร์มือถือ เป็นต้น


          ลูกค้า           เบอร์โทรศัพท์

                                              Database Management System
                                                                          4.41


 ประเภทของแอตทริบิวต์(ต่อ)
 Composite       attribute คือแอตทริบิวต์ที่ประกอบด้วยแอ
 ตทริบิวต์หลายตัวมารวมกันจึงให้ความหมายที่ชัดเจน

                จังหวัด
                                   ชื่อ
ถนน                                           สกุล
                          อาเภอ
                                     ่
                                   ชือ-สกุล
      ที่อยู่

                          ลูกค้า
                                                 Database Management System
                                                                     4.42


 ประเภทของแอตทริบิวต์(ต่อ)
 Derived   attribute คือ แอตทริบิวต์ที่เก็บผลการคานวณหรือ
 แปลงค่ามาจากแอตทริบิวต์อื่นๆ เช่น จานวนเงิน(ราคา*จานวน)



                             จานวนพนักงาน

           แผนก
                               รหัสแผนก


                                            Database Management System
                                                                       4.43


Weak Entity
 Weak    entity ต้องมีคุณสมบัติ 2 ข้อ คือ
 1. ไม่มี Primary Key มีเพียง partial key (ซึ่งเป็นค่าที่
   ซ้ากันได้) ดังนั้นนาเอา partial key ไปรวมกับ
   Primary key ของ Strong Entity ก็จะเป็นค่าที่ไม่ซ้า
   ได้
 2. Weak entity ต้องมีความสัมพันธ์กับ Strong Entity
   อย่างน้อย 1 entity คือ ลักษณะของการขึ้นต่อกัน คือ การที่เอนติตี้
   หนึ่งจะเกิดขึ้นได้นั้น ขึ้นกับอีกเอนติตี้หนึ่งว่าปรากฏอยู่หรือไม่



                                              Database Management System
                                                                                                 4.44


        Weak Entity (ต่อ)
       ตัวอย่าง      เอนติตี้พนักงานและเอนติตี้ญาติ ถ้าไม่มีเอนติตี้พนักงาน
          เอนติตี้ญาติก็จะไม่เกิดขึ้น
              – เอนติตี้ญาติ เป็น Weak Entity
              – เอนติตี้พนักงาน เป็น Entity                                           ลาดับที่
รหัสพนักงาน

                  พนักงาน              1
                                                    มี           M            ญาติ
     -ญาติ เป็น weak entity ที่ไม่มี primary key โดยคุณสมบัติ ลาดับที่ มีค่า
      ซ้ากันในรีเลชั่น ญาติ เพราะคุณสมบัติ ลาดับที่ มีค่าซ้าๆ กันได้ในหลายญาติ เช่น
               ลาดับที่ 1 เป็นญาติ นายขาว และลาดับที่ 1 เป็นญาติ นายแดง
     -ฝั่งชนิดของentity ญาติ เป็นแบบ Total Participation             Database Management System
Weak Entities(ต่อ)
                                      รหัสวิชา
         วิชา
            1                         ชื่อวิชา
                                                      ปี-ภาค
        เปิดสอน                รหัสการเปิดสอน
                                                         กลุ่ม
            M
                                       เวลาเรียน
     วิชาที่เปิดสอน

ชื่อวิชา(รหัสวิชา, ชื่อวิชา)
วิชาที่เปิดสอน(รหัสวิชา*, ปี-ภาค, กลุ่ม, เวลาเรียน)
                                                                                   4.46


  ตัวอย่าง Recursive Relationships

       การลงทะเบียนบางวิชา จะต้องเรียนวิชาอื่นมา 1 วิชา
 ตัวอย่าง
  (one to one)

                        วิชาที่ลงทะเบียน
                 1

               Course                          Precond.


                 1       วิชาที่ต้องผ่านก่อน

 Course(CourseID, CourseName, Unit, PrecondCourseID*)

                                                          Database Management System
                                                                      4.47


Recursive Relationships(ต่อ)
CourseID   CourseName                 Unit   PrecondCourseID*

           Database Management        3      4122202
4123601
           System
4122202    Introduction to Database   3

4121202    Programming and            3
           algorithm
4122101    Programing Language 1      3      4121202




                                             Database Management System
    ตัวอย่าง Recursive Relationships
   ตัวอย่าง การลงทะเบียนบางวิชา จะต้องเรียนวิชาอื่นมา 1 วิชาหรือหลายๆ
    วิชา (many to many)
                             วิชาที่ลงทะเบียน
                      m

                    Course                         Precond.

                             วิชาที่ต้องผ่านก่อน
                      m

          Precondition(CourseID, PrecondCourseID)
          Course(CourseID , CourseName, Unit)
Recursive Relationships(ต่อ)
Course
 CourseID                CourseName      Unit
 4123601    Database Management System   3
 4122202    Introduction to Database     3
 4121202    Programming and algorithm    3
 4122101    Programing Language 1        3
Precondition
 CourseID      PrecondCourseID
 4123601       4122202

 4123601       4122101
 4121202       4121101
 4122101       4121202
ตัวอย่าง Recursive Relationships
   ตัวอย่างพนักงานที่เป็นหัวหน้า 1 คน มีลูกน้องได้หลายคน ทั้ง
    หัวหน้าและลูกน้องก็เป็นพนักงานทั้งคู่ (one to many)

                             หัวหน้า
                  1

               Employees               Manage

                           ลูกน้อง
                  m

    Employees( EmpID, EmpName, BirthDate, MangerID*)
    ตัวอย่าง Ternary Relationships

                                   3 เอนติตี้
 เป็นความสัมพันธ์ที่มีเอนติตี้ที่เกี่ยวข้อง
                   ี
 เช่นความสัมพันธ์ดกรี 3 ของความสัมพันธ์ระหว่าง ผู้ขาย โครงการ
  สินค้า
    – เนื่องจากผู้ขายสามารถขายสินค้าให้กับโครงการใดก็ได้
      ตัวอย่าง Ternary Relationships

             รหัสโครงการ
                                    โครงการ
                                                                    รหัสสินค้า
รหัสผู้ขาย
                                       M


                    ผู้ขาย    M
                                    สาหรับ     M
                                                      สินค้า

                                           จานวน



ผู้ขาย-โครงการ-สินค้า(รหัสผู้ขาย, รหัสโครงการ, รหัสสินค้า, จานวน)
  ตัวอย่าง Ternary Relationships
      ID1
                E1
                              ID3
                1
ID2
                                R (ID3, ID2, ID1)
      E2    M
                R    M   E3



      ID1
                E1
                              ID3
                M
ID2
      E2    M
                R    M   E3     R (ID3, ID2, ID1)
                                                                      4.54


  Aggregation
  Treat     aggregation as any other entity type


 Physician   M
                 Treat    M    Patient

                 M
Treatment
                     Us       Physician(…), Patient(…), Drug(…)
                     e
                      M       Treat (PhysicianID, PatientID)
                              Use(PhysicianID, PatientID, DrugID)
                 Drug

                                             Database Management System
หลักการแปลง ER เป็นรีเลชั่น
1.   ให้แปลงเอนติติ้ทุกตัวเป็นรีเลชั่น และแปลงแอตทริบิวต์
     ทุกตัวของเอนติตี้ให้เป็นแอตทริบิวต์ของรีเลชั่น


         Customer           CusID

                         CusName
CusAdd      CusSurName


 Customer(CusID, CusName, CusSurName, CusAdd)
  หลักการแปลง ER เป็นรีเลชั่น(ต่อ)
  2. เพิ่มแอตทริบิวต์ให้กับรีเลชั่น
      2.1 ถ้าความสัมพันธ์เป็นแบบ 1 to 1 ให้นา pk ของรีเลชั่นฝั่งใดฝั่ง
           หนึ่งไปอยู่ในรีเลชั่นของอีกฝั่งหนึ่ง
      **ต้องให้ค่าในแอตทริบิวใหม่เป็น Null น้อยสุดหรือไม่มี
                           1                      1
             Teacher                  เป็นคณบดี          Faculty

                                 ThName                       FacName
  ThID                                                FacID
                 ThSurName

Teacher(ThID, ThName, ThSurName)
Faculty(FacID,FacName,ThID*)
                                                     4.57




Teacher(ThID, ThName, ThSurName)
Faculty(FacID,FacName,ThID*)


Teacher(ThID, ThName, ThSurName,FacID*)
Faculty(FacID,FacName)


                            Database Management System
ThID    ThName           ThSurName                                 4.58

  001   ผศ.วาสนา             ใจดี
  034   อ.สมคิด              ใจดี
  253   รศ.ฉลาด              ใจดี
  333   ผศ.สมาธิ             ใจดี
  111   อ. ดุษฎี             ใจดี
  002   อ. ประสงค์           ใจดี
  003   อ. ปรานี             ใจดี
              FacID      FacName             ThID*
                     1   วิทยาศาสตร์          001
                     2   มนุษย์               034
                     3   วิทยาการจัดการ       253
                     4   ครุศาสตร์            333
                     5   เทคโนโลยีอุตฯ         111
                                          Database Management System
ThID      ThName                   ThSurName         FacID              4.59

  001     ผศ.วาสนา                     ใจดี            1
  034     อ.สมคิด                      ใจดี            2
  253     รศ.ฉลาด                      ใจดี            3
  333     ผศ.สมาธิ                     ใจดี            4
  111     อ. ดุษฎี                     ใจดี            5
  002     อ. ประสงค์                   ใจดี
  003     อ. ปรานี                     ใจดี
        FacID     FacName
            1     วิทยาศาสตร์
            2     มนุษย์
            3     วิทยาการจัดการ
            4     ครุศาสตร์
            5     เทคโนโลยีอุตฯ
                                               Database Management System
                                                           4.60


     หมายเหตุ

กรณีที่เป็น Total Partial Relationship
นา PK ของด้านที่เป็น Partial Relationship
ไปเป็น FK ของด้านที่เป็น Total Relationship




                                  Database Management System
    หลักการแปลง ER เป็นรีเลชั่น(ต่อ)
    2. เพิ่มแอตทริบิวต์ให้กับรีเลชั่น
        2.2 ถ้าความสัมพันธ์เป็นแบบ 1 to Mให้นา pk ของรีเลชั่นฝั่งที่เป็น
           1ไปอยู่ในรีเลชั่นของฝั่งที่เป็น M


CusName                      1                      M
              Customer                  สั่งซื้อ           Orders

                                 ReqDate           OrderDate
    CusID                                                           OID
                  CusSurName

  Customer(CusID, CusName, CusSurName)
  Orders(OID,OrderDate, ReqDate ,CusID*)
    หลักการแปลง ER เป็นรีเลชั่น(ต่อ)
    2. เพิ่มแอตทริบิวต์ให้กับรีเลชั่น
        2.3 แอตทริบิวต์ที่อยู่บนความสัมพันธ์ จะนาไปใส่ในรีเลชั่นใด ก็ขึ้นอยู่
           กับว่าเมื่อใส่ลงในรีเลชั่นนั้นแล้ว จะมีบางแถวหรือไม่มีแถวข้อมูลใดเลยที่มี
             ค่าในแอตทริบิวต์เป็น Null

CusName                          1                        M
              Customer                        สั่งซื้อ             Orders

                                     ReqDate             OrderDate
    CusID                                                                     OID
                    CusSurName

  Customer(CusID, CusName, CusSurName)
  Orders(OID,OrderDate, ReqDate ,CusID*)
หลักการแปลง ER เป็นรีเลชั่น(ต่อ)
     3. สร้างรีเลชั่นใหม่สาหรับความสัมพันธ์แบบ M to M
        โดยสร้าง PK ได้จาก การนาเอา PK ของแต่ละรีเลชั่น
        มาประกอบกัน หรือ สร้างแอตทริบิวส์ขึ้นมาใหม่
                                                        Discount

 PName                          M                        M
               Products                รายการสั่งซื่อ           Orders

                                    Amount              UnitPrice
      PID                                                                OID
                        Price
  Product(PID, PName, Price)
  Orders(OID,OrderDate, ReqDate ,CusID*)
  OrderDetail(OID*, PID*, Discount, Amount, UnitPrice)
                                                                       4.64

     ตัวอย่าง สร้าง primary key ใหม่

 รหัสนักศึกษา ชื่อ-นามสกุล     เกรด      รหัสวิชา            กลุ่ม


                      M                  M
      นักศึกษา               ลงทะเบียน                วิชา

นักศึกษา (รหัสนักศึกษา,ชื่อ-นามสกุล)             ชื่อวิชา
วิชา (รหัสวิชา,กลุ่ม,ชื่อวิชา)
ลงทะเบียน (รหัสการลงทะเบียน,รหัสนักศึกษา*,รหัสวิชา*,กลุ่ม*,เกรด)
                                              Database Management System
หลักการแปลง ER เป็นรีเลชั่น(ต่อ)
4. สาหรับเอนติติ้ที่มีแอตทริบิวต์แบบหลายค่า
                   ที่มีแอตทริบิวต์แบบหลายค่านั้น
 ให้สร้างรีเลชั่นเพิ่ม
 PK ของรีเลชั่นใหม่เกิดจาก PK ของรีเลชั่นเดิมประกอบกับ แอตทริบิวต์ที่
  เกิดจากแอตทริบิวแบบหลายค่า
           CusName         Customer           CreditNum


                   CusID
                      CusSurName
 Customer(CusID, CusName, CusSurName)
 CusCredit(CusID*, CreditNum)
                                                                   4.66


            หากพบ multivalued attribute ควรแยกออกมา
            เป็น composite attribute

                     ชื่อ       นามสกุล

     รหัส                        เบอร์โทรศัพท์
                  พนักงาน

พนักงาน(รหัส,ชื่อ,นามสกุล,เบอร์โทรศัพท์1,เบอร์โทรศัพท์2)

                                          Database Management System
 หลักการแปลง ER เป็นรีเลชั่น(ต่อ)
 5. สาหรับเอนติตี้แบบอ่อน ให้สร้างเป็นรีเลชั่น และมี PK ที่มาจาก PK ของรี
   เลชั่นหนึ่งรวมกับ PK ของเอนติตี้แบบอ่อน


                           1              M        Invoice
             Invoice               has              Detail

    Inv no         Date                             Line

Invoice(Inv no, Date)
InvoiceDetail( Inv no* ,Line)
                                                                  4.68

Mulitvalued Attributes
และการแปลงเป็นรีเลชั่น
    Phone
             Faculty Member         Degrees
    Name

FACULTY_MEMBER (Name, Phone)
FACULTY_DEGREES (Name*, Degree)



     Faculty Member           has       Degree


                                         Degree
                                         Database Management System
                                                                              4.69

    EER model
    (Enhanced Entity Relationship Model)
   เป็น Model ที่นาแนวคิดของ ER Model มาเพิ่มเติมในเรื่อง

1. ความสัมพันธ์แบบ Superclass/Subclass        หรือ
  Supertype/Subtype
2. แนวคิดของ Generalization/Specialization ซึ่งเป็นแนวคิดที่ใช้
  ในการสร้างความสัมพันธ์ของ Entity ที่เป็น
  Superclass/Subclass รวมทั้งการถ่ายทอดคุณสมบัติ (Attribute
  Inheritance)

   เหมาะที่จะนามาใช้กับระบบงานทางธุรกิจที่มีความสลับซับซ้อน ซึ่งจะช่วยลด
    ความซับซ้อนของข้อมูล การเขียน Model ทาได้ง่าย
                                                     Database Management System
                                                                                              4.70


    EER model
   Superclass คือ รูปแบบของ Entity ที่เป็นต้นแบบของ Entity อื่นๆ โดย
    Superclass จะประกอบไปด้วย Subclass ต่างๆ

                                    ุ          ่
    Subclass คือ Entity ที่มีคณสมบัติบางอย่างทีแตกต่างจากสมาชิกของSubclass
    ด้วยกัน แต่จะมีคุณสมบัติพื้นฐานตาม Superclass

   ตัวอย่าง : Entity พนักงาน เป็น Superclass ประกอบด้วยข้อมูล รหัสพนักงาน,ชื่อ
    ,วันที่เริ่มทางาน
    Entity นี้ประกอบด้วย Subclass คือ
            - ผู้บริหาร จะมีข้อมูลเฉพาะ คือ รถและเงินเดือนประจาตาแหน่ง - ผูเ้ ชี่ยวชาญ จะมี
    ข้อมูลเฉพาะเกี่ยวกับความชานาญและค่าตอบแทน
            - พนักงานแรงงาน จะมีข้อมูลเฉพาะ คืออัตราค่าจ้างรายวัน
    ข้อมูลของ Entity ที่เป็น Subclass จะต้องมีข้อมูลทั้งหมดจากSuperclass

                                                                Database Management System
                                       Superclass/Subclass                             4.71


                  รหัสพนักงาน
                                                          วันทีเ่ ริ่มงาน
                                     Employee
            ชื่อพนักงาน




         Manager                     Specialist                        Labor

-รถประจาตาแหน่ง                 -ความชานาญ
                                                                -ค่าจ้างรายวัน
-เงินเดือนประจาตาแหน่ง          - ค่าตอบแทนผู้เชี่ยวชาญ


                                                              Database Management System
                                                                  4.72

การถ่ายทอดคุณสมบัติ
(Attribute Inheritance)
- Subclass จะรับถ่ายทอดคุณสมบัติทุกๆอย่างจาก
  Superclass
- ทาให้ไม่ต้องกาหนด Attribute ซ้าซ้อนใน Subclass

- ตัวอย่าง : Subclass ผู้บริหาร,ผู้เชี่ยวชาญและพนักงาน
  แรงงาน จะได้รับถ่ายทอดคุณสมบัติทุกๆอย่างจาก
  Superclass Employee

                                         Database Management System
                                                                              4.73


 Generalization
                                            ่
• เป็นกระบวนการจัดการกับ Entity ทีเป็นแม่แบบ เพื่อใช้กาหนดลักษณะที่
  เหมือนกันหรือร่วมกัน วิธีการนี้เป็นวิธีแบบล่างขึ้นบน
  (Bottom-Up Approach) ด้วยการมองหาสิ่งที่เหมือนกันใน
  Subclass เช่น การพิจารณา Entity ที่เป็น Subclass คือ
  ผู้บริหาร, ผู้เชี่ยวชาญและพนักงานแรงงาน ว่ามีลักษณะอะไรที่เหมือนกัน เพื่อ
  ออกแบบ Entity ที่เป็น Superclass คือ Employee ซึ่งมีข้อมูล
  ร่วมกัน คือ รหัสพนักงาน ชื่อและวันที่เริ่มทางาน
• จะกาหนดซับคลาสก่อน แล้วค่อยหาว่าซับคลาสทั้งหมดนั้นมีแอตทริบิวต์อะไร
  ที่เหมือนกันบ้าง




                                                    Database Management System
                                                                           4.74



Specialization
• เป็นกระบวนการจัดการกับ Entity ที่มีความแตกต่างกันในกลุ่มของ
  สมาชิกซึ่งขึ้นกับ Superclass วิธีนี้เป็นวิธีแบบบนลงล่าง (Top-
  Down Approach) ด้วยการมองจุดที่แตกต่างกันระหว่าง
  Subclass เช่น Superclass Employee ประกอบด้วยพนักงานที่
                                                  ่
  เป็นผู้บริหาร ผู้เชี่ยวชาญและพนักงานแรงงาน ซึงมีรายละเอียด
  เฉพาะตามประเภทพนักงาน

      ่       ่
• เครืองหมายทีใช้แสดงความสัมพันธ์ของ Superclass/Subclass
   • เครื่องหมาย U แสดงว่า Subclass เป็น Subset ของ Superclass
   • จุดเชื่อมต่อ คือ วงกลม
   • เส้นที่ลากจาก Superclass มายัง Subclass คือ เส้นที่ถ่ายทอดคุณสมบัติ




                                                 Database Management System
                                                                          4.75


    ตัวอย่าง ธุรกิจมีการว่าจ้างพนักงาน
โดยมีพนักงานที่แตกต่างกัน 3 ประเภท คือ
 1. Hourly Employees – พนักงานรายชั่วโมง

   2. Salary Employees – พนักงานประจา ได้รับเงินเดือน

   3. Consultants – ที่ปรึกษา ได้รับเงินพิเศษ

โดย Attribute ที่สาคัญของพนักงานแต่ละประเภท ประกอบด้วย
 Hourly Employee (Emp_no, Emp_name, Address,
  Date_hired, Hourly_Rate)
 Salary Employee (Emp_no, Emp_name, Address,
  Date_hired, Annual_Salary)
 Consultant ( Emp_no, Emp_name, Address,
  Date_hired, Contract_No, Billing_Rate)
                                                 Database Management System
                                                                           4.76
              Emp_no         Emp_name           Address
                                                  Date_hired
                             Employee
                                  d
                   U                    U
                              U

  Hourly                  Salary                     Consultant
 Employee                Employee


Hourly_rate            Annual_Salary        Contact_no         Billing_Rate

                                                  Database Management System
                                                                                        4.77

   สร้าง EER model
   ตามหลักการ specialization
                                                                        ตาแหน่ง
  รหัสพนักงาน                          พนักงาน

        ชื่อพนักงาน                       ชนิดค่าตอบแทน
                                         d
     เงินเดือน             เงินเดือน                                อัตราค่าแรงต่อชม.
                                                 รายชั่วโมง


            ่
   พนักงานทีได้รับ เงินเดือน                              ่
                                                 พนักงานทีได้รับค่าตอบแทนเป็น
                                                            ชั่วโมง


                                   ่
พนักงานได้รับค่าจ้างเป็นแบบใดแบบหนึง                           Database Management System
                                                      4.78


แปลง EER เป็น relation

 แบ่ง   4 กรณี
  – แปลงได้ 1 ตาราง โดยนาแอตทริบิวต์ของ
    subclass ทุกตัว จับมาไว้ในตารางของ
    superclass
  – แปลงได้ตารางเท่ากับจานวนของ subclass
    โดยนาแอตทริบิวต์ของ superclass ทุกตัว
    ไปรวมกับแอตทริบิวต์ของแต่ละ subclass

                             Database Management System
                                                      4.79


แปลง EER เป็น relation

 แบ่ง   4 กรณี
  – 3.แปลงได้ตารางเท่ากับจานวน superclass
    และsubclass โดยตารางที่เป็น superclass
    จะมีแอตทริบิวต์ของตัวมันเอง แต่สาหรับ
    subclass ให้นา pk ของsuperclass ไป
    รวมไว้ยังแต่ละ subclass ด้วย



                             Database Management System
                                                             4.80


แปลง EER เป็น relation
 แบ่ง   4 กรณี
  – 4.ใช้ได้กับความสัมพันธ์ superclass-
    subclass แบบ overlapped
     แปลงตารางได้เพียงตารางเดียวเท่านั้น  คือ ตาราง
      ที่เกิดจาก superclass โดยนา attribute ทุกตัว
      มาจาก subclass
     และเพิ่ม attribute ใหม่ ให้มีจานวนเท่ากับ
      subclass เพื่อเก็บ flagของsubclass


                                    Database Management System
                                                                                                    4.81


    การแปลงเป็นรีเลชั่น
   ทาได้ 2 วิธีคือ
     – วิธี 1 แปลงเป็น 3 รีเลชั่น คือ
           พนักงาน(รหัสพนักงาน, ชื่อพนักงาน, ตาแหน่ง, ชนิดค่าตอบแทน)
           เงินเดือน(รหัสพนักงาน, เงินเดือน)

           ค่าตอบแทนเป็นชม(รหัสพนักงาน, อัตราค่าแรง)

     – เหมาะกับการใช้ข้อมูลพนักงานบ่อยๆโดยไม่สนเรื่องค่าจ้าง
     – วิธี 2 แปลงเป็น 2 รีเลชั่น คือ
                                                    ่
            พนักงานที่ได้รับเงินเดือน(รหัสพนักงาน, ชือพนักงาน, ตาแหน่ง, เงินเดือน)
           พนักงานที่ได้รับค่าตอบแทนเป็นชม(รหัสพนักงาน, ชื่อพนักงาน, ตาแหน่ง, อัตราค่าแรงเป็นชม)

     – เหมาะกับความต้องการใช้ข้อมูลพนักงานแยกกัน




                                                                      Database Management System
                                                                                         4.82

     สร้าง EER model
     ตามหลักการ specialization(ต่อ)
                                                                         ตาแหน่ง
    รหัสพนักงาน                         พนักงาน

         ชื่อพนักงาน                       ชนิดค่าตอบแทน
                                          O
      เงินเดือน             เงินเดือน                                อัตราค่าแรงต่อชม.
                                                  รายชั่วโมง


             ่
    พนักงานทีได้รับ เงินเดือน                              ่
                                                  พนักงานทีได้รับค่าตอบแทนเป็น
                                                             ชั่วโมง


พนักงานแต่ละคนมีสิทธิ์ได้รับทั้งเงินเดือนและค่าตอบแทนเป็นชั่วโมงด้วย
                                                                Database Management System
                                                                           4.83


   การแปลงเป็นรีเลชั่น
 แปลงได้รีเลชั่นเดียวและเก็บข้อมูลทุกอย่างลงไป
 เพิ่มแอตทริบิวต์ที่ทาหน้าที่เป็นแฟล็ก สาหรับเก็บค่า       T หรือ F

 พนักงาน(รหัสพนักงาน,     ชื่อพนักงาน, ตาแหน่ง, แฟล็ก
  เงินเดือน, เงินเดือน, แฟล็กค่าตอบแทนเป็นชม, อัตราค่าแรงต่อ
  ชม)
   – ถ้าแฟล็กเงินเดือน มีค่าเป็นจริง, ควรต้องมีค่าในช่องเงินเดือนด้วย

                                                  Database Management System
                                                                         4.84

สร้าง EER model
ตามหลักการ generalization
         ่
พนักงานทีได้รับ เงินเดือน                    ่
                                    พนักงานทีได้รับค่าตอบแทนเป็น
                                               ชั่วโมง

                เงินเดือน                 รายชั่วโมง


                             O

                              ชนิดค่าตอบแทน
                            พนักงาน


                                                Database Management System
                                                                          4.85

    Constraint สาหรับ Specialization และ
    Generalization
 1.Condition เงื่อนไขในการจาแนกข้อมูล
 2.Disjoint/Overlap Constraint
   – d ข้อมูลระดับ superclass สามารถสัมพันธ์กับ subclass
     ได้เพียงหนึ่งตัวเท่านั้น
   – เช่น พนักงานทุกคนสามารถรับ เงินเดือนหรือค่าตอบแทนเป็นชม. เพียง
     อย่างใดอย่างหนึ่งเท่านั้น
   – o ข้อมูลระดับ superclass สามารถสัมพันธ์กับ subclass
     ได้มากกว่าหนึ่งตัว
   – พนักงานทุกคนสามารถรับเงินเดือนหรือค่าตอบแทนเป็นชม. อย่างใด
     อย่างหนึ่งหรือได้รับทั้งสองอย่างก็ได้
                                                 Database Management System
                                                                  4.86

 Constraint สาหรับ Specialization และ
 Generalization(ต่อ)
 3.Completeness/Incompleteness
  – หากระบุ subclass ทั้งหมดได้อย่างครบถ้วน เรียกว่า
    Completeness




                                         Database Management System
                                                                                           4.87

    ข้อมูลพนักงาน แบ่งประเภทของงานที่รับผิดชอบ
    เป็น 3 กลุ่มเท่านั้น Completeness
   รหัสพนักงาน                           พนักงาน

            ชื่อพนักงาน                           ประเภทงาน
                                           d
                          ผู้จัดการ                   เลขานุการ
                                      วิศวกร


ผู้จัดการ                                วิศวกร                   เลขานุการ




                                                                  Database Management System
                                                                  4.88
   ข้อมูลยานพาหนะ แบ่งซับคลาสได้ 2 กลุ่ม                  ไม่
                          ่
   ครอบคลุมรถยนต์ประเภทอืนๆ
   Incompleteness
                     รถ

                          ประเภทงาน
                     d
            รถยนต์            รถบรรทุก


รถยนต์                                   รถบรรทุก




                                         Database Management System
                                                                4.89


ลักษณะของการจับคู่ข้อมูล(Participation)
Disjoint      and Total Participation
  – พนักงานทุกคนสามารถรับ เงินเดือนหรือค่าตอบแทน
    เป็นชม. เพียงอย่างใดอย่างหนึ่งเท่านั้น
Disjoint      and Partial Participation
  – พนักงานที่ได้รับเงิน ต้องได้รับเงินเดือนหรือ
    ค่าตอบแทนเป็นชม. เพียงอย่างใดอย่างหนึ่งเท่านั้น แต่
    อาจมีพนักงานบางคนที่ไม่ได้รับเงินแบบใดๆเลย


                                       Database Management System
                                                                   4.90


ลักษณะของการจับคู่ข้อมูล(Participation)
 Overlap      and Total Participation
  – พนักงานทุกคนสามารถรับเงินเดือนหรือค่าตอบแทนเป็นชม.
    อย่างใดอย่างหนึ่งหรือได้รับทั้งสองอย่างก็ได้
 Overlap     and Partial Participation
  – พนักงานที่ได้รับเงิน ต้องได้รับเงินเดือนหรือ
    ค่าตอบแทนเป็นชม. อย่างใดอย่างหนึ่งหรือได้รับทั้งสอง
    อย่างก็ได้ แต่อาจมีพนักงานบางคนไม่ได้รับค่าเงินแบบใดๆ



                                          Database Management System
                                                                4.91


ปัญหาในการเขียน ER-Diagram
Fan    Trap
 – เป็นปัญหาที่เกิดจากลักษณะการจัดความสัมพันธ์ระหว่าง
   Entity
Chasm        Trap
 – เป็นปัญหาที่เกิดจากการเชื่อมโยงความสัมพันธ์ระหว่างข้อมูล
   ไม่ได้

                                       Database Management System
                                                                    4.92



     Fan Trap แบบ 1
 เกิดจากเอนติตี้ที่มีความสัมพันธ์กับเอนติตี้อื่นมากกว่า 1
    ตัวและมีชนิดความสัมพันธ์ออกจากตัวเองเป็น 1 ส่วนอีก
    ข้างหนึ่งเป็น M
           M            1          1               M
นักศึกษา       สังกัด       คณะ            มี            หลักสูตร



                                           Database Management System
                                                                                4.93


     Fan Trap(ต่อ)
สมคิดและจริยา เรียนคณะบัญชี แต่ไม่สามารถบอกได้ว่าใครเรียนหลักสูตรบัญชีหรือบริหาร

 สมคิด             r1             บัญชี              r4                  บริหาร


  จริยา            r2                                r5                   บัญชี
                                 มนุษย์
                                                                        ภาษาอังกฤษ
 สายใจ             r3                                r6

                                                       Database Management System
                                                                4.94


   ทางแก้ Fan Trap แบบ 1
เปลี่ยนแปลงตาแหน่งของเอนติตี้




        1         M              1             M
คณะ          มี       หลักสูตร       สังกัด           นักศึกษา



                                       Database Management System
                                                                            4.95



   Fan Trap แบบ 2
เกิดจากการที่เอนติตี้มีความสัมพันธ์แบบเชื่อมต่อเนื่องกัน
  เป็นวงกลม        ผู้ขาย
                                M
                                      ขาย
                                              M
                                                    สินค้า
                     M                                  M

                    ซื้อ                               ใช้

                            M       โครงการ       M

   •ผู้ขายขายสินค้าอะไร                      เมื่อโครงการติดต่อซื้อขายจาก
                                            ผู้ขายแต่ละรายแล้ว จะซื้อสินค้า
   •โครงการติดต่อซื้อจากผู้ขายรายใด
   •โครงการต้องการใช้สินค้าใดบ้าง                      ?
                                                  อะไรจากผู้ขายรายนั้นๆ
                                                   Database Management System
                                                                         4.96


    ทางแก้ Fan Trap แบบ 2
โดยเพิ่มเอนติตี้ตัวกลาง
         1          M      ทะเบียนการซื้อ-ใช้   M
ผู้ขาย        ขาย                                      ใช้
                                 สินค้า
                                   M                     1

                                 ซื้อ                สินค้า
                                    1

                            โครงการ

                                                Database Management System
                                                                           4.97



     Chasm Trap
                                        ี้
      เป็นปัญหาที่เกิดจากการเขียนเอนติตที่มีความสัมพันธ์กับเอน
           ติตี้อื่นๆมากกว่า 1 ตัวและความสัมพันธ์บางส่วนเป็น
           partial participation ทาให้การจับคู่ข้อมูล
           ระหว่างเอนติตี้ไม่ได้ครบถ้วน

              1             M              M               1
หลักสูตร           สังกัด       นักศึกษา       ช่วยงาน          โครงงาน


                                                  Database Management System
                                                                                4.98


    Chasm Trap (ต่อ)
โครงงานชื่อ งาน1 ไม่มีนักศึกษาช่วยงาน ทาให้ไม่ทราบว่าโครงงานนี้เป็นของหลักสูตรใด

บัญชี             r1             สมคิด               r4                   งาน1


บริหาร            r2             จริยา                                    งาน2


มนุษย์            r3            สายใจ                r5                   งาน3

                                                       Database Management System
                                                                            4.99


    ทางแก้ Chasm Trap
   เพิ่มความสัมพันธ์ที่เชื่อมเอนติตี้หลักสูตรกับโครงงาน


            1              M               M                  1
หลักสูตร          สังกัด       นักศึกษา            ช่วยงาน          โครงงาน

                           1                   M
                                 เจ้าของ




                                                   Database Management System
                                                                             4.100


  แบบฝึกหัดท้ายบทที่ 4
 1.  ยกตัวอย่างความสัมพันธ์แบบ 1-1, 1 to M, M to M
  มาแบบละ 2 ตัวอย่าง
 2. เขียน ER-Diagram จากความต้องการของระบบยืม-คืน
  หนังสือในห้องสมุด ดังต่อไปนี้
   – หนังสืออาจมีเหมือนกันหลายเล่ม บรรณารักษ์จึงไม่สามารถใช้ ISBN
     เพื่อแยกระหว่างเล่มที่เหมือนกันได้ ต้องสร้างรหัสของหนังสือแต่ละเล่ม
     ขึ้นมาใหม่
   – หนังสือแต่ละเล่มมีผู้แต่งเพียงหนึ่งคน
   – การยืมหนังสือในห้องสมุดแห่งนี้ เปิดให้บริการเฉพาะสมาชิกเท่านั้น ซึ่ง
     การเป็นสมาชิกนั้น มีวันหมดอายุ และข้อมูลส่วนตัวคือ ชื่อ ที่อยู่และ
     เบอร์โทร                                         Database Management System
                                                                           4.101


แบบฝึกหัดท้ายบทที่ 4(ต่อ)
   – สมาชิกแต่ละคนยืมหนังสือได้ครั้งละไม่เกิน 5 เล่ม
   – การยืม-คืนแต่ละครั้งจะต้องบันทึกด้วยว่ายืมวันใด จะต้องส่งหนังสือคืน
     เมื่อไร วันที่คืนหนังสือ และถ้าส่งช้ากว่ากาหนดต้องเสียค่าปรับ
 บรรณารักษ์ ต้องจัดทารายงานเพื่อสรุปในแต่ละเดือนและสมาชิกก็
  ต้องการบริการดังนี้
   – รายได้จากค่าปรับในแต่ละเดือน
   – แต่ละเดือนมีผู้มาใช้บริการห้องสมุดจานวนเท่าไร และยืมหนังสือเป็น
     จานวนกี่เล่ม
   – หนังสือในหมวดใดที่มีสมาชิกยืมมากสุด
   – สมาชิกมักจะค้นหาหนังสือที่ต้องการด้วยชื่อหนังสือ ชื่อผู้แต่งและ
     ISBN
                                                   Database Management System
                                                                                           4.102


     แบบฝึกหัดท้ายบทที่ 4(ต่อ)
     3. จงแปลง ER diagram จากข้อ 2 ให้เป็นตาราง
     4. จงแปลง ER เป็น Relation

หน่วยกิต
                                       1
                      ชื่อวิชา             เปิดสอน
                                                       M         วิชาที่เปิดสอน
                                                                                    สถานที่เรียน
           รหัสวิชา         ชื่อวิชา                          รหัสการเปิดสอน
                                                                                   เวลาเรียน
                                                     ปี-ภาค              กลุ่ม


                                                                   Database Management System
                                                                                4.103


               5. จงแปลง        ER เป็น Relation
               Product Code


Product Desc
        .
                                 be a component of

                    Product

                                                     m

                                        m
                                             Uses
                    be an assembly of

                                            Quantity
                                             Used

                        Bills of Material
                                                         Database Management System

								
To top