Database Systems 主講人 : 陳建源 日期 :99/9/14 研究室 : 法 Chapter 2 Database System Concepts and Architecture

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 e.g., ORACLE, SYBASE, SQL Server

1. Data Models

Network Model The first one to be implemented by Honeywell in (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

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

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 O 2, 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

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

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

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” 3. Schema Architecture and Data Independence

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

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 BDATE, ADDRESS FROM EMPLOYEE WHEREFNAME='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.customer- name and depositor account-number = account.account- number and account.balance > :amount END-EXEC 4. Database Languages and 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 4. Database Languages and Interfaces Interfaces

5. Database System Environment DBMS component modules Database system utilities Tools CASE tools, data dictionary Application environment 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

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

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 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 6. DBMS Architectures

Based on the data model used Traditional : Relational, Network, Hierarchical Emerging: Object-oriented, Object- relational Based on the number of users Single-user (typically used with micro- computers) 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) 7. Classification of DBMSs

 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 Summary