Requirements of a Conceptual Data Model Expressiveness: should be expressive enough to allow modeling of different types of relationships, objects and constraints of the miniworld. Simplicity: non-specialists should be able to understand Diagrammatic Representation: to ease interpretation Formality: There should be no ambiguity in the specification

1. Lecturer:
M.Zalmai “Rahmani”
rahmani.zalmai@gmail.com
Advanced Database Systems
Conceptual Modeling of Data
Lecture 02
Azma Institute
Database Department

2. Database Design Process
high level specs
conceptual schema
logical schema
(in DBMS model)
miniworld
conceptual design
logical design
physical design
functional analysis
application design
transaction implementation
Data requirementsfunctional requirements
application programs Physical schema
Requirement Analysis
Functional Design Database Design

3. Requirements of a Conceptual
Data Model
Expressiveness: should be expressive enough to allow modeling of
different types of relationships, objects and constraints of the miniworld.
Simplicity: non-specialists should be able to understand
Diagrammatic Representation: to ease interpretation
Formality: There should be no ambiguity in the specification

4. Entiities and Entity Sets
Entities
• nouns, ‘things’ in the world.
• E.g., students, courses, employees, departments, flights,
patients, ...
Attributes
• properties of entities.
• E.g., course name, deptname, departure time, age,
room#, ...
Entity set -- a set of entities that have the same attributes.
• an entity set is similar to a class, and an entity similar to an
instance

5. Attributes
single-valued vrs multi-valued:
• color of car could be multi-valued
• salary of employee is single-valued
atomic vrs composite:
• age of a person is atomic
• address of a person could be composite
stored vrs derived:
• derived attributes are those that can be derived from other
attributes or entities, e.g., age can be derived from date of birth.
• All other attributes are stored attributes

6. Relationships
sam 62900 main austin
pat 62901 north urbana
259 10000
245 2400
364 200000
305 20000
customer
account
Relationship:
• association between multiple entities
Relationship Set:
• set if relationships over the same entity sets
Binary,Ternary, 4-nary, … relationship sets
Cust-Account
Relationship set

7. Visualizing ER Relationships as a
Table
Relationship Set Corresponding to the Relationship Cust-Account
Row in the table
represents the pair
of entities
participating in
the relationship
Customer Account
John 1001
Megan 1001
Megan 2001

8. ER Diagram -- graphical
representation of ER schema
customer custacct account
cust name
ssno
street
city
acct number
balance
opening date
 Entity set -- rectangles; attributes -- ellipses; dashed ellipse -- derived
attribute; double ellipse -- multivalued attribute; relationship set --
diamonds; lines connect the respective relationship set with entity sets;
 Relationship sets may have 1 or many attributes associated with them --
known as relationship attributes.

9. Roles in a Relationship
The function that an entity plays in a relationship is called its role
Roles are normally not explicitly specified unless the meaning of the
relationship needs clarification
Roles needed when entity set is related to itself via a relationship.
employee works for
manager
worker

10. Constraints on Entity Sets
Key Constraint:
• With each entity set a notion of a key can be associated.
• A key is a set of attributes that uniquely identify an entity in entity set.
• Examples:
• designer may specify that {ssno} is a key for a entity set customer
entity with attributes {ssno, accountno, balance, name, address}
• designer may specify that {accountno} is also a key , that is, no joint
accounts are permitted.
• Denoted in ER diagram by underlining the attributes that form a key
• multiple keys may exist in which case one chosen as primary key and
underlined. Other keys called secondary keys either not indicated or
listed in a side comment attached to the diagram.

11. Constraints on Relationship Sets
Consider binary relationship set R between entity sets A and B
One to one: an entity in A is associated with at most one entity in B, and an
entity in B is associated with atmost one entity in A.
• an employee has only one spouse in a married-to relationship.
Many to One: An entity in A is associated with at most one entity in B, an
entity in B is associated with many entities in A.
• an employee works in a single department but a department consists of
many employees.

12. Constraints on Relationship
Sets(Cont.)
Many to Many: An entity in A is associated with many entities in B, and an
entity in B is associated with many entities in A.
• A customer may have many bank accounts. Accounts may be joint
between multiple customers.

13. Multiplicity of Relationships
Many-to-one One-to-oneMany-to-many
multiplicity of relationship in ER diagram represented by an
arrow pointing to “one”

14. Multiplicity of Relationships
Many-to-one One-to-oneMany-to-many
multiplicity of relationship in ER diagram represented by an
arrow pointing to “one”

15. Many to Many Relationship
• Multiple customers can share an account
• Many accounts may have one owner
customer custacct account
opening date
Customer Account Start Date
John 1001 Jan 20th
1999
Megan 1001 March 16th
1999
Megan 2001 Feb 18th
1994
Customer Account Start Date
John 1001 Jan 20th
1999
Megan 1001 March 16th
1999
legallegal

16. Many to One Relationship
• In a Many-One relationship, relationship attributes can be
repositioned to the entity set on the many side.
customer custacct account
opening date
customer custacct account
opening date

17. One to One Relationship
1 customer can have 1 account.
One account can be owned by
1 customer
relationship attributes can be
shifted to either of the entity
sets
Customer Account Start Date
Megan 1001 March 16th
1999
Megan 2001 Feb 18th
1994
Illegal
Customer Account Start Date
John 1001 Jan 20th
1999
Megan 1001 March 16th
1999
Illegal
Customer Account Start Date
Megan 1001 March 16th
1999
John 2001 Feb 18th
1994
Legal
customer custacct account
opening date

18. Weak Entity Sets
Entity sets that do not have sufficient attributes to form a key are called
weak entity sets.
A weak entity set existentially depend upon (one or more) strong entity
sets via a one-to-many relationship from whom they derive their key
A weak entity set may have a discriminator (or a partial key) that
distinguish between weak entities related to the same strong entity
key of weak entity set = Key of owner entity set(s) + discriminator

19. Weak Entity Sets (Cont.)
customer custacct account
cust name
ssno
street
city
acct number balance
opening date
transaction
Trans#
log
• Transaction is a weak entity set
related to accounts via log
relationship.
• Trans# distinguish different
transactions on same account

20. Weak Entity Sets (Cont.)
customer custacct account
cust name
ssno
street
city
acct number balance
opening date
transaction
Trans#
log
• Transaction is a weak entity set
related to accounts via log
relationship.
• Trans# distinguish different
transactions on same account