Conceptual Database Design

Conceptual DB Design
• Conceptual design produces an abstract model
of data to be included in the database
• Centers on
– “what kind of objects a database contains”
– and not on “how these objects are stored”
• ( Internal Schema)
– and not on “how these objects are represented /
displayed to a person that accesses the database”
• ( External Schema).
• Model is an abstraction of reality, a simplified
representation of some real world phenomenon
Continued…
• This model
– is independent of any database management
system and data model
– is based on some dedicated modeling technique
• (Entity-Relationship, UML)
• The result of this phase identifies:
1. the types of objects about which data will be collected
2. the properties of objects that will be presented as data
items
3. dependencies among objects and data items that should
be reflected in the database
 Entity – Relationship (ER) model
• Popular high-level conceptual data model
• Description of the data requirements of
users
• Concepts like:
– entities
– attributes
– relationships and
– constraints are used in this model

• It is a top-down approach
 Entity, Attributes, & Relationships

• Entity
– It is a basic object which an ER model
represents
– It is the thing about which an organization
wants to keep data
– It is an aggregation of a number of data
elements where each data element is an
attribute of the entity
Continued…
• Attributes
– Each entity has attributes – the particular
properties that describe it. e.g. name is
an attribute of the entity STUDENT
– An entity has a value for each of its
attributes
– The legal values of an attribute are
specified by a domain E.g. legal values
of a Sex attribute may be the values “M”
and “F”
Continued…
• Relationship
– an association between two or more entities
that is of particular interest
• Entity type
– a group of objects with the same properties,
which are identified by the enterprise as
having an independent existence.
Continued…
• Entity instance (occurrence) -- a specific
entity, e.g. “Student number RSC001/00”
• Note: “entity” may be used to mean
“entity instance”
• Strong entity type –
• Does not depend on anything else in the
database for its existence. It contains its own
primary key.
Continued…
• Weak entity type
– depends on some related entity for its
existence. It has no candidate keys
without including the primary key of the
entity it depends on.
• All entities / relationships of the same type
have the same attributes
Has 
Staff Dependent
Diagrammatic representation of entity types
UML Notation Meaning

EntityName Entity

EntityName
Entity with primary key {PK} attributes
AttributeName

Entity Name
Entity with attributes. The primary key attribute is
labeled with {PK}. Any alternate keys are labeled
attributeName {PK} with {AK}. Components of composite attributes
attributeName {AK} are listed below and indented to the right.
attributeName Derived attributes are identified with / at start of
attributeName attribute name. Multi-valued attributes are labeled
attributeName
with the range of possible values
/attributeName
attributeName {min .. max} {min .. max} for attribute.
…
 Continued…
UML Notation Meaning

RelationshipName  Relationship labeled with relationship

name and directional arrow

Relationship with multiplicity

(minValue … maxValue) (minValue … maxValue)
constraints (minValue …
maxValue)
RelationshipName 
EntityName EntityName Binary relationship

EntityName

Relationship EntityName
ternary relationship
EntityName Name
 Relationship
• Relationship type - a set of meaningful
associations among entity types
Has 
Branch Staff

• Degree of Relationship
– the number of participating entities in a
relationship
• Relationship of degree one is called unary/recursive
– A recursive relationship is a relationship where the same entity type
participates more than once in different roles.
• Relationship of degree two is called binary
• Relationship of degree three is called ternary
• Relationship of degree four is called quaternary (rare
occurrence)
Relationship continued…
Client

Staff Registers Branch

A staff registers a client at a branch (Ternary

relationship)

 Supervises

Supervisor Each entity participates in a

relationship type plays a
Staff particular role in the
Supervisee relationship (unary
relationship)
 Attributes on Relationships
• Attributes can also be assigned to relationships
• Therefore we can define attributes as properties of an
entity or a relationship

Advertises 
NewPaper ProperyForRent

DateAdvertised
Cost
 Key attributes
• Candidate key –a minimal set of attributes that
uniquely identifies each occurrence of an entity type
– e.g. StaffNo and SSN
• Primary Key – Candidate key that is elected to
uniquely identify each occurrence of entity types
• e.g. StaffNo
• Composite key – A candidate key that consists
of two or more attributes

Staff
StaffNo {PK}
…
 Structural Constraints
• Constraints that may be placed on entity types
that participate in a relationship
– restrictions on the relationships as perceived in the
‘real world’
Multiplicity (min..max)
The number (range of possible occurrences)
• it represents the maximum and minimum number of
entities of one entity type associated with an entity of
another entity type through a particular relationship.
• it represents one of the policies or business rules of
an enterprise
• it consists of two separate constraints, known as
• cardinality and
• participation
Structural constraints…
1. Cardinality: The maximum number of possible
relationship occurrences for an entity participating in a
given relationship type.
In binary relationship there are:-
– one-to- one (1:1) relationship
• an entity of one entity type can be associated with only one
entity of another entity type and vise versa

Manages 
Staff Branch
1..1 0..1

Members of a staff can

manage zero or one
a branch always has multiplicity branch
one manager
Structural constraints…

– One-to-many (1:N) relationship

• an entity of one entity type can be associated with many
entities of another entity type but entity of the second entity
type can be associate with only one entity of the first entity
type

oversees 
Staff Property for rent
0..1 0..*

Each staff oversees 0 or

more property for rent
every propertyforrent is multiplicity
overseen by 0 or 1
staff
Structural constraints…
– Many-to-many (M:N) relationship
• an entity of one entity type can be associated with many
entities of another entity type and vise versa

advertises 
Newspaper Property for rent
0..* 1..*

Each newspaper
advertises one or more
every propertyforrent is multiplicity property for rent
advertised by zero or
more newspaper
Structural constraints…
2. Participation: Determines whether all or only some entity
occurrence participate in a relationship

There are two types of participation:

– mandatory
• All entities of the appropriate type must participate in this
relationship (e.g. every branch must have a manager)
– optional
• Some entities of the appropriate type participate in this
relationship (e.g. some employees manage branches)

Manages 
Staff Branch
1..1 0..1
Structural constraints…
• Note that:
– Multiplicity = Cardinality & Participation
– If min = 0, optional participation. If min > 0,
mandatory participation
– If both sides have max=1, 1:1 cardinality
– If both sides have max>1, M:N cardinality
– Otherwise 1:N or N:1, that is, one-to-many or
many-to-one cardinality, depending on which
side has max > 1
 Alternative ER Modeling Notation
Chen Notation for ER Modeling Crow’s Feet Notation for ER Modeling

Strong Entity Entity Name

Entity Name
Weak Entity Entity Name

Relationship Relation
ship
Relationship name
Relationship associated
with a weak entity Relation
ship
Relationship name

Recursive Relationship
Role name Role name Role name
Relation
ship Entity Name Entity Name

Role name
 Chen Notation for ER Modeling Crow’s Feet Notation for ER Modeling

attribute
Attribute Entity Name
attribute AttributeName1
Primary key attribute [derivedAttribute]
Multi-valued attribute attribute {multivaluedAttribute}
compositeAttribute(…)
Derived attribute attribute
Attribute
Relationship name
One-to-one relationship 1 1

M Relationship name
One-to-many relationship 1

Relationship name
Many-to-many relationship N M

Mandatory for A and B 1 M Relationship

A B A B

Mandatory participation of B, M
1 Relationship
optional participation of A A B A B