Advance Database
Management System
Conceptual Design
Lecture-1
A simplified database design
process
Database
Requirements
UoD
Requirements
Collection and
Analysis
Functional
Requirements
1
A simplified database design
process
Database
Requirements
Conceptual Design
Functional
Requirements
Functional Analysis
Conceptual
Schema
High-level
Transaction
Spec.
DBMS Independent
Conceptual
Schema
Physical Design
Internal
Schema
Application
software
Hign-level
Transaction
Specs
Application Program
Design
Transaction
Implementation
DBMS Dependent
2
Conceptual Schema
• Outcome of high-level conceptual design
• Concise description of data requirements
of the users
• Include description of Entity types,
relationship and constraints
• No implementation details
• Ease of Understanding, used to
communicate with non-technical users
Example COMPANY Database
• Department: Name, Dept-ID, Manager, …
• Project: Name, Proj-ID, Location
(Managed by Departments)
• Employee: name, PAN, Address, Salary,
Gender, DOB …
• Dependents: Name, Address, Gender,
DOB, Relationship with Employee
3
Entities and Attributes
Dept_Name
Dept_ID
Manager
Department
• An entity represents an object of the real world that has
an independent existence
• An entity has attributes – properties that describe it
Attribute types
• Simple Vs Composite
– A composite attribute is made of one or more single
or composite attributes. Example: Name is made of
First Name, Middle Name and Last Name
• Single-valued Vs Multi-valued
– A single-valued attribute is described by one value
(Example: age of a person)
– A multi-valued attribute is described by many values
(Example: the color attribute of multi-colored bird)
4
Attribute types
• Stored Vs Derived
– An attribute whose value can be inferred from
the values of other attributes is called derived
attribute (Example: age can be derived from
Date of Birth and current date). If this is not
the case then it’s a stored attribute.
• Null Values
– Attributes that do not have any applicable
values are said to have null values. Different
from 0, unknown and missing values
Entity types and Entity sets
• An Entity type defines a collection of different
entities having the same type.
– For example “Department” defined earlier is
an entity type defining several department
having the same attribute structure
• Any specific collection of entities of a particular
type is called an entity set.
• An Entity Type describes the Schema or
intention for an Entity Set
5
Representations
Attributes
Entity Types
Derived Attributes
Multi-valued Attributes
Key Attributes
Dept_Name
Dept_ID
Manager
Department
• The Dept_ID is unique for each department belonging to
this entity set.
• Dept_ID can hence uniquely identify departments.
6
Key Attributes
• An attribute or a set of attribute that uniquely
identify entities in an entity set are called key
attribute(s).
• When a collection of attributes define a key, the
set is called composite key.
• Composite key should be minimal, no subset of
composite key should be key itself.
• Key attributes are shown underlined in ER
diagram
Key Attributes
• Key attributes should retain the unique definition
property for all extensions (EER Model) of the
entity type.
• An entity type may have more than one keys
independent of each other. (Example: Two
Ethernet defining the same machine)
• Some entity type may have no key attributes,
Entities of such types are called weak entities
7
Domain of Attributes
• The domain of an attribute is the set of all
valid values that an attribute can attain.
– Example: The domain of an attribute “Age” of
an employee is the set of all integers between
18 to 65.
• If composite attribute have n values with
domains D1, D2, …, Dn. Then the domain
of an attribute is D1 x D2 x …x Dn.
The COMPANY Revisited
Entity Types
Attributes
Department
Dept_id, Name, No. of
Employees, Manager,…
Project
Proj_id, Name, Team
Strength, Locations,
ControllingDept,…
Emp_id, Name(F,M,L),
PAN, Gender, Address,
Salary, …
Employee
8
Relationships
Department
Managed_by
Employee
• Relationship type relates two or more entity type
and define a relationship set. Any given
depiction of a relationship type is called a
relationship instance.
Relationships
• A relationship type R among n entity types E1, E2, … En,
defines a set of associations (a relationship set) among
entities of this type.
9
Relationships
• Degree of a relationship type. The number of
participating entity types in this relationship type
– Ex: Degree of relationship Department
“managed_by” Employee is 2
• Unary, Binary and Ternary relationships are the
special terms used for relationship of degree 1,
2 and 3 respectively
– Quick Exercise: Think of a example for a unary
relationship in COMPANY example
Relationships Vs Attributes
Employee
Works for
Department
Department
Employee
10
Relationships Vs Attributes
Dept-ID
Employee
Works for
Department
Dept-ID
Employee
Relationships Vs Attributes
• Relationships as attributes are a concept
used in data models called functional data
models
• In object databases relationships are
represented by object references
• In relational databases foreign keys
represents relationships as attributes
11
Constraints on Relationship Types
• Constraints limit the set of possible
combination of entities that can participate
in the relationship type
• Two main kind of constraints:
– Cardinality Ratio
– Participation Constraints
Cardinality Ratios
(N:1)
Employee
N
Works for
1
Department
• Represents a cardinality constraint that while a
department may have any number (N) of employees,
each employee entity should be associated with only one
department instance.
• Quick Exercise: How would you interpret it if in the above
relationship the ratio were to be (M:N) instead of (N:1)
12
Participation Constraints
Department
1
Handles
N
Project
• If every project has to be associated with a department,
then the “existence” of an instance of Project entity type
depends on the existence of instance of the Handles
relationship type.
Participation Constraints
Department
1
Handles
N
Project
• The entity type Project is said to be “totally
participate” in relationship type Handles. The
relationship is also said to introduce an
existence dependency on “Project”.
• Total participation is shown with the double line
in the ER diagram
13
Attributes of Relationship Types
Budget
Department
M
Handles
N
Project
• Budget refers to the allocated budget for a
specific department for handling a specific
budget. It belongs neither to the Department nor
to the Project for its entirety.
Attributes of Relationship Types
Budget
Department
1
Handles
N
• In 1:N or 1:1 relationships,
relationship attributes can be
moved to a corresponding
participating entity type
Department
1
Handles
Project
Budget
N
Project
14
Identifying Relationships
PAN
Employee
1
Insurance
Details
1
Insurance Record
• Insurance Record is a “weak entity type” with no key. It
has no existence without its association with entity type
Employee.
• The relationship Insurance Details is an “Identifying
relationship”.
• Note the convention for representing weak entity types
and identifying relationships
Identifying Relationships
PAN
Employee
1
Insurance
Details
1
Insurance Record
• Weak entity types always totally participate in their
identifying relationships, however not all total
participation indicate weak entity types
• Quick Exercise: Think of an example of total participation
from an entity type which is not a weak entity type in a
relationship
15
Summary of ER Notations
Employee
Insurance Record
Handles
Insurance
Details
Entity Type
Weak Entity Type
Relationship Type
Identifying Relationship Type
Summary of ER Notations
Attribute
PAN
Key Attribute
Multi-valued Attribute
Derived Attribute
16