UNIT- 1

DATABASE SYSTEMS CONCEPTS AND ARCHITECTURE

• Introduction to database systems

• Characteristics of database approach – Actors on
the scene –Workers behind the scene –
• Advantages of using DBMS approach,
• Data Models, Schemas, and Instances, Three
Schema Architecture and Data Independence,
• The Database System Environment,
• Centralized and Client/Server Architectures for
DBMSs,
• Classification of database management systems.
 Introduction

• A database is a collection of related data with

an implicit meaning.
• Data is known facts that can be recorded and
that have implicit meaning.
A database has the following implicit properties:
 Database management system
(DBMS)
• A database management system (DBMS) is a
computerized system that enables
users to create and maintain a database.
• The DBMS is a general-purpose software
system that facilitates the processes of
defining, constructing, manipulating, and
sharing databases among various users and
applications.
 Functionalities of DBMS
• Defining a database involves specifying the data types, structures, and
constraints of the data to be stored in the database. The database
definition or descriptive information is also
stored by the DBMS in the form of a database catalog or dictionary; it is
called meta-data.
• Constructing the database is the process of storing the data on some
storage medium that is controlled by the DBMS.
• Manipulating a database includes functions such as querying the database
to retrieve specific data, updating the database to reflect changes in the
miniworld, and generating reports from the data.
• Sharing a database allows multiple users and programs to access the
database simultaneously.
 Other Functionalities
• Protection includes system protection against
hardware or software malfunction (or crashes)
and security protection against unauthorized or
malicious access.
• Maintaining - A typical large database may have a
life cycle of many years, so the DBMS must be
able to maintain the database system by allowing
the system to evolve as requirements change
over time.
Example- University Database
• To complete our initial definitions, we will call the database and DBMS
software together a database system.
 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 multiuser transaction
processing
 Main Characteristics of the Database
Approach
• Self-describing nature of a database system:
– A DBMS catalog stores the description of a particular database
(e.g. data structures, types, and constraints)
– The description is called meta-data*.
– This allows the DBMS software to work with different database
applications.
• Insulation between programs and data
- program-data independence.
• Allows changing data structures and storage organization without having
to change the DBMS access programs
– program-operation independence.
• Actual method is invisible to end user
Example of a Simplified Database Catalog
 Main Characteristics of the Database
Approach (continued)
• Data abstraction:
- The characteristics that allows program-data
independence and program-operation independence
– 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.
 Main Characteristics of the 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.
 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 storage structures for efficient query processing.
• Providing backup and recovery services.
• Providing multiple interfaces to different classes of users.
• 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)
• Representing complex relationships among
data
• Enforcing integrity constraints on the database
• Permitting inferences and actions from the
stored data using deductive and active rules
and triggers
 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).
 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
 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.
Example of a Database 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.
 Three-Schema Architecture
• 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
 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.
 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.
 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.
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
• Client and server must install appropriate client module and
server module software for ODBC or JDBC
Two Tier Client-Server Architecture
• 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.
 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
Three-tier client-server architecture
 Classification of DBMS
• Based on the data model used
– Legacy: Network, Hierarchical.
– Currently used: Relational, Object-oriented, Object-
relational.
• Other classifications
– Single-user (typically used with personal computers)
vs. multi-user (most DBMSs).
– Centralized (uses a single computer with one
database)
vs. distributed (uses multiple computers, multiple
databases)
 Summary
• 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