Fundamentals of Database

Systems

Course Ins.Fitsum T.(M.sc)

1
 Learning Outcomes
1.Design Database
2.Implement Database using Relational Data model

2
 Course outline
• Chapter 1: Introduction to Database Systems
• Chapter 2: Database System Architecture
• Chapter 3: Database Modeling
• Chapter 4: Functional Dependency and Normalization
• Chapter 5: Record Storage and Primary File
Organization
• Chapter 6: The Relational Algebra and Relational
Calculus
• Chapter 7: The SQL Language
3
Textbook

4
Practical tool(MySQl Workbench)

5
Fundamentals of Database
Systems
Chapter One
Introduction to Database Systems

6
 Outline
• Introduction
• File Organization vs. Database Approach
• Characteristics of the Database Approach
• Actors on the Scene

7
Reference(Text book)

Read chapter one

Page 3-26

8
 Introduction: Initial Vocabulary
• What is Data?
– raw facts about things and events
– Structured: numbers, text, dates
– Unstructured: images, video, documents
• What is Information?
– transformed data that has value for
decision making.
• It is Essential to organize data and
information for retrieval and maintenance
9
 Introduction: What is Database?
• A set of information held in a
computer(dictionary definition)
• A very large, integrated collection
of data
• A collection of data arranged for
ease and speed of search and
retrieval.
– E.g. University- registration, grades

10
 Introduction: What is DBMS?
• a software package designed to store and
manage databases.
• a collection of programs that enables users to
create and maintain a database.
• Example:
– Ms Access
– My Sql
– Oracle

11
 Introduction: What is Db System?
• Database System=DBMS +Data(db)
– is the DBMS software together with the
data itself.
– Sometimes, the applications are also
included.

12
Example: Database Systems Today(social
network)

13
Example: Database Systems
Today(Entertainment)

14
Example: Database Systems Today(Banking)

15
 Example:Database System
applications
• Airlines: reservations, schedules
• Sales: customers, products, purchases
• Human resources: employee records, salaries, tax deductions.
• Telephone directories
• Library catalogues
• Medical records
• Airline bookings
• Credit card details
• Student records
• Customer histories
• Databases touch all aspects of our lives
16
 Data Handling Approaches(File based
approach)
• What is File?
– information stored on a computer as one unit with
one name
• In the early days, database applications were
built directly on top of file systems.
• Data is stored in files
– Each file has a specific format
– Programs that use these files depend on
knowledge about that format
17
File Processing Systems(Example)
Billing Purchasing
Program Program

Accounts Buyer Inventory Vendor

Customer
receivable file file file
file
file

Accounts Payable Sales Order Processing Payroll

Program Program Program

Inventory Employee
Vendor Invoice Customer
file file
file file file

Each user defines and implements the files needed for a specific software
application
18
Drawbacks of File based Approach
 Data redundancy and inconsistency
 Multiple file formats, duplication of information in
different files.
 Difficulty in accessing data
 Need to write a new program to carry out each
new task.
 Atomicity of updates

19
 Drawbacks of File based Approach(cont..)

• Concurrent access by multiple users.

– Concurrent accessed needed for performance.
– Uncontrolled concurrent accesses can lead to
inconsistencies.
– Example: Two people reading a balance and updating it
at the same time.
• Security problems
– Hard to provide user access to some, but not all, data.
• So,What is the solution for those Problems?
• Answer: Database Systems Approach
20
 Characteristics of the Database Approach

• Insulation between programs and data(program-

data independence):
– Allows changing data storage structures and operations
without having to change the DBMS access programs.
• Self-describing nature of a database system
• A DBMS catalog stores the description of the
database(meta data).
• This allows the DBMS software to work with different
databases.
21
 Characteristics of the Database
Approach(contd.)
• Data Abstraction:
• A data model is used to hide storage details and present
the users with a conceptual view of the database.
• Support of multiple views of the data:
• Each user may see a different view of the database,
which describes only the data of interest to that user.
• Sharing of data and multiuser transaction
processing:
• allowing a set of concurrent users to retrieve and to
update the database.
22
 Db System Approach(Example)
Order Dept. Accounting Payroll
Dept. Dept.

Program Program Program

A B C

Ordering
Invoicing Payroll
filing
System System
System

Back Inventory Customer Inventory Employee

Orders Master Master Pricing Master
file file file file file

 Single repository maintains data that is defined once and then accessed by various 23
users
 Disadvantages of Using the Database
Approach
• Expensive
– hardware, software, personnel,
processing overhead, operating cost , etc.
• Increased vulnerability to failure
• Recovery is more complex

24
 Actors on the Scene
• Database domain has several roles and career paths
associated with it.

25
 Actors on the Scene(cont..)
• Database Administrator (DBA):
– responsible for
• authorizing access to the database,
• for coordinating and monitoring its use,
• acquiring software and hardware resources,
• controlling its use and monitoring efficiency of
operations.

26
 Actors on the Scene(cont..)
• System(Application) Developer:
– a person in charge of developing applications
that access databases.
• End-users:
• they use the data for queries, reports and some of
them actually update the database content.
• Casual : access database occasionally when needed
• Naïve or Parametric : They use previously well-defined
functions in the form of “canned transactions” against
the database. 27
 Actors on the Scene(End users cont..)

– Sophisticated :
• use tools in the form of software packages
that work closely with the stored database.
– Stand-alone :
• mostly maintain personal databases using
ready-to-use packaged applications.

28
 CHAPTER TWO

Database System Architecture

29
 Data Abstraction, Data Models, Schema and Instances

• What is Data Abstraction?

– One fundamental characteristic of the database approach
is that it provides some level of data abstraction.
– the suppression of details of data organization and
storage and the highlighting of the essential features for
an improved understanding of data.
• What is Data model?
– A set of concepts to describe the structure of a database,
and certain constraints that the database should obey.

30
 Categories of Data models
• High-level or Conceptual data models:
– Provide concept that are close to the way many users
perceive data.
– Example: entities, attributes, and relationships.
• Low-level or Physical data model:
– Provide concepts that describe the details of how
data is stored in the computer
• Example: how data is stored on the computer storage
media such as magnetic tape

31
Data Abstraction, Data Models, Schema and
Instances
• What is Database Schema?
• The description of a database.
• It Includes descriptions of the database structure and
the constraints that should hold on the database.
• What is Schema Diagram?
• A diagrammatic display of (some aspects of) a
database schema.
• What is Schema Construct?
• A component of the schema or an object within the
schema, e.g., STUDENT, COURSE.

32
Db Schema, schema diagram and schema
construct (Example)

33
Db Schema, schema diagram and schema
construct (Example)

34
Data Abstraction, Data Models, Schema and
Instances contd.
• What is Database State?
• the content of a database at a moment in time.
• Also called Database Instance .
• Initial Database State: the database when it is
loaded
• Valid State: A state that satisfies the structure and
constraints of the database.
• The database schema changes very infrequently.
• The database state changes every time the database
is updated.
35
DBMS Architecture and Data Independence

• Three of four important characteristics of

the database approach.
1. Self-describing of a DB (Schema)
2. Insulation between programs and data
3. Support of multiple views of the data
• Three-Schema Architecture was proposed to
help achieve and visualize these
characteristics

36
 Three-Schema Architecture(The ANSI-SPARC Architecture)

Old Modern
37
Three-Schema Architecture(The ANSI-SPARC
Architecture)

38
 Three-Schema Architecture(The ANSI-SPARC
Architecture)
• Defines DBMS schemas at three levels:
– Internal schema
• at the internal level to describe physical storage structures
and access paths (e.g indexes).
– Conceptual schema
• at the conceptual level to describe the structure and
constraints for the whole database for a community of users.
• Example: describe entities, data types, relationships, user
operations, and constraints
– External schemas
• at the external level to describe the various user views.
39
Database Language and Interface
• Data definition language (DDL)
• Used by the DBA and database designers to
specify the conceptual schema of a database.
• In many DBMSs, the DDL is also used to define
internal and external schemas (views).
• Data manipulation language (DML)
• Used to specify database retrievals and updates.

40
 Database Language(Data definition language (DDL))

• In DBMSs where a clear separation is

maintained between the conceptual and
internal levels, the DDL is used to specify the
conceptual schema only.
– Another language, the storage definition language
(SDL), is used to specify the internal schema.
– The view definition language (VDL), to specify user
views and their mappings to the conceptual
schema.

41
 Database Language(Data Manipulation
language (DML))
• Used to specify database retrievals and
updates.
• DML can be embedded in a general-purpose
programming language (host language), such as
COBOL, C or an Assembly Language.
• Alternatively, stand-alone DML commands can be
applied directly (query language).

42
 Data Manipulation language:Two main types of DMLs

• High Level or Non-procedural Languages:

– Can be used on its own to specify complex database
operations concisely
– e.g., SQL, are set-oriented and specify what data to
retrieve than how to retrieve.
• Low Level or Procedural Languages:
– retrieves individual records or objects from the
database and processes each separately.
– record-at-a-time; they specify how to retrieve data and
include constructs such as looping.
43
 DBMS Interfaces
• User-friendly interfaces provided by a DBMS
may include the following:
• Menu-Based Interfaces for Web Clients or Browsing
– These interfaces present the user with lists of
options (called menus) that lead the user through
the formulation of a request.
– Pull-down menus are a very popular technique in
Web-based user interfaces.

44
 DBMS Interfaces(contd.)
• Forms-Based Interfaces
– A forms-based interface displays a form to each user.
– Users can fill out all of the form entries to insert new
data, or they can fill out only certain entries, retrieve
matching data.
• Graphical User Interfaces
– displays a schema to the user in diagrammatic form.
– The user then can specify a query by manipulating the
diagram.
– In many cases, GUIs utilize both menus and forms.

45
 DBMS Interfaces(contd.)
• Natural Language Interfaces
– These interfaces accept requests written in english
or some other language and attempt to understand
them.
– A natural language interface usually has its own
schema, which is similar to the database conceptual
schema, as well as a dictionary of important words.

46
 DBMS Interfaces(contd.)
• Speech Input and Output:
– Limited use of speech as an input query and
speech as an answer to a question or result of a
request is becoming commonplace.
– Applications with limited vocabularies such as
inquiries for telephone directory for input and
output to enable customers to access this
information.

47
 DBMS Interfaces(contd.)
• Interfaces for Parametric Users:
– Parametric users, such as bank tellers, often have a small
set of operations that they must perform repeatedly.
• Interfaces for the DBA:
– Most database systems contain privileged commands
that can be used only by the DBA staff.
– These include commands for creating accounts, setting
system parameters, granting account authorization,
changing a schema, and reorganizing the storage
structures of a database.

48
 Classification of DBMS
• Several criteria are normally used to classify DBMSs.
• Data model:
– relational, object, object-relational, hierarchical,
network, and other.
• Number of users supported by the system
– Single-user systems and Multiuser systems.
– Single-user systems support only one user at a time and
are mostly used with PCs.
– Multiuser systems, which include the majority of DBMSs,
support concurrent multiple users.
49
 Classification of DBMS(contd.)
• Number of sites over which the database is
distributed
– centralized, distributed DBMS (DDBMS) ,Homogeneous
DDBMSs, Heterogeneous DDBMSs
– A DBMS is centralized if the data is stored at a single
computer site.
– A centralized DBMS can support multiple users, but the
DBMS and the database reside totally at a single
computer site.

50
 Classification of DBMS(contd.)
• A distributed DBMS (DDBMS) can have the actual database and
DBMS software distributed over many sites, connected by a
computer network.
• Homogeneous DDBMSs use the same DBMS software at all the
sites, whereas heterogeneous DDBMSs can use different DBMS
software at each site.
• Cost of the DBMS:
– It is difficult to propose a classification of DBMSs based
on cost.
– Today we have open source (free) DBMS products like
MySQL.
51
 Chapter Three

Database Modeling

52
 Outline
• Database Design principles, Network and
hierarchical
• Data Modeling using Entity Relationship Model
– Using High level Data Models for Database Design
– Entity types and Sets, Attributes and Keys Relationships,
Roles and Structural Constraints Weak Entity Types
– Database Abstraction
– E/R Diagram naming conventions, and Design issues

53
Database Design Principles

54
 Database Design Principles:
Hierarchical Model
• Organizes its data using a tree structure.
• The root of the tree is the parent followed by
child nodes.
• A child node cannot have more than one
parent, though a parent can have many child
nodes.
• The first hierarchical database management
system was IMS (Information Management
System) released by IBM in 1968.

55
Database Design Principles:Hierarchical
Model(cont..)

56
 Database Design Principles:
Hierarchical Model (Cont.)
• Advantages:
– Simple to construct and operate on
– Language is simple; uses constructs like GET, GET
UNIQUE, GET NEXT, GET NEXT WITHIN PARENT etc.
• Disadvantages:
– Navigational and procedural nature of processing
– Database is visualized as a linear arrangement of
records

57
 Database Design Principles: Network
Model
• In 1969, CODASYL (Committee on Data Systems
Languages) released its first specification about the
network data model.
• recognized that data in a system is related to other
data in the same system.
• It is a network of links between the different records.

58
 Network Model (Cont.)
• Advantages:
– model complex relationships and represents
semantics of add/delete on the relationships.
– Language is navigational; uses constructs like FIND,
FIND member, FIND owner, FIND NEXT within set,
GET etc.
• Disadvantages:
– Navigational and procedural nature of processing

59
 Relational Model
• originated by E.F. Codd in the 1970s
• became widely used in the 1980s and 1990s.
• based on mathematics – relational algebra.
• data is stored in tables (also called relations).
• Each table is physically separate to other tables in the
system – unlike network or hierarchy models, where
there must be physical file links between data sets.

60
Relational Data model(Example)

61
 Object-Oriented Model (OO)
• In an OO db, each type of object in the database’s mini-
world is modelled by a class.
• A class has properties (attributes).
• A class also has methods that are stored with the class
definition
• e.g. the code to create a new Customer object
belongs in the Customer class.
• When an application is working with data in the
database, the application creates (instantiates) objects
from the class definitions.

62
 Object-Oriented Model (cont..)
• One advantage of the OO model is sub-classes
• Object Oriented data models are popular in
universities,
• but have not been widely accepted in the
industry;
• however, object-relational mapping (ORM)
tools are available which allow a seamless
integration of object-oriented programs with
relational database

63
 Object-Relational Model (OR)
• It treats every entity as an object (instance of a class)
and a relationship as an inheritance.
• has the capability to store object relationships in
relational form.
• Entities have attributes, which are the data elements
that characterize the entity.
• Some features and benefits of an Object-Relational
model are:
• Support for complex, user defined types
• Object inheritance

64
 Database Design

• Since the design process is complicated, especially for

large databases, it is divided into three sub phases:
 Conceptual database design
 Logical database design
 Physical database design

65
Database design(contd.)

66
 What is Conceptual database design?

• It is a high-level graphical representation of the database

design.
– is the process of constructing a model of the
information used in an enterprise, independent of any
physical considerations.
– Its output is easy for communication between end-
users and developers.
– Conceptual design may be Structured SAD based
(Commonly ERDs)or Object-Oriented SAD based
(commonly UMDs)
67
Conceptual Database Design using Entity-
Relationship Model

68
 Conceptual db design using Entity-
Relationship (ER) Model
 Conceptual modeling is a very important phase
 In designing a successful database application
 The ER model is a high-level conceptual data model
 It is a detailed, logical representation of the data for an
organisation or business area.
 It should be understandable to both the user and to the IT
technologist
 It was introduced by Peter Chen in 1976, and is now the
most widely used conceptual data model.
69
 Conceptual db design using Entity-
Relationship (ER) Model(cont..)
 The model must be as ‘open’ as possible and not tied
to any technology or to any particular business
methodology
 It must be flexible enough so that it can be used and
understood in practically any environment where
information is modelled
 The E-R model is usually expressed as an E-R diagram.

70
Sample E-R Diagram

71
 ER Model Concepts
• Entities and Attributes
– Entities are specific objects or things in the mini-world that are
represented in the database.
– Example the EMPLOYEE Habtamu, the CS
DEPARTMENT,etc
– Attributes are properties used to describe an entity.
– For example an EMPLOYEE entity may have a Name, SSN,
Address, Sex, BirthDate
– Each attribute has a value set (or data type) associated with it –
e.g. integer, string,

72
 ER Model Concepts: Entity Types
• Entities with the same basic attributes are grouped
or typed into an entity type. For example, the
EMPLOYEE entity type or the DEPARTMENT entity
type.
• In ER Diagram, Entity type are represented by
rectangle and attributes are represented by ellipse.

73
 Entity Types: Strong versus Weak entity type

 Most of the basic entity types are classified as strong entity

types.
 Exists independently from other entity types (such as
EMPLOYEE)
– Always have a unique characteristic (identifier) – an
attribute or combination of attributes that uniquely
distinguish each occurrence of that identity
 A weak entity type existence depends on some other entity
type.
 It has no meaning in the ER diagram without the entity on
which it depends (such as DEPENDENT)

74
 Strong versus Weak entity type(cont..)
 The entity type on which the weak entity type depends is
called the Identifying owner (or owner for short).
 Identifying relationship is the relationship between a weak
entity type and its owner
 Weak entity identifier is its partial identifier combined with
that of its owner to form a full identifier for weak entity.

75
 Types of Attributes
 An attribute is a property or characteristic of an entity
type.
 for example the entity EMPLOYEE may have attributes
Employee_Name and Employee_Address.
 Attributes may also be associated with relationships
 An attribute is associated with exactly one entity or
relationship
 In ER diagrams place attributes name in an ellipse with a
line connecting it to its associated entity

76
 Simple versus composite attributes
(following Fig.)
 Some attributes can be broken down into meaningful
component parts, such as Address, which can be broken
down into Street_Address, City..etc.
 The component attributes may appear above or below the
composite attribute on an ER diagram
 Provide flexibility to users, as can refer to it as a single unit
or to the individual components
 A simple (atomic) attribute is one that cannot be broken
down into smaller components

77
A composite attribute

78
Single-Valued versus Multivalued Attribute

• It frequently happens that there is an attribute that

may have more than one value for a given instance,
e.g. EMPLOYEE may have more than one Skill.
• A Multivalued attribute is one that may take on more
than one value – it is represented by an ellipse with
double lines
• Single valued attribute is an attribute with single value.
– e.g Employee name

79
Entity with a multivalued attribute (Skill) and derived
attribute (Years_Employed)

80
 Stored versus Derived Attributes
 Some attribute values can be calculated or derived
from others
 e.g., if Years_Employed needs to be calculated for EMPLOYEE,
it can be calculated using Date_Employed and Today's_Date
 A derived attribute is one whose value can be
calculated from related attribute values (plus possibly
other data not in the database)
 In ER Diagram, a derived attribute is signified by an
ellipse with a dashed line.

81
 Identifier/key attribute
• Identifier attribute or Key is an attribute (or combination
of attributes) that uniquely identifies individual
instances of an entity type.
• E.g Student_ID
• To be a candidate identifier, each entity instance must
have a single value for the attribute, and the attribute
must be associated with each entity
• The identifier attribute is underlined

82
 Simple and composite key attributes

(a) Simple key attribute

83
 Composite Identifier
• A Composite Identifier is when there is no single (or
atomic) that can serve as an identifier
– E.g Flight_ID is a composite identifier that has component
attributes Flight_Number and Date – this combination is
required to uniquely identify individual occurrences of
Flight
• Flight_ID is underlined, whilst its components are not

84
(b) Composite key attribute

85
 Criteria for selecting identifiers
 Some entities have more than one candidate
identifier, so the following criteria should be used:
 Choose identifier that will not change in value
over the life of each instance of the entity type
 Choose identifier that is guaranteed to have valid
values and Will not be null (or unknown). If
composite, make sure all parts will have valid
values

86
 Criteria for selecting identifiers(cont..)
 Avoid the use of intelligent identifiers whose structure
indicates classifications, locations or people that might
change.
e.g. the first two digits of an identifier may indicate a
warehouse location, but such codes are often changed
as conditions change, which renders them invalid.

87
 Relationship Types, Sets and
Instances
 A relationship is an association among the instances of one or
more entity types that is of interest to the organization
 Relationship Type is a meaningful association between (or
among) entities.
• A relationship type R among n entity types E1, E2, ..., En defines
a set of associations or a relationship set among entities from
these entity types.
 the relationship allows us to answer questions that could not
be answered given only the entity types.
 It is denoted by a diamond symbol in ER Diagram
88
Relationship types and instances

(a) Relationship type (Completes)

89
 Relationship Types, Sets and
Instances(cont..)
• Relationship instance is an association between (or
among) entity instances, where each relationship
includes exactly one entity from each participating
entity type.
• For example, in the following figure each line
represents a relationship instance between one
employee and one course, indicating that the
employee has completed that course

90
(b) Relationship instances

91
 Attributes on relationships
• Attributes may be associated with a many-to-many (or
one-to-one) relationship, as well as with an entity
– e.g., an organisation may want to record the date when an
employee completes each course
• In the following diagram, the relationship ‘Completes’
joins the EMPLOYEE and COURSE entities, and
Date_Completed is joined to this as it is a property of
the relationship ‘Completes’

92
An associative entity

(a) Attribute on a relationship

93
 Associative entities
 The presence of one or more attributes on a
relationship suggests that the relationship should
perhaps be represented as an entity type
 An associative entity is an entity type that associates
the instances of one or more entity types and contains
attributes that are peculiar to the relationship between
those entity instances.
 E.g. The associative entity type CERTIFICATE is
represented with the diamond relationship symbol
enclosed within the entity rectangle
94
 Associative entities (cont..)
 The purpose of this special symbol is to preserve the
information that the entity was initially specified as a
relationship on the ER diagram
 There is no relationship diamond on the line between
an associative entity and a strong entity, because the
associative entity represents the relationship

95
(b) An associative entity (CERTIFICATE)

96
 Degree of a relationship
 Is the number of entity types that participate in it.
 e.g ‘Completes’ has degree 2, since there are two
participating entity types, EMPLOYEE and COURSE
 The three most common relationship degrees are unary
(degree 1), binary (degree 2) and ternary (degree 3)
 Higher degree relationships are possible but rarely
encountered in practice

97
 Unary relationship
• Is between the instances of a single entity type (also called
recursive relationships)
– E.g ‘Is_Married_To’ is a one-to-one relationship between instances of
the PERSON entity type
– ‘Manages’ is a one-to-many relationship between instances of the
EMPLOYEE entity type

PERSON

Is_Married_To

98
 Unary relationship(cont..)
 Relationships could be mapped from one
entity to itself.
Manager_Of
1

Employee Manages

N
Subordinate_To
99
Unary relationship(cont..)

100
 Binary relationships
• Between the instances of two entity types, and is the most
common type of relationship encountered in data modelling.
– e.g. (one-to-one) an EMPLOYEE is assigned one
PARKING_PLACE, and each PARKING_PLACE is assigned to
one EMPLOYEE
– (one to many) many peoples may lives in a particular city
and each person only lives in one CITY.
– (many-to-many) a STUDENT may register for more than one
COURSE, and each COURSE may have many STUDENTS

101
Binary relationships(cont..)

N 1

Lives_In

Person City

Is_Born_In
N 1

102
Binary relationships(cont..)

103
 Ternary relationships
• A ternary relationship is a simultaneous relationship
among the instances of 3 entity types
• It is the most common relationship encountered in data
modelling
• Here, vendors can supply various parts to warehouses

104
Ternary relationships

105
Ternary relationships(cont..)

106
 Ternary relationships(cont..)
 The relationship ‘Supplies’ is used to record the specific
PARTs supplied by a given VENDOR to a particular
WAREHOUSE
 There are two attributes on the relationship ‘Supplies’,
Shipping_Mode and Unit_Cost
 e.g. one instance of ‘Supplies might record that VENDOR X
can ship PART C to WAREHOUSE Y, that the Shipping_Mode
is ‘next_day_air’ and the Unit_Cost is £5-00 per unit

107
Structural Constraints: Cardinality and
Participation constraints

 Relationship types usually have certain constraints that limit the

possible combinations of entities that may participate in the
corresponding relationship set.
 These constraints are determined from the miniworld situation
that the relationships represent.
 E.g. if the company has a rule that each employee
must work for exactly one department, then we
would like to describe this constraint in the schema

108
Structural Constraints: Cardinality and
Participation constraints(cont..)

109
 Structural Constraints: Cardinality and
Participation constraints(cont..)
 The number of instances of one entity that can or must
be associated with each instance of another entity.
 There are two main types of Structural constraints
 Cardinality ratio and participation
• The cardinality ratio for a binary relationship specifies the
maximum number of relationship instances that an entity
can participate in.

110
 Structural Constraints: Cardinality ratio and
Participation constraints(cont..)

• For example,
– in the WORKS_FOR binary relationship type,
• DEPARTMENT:EMPLOYEE is of cardinality ratio 1:N

– Meaning that each department can be related to (that is,

employs) any number of employees, but an employee can be
related to (work for) only one department.
– N indicates there is no maximum number

111
 Structural Constraints: Cardinality and
Participation constraints(cont..)
• On the other hand, an employee can be related to a
maximum of one department. The possible cardinality
ratios for binary relationship types are 1:1, 1:N, N:1, and
M:N.

112
 Structural Constraints: Cardinality and
Participation constraints(cont..)
 E.g 1:1 binary relationship MANAGES which relates a
department entity to the employee who manages that
department.
 This represents the miniworld constraints that at any
point in time an employee can manage one department
only and a department can have one manager only.

113
 Structural Constraints: Cardinality
and Participation constraints(cont..)

114
 Structural Constraints: Cardinality
and Participation constraints(cont..)
 The relationship type WORKS_ON is of cardinality ratio
M:N, because the mini-world rule is that an employee
can work on several projects and a project can have
several employees

115
 Structural Constraints: Cardinality
and Participation constraints(cont..)

116
 Structural Constraints: Cardinality
and Participation constraints(cont..)
 Cardinality ratios for binary relationships are represented
on ER diagrams by displaying 1, M, and N on the diamonds.
 The participation constraint specifies whether the
existence of an entity depends on its being related to
another entity via the relationship type.
 Specifies minimum and maximum cardinality

117
 Structural Constraints: Cardinality
and Participation constraints(cont..)
 There are two types of participation constraints
 Total and Partial
 E.g:- If a company policy states that every employee must
work for a department, then an employee entity can exist only
if it participates in at least one WORKS_FOR relationship
Instance .

118
 Structural Constraints: Cardinality
and Participation constraints(cont..)
 The participation of EMPLOYEE in WORKS_FOR is called total
participation,
 meaning that every entity in the total set of employee entities
must be related to a department entity via WORKS_FOR.

119
 Structural Constraints: Cardinality
and Participation constraints(cont..)

120
 Structural Constraints: Cardinality
and Participation constraints(cont..)
 when all entity type instance are not related to the
second entity type instance we refer partial
participation.
– E.g. We do not expect every employee to manage a
department, so the participation of EMPLOYEE in the
MANAGES relationship type is partial,
– meaning that some or part of the set of employee entities are
related to some department entity via MANAGES, but not
necessarily all 121
 Structural Constraints: Cardinality
and Participation constraints(cont..)

122
 Structural Constraints: Cardinality
and Participation constraints(cont..)
 In ER diagrams, total participation is displayed as a
double line connecting the participating entity type to
the relationship, whereas partial participation is
represented by a single line.

123
 Structural Constraints: Cardinality
and Participation constraints(cont..)

124
 Minimum cardinality
 Participation constraint Specifies minimum and maximum cardinality.
 The minimum cardinality of a relationship is the minimum number of
instances of an entity B that may be associated with each instance of
an entity A.
 E.g what is the minimum cardinality in WORKS_FOR relationship?

125
Minimum Cardinality(cont..)

126
 Maximum cardinality

 Is the maximum number of instances of an entity B

that may be associated with each instance of entity A.
 E.g what is the maximum cardinality in WORKS_ON
relationship?

127
Maximum cardinality(cont..)

128
 Multiple relationships

 In some situations an organisation may want to model more

than one relationship between the same entity types
 E.g.:- relationship between PROFESSOR and COURSE
 The relationship Is_qualified associates professors with the
courses they are qualified to teach.
 The relationship Is_scheduled associates professors with the
courses they actually teach during a given semester (where
the maximum cardinality for a given semester is 4)

129
(b) Professors and courses (fixed upon constraint)

130
 Entity Relationship Diagram
 Diagrammatic notation associated with the ER model is referred
to as ER diagrams.
 In ER diagrams the emphasis is on representing the schemas
rather than the instances.
 This is more useful in database design
 A database schema changes rarely, whereas the contents of
the entity sets change frequently.
 The schema is obviously easier to display, because it is much
smaller. 131
Summary of ER model notation

132
 Developing E-R Diagram
 Designing conceptual model for a database is not a one
linear process but an iterative activity.
 The entity sets, attributes, relationship sets, and constraints on
the data are to be specified from the requirement specification
documents.
 The basic E-R model is graphically depicted and
presented for review by the end-users.
 The process is repeated until the end users and
designers agree that the E-R diagram is a fair
representation of the organization’s activities and
functions.
133
 Developing E-R Diagram(cont..)
• Relationships between entities indicate access from one
entity to another.
– It is possible to access one entity occurrence from another
entity occurrence even if there are other entities and
relationships that separate them.
• This is often referred to as navigation of the ER diagram.
• The last phase in ER modeling is validating an ER Model
against requirement of the user.

134
 Developing E-R Diagram(cont..)
Example
Given the following requirements, Draw E-R diagram for the Company
Database.
The company database keeps track of a company’s employees,
departments and projects:
Requirements:
Concerning the Department:
1. Company is organized into departments
2. A department has a unique name, a unique number, location
and a particular employee who manages the department
3. We track the start date for the manager function
4. A department may be in several locations
5. A department controls a number of projects
135
 Developing E-R Diagram(cont..)

• Concerning the Project:

6.A project has a unique name, a unique number and is
in a single location.
• Concerning the Employee:
7.Each employee has a name,SSN, address, salary, sex
and birth date
8.An employee is assigned to one department but may
work on several projects which are not necessarily
controlled by the same department

136
 Developing E-R Diagram(cont..)

9.We track the number of hours per week that an employee

works on each project
10.We keep track of the direct supervisor of each employee
11.We track the dependents of each employee (for insurance
purposes)
• Concerning the dependent:
12.We record each dependent’s first name, sex, birth date, and
relationship to the employee

137
Developing E-R Diagram(cont..)
The entity Types:

EMPLOYEE DEPENDENT

DEPARTMENT

PROJECT

138
 Developing E-R Diagram(cont..)

• Attributes of Each Entity Types

• EMPLOYEE DEPARTMENT DEPENDENT PROJECT
• Ssn -depcode -name -procode
• Name -name - sex -name
• Sex -location -birthdate -location
• Address -relationship
• Salary
• bdate

139
 Developing E-R Diagram(cont..)
Entities with attributes:

fname minit lname

address salary
dependent
name sex

ssn name sex birthdate relationship

employee
bdate

name Depcode location project

department name Procode location

140
 Developing E-R Diagram(cont..)

• Identify relationship type, Cardinality and Degree

between entity types
– Between DEPARTMENT and PROJECT
– Between DEPARTMENT and EMPLOYEE
– Between DEPARTMENT and DEPENDENT
– Between PROJECT and EMPLOYEE
– Between PROJECT and DEPENDENT
– Between EMPLOYEE and DEPENDENT
– EMPLOYEE to EMPLOYEE

141
 Developing E-R Diagram(cont..)

• Between DEPARTMENT and PROJECT

– A department controls a number of projects
• Degree: Binary
• Cardinality ratio: 1:N
• Participation: partial
– A Project is controlled by one department
• Cardinality ratio:N:1
• Participation: total
• Between DEPARTMENT and EMPLOYEE
– An employee is assigned/works to one department
142
 Developing E-R Diagram(cont..)
• Degree: Binary
• Cardinality ratio: N:1
• Participation: total
– A department contains a number of Employees
• Degree: Binary
• Cardinality ratio: 1:N
• Participation: total
– Between DEPARTMENT and DEPENDENT
– No relationship from or to DEPARTMENT and DEPENDENT

143
 Developing E-R Diagram(cont..)
 Between PROJECT and EMPLOYEE
 Employee works on several Projects
• Degree: Binary
• Cardinality ratio: M:N
• Participation: total
 A Project contains several Employees
• Degree: Binary
• Cardinality ratio: N:M
• Participation: total

144
 Developing E-R Diagram(cont..)
 Between PROJECT and DEPENDENT
• There is no relationship between PROJECT and DEPENDENT
 Between EMPLOYEE and DEPENDENT
• An Employee may have one or more Dependents
• Degree: Binary
• Cardinality ratio: 1:N
• Participation: partial
• A Dependent is dependent on Employee
• Degree: Binary
• Cardinality ratio: N:1
• Participation: Total

145
 Developing E-R Diagram(cont..)

• EMPLOYEE to EMPLOYEE
• An Employee is supervisor of several Employees
• Degree: Unary
• Cardinality ratio: 1:N
• Participation: Partial
 Employees supervised by an Employee
• Degree: Unary
• Cardinality ratio: N:1
• Participation: Partial

146
 With relationships:

1
N works for department
1
employee 1
manages 1 controls
supervisee N
supervisor
N
N 1 M
supervision 1 works on project

dependents of

partial constraint
dependent
total constraint

147
 The final E-R Diagram
name Depcode location

fname minit lname 1

N works for department
name sex address salary
1 number of
startdate employees
ssn 1
employee manages controls
bdate 1
1 N
degree
supervisor N hours N
supervisee M
1
supervision works on project

dependents of name procode location

N

dependent

name sex birthdate relationship

148
 Example developing ER-Diagram

Given the following information, develop E-R Diagram.

– A student record management system will have the following
two basic data object categories with their own features or
properties: Students will have an Id, Name, Dept, Age, GPA and
Course will have an Id, Name, Credit Hours. Whenever a student
is enrolled in a course in a specific Academic Year and Semester,
the Student will have a grade for the course.

149
 Developing E-R Diagram(cont..)
• Solution
– Identify entity types
• Student
• Course
– Attributes of each entity type
– Student
• Id
• Name
• Age
• DOP
• GPA
• Dept.

150
Cont…

151