Previous Lecture
 Why databases?
CS203
DATABASE MANAGEMENT
SYSTEMS
 Data, Information, knowledge
 Introduction to databases
 Database Management Systems
 File Systems Vs. Database Management Systems
 Database system environment
Lecture 02
 DBMS Advantages
Dr. U.A.J. Pinidiyaarachchi
Department of Statistics and Computer Science
 Types of databases
10/28/2020
Database Design
Conceptual Design
Logical Design
Physical Design
Database Creation
10/28/2020
2
Requirement gathering
 Steps
Requirement Analysis
CS203- DBMS - Department of Statistics and Computer Science
Specify what need to be modeled in a real-world
domain
Complete technology- independent picture of the
database
Refine a conceptual design to a schema using
the data model of a DBMS
 The database designers interview the customers
 Aim
 Understanding the proposed system
 Documenting the data and functional requirements
 Outcome
 A document that includes the detailed requirements provided by the users
Define the schema using the DDL of the DBMS
Load data into a database
CS203- DBMS - Department of Statistics and Computer Science
3
10/28/2020
CS203- DBMS - Department of Statistics and Computer Science
Conceptual Design
Logical Design
 Design a high level description- schema based on the requirements
 Concerned with the meaning and structure of data, but not with the
details on how they are implemented
 Determine the specific type of database system (network, relational,
object-oriented) that is required
 Aim
 Aim
 to obtain a detailed description of the data that will suit user requirements
 Outcome
 formal representation of what data the database should contain and the
constraints the data must satisfy
4
 Refine the conceptual design to a structure using the data model of a
DBMS
 Eg: relational
 Outcome
 a detailed (relational ) specification of all the structures and constraints
needed to satisfy the description of the data in the conceptual data model
 Eg: table structures and constraints
 Eg: relational representation (E-R Diagram)
10/28/2020
CS203- DBMS - Department of Statistics and Computer Science
6
1
CONCEPTUAL DESIGN
Entity Relationship Diagrams
Relationships
Entities and attributes
 Relationship An association between two or more entities (usually of different
types)
 Entity - A real-world object distinguishable from other objects
 Entity Type - A definition of a collection of entities with identical set of
attributes
 Attributes - Each entity is described by a set of attributes (or
properties)
grade
name
title
IDNo
name
IDNo
 A relationship may also have attributes
 Relationship Type - A definition of a collection of relationships with the
identical set of attributes
gpa
credit
Ccode
gpa
Student
Course
Enroll
Student
Attributes
Relationships
 Degree Number of entity types involved in a relationship type (unary,
binary, ternary, … )
 Role Part played by entities of a unary relationship
PNo
 simple vs composite,
 single-value vs multi-value,
 stored vs derived
 Domain of an attribute- The set of values the attribute may take
name
ssn
qty
name
 Types of attributes
lot
name
SNo
color
Order
Part
city
fname
supervisor
JNo
Project
minit
lname
Employee
Supplier
subordinate
dept
Reports_To
IDNo
name
gpa
bdate
hobby
Student
age
2
Key Constraints
Let’s recap
 Key Attribute(s)
 A set of attributes of an entity type whose values are unique for each entity of
 Explain the following terms
 Entity
 Relationship
 Attribute
that type.
 Key Constraint
 Every entity type (except weak entities) must have a key attribute(s)
 e.g., IDno of Students
name
IDNo
gpa
Student
10/28/2020
CS203- DBMS - Department of Statistics and Computer Science
13
Cardinality Constraints
Cardinality Constraints
 Cardinality Ratio
 One-to-Many (1-to-M)
 Number of relationship instances that an entity can participate in
 Each entity in E1 is associated with more than one entity in E2
 One-to-one (1-to-1)
 Each entity in entity type E1 is associated with 0 or one entity in entity
type E2, and vice versa.
Name
name
NIC
since
Employee
manages
1
1
room
Department
versa.
name
grade
cno
gps
m
takes
Works-for
m
address
Employee
1
Weak Entities
 Many-to-many (M-to-N)
 Each entity in E1 is associated with more than one entities in E2, and vice
Student
name
NIC
location
Department
Cardinality Constraints
IDNo
DNo
name
dno
age
n
 Weak Entity Type
 An entity type without its own key.
 Typically have a partial key
 Must totally participate in an identifying relationship with a strong entity type
 The relationship must be m-to-1 or 1-to-1
title
credit
Course
name
city
University
Sname
size
1
has
m
phone
type
Student society
3