Data Base System Concepts and

Architecture

By Mr. Gebriye Em.

Department of CS,
Raya University
Outline

2.1 Data Models, Schemas, and Instances

2.2 Three –Schema Architecture and Data Independence
2.3 Database Languages and Interfaces
2.4 Software Modules of DBMS
2.5 Centralized and Client/Server architecture for DBMS
2.6 Classification of Database Management Systems
2.1 Data Models, Schemas, and Instances

 Data Model: A set of concepts to describe the structure of a database,

and certain constraints that the database should obey. They provide data
abstraction.
 Structure: data types, relationships, constraints
 Data Model Operations: Operations for specifying database retrievals
and updates by referring to the concepts of the data model.
 Generic operation: insert, delete, modify, retrieve
 User-defined operations
2.1.1 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.)
 Entities
 Attributes
 Relationships
 Physical (low-level, internal) data models: Provide concepts that
describe details of how data is stored in the computer.
 Record formats
 Record ordering
 Access paths
2.1.1 Categories of Data Models
(Continued…)

 Implementation (record-oriented) data models: Provide concepts that fall

between the above two, balancing user views with some computer
storage details.
 Relational
 Network
 Hierarchical
2.1.2 Schemas, Instances and Database State

 Database Schema (meta-data): The description of a database. It is very

important for further understanding of the database and its contants
 Schema Diagram: A diagrammatic display of (some aspects of ) a
database schema
 Database Instance: The actual data stored in a database at a particular
moment in time. Also called database state ( or occurrence, snapshot)

 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
Schema diagram for the UNIVERSITY database

 Schema Constructs
The UNIVERSITY database
Differentiating Schema and Instances

 The database schema changes less frequently

It changes during schema evolution
 Database definition
Database Instances are empty

 When you start loading data into the database

Initial state of your database
 When you update or delete
Your database state changes
 Valid state is a state that satisfies the structure and constraints of the
database
2.2 Three –Schema Architecture and Data
Independence

 2.2.1 Three-Schema Architecture

Database architecture:is a set of specifications , rules and processes
that determine how the database is designed and constructed. It also
determines how data is stored in the database and how data is accessed
by the components of DBMS
 It is generally accepted architecture for database systems and it was
suggested by ANSI/SPARC
 The 3-schema architecture was proposed to achieve and visualize 3
important characteristics :
 Insulation of programs and data/program and operations
 Support of multiple views of the data
 Use of catalog (database description)
2.2.1 Three-Schema Architecture(Continued…)

 The database system is described by three abstract levels which

correspond to three different views of the data stored in the database
 In this architecture schemas can be defined at 3 different levels:
1. External or View level - individual user view
 Contains 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
 A high-level data model or Implementation data model can be
used at this level.
Fig. Three-Schema Architecture
2.2.1 Three-Schema Architecture(Continued…)

2. Conceptual or Logical level- community user view

 Has a conceptual schema that describes the structure of the whole
database to a community of users
 The conceptual schema hides the details of physical storage
structures and concentrates on describing entities, relationships, data
types, constraints and user operations
 A high-level data model or Implementation data model can be used
at this level
2.2.1 Three-Schema Architecture(Continued…)

3.Internal or Physical level - physical or storage view

 Has an internal schema that describes the details of the physical
storage structures of the database
 The internal schema uses a physical data model and describes the
complete details of data storage and access paths for the database
 Efficiency considerations are the most important at the internal level
and the data structures are chosen to provide an efficient database
access
 Do all DBMSs implement the 3-schema architecture?
 Does the 3- schema architecture deal about the actual data?
 Mappings

 Mapping :the processes of transforming requests and results between

levels
– i.e. The process of transforming a request specified on
an external schema into a request against the conceptual
schema, and then into a request against the internal
schema for processing over the stored database
 These mappings might be time-consuming.So some DBMSs-
specially those that are meant to support small databases-do
not support external views
2.2.2 Data Independence

 What is Data independence ?

 The capacity to change the schema at one lower level without
having to change the schema at the next higher level(s). Only the
mappings between the levels are changed
 The 3-schema architecture makes it easier to achieve true
data independence
 There are two kinds of data independence:
1. Logical data independence
2. Physical data independence
2.2.2 Data Independence( Contiuued…)

1. Logical data independence

 Is the capacity to change the conceptual schema without
having to change the external schemas or application
programs
 When do we need to change the conceptual schema ?
 To expand the database
 Reduce the database
2.2.2 Data Independence( Continued …)

2.Physical data independence:

 Is the capacity to change the internal schema without
having to change the conceptual schema or external
schemas
 When do we need to change the internal schema?
 To improve the performance of retrieval or update of
data but the conceptual schema will remain the same
if we don’t add extra record type, data item or
constraint into the database.
2.3 Database Languages and Interfaces

 2.3.1 DBMS Languages

a. In DBMSs where no strict separation of levels is maintained:
 One language, called the data definition language (DDL), is used by the DBA
and by database designers to define both the conceptual and internal schemas
b. In DBMSs where a clear separation is maintained between the conceptual and
internal levels :
 The DDL is used to specify the conceptual schema only
 Another language, the storage definition language (SDL), is used to specify
the internal schema
 The mappings between the two schemas may be specified in either one of
these languages.
c. For true three-schema architecture:
 We would need a third language called, the view definition language (VDL),
to specify user views and their mappings to the conceptual schema, but in most
DBMSs the DDL is used to define both conceptual and external schemas.
2.3 Database Languages and Interfaces

2.3.1 DBMS Languages

 Data Manipulation Language (DML)
 Enable the user to perform operations like retrieval, insertion,
deletion, and modification of the data
 There are two types of DMLs:
 High-level or Non-procedural(set-at-a-time or set-oriented
DMLs.)
 Low-level or Procedural(Record-at-a-time DMLs)
 How are such languages presented in current DBMSs?
 No distinct languages. Rather, a comprehensive integrated language
is used. E.g. SQL(DDL + VDL + DML) But SDL is currently
removed
2.3 Database Languages and Interfaces

 2.3.1 DBMS Languages

 Any DML can be embedded in a general-purpose programming
language
 That language is called the host language and the DML is called the
data sublanguage
 But if a high-level DML is used in a stand-alone interactive manner,
it is called a query language
2.3 Database Languages and Interfaces

 2.3.2 DBMS Interfaces

 Menu-Based Interfaces for Browsing
– Provide the user with list of options called menus
– The menus lead the user through the formulation of a requests
– No need to memorise specific syntax of a query language
– Query is composed step-by-step by picking options
 Forms-Based Interfaces
– Such interfaces display a form to each user
– User then fills out form entries
– Usually for naïve users as interfaces for canned transactions
– Some DBMSs have form specification languages and others have utilities
2.3 Database Languages and Interfaces

 2.3.2 DBMS Interfaces

 Graphical User Interfaces
– GUI typically displays a schema to the user in a diagrammatic form
– Query is specified by manipulating the diagram
– In many cases they use both menus and forms
– Most GUIs use pointing devices to pick certain parts of a displayed schema
diagram
 Natural Language Interfaces
– Accept requests written in English or some other language and try to
understand them
– Have their own schema similar to that of database conceptual schema
– The natural language interface refers to the words in its schema, as well as to
a set of standard words, to interpret the request
2.3 Database Languages and Interfaces

 2.3.2 DBMS Interfaces

 Interfaces for Parametric Users
– Parametric users have a small set of operations that they must perform
repeatedly
– A small set of abbreviated commands is used to minimize the number of key
strokes required
– Function keys can be programmed to initiate various commands
 Interfaces for the DBA
– Special interface is needed for the DBA to execute some commands that are
allowed only for him. Such commands may include commands for creating
users, setting system parameters, granting account authorization, schema
change, etc
2.4 Software Modules of the DBMS
Application
programmers

APPLICATION
DBA Staff Casual users PROGRAMS

Precompiled

DDL STATEMENTS PRIVILEGED COMMANDS INTERACTIVE QUERY Parametric users

Host Language Compiler

DDL Compiler Query Compiler

COMPILED (CANNED)
DML STATEMENTS
TRANSACTIONS

execution

System Catalog/ DML Compiler

Data Dictionary

Run-time Database
execution execution
Processor

Concurrency Control/
Stored Data Manager Backup/Recovery
Subsystems

STORED DATABASE
2.4 Software Modules of the DBMS

 Access to the disk is controlled primarily by the operating system (OS), which
schedules disk input/output

 Stored data manager module of the DBMS controls access to DBMS

information that is stored on disk, whether it is part of the database or the
catalogue. Note the dotted lines and circles

 Stored data manager uses basic services of the OS to perform low-level data
transfer between hard disk and main memory

 Other task of Stored data manager: Handling buffers in main memory

2.4 Software Modules of the DBMS

 The DDL compiler processes schema definitions, specified in the DDL, and
stores the schema definitions (meta-data) in the DBMS catalogue

 The run-time database processor handles database accesses at run time under
the supervision of stored data manager

 It receives retrieval or update operations and carries them out on the database

 The query compiler handles high-level queries that are entered interactively
2.4 Software Modules of the DBMS

 It parses, analyzes, and compiles or interprets a query by creating database access

code, and then generates calls to the run-time processor for executing the code

 The pre-compiler extracts DML commands from an application program written

in a host programming language

 These commands are sent to the DML compiler for compilation into object code
for database access

 The rest of the program is sent to the host language compiler

2.4 Software Modules of the DBMS

 Object codes generated by DML compiler + Object codes from Host language
compiler = Canned transactions
 The executable codes of the canned transactions include calls to the Run-time
database processor
2.5 Centralized & Client/Server architecture for DBMS

 2.5.1 Centralized and Distributed Databases

 DBMSs can be categorized as Centralized or Distributed base on the
number of sites over which the database is located

 A DBMS is centralized if the data is stored at a single computer site

 A centralized DBMS can support multiple users, but the DBMS and the
database themselves reside totally at a single computer site

 The following figure shows a single-tier Centralized database

2.5 Centralized & Client/Server architecture for DBMS

Centralized Database
Dumb
Terminal 1
DBMS
Dumb
Terminal 2

Data Dumb
Terminal n
2.5 Centralized & Client/Server architecture for DBMS

 A distributed DBMS (DDBMS) can have the actual database and DBMS
distributed over many sites and connected by a computer network

 Homogeneous DDBMSs use the same DBMS at multiple sites

 Heterogeneous DDBMSs use different DBMSs at multiple sites .This leads to a

Federated DBMS (or Multidatabase system), where the participating DBMSs
are loosely coupled and have a degree of local autonomy

 Many DDBMSs use client-server architecture.

 Homogeneous DDBMSs

CLIENT
CLIENT CLIENT CLIENT CLIENT

MYSQL
MYSQL

LAN

CLIENT CLIENT CLIENT CLIENT

Mekelle Adigrat

CLIENT
CLIENT CLIENT CLIENT CLIENT

MYSQL
MYSQL

LAN

CLIENT CLIENT CLIENT CLIENT

Axum Adwa
 Heterogeneous DDBMSs

CLIENT
CLIENT CLIENT CLIENT CLIENT

DB 2
MYSQL

LAN

CLIENT CLIENT CLIENT CLIENT

Mekelle Adigrat

CLIENT
CLIENT CLIENT CLIENT CLIENT

MS ACCESS
ORACLE

LAN

CLIENT CLIENT CLIENT CLIENT

Axum Adwa
2.5 Centralized & Client/Server architecture for DBMS

 2.5.2 Client/Server architecture for DBMS

 A client is defined as a requester of services and a server is defined as the
provider of services. Usually the server is a more powerful machine to
provide the services

 A service can be any resource such as data, display device, CPU time,
memory, etc.

 A single machine can be both a client and a server depending on the software
configuration

 The client and the server has their own characteristics:

2.5 Centralized & Client/Server architecture for DBMS

 Characteristics of a client
 Initiates requests
 Waits for replies
 Receives replies
 Usually connects to a small number of servers at one time
 Typically interacts directly with end-users using a graphical user interface
 Characteristics of a server
 Never initiates requests or activities
 Waits for and replies to requests from connected clients
 A server can remotely install/uninstall applications and transfer data to the
intended clients
2.5 Centralized & Client/Server architecture for DBMS

 Two-tier Client/Server Architecture

 It contains a client and a server
 The DBMS & database are stored on the server, and the interface used to
access the database is installed on the client
 An interface called Open Data Base Connectivity (ODBC) provides
Application Program Interface (API) that enables clients to call the DBMS

Server
Client DBMS
User
Interface = Request
Data
 Two-tier Client/Server
Over a Communication Network

CLIENT 1
#1 SERVER

1 D/BASE
CLIENT 
#2


CLIENT 
#3

 Data Request
 Data Response
2.5 Centralized & Client/Server architecture for DBMS

 Usage Considerations
 Used extensively in non- time critical information processing where
management and operations of the system are not complex

 Used frequently in decision support systems where the transaction

load is light

 They work well in relatively homogeneous environments with

processing rules (business rules) that do not change very often and
when workgroup size is expected to be fewer than 100 users, such as
in small businesses.
2.5 Centralized & Client/Server architecture for DBMS

 Advantages:
 Since processing was shared between the client and server, sufficient
number of users could interact with such a system
 Disadvantages:
 Performance declines when the number of users exceeds 100
 Clients may require more resources
 With much similar processing on many clients, extending
existing applications and implementing new ones becomes
more complex
 User interface and business processing tend to get mixed
together
2.5 Centralized & Client/Server architecture for DBMS

The 3-tier architecture

 Purpose : to overcome the limitations
GUI Web
of the two-tier approach Client
Interface
 There are three tiers :
 Client tier –the interface
between the user and the system
 Middle tier(mainly Application Application Application
Server or Web Server) – contains Server or Web Programs, Web
most of the logic and communicates Server Pages
b/n the other tiers
 Database Server – manages the
database
Database
Database Server Management
System
2.5 Centralized & Client/Server architecture for DBMS

 The intermediate layer called the Applications Server or Web Server has the
following basic functions:

 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

 Encryption and decryption of data for transmission between the client &
server
2.5 Centralized & Client/Server architecture for DBMS

 The 3-tier architecture

 IIS=Internet Information Server
 IIS is a web server developed by
Microsoft
 It is the 2nd most popular web
server next to Apache HTTP
Server
2.5 Centralized & Client/Server architecture for DBMS

 The thin-client 3-tier model has these tiers:

 The database management system (DBMS)
 The main application software
 A web browser
 IT students in their web design course :
 Database tier: MySQL
 Middle tier: PHP/HTML
 Client tier: Your favorite web browser
 The thick-client 3-tier model has these tiers:
 The database management system (DBMS)
 The main application software
 Some sort of interface software which must be installed on each client
machine
2.5 Centralized & Client/Server architecture for DBMS

 Advantages of the 3-tier architecture

 Removes a huge processing burden from client machines

 Can be used to consolidate enterprise-wide business rules as application

servers process business rules in a single place for use by multiple
applications. When rules change, only a change to the application server is
required

 Any knowledge of the database server may be hidden from the client.
database queries may be presented to client in alternative forms

 The middle tier server improves performance, flexibility, maintainability,

reusability, and scalability by centralizing process logic
2.5 Centralized & Client/Server architecture for DBMS

 An n-tier architecture is one which has n tiers, usually including a

database tier, a client tier, and n-2 other tiers in between

 In other words an n-tier model will have :

 The database management system (DBMS)

 (n-2) application layers
 A GUI (thin or thick)
2.6 Classification of Database Management Systems

 Based on the data models used : Based on number of Sites

Centralized
 Traditional : Relational, Hierarchical,
Distributed
Network
Based on purpose
 Emerging : Object-relational , Object- Special-purpose
Oriented General-purpose
 Based on Cost
 <$10K
 $10K – $100K
 >$100K
 Based on number of users
 Single-user
 Multi-user
 Thanks you
 If you have any Question?