Mapping ER To Table

Mapping ER Model to
Relational Model
Relational Database System
issarapong.khu@kmutt.ac.th 1
Conceptual Logical Physical
Schema Schema Schema
ER: Tables/Relations: File organisation:

• Entities, • column names/attributes • File types
• Relationships, • rows/tuples • Index structures
• Attributes
Table name
Column names
Product:
Name Price Category Manufacturer
gizmo ¥ 19099 gadgets GizmoWorks
Power gizmo ¥ 29099 gadgets GizmoWorks
SingleTouch ¥ 149099 photography Canon
MultiTouch ¥203099 household Hitachi
Rows
Table Relation over Sets
A1 A2 A3 ... An
C Attributes {(a1, a2, a3, …, an),
a
r
a1 a2 a3 an (b1, b2, a3, …, cn),
d b1 b2 a3 cn (a1, c3, b3, …, bn),
i Tuple
n a1 c3 b3 bn
...
a . (x1, v2, d3, …, wn)}
l .
i . Component
t
y x1 v2 d3 wn
Arity
In Databases: Distinguish between

• Schema (structure ) and
• Instance (content)
Relation Schemas
Example:
Product ( Prodname: Name,
A relation schema Price: DollarPrice,
Category: Name,
R(A1:D1, ..., An:Dn) Manufacturer: Name)
consists of
• a name, say R
• a nonemtpy set of attributes, say A1,..., An
• a type or domain, say Di = dom(Ai) , for each attribute Ai
Types and Domains
Type: Class of atomic values, e.g.,
• integers, reals, strings
• integers between 15 and 80,
strings of (up to) 50 characters
Domain: Set of atomic values, that have a specific meaning in an application,

e.g.,
• Name, EmployeeAge
• Domains have a type, e.g.,
• EmployeeAge = Int[15,80]
• Domains may have default values
Example
• Domain declaration:
Name=String(30), DollarPrice=Decimal (10,2),
• Relation schema:
Product(Prodname: Name, Price: DollarPrice,
Category: Name, Manufacturer: Name)
• Instance: Name Price Category Manufacturer
gizmo ¥ 19099 gadgets GizmoWorks
Power gizmo ¥ 29099 gadgets GizmoWorks
SingleTouch ¥ 149099 photography Canon
MultiTouch ¥203099 household Hitachi

Null Values
Attribute values Three meanings of null values
• are atomic 1. not applicable
• have a known domain 2. not known
• can sometimes be “null” 3. absent (not recorded)
studno name hons tutor year thesis title
s1 jones ca bush 2 null
s2 brown cis kahn 2 null
s3 smith null goble 2 null
s4 bloggs ca goble 1 null
s5 jones cs zobel 1 null
s6 peters ca kahn 3 “A CS Survey”
name
Conceptual Model: PRODUCT BUYS PERSON
price name ssn
Relational Model:
Mapping Entity Types to Relations
• For every entity type create a relation
• Every atomic attribute of the entity type becomes a relation attribute
• Composite attributes: include all the atomic attributes
• Derived attributes are not included
(but remember their derivation rules)
• Relation instances are subsets of the cross product of the domains of
the attributes
• Attributes of the entity key make up the primary key of the relation
Step 1
given family
roomno
staffname
name
STUDENT STAFF
studno
STUDENT (studno, givenname, familyname)
STAFF (roomno, staffname)
Step 2
given family
slot roomno
name staffname
m 1
STUDENT TUTOR STAFF
studno
TUTOR(studno, staffname, rommno, slot)

and
Foreign key TUTOR(studno) references STUDENT(studno)
Foreign key TUTOR(staffname, roomno) references STAFF(name, roomno)
STUDENT STAFF
studno given family tutor roomno slot staffname roomno
4001 fred jones bush 2.26 12B kahn cb206
4002 mary brown kahn cb206 12B bush 2.26
4003 sue smith goble 2.82 10A goble 2.82
4004 fred bloggs goble 2.82 11A zobel 2.34
4005 peter jones zobel 2.34 13B watson cb212
4006 jill peters kahn cb206 12A woods cb204
capon cb114
lindsey 2.10
barringer 2.125
STUDENT STAFF
studno given family staffname roomno
4001 fred jones kahn cb206
4002 mary brown bush 2.26
4003 sue smith goble 2.82
4004 fred bloggs zobel 2.34
4005 peter jones watson cb212
4006 jill peters woods cb204
capon cb114
TUTOR lindsey 2.10
studno staffname roomno slot barringer 2.125
4001 bush 2.26 12B
4002 kahn cb206 12B
4003 goble 2.82 10A
4004 goble 2.82 11A
4005 zobel 2.34 13B
4006 kahn cb206 12A
A well-formed data model
Six principles for high quality data models:
1. Entity types should represent, and be named 4. Relationships (in the entity/relationship
after, the underlying nature of an object, not the sense) should only be used to express the
role it plays in a particular context. involvement of entity types with activities or
associations.
2. Entity types should be part of a sub-
type/super-type hierarchy (“class hierarchy” if 5. Candidate attributes should be suspected of
you’re familiar with object-oriented terms) in order representing relationships to other entity types.
to define a universal context for the model.
6. Entity types should have a single
3. Activities and associations should be attribute as their primary unique identifier.
represented by entity types (not relationships). This should be artificial, and not changeable by the
user. Relationships should not be used as a part of
the primary unique identifier. (They may be part of
alternate identifiers.)
issarapong.khu@mail.kmutt.ac.th
15
Constraints: Definition
• A constraint is an assertion about the database that must be true at all times
• Constraints are part of the database schema
• Modeling Constraints
• Finding constraints is part of the modeling process. They reflect facts that hold in the world or
business rules of an organization.
• Examples:
• Keys: ID number uniquely identifies a person
• Single-value constraints: a person can have only one father
• Referential integrity constraints: if you work for a company, it must exist in the database
• Domain constraints: e.g., peoples’ ages are between 0 and 150
• Cardinality constraints: e.g., at most 100 students enroll in a course
issarapong.khu@mail.kmutt.ac.th 16
Keys
• A key is a set of attributes that uniquely identify an object or entity:
• Person:
• social-security-number (U.S.)
• national insurance number (U.K.)
• codice fiscale (Italy) (Why not “age”?)
• name
• name + address
• name + address + dob
• Perfect keys are often hard to find, so organizations usually invent something.
Variants of Keys
• Multi-attribute (composite) keys:
• E.g., name + address
• Multiple keys:
• E.g., social-security-number, name + address
Strong and Weak Entities
Dominating and subordinate types are modeled as
• Entities (also “strong”, or “identifying” entities)
customer
• Weak Entities Identifying CUSTOMER
entity address
1
Supporting, or CUST-ORDER
identifying
relationship m orderid
ORDER
Weak entity
date
Strong and Weak Entities
(Identifier Dependency)
• A strong entity type has an identifying primary key
• A weak entity’s key comes not (completely) from its own attributes, but from the keys of
one or more entities to which it is linked by a supporting many-one relationship
• A weak entity type does not have a primary key but does have a discriminator.
customer
CUSTOMER
address
1
CUST-ORDER
m orderid
ORDER
issarapong.khu@mail.kmutt.ac.th date 20
Weak Entities May Depend on Other Weak Entities
c-name
CUSTOMER •Strong entity type
address • Identifying entity for
1 ORDER
• Identifying entity for
CUST-ORDER
LINE_ITEM
m orderid
ORDER
date
1
ORDER-MAKEUP
•Weak entity
• Identifying entity for
m
lineno LINE_ITEM
LINE_ITEM
quantity • Weak entity type
Turning Relationships into Entities
• Relationship types are less natural if
• the relationships have many attributes, or
• we want to model a relationship with that relationship type
• Example:
exammark
labmark
m n
STUDENT ENROL COURSE
TUTOR
STAFF
Design Principles for ER Modeling
• There are usually several ways to model a • Redundancy wastes space and encourages
real-world concept, inconsistency
• “Don’t say the same thing more than once”’
e.g.:
• entity vs. attribute name name addr
• entity vs. relationship
• Etc. 1
Beer ManfBy Manufacture
• Design choices can have an impact on
• redundancies among the data that we
store
name manf
• integrity constraints captured by the
database structure
Beer Manf
addr
Entity Vs. Attribute
• The following design illustrates both points:
name manf name addr
1
Beer ManfBy Manufacture
• Manufacture deserves to be an entity because we record addr, a non-key attribute

• Beers deserves to be an entity because it is at the “many” end If not, we would have to
make “set of beers” an attribute of Manufacture
Entity Vs. Attribute: Rules of Thumb
• Only make an entity if either:
1. It is more than a name of something; i.e.,

it has non-key attributes or relationships with a number of different entities, or
2. It is the “many” in a many-one relationship
Hints for ER Modelling
• Identify entity types by searching for nouns and noun phrases.
• Assume all entities are strong and check for weak ones on a later pass.
• You need an identifier for each strong entity.
• Assume all relationships have optional participation and check for mandatory (total) ones
on a later pass.
• Expect to keep changing your mind about whether things are entities, relationships or
attributes
• Keep the level of detail relevant and consistent. (e.g., leave out attributes at first)
• Approach diagram through different views and merge them.
Assignment
• Design an ER-diagram that covers the requirements below.
• Do not forget to include cardinality and participation constraints.
• Requirements : A Music Record Database (JOOK)
• A music record app wishes to use a database to help with its operations regarding its performers,
recordings and song catalogue.
• Songs have a unique song number, a non-unique title and a composition date. A song can be written
by several composers; the composer’s full name is required. Songs are recorded by recording artists
(bands or solo performers).
• A song is recorded as a track of an album. An album has many songs on it, called tracks. Albums have a
unique record catalogue number, a title and must have a producer (the full name of the producer is
required). Each track must have the recording date and the track number of the album.
• A song can appear on many (or no) playlists and be recorded by many different recording artists. The
same recording artist might re-record the same song on different playlists. A playlist must have only 1
recording artist appearing on it. Playlists can be released several times, and each time the release date
and associated number of sales is required.

Mapping ER To Table

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mapping ER To Table

Uploaded by

Copyright:

Available Formats

Mapping ER Model to

Relational Database System

ER: Tables/Relations: File organisation:

gizmo ¥ 19099 gadgets GizmoWorks

Power gizmo ¥ 29099 gadgets GizmoWorks

SingleTouch ¥ 149099 photography Canon

MultiTouch ¥203099 household Hitachi

In Databases: Distinguish between

Domain: Set of atomic values, that have a specific meaning in an application,

gizmo ¥ 19099 gadgets GizmoWorks

Power gizmo ¥ 29099 gadgets GizmoWorks

SingleTouch ¥ 149099 photography Canon

MultiTouch ¥203099 household Hitachi

Conceptual Model: PRODUCT BUYS PERSON

price name ssn

STUDENT (studno, givenname, familyname)

STAFF (roomno, staffname)

TUTOR(studno, staffname, rommno, slot)

name manf name addr

• Manufacture deserves to be an entity because we record addr, a non-key attribute

1. It is more than a name of something; i.e.,

2. It is the “many” in a many-one relationship

You might also like