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.

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

Simplified database system environment

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

◼ the database system contains not only the
database itself but also a complete definition or
description of the database structure and
constraints.
◼ This definition is stored in the DBMS
catalog,which contains information such as the
structure of each file, the type and storage format
of each data item, and various constraints on the
data.
◼ The information stored in the catalog is called
meta-data,
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 1- 3
Types of Databases and Database
Applications
◼ Traditional Applications:
◼ Numeric and Textual Databases
◼ More Recent Applications:
◼ Multimedia Databases
◼ Geographic Information Systems (GIS)
◼ Data Warehouses
◼ Real-time and Active Databases
◼ Many other applications
◼ We will focus on traditional applications, with
emphasis on scientific (biological) databases

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

Typical DBMS Functionality
◼ Define a particular database in terms of its data types,
structures, and constraints
◼ Construct or Load the initial database contents on a
secondary storage medium
◼ Manipulating the database:
◼ Retrieval: Querying, generating reports
◼ Modification: Insertions, deletions and updates to its content
◼ Accessing the database through Web applications
◼ Processing and Sharing by a set of concurrent users and
application programs – yet, keeping all data valid and
consistent

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

Typical DBMS Functionality
◼ Other features:
◼ Protection or Security measures to prevent
unauthorized access
◼ “Active” processing to take internal actions on data
◼ Presentation and Visualization of data
◼ Maintaining the database and associated
programs over the lifetime of the database
application

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

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

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

Example of a Database
(with a Conceptual Data Model)
◼ Some mini-world relationships:
◼ SECTIONs are of specific COURSEs
◼ STUDENTs take SECTIONs
◼ COURSEs have prerequisite COURSEs
◼ INSTRUCTORs teach SECTIONs
◼ COURSEs are offered by DEPARTMENTs
◼ STUDENTs major in DEPARTMENTs

◼ Note: The above entities and relationships are typically

expressed in a conceptual data model, such as the
ENTITY-RELATIONSHIP data model (see Chapters 3, 4)

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

Example of a simple database

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

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.
◼ 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.
◼ Most of the systems used today are based on it (Microsoft
Access, MySQL, …)

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

Historical Development of 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, XML, and other data types)

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

Historical Development of Database
Technology (continued)
◼ Data on the Web and E-commerce Applications:
◼ Web contains data in HTML (Hypertext markup
language) with links among pages.
◼ This has given rise to a new set of applications
and E-commerce is using new standards like XML
(eXtended Markup Language).
◼ Script programming languages such as PHP and
JavaScript allow generation of dynamic Web
pages that are partially generated from a
database.
◼ Also allow database updates through Web pages

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

Extending Database Capabilities
◼ New functionality is being added to DBMSs in the following areas:
◼ Scientific Applications

◼ XML (eXtensible Markup Language)

◼ Image Storage and Management

◼ Audio and Video Data Management

◼ Data Warehousing and 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.

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

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.

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

When not to use a DBMS
◼ When no DBMS may suffice:
◼ If the database system is not able to handle the
complexity of data because of modeling limitations
◼ If the database users need special operations not
supported by the DBMS.

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

 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”).
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
Slide 1- 1
Copyright © 2004 Pearson Education, Inc.
 Database Users
⚫Actors on the scene
– 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 administrators:
⚫Responsible for authorizing access to the database,
for coordinating and monitoring its use, acquiring
software and hardware resources, controlling its use
and Elmasri
monitoring efficiency
and Navathe, Fundamentals ofSystems,
of Database operations.
Fourth Edition
Slide 1- 2
Copyright © 2004 Pearson Education, Inc.
 Categories of 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 against the
database.
– Examples are bank-tellers or university secretaries who do
this activity for an entire shift of operations.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Slide 1- 3
Copyright © 2004 Pearson Education, Inc.
Categories of 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 a scientists that creates a database for its
own experiments.
– Another example is a user that maintains an address book
⚫You may become sophisticated or stand-alone
users
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
Slide 1- 4
Copyright © 2004 Pearson Education, Inc.
 FIGURE 2.3
Component modules of a DBMS and their interactions.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Copyright © 2004 Pearson Education, Inc.
Slide 2-5
Centralized and Client-Server
Architectures
• Centralized DBMS: combines everything
into single system including- DBMS
software, hardware, application programs
and user interface processing software.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Copyright © 2004 Pearson Education, Inc.
Slide 2-6
 FIGURE 2.4
A physical centralized architecture.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Copyright © 2004 Pearson Education, Inc.
Slide 2-7
 Specialized Servers with
Specialized functions:
• File Servers
• Printer Servers
• Web Servers
• E-mail Servers

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Copyright © 2004 Pearson Education, Inc.
Slide 2-8
 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.)
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Slide 2-9
 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.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Copyright © 2004 Pearson Education, Inc.
Slide 2-10
 Two Tier Client-Server
Architecture
• 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.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Copyright © 2004 Pearson Education, Inc.
Slide 2-11
 FIGURE 2.5
Logical two-tier client/server architecture.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Copyright © 2004 Pearson Education, Inc.
Slide 2-12
 FIGURE 2.6
Physical two-tier client-server architecture.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Copyright © 2004 Pearson Education, Inc.
Slide 2-13
⚫ The user interface programs and application programs can
run on the client side.

⚫ When DBMS access is required, the program establishes a

connection to the DBMS(which is on the server side); once
the connection is created.

⚫ the client program can communicate with the DBMS. A

standard called Open Database Connectivity(ODBC)
provides an application programming interface (API)

⚫ A related standard for the Java programming language,

called JDBC, has also been defined. This allows Java
client programs to access one or more DBMSs through a
standard interface
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Slide 2-14
⚫The architectures described here are called
two-tier architectures because the
software components are distributed over
two systems: client and server.

⚫This architecture are its simplicity and

seamless compatibility with existing
systems.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Copyright © 2004 Pearson Education, Inc.
Slide 2-15
 Three Tier Client-Server
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
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Slide 2-16
 FIGURE 2.7
Logical three-tier client/server architecture.

•(ERP,CRM)

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Copyright © 2004 Pearson Education, Inc.
Slide 2-17
 Classification of DBMSs
• Based on the data model used:
• Traditional: Relational, Network, Hierarchical.
• Emerging: Object-oriented, Object-relational.
• Other classifications:
• Single-user (typically used with micro-
computers) vs. multi-user (most DBMSs).
• Centralized (uses a single computer with one
database) vs. distributed (uses multiple
computers, multiple databases)
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Slide 2-18
 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.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Copyright © 2004 Pearson Education, Inc.
Slide 2-19
 DBMS Languages
• Data Manipulation Language (DML):
Used to specify database retrievals and
updates.
• DML commands (data sublanguage) can be
embedded in a general-purpose programming
language (host language), such as COBOL, C
or an Assembly Language.
• Alternatively, stand-alone DML commands can
be applied directly (query language).

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Copyright © 2004 Pearson Education, Inc.
Slide 2-20
 DBMS Languages
• 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.
• Low Level or Procedural Languages:
record-at-a-time; they specify how to
retrieve data and include constructs such as
looping.
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Slide 2-21
 DBMS Interfaces
• Stand-alone query language interfaces.
• Programmer interfaces for embedding DML in
programming languages:
• Pre-compiler Approach
• Procedure (Subroutine) Call Approach
• User-friendly interfaces:
• Menu-based, popular for browsing on the web
• Forms-based, designed for naïve users
• Graphics-based (Point and Click, Drag and Drop etc.)
• Natural language: requests in written English
• Combinations of the above
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
Copyright © 2004 Pearson Education, Inc.
Slide 2-22
 Other DBMS Interfaces
• Speech as Input (?) and Output
• Web Browser as an interface
• Parametric interfaces (e.g., bank tellers) using
function keys.
• Interfaces for the DBA:
• Creating accounts, granting authorizations
• Setting system parameters
• Changing schemas or access path

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition

Copyright © 2004 Pearson Education, Inc.
Slide 2-23
Data independence
◼ Data Abstraction:
◼ A data model is used to hide storage details and
present the users with a conceptual view of the
database. Program-data independence called data
abstraction.
◼ Programs refer to the data model constructs rather
than data storage details

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

Three-Schema Architecture
• Proposed to support DBMS characteristics of:
• Program-data independence.
• Support of multiple views of the data.

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

FIGURE 2.2
The three-
schema
architecture.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2-3

◼ Defines DBMS schemas at three levels:

◼ External schemas at the external level to describe the

various user views. Usually uses the same data model as
the conceptual level.

◼ The external or view level includes a number of external schemas or

user views. Each external schema describes the part of the database
that a particular user group is interested in and hides the rest of the
database from that user group. As in the previous level, each external
schema is typically implemented using a representational data model,
possibly based on an external schema design in a high-level data
model.

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

Three-Schema Architecture
• 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.

• At the conceptual level, we have the conceptual

schema, which describes all the entities, attributes, and
relationships together with integrity constraints.
• The logical schema comprises a series of diagrams
(i.e., ERD diagrams) that define the content of
database tables and describe how the tables are linked
together for data access.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2-5

Internal schema at the internal level to describe physical
storage structures and access paths. Typically uses a
physical data model

At the lowest level of abstraction, we have the internal

schema, which is a complete description of the internal
model, containing the definitions of stored records, the
methods of representation, the data fields, and the
indexes and storage structures used.

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

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.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2-7

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.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2-8

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

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2-9