DBMS BCS403

Module 1
Compiled by Dr. Sandhya N

Introduction to Databases: Introduction, Characteristics of database

approach,
Advantages of using the DBMS approach, History of database applications.
Overview of Database Languages and Architectures: Data Models, Schemas,
and Instances. Three schema architecture and data independence, database
languages, and interfaces, The Database System environment.
Conceptual Data Modelling using Entities and Relationships: Entity types,
Entity sets,
attributes, roles, and structural constraints, Weak entity types, ER
diagrams,examples, Specialization and Generalization.

Textbook 1:Ch 1.1 to 1.8, 2.1 to 2.6, 3.1 to 3.10

 Types of Databases and Database
Applications

Traditional database applications - to store and

access Numeric and Textual Databases.
Multimedia Databases - to store images, audio clips
and video streams digitally.
Geographic Information Systems (GIS) - to store
and analyze maps, weather data and satellite images.
Data Warehouses and online analytical
processing - to extract and analyze useful information
from very large databases to support decision making.
Real-time and Active Databases - to control
industrial and manufacturing processes.
 Basic Definitions
 Database: A collection of related data.
 Data: Known facts that can be recorded and
have an implicit meaning.
 Mini-world: Some part of the real world
about which data is stored in a database. For
example, student grades and transcripts at a
university.
 Database Management System (DBMS): A
software package/ system to facilitate the
creation and maintenance of a computerized
database.
 Database System: The DBMS software
together with the data itself. Sometimes, the
 Typical DBMS Functionality
Defining a database: involves the data types,
structures and constraints of data to be stored in the database.
Construct the Database: is a process of storing the
data on some storage medium that is controlled by DBMS.
Manipulating the database: includes querying,
generating reports, insertions, deletions and modifications to
its content.
Sharing: a set of users and programs to access the
database simultaneously yet, valid and consistent.
Application program: accesses the database by
sending queries or requests for data to the DBMS.
Query: causes some data to be retrieved.
Transaction: data to be read and written into the
database.
 Typical DBMS
Functionality
Other features:

Protection: involves system protection against

hardware or software malfunction.
Maintain: allows to evolve as requirements change
over time.
A simplified database system environment

Users/Programmers

Databas
e Application
System Programs/Queries

DBMS
Softwa Software to
re process
Queries/Program
s
Software to
Access Stored
Data

Stored
Stored
Database
Database
Definition
(Meta-Data)
 Example of a Database
(with a Conceptual Data Model)
Mini-world for the example: Part of a
UNIVERSITY environment.
Some mini-world entities:
STUDENT - data on each student
COURSE - data on each course
SECTION - data on each section of a course
GRADE_REPORT - grades that students
receive in the various sections they have
completed
PREREQUISITE - the prerequisites of each
course.
STUDENT
Name Student_nu Class Major
mber
Smith 17 1 CS
Brown 8 2 CS
COURSE
Course_Name Course_num Credit_hour Departm
ber s ent
Introduction CS13 4 CS
Data CS33 4 CS
Structures
Discrete MAT24 3 MAT
Mathematics
Database CS38 3 CS
SECTION
Section_identi Course_numb Semes Yea Instruct
fier er ter r or
85 MAT24 Fall 04 King
92 CS13 Fall 04 Anderso
n
102 CS33 Spring 05 Knuth
112 MAT24 Fall 05 Chang
119 CS13 Fall 05 Anderso
n
GRADE_REPO
135
RT CS38
Student_num Section_identi Fall
Grade 05 Stone
ber fier
17 112 B
17 119 C
8 85 A
8 92 A
8 102 B
8 135 A
PREREQUISIT
E

Course_num Prerequisite_nu
ber mber
CS38 CS33
CS38 MAT24
CS33 CS13

Database manipulation involves querying and updating.

Ex:
 Retrieve the list of all courses and grades of ‘smith’.
List the names of students who took the section of the ‘database’
course offered in fall 2005.
List the prerequisites of the ‘database’ course.
Ex. for updates:
Change the class of ‘smith’
Create a new section for the ‘Database’ course
Enter a grade
 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, and

data Abstraction : Called program-data
independence. Allows changing data storage
structures and operations 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.
Support of multiple views of the data: Each
user may see a different view of the database,
which describes only the data of interest to that
user.

Sharing of data and multiuser transaction

processing : allowing a set of concurrent users to
retrieve and to update the database. 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.
 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”).
 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): Analysts determine the requirement of end users,
especially naïve and parametric end users, and develop
specifications for canned transactions. Programmers implement
these specifications as programs, then test, debug, document
and maintain.
 Categories of End-users
 Casual : access database occasionally when needed.
 Naïve 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.
 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.
Workers behind the scene
DBMS system designers and
implementers: design and implement the
DBMS modules and interfaces as a software
package.

Tool developers: design and implement

tools.

Operators and maintenance personnel:

responsible for the actual running and
maintenance of the hardware and software
environment for the database system.
 Advantages of Using the
Database Approach
Controlling redundancy
Restricting unauthorized access.
Providing persistent storage for program Objects
Providing Storage Structures for efficient Query
Processing
Providing backup and recovery.
Providing multiple user interfaces.
Representing complex relationships among data.
Enforcing integrity constraints.
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.
 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.
 A Brief History of Database
Applications
 Early Database Applications Using
Hierarchical and Network Systems: 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.

 Providing Application Flexibility with

Relational Databases: 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.
 A Brief History of Database
Applications
 Object-oriented applications and the need for
more complex databases: 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.

 Interchanging Data on the Web for E-

commerce: 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).
 A Brief History of Database
Applications
Extending Database Capabilities for New
Applications:
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.
 A Brief History of Database
Applications
Databases versus information
retrieval:
 IR is concerned with searching for material
based on these keywords, and with the many
problems dealing with document processing
and free-form text processing.
 Retrieval of information on the web is a new
problem that requires techniques from
databases and IR to be applied in a variety of
novel combinations.
 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
 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.)
Ex. Concepts: entities, attributes, and relationships, Object
data model group(ODMG).
 Physical (low-level, internal) data models: Provide
concepts that describe details of how data is stored in the
computer.
Ex. Information: record formats, record orderings, and
access paths.
 Implementation (representational) data models:
Provide concepts that fall between the above two,
balancing user views with some computer storage details.
Ex. models: relational data model, network and heirarchical
datamodel
 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 Instance: The actual data stored in
a database at a particular moment in time.
Also called database state (or occurrence).
• Database State: Refers to the content of a
database at a moment in time.
• Initial Database State: Refers to the
database when it is loaded
• Valid State: A state that satisfies the
structure and constraints of the database.
• Database state vs Schema
• 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.
Three-Schema
Architecture
 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.
 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
• 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.
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 and
Interfaces
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.
 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).
 High Level or Non-procedural
Languages: e.g., SQL, are set-oriented
and specify what data to retrieve than how
to retrieve. Also called declarative
languages also called set-at-a-time.
 Low Level or Procedural Languages:
record-at-a-time; they specify how to
retrieve data and include constructs such
as looping also called record-at-a-time.
 DBMS Interfaces
User-friendly interfaces:
• Menu-based interfaces: popular for browsing on the
web
• Forms-based interfaces: designed for naïve users
• Graphics-based interfaces: Point and Click, Drag and
Drop etc.
• Natural language: requests in written English
• Speech Input and Output
• 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
 The Database system
Environment
Component modules of a DBMS and their interactions
DBMS Component Modules
 A DBMS is a complex software system

 The figure showed in previous slide is divide

into two halves.
 The top half refers to the various users of the
database system
 The lower half shows the internals of the DBMS
responsible for storage of data and processing
of transactions
 Database System Utilities
• To perform certain functions such as:
• Loading data stored in files into a database.
Includes data conversion tools.
• Backing up the database periodically on tape.
• Reorganizing database file structures.
• Report generation utilities.
• Performance monitoring utilities.
• Other functions, such as sorting, user
monitoring, data compression, etc.
Tools, Application Environments,
and communications Facilities
• Data dictionary / repository:
• Used to store schema descriptions and other
information such as design decisions, application
program descriptions, user information, usage
standards, etc.
• Active data dictionary is accessed by DBMS software
and users/DBA.
• Passive data dictionary is accessed by users/DBA
only.
• Application Development Environments
and CASE (computer-aided software
engineering) tools:
• Examples – Power builder (Sybase), Builder
(Borland)
DBMS also needs to interface with
 Centralized and Client-Server
Architectures
Centralized DBMS: combines everything
into single system including- DBMS
software, hardware, application programs
and user interface processing software.
Basic Client-Server Architectures
• Specialized Servers with Specialized
functions
• File Servers
• Printer Servers
• Web Servers
• E-mail Servers

• Clients
• DBMS Server
Clients
• Provide appropriate interfaces and a client-version of
the system to access and utilize the server resources.
• Clients maybe diskless machines or PCs or
Workstations with disks with only the client software
installed.
• Connected to the servers via some form of a
network.
(LAN: local area network, wireless network, etc.)

DBMS SERVERS
• Provides database query and transaction services to
the clients
• Sometimes called query and transaction servers
Two Tier Client-Server Architecture
• User Interface Programs and Application
Programs run on the client side
• Interface called ODBC (Open Database
Connectivity) provides an Application program
interface (API) allow client side programs to call
the DBMS. Most DBMS vendors provide ODBC
drivers.
• A client program may connect to several DBMSs.
• Other variations of clients are possible: e.g., in some
DBMSs, more functionality is transferred to clients
including data dictionary functions, optimization and
recovery across multiple servers, etc. In such
situations the server may be called the Data Server.
This is called two-tier architectures because the software
components are distributed over two systems: client and
server
 Three Tier Client-Server
Architecture
• The emergence of the Web changed the roles
of client and server, leading to the three-tier
architecture. Common for Web applications
• Intermediate Layer called Application Server
or Web Server:
• stores the web connectivity software and the rules
and business logic (constraints) part of the
application used to access the right amount of data
from the database server
• acts like a conduit for sending partially processed data
between the database server and the client.
• Additional Features- Security:
• encrypt the data at the server before transmission
• decrypt data at the client
Classification of DBMSs
1.Based on the data model used:
Traditional: Relational, Network, Hierarchical.
Emerging: Object-oriented, Object-relational,
XML model.
2. Based on number of users: Single-user
(typically used with micro- computers) vs.
multi-user (most DBMSs).
3.Based on number of sites: Centralized
(uses a single computer with one database)
vs. distributed (uses multiple computers,
multiple databases)
 Distributed Database Systems have now come to
be known as client server based database systems
because they do not support a totally distributed
environment, but rather a set of database servers
supporting a set of clients.
Homogeneous DDBMS- use same DBMS S/W at
multiple sites.
Heterogeneous DDBMS- use different DBMS S/W at
multiple sites.
Federated or Multi database Systems –
participating DBMS are loosely coupled.
4. Based on cost: ranges from free to several dollars.
5. Types of access paths- options for storing files.
6. General purpose and special purpose
ENTITY-RELATIONSHIP MODEL

Chapter 3
 ER Diagrams
Popular high level data model.
Used for design of database applications.

The object modeling methodologies such

as universal modeling language (UML) are
used for detailed design of database using
class diagrams similar to ER diagrams.
 A simplified diagram to illustrate
the main phases of database design
miniwor
ld
Requirements
collection and
Functional analysis
Data
Requirements
Functional Analysis Requirements
Conceptual
Design
Conceptual Schema
High-level Transaction
Specification (In a high-level data
DBMS- model)
Logical Design
Independent (data model
DBMS-specific
mapping
Logical(conceptual)
Application Program schema (In the data model
Design of a specific DBMS)
Physical design
Transaction Internal Schema
Implementation
Application
 Requirements collection and analysis: The database
designers interview prospective database users to understand
and document their data requirements. By writing set of user’s
requirements.
 Functional requirements: consists of user-defined
operations that will be applied to the database.
 Conceptual design: concise description of the data
requirements of the users and includes detailed descriptions
of the entity type, relationships and constraints. It does not
include implementation details, usually used to communicate
with the non-technical users.
 Logical design: transforms the high-level data model into
implementation data model(database schema).
 Physical design: the internal storage structures, indexes,
access paths, and file organizations for the database files are
specified.
 In parallel with these activities, application programs are
designed and implemented as database transactions
corresponding to the high-level transaction specifications.
 Example COMPANY
Database
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.
Each department controls a number of
PROJECTs. Each project has a name,
number and is located at a single location.
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 employee.
 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 a Name, SSN,
Address, Sex, BirthDate
 A specific entity will have a value for each of its attributes.
For example a specific employee entity may have Name='John
Smith', SSN='123456789', Address ='731, Fondren,
Houston, TX', Sex='M', BirthDate='09-JAN-55‘
 Each attribute has a value set (or data type) associated
with it.
e.g. integer, string, subrange, enumerated type, …
 Types of Attributes
 Simple
Each entity has a single atomic value for the
attribute.
For example, SSN or USN.
 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
Stored and derived attributes
Any two attributes which are related for ex: age and
date of birth are related. Where age can be derived
from DOB. Age is derived attribute and DOB is the
stored attribute.
NULL values
Entity may not have an applicable value. For ex:
college degrees may not be applicable to all.
Complex attributes:
Composite and multi-valued attributes may be nested
arbitrarily to any number of levels although this is rare.It
is said to be complex attribute. For example,
PreviousDegrees of a STUDENT is a composite multi-
valued attribute denoted by {PreviousDegrees (College,
Year, Degree, Field)}.
 Entity Types and Key
Attributes
 Entities with the same basic attributes are grouped or
typed into an entity type. For example, the EMPLOYEE
entity type or the PROJECT entity type.
 Entity set is the collection of a particular entity type.
 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.
 A key attribute may be composite. For example,
VehicleTagNumber is a key of the CAR entity type with
components (Number, State).
 An entity type may have more than one key. For
example, the CAR entity type may have two keys:
 VehicleIdentificationNumber (popularly called VIN) and
 VehicleTagNumber (Number, State), also known as
license_plate number.
 ENTITY SET corresponding to the
ENTITY TYPE CAR
CAR
ation(RegistrationNumber, State), VehicleID, Make, Model, Year, (Colo

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))
.
.
.
 Relationship sets, Relationship
Types and instances
 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.
 The relationship set R is a set of relationship instances ri
, where each ri associates n individual entities(e1,e2,e3..en)
 More than one relationship type can exist with
the same participating entity types. For
example, MANAGES and WORKS_FOR are
distinct relationships between EMPLOYEE and
DEPARTMENT, but with different meanings and
different relationship instances.
 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
Example relationship instances of the WORKS_FOR
relationship between EMPLOYEE and DEPARTMENT
EMPLOYEE WORKS_FOR DEPARTMENT

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

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

r7
 Recursive relationships and role

names
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.
 We can also have a recursive relationship
type.Both participations are same entity type in
different roles.
 For example, SUPERVISION relationships between
EMPLOYEE (in role of supervisor or boss) and
(another) EMPLOYEE (in role of subordinate or
worker).
 In ER diagram, need to display role names to
distinguish participations.
 A RECURSIVE RELATIONSHIP
SUPERVISION
EMPLOYEE SUPERVISION

e1 
2
e2 1 r1

2
e3 1 r2

2
e4  1 r3
e5 2

1
1 r4
e6 
2
e7 1 r5


2
r6
Attributes of Relationship
types

A relationship type can have

attributes; for example, HoursPerWeek
of WORKS_ON; its value for each
relationship instance describes the
number of hours per week that an
EMPLOYEE works on a PROJECT.
 Constraints on Relationships
Constraints on Relationship Types
( Also known as ratio constraints )
 Maximum Cardinality
 One-to-one (1:1)
 One-to-many (1:N) or Many-to-one (N:1)
 Many-to-many
Minimum Cardinality (also called
participation constraint or existence
dependency constraints)
• Total participation
• Partial participation
 Structural Constraints –one way to
express semantics of relationships

Structural constraints on relationships:

 Cardinality ratio (of a binary relationship):
1:1, 1:N, N:1, or M:N
SHOWN BY PLACING APPROPRIATE NUMBER ON
THE LINK.
 Participation constraint (on each
participating entity type): total (called
existence dependency) or partial.
SHOWN BY DOUBLE LINING THE LINK
NOTE: These are easy to specify for Binary
Ch
Relationship Types.
apt
er
3-
 Alternative (min, max) notation for
relationship structural constraints:
 Specified on each participation of an entity type E in a
relationship type R
 Specifies that each entity e in E participates in at least min

and at most max relationship instances in R

 Default(no constraint): min=0, max=n
 Must have minmax, min0, max 1
 Derived from the knowledge of mini-world constraints

Examples:
 A department has exactly one manager and an employee can

manage at most one department.

 Specify (0,1) for participation of EMPLOYEE in MANAGES

 Specify (1,1) for participation of DEPARTMENT in MANAGES

 An employee can work for exactly one department but a

department can have any number of employees.

 Specify (1,1) for participation of EMPLOYEE in WORKS_FOR

 Specify (0,n) for participation of DEPARTMENT in

Many-to-one (N:1) RELATIONSHIP
EMPLOYEE WORKS_FOR DEPARTMENT

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

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

r7
Many-to-many (M:N) RELATIONSHIP

r9

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

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

r
r8 7
 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:
Suppose that a DEPENDENT entity is identified by
the dependent’s first name and birthdate, 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
SUMMARY OF ER-DIAGRAM NOTATION FOR ER SCHEMAS
Symbol Meaning
Entity
Weak Entity
Relationship
Identfying relationship

Attribute
Key Attribute
Multi-valued attribute
Composite Attribute
Derived Attribute

E1 E2 Total Participation of E2
inR
1
E1 N E2
Cardinality Ratio 1:N
for E1:E2 in R
(min,ma
R E
Structural constraint
x)
The (min,max) notation
relationship constraints
(0,1) (1,1)

(1,1) (1,N)
ER DIAGRAM – Relationship Types are: WORKS_FOR,
MANAGES, WORKS_ON, CONTROLS, SUPERVISION,
DEPENDENTS_OF
COMPANY ER Schema Diagram
using (min, max) notation
 Specialization

Specialization is the process of defining a set of subclasses of an entity

type; this entity type is called the superclass of the specialization. The
set of subclasses that forms a specialization is defined on the basis of
some distinguishing characteristic of the entities in the superclass. For
example, the set of subclasses {SECRETARY,ENGINEER, TECHNICIAN} is
a specialization of the superclass EMPLOYEE that distinguishes among
employee entities based on the job type of each employee entity.
The specialization process allows us to do the following:
■ Define a set of subclasses 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

A reverse process of abstraction in which

we suppress the differences among
several entity types, identify their
common features, and generalize them
into a single superclass of which the
original entity types are special
subclasses.
Constraints on Specialization and Generalization
In some specializations we can determine exactly the entities
that will become members of each subclass by placing a
condition on the value of some attribute of the superclass. Such
subclasses are called predicate-defined (or condition-
defined) subclasses

If all subclasses in a specialization have their membership

condition on the same attribute of the superclass, the
specialization itself is called an attribute-defined
specialization, and the attribute is called the defining
attribute of the specialization.
END