Module 1 -DBMS

Copyright © 2016 Ramez Elmasri and Shamkant B.
Navathe
CHAPTER 1
Databases and Database Users
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 2

OUTLINE
 Types of Databases and Database Applications
 Basic Definitions
 Typical DBMS Functionality
 Example of a Database (UNIVERSITY)
 Main Characteristics of the Database Approach
 Types of Database Users
 Advantages of Using the Database Approach
 Historical Development of Database
Technology
 Extending Database Capabilities
 When Not to Use Databases
What is data, database,
DBMS
 Data: Known facts that can be recorded and have an implicit
meaning; raw
 Database: a highly organized, interrelated, and structured set of
data about a particular enterprise
 Controlled by a database management system (DBMS)
 DBMS
 Set of programs to access the data
 An environment that is both convenient and efficient to use
 Database systems are used to manage collections of data that
are:
 Highly valuable
 Relatively large
 Accessed by multiple users and applications, often at the
same time.
 A modern database system is a complex software system whose
task is to manage a large, complex collection of data.
 Databases touch all aspects of our lives
Types of Databases and
Database Applications
 Traditional applications:
 Numeric and textual databases
 More recent applications:
 Multimedia databases
 Geographic Information Systems (GIS)
 Biological and genome databases
 Data warehouses
 Mobile databases
 Real-time and active databases

Recent Developments (1)
 Social Networks started capturing a lot of
information about people and about
communications among people-posts,
tweets, photos, videos in systems such as:
- Facebook
- Twitter
- Linked-In
 All of the above constitutes data
 Search Engines, Google, Bing, Yahoo:
collect their own repository of web pages
for searching purposes
Recent Developments (2)
 New technologies are emerging from the
so-called non-SQL, non-database software
vendors to manage vast amounts of data
generated on the web:
 Big data storage systems involving large
clusters of distributed computers
 NOSQL (Non-SQL, Not Only SQL) systems
 A large amount of data now resides on the
“cloud” which means it is in huge data
centers using thousands of machines.

What is “big data”?
 "Big data are high-volume, high-velocity, and/or high-variety
information assets that require new forms of processing to
enable enhanced decision making, insight discovery and
process optimization”
 Three Vs

3Vs (volume, variety and velocity) are three defining
properties or dimensions of big data.
 Volume refers to the amount of data,
 variety refers to the number of types of data
 velocity refers to the speed of data processing
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Why is “big data” a “big
deal”?
 Government
 Private Sector

Walmart handles more than 1 million customer
transactions every hour, which is imported into
databases estimated to contain more than 2.5
petabytes of data

Facebook handles 40 billion photos from its user base

Falcon Credit Card Fraud Detection System protects
2.1 billion active accounts world-wide
 Science

Large Synoptic Survey Telescope will generate 140
Terabyte of data every 5 days

Biomedical computation like decoding human
Genome and personalized medicine
Basic Definitions
 Database:
 A collection of related data.
 Data:
 Known facts that can be recorded and have an implicit
meaning.
 Mini-world:
 Some part of the real world about which data is stored in
a database. For example, student grades and transcripts

at a university.
 Database Management System (DBMS):
 A software package/system to facilitate the creation and
maintenance of a computerized database.

 Database system:
 The DBMS software together with the data itself.
Sometimes, the applications are also included.

Impact of Databases and
Database Technology
 Businesses: Banking, Insurance, Retail,
Transportation, Healthcare, Manufacturing
 Service industries: Financial, Real-estate,
Legal, Electronic Commerce, Small businesses
 Education : Resources for content and
Delivery
 More recently: Social Networks, Environmental
and Scientific Applications, Medicine and
Genetics
 Personalized applications: based on smart
mobile devices

A simplified architecture for a
database system
View level: what application programs see; views can also hide
information (such as an instructor’s salary) for security purposes.
Physical level: describes

how a record (e.g.,
instructor) is stored.

A simplified architecture for a
database system

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

(with a Conceptual Data
Model)
 Some mini-world relationships:
 SECTIONs are of specific COURSEs
 STUDENTs take SECTIONs
 COURSEs have prerequisite COURSEs
 INSTRUCTORs teach SECTIONs
 COURSEs are offered by DEPARTMENTs
 STUDENTs major in DEPARTMENTs
 Note: The above entities and relationships are
typically expressed in a conceptual data model,
such as the entity-relationship (ER) data or UML
class model

Example of a Simple
Database

The relational model
E.F. “Ted” Codd

Main Characteristics of the
Database Approach
 Self-describing nature of a database system:
 Insulation between programs and data, and
Data Abstraction
 Support of multiple views of the data
 Sharing of data and multi-user transaction
processing

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

Example of a Simplified
Database Catalog

Database Approach
(continued)
 Data abstraction:
 A data model is used to hide storage
details and present the users with a
conceptual view of the database.
 Programs refer to the data model constructs
rather than data storage details
 Support of multiple views of the data:
 Each user may see a different view of the
database, which describes only the data of
interest to that user.

Database Approach
(continued)

Database Approach
(continued)
 Sharing of data and multi-user transaction
processing:
 Allowing a set of concurrent users to retrieve from
and to update the database.
 Concurrency control within the DBMS guarantees
that each transaction is correctly executed or
aborted
 Recovery subsystem ensures each completed
transaction has its effect permanently recorded in
the database
 OLTP (Online Transaction Processing) is a major part
of database applications; allows hundreds of
concurrent transactions to execute per second.
Database Users
 Users may be divided into
 Those who actually use and control the
database content, and those who design,
develop and maintain database applications
(called “Actors on the Scene”), and
 Those who design and develop the DBMS
software and related tools, and the
computer systems operators (called
“Workers Behind the Scene”).

Database Users – Actors on
the Scene
 Actors on the scene

Database administrators

Responsible for authorizing access to the
database, for coordinating 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.

Database End Users
 Actors on the scene (continued)
 End-users: They use the data for queries,
reports and some of them update the database
content. End-users can be categorized into:

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.
 Users of mobile apps mostly fall in this category
 Bank-tellers or reservation clerks are parametric users
who do this activity for an entire shift of operations.
 Social media users post and read information from
websites
Database End Users
(continued)
 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 the user of a tax program that
creates its own internal database.
 Another example is a user that maintains a
database of personal photos and videos.
Database Users – Actors on
the Scene (continued)
 System analysts and application developers
 System analysts: They understand the user
requirements of naïve and sophisticated users
and design applications including canned
transactions to meet those requirements.
 Application programmers: Implement the
specifications developed by analysts and test
and debug them before deployment.
 Business analysts: There is an increasing need
for such people who can analyze vast amounts
of business data and real-time data (“Big Data”)
for better decision making related to planning,
advertising, marketing etc.  Slide 1-
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe 28
Database Users – Actors
behind the Scene
 System designers and implementors: Design
and implement DBMS packages in the form of modules
and interfaces and test and debug them. The DBMS must
interface with applications, language compilers, operating
system components, etc.
 Tool developers: Design and implement software
systems called tools for modeling and designing
databases, performance monitoring, prototyping, test
data generation, user interface creation, simulation etc.
that facilitate building of applications and allow using
database effectively.

Operators and maintenance personnel : They
manage the actual running and maintenance of the
database system hardware and software environment.

Advantages of Using the
Database Approach
 Controlling redundancy in data storage and in
development and maintenance efforts.
 Sharing of data among multiple users.
 Restricting unauthorized access to data.
Only the DBA staff uses privileged commands
and facilities.
 Providing persistent storage for program
Objects
 E.g., Object-oriented DBMSs make program
objects persistent
 Providing storage structures (e.g. indexes) for
efficient query processing.
Advantages of Using the
Database Approach
(continued)
 Providing optimization of queries for efficient
processing
 Providing backup and recovery services
 Providing multiple interfaces to different
classes of users
 Representing complex relationships among
data
 Enforcing integrity constraints on the database
 Drawing inferences and actions from the stored
data using deductive and active rules and
triggers

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

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

Historical Development of
Database Technology
 Early database applications:
 The Hierarchical and Network models were introduced
in mid 1960s and dominated during the seventies.
 A bulk of the worldwide database processing still
occurs using these models, particularly, the
hierarchical model using IBM’s IMS system.
 Relational model-based systems:
 Relational model was originally introduced in 1970,
was heavily researched and experimented within IBM
Research and several universities.
 Relational DBMS Products emerged in the early
1980s.

Database Technology
(continued)
 Object-oriented and emerging applications:
 Object-Oriented Database Management Systems
(OODBMSs) were introduced in late 1980s and early
1990s to cater to the need of complex data
processing in CAD and other applications.

Their use has not taken off much
 Many relational DBMSs have incorporated object
database concepts, leading to a new category called
object-relational DBMSs (ORDBMSs)
 Extended relational systems add further capabilities
(e.g. for multimedia data, text, XML, and other data
types)

Database Technology
(continued)
 Data on the Web and e-commerce
applications:
 Web contains data in HTML (Hypertext markup
language) with links among pages
 Has given rise to a new set of applications and
E-commerce is using new standards like XML
(eXtended Markup Language) (see Ch. 13).
 Script programming languages such as PHP
and JavaScript allow generation of dynamic
Web pages that are partially generated from a
database (see Ch. 11).

Also allow database updates through Web
pages
Extending Database
Capabilities (1)
 New functionality is being added to DBMSs in the
following areas:
 Scientific applications – physics, chemistry,
biology, genetics
 Spatial: weather, earth and atmospheric sciences
and astronomy
 XML (eXtensible Markup Language)
 Image storage and management
 Audio and video 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.
Extending Database
Capabilities (2)
 Background since the advent of the 21st Century:

First decade of the 21st century has seen
tremendous growth in user generated data and
automatically collected data from applications
and search engines.

Social Media platforms such as Facebook and
Twitter are generating millions of transactions a
day and businesses are interested to tap into
this data to “understand” the users

Cloud Storage and Backup is making unlimited
amount of storage available to users and
applications
Extending Database
Capabilities (3)
 Emergence of Big Data Technologies and NOSQL databases

New data storage, management and analysis technology
was necessary to deal with the onslaught of data in
petabytes a day (10**15 bytes or 1000 terabytes) in
some applications – this started being commonly called as
“Big Data”.

Hadoop (which originated from Yahoo) and Mapreduce
Programming approach to distributed data processing
(which originated from Google) as well as the Google file
system have given rise to Big Data technologies (Chapter
25). Further enhancements are taking place in the form of
Spark based technology.

NOSQL (Not Only SQL- where SQL is the de facto standard
language for relational DBMSs) systems have been
designed for rapid search and retrieval from documents,
processing of huge graphs occurring on social networks,
and other forms of unstructured data with flexible models
of transaction processing (Chapter 24).

Extending Database
Capabilities (4)
 The following are some examples of these applications:
 Scientific applications that store large amounts of data
resulting from scientific experiments in areas such as high-
energy physics, the mapping of the human genome, and the
discovery of protein structures.
 Storage and retrieval of images, including scanned news or
personal photographs, satellite photographic images, and
images from medical procedures such as x-rays and MRIs
(magnetic resonance imaging).
 Storage and retrieval of videos, such as movies, and video
clips from news or personal digital cameras.

Extending Database
Capabilities (5)
 Data mining applications that analyze large amounts of
data searching for the occurrences of specific patterns or
relationships, and for identifying unusual patterns in areas
such as credit card usage.
 Spatial applications that store spatial locations of data, such
as weather information, maps used in geographical
information systems, and in automobile navigational
systems.
 Time series applications that store information such as
economic data at regular points in time, such as daily sales
and monthly gross national product figures.
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 access to data by multiple users is not required
 When a DBMS may be infeasible
 In embedded systems where a general-purpose
DBMS may not fit in available storage

When not to use a DBMS
 When no DBMS may suffice:
 If there are stringent real-time requirements
that may not be met because of DBMS

overhead (e.g., telephone switching systems)
 If the database system is not able to handle the
complexity of data because of modeling
limitations (e.g., in complex genome and protein
databases)
 If the database users need special operations not
supported by the DBMS (e.g., GIS and location-
based services).

Chapter Summary
 Types of databases and database applications
 Basic definitions
 Typical DBMS functionality
 Example of a database (UNIVERSITY)
 Main characteristics of the database Approach
 Types of database users
 Advantages of using the database approach
 Historical development of database technology
 Extending database capabilities
 When not to use databases

CHAPTER 2
Database System Concepts

and Architecture

Outline
 Data Models and Their Categories
 History of Data Models
 Schemas, Instances, and States
 Three-Schema Architecture
 Data Independence
 DBMS Languages and Interfaces
 Database System Utilities and Tools
 Centralized and Client-Server Architectures
 Classification of DBMSs

Data Models
 Data Model:
 A set of concepts to describe the structure of a
database, the operations for manipulating these
structures, and certain constraints that the
database should obey.
 Data Model Structure and Constraints:
 Constructs are used to define the database structure
 Constructs typically include elements (and their
data types) as well as groups of elements (e.g.
entity, record, table), and relationships among
such groups
 Constraints specify some restrictions on valid data;
these constraints must be enforced at all times
Data Models (continued)
 Data Model Operations:
 These operations are used for specifying
database retrievals and updates by referring
to the constructs of the data model.
 Operations on the data model may include
basic model operations (e.g. generic
insert, delete, update) and user-defined
operations (e.g. compute_student_gpa,
update_inventory)

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

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

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

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

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

 State is also called extension.

Schema

Example of a database state

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

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

The three-schema
architecture

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

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

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

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

DBMS Languages
 Data Definition Language (DDL):
 Used by the DBA and database designers to
specify the conceptual schema of a database.
 In many DBMSs, the DDL is also used to define
internal and external schemas (views).
 In some DBMSs, separate storage definition
language (SDL) and view definition
language (VDL) are used to define internal
and external schemas.

SDL is typically realized via DBMS commands
provided to the DBA and database designers

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

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

DBMS Interfaces
 Stand-alone query language interfaces
 Example: Entering SQL queries at the DBMS
interactive SQL interface (e.g. SQL*Plus in
ORACLE)
 Programmer interfaces for embedding DML
in programming languages
 User-friendly interfaces
 Menu-based, forms-based, graphics-based,
etc.
 Mobile Interfaces:interfaces allowing users
to perform transactions using mobile apps
DBMS Programming Language
Interfaces
 Programmer interfaces for embedding DML
in a programming languages:

Embedded Approach: e.g embedded SQL (for C, C++,
etc.), SQLJ (for Java)

Procedure Call Approach: e.g. JDBC for Java, ODBC
(Open Databse Connectivity) for other programming
languages as API’s (application programming interfaces)

Database Programming Language Approach: e.g.
ORACLE has PL/SQL, a programming language based on
SQL; language incorporates SQL and its data types as
integral components

Scripting Languages: PHP (client-side scripting) and
Python (server-side scripting) are used to write database
programs.

User-Friendly DBMS
Interfaces
 Menu-based (Web-based), popular for browsing
on the web
 Forms-based, designed for naïve users used to
filling in entries on a form
 Graphics-based

Point and Click, Drag and Drop, etc.

Specifying a query on a schema diagram
 Natural language: requests in written English
 Combinations of the above:

For example, both menus and forms used
extensively in Web database interfaces

Other DBMS Interfaces
 Natural language: free text as a query
 Speech : Input query and Output response
 Web Browser with keyword search
 Parametric interfaces, e.g., bank tellers
using function keys.
 Interfaces for the DBA:

Creating user accounts, granting
authorizations

Setting system parameters

Changing schemas or access paths

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.
 Performance monitoring utilities.
 Report generation utilities.
 Other functions, such as sorting, user
monitoring, data compression, etc.

Other Tools
 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.

Other Tools
 Application Development Environments and
CASE (computer-aided software
engineering) tools:
 Examples:
 PowerBuilder (Sybase)
 JBuilder (Borland)
 JDeveloper 10G (Oracle)

Typical DBMS Component
Modules

Centralized and
Client-Server DBMS
Architectures
 Centralized DBMS:
 Combines everything into single system
including- DBMS software, hardware,
application programs, and user interface
processing software.
 User can still connect through a remote
terminal – however, all processing is done at
centralized site.

A Physical Centralized
Architecture

Basic 2-tier Client-Server
Architectures
 Specialized Servers with Specialized
functions
 Print server
 File server
 DBMS server
 Web server
 Email server
 Clients can access the specialized servers
as needed

Logical two-tier client server
architecture

Clients
 Provide appropriate interfaces through a
client software module to access and utilize
the various server resources.
 Clients may be 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 Server
 Provides database query and transaction services
to the clients
 Relational DBMS servers are often called SQL
servers, query servers, or transaction servers
 Applications running on clients utilize an
Application Program Interface (API) to access
server databases via standard interface such as:
 ODBC: Open Database Connectivity standard
 JDBC: for Java programming access

Two Tier Client-Server
Architecture
 Client and server must install appropriate
client module and server module software
for ODBC or JDBC
 A client program may connect to several
DBMSs, sometimes called the data sources.
 In general, data sources can be files or
other non-DBMS software that manages
data.
 See Chapter 10 for details on Database
Programming

Three Tier Client-Server
Architecture
 Common for Web applications
 Intermediate Layer called Application Server or Web
Server:
 Stores the web connectivity software and the business
logic part of the application used to access the
corresponding data from the database server
 Acts like a conduit for sending partially processed data
between the database server and the client.
 Three-tier Architecture Can Enhance Security:
 Database server only accessible via middle tier
 Clients cannot directly access database server
 Clients contain user interfaces and Web browsers
 The client is typically a PC or a mobile device connected
to the Web

Three-tier client-server
architecture

Classification of DBMSs
 Based on the data model used
 Legacy: Network, Hierarchical.
 Currently Used: Relational, Object-oriented, Object-
relational
 Recent Technologies: Key-value storage systems,
NOSQL systems: document based, column-based,
graph-based and key-value based. Native XML DBMSs.
 Other classifications
 Single-user (typically used with personal computers)
vs. multi-user (most DBMSs).
 Centralized (uses a single computer with one database)
vs. distributed (multiple computers, multiple DBs)

Variations of Distributed
DBMSs (DDBMSs)
 Homogeneous DDBMS
 Heterogeneous DDBMS
 Federated or Multidatabase Systems
 Participating Databases are loosely coupled
with high degree of autonomy.
 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.

Cost considerations for
DBMSs
 Cost Range: from free open-source systems to
configurations costing millions of dollars
 Examples of free relational DBMSs: MySQL,
PostgreSQL, others
 Commercial DBMS offer additional specialized
modules, e.g. time-series module, spatial data
module, document module, XML module
 These offer additional specialized functionality when
purchased separately
 Sometimes called cartridges (e.g., in Oracle) or blades
 Different licensing options: site license, maximum
number of concurrent users (seat license), single
user, etc.

Other Considerations
 Type of access paths within database
system
 E.g.- inverted indexing based (ADABAS is
one such system).Fully indexed databases
provide access by any keyword (used in
search engines)
 General Purpose vs. Special Purpose
 E.g.- Airline Reservation systems or many
others-reservation systems for hotel/car etc.
Are special purpose OLTP (Online
Transaction Processing Systems)
History of Data Models
(Additional Material)
 Network Model
 Hierarchical Model
 Relational Model
 Object-oriented Data Models
 Object-Relational Models

Chapter Summary
 Data Models and Their Categories
 Schemas, Instances, and States
 Three-Schema Architecture
 Data Independence
 DBMS Languages and Interfaces
 Database System Utilities and Tools
 Database System Environment
 Centralized and Client-Server Architectures
 Classification of DBMSs
 History of Data Models

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

Chapter Outline
 Overview of Database Design Process
 Example Database Application (COMPANY)
 ER Model Concepts
 Entities and Attributes
 Entity Types, Value Sets, and Key Attributes
 Relationships and Relationship Types
 Weak Entity Types
 Roles and Attributes in Relationship Types
 ER Diagrams - Notation
 ER Diagram for COMPANY Schema
 Alternative Notations – UML class diagrams, others

Overview of Database Design
Process
 Two main activities:
 Database design
 Applications design
 Focus in this chapter on database design
 To design the conceptual schema for a
database application
 Applications design focuses on the programs
and interfaces that access the database
 Generally considered part of software
engineering

Overview of Database Design
Process

Example COMPANY Database
 We need to create a database schema
design based on the following (simplified)
requirements of the COMPANY Database:
 The company is organized into
DEPARTMENTs. Each department has a name,
number and an employee who manages the
department. We keep track of the start date
of the department manager. A department
may have several locations.
 Each department controls a number of
PROJECTs. Each project has a unique name,
unique number and is located at a single
location.
Example COMPANY Database
(Contd.)
 We store each EMPLOYEE’s social security
number, address, salary, sex, and birthdate.

Each employee works for one department but
may work on several projects.

We keep track of the number of hours per week
that an employee currently works on each
project.

We also keep track of the direct supervisor of
each employee.
 Each employee may have a number of
DEPENDENTs.

For each dependent, we keep track of their name,
sex, birthdate, and relationship to the employee.

ER Diagram

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

Entities and their Attributes

Types of Attributes (1)
 Simple(Atomic)

Each entity has a single atomic value for the attribute.
For example, SSN or Sex.
 Composite

The attribute may be composed of several
components. For example:

Address(Apt#, House#, Street, City, State, ZipCode,
Country), or

Name(FirstName, MiddleName, LastName).

Composition may form a hierarchy where some
components are themselves composite.

 Single-valued
 Most attributes have a single value for a particular entity;
such attributes are called single-valued. For example,
 Age is a single-valued attribute of a person.
 Multi-valued
 An entity may have multiple values for that attribute.
For example, Color of a CAR or PreviousDegrees of a
STUDENT.

Denoted as {Color} or {PreviousDegrees}.

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

Example of a composite
attribute

Stored versus Derived Attributes.
In some cases, two (or more) attribute values are related—for
example, the Age and Birth_date attributes of a person.

 For a particular person entity, the value of Age can be determined
from the current (today’s) date and the value of that person’s
Birth_date.
 The Age attribute is hence called a derived attribute and is said to be
derivable from the Birth_date attribute, which is called a stored attribute.
 Some attribute values can be derived from related entities; for example, an
attribute Number_of_employees of a DEPARTMENT entity can be derived by
counting the number of employees related to (working for) that department.
NULL Values
•In some cases, a particular entity may not have an applicable value
for an attribute.
• For example, the Apartment_number attribute of an address applies only to
addresses that are in apartment buildings and not to other types of
residences, such as single-family homes.
•A College_degrees attribute applies only to people with college degrees.
For such situations, a special value called NULL is created.
• An address of a single-family home would have NULL for its
Apartment_number attribute, and a person with no college degree would
have NULL for College_degrees.
NULL Values
•The unknown category of NULL can be further classified into two cases.
• The first case arises when it is known that the attribute value exists but is
missing—for instance, if the Height attribute of a person is listed as NULL.
•The second case arises when it is not known whether the attribute value
exists—for example, if the Home_phone attribute of a person is NULL.

Complex Attributes
• composite and multivalued attributes can be nested arbitrarily. We can
represent arbitrary nesting by grouping components of a composite attribute
between parentheses () and separating the components with commas, and
by displaying multivalued attributes between braces { }. Such attributes are
called complex attributes.
•For example, if a person can have more than one residence and each
residence can have a single address and multiple phones, an attribute
Address_phone for a person can be specified as shown in Figure .Both
Phone and Address are themselves composite attributes .

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

Entity Types and Key
Attributes (2)
 A key attribute may be composite.

VehicleTagNumber is a key of the CAR entity
type with components (Number, State).
 An entity type may have more than one key.

The CAR entity type may have two keys:

VehicleIdentificationNumber (popularly called VIN)

VehicleTagNumber (Number, State), license plate
number.
 Each key is underlined

Entity Types

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

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

Initial Design of Entity Types
for the COMPANY Database
Schema
 Based on the requirements, we can identify
four initial entity types in the COMPANY
database:

DEPARTMENT

PROJECT

EMPLOYEE

DEPENDENT
 Their initial design is shown on the following
slide
 The initial attributes shown are derived from
the requirements description
Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Refining the initial design by
introducing relationships
 The initial design is typically not complete
 Some aspects in the requirements will be
represented as relationships
 ER model has three main concepts:
 Entities (and their entity types and entity
sets)
 Attributes (simple, composite, multivalued)
 Relationships (and their relationship types
and relationship sets)
 We introduce relationship concepts next
Relationships and Relationship
Types (1)
 A relationship relates two or more distinct
entities with a specific meaning.

For example, EMPLOYEE John Smith works on the
ProductX PROJECT, or EMPLOYEE Franklin Wong
manages the Research DEPARTMENT.
 Relationships of the same type are grouped or
typed into a relationship type.

For example, the WORKS_ON relationship type in which
EMPLOYEEs and PROJECTs participate, or the MANAGES
relationship type in which EMPLOYEEs and
DEPARTMENTs participate.
 The degree of a relationship type is the number of
participating entity types.

Both MANAGES and WORKS_ON are binary
relationships.

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

Relationship Degree, Role names, Recursive
relationship
Degree of a Relationship Type -The degree of a relationship type is

the number of participating entity types. Hence, the WORKS_FOR
relationship is of degree two.
A relationship type of degree two is called binary, and one of degree
three is called ternary.
An example of a ternary relationship is

SUPPLY, shown in Figure 7.10,
where each relationship instance ri associates
three entities—a supplier s, a part p,
and a project j—whenever s supplies part p to
project j.
Relationship AS Attributes

Role name and recursive relationship

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

Cardinality ratio of binary relationship

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

Relationship type vs.
relationship set (2)
 Previous figures displayed the relationship
sets
 Each instance in the set relates individual
participating entities – one from each
participating entity type
 In ER diagrams, we represent the relationship
type as follows:

Diamond-shaped box is used to display a
relationship type

Connected to the participating entity types via
straight lines
Refining the COMPANY database
schema by introducing
relationships
 By examining the requirements, six relationship
types are identified
 All are binary relationships( degree 2)
 Listed below with their participating entity types:
 WORKS_FOR (between EMPLOYEE, DEPARTMENT)
 MANAGES (also between EMPLOYEE, DEPARTMENT)
 CONTROLS (between DEPARTMENT, PROJECT)
 WORKS_ON (between EMPLOYEE, PROJECT)
 SUPERVISION (between EMPLOYEE (as subordinate),
EMPLOYEE (as supervisor))
 DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)

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

Discussion on Relationship
Types
 In the refined design, some attributes from the
initial entity types are refined into relationships:
 Manager of DEPARTMENT -> MANAGES
 Works_on of EMPLOYEE -> WORKS_ON
 Department of EMPLOYEE -> WORKS_FOR
 etc
 In general, more than one relationship type can
exist between the same participating entity types
 MANAGES and WORKS_FOR are distinct relationship
types between EMPLOYEE and DEPARTMENT
 Different meanings and different relationship
instances.
Recursive Relationship Type
 An relationship type whose with the same
participating entity type in distinct roles
 Example: the SUPERVISION relationship
 EMPLOYEE participates twice in two distinct roles:
 supervisor (or boss) role
 supervisee (or subordinate) role
 Each relationship instance relates two distinct
EMPLOYEE entities:
 One employee in supervisor role
 One employee in supervisee role

Weak Entity Types
 An entity that does not have a key attribute
 A weak entity must participate in an identifying relationship
type with an owner or identifying entity type
 Entities are identified by the combination of:
 A partial key of the weak entity type
 The particular entity they are related to in the identifying
entity type
 Example:
 A DEPENDENT entity is identified by the dependent’s first
name, and the specific EMPLOYEE with whom the

dependent is related
 Name of DEPENDENT is the partial key
 DEPENDENT is a weak entity type
 EMPLOYEE is its identifying entity type via the identifying
relationship type DEPENDENT_OF

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

Many-to-one (N:1) Relationship

Many-to-many (M:N) Relationship

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

A Recursive Relationship Supervision`

Summary of notation for ER
diagrams

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

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

Example Attribute of a Relationship Type:
Hours of WORKS_ON

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

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

The (min,max) notation for
relationship constraints
Read the min,max numbers next to the entity

type and looking away from the entity type

COMPANY ER Schema Diagram
using (min, max) notation

Alternative diagrammatic
notation
 ER diagrams is one popular example for
displaying database schemas
 Many other notations exist in the literature
and in various database design and
modeling tools
 Appendix A illustrates some of the
alternative notations that have been used
 UML class diagrams is representative of
another way of displaying ER concepts that
is used in several commercial design tools
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
E1 1 N
R E2
CARDINALITY RATIO 1:N FOR E 1:E2 IN R
(min,max)
R E STRUCTURAL CONSTRAINT (min, max) ON
PARTICIPATION OF E IN R
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

UML class diagrams
 Represent classes (similar to entity types) as large
rounded boxes with three sections:

Top section includes entity type (class) name

Second section includes attributes

Third section includes class operations (operations
are not in basic ER model)
 Relationships (called associations) represented as
lines connecting the classes

Other UML terminology also differs from ER
terminology
 Used in database design and object-oriented
software design
 UML has many other types of diagrams for
software design

UML class diagram for COMPANY
database schema

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
 Constraints are harder to specify for higher-
degree relationships (n > 2) than for binary
relationships

Relationship Types of Degree
Higher than Two
 Choosing between Binary and Ternary (or Higher-
Degree) Relationships
151
Discussion of n-ary relationships
(n > 2)
 In general, 3 binary relationships can represent
different information than a single ternary
relationship (see Figure 3.17a and b on next slide)
 If needed, the binary and n-ary relationships can
all be included in the schema design (see Figure
3.17a and b, where all relationships convey
different meanings)
 In some cases, a ternary relationship can be
represented as a weak entity if the data model
allows a weak entity type to have multiple
identifying relationships (and hence multiple
owner entity types) (see Figure 3.17c)

Discussion of n-ary relationships
(n > 2)
 If a particular binary relationship can be
derived from a higher-degree relationship
at all times, then it is redundant
 For example, the TAUGHT_DURING binary
relationship in Figure 3.18 (see next slide)
can be derived from the ternary
relationship OFFERS (based on the meaning
of the relationships)

Another example of a ternary
relationship

Displaying constraints on
higher-degree relationships
 The (min, max) constraints can be displayed on
the edges – however, they do not fully describe
the constraints
 Displaying a 1, M, or N indicates additional
constraints
 An M or N indicates no constraint
 A 1 indicates that an entity can participate in at
most one relationship instance that has a particular
combination of the other participating entities
 In general, both (min, max) and 1, M, or N are
needed to describe fully the constraints

Example
156
Constraints on Ternary (or Higher-
Degree) Relationships
 There are two notations for specifying structural constraints on n-ary relationships, and they
specify different constraints.
 They should thus both be used if it is important to fully specify the structural constraints on a
ternary or higher-degree relationship.

 The first notation is based on the cardinality ratio notation of binary relationships displayed.
 The second notation is based on the (min, max) notation displayed for binary relationships.
 A (min, max) on a participation here specifies that each
entity is related to at least min and at most max relationship instances in the relationship set.
157
ER Digram –University
database

Air line data Base –ER digram

ER digram –Bank Data base

Subclasses and Superclasses
An entity type may have additional meaningful

subgroupings of its entities
SECRETARY
ENGINEER Superclasses: EMPLOYEE

EMPLOYEE Subclasses: SECRETARY,
TECHNICIAN
ENGINEER,
TECHNICIAN,
SALARIED_EMPLOYEE
SALARIED_EMPLOYEE,
HOURLY_EMPLOYEE
HOURLY_EMPLOYEE
Every entity that is a member of one of
these subgroupings is also an employee
Example
Lname SSN
Fname Addr
DEPARTMENT WORKS EMPLOYEE
d
  d
 

TypingSpeed
EngType MANAGER 
TGrade 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.

Generalization

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
EngType MANAGER 
TGrade 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

Other alternative diagrammatic
notations

Specialization and
Generalization Hierarchies
and Lattices

Specialization and
Generalization Hierarchies
and Lattices

Modeling of UNION Types
Using Categories

A Sample UNIVERSITY EER Schema,
Design Choices, and Formal
Definitions

Data Modeling Tools
 A number of popular tools that cover conceptual
modeling and mapping into relational schema
design.
 Examples: ERWin, S- Designer (Enterprise Application
Suite), ER- Studio, etc.
 POSITIVES:
 Serves as documentation of application requirements,
easy user interface - mostly graphics editor support
 NEGATIVES:
 Most tools lack a proper distinct notation for
relationships with relationship attributes
 Mostly represent a relational design in a diagrammatic
form rather than a conceptual ER-based design

(See Chapter 12 for details)
Some of the Currently Available
Automated Database Design Tools
COMPANY TOOL FUNCTIONALITY
Embarcadero ER Studio Database Modeling in ER and IDEF1X
Technologies
DB Artisan Database administration, space and security
management
Oracle Developer 2000/Designer 2000 Database modeling, application development
Popkin System Architect 2001 Data modeling, object modeling, process modeling,
Software structured analysis/design
Platinum Enterprise Modeling Suite: Data, process, and business component modeling
(Computer Erwin, BPWin, Paradigm Plus
Associates)
Persistence Pwertier Mapping from O-O to relational model
Inc.
Rational (IBM) Rational Rose UML Modeling & application generation in C++/JAVA
Resolution Ltd. Xcase Conceptual modeling up to code maintenance
Sybase Enterprise Application Suite Data modeling, business logic modeling
Visio Visio Enterprise Data modeling, design/reengineering Visual Basic/C++

Chapter Summary
 ER Model Concepts: Entities, attributes,
relationships
 Constraints in the ER model
 Using ER in step-by-step conceptual
schema design for the COMPANY database
 ER Diagrams - Notation
 Alternative Notations – UML class diagrams,
others

Module 1 -DBMS

Uploaded by

Module 1 -DBMS

Uploaded by

Copyright © 2016 Ramez Elmasri and Shamkant B.

Databases and Database Users

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

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

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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

a database. For example, student grades and transcripts

maintenance of a computerized database.

Sometimes, the applications are also included.

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

Physical level: describes

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

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

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

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

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

E.F. “Ted” Codd

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 Image storage and management

 Audio and video data management

 Time series and historical data management

 The above gives rise to new research and

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

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

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

that may not be met because of DBMS

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

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

Database System Concepts

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

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

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

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

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

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

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

 Schema is also called intension.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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