1 Database System Concepts Architecture

8/12/2019 1 Database System Concepts Architecture

1/59

D T B SE SYSTEMS

Nguyen Ngoc Thien An

DATABASE SYSTEM

CONCEPTS & ARCHITECTURE

Spring 2 14


2/59

Contents

Introduction

File-based Approach & Shared File Approach

Database Approach

Three-Schema Architecture & Data Independence Database Languages, Data Models, Database Schemas

& Database States

Classification of DBMS

Data Management Systems Framework

Reading Suggestion:[1] Chapter 1, Chapter 2

2


3/59

Introduction (1)3

Store textual or numericinformation

Traditionaldatabase

applications

Store images, audio clips, andvideo streams digitally

Multimediadatabases

Store & analyze maps, weatherdata, and satellite images

Geographicinformation

systems (GIS)


4/59

Introduction (2)4

Extract and analyze usefulbusiness information from verylarge databases

Support decision making

Datawarehouses &

Online analyticalprocessing

(OLAP) systems

Control industrial andmanufacturing processes

Real-time andactive databasetechnology


5/59

Contents

Introduction


Database Approach


& Database States



5


6/59

File-based Approach (1)6

Data is stored in one or more separate

computer files.

Data is then processed by computer programs

applications.


7/59

7


8/59


Problems/Limitations

Data Redundancy

Data Inconsistency


9/59


Customer

Orders

Customer File

Stock File

Order File

Customer

Invoicing

Customer File

Stock File

Order File

Purchase

Orders

Stock File

Supplier File

Stock

Control

Stock File

Order File

Customer File

Stock File

Order File

Supplier File

Customer

Orders

Customer

Invoicing

Purchase

Orders

Stock

Control

Applications ApplicationsFiles Files

Shared File Approach


10/59

Shared File Approach10

Data (files) is shared between different applications.

Data redundancy problem is alleviated.

Data inconsistency problem across different versions of thesame file is solved.

Other problems: Rigid data structure: If applications have to share files, the file

structure that suits one application might not suit another

Physical data dependency: If the structure of the data file needsto be changed in some way, this alteration will need to bereflected in all application programs that use that data file

No support of concurrency control: While a data file is beingprocessed by one application, the file will not be available forother applications or for ad hoc queries


11/59

Contents

Introduction


Database Approach


& Database States



11


12/59

Contents - Database Approach12

Database Approach

Overview

Data, Database & DBMS

Actors on the Scene

Workers behind the Scene

Characteristics of Database Approach

Advantages of Database ApproachHistory of Database Systems

When Not to Use a DBMS?


13/59

Overview of Database Approach (1)13

Arose because:

Definition of data was embedded in application

programs, rather than being stored separately

and independently.No control over access and manipulation of data

beyond that imposed by application programs.

Result:

The Database and Database Management

System (DBMS).


14/59

Overview of Database Approach (2)14


15/59

Data15

Known facts that can be recorded and that

have implicit meaning.

Information? Knowledge?

More: www.whatis.com


16/59

Database16

Shared collection of logically related data and adescription of this data. Logically related data comprises entities, attributes, and

relationships of an organizationsinformation.

System catalog (metadata) provides description of data toenable programdata independence.

Miniworldor universe of discourse(UoD): Represents some aspect of the real world.

Changes to the miniworld must be reflected in thedatabase as soon as possible.

Designed to meet the information needs of anorganization.

Example: Amazon.com


17/59

DBMSDefinitions17

DataBase Management System (DBMS)

A general-purpose software system thatfacilitates the processes of defining,constructing, manipulating, and sharingdatabases among various users andapplications.

Definition 1

A software system that enables users todefine, create, maintain, and control accessto the databases.

Definition 2


18/59

DBMSFunctions (1)18

Specify the data types, structures, and constraints ofthe data to be stored.

Meta-data:

Database definition or descriptive information. Stored by the DBMS in the form of a database

catalog or dictionary.

Defining a database

Store the data on some storage medium that iscontrolled by the DBMS.

Constructing a database

Query and update the database miniworld.

Generate reports.

Manipulating a database

Functions

of DBMS


19/59

DBMSFunctions (2)19

Allow multiple users and programs to access thedatabase simultaneously.

Sharing a database

System protection against hardware or softwaremalfunction (or crashes).

Security protectionagainst unauthorized or maliciousaccess.

Protecting a database

Allow the system to evolve as requirements changeover time.

Maintain a database

Functions

of DBMS


20/59

DBMSOther Conceptions20

Application program Accesses database by sending queries to DBMS.

Query Causes some data to be retrieved.

Transaction May cause some data to be read and some data to be written

into the database.

Controlled access to database may include: A security system

An integrity system

A concurrency control system

A recovery control system

A user-accessible catalog

Database System = the Database + DBMS software.


21/59

Database System Environment21


22/59

Example of Database: University22


23/59

Examples of Queries & Updates23

Examples of queries: Retrieve the transcript.

List the names of students who took the section of theDatabase course offered in fall 2008 and their grades inthat section.

List the prerequisites of the Databasecourse.

Examples of updates: Change the class of Smithto sophomore.

Create a new section for the Database course for this

semester. Enter a grade of Afor Smithin the Databasesection of

last semester.

Delete a canceled E-commercecourse in this semester.


24/59

Designing Database24

Phases for designing a database:

Requirements specification and analysis

Conceptual design

Logical design

Physical design


25/59

Actors on the Scene (1)25

Database Administrator (DBA) Authorize access to DB.

Coordinate and monitor its use.

Acquiring software and hardware resources.

Database Designers Identify the data to be stored in DB.

Choose appropriate structures to represent and store this data.

End Users People whose jobs require access to the database.

Types: Casual end users Naive or parametric end users

Sophisticated end users

Standalone users


26/59


System Analysts

Determine requirements of end users.

Application Programmers

Implement these specifications as programs.

More details: see [1] - 1.4


27/59



28/59

Workers behind the Scene28

DBMS system designersand implementers

Design and implement the DBMS modules and

interfaces as a software package

Tool developersDesign and implement tools.

Operatorsand maintenance personnel

Responsible for running and maintenance ofhardware and software environment for database

system.


29/59

Database Approach - Characteristics (1)29

Main Characteristics

of Database Approach

Self-describingnature of adatabasesystem

Insulation

betweenprogramsand data,and data

abstraction

Support ofmultipleviews of the

data

Sharing of

data andmultiusertransactionprocessing


30/59


Self-describing

nature of a DB

system

Database system

contains complete

definition of structure

and constraints.

Meta-data

Describes structure of

the database


31/59


Insulation between programs and data

Program-data independence: Structure of data files isstored in DBMS catalog separately from accessprograms.

Program-operation independence Data abstraction = Program-data independence +

Program-operation independence

Conceptual representation of data: does not include

details of how data is stored or how operations areimplemented.

Data model: Type of data abstraction used to provideconceptual representation.


32/59


Support of multiple views of the data

View

Subset of the database.

Contains virtual data derived from the database filesbut is not explicitly stored.

Multiuser DBMS

Users have a variety of distinct applications.

Must provide facilities for defining multiple views.


33/59


Sharing of Data and Multiuser Transaction Processing Allow multiple users to access the database at the same time.

Concurrency control software. Ensure that several users trying to update the same data do so in a

controlled manner.

Online transaction processing (OLTP) application. Transaction

Central to many database applications.

Executing program or process that includes one or more database.

Isolation property Each transaction appears to execute in isolation from other transactions.

Atomicity property Either all the database operations in a transaction are executed or none

are.


34/59

Database ApproachAdvantages (1)34

Controlling redundancy Data normalization

Denormalization Sometimes necessary to use controlled redundancy to improve the

performance of queries.

Restricting unauthorized access

Providing persistent storage for program objects

Impedance mismatch problem

Providing storage structures and search techniques for efficientquery processing

Indexes.

Buffering and caching. Query processing and optimization.

Providing backup and recovery

Providing multiple user interfaces


35/59

Database ApproachAdvantages (2)35

Representing complex relationships among data.

Enforcing integrity constraints

Referential integrity constraint

Key or uniqueness constraint

Business rules

Inherent rules of the data model Permitting inferencing and actions using rules

Deductive database systems

Trigger

Stored procedures

Reduced application development time Flexibility

Availability of up-to-date information

Economies of scale


36/59

History of Database Systems (1)36

First generation: Hierarchical & Network Databases

Second generation: Relational Databases

Providing data abstraction and application flexibility

Third generation: Object-Relational & Object-Oriented Databases

Used in specialized applications: engineering design, multimedia

publishing, and manufacturing systems. Others:

Interchanging data on the Web for e-commerce using XML

Extending database capabilities for new applications Extensions to better support specialized requirements for applications

Enterprise resource planning(ERP)

Customer relationship management (CRM)

Information retrieval(IR) Deals with books, manuscripts, and various forms of library-based articles



37/59

History of Database Systems (2)37


38/59

When Not to Use a DBMS?38

More desirable to use regular files for:

Simple, well-defined database applications not

expected to change at all.

Stringent, real-time requirements that may not bemet because of DBMS overhead.

Embedded systems with limited storage capacity.

No multiple-user access to data.



39/59

Contents

Introduction


Database Approach


& Database States



39


40/59

Objectives40

Objectives of

Three-Schema Architecture

All usersshould beable to

access samedata.

Users should

not need toknowphysicaldatabasestoragedetails.

DBA shouldbe able to

changedatabasestorage

structureswithout

affecting theusers views.

Internalstructure of

databaseshould beunaffectedby changesto physicalaspects ofstorage.

DBA shouldbe able to

changeconceptualstructure ofdatabasewithout

affecting allusers.


41/59

Three-Schema Architecture (1)41

View 1View 1View 1

Conceptual Schema

Internal Schema

External level

Conceptual level

Internal level

Physical data

organization

.

Stored Database

External/Conceptual

Mapping

Conceptual/Internal

Mapping

End

Users


42/59


External LevelUsersview of the database.

Describes part of the database that a particular user groupis interested in.

Conceptual Level Describes structure of the whole database for a communityof users.

Describes what data is stored in database andrelationships among the data.

Internal Level Physical representation of the database on the computer.

Describes physical storage structure of the database (howthe data is stored in the database).


43/59



44/59

Data Independence (1)44

Data Independence is the capacity to change theschema at one level of a database system withouthaving to change the schema at the next higher level. Logical Data Independence

Refers to immunity of external schemas to changes in

conceptual schema. Conceptual schema changes (e.g. addition/removal of entities)

should not require changes to external schema or rewrites ofapplication programs.

Physical Data Independence

Refers to immunity of conceptual schema to changes in theinternal schema.

Internal schema changes (e.g. using different fileorganizations, storage structures/devices) should not requirechanges to conceptual or external schemas.


45/59

Data Independence (2)45


46/59

Contents

Introduction


Database Approach


& Database States



46


47/59

Database Languages (1)47

Data Definition Language (DDL) allows the DBAor user to describe and name entities, attributes,and relationships required for the application plusany associated integrity and security constraints.

In most DBMSs, the DDL is used to define bothconceptual and external schemas.

Data Manipulation Language (DML) providesbasic data manipulation operations (retrieval,insertion, deletion, modification).

Data Control Language (DCL) defines activitiesthat are not in the categories of those for the DDLand DML, such as granting privileges to users,and defining when proposed changes to adatabases should be irrevocably made.


48/59

Database Languages (2)48

Data Manipulation Language (DML) Procedural DML: allows user to tell system exactly howto

manipulate data (e.g., Network and hierarchical DMLs).

Non-Procedural DML (Declarative language) allows user tostate what data is needed rather than how it is to be

retrieved (e.g., SQL, QBE). Fourth Generation Languages (4GLs)

Non-procedural languages: SQL, QBE, etc.

Application generators, report generators, etc.

See more in [1] - 2.3 for: Storage definition language (SDL).

View definition language (VDL).


49/59

Data Models (1)49

Data Model: An integrated collection ofconcepts for describing data, relationshipsbetween data, and constraints on the data inan organization.

Provides means to achieve data abstraction.

Basic operations

Specify retrievals and updates on the database.

Dynamic aspect or behavior of a databaseapplication

Allows the database designer to specify a set ofvalid operations allowed on database objects.


50/59

Data Models (2)50

Categories of data models include: Object-based (Conceptual/High-level) Close to the way many users perceive data.

E.g.: Entity-Relationship model, Object-Oriented,

Record-based (Representational) Easily understood by end users.

Also similar to how data organized in computerstorage.

E.g.: Relational, Network, Hierarchical

Physical (Low-level): Used to describe data at the internal level.

Describes how data is stored as files in thecomputer.

E.g.: Access path, Index

Describe

data at the

conceptual

& external

levels


51/59

Database Schemas (1)51

Database Schema: the description of a database, which isspecified during database design and is not expected tochange frequently. Defining a new database is specifying database schema to the

DBMS

Schema Diagram: displays selected aspects of schema. Database State (Snapshot): the data in the database at a

particular moment in time. Initial state: Populated or loaded with the initial data.

Valid state: Satisfies the structure and constraints specified in theschema.

Schema Evolution Changes applied to schema as application requirements change.


52/59

Database Schemas (2)52


53/59

Contents

Introduction


Database Approach


& Database States



53


54/59

Classification of DBMS54

DBMS

Data model

Relational

Object

Hierarchical& network

Native XMLDBMS

Number ofusers

Single-user

Multiuser

Number ofsites

Centralized Distributed

Homogeneous

Heterogeneous

Cost

Opensource

Differenttypes of

licensing

Types ofaccess path

options

General orspecial-purpose


55/59

Contents

Introduction


Database Approach


& Database States



55


56/59

Data Management Systems Framework (1)

56

Where are we?

Application Layer

Visualization, Collaborative Computing, Mobile Computing,Knowledge-based Systems

Data Management Layer

Layer 3: information extraction & sharing

Data Warehousing, Data Mining, Internet DBs, Collaborative, P2P& Grid Data Management

Layer 2: interoperability & migration

Heterogeneous DB Systems, Client/Server DBs, Multimedia DBSystems, Migrating Legacy DBs

Layer 1: DB technologies

DB Systems, Distributed DB Systems

Supporting Layer

Networking, Mass Storage, Agents, Grid Computing Infrastructure,

Parallel & Distributed Processing, Distributed Object Management


57/59

Data Management Systems Framework (2)

57

Extending database capabilities for new applications: Example applications: storage and retrieval of images,

videos, data mining (large amounts of data need to bestored and analyzed), spatial databases, time seriesapplications,

More complex data structures than relationalrepresentation.

New data types except for the basic numeric and characterstring types.

New operations and query languages for new data types.

New storage and retrieval methods. New security mechanisms.


58/59

Contents

Introduction


Database Approach

Three-Schema Architecture & Data Independence

Database Languages, Data Models, Database Schemas &Database States



Read more:

The Database System Environment: [1] 2.4

Centralized and Client/Server Architectures for DBMSs: [1] - 2.5

58


59/59

Q & A59

Documents

1 Database System Concepts Architecture