Professional Documents
Culture Documents
Database system
Concepts and Architecture
1
Database Systems
Database system consists of logically related
data stored in a single logical data repository
May be physically distributed among multiple
storage facilities
DBMS eliminates most of file system’s problems
Current generation stores data structures,
relationships between structures, and access paths
Also defines, stores, and manages all access paths and
components
2
The Database System
Environment
Database system: defines and regulates the
collection, storage, management, use of data
Five major parts of a database system:
Hardware
Software
People
Procedures
Data
3
The Database System
Environment (cont'd.)
Hardware: all the system’s physical
devices
Software: three types of software
required:
Operating system software
DBMS software
Application programs and utility software
4
The Database System Environment (cont'd.)
5
The Database System
Environment (cont'd.)
Database systems are created and
managed at different levels of complexity
Database solutions must be cost-effective
as well as tactically and strategically
effective
Database technology already in use
affects selection of a database system
6
Types of Databases
Databases can be classified according to:
Number of users
Database location(s)
Expected type and extent of use
Single-user database supports only one user at
a time
Desktop database: single-user; runs on PC
Multiuser database supports multiple users at
the same time
Workgroup and enterprise databases
7
Types of Databases (cont’d.)
Centralized database: data located at a single site
Distributed database: data distributed across
several different sites
Operational database: supports a company’s day-
to-day operations
Transactional or production database
Data warehouse: stores data used for tactical or
strategic decisions
8
Types of Databases (cont'd.)
Unstructured data exist in their original state
Structured data result from formatting
Structure
applied based on type of processing to be
performed
Semistructured data have been processed to some
extent
Extensible Markup Language (XML) represents
data elements in textual format
XML database supports semistructured XML data
9
Database abstraction
Data abstraction refers to, providing only
essential information to the outside world and
hiding their background details, i.e., to represent
the needed information in program without
presenting the details.
Data abstraction is a programming (and design)
technique that relies on the separation of
interface and implementation.
Data abstraction is usually the first step in
database design. Data abstraction makes it
possible for the developer to start from essential
elements
10
Database languages
Data Definition Language (DDL):
Language used to define each data
element required by the organization.
Commands for setting up schema or the
intension of database
These commands are used to setup a
database, create, delete and alter table with
the facility of handling constraints
are used to define the database structure or
schema. 11
Examples
CREATE - to create objects in the database
ALTER - alters the structure of the database
DROP - delete objects from the database
TRUNCATE - remove all records from a
table, including all spaces allocated for the
records are removed
COMMENT - add comments to the data
dictionary
RENAME - rename an object
12
Data Manipulation Language (DML):
14
Data control languages
GRANT - gives user's access privileges
to database
REVOKE - withdraw access privileges
given with the GRANT command
15
Database Architecture
The design of a Database Management
System highly depends on its architecture.
It can be centralized or decentralized or
hierarchical.
DBMS architecture can be seen as single
tier or multi tier.
n-tier architecture divides the whole
system into related but independent n
modules, which can be independently
modified, altered, changed or replaced.
16
3-tier architecture
Most widely used architecture is 3-tier
architecture. 3-tier architecture separates it
tier from each other on basis of users. It is
described as follows:
17
Cont…
Database (Data) Tier: At this tier, only database
resides. Database along with its query processing
languages sits in layer-3 of 3-tier architecture.
Application (Middle) Tier: At this tier the application
server and program, which access database,
resides. For a user this application tier works as
abstracted view of database. Users are unaware of
any existence of database beyond application.
User (Presentation) Tier: An end user sits on this
tier. At this layer multiple views of database can be
provided by the application. All views are generated
by applications, which reside in application tier.
18
3 Levels of Abstraction
Physical or Internal Level
Lowest level of abstraction describes how data are
actually stored
Describes complex low-level data structures in detail
Logical or Conceptual Level
Describes what data are stored in the DB & what
relationships exist among those data
Describes the entire DB in terms of relatively simpler
structures
View or External Level
Highest level of abstraction which describes only a part
of the DB
User’s view of the DB. This level describes that part of
the DB that is relevant to each user
19
Levels of Abstraction
20
ANSI/SPARC 3-Tier Architecture
21
ANSI/SPARC 3-Tier Architecture
Conceptual/
Logical Level Conceptual Schema
Database
22
Data Independence
The ability to modify a schema definition in
one level with out affecting a scheme
definition in the next higher level is called DI
Major objective of the 3-tier architecture is
to proved data independence (DI)
Upper levels are unaffected by changes at
the lower level
Two kinds of DI:
LogicalDI
Physical DI
23
Data Independence
Logical DI
resistance of the external schemas to
changes in the conceptual schema
Addition or removal of entities, attributes, or
relationships, should be possible without
having to change the external schemas or
having to rewrite the application programs
24
Data Independence
Physical DI
resistance of the conceptual schema to
changes in the internal schema
Using different file organizations or storage
structures, using different storage devices,
modifying indexes, or changing hashing
algorithms should be possible without having to
change the upper schemas
Deterioration in performance is the most
common reason for internal schema changes
25