Database Concepts

and Architecture
Part I

August 5, 2019
 Database System Architecture
 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
 The framework presented here is not only the
single possibility
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
 precisely one “internal view”, representing the DB as stored
internally 4
 External (C) An Example
Struct employee corresponding
{ data items can External (COBOL)
char empno (6); have different
names at different
01 EMPC.
int salary;
} points 02 EMPNO PIC X(6)
- possible with the 02 DEPTNO PIC X(4)
Conceptual mapping
EMPLOYEE
EMPLOYEE_NUMBER CHARACTER (6)
DEPARTMENT_NUMBER CHARACTER (4)
SALARY INTEGER (5)
Internal control information
e.g., codes, flags, or pointers
STORED_EMPLOYEE BYTES=20
PREFIX BYTES=6, OFFSET=0
EMP# BYTES=6, OFFSET=6,INDEX=EMPX
DEPt# BYTES=4, OFFSET=12
PAY BYTES=4, ALIGN=FULLWORD, OFFSET=16
5
Detailed System Architecture

6
 The External Level (Individual User Level)

 Application programmer/end user

 Each user has a language at his/her disposal
 Application programmer: either a conventional programming
language (e.g. C, C++, or Java) or a proprietary language
 End user: either a query language or some special purpose
language (forms or menu driven online applications)
 Host language
 Responsible for providing various non-database facilities
 Data sublanguage (DSL) Ex: SQL
 Concerned specifically with database objects and operation
 Embedded within the corresponding host language
7
 The External Level (Contn…)

 A system might support any no. of host and DSL

 Distinction is for architectural purposes, for user they are not
distinct

 Each external view is defined by external schema

written using the DDL portion of the user’s DSL
 External schema consists definitions of each of the
various external record types in that external view
 In addition there must be a definition of the mapping
between the external schema and the underlying
conceptual schema
8
 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 9
 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
 Internal view 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
10
 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
 If the structure of the stored DB is changed, then the
mapping must be changed accordingly, so that the
conceptual schema can remain invariant
 Key for providing physical data independence
 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
11
 Mappings (2/2)
 External/conceptual mapping
 Correspondence b/w a particular external view and the
conceptual view
 Key for providing logical data independence
 Logical data independence
 The conceptual schema can be changed without affecting the
existing external schemas, or
 If 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
12
 Data Independence
 To achieve data independence
 Conceptual DDL definitions must not involve any
considerations of 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
13
 The Database Administrator
 DA is the person who makes the strategic and policy
decisions, and
 DBA is the person who provides the necessary
technical support for implementing those decisions
 DBA is responsible for the overall control of the system at a
technical level
 DBA’s Responsibilities
 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 14
 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 main job function 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 engineers, scientists, business analysts, and others who
thoroughly familiarize themselves with the facilities of the DBMS so as to
implement their applications to meet their 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 15
 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
16