Conceptual Database Design
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).
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
It is a top-down approach
4
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
Meaning Entity
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)
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
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
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:-
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
20
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
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
Note that for a *:* relationship, we may choose a relationship name that makes sense in either direction
25
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
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
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
32
33
Chasm Traps
Where a model suggests the existence of a relationship between entity types, but the pathway does not exist between certain entity occurrences.
36
37
Entity Name
Relation ship
Relationship name
Recursive Relationship
Relation ship
Role name Role name Role name
Entity Name
Role name
Entity Name
39
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