Transcript Entity types

บทที่ 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)
ได้