Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Chapter 1 Introduction: Databases and Database Users Modified by Dr. Hsiang-Fu Yu National Taipei

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Chapter 1

Introduction: Databases and Database Users

Modified by Dr. Hsiang-Fu Yu

National Taipei University of Education

2011 for 6th Edition

Slide 1- 2Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Outline

Types of Databases and Database Applications Basic Definitions Typical DBMS Functionality Example of a Database (UNIVERSITY) Main Characteristics of the Database Approach Database Users Advantages of Using the Database Approach A Brief History of Database Applications When Not to Use Databases


Types of Databases and Database Applications

Traditional Applications Numeric and Textual Databases

More Recent Applications Multimedia Databases Geographic Information Systems (GIS) Data Warehouses and OnLine Analytical

Processing (OLAP) systems Real-time and Active Databases Many other applications


Basic Definitions

Database A collection of related data. Represents some aspect of the real world. Logically coherent collection of data with inherent meaning. Built for a specific purpose.

Data Known facts that can be recorded and have an implicit meaning.

Mini-world or universe of discourse (UoD) Some part of the real world about which data is stored in a

database. For example, student grades and transcripts at a university.


Basic Definitions (cont.)

Database Management System (DBMS) A software package/system to facilitate the creation

and maintenance of a computerized database. Database System

The DBMS software together with the data itself. Sometimes, the applications are also included.


Simplified database system environment


Typical DBMS Features

Defining a database Specify the data types, structures, and constraints of the

data to be stored. Meta-data

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

dictionary. Manipulating a database

Query and update the database. Generate reports.

Sharing a database Allow multiple users and programs to access the database

simultaneously.


Typical DBMS Features (cont.)

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. Protection

System protection Security protection


Typical DBMS Features (cont.)

Maintain the database system Allow the system to evolve as requirements

change over time. Maintain the database and associated programs

over the lifetime of the database application.


Example of a Database(with a Conceptual Data Model)

Mini-world for the example: Part of a UNIVERSITY environment.

Data records (some mini-world entities): STUDENTs COURSEs SECTIONs (of COURSEs) GRADE_REPORT PREREQUISITE



Example of a Database (cont.)

Phases for designing a database: Requirements specification and analysis Conceptual design Logical design Physical design

Construct UNIVERSITY database Store data to represent each student, course,

section, grade report, and prerequisite as a record in appropriate file.

Relationships among the records


Example of a Database (cont.)

Manipulation involves querying and updating Examples of queries:

Retrieve the transcript. List the names of students who took the section of the

‘Database’ course offered in fall 2008 and their grades in that section.

List the prerequisites of the ‘Database’ course. Examples of updates:

Change the class of ‘Smith’ to sophomore. Create a new section for the ‘Database’ course for this

semester. Enter a grade of ‘A’ for ‘Smith’ in the ‘Database’ section of last

semester.


Main Characteristics of the Database Approach

Self-describing nature of a database system Insulation between programs and data, and data

abstraction Support of multiple views of the data Sharing of data and multi-user transaction

processing


Self-describing Nature of a Database System

Database system contains complete definition of structure and constraints.

A DBMS catalog stores the description of a particular database (e.g. data structures, types, and constraints).

The description is called meta-data, describing structure of the database.

This allows the DBMS software to work with different database applications.

The database catalog used by: DBMS software Database users who need information about database

structure


Insulation between Programs and Data

Program-data independence Structure of data files is stored in DBMS catalog separately

from access programs. Program-operation independence

Operations (or methods for object class) specified in two parts:

Interface includes operation name and data types of its arguments.

Implementation can be changed without affecting the interface.

The application programs can operate on the data by invoking the operations through their names and arguments, regardless of how the operations are implemented.


Example of a Simplified Database Catalog


Data Abstraction

The characteristic that allows program-data independence and program-operation independence

Conceptual representation of data Does not include details of how data is stored or how

operations are implemented Data model

Type of data abstraction used to provide conceptual representation

To hide storage details and present the users with a conceptual view of the database

Programs refer to the data model constructs rather than data storage details.


Support of Multiple Views of the Data

Each user may see a different view of the database, which describes only the data of interest to that user.

View Subset of the database Contains virtual data derived from the database

files but is not explicitly stored Multi-user DBMS

Users have a variety of distinct applications. Must provide facilities for defining multiple views.


Sharing of Data and Multi-user 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 Result of the updates is correct

OnLine Transaction Processing (OLTP) is a major part of database applications. This allows hundreds of concurrent transactions to execute per second.


Sharing of Data and Multi-user Transaction Processing (cont.)

A Transaction is An execution program or process that includes one or more

database accesses, such as reading or updating. Supposed to execute a logically correct database access if

executed in its entirety without interference from other transactions.

A DBMS must enforce following transaction properties Isolation

Each transaction appears to execute in isolation from other transactions.

Atomicity Either all the database operations in a transaction are

executed or none are.


Sharing of Data and Multi-user Transaction Processing (cont.)

Concurrency control within the DBMS guarantees that each transaction is correctly executed or aborted.

Recovery subsystem ensures each completed transaction has its effect permanently recorded in the database.


Database Users

Users may be divided into Those who actually use and control the database

content, and those who design, develop and maintain database applications (called “Actors on the Scene”), and

Those who design and develop the DBMS software and related tools, and the computer systems operators (called “Workers Behind the Scene”).


Actors on the Scene

Database Administrators Authorizing access to the database Coordinating and monitoring its use Acquiring software and hardware resources Monitoring efficiency of operations

Database Designers Define the content, the structure, the constraints, and

functions or transactions against the database. Communicate with the end-users and understand their

needs.


Actors on the Scene (cont.)

End-users People whose jobs require access to the database types

Casual: access database occasionally when needed Naive or Parametric: they make up a large section

of the end-user population. They use previously well-defined functions in the form of

“canned transactions” against the database. Examples are bank-tellers or reservation clerks who do

this activity for an entire shift of operations.


Types of End-users (cont.)

Sophisticated: These include business analysts, scientists, engineers,

others thoroughly familiar with the system capabilities. Many use tools in the form of software packages that work

closely with the stored database. Stand-alone:

Mostly maintain personal databases using ready-to-use packaged applications.

An example is a tax program user that creates its own internal database.

Another example is a user that maintains an address book


Actors on the Scene (cont.)

System Analysts Determine requirements of end users.

Application Programmers (Software Engineers) Implement these specifications as programs.


Workers behind the Scene

DBMS System Designers and Implementers Design and implement the DBMS modules and interfaces

as a software package. Tool Developers

Design and implement tools – the software packages that facilitate database modeling and design, database system design, and improved performance.

Operators and Maintenance Personnel Responsible for the actual running and maintenance of the

hardware and software environment for the database system


Advantages of Using the DBMS Approach

Controlling redundancy Redundancy leads to

Duplication effort Wasted storage spaces Inconsistency

Data normalization Denormalization

Sometimes necessary to use controlled redundancy to improve the performance of queries

Restricting unauthorized access to data Security and authorization subsystem Privileged software


Advantages of Using the DBMS Approach (cont.)

Providing persistent storage for program objects Complex object in C++ can be stored permanently

in an object-oriented DBMS. To avoid the impedance mismatch problem in

object-oriented DBMS The data structures provided by the DBMS are

incompatible with the programming language’s data structures.



Providing storage structures and search techniques for efficient query processing Indexes Buffering and caching Query processing and optimization

Providing backup and recovery services Providing multiple user interfaces Representing complex relationships among data



Enforcing integrity constraints on the database Integrity Constraints

保持資料對人而言在語意上正確 Referential integrity constraint

Every section record must be related to a course record

Key or uniqueness constraint Every course record must have a unique value for

Course_number Business rules Inherent rules of the data model



Permitting inferencing and actions using rules Deductive database systems

Provide capabilities for defining deduction rules. Inference new information from the stored database

facts. Trigger

Rule activated by updates to the table Stored procedures

More involved procedures to enforce rules


Additional Implications of Using the DBMS Approach

Potential for enforcing standards This is very crucial for the success of database

applications in large organizations. Standards refer to data item names, display

formats, screens, report structures, meta-data (description of data), Web page layouts, etc.

Reduced application development time Incremental time to add each new application is

reduced.


Additional Implications of Using the Database Approach (continued)

Flexibility to change data structures Database structure may evolve as new

requirements are defined. Availability of current information

Extremely important for on-line transaction systems such as airline, hotel, car reservations.

Economies of scale Wasteful overlap of resources and personnel can

be avoided by consolidating data and applications across departments.


A Brief History of Database Applications

Early Database Applications The Hierarchical and Network Models were introduced in mid

1960s and dominated during the seventies. A bulk of the worldwide database processing still occurs using

these models, particularly, the hierarchical model. Providing data abstraction and application flexibility with

relational databases Relational model was originally introduced in 1970, was heavily

researched and experimented within IBM Research and several universities.

Relational DBMS Products emerged in the early 1980s. Separate physical storage of data from its conceptual

representation. Provide a mathematical foundation for data representation and

querying.


A Brief History of Database Applications (cont.)

Object-oriented applications and the need for more complex databases

Object-Oriented Database Management Systems (OODBMSs) were introduced in late 1980s and early 1990s to cater to the need of complex data processing in CAD and other applications.

Their use has not taken off much. Used in specialized applications: engineering design,

multimedia publishing, and manufacturing systems. Many relational DBMSs have incorporated object database

concepts, leading to a new category called object-relational DBMSs (ORDBMSs)


A Brief History of Database Applications (cont.)

Interchanging data on the Web for e-commerce using XML Extended markup language (XML) primary standard for

interchanging data among various types of databases and Web pages

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

applications Enterprise resource planning (ERP) Customer relationship management (CRM)

Databases versus information retrieval Information retrieval (IR)

Deals with books, manuscripts, and various forms of library-based articles


Database vs. File-processing

Traditional file processing Each user defines and implements the files needed

for a specific software applications as part of programming the application.

Database approach Single repository maintains data that is defined

once and then accessed by various users.


When not to use a DBMS

Main overhead costs of using a DBMS High initial investment and possible need for

additional hardware. The generality that a DBMS provides for defining

and processing data Overhead for providing security, concurrency

control, recovery, and integrity functions.


When not to use a DBMS (cont.)

A DBMS may be unnecessary when Simple, well-defined database applications not expected to

change at all Stringent, real-time requirements that may not be met

because of DBMS overhead Embedded systems with limited storage capacity No multiple-user access to data

When no DBMS may suffice If the database system is not able to handle the complexity

of data because of modeling limitations If the database users need special operations not supported

by the DBMS.


Summary

Types of Databases and Database Applications Basic Definitions Typical DBMS Functionality Example of a Database (UNIVERSITY) Main Characteristics of the Database Approach Database Users Advantages of Using the Database Approach When Not to Use Databases

Documents

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Chapter 1 Introduction: Databases and Database Users Modified by Dr. Hsiang-Fu Yu National Taipei