CO312: Database Systems

References

• Ramez Elmasri and Shamkant B. Navathe, Fundamentals of Database Systems, 5th Edition, 2007

• Raghu Ramakrishnan and Johannes Gehrke, Database Management Systems, 3rd Edition, McGraw-
Hill, 2004

Topics

• Introduction

– Information models and systems, Database system evolution, File based systems, DBMS ap-
proach, Database environment and components, DBMS functions, DBMS architecture, Data
independence
• Data modeling

– Motivation, Roll in system development, Levels of abstraction and practice, Conceptual mod-
els; ER and UML, Logical models; Relational and OO models
• RDBMS Concepts
– Relational algebra and relational calculus, Relational integrity, Normalization, Object oriented
extensions
• Database Query Languages
– 4GL environments, SQL, DDL, DML and DCL, Query optimization, Rule based and cost
based approaches, Embedded SQL

• Transaction Processing
– Transactions, Concurrency control, Serialization, Failure and recovery
• Distributed Databases
– Data fragmentation, Replication and allocation, Distributed query processing, Distributed
transaction model, Concurrency control, Homogeneous and heterogeneous environments
• Physical Database Design
– Storage and file structures, indexed, hashed and signature files, B-trees, Sparse and dense
indexes, Variable length records, Database tuning

1
1 Introduction to Database Systems
1.1 Definitions

Data
Refers to known facts that can be recorded and have an implicit meaning.

Database
A collection of related data with the following properties
• Intended application and users, i.e., specific purpose
• Represents some aspects of the real world

• Logically organized

Database Management System (DBMS)

• A software package/ system to facilitate the creation and maintenance of a computerized database.

• The operations supported by a DBMS include:

– Defining the database specify types of data and relationships (files/records/fields/physical &
logical links)
– Constructing database: the process of storing data
– Manipulating the database i.e. query, update (insert/delete/modify), generate reports

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

1.2 DBMS Functions

Typical DBMS Functionality

• Define a database
– in terms of data types, structures and constraints
• Construct or Load the Database on a secondary storage medium

• Manipulating the database

– querying, generating reports, insertions, deletions and modifications to its content
• Concurrent Processing and Sharing by a set of users and programs - yet, keeping all data valid and
consistent

• Other features:

– Protection or Security measures to prevent unauthorized access

– Active processing to take internal actions on data
– Presentation and Visualization of data

2
1.3 Database Environment
A simplified database system environment

Figure 1: A simplified database system environment

1.4 Example
Example: UNIVERSITY database

data elements
Name, StudentNumber, Class, Major

data type
STUDENT (Name : string, StudentNumber : integer) GRADE REPORT (Grade: single character)

3
 Figure 2: Example: UNIVERSITY database

1.5 File based Systems vs. Database Approach

Database Approach vs. Traditional File Processing

• Traditional File Processing System

– each group of users has its own data files and application programs for that specific data file
Example
∗ Payroll Dept. Staff Salary (Staff Number, First Name, Last Name, Address, Sex,Date of Birth, Salary, PIN, Department)
∗ Personnel Dept. Staff (Staff Number, First Name, Last Name, Address, Telephone Number, Position, Sex, Date of Birth, Salary, PIN, Department)
∗ Both the Payroll department and the Personnel Department stored similar data items.

Problems With Traditional File Processing

• Redundant data
• Wasted storage space
• Inconsistent data
• Difficult to add/modify applications
• File structure is part of the code

The Database Approach

• In the database approach

– There is a single repository of data that is defined once and accessible to all users.
• The database is self-describing collection of data. The database includes:
– Data
– Meta data (data that describes the structure of the database), stored in a DBMS catalog
containing
∗ Storage format
∗ File structure
∗ Data format
∗ Constraints

4
Main Characteristics of the Database Approach

• Self-describing nature of a database system

– A DBMS catalog stores the description of the database (meta-data). This allows the DBMS
software to work with different databases. e.g. a university database, a banking database or
a company database as long as the database definition is stored in the catalog.

• Insulation between programs and data

– This is called program-data independence. It allows changing data storage structures and
operations without having to change the DBMS access programs.

• Data Abstraction
– A data model is used to hide storage details and present the users with a conceptual view of
the database.

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

• Sharing of data and multiuser transaction processing

– This allows a set of concurrent users to retrieve and to update the database. Concurrency
control within the DBMS guarantees that each transaction is correctly executed or completely
aborted. OLTP (Online Transaction Processing) is a major part of database applications.

Database Users

• Users may be divided into

– those who actually use and control the content (called Actors on the scene).
– those who enable the database to be developed and the DBMS software to be designed and
implemented (called Workers behind the scene).

Actors on the scene

• Database administrators
– responsible for authorizing access to the database, for coordinating and monitoring its use,
acquiring software, and hardware resources, controlling its use and monitoring efficiency of
operations.
• Database Designers

– responsible to define the content, the structure, the constraints, and functions or transactions
against the database. They must communicate with the end-users and understand their needs.
• End-users

– they use the data for queries, reports and some of them actually update the database content.
• System Analysts and Application programmers (Software Engineers)
– Design and implement canned transactions for parametric users.

5
Categories of End-users

• Casual Users
– who access database occasionally when needed
• Naı̈ve 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.

• Sophisticated user
– these include business analysts, scientists, engineers, others thoroughly familiar with the sys-
tem capabilities. Many use tools in the form of software packages that work closely with the
stored database.
• Stand-alone users
– mostly maintain personal databases using ready-to-use packaged applications. An example is
a tax program user that creates his or her own internal database.

Workers behind the scene

• DBMS designers and implementers

– They design and implement the DBMS software package itself.

• Tool developers
– They design and implement tools that facilitate the use of the DBMS software. Tools include
design tools, performance tools, special interfaces, etc.
• Operators and maintenance personnel

– They work on running and maintaining the hardware and software environment for the
database system.

Advantages the Database Approach

• Controlling redundancy in data storage and in development and maintenance efforts.

• Restricting unauthorized access to data.

• Providing Storage Structures for efficient Query Processing, e.g., indexes
• Providing backup and recovery services.

• Providing multiple interfaces to different classes of users.

• Representing complex relationships among data.

• Enforcing integrity constraints on the database.

• Drawing Inferences and Actions using rules, e.g., triggers and stored procedures.

6
Implications of Using the Database 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 etc.
• Reduced application development time : incremental time to add each new application is reduced.

• Flexibility to change data structures : database structure may evolve as new requirements are
defined.

• Availability of up-to-date information : very important for on-line transaction systems such as
airline, hotel, car reservations.
• Economies of scale : by consolidating data and applications across departments wasteful overlap
of resources and personnel can be avoided.

1.6 Database System Evolution

Historical Development

• Early Database Applications

– The Hierarchical and Network Models were introduced in mid 1960’s and dominated during
the seventies.
– New queries were difficult to implement.

• Relational Model based Systems

– The relational model was introduced in 1970 and a dominent database system for traditional
database applications.

• Object-oriented applications
– OODB’s were introduced in late 1980’s and early 1990’s to cater to the need of complex data
processing needs arised with the emergence of OO programming languages.
– They are mainly used in appplications such as engineering design, multimedia publishing and
manufacturing systems.
• Data on the Web and E-commerce Applications
– Web contains data in HTML (Hypertext markup language) with links among pages.
– This has given rise to a new set of applications and E-commerce is using new standards like
XML (eXtendedMarkup Language).

• Extending Database Capabilities for New Applications

– Scientific applications: need to store large amounts of data from scientific experiments.
– Multimedia retrieval (images, videos)
– Data mining: searching for specific patterns or relationships.
– Spatial applications: need to store spatial location data such as weather information or maps.
– Time series applications: e.g. need to store economic data at regular points in time.

7
When not to use a DBMS

• Main costs of using a DBMS:

– High initial investment and possible need for additional hardware.
– Overhead for providing generality, security, concurrency control, recovery, and integrity func-
tions.

• When a DBMS may be unnecessary:

– If the database and applications are simple, well defined, and not expected to change.
– If there are stringent real-time requirements that may not be met because of DBMS overhead.
– If access to data by multiple users is not required.

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

1.7 Database Architecture

Data Model
A set of concepts to describe the structure of a database, and certain constraints that the database
should obey.

Data Model Operations

Operations for specifying database retrievals and updates by referring to the concepts of the data model.
Operations on the data model may include basic operations and user-defined operations.

Categories of data models

Conceptual (high-level, semantic) data models
Provide concepts that are close to the way many users perceive data. (Also called entity-based or
object-based data models.)

Physical (low-level, internal) data models

Provide concepts that describe details of how data is stored in the computer.

Implementation (representational) data models

Provide concepts that fall between the above two, balancing user views with some computer storage
details.

Schemas versus Instances

• Database Schema : The description of a database. Includes descriptions of the database structure
and the constraints that should hold on the database.

• Schema Diagram : A diagrammatic display of (some aspects of) a database schema.

• Schema Construct : A component of the schema or an object within the schema, e.g., STUDENT,
COURSE.
• Database Instance : The actual data stored in a database at a particular moment in time. Also
called database state (or occurrence).

8
 Figure 3: The three-schema architecture

Database Schema Vs. Database State

• Database State : Refers to the content of a database at a moment in time.

• Initial Database State : Refers to the database when it is loaded.
• Valid State : A state that satisfies the structure and constraints of the database.
• Distinction
– The database schema changes very infrequently. The database state changes every time the
database is updated.

1.8 The Three-Schema Architecture

Three-Schema Architecture

• Proposed to support DBMS characteristics of:

– Program-data independence.
– Support of multiple views of the data.

• Defines DBMS schemas at three levels:

– Internal schema at the internal level to describe physical storage structures and access paths.
Typically uses a physical data model.
– Conceptual schema at the conceptual level to describe the structure and constraints for the
whole database for a community of users. Uses a conceptual or an implementation data model.
– External schemas at the external level to describe the various user views. Usually uses the
same data model as the conceptual level.

Mappings among schema levels are needed to transform requests and data. Programs refer to an
external schema, and are mapped by the DBMS to the internal schema for execution.

9
1.9 Data Independence

Logical Data Independence

The capacity to change the conceptual schema without having to change the external schemas and their
application programs.

Physical Data Independence

The capacity to change the internal schema without having to change the conceptual schema.
When a schema at a lower level is changed, only the mappings between this schema and higher-level
schemas need to be changed in a DBMS that fully supports data independence. The higher-level schemas
themselves are unchanged. Hence, the application programs need not be changed since they refer to the
external schemas.

1.10 Database languages and Interfaces

DBMS Languages

• Data Definition Language (DDL): Used to specify the conceptual schema of a database. In many
DBMSs, the DDL is also used to define internal and external schemas (views).
• Separate storage definition language (SDL): Used to specify the internal schma.
• View definition language (VDL): Used to define internal and external schemas.

• Data Manipulation Language (DML): Used to specify database retrievals and updates.
– DML commands (data sublanguage) can be embedded in a general-purpose programming
language (host language), such as COBOL, C or an Assembly Language.
– Alternatively, stand-alone DML commands can be applied directly (query language).

• High Level or Non-procedural Languages : e.g., SQL, are set-oriented and specify what data to
retrieve than how to retrieve. Also called declarative languages.
• Low Level or Procedural Languages : record-at-a-time; they specify how to retrieve data and include
constructs such as looping.

DBMS Interfaces

• Menu-based Interfaces
• Form-based Interfaces

• Graphical User Interfaces

• Natural Language Interfaces

• Speech as Input and Output

• Parametric interfaces (e.g., bank tellers) using function keys.
• Interfaces for the DBA:
– Creating accounts, granting authorizations
– Setting system parameters
– Changing schemas or access path

10
 Figure 4: Component modules of a DBMS and their interactions

DBMS Components

• The DBMS is a complex software system

– It can be partitioned into several components, each providing a given services

Database System Utilities

• To perform certain functions such as:

– Loading data stored in files into a database. Includes data conversion tools.
– Backing up the database periodically on tape.
– Reorganizing database file structures.
– Report generation utilities.
– Performance monitoring utilities.
– Other functions, such as sorting, user monitoring, data compression, etc.

11
Other Tools

• Data dictionary / data repository

– Used to store schema descriptions and other information such as design decisions, application
program descriptions, user information, usage standards, etc.
• Application Development Environments and CASE (computer-aided software engineering) tools

– Examples : Power builder (Sybase), Builder (Borland)

1.11 Classification of DBMSs

• Based on the data model used

– Traditional : Relational, Network, Hierarchical.

– Emerging : Object-oriented, Object-relational.
• Based on number of users supported by the system

– Single-user (typically used with micro-computers) vs. multi-user (most DBMSs).

• Based on the number of sites over which the database is distributed
– Centralized (uses a single computer with one database) vs. distributed (uses multiple com-
puters, multiple databases)

• Based on cost
– Open source (free) vs. Commercial

File: Lectures 2014.tex Date: Friday 24th January, 2014 3:31pm Revision: 0.3

12