Transcript 投影片 1

Database Systems
Chapter 2
Database System Concepts and
Architecture
主講人:陳建源
研究室 :法401
Email: [email protected]
日期:99/9/14
Outline







1. Data Models
2. Schemas vs Instances
3. Schema Architecture and Data Independence
4. Database Languages and Interfaces
5. The Database System Environment
6. DBMS Architectures
7. Classification of Database Management Systems
1. Data Models

Definition


A set of concepts to describe the structure of a
database, and certain constraints that the database
should obey
Most data models also include a set of basic
operations for specifying retrievals and updates on
the database
1. Data Models

Categories of data models

Conceptual (high-level, semantic) data models



Provide concepts that are close to the way many users
perceive data
e.g., Entity-relationship model, object data model
Physical (low-level, internal) data models

Provide concepts that describe details of how data is
stored in the computer
1. Data Models

Representational data models



Easily understood by end users
Also similar to how data organized in computer storage
Implementation (record-oriented) data models


Provide concepts that fall between the above two,
balancing user views with some computer storage details
e.g., relational model, hierarchical model, network model
1. Data Models



Entity
 Represents a real-world object or concept
Attribute
 Represents some property of interest
 Further describes an entity
Relationship among two or more entities
 Represents an association among the entities
 Entity-Relationship model
1. Data Models

History of data models

Relational Model



Proposed in 1970 by E.F. Codd (IBM)
First commercial system in 1981-82
e.g., ORACLE, SYBASE, SQL Server
1. Data Models
1. Data Models

Network Model



The first one to be implemented by Honeywell in 196465 (IDS System)
Adopted heavily due to the support by CODASYL
(CODASYL - DBTG report of 1971)
Later implemented in a large variety of systems - IDMS
(Cullinet - now CA), DMS 1100 (Unisys), IMAGE (H.P.),
VAX -DBMS (Digital)
1. Data Models
1. Data Models

Hierarchical Data Model



Implemented in a joint effort by IBM and North
American Rockwell around 1965
Resulted in the IMS family of systems
The most popular model
1. Data Models
1. Data Models

Object-oriented Data Models




Several models have been proposed for implementing in a
database system
One set comprises models of persistent O-O Programming
Languages such as C++ (e.g., in OBJECTSTORE or VERSANT),
and Smalltalk (e.g., in GEMSTONE)
Additionally, systems like O2, ORION (at MCC - then ITASCA),
IRIS (at H.P.- used in Open OODB)
Object Database Standard: ODMG-93, ODMG-version 2.0,
ODMG-version 3.0
1. Data Models

Object-Relational Models




Most recent trend, started with Informix Universal Server
Relational systems incorporate concepts from object
databases leading to object-relational
Exemplified in the latest versions of Oracle-10i, DB2,
and SQL Server and other DBMSs
Standards included in SQL-99 and expected to be
enhanced in future SQL standards
2. Schemas vs Instances

Database Schema




The description of a database
Includes descriptions of the database structure and
the constraints that should hold on the database
Can be displayed as a diagram (called schema
diagram)
Database schema changes very infrequently
2. Schemas vs Instances

Example schema diagram
2. Schemas vs Instances

Database Instance



The actual data stored in a database at a particular
moment in time
Also called database state (or occurrence)
The database state changes every time the database
is updated

e.g., insert or delete a record
2. Schemas vs Instances




Define a new database
 Specify database schema to the DBMS
Initial state
 Populated or loaded with the initial data
Valid state
 Satisfies the structure and constraints specified in
the schema
Schema evolution

Changes applied to schema as application requirements
change
2. Schemas vs Instances

Example database state
3. Schema Architecture
and Data Independence

Three-Schema Architecture

Internal schema



Describe data storage structures and access paths at the
internal level
Typically uses a physical data model
Conceptual schema


Describe the structure and constraints for the database at
the conceptual level
Uses a conceptual or an implementation data model
3. Schema Architecture
and Data Independence

External schemas



Describe the various user views at the external level
Usually uses the same data model as the conceptual level
Purposes


Support program-data independence
Support of multiple views of the data
3. Schema Architecture
and Data Independence
3. Schema Architecture
and Data Independence

Logical Data Independence



The capacity to change the conceptual schema
without having to change the external schemas and
their application programs
Only view definition and the mapping need be
change
e.g., Changing the Grade_Report
3. Schema Architecture
and Data Independence
3. Schema Architecture
and Data Independence

Physical Data Independence


The capacity to change the internal schema without
having to change the conceptual schema
e.g., providing an access path by Semester and Year
should not change query “list all sections offered in
fall 1998”
4. Database Languages and
Interfaces

Data Definition Language (DDL)



Used by the DBA and database designers to specify
the conceptual schema
In many DBMSs, DDL is also used to define
conceptual and external schemas (views)
In some DBMSs,


Internal: storage definition language (SDL)
External: view definition language (VDL)
4. Database Languages and
Interfaces
4. Database Languages and
Interfaces

Data Manipulation Language (DML)



Used to specify database retrievals and updates
DML commands (data sublanguage) can be
embedded in a general-purpose programming
language, such as COBOL, PL/1, C/C++
Alternatively, stand-alone DML commands can be
applied directly (query language)
4. Database Languages and
Interfaces

Example in SQL
SELECT
FROM
WHERE
BDATE, ADDRESS
EMPLOYEE
FNAME='John' AND MINIT='B'
AND LNAME='Smith'
4. Database Languages and
Interfaces

Example of embedded SQL
EXEC SQL
declare c cursor for
select customer-name, customer-city
from depositor, customer, account
where depositor.customer-name = customer.customername
and depositor account-number = account.accountnumber
and account.balance > :amount
END-EXEC
4. Database Languages and
Interfaces
Interfaces







Menu-based interfaces for Web clients or browsing
Forms-based interfaces
Graphical user interfaces
Natural language interfaces
Speech input and output
Interfaces for parametric users
Interfaces for the DBA
5. Database System Environment



DBMS component modules
Database system utilities
Tools


Application environment


CASE tools, data dictionary
e.g., PowerBuilder
Communication facilities
5. Database System Environment

DBMS component modules









Buffer management
Stored data manager
DDL compiler
Interactive query interface
• Query compiler
• Query optimizer
Precompiler
Runtime database processor
System catalog
Concurrency control system
Backup and recovery system
5. Database System Environment
5. Database System Environment





Database System Utilities
Loading
 Load existing data files
Backup
 Creates a backup copy of the database
Database storage reorganization
 Reorganize a set of database files into different file organizations
Performance monitoring
 Monitors database usage and provides statistics to the DBA
6. DBMS Architectures

Centralized DBMS


Combines everything into single system
including- DBMS software, hardware,
application programs, and user interface
processing software
User can still connect through a remote
terminal – however, all processing is done at
centralized site
6. DBMS Architectures

A physical centralized architecture
6. DBMS Architectures

Basic Client-Server Architectures

Specialized Servers with Specialized functions






Print server
File server
DBMS server
Web server
Email server
Clients can access the specialized servers as
needed
6. DBMS Architectures

Logical client-server architecture
6. DBMS Architectures

Two Tier Client-Server Architecture



A client program may connect to several
DBMSs, sometimes called the data sources
In general, data sources can be files or other
non-DBMS software that manages data
Other variations of clients are possible

in some object DBMSs, more functionality is
transferred to clients including data dictionary
functions, optimization and recovery across multiple
servers, etc.
6. DBMS Architectures

Three Tier Client-Server Architecture


Common for Web applications
Intermediate Layer called Application Server or Web
Server:



Stores the web connectivity software and the business logic
part of the application used to access data from database server
Acts like a conduit for sending partially processed data
between the database server and the client.
Three-tier Architecture Can Enhance Security


Database server only accessible via middle tier
Clients cannot directly access database server
6. DBMS Architectures

Logical three tier client-server architecture
7. Classification of DBMSs

Based on the data model used



Traditional: Relational, Network,
Hierarchical
Emerging: Object-oriented, Objectrelational
Based on the number of users


Single-user (typically used with microcomputers)
multi-user (most DBMSs)
7. Classification of DBMSs

Based on the number of sites


Centralized (uses a single computer with one
database)
Distributed (uses multiple computers, multiple
databases)


Homogeneous
Heterogeneous (Federated DBMS)
Summary





Concepts used in database systems
Main categories of data models
Types of languages supported by DMBSs
Interfaces provided by the DBMS
DBMS classification criteria:

Data model, number of users, number of sties, access
paths, cost