บทที่ 5 ตัวแบบความสั มพันธ์ ของเอนทิตี อ. ดร. ชุรี เตชะวุฒิ CS (204)321 ระบบฐานข้อมูล 1 (Database System I) Outlines 1) Database design process 2) ER Model concepts 3) ER diagrams notation 4) 5) 6) 7) 8) 9) Relationships and relationship types Degree of relationship types Cardinality of relationships Cardinality constraints and cardinality ratio Weak entity types Transforming ER diagrams into relations Database Design Process DBMS-independent Miniworld Requirements collection & analysis Functional requirements Functional analysis High-level transaction specification Database requirements Conceptual design Conceptual schema DBMS-specific Logical design (Data model mapping) Application program design Transaction implementation Application programs Logical schema Physical design Internal schema ER Model Concepts ER model describes data as entities, relationships, and attributes. Three important concepts are: Entities and attributes Entity types and key attributes Relationships and relationships types Entities and attributes Entities Entities are specific objects or things in the mini-world that are represented in the database. An entity may be an object with a physical existence (for example, PERSON, CAR, HOUSE, or EMPLOYEE) or with a conceptual existence (for example, DEPARTMENT, PROJECT, JOB, or UNIVERSITY COURSE.) Attributes Attributes are properties used to describe an entity, for example an EMPLOYEE entity may have a Name, SSN, Address, Sex, and BirthDate. Entities and attributes Value A specific entity will have a value for each of its attributes, for example a specific employee entity may have Name=‘John Smith’, SSN=‘123456789’, Address=‘731 Fondren, Houston, TX’, Sex=‘M’, BirthDate=’09-JAN-55’. Each attribute has a value set (or data type) associated with it – e.g., integer, string, subrange, enumerated type, ..... Entities and attributes Types of attributes Simple VS. Composite Simple (or atomic) attributes: Attributes that are not divisible such as SSN and sex. Composite attributes: Attributes that can be divided into smaller subparts. For example, Address(Apt#, House#, Street, City, State, Zipcode, Country) or Name(FirstName, MiddleName, LastName). Entities and attributes Types of attributes (Continued) Single-valued VS. Multi-valued Single-valued attributes: An attribute that has a single value, such as Age of person. Multivalued attributes: Attributes that have numbers of values. For example, Color of a car or PreviousDegrees of a STUDENT. Denoted as {Color} and {PreviousDegrees}. Stored VS. Derived Stored attributes: e.g., BirthDate Derived attributes: It is derivable from stored attribute.; such as Age Null-valued attribute: An attribute that it’s attribute value exists but is missing, or is unknown whether the attribute value exists. Entity types and key attributes Entity types A set of entities that have the same attributes. Each entity type in the database is described by a name and a list of attributes. Example of entity type Entity type name: EMPLOYEE Ssn, Name, Age, Salary Attributes: Entity set: • e1 (152056009, John Smith, 55, 80k) (Extension) • e2 (123098987, Fred Brown, 40, 30k) • e3 (143024992, Judy Clark, 25, 20k) … Entity types and key attributes Entity types (Continued) ER diagrammatic notation Use a rectangular box enclosing the entity type name. Attribute names are enclosed in ovals and are attached to their entity type by straight lines. Composite attributes are attached to their component attributes by straight lines. Multivalued attributes are displayed in double ovals. Entity types and key attributes Entity types (Continued) Example of ER diagram EMPLOYEE Salary Ssn Name Age Entity types and key attributes Key attributes Attributes of whose values are distinct for each individual entity and its values can be used to identify each entity uniquely. A key attributes may be composite. Example key attributes Entity type PERSON CAR Key attribute Social Security Number Registration (Number + State) ER diagrammatic notation Each key attribute has its name underlined inside the oval. Entity types and key attributes Key attributes (Continued) Example of ER diagram EMPLOYEE Salary Ssn Name Age Exercise Requirements for CAR are as followings: 1) 2) 3) 4) CAR is an entity type. Registration is a key attribute consisting of RegistrationNumber and State. Other important attributes for a car are VehicleID, Make, Model, Year. A car can have more than one Color. Possible attribute values for CAR entity type: car1 ABC 123 TEXAS TK629 Ford Mustang Convertible 1989 red, black car2 ABC 123 NEW YORK WP9872 Nissan Sentra 2-door 1992 blue car3 VSY 720 TEXAS TD729 Chrysler LeBaron 4-door 1993 white, blue … … … … … … … … Exercise Answer the following questions: 1) 2) 3) 4) What is the name of your entity type? What are the attributes for the entity type? What are the types of each attributes? Write ER diagram from the requirements above. Exercise CAR Entity type name: Attributes: Registration(RegistrationNumber, State), VehicleID, Make, Model, Year, {Color} Entity set: (Extension) • car1 ((ABC123, TEXAS), TK629, Ford Mustang, Convertible, 1989, {red, black}) • car2 ((ABC123, NEW YORK), WP9872, Nissan Sentra, 2-door, 1992, {blue}) • car3 CAR ((VSY720, TEXAS), TD729, Chrysler LeBaron, 4-door, 1993, {white, blue}) … Exercise ER diagram CAR Registration Number Color State Year Model VehicleID Make ER diagram notation ENTITY TYPE WEAK ENTITY TYPE RELATIONSHIP TYPE IDENTIFYING RELATIONSHIP TYPE ATTRIBUTE KEY ATTRIBUTE MULTIVALUED ATTRIBUTE COMPOSITE ATTRIBUTE DERIVED ATTRIBUTE Example of COMPANY Database Requirements for the COMPANY database The company is organized into DEPARTMENTs. Each department has a name, number, and a employee who manages the department. We keep track of the start date of the department manager. A department may have several locations. Each department controls a number of PROJECTs. Each project has a name, number, and is located at a single location. We store each EMPLOYEE’s social security number, address, salary, sex and birth date. Each employee works for one department but may work on several projects. We keep track of the number of hours per week that an employee currently works on each project. We also keep track of the direct supervisor of each employee. Each employee may have a number of DEPENDENTs. For each dependent, we keep their name, sex, birth date, and relationship to the employee. ER diagram of COMPANY database กฎธุรกิจ (Business rule) การพัฒนาตัวแบบข้อมูลให้มีความถูกต้องนั้น นอกจากผูอ้ อกแบบฐานข้อมูลจะต้องเข้าใจ ข้ อมูลขององค์ กรอย่างดีแล้ว ยังต้องเข้าใจกฎเกณฑ์ การทางานหรือระเบียบปฏิบัติที่กาหนด ขึน้ ขององค์ กรนั้นๆ กฎเกณฑ์เหล่านี้เรี ยกว่า “กฎธุรกิจ” กฎธุรกิจไม่เป็ นเอกภาพ (Universal) แต่ละองค์กรมีกฎเกณพ์หรื อนโยบายแตกต่างกัน และสามารถเปลี่ยนแปลงได้ ตัวแบบข้อมูลจะต้องมีความสัมพันธ์กนั กับกฎธุรกิจ ถึงแม้วา่ ตัวแบบข้อมูลจะไม่ สามารถแสดงกฎธุรกิจได้ท้ งั ทั้งหมดก็ตาม กฎธุรกิจ (Business rule) ตัวอย่างของกฎธุรกิจ เช่น นักศึกษาจะลงทะเบียนวิชาหนึ่ งได้กต็ ่อเมื่อได้สอบผ่านวิชาที่ตอ้ งผ่านก่อนของวิชา นั้นๆแล้ว ลูกค้าของสหกรณ์จะเป็ นเจ้าของบัญชีเงินฝากได้เพียงบัญชีเดียวและแต่ละบัญชีตอ้ งมี เจ้าของเพียงคนเดียว ให้พนักงานทุกคนแต่งกายในชุดประจาชาติทุกวันศุกร์ ในระหว่างการพัฒนาตัวแบบอีอาร์ เราอาจนากฎเหล่านี้ประยุกต์ใช้ได้ เนื่องจากกฎบาง กฎบ่งบอกถึงความสัมพันธ์ระหว่างเอนทิตี หรื อค่าของคาร์ดินลั ลิตีการมีส่วนร่ วมใน ความสัมพันธ์ หรื อกฎความคงสภาพอื่น แต่กฎบางกฎอาจนาไปแสดงในตัวแบบข้อมูล ไม่ได้ เช่น ตัวอย่างของกฎธุรกิจ ข้อสุ ดท้าย เป็ นต้น Relationships and relationship types Relationships A relationship relates two or more distinct entities with a specific meaning. e.g. EMPLOYEE “John Smith” works on “the Product X” PROJECT. EMPLOYEE “Franklin Wong” manages “the Research” DEPARMENT. Relationship types A relationship type defines a set of associations among entities. e.g. WORKS_ON relationship type in which EMPLOYEEs and PROJECTs participate. MANAGEs relationship type in which EMPLOYEEs and DEPARMENTs participate. Relationships and relationship types Relationship instances Each relationship type R consists of relationship instances ri . Example of relationship type WORKS_FOR between two entity types EMPLOYEE e1 WORKS_FOR r1 DEPARTMENT d1 e2 r2 d2 e3 r3 d3 e5 r4 … r5 … e4 … Relationships and relationship types ER diagrammatic notation Use a diamond-shaped box to display a relationship type enclosing the relationship name. It must be connected by straight lines to the rectangular boxes representing the participating entity types. Relationships and relationship types Example of ER diagram EMPLOYEE WORKS_FOR PROJECT Name Ssn Number Name Location Age Salary Degree of relationship types It is the number of participating entity types. Three kinds of degree of a relationship type: Unary relationship Binary relationship Ternary relationship More than one relationship type can exist with the same participating entity types. e.g. MANAGES and WORKS_FOR are distinct relationships between EMPLOYEE and DEPARTMENT participate. Degree of relationship types Unary One entity related to another of the same entity type. Binary Entities of two different types related to each other. Ternary or n-ary Entities of three different types related to each other. Cardinality of relationships one - to - one Each entity in the relationship will have exactly one related entity. one - to - many An entity on one side of the relationship can have many related entities, but an entity on the other side will have a maximum of one related entity. many - to - many Entities on both sides of the relationship can have many related entities on the other side. Cardinality constraints and cardinality ratio Cardinality constraints The number of instances of one entity that can or must be associated with each instance of another entity. Cardinality ratio (or Relationship participant) คือ การบ่งบอกลักษณะของความสัมพันธ์ที่ละเอียดมากขึ้นกว่าการระบุคาร์ดินลั ลิตี ทาให้ทราบจานวนเอนทิตีต่าที่สุดและสู งที่สุดที่สัมพันธ์กบั เอนทิตีในอีกเซตหนึ่ง Minimum cardinality - If zero, then optional. - If one or more, then mandatory. Maximum cardinality - The maximum number Cardinality constraints and cardinality ratio ความสั มพันธ์ แบบบังคับ (Mandatory relationship) เป็ นความสัมพันธ์ที่เกิดขึ้นเมื่อเอนทิตีทุกตัวของเซตต้องมีส่วนร่ วมในความสัมพันธ์ ของเอนทิตีเซตเสมอ ความสั มพันธ์ แบบทางเลือก (Optional relationship) เป็ นความสัมพันธ์ที่เกิดขึ้นเมื่อมีเอนทิตีบางตัวไม่มีส่วนร่ วมในความสัมพันธ์ของ เอนทิตีเซต Example ร้านให้เช่าวิดีโอเก็บสต็อกของวิดีโอ (VDO) ที่ผลิตจากภาพยนตร์ (MOVIE) โดย ภาพยนตร์หนึ่งเรื่ องจะนาไปจัดทาเป็ นม้วนวิดีโอสู งสุ ด 20 ม้วนหรื อไม่จดั ทาเลย และ วิดีโอหนึ่งม้วนสร้างจากภาพยนตร์ เพียงหนึ่ งเรื่ องเท่านั้น MOVIE MOVIE MOVIE 1 (0,20) 1 make make make N (1,1) N VDO VDO VDO Cardinality constraints and cardinality ratio Cardinality ratio (Continued) 1 Mandatory one N Mandatory many 1 Optional one N Optional many Cardinality constraints and cardinality ratio Cardinality ratio (Continued) Mandatory one Mandatory many Optional one Optional many Cardinality constraints and cardinality ratio Cardinality ratio (Continued) สัญลักษณ์ที่ใช้กาหนดคาร์ ดินลั ลิตีในตัวแบบอีอาร์ มีดงั นี้ 1. Chen’s model 1 1 1 N M N 2. Crow’s foot model 3. IDEF1X (Integrating Definition for Information modeling) ใช้จุดแทนความสัมพันธ์ดา้ น many 4. Rein85 แทนความสัมพันธ์ดา้ น many แทนความสัมพันธ์ดา้ น one Examples of unary relationships PERSON is_married_to one-to-one EMPLOYEE manages one-to-many Examples of binary relationships EMPLOYEE is_assigned PARKING PLACE one-to-one PRODUCT LINE contains PRODUCT one-to-many STUDENT registers_for many-to-many COURSE Examples of ternary/n-ary relationships COMPANY M sell N PRODUCT P COUNTRY • ใช้เมื่อความสัมพันธ์แบบไบนารี ไม่สามารถอธิ บายความสัมพันธ์ระหว่าง 3 เอนทิตีได้ และสอดคล้องกับความเป็ นจริ งมากกว่า • บริ ษทั ส่ งสิ นค้าไปจาหน่ายยังประเทศต่างๆทัว่ โลก และสิ นค้าชนิดเดียวกันอาจมีราคา ต่างกันเมื่อส่ งไปขายต่างประเทศกัน บริ ษทั จะส่ งสิ นค้าไปบางประเทศเท่านั้นขึ้นอยูก่ บั ประเภทสิ นค้า Examples of ternary/n-ary relationships Occurrence diagram PRODUCT p1 COMPANY c1 r1 p2 p3 r2 c3 r3 … c2 COUNTRY s1 … s2 … s3 … ความสั มพันธ์ ทพี่ ฒ ั นามาจากแอททริ บิวต์ บางครั้งเอนทิตีหรื อความสัมพันธ์ของเอนทิตีอาจมีจุดเริ่ มต้นมาจากแอททริ บิวต์ของเอนทิ ตี ตัวอย่างเช่ น หน่วยอาคารสถานที่ตอ้ งการเก็บข่อมูลเกี่ยวกับการใช้จกั รยานยนต์ของ นักศึกษา โดยจะบันทึกข้อมูลของนักศึกษาได้แก่ รหัสประจาตัว ชื่อ ที่อยูแ่ ละข้อมูลของ รถจักรยานยนต์ที่นกั ศึกษาเป็ นเจ้าของ std_name address std_code motorcycle STUDENT ความสั มพันธ์ ทพี่ ฒ ั นามาจากแอททริ บิวต์ จากการสารวจพบว่า นักศึกษาส่ วนใหญ่ไม่ได้เป็ นเจ้าของรถจักรยานยนต์ ดังนั้นค่าของ แอททริ บิวต์ motorcycle ส่ วนใหญ่จะเป็ นค่าว่าง (Null) นอกจากนี้ยงั ต้องการเก็บ ข้อมูลเฉพาะของแอททริ บิวต์น้ ีเพิ่มอีก เช่น ทะเบียนรถ ยีห่ อ้ และรุ่ นเป็ นต้น ในกรณี เช่นนี้ motorcycle ควรเป็ นเอนทิตีมากกว่าแอททริ บิวต์ std_name address std_code STUDENT 1 model license own make 1 MOTORCYCLE Multiple relationship เอนทิตี 2 เอนทิตีอาจมีความสัมพันธ์มากกว่า 1 แบบ work_in N 1 PERSON DIVISION 1 manage 1 เอนทิตี PERSON ทางานในแผนกหนึ่ ง และในขณะเดียวกันมีบางคนที่เป็ นผูจ้ ดั การ ของแผนกด้วย Weak entity types โดยทัว่ ไปเอนทิตีเซตแบ่งเป็ น 2 ประเภท 1. Strong/Independent entity คือ เอนทิตีเซตที่สามารถเกิดขึ้นได้โดยอิสระ และมีตวั ชี้เฉพาะเพื่อบ่งชี้เอนทิตีเสมอ 2. Weak/Dependent entity คือ เอนทิตีเซตแบบอ่อนที่ไม่สามารถเกิดขึ้นได้ดว้ ยตัวเอง และต้องพึ่งพาเอนทิตีเซต อื่นเสมอ ไม่มีตวั ชี้เฉพาะของตัวเอง Weak entity types An entity that does not have a key attribute. A weak entity must participate in an identifying relationship type with an owner or identifying entity type. Entities are identified by the combination of: A partial key of the weak entity type The particular entity they are related to in the identifying entity type Example: Suppose that a DEPENDENT entity is identified by the dependent’s first name and birhtdate, and the specific EMPLOYEE that the dependent is related to. DEPENDENT is a weak entity type with EMPLOYEE as its identifying entity type via the identifying relationship type DEPENDENT_OF. Weak entity types EMPLOYEE 1 DEPENDENTS _OF N DEPENDENT EMPLOYEE(fname, lname, ssn, bdate, address, sex, salary, superssn, dno) DEPENDENT(essn, dependent_name, sex, bdate, relationship) Partial key/identifier สัญลักษณ์แทน สัญลักษณ์แทน Weak entity type Identifying relationship type Attribute variation หรื อ การสร้างตัวแบบสาหรับข้อมูลที่แปรตามกาลเวลา เอนทิตีแบบอ่อนสามารถนามาประยุกต์ใช้ เมื่อแอททริ บิวต์บางตัวมีค่าแปรเปลี่ยนตาม เวลา (Time-dependent attribute) บางครั้งเรี ยก Historical attribute ตัวอย่ าง ต้องการติดตามการพัฒนาสุ ขภาพของสถานเลี้ยงเด็กกาพร้า โดยรวบรวม ข้อมูลความสู ง และน้ าหนักของเด็กที่เปลี่ยนแปลงในแต่ละเดือน PERSON 1 develop N PERSON(person_id, name, date_of_birth) DEVELOP(person_id, date_measured, weight, height) WEIGH_ HEIGH Composite/Associative entity หรื อ เอนทิตีประกอบ เป็ นเอนทิตีที่นาตัวชี้เฉพาะของเอนทิตีอื่น 2 ตัวหรื อมากกว่ามาประกอบกันเป็ นตัวชี้ เฉพาะของตัวเอง ซึ่ งเอนทิตีประเภทนี้มกั จะมาจากความสัมพันธ์แบบ M:N STUDENT STUDENT 1 1 N REGISTRY N REGISTRY N 1 COURSE COURSE Composite/Associative entity กาหนดตัวชี้เฉพาะของเอนทิตีประกอบได้ 2 วิธี 1. Default identifier นาตัวชี้เฉพาะของเอนทิตีประกอบเดิมมาผสมกัน เช่น {std_code, crs_code} สร้างตัวชี้เฉพาะขึ้นมาใหม่ ในกรณี ที่พบว่าค่า default identifier มีโอกาสซ้ ากันหรื อมีตวั ชี้เฉพาะที่ผใู ้ ช้คุน ้ เคยอยูแ่ ล้ว เช่น {reg_no} 2. Surrogate identifier Transforming ER Diagrams into Relations Step 1: Mapping Regular Entities to Relations Step 2: Mapping Weak Entities Step 3: Mapping Unary/Binary Relationships Step 4: Mapping Multivalued attributes Step 5: Mapping N-ary Relationship Types. Transforming ER Diagrams into Relations 1. Mapping Regular Entities to Relations Simple attributes: ER attributes map directly onto the relation Composite attributes: Use only their simple, component attributes Multi-valued attributes: Becomes a separate relation with a foreign key taken from the superior entity Example: We create the relations EMPLOYEE, DEPARTMENT, and PROJECT in the relational schema corresponding to the regular entities in the ER diagram. SSN is a primary key for the relation EMPLOYEE DNUMBER is a primary key for the relation DEPARTMENT and PNUMBER is a primary key for the relation PROJECT. Transforming ER Diagrams into Relations Figure 3.2: The ER conceptual schema diagram for the COMPANY database. Transforming ER Diagrams into Relations 2. Mapping Weak Entities Becomes a separate relation with a foreign key taken from the parent entity. Primary key composed of: Partial identifier of weak entity type Primary key of identifying entity type (strong entity type) Example: Create the relation DEPENDENT in this step to correspond to the weak entity type DEPENDENT. Include the primary key SSN of the EMPLOYEE relation as a foreign key attribute of DEPENDENT (renamed to ESSN). The primary key of the DEPENDENT relation is the combination {ESSN, DEPENDENT_NAME} because DEPENDENT_NAME is the partial key of DEPENDENT. Transforming ER Diagrams into Relations 3. Mapping Binary Relationships One-to-One: Primary key on the optional side becomes a foreign key on the mandatory side. Example: The 1:1 relation MANAGES is mapped by choosing the entity type EMPLOYEEE as the optional side and DEPARTMENT as the mandatory side. We include the primary key of the EMPLOYEE relation as foreign key in the DEPARTMENT relation and rename it MGRSSN. We also include the simple attribute StartDate of the MANAGES relationship type in the DEPARMENT relation and rename it MGRSTARTDATE. Transforming ER Diagrams into Relations 3. Mapping Binary Relationships One-to-Many: Primary key on the one side becomes a foreign key on the many side. Example: The 1:N relationship types WORKS_FOR, CONTROLS, and SUPERVISION in the figure. For WORKS_FOR we include the primary key DNUMBER of the DEPARTMENT relation as foreign key in the EMPLOYEE relation and call it DNO. Transforming ER Diagrams into Relations 3. Mapping Binary Relationships Many-to-Many: Create a new relation with the primary keys of the two entities as its primary key Example: The M:N relationship type WORKS_ON from the ER diagram is mapped by creating a relation WORKS_ON in the relational database schema. The primary keys of the PROJECT and EMPLOYEE relations are included as foreign keys in WORKS_ON and renamed PNO and ESSN, respectively. Attribute HOURS in WORKS_ON represents the HOURS attribute of the relation type. The primary key of the WORKS_ON relation is the combination of the foreign key attributes {ESSN, PNO}. Transforming ER Diagrams into Relations 3. Mapping Unary Relationships และ One-to-Many: เอนทิตีเซตในความสัมพันธ์จะแปลงเป็ น หนึ่งรี เลชัน จากนั้นจึงเพิ่มคียน์ อก (ซึ่ งอ้างถึงคียห์ ลักของรี เลชัน) เข้าไปในรี เลชัน เดียวกันนี้ One-to-One supervisor 1 EMPLOYEE Example: EMPLOYEE(emp_code,emp_name) supervise N supervisee EMPLOYEE(emp_code, emp_name, supervisor_code) Transforming ER Diagrams into Relations 3. Mapping Unary Relationships Many-to-Many: แปลงเอนทิตีเซตในความสัมพันธ์เป็ นรี เลชัน จากนั้นสร้าง รี เลชันใหม่สาหรับความสัมพันธ์และบรรจุคียห์ ลักของเอนทิตีที่เกี่ยวข้องทั้งสอง บทบาท โดยตั้งชื่อให้แตกต่างกัน pre_course M COURSE Example: COURSE(crs_code, crs_name, crs_credit) pre_requisite N offered_course COURSE(crs_code, crs_name, crs_credit) PREREQUISITE(course_code, pre_crsCode) Transforming ER Diagrams into Relations 4. Mapping Multivalued attributes Create a new relation that includes a multivalued attribute plus the primary key attribute of the entity type - as a foreign key in R If the multivalued attribute is composite, we include its simple components. Example: The relation DEPT_LOCATIONS is created. The attribute DLOCATION represents the multivalued attribute LOCATIONS of DEPARTMENT. DNUMBER-as foreign key-represents the primary key of the DEPARTMENT relation. The primary key is the combination of {DNUMBER, DLOCATION}. Transforming ER Diagrams into Relations 5. Mapping N-ary Relationship Types. For each n-ary relationship type R, where n>2, create a new relationship S to represent R. Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types. Also include any simple attributes of the n-ary relationship type (or simple components of composite attributes) as attributes of S. Example: The relationship type SUPPLY in the ER below. This can be mapped to the relation SUPPLY shown in the relational schema, whose primary key is the combination of the three foreign keys {SNAME, PARTNO, PROJNAME} Transforming ER Diagrams into Relations Example of ternary relationship types: The SUPPLY relationship. Transforming ER Diagrams into Relations Mapping the n-ary relationship type SUPPLY Summary of Mapping Constructs and Constraints Correspondence between ER and Relational Models ER Model Entity type 1:1 or 1:N relationship type M:N relationship type n-ary relationship type Simple attribute Composite attribute Multivalued attribute Value set Key attribute Relational Model “Entity” relation Foreign key (or “relationship” relation) “Relationship” relation and two foreign keys “Relationship” relation and n foreign keys Attribute Set of simple component attributes Relation and foreign key Domain Primary (or secondary) key กฎความคงสภาพทีบ่ ังคับใช้ กบั ความสั มพันธ์ ระหว่ างตาราง การกาหนดเงื่อนไขบางอย่างสาหรับคียน์ อก เพื่อให้ขอ้ มูลมีความคงสภาพอยูเ่ สมอ มีวธิ ี การกาหนดตามการมีส่วนร่ วม (Relationship participation) ว่าเป็ นแบบบังคับ (Mandatory) หรื อแบบเลือก (Optional) ดังนี้ 1. คียห์ ลักของตารางต้องไม่เป็ นค่าว่าง (NOT NULL) 2. สาหรับเอนทิตีแบบอ่อน ซึ่ งมีคาร์ดินลั ลิตีแบบ 1:N โดยปริ ยาย และความสัมพันธ์ ด้านหนึ่งเป็ นแบบบังคับ ดังนั้นเงื่อนไขของคียน์ อกต้องไม่เป็ นค่าว่าง (NOT NULL) ลบแบบต่อเรี ยง (ON DELETE CASCADE) และแก้ไขแบบต่อเรี ยง (ON UPDATE CASCADE) กฎความคงสภาพทีบ่ ังคับใช้ กบั ความสั มพันธ์ ระหว่ างตาราง 3. สาหรับ Binary relationship ที่มีความสัมพันธ์แบบ 1:N Participation ค่ าของคีย์นอก Delete Update 1. แบบบังคับทั้งคู่ 2. แบบเลือกทั้งคู่ 3. แบบบังคับด้าน “1” และแบบเลือกด้าน “N” 4. แบบบังคับด้าน “N” และแบบเลือกด้าน “1” NN R C NA R หรื อ SN C NN R C NA R หรื อ SN C NN (NOT NULL) C (Cascade update) NA (NOT ALLOW) SN (Set to null) R (Restricted delete) กฎความคงสภาพทีบ่ ังคับใช้ กบั ความสั มพันธ์ ระหว่ างตาราง 3. สาหรับ Binary relationship ที่มีความสัมพันธ์แบบ 1:N ตัวอย่าง ADVISOR(adv_code, adv_name, office) STUDENT(std_code, std_name, major, adv_code) โดย adv_code ที่เป็ นคียน์ อกของตาราง STUDENT จะใช้ขอ้ 3 เป็ นเกณฑ์ ADVISOR 1 advise N STUDENT กฎความคงสภาพทีบ่ ังคับใช้ กบั ความสั มพันธ์ ระหว่ างตาราง 4. สาหรับ Binary relationship ที่มีความสัมพันธ์แบบ M:N Participation ค่ าของคีย์นอก Delete Update 1. แบบบังคับทั้งคู่ 2. แบบเลือกทั้งคู่ 3. ด้านนึงเป็ นแบบบังคับ และอีก ด้านนึงเป็ นแบบเลือก 3.1. คียห์ ลักด้านเลือก 3.2. คียห์ ลักด้านบังคับ NN R C NN C C NN C C NN R C กฎความคงสภาพทีบ่ ังคับใช้ กบั ความสั มพันธ์ ระหว่ างตาราง 4. สาหรับ Binary relationship ที่มีความสัมพันธ์แบบ M:N ตัวอย่าง STUDENT(std_code, std_name, major) SUBJECT(subj_code, subj_name) REGISTRATION(std_code, subj_code, mark) M STUDENT STUDENT 1 N take N REGISTRATION N SUBJECT 1 จะใช้ขอ้ 3 เป็ นเกณฑ์ โดย std_code ของตาราง REGISTRATION ใช้เกณฑ์ 3.1. และ subj_code ของตาราง REGISTRATION ใช้เกณฑ์ 3.2. SUBJECT กฎความคงสภาพทีบ่ ังคับใช้ กบั ความสั มพันธ์ ระหว่ างตาราง 5. สาหรับ Binary relationship ที่มีความสัมพันธ์แบบ 1:1 Participation ค่ าของคีย์นอก Delete Update 1. แบบบังคับทั้งคู่ 2. แบบเลือกทั้งคู่ 3. ด้านใดด้านนึงเป็ นแบบบังคับ 3.1. คียน์ อกด้านเลือก NN R C NA SN C NN R C กฎความคงสภาพทีบ่ ังคับใช้ กบั ความสั มพันธ์ ระหว่ างตาราง 5. สาหรับ Binary relationship ที่มีความสัมพันธ์แบบ 1:1 ตัวอย่าง STUDENT(std_code, std_name, major) PROJECT(proj_id, proj_title, date_completed, std_code) STUDENT 1 complete 1 PROJECT จะใช้ขอ้ 3 เป็ นเกณฑ์ โดย std_code ที่เป็ นคียน์ อกของตาราง PROJECT ใช้เกณฑ์ 3.1. การสร้ างพจนานุกรมข้ อมูล (Data dictionary) ก่อนที่จะสร้างฐานข้อมูลจริ งโดยใช้ระบบจัดการฐานข้อมูล เราสามารถสร้าง พจนานุกรมข้อมูล เพื่อกาหนดรายละเอียดเกี่ยวกับโครงสร้างของตาราง และความสัมพันธ์ระหว่างตาราง การสร้ างพจนานุกรมข้ อมูล (Data dictionary) ชื่อตาราง ชื่อแอททริบวิ ต์ ความหมาย STUDENT std_code รหัสประจำตัว นักศึกษำ std_name ชื่อนักศึกษำ PROJECT proj_id รหัสโปรเจค ชนิดข้ อมูล CHAR(10) เป็ นค่ าว่ าง คีย์ รีเลชั่นที่อ้างึง ไม่ได้ PK CHAR(30) ไม่ได้ NUMBER(4) ไม่ได้ FK proj_title ชื่อโปรเจค CHAR(60) ไม่ได้ PK std_code รหัสนักศึกษำที่เป็ น CHAR(10) เจ้ ำของโปรเจค ไม่ได้ FK STUDENT date_complete วันที่ทำโปรเจค DATE(4) ได้