Usage of Weak Entities An Example of Ternary Relationship ...

¡¦¥¦¡¤§ ¨©¡¦ ¡¦¨¨¦£
¢¡¤£
¢¢¢¦¤
7¦9¦7¤: ;;;¦=8
6¢7¤8
C¢DC¢E¢F¦G@GF¤HIJ
@AB
a¦c¦a¤d efa¦g a¦heie¦gb
`¢a¤b
m¢nm¢o¢p¦qjqp¤rst
jkl
"¦$¦"¤% &'"¦( "¦)&*&¦(#
!¢"¤#
.¢/.¢0¢1¦2+21¤345
+,-
L¦N¦L¤O PQL¦R L¦SPTP¦RM
K¢L¤M
X¢YX¢Z¢[¦\U\[¤]^_
UVW
v¦x¦v¤y z{v¦| v¦}z~z¦|w
u¢v¤w
‚¢ƒ‚¢„¢…¦††…¤‡ˆ‰
€
Usage of Weak Entities
Database Modeling Using the Entity-
Relationship Model
(Continued)
• Weak Entity can be used when converting a
n-ary relationship to a number of binary
relationships.
• The basic algorithm can be found in the
previous lecture note.
• The additional ENTITY CLASS is actually
a weak entity.
An Example of Ternary Relationship
Converted E-R Diagram
SName
Quantity
ProjName
SName
Quantity
ProjName
SUPPLIER
SUPPLY
PROJECT
SUPPLIER
1 N N 1
SS SUPPLY SPJ
PROJECT
N
SP
PART
PartNo
1
PART
PartNo
What if defining a cardinality constraint
Converted E-R Diagram
SName
Quantity
ProjName
SName
Quantity
ProjName
SUPPLIER
1 M
SUPPLY
PROJECT
SUPPLIER
1 1 N 1
SS SUPPLY SPJ
PROJECT
N
N
SP
PART
PartNo
1
PART
PartNo
1

‹¦¦‹¤Ž ‹¦‘ ‹¦’“¦‘Œ
Š¢‹¤Œ
—¢˜—¢¢š¦›”›š¤œž
”•–
µ¦·¦µ¤¸ ¹ºµ¦» µ¦¼¹½¹¦»
´¢µ¤
Á¢ÂÁ¢Ã¢Ä¦Å¾ÅĤÆÇÈ
¾¿À
ߦá¦ß¤â ãäߦå ߦæãçã¦åà
ޢߤà
ë¢ìë¢í¢î¦ïèïî¤ðñò
èéê
¤¡ ¦¢¦ ¤£ ¤¥ ¦ ¦§¤¨¤ ¦¡
Ÿ¢
¬¢­¬¢®¢¯¦°©°¯¤±²³
©ª«
Ê¦Ì¦Ê¤Í ÎÏʦРʦÑÎÒΦÐË
ɢʤË
Ö¢×֢آ٦ÚÓÚÙ¤ÛÜÝ
ÓÔÕ
ô¦ö¦ô¤÷ øùô¦ú ô¦ûøüø¦úõ
ó¢ô¤õ
¢¡£ ¢¤¢¥§¦ý¨¦©¥££
ýþÿ
Design Principles
• Faithfulness
• Avoiding redundancy
• Keep it simple
• Picking the right kind of element
Faithfulness
• Include everything needs to be described.
• Avoid meaningless descriptions.
• Enforce as many constraints as possible.
– Cardinality Ratios.
– Participation Constraints
– Existence Dependency.
Cardinality Ratios
• The cardinality ratios for binary relationships
– 1:1, 1:N, N:1, and M:N
• Attributes of 1:1 relationship types can be migrated
to either of the participating entity types.
• Attributes of 1:N or N:1 relationship types can be
migrated only to the entity type at N-side of the
relationship.
• Attributes of M:N relationship types must be
specified as relationship attributes.
EMPLOYEE
Starting date
EMPLOYEE
EMPLOYEE
Examples
Manages
1 1
Starting date
Manages
1 1
Manages
1 1
DEPARTMENT
DEPARTMENT
DEPARTMENT
Starting date
Examples
Examples
EMPLOYEE
Hours
N
Works_on
1
Hours
PROJECT
EMPLOYEE
M
Works_on
N
PROJECT
EMPLOYEE
N
Works_on
1
PROJECT
Hours
Note:
IF we assumed that each employee can only work on one project, and there
may be many employees working on the same project, THEN:
The attribute Hours can be migrated to EMPLOYEE, but not PROJECT.
Note:
IF we assume that each employee may work on multiple projects at
the same time, and there may be many employees working on the
same projects, THEN:
The attribute Hours can not be migrated to either PROJECT or
EMPLOYEE.
2

§§ § §£§
¢
¢!£ ¢"¢#§$%¨$©#&£'£(
¨
§A§B CD§E §FC£GC§E@
>¢@
IJ K¢L£K¢M¢N§O%Ḧ O©NP£Q£R
Ḧ
i§k§il mni§o i§pm£qm§oj
h¢ij
u¢v£u¢w¢x§y%r¨y©xz£{£|
r¨st
*§,§*- ./*§0 *§1.£2.§0+
)¢*+
6¢7£6¢8¢9§:%3¨:©9;£

“§•§“– —˜“§ “§š—£›—§”
’¢“”
Ÿ¢ £Ÿ¢¡ ¢§£%œ¨£©¢¤£¥£¦
œ¨ž
½§¿§½À Á½§Ã ½§ÄÁ£ÅÁ§Ã¾
¼¢½¾
ɢʣɢˢ̧Í%ƨͩÌΣϣÐ
ƨÇÈ
ç§é§çê ëìç§í ç§îë£ïë§íè
æ¢çè
ó¢ô£ó¢õ¢ö§÷%ð¨÷©öø£ù£ú
ð¨ñò
¨§ª§¨« ¬­¨§® ¨§¯¬£°¬§®©
§¢¨©
´¢µ£´¢¢·§¸%±¨¸©·¹£º£»
±¨²³
Ò§Ô§ÒÕ Ö×Ò§Ø Ò§ÙÖ£ÚÖ§ØÓ
Ñ¢ÒÓ
ޢߣޢà¢á§â%Û¨â©áã£ä£å
Û¨ÜÝ
EMPLOYEE
Examples
(0,1) (1,1)
Manages
DEPARTMENT
EMPLOYEE
(0,N)
Examples
Dependents_of
What does this example imply
1 Manages 1
SSN
DEPENDENT
(1,1)
EMPLOYEE
What does this example imply
DEPARTMENT
name sex birthdate relationship
What does this example imply
Avoiding Redundancy
Examples
• Problem with redundancy
– Wastes space.
– Encourages inconsistency.
• Principle: describe and store everything
once only.
• Intuition: something is redundant if it could
be hidden from view, and you could still
figure out what it is from the other data.
name
BEERS
ManfBy
name
manf
BEERS
manfadd
Question: Which one is better
name
MANFS
address
KISS: Keep It Simple, Student
• Avoid intermediate concepts if unnecessary.
name
BEERS
ManfBy
name
MANFS
4