02 ch7 1

PART-2
DATABASE DESIGN
Chapter 7.1:
Entity-Relationship Model
Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
Chapter 7: Entity-Relationship Model
 Design Process
 Modeling (E-R Model)
 Constraints
 E-R Diagram
 Design Issues
 Weak Entity Sets
 Extended E-R Features
 Design of the Bank Database
 Reduction to Relation Schemas
 Database Design
 UML
Database System Concepts 7.2 ©Silberschatz, Korth and Sudarshan

Database Design
 Database design or database model

 Database design represent the logical structure of database
 The process of creating a logical representation of the structure of database is
called database design.
 It should be representing graphically
 The goal is to identifying the fact to be store in database
 Data modeling involves users and analyst

 Database design is created using a data model.

Data Model
 Data model is used to develop a database design

 Or
 Data model is a set of tools that are used to develop a database design.
 Graphical system used to capture the nature and relationship among data
 Data models are created at enterprise level as well as project levels

 Data model organizes data for various users
 Every DBMS is based on Data Model

Data Model
Type of Data Model
 Semantic Data Model
 Records Based Data Model
 Physical Data Model

Data Model
Type of Data Model

 Semantic Data Model
 The model which provide more tool
 They only deal at External Level and Conceptual Level
 Types of Semantic Data Model

 Object Based Data Model
 Entity Relationship Data Model

Data Model
Type of Data Model

 The database consists of a number of fixed-format records and each
record type having fixed number of fields.
 Types of Records Based data model are
 Relational Data Model
 Network Data Model
 Hierarchical Data Model.

Data Model
Type of Data Model

 Relational Data Model
 Based on mathematical relation
 Tables are used to represent Data and Relationships

Data Model
Type of Data Model

 Sometimes called the DBTG model.
 Data is stored in records; each record consists of a group of related
data values.
 Each record can have several child and each child record can have
more then one parent records.
 The IDS database architecture based on network data model.
 IDS( Integrated Data Store): one of the first database management
systems from the 1960s.

Data Model
Type of Data Model
CUSTOMER Loan
1 Habib Zahid 50720
L1 5000
2 Asim Asghar 12400

L2 4500
3 Javeed Suliman 23000
L3 6025
4 Asim Asghar 11000
L4 7000
 Parent Record is called Owner

 Child Record is called Member
 Support 1-1, 1-M & M-M relationship
 Support recursive relationship
Data Model
Type of Data Model
 Disadvantages
 Structure must be defined in advanced which is difficult task.
 It is very complex to understand and developed

Data Model
Type of Data Model
 Hierarchical Data Model
 Use two data structuring concepts: records and parent-child relationships
 A record is a collection of field values that provide information on an
entity or a relationship instance.
 A parent-child relationship type (PCR type) is a 1:M relationship between
two record types.
 Hierarchical data model is tree like structure database and data is store
in the form of branches.
 In hierarchical data model, high level record is called parent
 The parent at top most position is called root.
 A lower level record is called child
 A parent may have more then one child but a child can have only one
parent.

Data Model
Type of Data Model
 This model can support 1:1 and 1:M relationship directly
 It can not support M:M relationship and recursive relationship directly.
 The IMS database architecture based on Hierarchical data model.
 Another popular hierarchical DBMS is MRI’s System-2000
 Advantages
 Flexible for changing the structure
 Insertion, deletion and modification is easy
 Little skill is required to developed and understand
 Accessing and updating is very fast

Data Model
Type of Data Model
 Disadvantages
 Structure should must be defined in advanced which is difficult task.
 Adding new records to database need to redefined the whole
database
 No relationship between child records
 Physical Data Model

 It is a Sample of a whole system or plan which can not be use in the
real, but it is only an instance of that system or project.

Entity Relationship Model
 Introduced by Peter Chen in 1976
 It is logical representation of the data for an organization
 E-R Model is expressed in the term of entities, attributes and
relationships.
 Graphical representation of an entity relationship model is called Entity
Relationship Diagram (ERD).
 Advantages
 Conceptual Simplicity
 Visual Representation
 Effective Communication Tool
 Integrated with Relational Database Model

 A semantic data model, used for the graphical representation of the
conceptual database design.
 just like the SW design, first we going to collect the information and
requirements.(we are going to talk to people what they want)
 The main intention of ER Model is to help the communications b/w the
technical db designer and the naïve db user (who doesn’t know anything
abt db)
 Components of E-R Model
 Entity
 Attribute
 Relationship

 Entity
 An entity is a person, place, object, event, or concept in the user
environment about which organization wish to maintain the data.
 Or
 An Entity is a “Thing” or “Object” in the real world that is
distinguishable from all other objects. it is often noun.
 E.g. each person in the university, company, event, plan, etc…

 Entity is used to three different meaning
 Entity type
 Entity Instance
 Entity set
 Entity Type
 Entity type is a collection of entities that share common properties or
characteristics.
 A label assign to object that exist in a environment and that have
similar properties.
 (the schema or heading of a tbl. e.g student)
 Entity type are distinguishable from other entity types on the base of
properties

 Entity Instance
 A single occurrence of an entity type
 A particular object belonging to a particular entity type is called entity
instance
 Example:
 Entity Type: Student
 Entity Instance: Habib, ahmad, Mahmood ..etc..

 Entity Instance Entity
Entity Type Instance
Properties of
Entity Type Entity
Instance

 Entity Set
 All instance belonging to any entity type are called entity set.
 For example:
 Entity Type: Student
 Entity Instance: Habib
 Entity Instance: Asad
 Entity Set: All students

 Entity Set Entity Set
Entity Type
Properties of
Entity Type

 Types of Entity Type
 Weak Entity Type
 Strong Entity Type
 Weak Entity Type
 An entity type whose existence depends on some other entity type.
 An entity type whose instances cannot exist without being linked with
the instances of some other entity types.
 They cannot exist independently
 It has a partial identifiers. Weak entity type is
represented by double
line Rectangle
DEPENDENT

 Strong Entity Type
 An entity type that exists independently of other entity types.
 An entity type whose instances can exist independently
 The entity type that have there own identity
 It always have an identifier
 It is also called Identifying owner Strong entity type is
represented by Single line
Rectangle
EMPLOYEE

 Identifying Relationship
 The relationship between the weak entity type and its owner is
called identifying relationship.
 It is represented by double line diamond.
Partial
Identifying
Identifier Identifier
Relationship
Strong
Weak
Entity Type
Entity Type
 Naming Entity Type
 Singular Name, placed inside the box
 Specific to organization
 Name should be Capital
 Abbreviation can be used (e.g STUDENT=STD, EMPLOYEE=EMP,
etc…)
 Entity type is indicated by Rectangle
CUSTOMER ORDER

 Attribute
 The properties associated with entity type
 A property or characteristic of an entity type or relationship that is of
interest to the organization.
 Attribute may be associated with relationship
 Example
 STUDENT Student_ID, Student_Name, Phone_Number, Email
 EMPLOYEE Employee_ID, Ename, Job, Hiredate
 Graphical representation

 Attribute
 Graphical representation
Ename
 Old Method: Represented by Oval
Job
Ename Address
Date_Employed
EMPLOYEE
Skill

 Naming Attribute
 Initial capital letter followed by lowercase letters e.g. Ename
 If attribute consist of two words then use the underscore character to
connect the words and start each word with capital letter e.g.
Student_Name
 Domain of an Attribute
 Set of possible value for an attribute is called domain
 Domain can be used for the boundaries check
 Attribute in an entity set get the value from the same domain

Types of Attributes
 Different types of attributes are represented in E-R Diagram as follows:
 Required Attribute
 The attribute that must have a value for every instance
 E.g ID in every table
 Optional Attribute
 The attribute that may not have a value for every entity instance. E.g:
hobbies attribute in a table
 The attribute without a value is said to be null.

 Attribute
 Required Versus Optional Attribute
Optional
Attribute

 Attribute
 Simple Attribute
 An attribute that can not be broken down into smaller parts or
component is known as simple attribute or atomic attribute.
 The attribute having a single value
 Example: A person can have only one gender and one date of
birth, Roll_No, Marks etc.
 Composite Attribute
 The attribute that can be broken down into meaningful
component e.g: address(street address, city, state, postal_code).
 Name (Fname, Lname, MiddleName ).
 Graphical representation of Composite Attribute

 Attribute
 Graphical representation of Composite Attribute
 Old Method
Addres
Name
s
First_ Middle Last_

Name _Name Name Street City State

 Attribute
 Single Valued Attribute

 The attribute that may take a single value for a given entity
instance. For Example CNIC_No
 Multi-Valued Attribute
 The attribute that may take more then one value for a given
instance. For Example Skill, Subject, color, or a person can have
two or more degrees, etc..

 Attribute
 Single Valued Versus Multi-valued Attribute
 Graphical representation of Multi-Valued Attributed

 To represent the Multi-valued attribute curly braces are used
around the attribute name but some ER diagramming tools may
use an * after the attribute name.
Multi Value
Attribute

 Attribute
 Single Valued Versus Multi-Valued Attribute
 Old Graphical representation of Multi-Valued Attributed: Double
line oval / Ellipse
 E.g: Skill
Job
Ename Address
EMPLOYEE
Skill

 Attribute
 Derived Attribute
 The attribute whose value can be calculated from related
attribute value.
 The data not actually store in database but derived from other
related attribute that are store in database.
 Example
 Date_Employed attribute used in EMPLOYEE entity type used to
calculate Years_Employed
 Or from DOB of person we can calculate Age of person.

 Attribute
 Graphical representation of Derived Attributed: Square Brackets
around the attribute name, e.g. [Years_Employed] but some ER
diagramming tools may use forward slash ‘/’.
Derived
Attribute

 Attribute
 Old Graphical representation of Derived Attributes: Dashed Ellipse
Date_
Employed Years_
Ename Employed
EMPLOYEE
Skill

 Attribute
 Identifier Attribute
 Identifier is an attribute that identifies an entity instance among
other instances in entity type. or
 The attribute or set of attribute that uniquely distinguish each
occurrence of entity(each instance of entity). Identifier attribute is
represented by underline. E.g Std_ID, Roll No, Registration No
for student entity, Emp_id for Employee entity type.
 Partial Identifier
 Represented by double under line. E.g Dependent_Name,
Child_Name etc…

 Attribute
 Identifier
 Graphical representation
Partial Identifier

Relationship
 A meaningful association among entity types.
 Relationship is the association among the instance of one or more entity
types.
 Relationship are the glue that holds together the various component of
E-R model.
 Examples
 STUDENT Completes COURSES
 Noun -------verb--------noun
 Other examples like: student writes examination
 Student attends class
 Driver drives car (a driver at a time drives only one car)

Relationship
 Graphical Representation
 Denoted by Line labeled with the name of relationship
Completes
STUDENT COURSE

Relationship
 Denoted by Line labeled with the name of relationship
STUDENT COURSE
Roll_No Completes Course_ID
Name (…) Course_Title
Birt_data {Topic}

Relationship
 Old Method: Diamond symbol is used for relationship
First_Name Middle_Name
Last_Name
Title
Roll_No Name DOB
Course_ID
Topic
STUDENT Completes COURSES

Relationship
 Relationship Instance
 Association between entity instances which includes one occurrence
from each participating entity type.
 Each line represents a relationship instance between one STUDENT

and one COURSE.
Relationship
 Attribute on Relationship
 Attributes that are associated with a relationship
Attribute on
Relationship
 Each Instance of Relationship Completes, there is a value for

Date_Completed
Relationship
 Attribute on Relationship
Teach_Duration
Teach_Time
Title
Staff_No Name Course_ID
TEACHER Teaches COURSES
 Teacher teaches Database at 10 am for 50 minutes

Relationship
 Degree of Relationship
 The number of entity types that participate in a relationship are
called degree of relationship.
 The most commonly used relationship in E-R Model are Unary,
Binary and Ternary relationship.
 Unary Relationship
 A relationship among the instances of single entity type
 Unary relationship are also called recursive relationship

Relationship
 . Unary Relationship: Employee manages employee.
Man
ages
EMPLOYEE
Lives
with
 A PERSON lives with another person: PERSON
 TEACHER works with another teacher.
TEACHER Works with

Relationship
 . Binary Relationship
 A relationship among the instances of two entity types
EMPLOYEE PARKING SPACE
STUDENT DEPARTMENT
STUDENT COURSE

Relationship
 . Binary Relationship
 One-to-one Relationship:
 This type of relationship is used when “for each instance in 1st entity
type(entity class) , there is only one instance in the 2nd entity type and vice
versa”. E.g:
CHAIRMAN Runs DEPARTMENT
 The above relationship means that one chairman runs only one department.
Similarly, one department is run by one chairman
COUNTRY has PRESIDENT
 The above relationship means that one country has one president. Similarly,
one president is of only one country.
MANAGER Manages BRANCH

Relationship
 Binary Relationship
 One-to-Many Relationship:
 . This type of relationship is used when “for each instance in 1st entity type,
there can be many instances in the 2nd entity type and for each instance in 2nd
entity type, there is only one instance in 1st entity type”. E.g:
STATE has CITY
 The above relationship means that one state can have many cities, but one city
is belonged to one state.
UNIVERSITY has DEPARTMENT
 The above relationship means that one university can have many departments,
but one department is part of only one university.
EMPLOYER Employs EMPLOYEE

Relationship
 Binary Relationship
 Many-to-Many Relationship:
 This type of relationship is used when “for each instance in 1st entity type,
there can be many instances in the 2nd entity type and for each instance in
2nd entity type, there can be many instances in the 1st entity type”. E.g:
STD Studies COURSE
 The above relationship means that one std may study many courses and
one course may be studied by many students.
EMPLOYEE Learns SKILL
 The above relationship means that one employee can learn many skills and
one skill can be learned by many employees.
READER Reads BOOK

Relationship
 Ternary Relationship
 A relationship among the instances of three entity types
a relationship can have attributes of its own
 The above relationship means that one or many vendors with one or many
warehouses supplies one or many parts.

Relationship
 Ternary Relationship
 The last relationship means that one or many analysts with one or many
programmers work on one or many projects.

Relationship
 Cardinality Constraints
 The number of instance of an entity type that can be associated with each
instance of another entity type is called cardinality constraints.
 There are 3 symbols used to show degree. A circle means zero, a line
means one and crow’s foot symbol means many.
Completes
STUDENT COURSES
 Each student completes one or more then one courses but for each course
there may or may not exist student who complete the course.

Relationship
 Figure: Relationship cardinalities
Mandatory One
Mandatory Many
Optional One
Optional Many

Relationship
 Minimum Cardinality
 Minimum number of instances of entity B that may be associated with each
instance of entity A.
A B
 The minimum no of instances of entity type B are “0”. When minimum

number of instance of entity is zero we say that entity type is optional
participant.

Relationship
 Minimum Cardinality
A B
 If the minimum cardinality is zero, participation is optional
 If the minimum cardinality is one, participation is mandatory

Relationship
 Maximum Cardinality
 Maximum number of instances of entity B that may be associated with each
instance of entity A.
A B
 The maximum no of instances of entity type B are unspecified but

“many” and greater than one.

Relationship


02 ch7 1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

02 ch7 1

Uploaded by

Copyright:

Available Formats

PART-2

Database System Concepts, 6th Ed.

Database System Concepts 7.2 ©Silberschatz, Korth and Sudarshan

 Database design or database model

 Data modeling involves users and analyst

Database System Concepts 7.3 ©Silberschatz, Korth and Sudarshan

 Data model is used to develop a database design

 Data models are created at enterprise level as well as project levels

Database System Concepts 7.4 ©Silberschatz, Korth and Sudarshan

Type of Data Model

 Semantic Data Model

 Records Based Data Model

 Physical Data Model

Database System Concepts 7.5 ©Silberschatz, Korth and Sudarshan

Type of Data Model

 Types of Semantic Data Model

Database System Concepts 7.6 ©Silberschatz, Korth and Sudarshan

Type of Data Model

 Types of Records Based data model are

 Relational Data Model

 Network Data Model

 Hierarchical Data Model.

Database System Concepts 7.7 ©Silberschatz, Korth and Sudarshan

Type of Data Model

Database System Concepts 7.8 ©Silberschatz, Korth and Sudarshan

Type of Data Model

Database System Concepts 7.9 ©Silberschatz, Korth and Sudarshan

2 Asim Asghar 12400

 Parent Record is called Owner

Database System Concepts 7.11 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.12 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.13 ©Silberschatz, Korth and Sudarshan

 Physical Data Model

Database System Concepts 7.14 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.15 ©Silberschatz, Korth and Sudarshan

 Components of E-R Model

Database System Concepts 7.16 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.17 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.18 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.19 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.20 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.21 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.22 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.23 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.24 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.26 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.27 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.28 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.29 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.30 ©Silberschatz, Korth and Sudarshan

 Required Versus Optional Attribute

Database System Concepts 7.31 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.32 ©Silberschatz, Korth and Sudarshan

First_ Middle Last_

Database System Concepts 7.33 ©Silberschatz, Korth and Sudarshan

 Single Valued Attribute

Database System Concepts 7.34 ©Silberschatz, Korth and Sudarshan

 Graphical representation of Multi-Valued Attributed

Database System Concepts 7.35 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.36 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.37 ©Silberschatz, Korth and Sudarshan

Database System Concepts 7.38 ©Silberschatz, Korth and Sudarshan