MODULE – 1

INTRODUCTION TO DATABASES

OVERVIEW OF DATABASE LANGUAGES

AND ARCHITECTURES

CONCEPTUAL DATA MODELING USING

ENTITIES AND RELATIONSHIPS

1
INTRODUCTION
⚫Definition
⚫DBMS- Definition and
Functionalities
⚫Properties of database
⚫A Simplified Database System
Environment
⚫Example of University Database

2
Basic Definitions
⚫ Data: Known facts that can be recorded and have an implicit
meaning.

⚫ Database: A collection of related data with an implicit meaning.

⚫ Mini-world or Universe of discourse(UoD): 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 collection of

programs that enables users to create and maintain database.
DBMS is a general purpose software system that facilitates the
processes of defining, constructing, manipulating and sharing
databases among various users and applications.

⚫ Database System: The DBMS software together with the

database. Sometimes, the applications are also included.

⚫ Metadata : The information present in the database in the form of3

 Implicit Properties of database
⚫ Database represents some aspects of the real
world(miniworld), Changes to the miniworld are
reflected in database.

⚫ database is logically coherent collection of data,

random assortment of data cannot be referred as
database.

⚫ A DB is designed, built and populated with data

for specific purpose, it has an intended group of
users and some preconceived applications In
which these users are interested.
4
 Typical DBMS Functionality
⚫ Define a database : In terms of data types,
structures and constraints.

⚫ Construct or Load the Database on a secondary

storage medium.

⚫ Manipulating the database : Querying, generating

reports, insertions, deletions and modifications to
its content to reflect changes in the miniworld

⚫ Sharing and Concurrent Processing by a set of

users and programs – yet, keeping all data valid
and consistent.

5
 Typical DBMS Functionality
Other functions of DBMS

◦ Protection or Security measures to

prevent unauthorized access

◦ Maintaining of the database for a

longer period of time by allowing the
system to evolve as requirements
change over time.

6
A Simplified Database System
Environment

7
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 could be expressed in the

ENTITY-RELATIONSHIP data model.

8
Example of a Database System

9
 Main Characteristics of the
Database Approach
⚫ Self-describing nature of a database system:
◦ A DBMS catalog stores the description of the database.
The description is called meta-data. This allows the
DBMS software to work with different databases.
⚫ Insulation between programs and data:
◦ Program – data independence
●Allows changing data storage structures and operations
without having to change the DBMS access programs.
◦ Program – operation independence
●User application programs can operate on the data by
invoking operations through their names and
parameters regardless how operations are
implemented.

10
 Main Characteristics of the
Database Approach

⚫ Data Abstraction:
◦ The characteristics that allows program – data
independence and program – operation
independence is called 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. 11
 Main Characteristics of the
Database Approach

⚫ Sharing of data and multiuser transaction

processing :
◦ Allowing a set of concurrent users to retrieve
and to update the database. Concurrency
control within the DBMS guarantees that each
transaction is correctly executed or
completely aborted.

◦ OLTP (Online Transaction Processing) is a major

part of database applications.

12
Database Users
Users may be divided into those
who actually use and control the
content (called “Actors on the
Scene”) and
those who enable the
database to be developed and
the DBMS software to be
designed and implemented
(called “Workers Behind the
Scene”).
13
 Database Users
Actors on the scene

◦ Database administrators: responsible for authorizing

access to the database, for co – ordinating and monitoring its
use, acquiring software, and hardware resources, controlling
its use and monitoring efficiency of operations.

◦ Database Designers: responsible to define the content, the

structure, the constraints, and functions or transactions
against the database. They must communicate with the end-
users and understand their needs.

◦ End-users: they use the data for queries, reports and some
of them actually update the database content.

◦ System Analysts and Application

Programmers(Software Engineers):
● System Analyst determine the requirements of end users,
especially Naïve and parametric end users and develop
specifications for canned transactions that meet these
requirements. 14
 Categories of End-users
⚫Casual : access database occasionally
when needed

⚫Naive or Parametric : they make up a

large section of the end-user population.
They use previously well-defined
functions in the form of “canned
transactions” against the database.
Examples are bank-tellers or reservation
clerks who do this activity for an entire
shift of operations.
15
 Categories of End-users
⚫Sophisticated : these include business
analysts, scientists, engineers, others
thoroughly familiar with the system
capabilities. Many 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. An example is a tax
program user that creates his or her own
internal database. 16
 Database Users

⚫Workers behind the scene

◦ DBMS System Designers and Implementers

◦ Tool Developers
◦ Operators and Maintenance Personnel

17
 Advantages of Using the Database
Approach
⚫ Controlling redundancy in data storage and in
development and maintenance efforts.

⚫ Restricting unauthorized access to data.

⚫ Providing persistent storage for program

Objects

⚫ Providing Storage Structures for efficient

Query Processing

18
 Advantages of Using the Database
Approach

⚫ Providing backup and recovery services.

⚫ Providing multiple interfaces to different

classes of users.

⚫ Representing complex relationships among

data.

⚫ Enforcing integrity constraints on the database.

⚫ Permitting Inferencing and Actions using rules

19
 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) etc.

⚫Reduced application development

time:
◦ Incremental time to add each new application is reduced.

20
 Additional Implications of Using the
Database Approach
⚫Flexibility to change data structures:
◦ Database structure may evolve as new requirements are
defined.

⚫Availability of up-to-date
information:
◦ Very important for on-line transaction systems such as airline,
hotel, car reservations.

⚫Economies of scale:
◦ By consolidating data and applications across departments
wasteful overlap of resources and personnel can be avoided.
21
 When not to use a DBMS
⚫ Main inhibitors (costs) of using a DBMS:
◦ High initial investment and possible need for
additional hardware.
◦ Overhead for providing generality, security,
concurrency control, recovery, and integrity
functions.

⚫ When a DBMS may be unnecessary:

◦ If the database and applications are simple, well
defined, and not expected to change.
◦ If there are stringent real-time requirements that
may not be met because of DBMS overhead.
◦ If access to data by multiple users is not required.

22
When not to use a DBMS
⚫When no DBMS may suffice:
◦ If the database system is not able to
handle the complexity of data
because of modeling limitations

◦ If the database users need special

operations not supported by the
DBMS.

23
Brief History of Database Applications

⚫Early Database Applications: The

Hierarchical and Network Models were
introduced in mid 1960’s and dominated
during the seventies. A bulk of the
worldwide database processing still
occurs using these models.

⚫Relational Model based Systems: The

model that was originally introduced in
1970 was heavily researched and
experimented with in IBM and the
universities. Relational DBMS Products
emerged in the 1980’s. 24
 Historical Development of
Database Technology
⚫ Object-oriented applications: OODBMSs
were introduced in late 1980’s and early
1990’s to cater to the need of complex data
processing in CAD and other applications.
Their use has not taken off much.

⚫ Data on the Web and E-commerce

Applications: Web contains data in HTML
(Hypertext markup language) with links
among pages. This has given rise to a new
set of applications and E-commerce is using
new standards like XML (eXtended Markup
Language).

25
Extending Database Capabilities

⚫New functionality is being added to

DBMSs in the following areas:
◦ Scientific Applications
◦ Image Storage and Management
◦ Audio and Video data management
◦ Data Mining
◦ Spatial data management
◦ Time Series and Historical Data Management

The above gives rise to new research and development in

incorporating new data types, complex data structures,
new operations and storage and indexing schemes in
database systems.
26
Data Models
⚫Data Model: A set of concepts to
describe the structure of a database,
and certain constraints that the
database should obey.

⚫Data Model Operations: Operations

for specifying database retrievals and
updates by referring to the concepts
of the data model. Operations on the
data model may include basic
operations and user-defined
operations. 27
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.

⚫Implementation (representational)
data models
◦ Provide concepts that fall between the above two,
balancing user views with some computer storage 28
Schemas, Instances and Database State

⚫ Database Schema
◦ The description of a database. Includes descriptions of the database
structure and the constraints that should hold on the database.

⚫ Schema Diagram
◦ A diagrammatic display of (some aspects of) a database schema.

⚫ Schema Construct
◦ A component of the schema or an object within the schema, e.g.,
STUDENT, COURSE.

⚫ Database State
◦ The actual data stored in a database at a particular moment in time.
Also called snapshot or instance or occurrence.

29
30
Database Schema Vs. Database
State
⚫Initial Database State
◦ Refers to the database when it is loaded

⚫Valid State
◦ A state that satisfies the structure and constraints of the
database.

⚫Distinction
◦ The database schema changes very infrequently. The database state
changes every time the database is updated.
◦ Schema is also called intension, whereas state is called
extension.

31
Three-Schema Architecture
⚫Proposed to support DBMS
characteristics of:

◦ Program-data independence.

◦ Support of multiple views of the

data.

32
Three-Schema Architecture
⚫ Defines DBMS schemas at three levels:

◦ Internal schema at the internal level to

describe physical storage structures and access
paths. 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 level.

33
Three-Schema Architecture

34
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.

35
 Data Independence
⚫ The capacity to change the schema at one level of a
database system without having to change the
system at the next higher level.

⚫ Two types of data independences:

◦ Logical Data Independence: The capacity to change the
conceptual schema without having to change the external
schemas and their application programs.

◦ Physical Data Independence: The capacity to change

the internal schema without having to change the
conceptual schema.

36
Data Independence
⚫ 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.
37
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.
38
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 or an Assembly
Language.

◦ Alternatively, stand-alone DML commands

can be applied directly (query
language).
39
DML Types
⚫High Level or Non-procedural
DML: e.g., SQL, are set-oriented
and specify what data to retrieve
than how to retrieve. Also called
declarative languages.

⚫Low Level or Procedural DML:

record-at-a-time; they specify
how to retrieve data and include
constructs such as looping.
40
 DBMS Interfaces
⚫Stand-alone query language interfaces.

⚫Programmer interfaces for embedding DML

in programming languages:

◦ Pre-compiler Approach

◦ Procedure (Subroutine) Call Approach

41
DBMS Interfaces
⚫ User-friendly 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
◦ Speech as Input and Output
◦ Web Browser as an interface
◦ Parametric interfaces (e.g., bank tellers) using
function keys.
◦ Interfaces for the DBA:
●Creating accounts, granting authorizations
●Setting system parameters
●Changing schemas or access path

42
DBMS Component Modules

43
 DBMS ARCHITECTURES

CENTRALIZED DBMS ARCHITECTURE

44
 BASIC CLIENT/SERVER ARCHITECTURES

⚫ Two main types of basic DBMS

architectures were created on this underlying
client/server framework: two-tier and three-
tier.

45
Two-Tier Client/Server Architectures
for DBMSs
⚫ In such an architecture, the
server is often called a query
server or transaction server
because it provides these two
functionalities.

⚫ In an RDBMS, the server is also

often called an SQL server.
The user interface programs
and application programs can
run on the client side.

⚫A standard called Open

Database Connectivity
(ODBC) provides an
application programming
interface (API), which allows
client-side programs to call the
DBMS, as long as both client
46
Three-Tier and n-Tier Architectures for Web Applications

⚫ Intermediate layer or
middle tier is called the
application server or the
Web server, depending
on the application.
⚫ This server plays an
intermediary role by
running application
programs and storing
business rules (procedures
or constraints) that are
used to access data from
the database server.
⚫ It can also improve
database security by47
Using High – Level Conceptual Data Models
for Database Design

48
An Example Database
Application
⚫ Requirements of the Company
(oversimplified for illustrative purposes)

◦ 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 name, number and is located
at a single location.

49
Contd…
⮚ We store each EMPLOYEE’s social security
number, address, salary, sex, and birth
date. 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, birth date, and
relationship to employee.
50
Entity Types, Entity Sets, Attributes
and Keys

⚫ Entity
◦ A thing in the real world with an
independent existence.
◦ Eg: A particular person, Car, House or an
Employee

⚫ Attribute
◦ The particular property that describes
the entity.
◦ Eg: An Employee’s name, age, address,
salary and job
51
Types of Attributes
⚫ Composite versus simple(Atomic) Attributes

⚫ Single Valued versus Multivalued Attributes

⚫ Stored versus Derived Attributes

⚫ Complex Attributes
◦ For example, {Address_phone({Phone(Area_Code,
Phone_Number)}, Address(Street_Address(Number,
Street, Apartment_Number), City, Zip_Code))}

⚫ Null Values

52
Entity Types
⚫ A collection of entities that have the same
attributes.

⚫ Each entity type in the database is described by its

name and attributes.

⚫ An entity type describes the schema or intension

for a set of entities that share the same structure.

⚫ Eg: EMPLOYEE and COMPANY and a list of attributes

for each.

⚫ An entity type is represented in ER diagrams as a

rectangular box enclosing the entity type name.
53
Entity Set
⚫The collection of entities of a
particular entity type is grouped
into an entity set.

⚫This is also called as Extension

of the entity type.

54
Key Attribute of an Entity Type

⚫ An entity type usually has an attribute whose

values are distinct for each individual entity in the
entity set.

⚫ Such an attribute is called as key attribute and its

values can be used to identify each entity
uniquely.

⚫ Eg: No two companies will have the same name,

so name attribute is the key attribute in COMPANY.

⚫ In ER diagrammatic notation, each key attribute

has its name underlined inside the oval.

55
Value Sets (Domains) of
Attributes
⚫Each simple attribute of an entity
type is associated with a value
set (or domain of values), which
specifies the set of values that
may be assigned to that attribute
for each individual entity.

⚫Value sets are typically specified

using the basic data types.
56
 ENTITY SET corresponding to
the
ENTITY TYPE CAR Entity Type

CAR
Registration(RegistrationNumber, State), VehicleID, Make, Model, Year, (Color)

car1
((ABC 123, TEXAS), TK629, Ford Mustang, convertible, 1999,
(red, black))
car2
((ABC 123, NEW YORK), WP9872, Nissan 300ZX, 2-door,
2002, (blue))
car3
((VSY 720, TEXAS), TD729, Buick LeSabre, 4-door, 2003,
Entity Set
(white, blue))
.
.
. 57
Relationship Types, Relationship
Sets, and Instances
⚫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.

⚫Mathematically, the relationship

set R is a set of relationship
instances ri, where each ri
associates n individual entities. 58
 Example 1…
EMPLOYEE WORKS_FOR DEPARTMENT

e1  r1  d1
e2  r2
d2
e3 

r3
e4 
r4  d3
e5 
r5
e6 

e7 r6


r7

59
Example 2…
EMPLOYEE WORKS_ON PROJECT
r9

e1 
r1  p1
e2  r2
p2
e3  r3


e4 
r4  p3
e5 
r5
e6 
r6
e7 

r7
r
8
60
Relationship Degree
⚫The degree of a relationship type
is the number of participating
entity types.

⚫A relationship type of degree two

is called binary, and one of
degree three is called ternary.

61
Role Names and Recursive Relationships

⚫ Each entity type that participates in a

relationship type plays a particular role in the
relationship.

⚫ The role name signifies the role that a

participating entity from the entity type plays
in each relationship instance, and helps to
explain what the relationship means.

⚫ Some entity types participates more than once

in a relationship type in different roles. Such
relationship types are called recursive
relationships.
62
Example…
EMPLOYEE SUPERVISION

e1 2

1 r1
e2  2
1 r2
e3 
2
1 r3
e4 
2
e5 1
 1 r4
e6 2
 1 r5
e7  2
r6
(1) Supervisor
Role
(2) Subordinate
Role 63
 Constraints on Relationship
Types
⚫ There are two types of relationship constraints:

◦ Cardinality ratio
● The cardinality ratio for binary relationship specifies the
maximum number of relationship instances that an entity
can participate in.
● The possible cardinality ratio for binary relationship types
are 1:1, 1:N, N:1 and M:N
◦ Participation
● The participation constraint specifies whether the existence
of an entity depends on its being related to another entity
via the relationship type.
● This constraint specifies the minimum number of
relationship instances that each entity can participate in.

⚫ The cardinality ratio and participation constraint together called

as structural constraint. 64
 1:1 Relationship
EMPLOYEE MANAGES DEPARTMENT

e1  r1  d1
e2  r2
d2
e3 

r3
e4 
d3
e5 
. 

e6 
.
e7 

65
 1:N Relationship
EMPLOYEE WORKS_FOR DEPARTMENT

e1  r1  d1
e2  r2
d2
e3 

r3
e4 
r4  d3
e5 
r5
e6 

e7 r6


r7

66
 M:N Relationship
EMPLOYEE WORKS_ON PROJECT
r9

e1  r1  p1
e2  r2
p2
e3 

r3
e4 
r4  p3
e5 
r5
e6 

e7 r6


r7
r8

67
Participation Constraint and
Existence Dependence
⚫ The participation constraint specifies
whether the existence of an entity
depends on its being related to another
entity via the relationship type.

⚫ This is also called as minimum cardinality

constraint.

⚫ Two types of participation constraint:

◦ Total Participation, also called as Existence
Dependency
◦ Partial Participation
68
Attributes as 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.

69
 Weak Entity Types
⚫ Entity types that do not have key attributes of their own are called
weak entity types.

⚫ The entity types which contain key attributes of their own are called
regular entity types or strong entity types.

⚫ Entities belonging to weak entity type are identified by being related

to specific entities from another entity type in combination with one of
their attribute values. This other entity type is called as identifying
entity type or owner entity type.

⚫ The relationship type that relates a weak entity type to its owner is
called as identifying relationship of the weak entity type.

⚫ The weak entity type normally has a partial key, which is the set of
attributes that can uniquely identify weak entities that are related to
the same owner entity.
70
Example…
Example:
Suppose that a DEPENDENT entity
is identified by the dependent’s
first name and birth date, and the
specific EMPLOYEE that the
dependent is related to.

DEPENDENT is a weak entity type

with EMPLOYEE as its identifying
entity type via the identifying
relationship type DEPENDENT_OF.
71
Notations Used in ER Diagrams
Symb Meaning
ol
ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE

DERIVED ATTRIBUTE

TOTAL PARTICIPATION OF E2 IN R

E1 R E2 CARDINALITY RATIO 1:N FOR E1:E2 IN R

E1 1 N STRUCTURAL CONSTRAINT (min, max) ON

R E2
PARTICIPATION OF E IN R
(min,ma
R
x)
E

72
Proper Naming of Schema
Constructs
⚫ Use singular names for entity types,
rather than plural one.

⚫ Verbs tend to indicate the relationship

types.

⚫ Anothernaming consideration involves

choosing the binary relationship names
to make the ER diagram of the schema
readable from left to right and top to
bottom.
73
E – R Diagram for COMPANY

74
Alternative Notations for ER
Diagrams

75
Relationships of Higher Degree
⚫Relationship types of degree 2
are called binary
⚫Relationship types of degree 3
are called ternary and of degree
n are called n-ary
⚫In general, an n-ary relationship
is not equivalent to n binary
relationships

76
 Subclasses and Superclasses
❑An entity type may have additional
meaningful subgroupings of its entities
SECRETAR
Y
Superclasses: EMPLOYEE
ENGINEER
EMPLOYEE Subclasses: SECRETARY,
ENGINEER,
TECHNICIA
N
TECHNICIAN,

SALARIED_EMPLOYEE,
SALARIED_EMPLOYEE HOURLY_EMPLOYEE

HOURLY_EMPLOYEE

Every entity that is a member of one of these

subgroupings is also an employee

77
 Example

Lname SSN
Fname Addr

DEPARTMENT WORKS EMPLOYEE

d
∪ ∪ d
∪ ∪
∪
TypingSpee
EngType MANAGER ∪
d TGrade HOURLY_EM
P
SECRETAR TECHNICIA ENGINEE SALARIED_EM
Y N R P

EMPLOYEE: WORKS MANAGES BELONGS_T

SECRETARY: WORKS O
TECHNICIAN: WORKS
ENGINEER: WORKS
MANAGER: WORKS, MANAGES PROJECT TRADE_UNIO
SALARIED_EMP: WORKS N
HOURLY_EMP: WORKS, BELONGS_TO

78
Why class/subclass relationships
and specializations
⚫ Certain attributes may apply to some but not
all entities of the superclass.
◦ A subclass is defined in order to group the entities to
which these attributes apply.
◦ The members of the subclass may still share the
majority of their attributes with the other members
of the superclass.

EMPLOYEE (Name, SSN, BirthDate, Address)

SECRETARY (Name, SSN, BirthDate, Address,
TypingSpeed)
ENGINEER (Name, SSN, BirthDate, Address,
EngineerType)
TECHNICIAN (Name, SSN, BirthDate, Address, TGrade)

79
Why need class/subclass
relationships and specializations
⚫Some relationship types may be
participated in only by entities
that are members of the
subclass.

80
Subclasses vs. Superclasses
⚫ The set of entities in each subclasses is a
subset of the entities that belong to
EMPLOYEE
⚫ Each is called a subclass of EMPLOYEE
⚫ EMPLOYEE is the superclass for each of
these subclasses
⚫ The relationship between a superclass
and any one of its subclass is called a
superclass/subclass or class/subclass
relationship.
e.g., EMPLOYEE/SECRETARY and EMPLOYEE/TECHNICIAN are two
class/subclass relationships.

81
Properties of Superclasses and
Subclasses
⚫A member entity of the subclass
represents the same real-world entity
as some member of the superclass.

⚫ The subclass member is the same as the

entity in the superclass, but in a distinct
specific role.

⚫ When implementing a superclass/subclass

relationship, a member of the subclass
may be represented as a distinct
database object – a distinct record that
is related via the key attribute to its
superclass entity.
82
Properties of Superclasses and
Subclasses (cont.)
⚫ An entity CANNOT exist in the DB
merely by being a member of a
subclass. It must also be a member
of the superclass.
⚫ An entity can be a member of more
than one subclass.
◦ Example: A salaried employee who is also an engineer belongs to
the two subclasses ENGINEER and SALARIED_EMPLOYEE

⚫ Itis not necessary that every entity in a

superclass be a member of some
subclass
◦ Example: A technical writer is an employee but does not belong to
any subclasses.
83
Type inheritance
⚫The type of an entity is defined
by the attributes it possesses
and the relationship types
which it participates.
⚫An entity that is a member of a
subclass inherits all the
attributes of the entity as a
member of the superclass, as
well as all the relationships in
which the superclass participates.
84
Example
Lnam SSN
e Addr EMPLOYEE
Fnam
e Fname, Lname, SSN,
Addr
SECRETARY
EMPLOYEE Fname, Lname, SSN, Addr
TypingSpeed
TECHNICIAN
Fname, Lname, SSN, Addr, TGrade
d ENGINEER
Fname, Lname, SSN, Addr, EngType

∪
TypingSpeed ∪ ∪ EngType
TGrade

SECRETARY ENGINEER
TECHNICIAN

85
 Example

DEPARTMENT WORKS EMPLOYEE

d
∪ ∪ d
∪ ∪
∪
TypingSpee
EngType MANAGER ∪
d TGrade HOURLY_EM
P
SECRETAR TECHNICIA ENGINEE SALARIED_EM
Y N R P

Entity Type: Relationship Type MANAGES BELONGS_T

EMPLOYEE: WORKS O
SECRETARY: WORKS
TECHNICIAN: WORKS PROJECT TRADE_UNIO
ENGINEER: WORKS N
MANAGER: WORKS, MANAGES
SALARIED_EMP: WORKS
HOURLY_EMP: WORKS, BELONGS_TO

86
Specialization
⚫The process of defining a set of
subclass of an entity type (the
superclass of the specialization).

⚫The set of subclasses that form a

specialization is defined on the basis
of some distinguishing
characteristics of the entities in
the superclass.
{SECRETARY, ENGINEER, TECHNICIAN} is a specialization
of EMPLOYEE based on the job type of each entity.
87
Specialization (cont.)
⚫ The same entity type may have several
specializations based on different
distinguishing characteristics.
⚫ The EMPLOYEE entity type may have two
specializations:
◦ Based on the methods of pay:
{SALARIED_EMPLOYEE, HOURLY_EMPLOYEE}
◦ Based on the type of job:
{SECRETARY, ENGINEER, TECHNICIAN}
⚫ A subclass can participate in specific
relationship type

88
Diagrammatically representation of
specialization in an EER diagram

Esuper

Specific Specific
attributes attributes

∪ ∪
…
…
E2
E1

89
Example
EMPLOYEE

d
∪ ∪ d
∪ ∪
∪
MANAGER ∪
HOURLY_EM
P
SECRETAR TECHNICIA ENGINEE SALARIED_EM
Y N R P

MANAGES BELONGS_T
O

PROJECT TRADE_UNIO
N

90
Specialization
The specialization process allows
us to do the following:
⚫Define a set of subclass of an
entity type
⚫Establish additional specific
attributes with each subclass
⚫Establish additional specific
relationship types between each
subclass and other entity types or
other subclasses 91
Generalization
⚫Generalization is the reverse of
specialization process. It defines
a generalized entity type from
the given entity types.

92
Generalization (cont.)
NoOfPassenger LicensePlateNo NoOfAxles LicensePlateNo
s
MaxSpee Tonnage
d CAR Price TRUCK Price
VehicleID VehicleID

VehicleID Price LicensePlateNo

VEHICLE

NoOfPassenger d
s ∪ NoOfAxles
∪

MaxSpee
d CAR TRUCK Tonnage

93
Generalization (cont.)
⚫We can view {CAR, TRUCK} as a
specialization of VEHICLE
⚫Alternatively, we can view
VEHICLE as a generalization of
CAR and TRUCK

94
Generalization (cont.)
⚫Generalization suppresses the
difference among several entity types,
identifying their common features,
and generalize them into a single
superclass of which the original
types are special subclasses.

⚫The decision as to which process,

generalization or specialization, is
more appropriate in a particular
situation is often subjective.
95
Generalization (cont.)
⚫Generalization suppresses the
difference among several entity types,
identifying their common features,
and generalize them into a single
superclass of which the original
types are special subclasses.

⚫The decision as to which process,

generalization or specialization, is
more appropriate in a particular
situation is often subjective.
96
Questions
1. What are the advantages of DBMS. Explain.
2. Explain the three-schema architecture with a
neat diagram.
3. With a neat diagram, explain the various
components of DBMS.
4. Explain the different ways of interacting with
the databases.
5. Explain the different types of attributes with
examples for each.
6. Write an E-R diagram for hospital database by
considering at least 5 entities.
7. Differentiate between specialization and
generalization.
97