Components and Functionalities of a

Database System
• A database system is partitioned into modules that
deal with each of the responsibilities of the overall
system.
• The functional components of a database system
can be broadly partitioned into two:
– storage manager and
– the query processor components as shown in the figure
next slide.

1
 2
Database System Structure
 Components and Functionalities of a
Database System
• Storage manager: is a program module that
provides interface between the low level data
stored in the database and the application
programs or queries submitted to the system.
• The storage manager translates the various
DML statements into low level file system
commands (the conventional operating system
commands); this it is responsible for storing,
retrieving and updating data.
3
 Components and Functionalities of a
Database System
• The main components of the storage manager are:
– Authorization and integrity manager: checks for credentials of the
users and tests for the integrity constraints.
– Transaction Manager: enables to preserve consistency despite
system failure and avoid conflict at the time of concurrent
transaction.
– File manager: manages disk storage allocation and data structure for
stored data.
– Buffer manger: is responsible for fetching data from disk storage to
the main memory.

4
 Components and Functionalities of a
Database System
• Query Processor: is a module that handles queries as
well as requests for modification of the data and metadata.
Some of the components are:
– DDL interpreter (compiler): processes DDL statements for
schema definition (meta-data) and records the definitions in the
data dictionary.
– DML compiler: analyze, translates and optimizes DML
statements in a high-level query language into an evaluation
plan consisting of low-level instructions codes to the query
evaluation (execution) engine.
– Query evaluation engine: execute low-level instructions
generated by the DML compiler.

5
 Data Models
• Data Model: A set of concepts to describe the structure of a
database, and certain constraints that the database should
obey.
• Data Model Operations: Operations for specifying
database retrievals and updates by referring to the concepts
of the data model. Operations on the data model may include
basic operations and user-defined operations.

Slide 2-6
 Types of Data Models
• Hierarchical Model
• Network Model
• Relational Model
• High-level (Conceptual) Model
– Entity–Relationship Model
– Object-Oriented Model

7
 1. Hierarchical Model
• organizes data in a tree structure.
• uses Parent Child Relationships (one to many).
– Each parent can have many children
– Each child has only one parent
• implies that a record can have repeating information,
generally in the child data segments.
• popular from the late 1960s, with the introduction of IBM's
Information Management System (IMS) DBMS, through the
1970s.

8
Example

9
 2. Network Model
• permitted the modeling of many-to-many relationships in
data.
• Each record can have multiple parents
– Composed of sets
– Each set has owner record and member record
– Member may have several owners
• The data model is a simple network, and link and
intersection record types may exist, as well as sets between
them
• In 1971, the Conference on Data Systems Languages
(CODASYL) formally defined the network model.
10
Example

11
 3. Relational Model
• The history of the relational database began with E.F. Codd's 1970
paper, A Relational Model of Data for Large Shared Data Banks.
The concept derives from his principles of relational algebra. Most
of the database systems in use today are based on the relational
system, know as Relational Database Management Systems
(RDBMS)
• The model initial allows the definition of data structures, storage
and retrieval operations and integrity constraints. In such a database
the data and relations between them are organized in tables.
• A table is a collection of records and each record in a table contains
the same fields organized in columns.
• The records in the table form the rows of the table.

12
Example

13
 Properties of Relational Tables
• Values Are Atomic
• Each Row is Unique
• Column Values Are of the Same Kind
• The Sequence of Columns is Insignificant
• The Sequence of Rows is Insignificant
• Each Column Has a Unique Name

14
 Steps of Database Design
• In general, it involves three steps
– Requirements analysis – specifies what the system
is required to do based on user input.
– Design – specifies how the system will address the
requirements.
• Conceptual Design
• Implementation (Logical) Design
• Physical Design
– Implementation – translates design specifications
into a working system.
15
 Requirement analysis
• determines the data, information, system components,
data processing and analysis functions required by the
system.
• involves the process of identifying and documenting the
data required by users to meet present and future
information needs.
• Requirements are determined by interviewing producers
and users of data and producing a formal requirements
specification. The specification includes
– the data required for processing, natural data relationships,
constraints with respect to performance, integrity and security.

16
 Requirement analysis
• The Requirements analysis should address the
following questions
- What user views are required (present and future)?
- What data elements are required in these user views?
- What are the primary keys that uniquely identify entities in
the organization?
- What are the relationships between data elements?
- What are the operational requirements such as security,
integrity, and response time?

17
 Steps in Requirements Analysis
1. Identify scope of the design effort.
2. Establish metadata collection standards – who to interview, what to
collect, how to structure interview.
3. Identify user views – extracted by reviewing user tasks, types of
decisions. Forms, reports, graphs, maps can be useful information for
defining views.
– User view- subset of data used by a user in a specific context
4. Build a data dictionary – define and describe each item in detail: name,
description, type, length, range and relationships
5. Identify data volumes and usage patterns – how much data is used and
how frequently is data change.
6. Identify operational (functional) requirements.

18
 Design
• Design of a database involves three types of designing steps:
– Conceptual Design: Synthesis of information from requirements
analysis according to semantic rules. Outcome is a conceptual
model. The conceptual model describes entities, attributes and
relations among entities independent of implementation details.
– Implementation (Logical) Design: Transforms the conceptual data
model into an internal model - schema that can be processed by a
particular DBMS. For example E/R model to relational model
mapping.
– Physical Design: Involves design of internal storage structures,
record formats, access methods, record blocking and soon. [Requires
a higher level study]

19
 Implementation
• is simply translating the implementation design into one of
the database management systems. That is
writing/developing the entities and/or the objects in the
database schema together with their relationships and
constraints.

20
21
 Schemas versus Instances
• Database Schema: The description of a database.
Includes descriptions of the database structure and
the constraints that should hold on the database.
• Schema Diagram: A diagrammatic display of (some
aspects of) a database schema.
• Schema Construct: A component of the schema or
an object within the schema, e.g., STUDENT,
COURSE.
• Database Instance: The actual data stored in a
database at a particular moment in time. Also called
database state (or occurrence).
Slide 2-22
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 when it is
loaded
• Valid State: A state that satisfies the structure and
constraints of the database.
• Distinction
• The database schema changes very infrequently. The database
state changes every time the database is updated.
• Schema is also called intension, whereas state is called
extension.

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

Slide 2-24
 Three-Schema Architecture
• Defines DBMS schemas at three levels:
• Internal schema at the internal level to describe physical
storage structures and access paths. Typically uses a
physical data model.
• Conceptual schema at the conceptual level to describe the
structure and constraints for the whole database for a
community of users. Uses a conceptual or an
implementation data model.
• External schemas at the external level to describe the
various user views. Usually uses the same data model as
the conceptual level.

Slide 2-25
 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.

Slide 2-26
 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.

Slide 2-27
 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).

Slide 2-28
 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.

Slide 2-29
 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

Slide 2-30
 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

Slide 2-31
 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.

Slide 2-32
 Centralized and Client-Server Architectures
• Centralized DBMS: combines everything into
single system including- DBMS software,
hardware, application programs and user
interface processing software.

Slide 2-33
 Basic Client-Server Architectures
• Specialized Servers with Specialized functions
• Clients
• DBMS Server

Slide 2-34
 Specialized Servers with Specialized
functions:
• File Servers
• Printer Servers
• Web Servers
• E-mail Servers

Slide 2-35