CSE3001-DataBase Management Systems-

UNIT 1

Syllabus

Introduction to Database system: purpose of database

system, T1:View of data, Data Independence(7),
relational databases-TE1:Database Languages(4)-
T2:Database System architecture- levels, Mappings,
Database, users and DBA Data Models: Importance,
Basic building blocks, T3:Degrees of data abstraction(3).
Database design(3) and A1:ER Model: Overview, ER-
Model, Constraints, ER Diagrams, ERD Issues, weak
entity sets. (understand from the slide)
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 1
Basic Definitions:
What is data, database, DBMS??
 Data: Known facts that can be recorded and have an implicit meaning; raw
 Database: a highly organized, interrelated, and structured set of data about a
particular enterprise
 Controlled by a database management system (DBMS)
 DBMS
 Set of programs to access the data
 An environment that is both convenient and efficient to use
 Database systems are used to manage collections of data that are:
 Highly valuable
 Relatively large
 Accessed by multiple users and applications, often at the same time.
 A modern database system is a complex software system whose task is to
manage a large, complex collection of data.
 Databases touch all aspects of our lives

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 2

Purpose of Database Management
Systems
 DBMS contains information about a particular enterprise
 Collection of interrelated data
 Set of programs to access the data
 An environment that is both convenient and efficient to use
 Database Applications:
 Banking: transactions
 Airlines: reservations, schedules
 Universities: registration, grades
 Sales: customers, products, purchases
 Online retailers: order tracking, customized recommendations
 Manufacturing: production, inventory, orders, supply chain
 Human resources: employee records, salaries, tax deductions

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

1. Purpose of Database system:
What a DBMS Facilitates??
 Define a particular database in terms of its data types,
structures, and constraints
 Construct or load the initial database contents on a secondary
storage medium
 Manipulating the database:
 Retrieval: Querying, generating reports
 Modification: Insertions, deletions and updates to its content
 Accessing the database through Web applications
 Processing and sharing by a set of concurrent users and
application programs – yet, keeping all data valid and consistent

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

Purpose of Database Management
Systems
 DBMS may additionally provide:
 Protection or security measures to prevent unauthorized
access
 “Active” processing to take internal actions on data
 Presentation and visualization of data
 Maintenance of the database and associated programs
over the lifetime of the database application

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

Example of a Database

 Mini-world for the example:

 Part of a UNIVERSITY environment
 Some mini-world entities:
 STUDENTs
 COURSEs
 SLOTSs (of COURSEs)
 (Academic) DEPARTMENTs
 INSTRUCTORs

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

Example of a Database

 Some mini-world relationships:

 SLOTSs are of specific COURSEs
 STUDENTs take COURSESs
 COURSEs have prerequisite COURSEs
 INSTRUCTORs teach SLOTSs
 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 (ER) data or UML class model

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

Example of a Simple Database

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

View of Data in DBMS
View level: what application
programs see; views can also hide
information (such as an instructor’s
salary) for security purposes.

type instructor = record

ID : string;
name : string;
dept_name : string;
salary : integer;
end;
Physical level:
describes how a record
(e.g., instructor) is
stored.

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

View of Data in DBMS
 Physical level: describes how a record (e.g., instructor) is
stored.
 Logical level: describes data stored in database, and the
relationships among the data.
type instructor = record
ID : string;
name : string;
dept_name : string;
salary : integer;
end;
 View level: application programs hide details of data
types. Views can also hide information (such as an
employee’s salary) for security purposes.

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

Data Independence Explained-
Animation

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 2- 11

View of Data in DBMS
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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 2- 12

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 2- 13

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 2- 14

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 2- 15

DBMS Languages-
Data Definition Language(DDL)
 Data Definition Language (DDL):
 Used by the DBA and database designers to specify the conceptual schema of a database.
 Example: create table instructor (
ID char(5),
name varchar(20),
dept_name varchar(20),
salary numeric(8,2))
 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
DDL Commands in SQL

 CREATE to create a new table or database.

 ALTER for alteration.
 Truncate to delete data from the table.
 DROP to drop a table.
 RENAME to rename a table.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 2- 16

DBMS Languages-
Data Manipulation Language(DML)
 Language for accessing and manipulating the data organized by the appropriate data
model
 DML also known as query language
 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).
DML Commands
 SELECT – retrieve data from the a database
 INSERT – insert data into a table
 UPDATE – updates existing data within a table
 DELETE – deletes all records from a table, the space for the records remain
 MERGE – UPSERT operation (insert or update)
 CALL – call a PL/SQL or Java subprogram
 LOCK TABLE – control concurrency

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

DBMS Languages-
Data Manipulation Language(DML)
 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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 2- 18

Database System Architecture
(Levels, Mappings, Database, users and DBA)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 19

Database System Architecture
(Levels, Mappings, Database, users and DBA)
 Users:
 DBA staff who works on defining the database and
tuning it by making changes to its definition using the
DDL and other privileged commands
 Casual users who work with interactive interfaces to
formulate queries,
 Application programmers who create programs
using some host programming languages, and
 Parametric users who do data entry work by
supplying parameters to predefined transactions.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 20

Database System Architecture
(Levels, Mappings, Database, users and DBA)
 The DDL compiler processes schema definitions, specified in the DDL, and
stores descriptions of the schemas (meta-data) in the DBMS catalog.
 DBMS Catalog: The catalog includes information such as the names and
sizes of files, names and data types of data items, storage details of each file,
mapping information among schemas, and constraints.
 Stored data manager, which in turn uses basic operating system services
for carrying out low-level input/output (read/write) operations between the
disk and main memory.
 The runtime database processor handles other aspects of data transfer,
such as management of buffers in the main memory. Some DBMSs have
their own buffer management module whereas others depend on the OS for
buffer management.
 Concurrency control and backup and recovery systems are integrated
into the working of the runtime database processor for purposes of
transaction management.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 21

Data Models
 A collection of tools for describing
 Data
 Data relationships
 Data semantics
 Data constraints
 Relational model
 Entity-Relationship data model (mainly for
database design)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

 Data Models- Basic Building blocks-
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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 2- 23

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 2- 24

Data Models- Basic Building blocks-
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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 2- 25

Data Models- Basic Building blocks-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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 2- 26

Relational Model
 All the data is stored in various tables.
 Example of tabular data in the relational model

Columns

Rows

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

A Sample Relational Database

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Data Models- Basic Building blocks-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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 2- 29

Example of a Database Schema

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

Example of a database state

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

Data models-Degrees of data abstraction-
The three-schema architecture

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

 Data models-Degrees of data abstraction-
The 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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 2- 33

Data models-Degrees of data abstraction-
The three-schema architecture
 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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 2- 34

Database Design
The process of designing the general structure of the
database:

 Logical Design – Deciding on the database schema.

Database design requires that we find a “good” collection
of relation schemas.
 Business decision – What attributes should we record in the
database?
 Computer Science decision – What relation schemas should
we have and how should the attributes be distributed among
the various relation schemas?
 Physical Design – Deciding on the physical layout of the
database

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 35

Data Base design Approaches
 Need to come up with a methodology to ensure that each
of the relations in the database is “good”
 Two ways of doing so:
 Entity Relationship Model (Chapter 7)

 Models an enterprise as a collection of entities and

relationships
 Represented diagrammatically by an entity-relationship
diagram:
 Normalization Theory (Chapter 8)
 Formalize what designs are bad, and test for them

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Overview of Database Design Process

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 37

Database Design (Cont.)
 Is there any problem with this relation?

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Tutorial: 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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 39

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 40

ER Model or Entity Relationship Diagram
 ER Model stands for Entity Relationship Model is a high-level
conceptual data model diagram.
 ER model helps to systematically analyze data requirements to
produce a well-designed database.
 The ER Model represents real-world entities and the
relationships between them.
 Creating an ER Model in DBMS is considered as a best
practice before implementing your database.
 ER Modeling helps you to analyze data requirements
systematically to produce a well-designed database.
 So, it is considered a best practice to complete ER modeling
before implementing your database.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 41

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, Gender, 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',
Gender='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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 42

Entity Relationship Diagram-
Animation Explained

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 43

Types of Attributes (1)
 Simple
 Each entity has a single atomic value for the attribute. For example,
SSN or Gender.
 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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 44

Example of a composite attribute

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

Relationship of Attributes-Cardinality

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

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 47

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 48

Displaying an Entity type
 ER Diagrams Symbols & Notations
 Entity Relationship Diagram Symbols & Notations mainly contains three
basic symbols which are rectangle, oval and diamond to represent
relationships between elements, entities and attributes. T
 here are some sub-elements which are based on main elements in ERD
Diagram.
 ER Diagram is a visual representation of data that describes how data is
related to each other using different ERD Symbols and Notations.
 Following are the main components and its symbols in ER Diagrams:
 Rectangles: This Entity Relationship Diagram symbol represents entity types
 Ellipses : Symbol represent attributes
 Diamonds: This symbol represents relationship types
 Lines: It links attributes to entity types and entity types with other
relationship types
 Primary key: attributes are underlined
 Double Ellipses: Represent multi-valued attributes

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

Displaying an Entity type
 Following are the main components and its symbols
in ER Diagrams:
 Rectangles: This Entity Relationship Diagram symbol
represents entity types
 Ellipses : Symbol represent attributes
 Diamonds: This symbol represents relationship types
 Lines: It links attributes to entity types and entity
types with other relationship types
 Primary key: attributes are underlined
 Double Ellipses: Represent multi-valued attributes

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

Entity –Attribute-Relationship
-Real life examples

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

Displaying an Entity type

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

Entity, Attributes- Representation
Entities are represented by means of rectangles.
Rectangles are named with the entity set they represent.

Attributes
Attributes are the properties of entities.
Attributes are represented by means of ellipses.
Every ellipse represents one attribute and is directly
connected to its entity (rectangle).

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 53

Composite Attributes- Representation
 If the attributes are composite, they are further divided
in a tree like structure.
 Every node is then connected to its attribute.
 That is, composite attributes are represented by
ellipses that are connected with an ellipse.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 54

Multivalued Attributes-
Representation
 Multivalued attributes are depicted by double ellipse

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 55

 Derived Attributes- Representation
Derived attributes are depicted by dashed ellipse.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 56

Relationship-Representation

 Relationships are represented by diamond-shaped box.

 Name of the relationship is written inside the
diamond-box.
 All the entities (rectangles) participating in a
relationship, are connected to it by a line.
 One-to-one

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 57

Relationship-Representation

 One-to-one

Many-to-One

One-to-Many

Many-to-Many

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 58

 Cardinality-Data Modelling
A cardinality is the number of rows a table can have in the
relationship. Cardinality defines the possible number
of occurrences in one entity which is
associated with the number of
occurrences in another

1.One and Only One

2.One or Many
3.Zero or One or Many

4.Zero or One

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 59

 Cardinality-Data Modelling
A cardinality is the number of rows a table can have in the
relationship.

The relationship line shows that a

customer can have zero or many
orders, while an order can be
associated with one and only one
customer. The verb used for the
relationship can be “places”, as in the
customer places an order.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 60
Cardinality-Data Modelling

Moving on to product and order, a product can

be associated with zero or many orders, while
an order must have one or many products (you
can’t have an order without ordering
something!). For product and order, we can use
the verb “is added to” to describe how a
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 61
 Cardinality-Data Modelling
A cardinality is the number of rows a table can have in the
relationship.

Orders and discount codes have a zero or one relationship: a

customer might not input a discount code, but if they do, they can
only use one at a time. Going back down the line the other way, an
order might not have any discount code associated with it, but if it
does, it can only have one. A discount code is “applied to” an order.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 62

ERD-Car

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

ERD-Relationships-Employee Mini World

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

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

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

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 66

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 67

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

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

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 69

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 70

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 71

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 72

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 73

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

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

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 75

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 76

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 © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 3- 77