MODULE – 1

INTRODUCTION TO DATABASES

OVERVIEW OF DATABASE LANGUAGES AND

ARCHITECTURES

CONCEPTUAL DATA MODELING USING ENTITIES

AND RELATIONSHIPS
 Types of Databases and Database
Applications

 Numeric and Textual Databases

 Multimedia Databases
 Geographic Information Systems (GIS)
 Data Warehouses and Online Analytical Processing (OLAP)
 Real-time and Active Databases
Basic Definitions

 Database: A collection of related data.

 Data: Known facts that can be recorded and have 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.
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.

 Concurrent Processing and Sharing by a set of users and

programs – yet, keeping all data valid and consistent.
Typical DBMS Functionality

Other features:

 Metadata : The information present in the database

in the form of data catalog or data dictionary.

 Protection or Security measures to prevent

unauthorized access

 “Active” processing to take internal actions on data

 Presentation and Visualization of data

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

Note: The above could be expressed in the ENTITY-

RELATIONSHIP data model.
A Simplified Database System
Environment
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.
Example of a Database System
Main Characteristics of the Database Approach

1. Self-describing nature of a database system.

2. Insulation between programs and data, and data
manipulation.
3. Support of multiple views of the data.
4. Sharing of data and multi-user transaction processing
 Main Characteristics of the Database Approach

1. Self-describing nature of a database system

What will be your description of the data stored in the following tables ?

1BM14CS001 Aditya 3 WP
1BM14CS002 Bharath 3 DS

1BM14CS001 1000
1BM14CS002 1000

1BM14CS001 S
1BM14CS002 B
Main Characteristics of the Database Approach

1. Self-describing nature of a database system.

Student_Details

USN Name Sem Sub

1BM14CS001 Aditya 3 WP
1BM14CS002 Bharath 3 DS

Student_ExamFee_Details Student_Grade_Details
USN Amount USN Grade
1BM14CS001 1000 1BM14CS001 S
1BM14CS002 1000 1BM14CS002 B
 Main Characteristics of the Database Approach

1. Self-describing nature of a database system.

Column_name Data_Type Belongs_to

USN Char(10) Student_Details Catalog
Information stored in
Name Char(30) Student_Details
catalog is called
Sem Integer Student_Details meta-data which
Describes the structure
Sub Char(2) Student_Details
Of primary
Amount Float Student_ExamFee_Details database
Grade Char(1) Student_Grade_Details
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.
Main Characteristics of the Database Approach

2. Insulation between programs and data, and data

manipulation.
File Approach
student.txt
1BM14CS001 Aditya LA,Java,DBMS,OS,DC
1BM14CS002 Baharth DBMS,OS,DC

fp=fopen("student.txt","r");
while(fscanf(fp,"%s %s %s",USN,name,subjects)!=EOF)
{
printf("USN: %s Name: %s Subjects: %s",USN,name,subjects);
}

What will be the Output of the above program statements ?

Main Characteristics of the Database Approach

2. Insulation between programs and data, and data

manipulation.
File Approach
student.txt
Aditya 1BM14CS001 LA,Java,DBMS,OS,DC
Baharth 1BM14CS002 DBMS,OS,DC

fp=fopen("student.txt","r");
while(fscanf(fp,"%s %s %s",USN,name,subjects)!=EOF)
{
printf("USN: %s Name: %s Subjects: %s",USN,name,subjects);
}
What will be the Output of the above program statements ?
 Main Characteristics of the Database Approach

2. Insulation between programs and data, and data

manipulation.
DBMS Approach
student
USN Name Subjects
1BM14CS001 Aditya LA, Java, DBMS,OS,DC
1BM14CS002 Bharath DBMS, OS, DC

select USN, Name, Subjects from student; SQL query to retrieve

and display table
information

1BM14CS001 Aditya LA,Java,DBMS,OS,DC

1BM14CS002 Bharath DBMS,OS,DC
 Main Characteristics of the Database Approach

2. Insulation between programs and data, and data

manipulation.
DBMS Approach
student
Name USN Subjects
Aditya 1BM14CS001 LA, Java, DBMS,OS,DC
Bharath 1BM14CS002 DBMS, OS, DC

select USN, Name, Subjects from student; SQL query to retrieve

and display table information

1BM14CS001 Aditya LA,Java,DBMS,OS,DC

1BM14CS002 Bharath DBMS,OS,DC
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.
Main Characteristics of the Database Approach

3. Support of multiple views of the data

Main Characteristics of the Database Approach

4. Sharing of data and

Trainmulti-user transaction processing
Reservation Database
Source Destination Train Name Start Time Start Date Number of Seats
Availability
Bangalore Mysore Chamundi 18:15 14-1-2016 2
Express

Train Ticket Booking

Software
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.
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, and data manipulation:
 Called program-data independence.
 Allows changing data structures and storage organization without having to
change the DBMS access programs.
 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
Main Characteristics of the Database Approach

 Support of multiple views of the data:

 Each user may see a different view of the database, which describes
only the data of interest to that user.
 Sharing of data and 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.
Advantages of Using the Database Approach

1. Controlling redundancy in data storage and in development and maintenance

efforts.
2. Restricting unauthorized access to data.
3. Providing persistent storage for program Objects (data structures provided by
DBMS & the programming languages were incompatible)
4. Providing Storage Structures (e.g. indexes) for efficient Query Processing
5. Providing backup and recovery services.
6. Providing multiple interfaces to different classes of users.
7. Representing complex relationships among data.
8. Enforcing integrity constraints on the database.
9. Drawing inferences and actions from the stored data using deductive and active
rules
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”).
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.
 Application Programmers implement these specifications as programs, then they test,
debug, document and maintain these canned transactions.
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.
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.
Database Users

 Workers behind the scene

 DBMS System Designers and Implementers

 Tool Developers
 Operators and Maintenance Personnel
 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

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

 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.
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.
 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.
 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).
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.
 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.
When not to use a DBMS
 When no DBMS may suffice:
 Ifthe database system is not able to handle the
complexity of data because of modeling limitations

 Ifthe database users need special operations not

supported by the DBMS.
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.
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 details.
 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.
Three-Schema Architecture
 Proposed to support DBMS characteristics of:

 Program-data independence.

 Support of multiple views of the data.

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.
Three-Schema Architecture
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 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.
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.
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.
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).
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.
 DBMS Interfaces

 Stand-alone query language interfaces.

 Programmer interfaces for embedding DML in

programming languages:

 Pre-compiler Approach

 Procedure (Subroutine) Call Approach

 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
DBMS Component Modules
Using High – Level Conceptual Data Models for
Database Design
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.
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.
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
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
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.
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.

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.
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.
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, (white, blue))
.
Entity Set .
.
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.
Example 1…
EMPLOYEE WORKS_FOR DEPARTMENT

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

e6 r5


e7  r6

r7
Example 2…
EMPLOYEE WORKS_ON PROJECT
r9

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

e7 r6


r7
r8
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.
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.
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
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.
1:1 Relationship
EMPLOYEE MANAGES DEPARTMENT

e1  r1  d1
e2  r2
e3   d2
r3
e4 

e5 
.  d3

e6 
.
e7 

.
1:N Relationship
EMPLOYEE WORKS_FOR DEPARTMENT

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

e6 r5


e7 
r6

r7
 M:N Relationship
EMPLOYEE WORKS_ON PROJECT
r9

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

r5
e6 

e7 
r6

r7
r8
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
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.
 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.
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.
Notations Used in ER Diagrams
Symbol Meaning

ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE

DERIVED ATTRIBUTE

E1 R E2 TOTAL PARTICIPATION OF E2 IN R

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

E1 R E2

(min,max) STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION OF E IN R

R E
Proper Naming of Schema Constructs

 Use singular names for entity types, rather than

plural one.

 Verbs tend to indicate the relationship types.

 Another naming consideration involves choosing the

binary relationship names to make the ER diagram
of the schema readable from left to right and top
to bottom.
E – R Diagram for COMPANY
Alternative Notations for ER Diagrams
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
 Ingeneral, an n-ary relationship is not equivalent to
n binary relationships
 Subclasses and Superclasses

An entity type may have additional meaningful

subgroupings of its entities
SECRETARY

Superclasses: EMPLOYEE
ENGINEER
EMPLOYEE Subclasses: SECRETARY, ENGINEER,
TECHNICIAN TECHNICIAN,
SALARIED_EMPLOYEE,
HOURLY_EMPLOYEE

SALARIED_EMPLOYEE

HOURLY_EMPLOYEE

Every entity that is a member of one of these subgroupings is

also an employee

Manjunatha A S, Senior Asst. Prof. Dept. of Computer Science & Engg

 Example
Lname SSN
Fname Addr

DEPARTMENT WORKS EMPLOYEE

d
 d

TypingSpeed MANAGER
TGrade EngType HOURLY_EMP

SECRETARY TECHNICIAN ENGINEER SALARIED_EMP

EMPLOYEE: WORKS MANAGES BELONGS_TO

SECRETARY: WORKS
TECHNICIAN: WORKS
ENGINEER: WORKS
MANAGER: WORKS, MANAGES PROJECT TRADE_UNION
SALARIED_EMP: WORKS
HOURLY_EMP: WORKS, BELONGS_TO
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)
Why need class/subclass relationships
and specializations
 Some relationship types may be participated in
only by entities that are members of the subclass.
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.
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.
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
 It is 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.
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.
 Example
Lname SSN
Addr EMPLOYEE
Fname
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
 Example

DEPARTMENT WORKS EMPLOYEE

d
 d

TypingSpeed MANAGER
TGrade EngType HOURLY_EMP

SECRETARY TECHNICIAN ENGINEER SALARIED_EMP

Entity Type: Relationship Type MANAGES BELONGS_TO

EMPLOYEE: WORKS
SECRETARY: WORKS
TECHNICIAN: WORKS PROJECT TRADE_UNION
ENGINEER: WORKS
MANAGER: WORKS, MANAGES
SALARIED_EMP: WORKS
HOURLY_EMP: WORKS, BELONGS_TO
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.
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
Diagrammatically representation of
specialization in an EER diagram
…

Esuper

Specific attributes Specific attributes

…
…
E2
E1
Example
EMPLOYEE

d
 d

MANAGER HOURLY_EMP

SECRETARY TECHNICIAN ENGINEER SALARIED_EMP

MANAGES BELONGS_TO

PROJECT TRADE_UNION
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
Generalization
 Generalization is the reverse of specialization
process. It defines a generalized entity type from
the given entity types.
Generalization (cont.)
NoOfPassengers LicensePlateNo NoOfAxles LicensePlateNo

MaxSpeed Tonnage
CAR Price TRUCK Price
VehicleID VehicleID

VehicleID Price LicensePlateNo

VEHICLE

NoOfPassengers d NoOfAxles

MaxSpeed
CAR TRUCK Tonnage
Generalization (cont.)
 We can view {CAR, TRUCK} as a specialization of
VEHICLE
 Alternatively, we can view VEHICLE as a
generalization of CAR and TRUCK
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.
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.
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.