Database Concepts

and Architecture

August 7, 12, 2024

 Database System Architecture
◆ Framework on which subsequent concepts can
build
◆ Useful for describing general DB concepts and
the structure of specific DB systems
◆ Architecture
proposed by the ANSI/SPARC
Study Group on Data Base Management
Systems

2
 The Levels of Abstraction
Three level ANSI/SPARC architecture
External Level
(Individual User View)
concerned with the way the data is
seen by individual users

Conceptual Level
(Community User View)
a level of indirection between the other two

Internal level
(Storage View)
concerned with the way the data is
stored inside the system

3
 What is in each Level?
Implementation level: defined in machine-
◆ Internal Level oriented constructs such as bits and bytes
◼ Data storage details, access path

◆ Conceptual Level (Structure of the entire database)

◼ Entities, data types, relationships, user operations, constraints
Model levels: defined in user-oriented
◆ External Level constructs such as records and fields
◼ Part of the database interested to a particular user group
◆ Remember:
◼ many distinct “external views”, but precisely
◼ one “conceptual view”, consisting of an abstract
representation of the DB in entirety, and
◼ one “internal view”, representing the DB as stored internally
4
Detailed System Architecture

5
 The External Level (Individual User Level)

◆ Application programmer/end user

◆ Each user has a language at his/her disposal
◆ Host language: to provide non-database facilities
◆ Data sublanguage (DSL) Ex: SQL
◼ Concerned specifically with database objects and operation
◼ Embedded within the corresponding host language
◆ Each external view is defined by external schema
written using the DDL portion of the user’s DSL
◆ External schema: definitions of various external record
types in that external view + definition of the mapping
b/w external schema and conceptual schema 6
 The Conceptual Level
◆ The conceptual view:
◼ View of the data “as it really is” rather than as users are
forced to see it
◼ Defined by conceptual schema written using conceptual DDL
◆ A conceptual record is not necessarily the same as
either an external record or a stored record
◼ Fields and record names can be changed
◼ Several conceptual fields can be combined into a single
external field
◆ Mostly the “conceptual schema” is a simple union of all
individual external schemas, plus certain security and
integrity constraints
7
 The Internal Level
◆ Internal view is low level rep. of the entire database
◼ Described by means of the internal schema and written
using internal DDL
◼ Effectively assumes an unbounded linear address space
◆ Details of how that address space is mapped to
physical storage are highly system specific
◆ Internal schema
◼ Defines the various stored record types
◼ Specifies what indexes exist
◼ How stored fields are represented
◼ What physical sequence the stored records are in
8
 Mappings (1/2)
◆ Conceptual/internal mapping
◼ Correspondence b/w the conceptual view and the stored DB
◼ Specifies how conceptual records and fields are represented
at the internal level
◼ Structure of the stored DB is changed → the mapping must
be changed accordingly, so that the conceptual schema can
remain invariant
◼ Key for providing physical data independence
◆ Physical storage structure/devices used to store the data
could be changed without a change in the conceptual
view or any of the external views
◼ Responsibility of DBA or the DBMS
9
 Mappings (2/2)
◆ External/conceptual mapping
◼ Correspondence b/w a particular external view and the
conceptual view
◼ Key for providing logical data independence
◆ The conceptual schema can be changed without affecting
the existing external schemas, or
◆ Users and user programs are immune to changes at
conceptual level of the DB
◼ Some changes, such as the deletion of a conceptual view
field or record, may require changes in the external view and
application programs using this external view
10
 Data Independence
◆ To achieve data independence
◼ Conceptual DDL definitions must not involve any physical
representation or access technique at all
◼ They must be definitions of information content only
◼ There must be no reference in the conceptual schema to
stored field rep., stored record sequence, indexes, hashing
schemes, pointers, or any other storage & access details

◆ If the conceptual schema is made truly data-

independent in this way, then the external schemas,
which are defined in terms of the conceptual schema
will also be data-independent
11
 The Database Administrator
◆ Person who makes the strategic and policy decisions

◆ DBA is the person who provides the necessary

technical support for implementing those decisions
◆ Defining the information content of the DB
◆ Defining the internal schema
◆ Liaising with users
◆ Defining security and integrity constraints (logical
extension of the conceptual schema)
◆ Defining dump/restore schemes
◆ Monitoring performance and responding to changing
requirements
12
 End Users
◆ Casual End Users:
◼ Occasionally access the DB, but require different information each time
◼ Use query language to specify their requests
◆ Naïve or Parametric End Users: (a sizable portion of DB end users)
◼ Their job revolves around constantly querying and updating the DB,
using standard types of queries and updates – called canned
transactions – that have been carefully programmed and tested
◆ Sophisticated End Users:
◼ Include people thoroughly familiarize themselves with the facilities of the
DBMS and can implement their applications having complex requirement
◆ Stand-alone Users:
◼ Maintain personal DBs by using ready-made program packages that
provide easy-to-use menu-based or graphics-based interfaces
◼ Ex: user of a tax package that stores a variety of personal financial data
for tax purposes
13
 DBMS
◆ Conceptually this happens
◼ A user issues an access request, using some
particular DSL (typically SQL)
◼ The DBMS accepts that request and analyzes it
◼ The DBMS inspects, the object version of the
external schema for that user, the corresponding
external/conceptual mapping, the conceptual
schema, the conceptual/internal mapping, and the
stored DB definition
◼ The DBMS executes the necessary operations on
the stored DB
14
 DBMS Component Modules

◆ DB and Data dictionary: stored on disk

◆ Accessto disk: controlled primarily by the OS,
which schedules disk I/O
◆A higher-level module of the DBMS controls
access to DBMS information stored on disk,
whether it is part of DB or Data dictionary
◆ Stored Data Manager

15
 DBMS Component Modules

The dotted
lines and
5
2 circles
4 illustrate
Canned transactions accesses that
are under the
1
control of
3 stored data
manager

16
 DBMS Component Modules
◆ Stored Data Manager
◼ May use basic OS services to carry out low-level
data transfer b/w the disk and main storage
◼ But it controls other aspects of data transfer, such
as handling buffers in main mem
◆ Once the data is in the main mem buffers, it can
be processed by other DBMS modules, as well
as by application programs
◆ Some DBMS have their own buffer manager
module, while others use the OS for handling
the buffering of disk pages 17
 DBMS Component Module:
DDL Compiler

◆ DBMS must be able to accept data definitions

(all schemas and associated mappings) in
source form and convert them to the
appropriate object form
◆ Sothe DBMS must include DDL processor or
DDL compiler components for each of the
various DDLs
◆ DDLcompiler also stores descriptions of the
schema (meta-data) in the data dictionary
18
 DBMS Component Module:
DDL Compiler
◆ Data Dictionary
◼ “raw data”+definitions of other objects in the system
◼ All schemas + mappings + all security and integrity
constraints (both source and object form)
◼ Much additional information
◆ For ex: which programs use which parts of the DB; which
user requires which reports etc.
◼ Dictionary can be queried just like any other DB
◆ For ex: it is possible to tell which programs and/or users
are likely to be affected by some proposed change to the
system
19
 Interfaces to a Data Dictionary
Database Application End Users
Administrators Programmers

Human Interfaces
Data Dictionary
Software and
DBMS Interfaces

Integrity
Compilers / Application Programs / Constraint
Precompilers Report Generators Enforcer

Both humans and software view and use data dictionary

Integrity, query processing, etc for software data entry,
and query formulation by humans
20
 DBMS Component Modules:
Runtime DB Processor

◆ Handles DB accesses at runtime

◆ Itreceives retrieval or update operations and
carries them out on the DB
◆ Access to disk goes through the stored data
manager, and the buffer manager keeps track
of the database pages in memory
◆ Ingeneral, DML requests can be planned/
unplanned
21
 DBMS Component Modules:
Runtime DB Processor

◆ Planned requests: operational or productions

applications
◆ Unplanned requests: decision support
applications
◼ The DBA will probably have tuned the physical DB
design in such a way as to guarantee good
performance for planned requests
◼ The physical DB design may or may not be well
suited for the specific request under consideration
22
 DBMS Component Modules: Query
Compiler
◆ Handles high-level quarries entered interactively
◆ Query compiler parses, analyzes, and compiles
or interprets a query by creating DB access
code, and then generates calls to the runtime
processor for executing the code
◆ Query Optimizer: determines an efficient way
of implementing the request
◆ Theoptimized requests are then executed
under the control of the run-time processor
23
 DBMS Component Modules:
Precompiler
◆ 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 DB access
◆ Therest of the program is sent to the host
language compiler
◆ The object codes for the DML commands and
rest of the program are linked, forming a canned
transaction whose executable code includes calls
to the runtime DB processor 24
“Two tier system” or “client-server”
◆ Clientprogram accesses the DBMS running on a
separate computer from the computer on which the
DB resides Three Tier
System
The client
accesses a
connection middle computer,
(ODBC), (JDBC) called the
application
server, which in
turn accesses the
DB server
Data files Database server
Applications
(someone else’s C program)
25
 DBMS Server
◆ Provides database query and transaction services
to the clients
◆ Relational DBMS servers - SQL servers, query
servers, or transaction servers
◆ Applications running on clients utilize an API
(Application Program Interface ) to access server
databases via standard interface
◼ 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 26
 Utilities

◆ Programs designed to help DBA with various

administration tasks
◼ Operate at the external level of the system: special
purpose applications
◼ Operate directly at the internal level of the system
(really part of the server); provided by vendor
◼ Not be provided by the DBMS vendor, but rather by
some third party

27
 Utilities – Some Examples
◼ Load routines: Loading data stored in files into a database.
Includes data conversion tools
◼ Dump/Restore routines: periodic database backup on tape
◼ Reorganization routines: to rearrange data in the stored DB
for various reasons (usually performance)
◆ For ex: to cluster data in some particular way on disk, or to
reclaim space occupied by logically deleted data
◼ Report generation utilities
◼ Performance monitoring or Statistical utilities
◼ Analysis routines: to analyze the statistics just mentioned
◼ Other functions, such as sorting, monitoring access by users,
data compression, etc.
28
 Classification of DBMSs
◼ Based on the data model used:
◆ Traditional: Relational, Network, Hierarchical
◆ Object-oriented, Object-relational
◆ NoSQL (“not only SQL” or “non-SQL”)
◼ 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)
29
 How the Programmer Sees the
DBMS
◆ Start with DDL to create tables:

CREATE TABLE Students (

Name CHAR(30)
Rollno CHAR(7) PRIMARY KEY NOT NULL,
Programme CHAR(20)
) ...

◆ Continue with DML to populate tables:

INSERT INTO Students
VALUES(‘Reema’, ‘2014301’, ‘undergraduate’)
. . . .
30
How the Programmer Sees the
DBMS
◆ Tables:
Students: Registers:
Rollno Name Programme Rollno Cid
2012001 Madhu undergrad 2014007 CS203
2015050 Rishi grad 2015001 ES103
… … 2015005 ES103
Courses: …
Cid Cname Semester
CS201 Database Design and odd
Management
CS306 Operating systems even
…… ……

◆Still implemented as files, but behind the scenes

can be quite complex
“data independence” = separate logical view
from physical implementation 31
 Transactions
◆ Enroll “Rakesh” in “DBMS”:
BEGIN TRANSACTION;

INSERT INTO Registers

SELECT Students.Rollno, Courses.Cid
FROM Students, Courses
WHERE Students.Name = ‘Rakesh’ and
Courses.Cname = ‘DBMS’

-- More updates here....

IF everything-went-OK
THEN COMMIT;
ELSE ROLLBACK
If system crashes, the transaction is still either committed or aborted 32
 Transactions
◆ A transaction = sequence of statements that either all
succeed, or all fail
◆ Transactions have the ACID properties:

A = atomicity (should be done or undone completely )

C = consistency (should transform a system from one
consistent state to another consistent
state)
I = isolation (each transaction should happen
independently of other transactions )
D = durability (completed transactions should remain
permanent)
33
 Queries
◆ Find all courses that “Rakesh” takes

SELECT C.name
FROM Students S, Registers R, Courses C
WHERE S.name=“Rakesh” and
S.Rollno = R.Rollno and R.Cid = C.Cid

◆ What happens behind the scene ?

◼ Query compiler figures out how to answer the
query efficiently

34
 DBMS Interfaces

◆ Stand-alone query language interfaces

◼ Example: Entering SQL queries at the DBMS
interactive SQL interface (e.g. SQL*Plus in
ORACLE)

◆ Programmerinterfaces for embedding DML in

programming languages

◆ User-friendly interfaces
◼ Menu-based, forms-based, graphics-based, etc.
35
 DBMS Programming Language
Interfaces
◆ Forembedding 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 for other programming languages
◼ Database Programming Language Approach:
e.g., ORACLE has PL/SQL, a programming
language based on SQL; incorporates SQL and its
data types as integral components
36
User-Friendly DBMS 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:
◆ For example, both menus and forms used extensively in
Web database interfaces
37
 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 user accounts, granting authorizations
◆ Setting system parameters

◆ Changing schemas or access paths

38