Module 1

1. Databases and Database Users -1.3, 1.6

2. Database System Concepts and Architecture
-2.1,2.2,2.3
3. Data Modeling Using the Entity-Relationship
(ER) Model- 3.3, 3.4, 3.5

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Chapter 1
Introduction: Databases and
Database Users

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Outline
 Main Characteristics of the Database Approach
 Advantages of Using the Database Approach

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 1- 3

Basic Definitions
 Database:
 A collection of related data.

 Data:
 Known facts that can be recorded and have an implicit meaning.

 Mini-world:
 Some part of the real world about which data is stored in a

database. For example, student grades and transcripts at a

university.
 Database Management System (DBMS):
 A software package/ system to facilitate the creation and

maintenance of a computerized database.

 Database System:
 The DBMS software together with the data itself. Sometimes, the

applications are also included.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 1- 4

Example of a Database
(with a Conceptual Data Model)
 Mini-world for the example:
 Part of a UNIVERSITY environment.
 Some mini-world entities:
 STUDENTs
 COURSEs
 SECTIONs (of COURSEs)
 (academic) DEPARTMENTs
 INSTRUCTORs

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 1- 5

Example of a Database
(with a Conceptual Data Model)
 Some mini-world relationships:
 SECTIONs are of specific COURSEs
 STUDENTs take SECTIONs
 COURSEs have prerequisite COURSEs
 INSTRUCTORs teach SECTIONs
 COURSEs are offered by DEPARTMENTs
 STUDENTs major in DEPARTMENTs

 Note: The above entities and relationships are typically

expressed in a conceptual data model, such as the
ENTITY-RELATIONSHIP data model (see Chapters 3, 4)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 1- 6

Example of a simple database

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 1- 7

Main Characteristics of the Database
Approach
 Self-describing nature of a database system:
 A DBMS catalog stores the description of a particular
database (e.g. data structures, types, and constraints)
 The description is called meta-data.
 This allows the DBMS software to work with different
database applications.
 Insulation between programs and data:
 Called program-data independence.
 Allows changing data structures and storage organization
without having to change the DBMS access programs.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 1- 8

Example of a simplified database catalog

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 1- 9

Main Characteristics of the Database
Approach (continued)
 Data Abstraction:
 A data model is used to hide storage details and
present the users with a conceptual view of the
database.
 Programs refer to the data model constructs rather
than data storage details
 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.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 1- 10

Main Characteristics of the Database
Approach (continued)
 Sharing of data and multi-user transaction
processing:
 Allowing a set of concurrent users to retrieve from and to
update the database.
 Concurrency control within the DBMS guarantees that each
transaction is correctly executed or aborted
 Recovery subsystem ensures each completed transaction
has its effect permanently recorded in the database
 OLTP (Online Transaction Processing) is a major part of
database applications. This allows hundreds of concurrent
transactions to execute per second.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 1- 11

Advantages of Using the Database
Approach
 Controlling redundancy in data storage and in
development and maintenance efforts.
 Sharing of data among multiple users.
 Restricting unauthorized access to data.
 Providing persistent storage for program Objects
 In Object-oriented DBMSs – see Chapters 20-22
 Providing Storage Structures (e.g. indexes) for
efficient Query Processing

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 1- 12

Advantages of Using the Database
Approach (continued)
 Providing backup and recovery services.
 Providing multiple interfaces to different classes
of users.
 Representing complex relationships among data.
 Enforcing integrity constraints on the database.
 Drawing inferences and actions from the stored
data using deductive and active rules

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 1- 13

Additional Implications of Using the
Database Approach
 Potential for enforcing standards:
 This is very crucial for the success of database
applications in large organizations. Standards
refer to data item names, display formats, screens,
report structures, meta-data (description of data),
Web page layouts, etc.
 Reduced application development time:
 Incremental time to add each new application is
reduced.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 1- 14

Additional Implications of Using the
Database Approach (continued)
 Flexibility to change data structures:
 Database structure may evolve as new
requirements are defined.
 Availability of current information:
 Extremely important for on-line transaction
systems such as airline, hotel, car reservations.
 Economies of scale:
 Wasteful overlap of resources and personnel can
be avoided by consolidating data and applications
across departments.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 1- 15

Chapter 2
Database System Concepts and
Architecture

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Outline
 Data Models and Their Categories
 History of Data Models
 Schemas, Instances, and States
 Three-Schema Architecture
 Data Independence
 DBMS Languages and Interfaces

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 17

Data Models
 Data Model:
 A set of concepts to describe the structure of a database,
the operations for manipulating these structures, and
certain constraints that the database should obey.
 Data Model Structure and Constraints:
 Constructs are used to define the database structure
 Constructs typically include elements (and their data
types) as well as groups of elements (e.g. entity, record,
table), and relationships among such groups
 Constraints specify some restrictions on valid data; these
constraints must be enforced at all times

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 18

Data Models (continued)
 Data Model Operations:
 These operations are used for specifying database
retrievals and updates by referring to the
constructs of the data model.
 Operations on the data model may include basic
model operations (e.g. generic insert, delete,
update) and user-defined operations (e.g.
compute_student_gpa, update_inventory)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 19

Categories of Data Models
 Conceptual (high-level, semantic) data models:
 Provide concepts that are close to the way many users
perceive data.

(Also called entity-based or object-based data models.)
 Physical (low-level, internal) data models:
 Provide concepts that describe details of how data is stored
in the computer. These are usually specified in an ad-hoc
manner through DBMS design and administration manuals
 Implementation (representational) data models:
 Provide concepts that fall between the above two, used by
many commercial DBMS implementations (e.g. relational
data models used in many commercial systems).

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 20

Schemas versus Instances
 Database Schema:
 The description of a database.
 Includes descriptions of the database structure,
data types, and the constraints on the database.
 Schema Diagram:
 An illustrative display of (most aspects of) a
database schema.
 Schema Construct:
 A component of the schema or an object within
the schema, e.g., STUDENT, COURSE.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 21

Schemas versus Instances
 Database State:
 The actual data stored in a database at a
particular moment in time. This includes the
collection of all the data in the database.
 Also called database instance (or occurrence or
snapshot).

The term instance is also applied to individual
database components, e.g. record instance, table
instance, entity instance

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 22

Database Schema
vs. Database State
 Database State:
 Refers to the content of a database at a moment
in time.
 Initial Database State:
 Refers to the database state when it is initially
loaded into the system.
 Valid State:
 A state that satisfies the structure and constraints
of the database.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 23

Database Schema
vs. Database State (continued)
 Distinction
 The database schema changes very infrequently.
 The database state changes every time the
database is updated.

 Schema is also called intension.

 State is also called extension.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 24

Example of a Database Schema

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 25

Example of a database state

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 26

Three-Schema Architecture
 Proposed to support DBMS characteristics of:
 Program-data independence.
 Support of multiple views of the data.
 Not explicitly used in commercial DBMS products,
but has been useful in explaining database
system organization

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 27

Three-Schema Architecture
 Defines DBMS schemas at three levels:
 Internal schema at the internal level to describe physical
storage structures and access paths (e.g indexes).

Typically uses a physical data model.
 Conceptual schema at the conceptual level to describe the
structure and constraints for the whole database for a
community of users.

Uses a conceptual or an implementation data model.
 External schemas at the external level to describe the
various user views.

Usually uses the same data model as the conceptual schema.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 28

The three-schema architecture

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 29

Three-Schema Architecture
 Mappings among schema levels are needed to
transform requests and data.
 Programs refer to an external schema, and are
mapped by the DBMS to the internal schema for
execution.
 Data extracted from the internal DBMS level is
reformatted to match the user’s external view (e.g.
formatting the results of an SQL query for display
in a Web page)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 30

Data Independence
 Logical Data Independence:
 The capacity to change the conceptual schema
without having to change the external schemas
and their associated application programs.
 Physical Data Independence:
 The capacity to change the internal schema
without having to change the conceptual schema.
 For example, the internal schema may be changed
when certain file structures are reorganized or new
indexes are created to improve database
performance

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 31

Data Independence (continued)
 When a schema at a lower level is changed, only
the mappings between this schema and higher-
level schemas need to be changed in a DBMS
that fully supports data independence.
 The higher-level schemas themselves are
unchanged.
 Hence, the application programs need not be
changed since they refer to the external schemas.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 32

DBMS Languages
 Data Definition Language (DDL)
 Data Manipulation Language (DML)
 High-Level or Non-procedural Languages: These
include the relational language SQL

May be used in a standalone way or may be
embedded in a programming language
 Low Level or Procedural Languages:

These must be embedded in a programming
language

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 33

DBMS Languages
 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).
 In some DBMSs, separate storage definition
language (SDL) and view definition language
(VDL) are used to define internal and external
schemas.

SDL is typically realized via DBMS commands
provided to the DBA and database designers

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 34

DBMS Languages
 Data Manipulation Language (DML):
 Used to specify database retrievals and updates
 DML commands (data sublanguage) can be
embedded in a general-purpose programming
language (host language), such as COBOL, C, C+
+, or Java.

A library of functions can also be provided to access
the DBMS from a programming language
 Alternatively, stand-alone DML commands can be
applied directly (called a query language).

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 35

Types of DML
 High Level or Non-procedural Language:
 For example, the SQL relational language
 Are “set”-oriented and specify what data to retrieve
rather than how to retrieve it.
 Also called declarative languages.
 Low Level or Procedural Language:
 Retrieve data one record-at-a-time;
 Constructs such as looping are needed to retrieve
multiple records, along with positioning pointers.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 36

DBMS Interfaces
 Stand-alone query language interfaces
 Example: Entering SQL queries at the DBMS
interactive SQL interface (e.g. SQL*Plus in
ORACLE)
 Programmer interfaces for embedding DML in
programming languages
 User-friendly interfaces
 Menu-based, forms-based, graphics-based, etc.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 37

DBMS Programming Language Interfaces
 Programmer interfaces for embedding DML in a
programming languages:
 Embedded Approach: e.g embedded SQL (for C,
C++, etc.), SQLJ (for Java)
 Procedure Call Approach: e.g. JDBC for Java,
ODBC for other programming languages
 Database Programming Language Approach:
e.g. ORACLE has PL/SQL, a programming
language based on SQL; language incorporates
SQL and its data types as integral components

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 38

User-Friendly DBMS Interfaces

 Menu-based, popular for browsing on the web

 Forms-based, designed for naïve users
 Graphics-based

(Point and Click, Drag and Drop, etc.)
 Natural language: requests in written English
 Combinations of the above:

For example, both menus and forms used
extensively in Web database interfaces

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 39

Other DBMS Interfaces
 Speech as Input and Output
 Web Browser as an interface
 Parametric interfaces, e.g., bank tellers using
function keys.
 Interfaces for the DBA:

Creating user accounts, granting authorizations

Setting system parameters

Changing schemas or access paths

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 40

Chapter 3
Data Modeling Using the Entity-
Relationship (ER) Model

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Chapter Outline
 Overview of Database Design Process
 Example Database Application (COMPANY)
 ER Model Concepts
 Entities and Attributes
 Entity Types, Value Sets, and Key Attributes
 Relationships and Relationship Types
 Weak Entity Types
 Roles and Attributes in Relationship Types
 ER Diagrams – Notation

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 42

Example COMPANY Database
 We need to create a database schema design
based on the following (simplified) requirements
of the COMPANY Database:
 The company is organized into DEPARTMENTs.
Each department has a name, number and an
employee who manages the department. We keep
track of the start date of the department manager.
A department may have several locations.
 Each department controls a number of
PROJECTs. Each project has a unique name,
unique number and is located at a single location.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 43

Example COMPANY Database
(Contd.)
 We store each EMPLOYEE’s social security
number, address, salary, sex, and birthdate.

Each employee works for one department but may
work on several projects.

We keep track of the number of hours per week that
an employee currently works on each project.

We also keep track of the direct supervisor of each
employee.
 Each employee may have a number of
DEPENDENTs.

For each dependent, we keep track of their name,
sex, birthdate, and relationship to the employee.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 44

ER Model Concepts
 Entities and Attributes

Entities are specific objects or things in the mini-world that
are represented in the database.

For example the EMPLOYEE John Smith, the Research
DEPARTMENT, the ProductX PROJECT

Attributes are properties used to describe an entity.

For example an EMPLOYEE entity may have the attributes
Name, SSN, Address, Sex, BirthDate

A specific entity will have a value for each of its attributes.

For example a specific employee entity may have
Name='John Smith', SSN='123456789', Address ='731,
Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55‘

Each attribute has a value set (or data type) associated with
it – e.g. integer, string, subrange, enumerated type, …

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 45

Types of Attributes (1)
 Simple

Each entity has a single atomic value for the attribute. For
example, SSN or Sex.
 Composite

The attribute may be composed of several components. For
example:

Address(Apt#, House#, Street, City, State, ZipCode, Country), or

Name(FirstName, MiddleName, LastName).

Composition may form a hierarchy where some components
are themselves composite.
 Multi-valued

An entity may have multiple values for that attribute. For
example, Color of a CAR or PreviousDegrees of a STUDENT.

Denoted as {Color} or {PreviousDegrees}.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 46

Types of Attributes (2)
 In general, composite and multi-valued attributes
may be nested arbitrarily to any number of levels,
although this is rare.
 For example, PreviousDegrees of a STUDENT is
a composite multi-valued attribute denoted by
{PreviousDegrees (College, Year, Degree, Field)}
 Multiple PreviousDegrees values can exist
 Each has four subcomponent attributes:

College, Year, Degree, Field

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 47

Example of a composite attribute

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 48

Entity Types and Key Attributes (1)
 Entities with the same basic attributes are
grouped or typed into an entity type.
 For example, the entity type EMPLOYEE
and PROJECT.
 An attribute of an entity type for which each
entity must have a unique value is called a
key attribute of the entity type.
 For example, SSN of EMPLOYEE.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 49

Entity Types and Key Attributes (2)
 A key attribute may be composite.
 VehicleTagNumber is a key of the CAR entity

type with components (Number, State).

 An entity type may have more than one key.
 The CAR entity type may have two keys:


VehicleIdentificationNumber (popularly called VIN)

VehicleTagNumber (Number, State), aka license
plate number.
 Each key is underlined

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 50

Displaying an Entity type
 In ER diagrams, an entity type is displayed in a
rectangular box
 Attributes are displayed in ovals
 Each attribute is connected to its entity type
 Components of a composite attribute are
connected to the oval representing the composite
attribute
 Each key attribute is underlined
 Multivalued attributes displayed in double ovals
 See CAR example on next slide

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 51

Entity Type CAR with two keys and a
corresponding Entity Set

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 52

Entity Set
 Each entity type will have a collection of entities
stored in the database
 Called the entity set
 Previous slide shows three CAR entity instances
in the entity set for CAR
 Same name (CAR) used to refer to both the entity
type and the entity set
 Entity set is the current state of the entities of that
type that are stored in the database

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 53

Initial Design of Entity Types for the
COMPANY Database Schema

 Based on the requirements, we can identify four

initial entity types in the COMPANY database:
 DEPARTMENT
 PROJECT
 EMPLOYEE
 DEPENDENT
 Their initial design is shown on the following slide
 The initial attributes shown are derived from the
requirements description

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 54

Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 55

Refining the initial design by introducing
relationships
 The initial design is typically not complete
 Some aspects in the requirements will be
represented as relationships
 ER model has three main concepts:
 Entities (and their entity types and entity sets)
 Attributes (simple, composite, multivalued)
 Relationships (and their relationship types and
relationship sets)
 We introduce relationship concepts next

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 56

Relationships and Relationship Types (1)
 A relationship relates two or more distinct entities with a
specific meaning.

For example, EMPLOYEE John Smith works on the ProductX
PROJECT, or EMPLOYEE Franklin Wong manages the
Research DEPARTMENT.
 Relationships of the same type are grouped or typed into
a relationship type.

For example, the WORKS_ON relationship type in which
EMPLOYEEs and PROJECTs participate, or the MANAGES
relationship type in which EMPLOYEEs and DEPARTMENTs
participate.
 The degree of a relationship type is the number of
participating entity types.

Both MANAGES and WORKS_ON are binary relationships.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 57

Relationship instances of the WORKS_FOR N:1
relationship between EMPLOYEE and DEPARTMENT

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 58

Relationship instances of the M:N WORKS_ON
relationship between EMPLOYEE and PROJECT

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 59

Relationship type vs. relationship set (1)
 Relationship Type:
 Is the schema description of a relationship
 Identifies the relationship name and the
participating entity types
 Also identifies certain relationship constraints
 Relationship Set:
 The current set of relationship instances
represented in the database
 The current state of a relationship type

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 60

Relationship type vs. relationship set (2)
 Previous figures displayed the relationship sets
 Each instance in the set relates individual
participating entities – one from each participating
entity type
 In ER diagrams, we represent the relationship
type as follows:
 Diamond-shaped box is used to display a
relationship type
 Connected to the participating entity types via
straight lines

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 61

Refining the COMPANY database
schema by introducing relationships
 By examining the requirements, six relationship types are
identified
 All are binary relationships( degree 2)
 Listed below with their participating entity types:
 WORKS_FOR (between EMPLOYEE, DEPARTMENT)
 MANAGES (also between EMPLOYEE, DEPARTMENT)
 CONTROLS (between DEPARTMENT, PROJECT)
 WORKS_ON (between EMPLOYEE, PROJECT)
 SUPERVISION (between EMPLOYEE (as subordinate),
EMPLOYEE (as supervisor))
 DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 62

ER DIAGRAM – Relationship Types are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 63

Discussion on Relationship Types
 In the refined design, some attributes from the initial entity
types are refined into relationships:
 Manager of DEPARTMENT -> MANAGES
 Works_on of EMPLOYEE -> WORKS_ON
 Department of EMPLOYEE -> WORKS_FOR
 etc
 In general, more than one relationship type can exist
between the same participating entity types
 MANAGES and WORKS_FOR are distinct relationship
types between EMPLOYEE and DEPARTMENT
 Different meanings and different relationship instances.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 64

Recursive Relationship Type
 An relationship type whose with the same participating
entity type in distinct roles
 Example: the SUPERVISION relationship
 EMPLOYEE participates twice in two distinct roles:
 supervisor (or boss) role
 supervisee (or subordinate) role
 Each relationship instance relates two distinct
EMPLOYEE entities:
 One employee in supervisor role
 One employee in supervisee role

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 65

Weak Entity Types
 An entity that does not have a key attribute
 A weak entity must participate in an identifying relationship type with
an owner or identifying entity type
 Entities are identified by the combination of:
 A partial key of the weak entity type

 The particular entity they are related to in the identifying entity

type
 Example:
 A DEPENDENT entity is identified by the dependent’s first name,

and the specific EMPLOYEE with whom the dependent is related

 Name of DEPENDENT is the partial key

 DEPENDENT is a weak entity type

 EMPLOYEE is its identifying entity type via the identifying

relationship type DEPENDENT_OF

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 66

Constraints on Relationships
 Constraints on Relationship Types
 (Also known as ratio constraints)
 Cardinality Ratio (specifies maximum participation)

One-to-one (1:1)

One-to-many (1:N) or Many-to-one (N:1)

Many-to-many (M:N)
 Existence Dependency Constraint (specifies minimum
participation) (also called participation constraint)

zero (optional participation, not existence-dependent)

one or more (mandatory participation, existence-dependent)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 67

Many-to-one (N:1) Relationship

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 68

Many-to-many (M:N) Relationship

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 69

Displaying a recursive
relationship
 In a recursive relationship type.

Both participations are same entity type in
different roles.

For example, SUPERVISION relationships
between EMPLOYEE (in role of supervisor or
boss) and (another) EMPLOYEE (in role of
subordinate or worker).
 In following figure, first role participation labeled
with 1 and second role participation labeled with
2.
 In ER diagram, need to display role names to
distinguish participations.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 70

A Recursive Relationship Supervision`

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 71

Recursive Relationship Type is: SUPERVISION
(participation role names are shown)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 72

Attributes of Relationship types
 A relationship type can have attributes:
 For example, HoursPerWeek of WORKS_ON
 Its value for each relationship instance describes
the number of hours per week that an EMPLOYEE
works on a PROJECT.

A value of HoursPerWeek depends on a particular
(employee, project) combination
 Most relationship attributes are used with M:N
relationships

In 1:N relationships, they can be transferred to the
entity type on the N-side of the relationship

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 73

Example Attribute of a Relationship Type:
Hours of WORKS_ON

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 74

Notation for Constraints on
Relationships
 Cardinality ratio (of a binary relationship): 1:1,
1:N, N:1, or M:N
 Shown by placing appropriate numbers on the
relationship edges.
 Participation constraint (on each participating
entity type): total (called existence dependency)
or partial.
 Total shown by double line, partial by single line.
 NOTE: These are easy to specify for Binary
Relationship Types.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 75

Alternative (min, max) notation for
relationship structural constraints:
 Specified on each participation of an entity type E in a relationship
type R
 Specifies that each entity e in E participates in at least min and at
most max relationship instances in R
 Default(no constraint): min=0, max=n (signifying no limit)
 Must have minmax, min0, max 1
 Derived from the knowledge of mini-world constraints
 Examples:

A department has exactly one manager and an employee can
manage at most one department.

Specify (0,1) for participation of EMPLOYEE in MANAGES

Specify (1,1) for participation of DEPARTMENT in MANAGES

An employee can work for exactly one department but a
department can have any number of employees.

Specify (1,1) for participation of EMPLOYEE in WORKS_FOR

Specify (0,n) for participation of DEPARTMENT in WORKS_FOR

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 76

The (min,max) notation for
relationship constraints

Read the min,max numbers next to the entity

type and looking away from the entity type

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 77

COMPANY ER Schema Diagram using (min,
max) notation

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 78

Alternative diagrammatic notation
 ER diagrams is one popular example for
displaying database schemas
 Many other notations exist in the literature and in
various database design and modeling tools
 Appendix A illustrates some of the alternative
notations that have been used
 UML class diagrams is representative of another
way of displaying ER concepts that is used in
several commercial design tools

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 79

Summary of notation for ER diagrams

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 80