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

2

Continued

This model
is independent of any database management system and data model is based on some dedicated modeling technique
(Entity-Relationship, UML) the types of objects about which data will be collected the properties of objects that will be presented as data items dependencies among objects and data items that should be reflected in the database

The result of this phase identifies:

1. 2. 3.

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
4

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
6

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
Staff Has Dependent
9

Diagrammatic representation of entity types

UML Notation
EntityName EntityName AttributeName Entity Name

Meaning Entity

Entity with primary key {PK} attributes

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

attributeName {PK} attributeName {AK} attributeName attributeName attributeName /attributeName attributeName {min .. max}

10

Continued
UML Notation
RelationshipName

Meaning
Relationship labeled with relationship name and directional arrow

(minValue maxValue)

(minValue maxValue)

Relationship with multiplicity constraints (minValue maxValue)

EntityName

RelationshipName

EntityName

Binary relationship

EntityName

EntityName

Relationship Name

EntityName

ternary relationship

11

Relationship
Relationship type - a set of meaningful associations
among entity types
Branch

Has

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)
12

Relationship continued
Client

Staff

Registers

Branch

A staff registers a client at a branch (Ternary relationship)

Supervises Supervisor

Staff
Supervisee

Each entity participates in a relationship type plays a particular role in the relationship (unary relationship)

13

Attributes on Relationships
Attributes can also be assigned to relationships Therefore we can define attributes as properties of an entity or a relationship
NewPaper Advertises ProperyForRent

DateAdvertised Cost

14

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}
15

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
16

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 Consider the relationship Manages, which relates the Staff and Branch entity types Determining the multiplicity Determining the multiplicity normally requires examining the precise relationships between the data given in a enterprise constraint using sample data. The sample data may be obtained by examining filled-in forms or reports and, if possible, from discussion with users.

Note the sample data should be true representation of all the data being modeled 17

18

Note that for a 1:1 relationship, we may choose a relationship name that makes sense in either direction
19

Can u come up with 1:1 cardinality?

20

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

21

.
.

If we know the actual minimum and maximum values for the multiplicity, we can display these instead. For example, if a member of staff oversees a minimum of zero and a maximum of 100 properties for rent, we can replace the 0..* with 0..100.

Note: with 1:* relationships, we choose a relationship name that makes sense in the 1:* direction.
22

Can u come up with 1:* cardinality?

23

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
Semantic net showing four occurrences of the Newspaper Advertises PropertyForRent relationship type.

24

 (Note that for a *:* relationship, we maelationship name that makes sense in either direction

The multiplicity of the Newspaper Advertises PropertyForRent many-to-many (*:*) relationship.

Note that for a *:* relationship, we may choose a relationship name that makes sense in either direction
25

Can u come up with *:* cardinality?

26

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)
27

Cardinality and Participation Constraints

Multiplicity described as cardinality and participation constraints for the Staff Manages Branch (1:1) relationship.
28

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
29

Problems with ER Models

problems that may arise when creating an ER model.
These problems are referred to as connection traps.

Two main types of connection traps, called

Fan traps and Chasm traps

30

 Fan Traps
Where a model represents a relationship between entity types, but the pathway between certain entity occurrences is ambiguous. A fan trap may exist where two or more 1:* relationships fan out from the same entity.

Example:
two 1:* relationships (Has and Operates) emanating from the same entity called Division.
31

 An example of a fan trap.

An example of a fan trap.

32

The ER model restructured to remove the fan trap.

33

The semantic net of the updated ER model

34

 Chasm Traps
Where a model suggests the existence of a relationship between entity types, but the pathway does not exist between certain entity occurrences.

An example of a chasm trap.

35

The semantic net of the ER model

36

37

The semantic net of the ER model shown previously

38

Alternative ER Modeling Notation

Chen Notation for ER Modeling Strong Entity Weak Entity Relationship Relationship associated with a weak entity Entity Name Entity Name
Relation ship
Relationship name

Crows Feet Notation for ER Modeling

Entity Name

Relation ship

Relationship name

Recursive Relationship
Relation ship
Role name Role name Role name

Entity Name
Role name

Entity Name
39

Chen Notation for ER Modeling

Attribute Primary key attribute
attribute attribute

Crows Feet Notation for ER Modeling

Entity Name AttributeName1 [derivedAttribute] {multivaluedAttribute} compositeAttribute() Attribute
1 Relationship name Relationship name Relationship name

Multi-valued attribute
Derived attribute One-to-one relationship One-to-many relationship Many-to-many relationship Mandatory for A and B Mandatory participation of B, optional participation of A
1

attribute
attribute

1 N 1

M M M

A
A

B
M

Relationship

Relationship

B
40