Database Systems

1

1

Chapter 1

Database Systems

Database Systems:

Design, Implementation, and Management,

Sixth Edition, Rob and Coronel

1

2Database Systems: Design, Implementation, & Management, 6th Edition, Rob & Coronel

In this chapter, you will learn:

• The difference between data and information

• What a database is, about different types of

databases, and why they are valuable assets

for decision making

• Why database design is important

• How modern databases evolved from files

and file systems

1


In this chapter, you will learn (continued):

• About flaws in file system data management

• How a database system differs from a file

system, and how a DBMS functions within the

database system

1


Data vs. Information

• Data:

– Raw facts; building blocks of information

– Unprocessed information

• Information:

– Data processed to reveal meaning

• Accurate, relevant, and timely information is

key to good decision making

• Good decision making is key to survival in

global environment

1


Sales per Employee for Each of

ROBCOR’s Two Divisions

1


Introducing the Database

and the DBMS

• Database—shared, integrated computer

structure that houses:

– End user data (raw facts)

– Metadata (data about data)

1


Introducing the Database

and the DBMS (continued)

• DBMS (database management system):

– Collection of programs that manages

database structure and controls access to

data

– Possible to share data among multiple

applications or users

– Makes data management more efficient and

effective

1


DBMS Makes Data Management More

Efficient and Effective

• End users have better access to more and

better-managed data

– Promotes integrated view of organization’s

operations

– Probability of data inconsistency is greatly

reduced

– Possible to produce quick answers to ad hoc

queries

1


The DBMS Manages the Interaction

Between the End User and the Database

1


Types of Databases

• Single-user:

– Supports only one user at a time

• Desktop:

– Single-user database running on a personal

computer

• Multi-user:

– Supports multiple users at the same time

1


Types of Databases (continued)

• Workgroup:

– Multi-user database that supports a small

group of users or a single department

• Enterprise:

– Multi-user database that supports a large

group of users or an entire organization

1


Location of Databases

• Centralized:

– Supports data located at a single site

• Distributed:

– Supports data distributed across several sites

1


Uses of Databases

• Transactional (or production):

– Supports a company’s day-to-day operations

• Data warehouse:

– Stores data used to generate information

required to make tactical or strategic decisions

• Such decisions typically require ―data

massaging‖

– Often used to store historical data

– Structure is quite different

1


Why Database Design is Important

• Defines the database’s expected use

• Different approach needed for different types

of databases

• Avoid redundant data (unnecessarily

duplicated)

• Poorly designed database generates errors

leads to bad decisions can lead to

failure of organization

1


The Historical Roots of Database:

Files and File Systems

• Although managing data through file systems is

largely obsolete

– Understanding relatively simple characteristics of

file systems makes complexity of database

design easier to understand

– Awareness of problems that plagued file systems

can help prevent similar problems in DBMS

– Knowledge of file systems is helpful if you plan to

convert an obsolete file system to a DBMS

1


Manual File Systems

• Traditionally composed of collection of file

folders kept in file cabinet

• Organization within folders was based on

data’s expected use (ideally logically related)

• System was adequate for small amounts of

data with few reporting requirements

• Finding and using data in growing collections

of file folders became time-consuming and

cumbersome

1


Conversion from Manual File System to

Computer File System

• Could be technically complex, requiring hiring

of data processing (DP) specialists

• DP specialists created file structures, wrote

software, and designed application programs

• Resulted in numerous ―home-grown‖ systems

being created

• Initially, computer files were similar in design

to manual files (see Figure 1.3)

1


Contents of Customer File

1


Basic File Terminology

1


Example of Early Database Design

• DP specialist wrote programs for reports:

– Monthly summaries of types and amounts of

insurance sold by agents

– Monthly reports about which customers should

be contacted for renewal

– Reports that analyzed ratios of insurance types

sold by agent

– Customer contact letters summarizing coverage

• Additional reports were written as required

1



(continued)

• Other departments requested databases be

written for them

– SALES database created for sales department

– AGENT database created for personnel

department

1


Contents of the Agent File

1


Evolution of Simple File System

• As number of databases increased, small file

system evolved

• Each file used its own application programs

• Each file was owned by individual or

department who commissioned its creation

1


A Simple File System

1



(continued)

• As system grew, demand for DP’s

programming skills grew

• Additional programmers hired

• DP specialist evolved into DP manager,

supervising a DP department

• Primary activity of department (and DP

manager) remained programming

1


Problems with

File System Data Management

• Every task requires extensive programming in

a third-generation language (3GL)

– Programmer must specify task and how it

must be done

• Modern databases use fourth-generation

language (4GL)

– Allows user to specify what must be done

without specifying how it is to be done

1


Programming in 3GL

• Time-consuming, high-level activity

• Programmer must be familiar with physical

file structure

• As system becomes complex, access paths

become difficult to manage and tend to

produce malfunctions

• Complex coding establishes precise location

of files and system components and data

characteristics

1


Programming in 3GL (continued)

• Ad hoc queries are impossible

• Writing programs to design new reports is time

consuming

• As number of files increases, system

administration becomes difficult

• Making changes in existing file structure is

difficult

• File structure changes require modifications in

all programs that use data in that file

1


Programming in 3GL (continued)

• Modifications are likely to produce errors,

requiring additional time to ―debug‖ the

program

• Security features hard to program and

therefore often omitted

1


Structural and Data Dependence

• Structural dependence

– Access to a file depends on its structure

• Data dependence

– Changes in database structure affect

program’s ability to access data

– Logical data format

• How a human being views the data

– Physical data format

• How the computer ―sees‖ the data

1


Field Definitions

and Naming Conventions

• Flexible record definition anticipates reporting

requirements by breaking up fields into their

component parts

1


Sample Customer File Fields

1


Data Redundancy

• Data redundancy results in data inconsistency

– Different and conflicting versions of the same

data appear in different places

• Errors more likely to occur when complex

entries are made in several different files and

recur frequently in one or more files

• Data anomalies develop when required

changes in redundant data are not made

successfully

1


Data Anomalies

• Modification anomalies

– Occur when changes must be made to

existing records

• Insertion anomalies

– Occur when entering new records

• Deletion anomalies

– Occur when deleting records

1


Database vs. File System

• Problems inherent in file systems make using

a database system desirable

• File system

– Many separate and unrelated files

• Database

– Logically related data stored in a single logical

data repository

1


Contrasting Database and File Systems

1


The Database System Environment

• Database system is composed of 5 main

parts:

1. Hardware

2. Software

• Operating system software

• DBMS software

• Application programs and utility software

3. People

4. Procedures

5. Data

1


The Database System Environment

(continued)

1


DBMS Functions

• Performs functions that guarantee integrity and

consistency of data

– Data dictionary management

• defines data elements and their relationships

– Data storage management

• stores data and related data entry forms, report

definitions, etc.

– Data transformation and presentation

• translates logical requests into commands to

physically locate and retrieve the requested data

1


DBMS Functions (continued)

– Security management

• enforces user security and data privacy within

database

– Multi-user access control

• creates structures that allow multiple users to

access the data

– Backup and recovery management

• provides backup and data recovery procedures

1


DBMS Functions (continued)

– Data integrity management

• promotes and enforces integrity rules to

eliminate data integrity problems

– Database access languages and application

programming interfaces

• provides data access through a query language

– Database communication interfaces

• allows database to accept end-user requests

within a computer network environment

1


Illustrating Metadata

with Microsoft Access

1


Illustrating Data Storage Management

with Oracle

1


Summary

• Information is derived from data, which is stored

in a database

• To implement and manage a database, use a

DBMS

• Database design defines its structure

• Good design is important

1


Summary (continued)

• Databases were preceded by file systems

• Because file systems lack a DBMS, file

management becomes difficult as a file

system grows

• DBMS were developed to address file

systems’ inherent weaknesses

1

46

Chapter 2

Data Model

Database Systems:



1



• Why data models are important

• About the basic data-modeling building

blocks

• What business rules are and how they affect

database design

• How the major data models evolved, and

their advantages and disadvantages

• How data models can be classified by level of

abstraction

1


The Importance of Data Models

• Data model

– Relatively simple representation, usually

graphical, of complex real-world data

structures

– Communications tool to facilitate interaction

among the designer, the applications

programmer, and the end user

• Good database design uses an appropriate

data model as its foundation

1


Importance of Data Modeling

• End-users have different views and needs for

data

• Data model organizes data for various users

1


Data Model Basic Building Blocks

• Entity is anything about which data are to be

collected and stored

• Attribute is a characteristic of an entity

• Relationship describes an association among

(two or more) entities

– One-to-many (1:M) relationship

– Many-to-many (M:N or M:M) relationship

– One-to-one (1:1) relationship

1


Business Rules

• Brief, precise, and unambiguous description

of a policy, procedure, or principle within a

specific organization’s environment

• Apply to any organization that stores and

uses data to generate information

• Description of operations that help to create

and enforce actions within that organization’s

environment

1


Business Rules (continued)

• Must be rendered in writing

• Must be kept up to date

• Sometimes are external to the organization

• Must be easy to understand and widely

disseminated

• Describe characteristics of the data as viewed by the company

1


Sources of Business Rules

• Company managers

• Policy makers

• Department managers

• Written documentation

– Procedures

– Standards

– Operations manuals

• Direct interviews with end users

1


Importance of Business Rules

• Promote creation of an accurate data model

• Standardize company’s view of data

• Constitute a communications tool between users

and designers

• Allow designer to understand the nature, role,

and scope of data

• Allow designer to understand business

processes

• Allow designer to develop appropriate

relationship participation rules and constraints

1


The Evolution of Data Models

• Hierarchical

• Network

• Relational

• Entity relationship

• Object oriented

1


The Hierarchical Model—Evolution

• GUAM (Generalized Update Access Method)

– Based on the recognition that the many

smaller parts would come together as

components of still larger components

• Information Management System (IMS)

– World’s leading mainframe hierarchical

database system in the 1970s and early 1980s

1


The Hierarchical Model—Characteristics

• Basic concepts form the basis for subsequent

database development

• Limitations lead to a different way of looking

at database design

• Basic concepts show up in current data

models

• Best understood by examining manufacturing

process

1


A Hierarchical Structure

1


Hierarchical Structure—Characteristics

• Each parent can have many children

• Each child has only one parent

• Tree is defined by path that traces parent

segments to child segments, beginning from

the left

• Hierarchical path

– Ordered sequencing of segments tracing

hierarchical structure

• Preorder traversal or hierarchic sequence

– ―Left-list‖ path

1


The Hierarchical Model

• Advantages

– Conceptual simplicity

– Database security

– Data independence

– Database integrity

– Efficiency

1


The Hierarchical Model (continued)

• Disadvantages

– Complex implementation

– Difficult to manage

– Lacks structural independence

– Complex applications programming and use

– Implementation limitations

– Lack of standards

1


Child with Multiple Parents

1


The Network Model

• Created to

– Represent complex data relationships more

effectively

– Improve database performance

– Impose a database standard

• Conference on Data Systems Languages

(CODASYL)

• American National Standards Institute (ANSI)

• Database Task Group (DBTG)

1


Crucial Database Components

• Schema

– Conceptual organization of entire database as viewed by the database administrator

• Subschema

– Defines database portion ―seen‖ by the application programs that actually produce the desired information from data contained within the database

• Data Management Language (DML)

– Define data characteristics and data structure in order to manipulate the data

1


Data Management

Language Components

• Schema Data Definition Language (DDL)

– Enables database administrator to define

schema components

• Subschema DDL

– Allows application programs to define

database components that will be used

• DML

– Manipulates database contents

1


Network Model—Basic Structure

• Resembles hierarchical model

• Collection of records in 1:M relationships

• Set

– Relationship

– Composed of at least two record types

• Owner

– Equivalent to the hierarchical model’s parent

• Member

– Equivalent to the hierarchical model’s child

1


A Network Data Model

1


The Network Data Model

• Advantages

– Conceptual simplicity

– Handles more relationship types

– Data access flexibility

– Promotes database integrity

– Data independence

– Conformance to standards

1


The Network Data Model (continued)

• Disadvantages

– System complexity

– Lack of structural independence

1


The Relational Model

• Developed by Codd (IBM) in 1970

• Considered ingenious but impractical in 1970

• Conceptually simple

• Computers lacked power to implement the

relational model

• Today, microcomputers can run sophisticated

relational database software

1


The Relational Model—Basic Structure

• Relational Database Management System

(RDBMS)

• Performs same basic functions provided by

hierarchical and network DBMS systems, plus

other functions

• Most important advantage of the RDBMS is

its ability to let the user/designer operate in a

human logical environment

1


The Relational Model—

Basic Structure (continued)

• Table (relations)

– Matrix consisting of a series of row/column

intersections

– Related to each other by sharing a common

entity characteristic

• Relational schema

– Visual representation of relational database’s

entities, attributes within those entities, and

relationships between those entities

1


Relational Table

• Stores a collection of related entities

– Resembles a file

• Relational table is purely logical structure

– How data are physically stored in the

database is of no concern to the user or the

designer

– This property became the source of a real

database revolution

1


A Relational Schema

1


Linking Relational Tables

1


The Relational Model

• Advantages

– Structural independence

– Improved conceptual simplicity

– Easier database design, implementation,

management, and use

– Ad hoc query capability

– Powerful database management system

1


The Relational Model (continued)

• Disadvantages

– Substantial hardware and system software

overhead

– Can facilitate poor design and implementation

– May promote ―islands of information‖ problems

1


The Entity Relationship Model

• Widely accepted and adapted graphical tool

for data modeling

• Introduced by Chen in 1976

• Graphical representation of entities and their

relationships in a database structure

1


The Entity Relationship Model—

Basic Structure

• Entity relationship diagram (ERD)

– Uses graphic representations to model

database components

– Entity is mapped to a relational table

• Entity instance (or occurrence) is row in table

• Entity set is collection of like entities

• Connectivity labels types of relationships

– Diamond connected to related entities through

a relationship line

1


Relationships: The Basic Chen ERD

1


Relationships:

The Basic Crow’s Foot ERD

1


The Entity Relationship Model

• Advantages

– Exceptional conceptual simplicity

– Visual representation

– Effective communication tool

– Integrated with the relational data model

1


The Entity Relationship Model (continued)

• Disadvantages

– Limited constraint representation

– Limited relationship representation

– No data manipulation language

– Loss of information content

1


The Object Oriented Model

• Semantic data model (SDM) developed by

Hammer and McLeod in 1981

• Modeled both data and their relationships in a

single structure known as an object

• Basis of object oriented data model (OODM)

• OODM becomes the basis for the object

oriented database management system

(OODBMS)

1


The Object Oriented Model (continued)

• Object is described by its factual content

– Like relational model’s entity

• Includes information about relationships

between facts within object and relationships

with other objects

– Unlike relational model’s entity

• Subsequent OODM development allowed an

object to also contain operations

• Object becomes basic building block for

autonomous structures

1


Developments that

Boosted OODM’s Popularity

• Growing costs put a premium on code reusability

• Complex data types and system requirements became difficult to manage with a traditional RDBMS

• Became possible to support increasingly sophisticated transaction & information requirements

• Ever-increasing computing power made it possible to support the large computing overhead required

1


Object Oriented Data Model—

Basic Structure

• Object: abstraction of a real-world entity

• Attributes describe the properties of an object

• Objects that share similar characteristics are

grouped in classes

• Classes are organized in a class hierarchy

• Inheritance is the ability of an object within

the class hierarchy to inherit the attributes

and methods of classes above it

1


A Comparison of the OO Model

and the ER Model

1


The Object Oriented Model

• Advantages

– Adds semantic content

– Visual presentation includes semantic content

– Database integrity

– Both structural and data independence

1


The Object Oriented Model (continued)

• Disadvantages

– Slow pace of OODM standards development

– Complex navigational data access

– Steep learning curve

– High system overhead slows transactions

– Lack of market penetration

1


Other Models

• Extended Relational Data Model (ERDM)

– Semantic data model developed in response

to increasing complexity of applications

– DBMS based on the ERDM often described as

an object/relational database management

system (O/RDBMS)

– Primarily geared to business applications

1


Other Models (continued)

• Date’s objections to ERDM label

– Given proper support for domains, relational

data models are quite capable of handling

complex data

• Therefore, capability that is supposedly being

extended is already there

– O/RDM label is not accurate because the

relational data model’s domain is not an object

model structure

1


Data Models: A Summary

• Each new data model capitalized on the

shortcomings of previous models

• Common characteristics:

– Conceptual simplicity without compromising the

semantic completeness of the database

– Represent the real world as closely as possible

– Representation of real-world transformations

(behavior) must be in compliance with

consistency and integrity characteristics of any

data model

1


The Development of Data Models

1


Database Models and the Internet

• Characteristics of successful ―Internet age‖

databases

– Flexible, efficient, and secure Internet access

that is easily used, developed, and supported

– Support for complex data types and

relationships

– Seamless interfacing with multiple data

sources and structures

1


Database Models and the Internet

(continued)

– Relative conceptual simplicity to make

database design and implementation less

cumbersome

– An abundance of available database design,

implementation, and application development

tools

– A powerful DBMS graphical user interface

(GUI) to help make the DBA’s job easier

1


Degrees of Data Abstraction

• Way of classifying data models

• Many processes begin at high level of

abstraction and proceed to an ever-

increasing level of detail

• Designing a usable database follows the

same basic process

1


Degrees of Data Abstraction (continued)

• American National Standards

Institute/Standards Planning and

Requirements Committee (ANSI/SPARC)

– Classified data models according to their

degree of abstraction (1970s):

• Conceptual

• External

• Internal

1


Data Abstraction Levels

1


The Conceptual Model

• Represents global view of the database

• Enterprise-wide representation of data as

viewed by high-level managers

• Basis for identification and description of

main data objects, avoiding details

• Most widely used conceptual model is the

entity relationship (ER) model

1


A Conceptual Model for Tiny College

1


Advantages of Conceptual Model

• Provides a relatively easily understood macro

level view of data environment

• Independent of both software and hardware

– Does not depend on the DBMS software used

to implement the model

– Does not depend on the hardware used in the

implementation of the model

– Changes in either the hardware or the DBMS

software have no effect on the database

design at the conceptual level

1


The Internal Model

• Representation of the database as ―seen‖ by

the DBMS

• Adapts the conceptual model to the DBMS

• Software dependent

• Hardware independent

1


The External Model

• End users’ view of the data environment

• Requires that the modeler subdivide set of

requirements and constraints into functional

modules that can be examined within the

framework of their external models

• Good design should:

– Consider such relationships between views

– Provide programmers with a set of restrictions

that govern common entities

1


A Division of an Internal Model into

External Models

1


Advantages of External Models

• Use of database subsets makes application

program development much simpler

– Facilitates designer’s task by making it easier

to identify specific data required to support

each business unit’s operations

– Provides feedback about the conceptual

model’s adequacy

• Creation of external models helps to ensure

security constraints in the database design

1


The External Model

• DBMS dependent

• Hardware independent

1


The External Models for Tiny College

1


The Physical Model

• Operates at lowest level of abstraction,

describing the way data are saved on storage

media such as disks or tapes

• Software and hardware dependent

• Requires that database designers have a

detailed knowledge of the hardware and

software used to implement database design

1


Levels of Data Abstraction

1


Summary

• A good DBMS will perform poorly with a

poorly designed database

• A data model is a (relatively) simple

abstraction of a complex real-world data-

gathering environment

• Basic data modeling components are:

– Entities

– Attributes

– Relationships

1


Summary (continued)

• Hierarchical model

– Based on a tree structure composed of a root

segment, parent segments, and child

segments

– Depicts a set of one-to-many (l:M)

relationships between a parent and its children

– Does not include ad hoc querying capability

1


Summary (continued)

• Network model attempts to deal with many of the hierarchical model’s limitations

• Relational model:

– Current database implementation standard

– Much simpler than hierarchical or network design

• Object is basic modeling structure of object oriented model

• Data modeling requirements are a function of different data views (global vs. local) and level of data abstraction

1

114

Chapter 3

The Relational Database Model

Database Systems:



1



• That the relational database model takes a

logical view of data

• That the relational model’s basic components

are entities, attributes, and relationships

among entities

• How entities and their attributes are

organized into tables

1



• About relational database operators, the data

dictionary, and the system catalog

• How data redundancy is handled in the

relational database model

• Why indexing is important

1


A Logical View of Data

• Relational model

– Enables us to view data logically rather than

physically

– Reminds us of simpler file concept of data

storage

• Table

– Has advantages of structural and data

independence

– Resembles a file from conceptual point of view

– Easier to understand than its hierarchical and

network database predecessors

1


Tables and Their Characteristics

• Table: two-dimensional structure composed of

rows and columns

• Contains group of related entities an entity

set

– Terms entity set and table are often used

interchangeably

1


Tables and Their Characteristics

(continued)

• Table also called a relation because the

relational model’s creator, Codd, used the term

relation as a synonym for table

• Think of a table as a persistent relation:

– A relation whose contents can be permanently

saved for future use

1


Characteristics of a Relational Table

Table 3.1

1


STUDENT Table Attribute Values

1


Keys

• Consists of one or more attributes that

determine other attributes

• Primary key (PK) is an attribute (or a

combination of attributes) that uniquely

identifies any given entity (row)

• Key’s role is based on determination

– If you know the value of attribute A, you can

look up (determine) the value of attribute B

1


Student Classification

1


Keys (continued)

• Composite key

– Composed of more than one attribute

• Key attribute

– Any attribute that is part of a key

• Superkey

– Any key that uniquely identifies each entity

• Candidate key

– A superkey without redundancies

1


Null Values

• No data entry

• Not permitted in primary key

• Should be avoided in other attributes

• Can represent

– An unknown attribute value

– A known, but missing, attribute value

– A ―not applicable‖ condition

• Can create problems in logic and using

formulas

1


Controlled Redundancy

• Makes the relational database work

• Tables within the database share common

attributes that enable us to link tables

together

• Multiple occurrences of values in a table are

not redundant when they are required to

make the relationship work

• Redundancy is unnecessary duplication of

data

1


An Example of a

Simple Relational Database

1


The Relational Schema for the

CH03_SaleCo Database

1


Keys (continued)

• Foreign key (FK)

– An attribute whose values match primary key

values in the related table

• Referential integrity

– FK contains a value that refers to an existing

valid tuple (row) in another relation

• Secondary key

– Key used strictly for data retrieval purposes

1


Relational Database Keys

1


Integrity Rules

1


An Illustration of Integrity Rules

1


A Dummy Variable Value Used as a Flag

1


Relational Database Operators

• Relational algebra

– Defines theoretical way of manipulating table

contents using relational operators:

• SELECT

• PROJECT

• JOIN

• INTERSECT

– Use of relational algebra operators on existing

tables (relations) produces new relations

• UNION

• DIFFERENCE

• PRODUCT

• DIVIDE

1


Relational Algebra Operators (continued)

• Union:

– Combines all rows from two tables, excluding

duplicate rows

– Tables must have the same attribute

characteristics

• Intersect:

– Yields only the rows that appear in both tables

1


Union

1


Intersect

1



• Difference

– Yields all rows in one table not found in the

other table—that is, it subtracts one table from

the other

• Product

– Yields all possible pairs of rows from two

tables

• Also known as the Cartesian product

1


Difference

1


Product

1



• Select

– Yields values for all rows found in a table

– Can be used to list either all row values or it

can yield only those row values that match a

specified criterion

– Yields a horizontal subset of a table

• Project

– Yields all values for selected attributes

– Yields a vertical subset of a table

1


Select

1


Project

1



• Join

– Allows us to combine information from two or

more tables

– Real power behind the relational database,

allowing the use of independent tables linked

by common attributes

1


Two Tables That Will Be Used

in Join Illustrations

1


Natural Join

• Links tables by selecting only rows with common values in their common attribute(s)

• Result of a three-stage process:

1. PRODUCT of the tables is created

2. SELECT is performed on Step 1 output to yield only the rows for which the AGENT_CODE values are equal

• Common column(s) are called join column(s)

3. PROJECT is performed on Step 2 results to yield a single copy of each attribute, thereby eliminating duplicate columns

1


Natural Join, Step 1: PRODUCT

1


Natural Join, Step 2: SELECT

1


Natural Join, Step 3: PROJECT

1


Natural Join (continued)

• Final outcome yields table that

– Does not include unmatched pairs

– Provides only copies of matches

• If no match is made between the table rows,

– the new table does not include the unmatched

row

1


Natural Join (continued)

• The column on which we made the JOIN—that

is, AGENT_CODE—occurs only once in the

new table

• If the same AGENT_CODE were to occur

several times in the AGENT table,

– a customer would be listed for each match

1


Other Forms of Join• Equijoin

– Links tables on the basis of an equality condition that compares specified columns of each table

– Outcome does not eliminate duplicate columns

– Condition or criterion to join tables must be explicitly defined

– Takes its name from the equality comparison operator (=) used in the condition

• Theta join

– If any other comparison operator is used

1


Outer Join

• Matched pairs are retained and any unmatched values in other table are left null

• In outer join for tables CUSTOMER and AGENT, two scenarios are possible:

– Left outer join

• Yields all rows in CUSTOMER table, including those that do not have a matching value in the AGENT table

– Right outer join

• Yields all rows in AGENT table, including those that do not have matching values in the CUSTOMER table

1


Left Outer Join

1


Right Outer Join

1


Divide

• DIVIDE requires the use of one single-column

table and one two-column table

1


DIVIDE

1


The Data Dictionary

and System Catalog

• Data dictionary

– Used to provide detailed accounting of all tables found within the user/designer-created database

– Contains (at least) all the attribute names and characteristics for each table in the system

– Contains metadata—data about data

– Sometimes described as ―the database designer’s database‖ because it records the design decisions about tables and their structures

1


A Sample Data Dictionary

1


The Data Dictionary

and the System Catalog (continued)

• System catalog

– Contains metadata

– Detailed system data dictionary that describes

all objects within the database

– Terms ―system catalog‖ and ―data dictionary‖

are often used interchangeably

– Can be queried just like any user/designer-

created table

1


Relationships within the

Relational Database

• 1:M relationship

– Relational modeling ideal

– Should be the norm in any relational database design

• M:N relationships

– Must be avoided because they lead to data redundancies

• 1:1 relationship

– Should be rare in any relational database design

1


The 1:1 Relationship

• Relational database norm

• Found in any database environment

• One entity can be related to only one other

entity, and vice versa

• Often means that entity components were not

defined properly

• Could indicate that two entities actually

belong in the same table

• Sometimes 1:1 relationships are appropriate

1


The 1:1 Relationship Between

PROFESSOR and DEPARTMENT

1


The Implemented 1:1 Relationship Between

PROFESSOR and DEPARTMENT

1


The 1:M Relationship

Between PAINTER and PAINTING

1


The Implemented 1:M Relationship

Between PAINTER and PAINTING

1


The 1:M Relationship

Between COURSE and CLASS

1


The Implemented 1:M Relationship


1


The M:N Relationship

• Can be implemented by breaking it up to

produce a set of 1:M relationships

• Can avoid problems inherent to M:N

relationship by creating a composite entity or

bridge entity

1


The ERD’s M:N Relationship

Between STUDENT and CLASS

1


Sample Student Enrollment Data

1




1


Linking Table

• Implementation of a composite entity

• Yields required M:N to 1:M conversion

• Composite entity table must contain at least

the primary keys of original tables

• Linking table contains multiple occurrences of

the foreign key values

• Additional attributes may be assigned as

needed

1


Converting the M:N Relationship

into Two 1:M Relationships

1


Changing the M:N Relationship

to Two 1:M Relationships

1


The Expanded Entity Relationship Model

1



Ch03_TinyCollege Database

1


Data Redundancy Revisited

• Data redundancy leads to data anomalies

– Such anomalies can destroy database

effectiveness

• Foreign keys

– Control data redundancies by using common

attributes shared by tables

– Crucial to exercising data redundancy control

• Sometimes, data redundancy is necessary

1


A Small Invoicing System

1


The Relational Schema

for the Invoicing System

1


Indexes

• Arrangement used to logically access rows in

a table

• Index key

– Index’s reference point

– Points to data location identified by the key

• Unique index

– Index in which the index key can only have

one pointer value (row) associated with it

• Each index is associated with only one table

1


Components of an Index

1


Summary

• Entities are basic building blocks of a

relational database

• Entity set is a grouping of related entities,

stored in a table

• Keys define functional dependencies

– Superkey

– Candidate key

– Primary key

– Secondary key

– Foreign key

1


Summary (continued)

• Primary key uniquely identifies attributes

– Can link tables by using controlled redundancy

• Relational databases classified according to degree to which they support relational algebra functions

• Relationships between entities are represented by entity relationship models

• Data retrieval speed can be increased dramatically by using indexes

1

185

Chapter 4

Entity Relationship (ER) Modeling

Database Systems:



1



• How relationships between entities are defined and refined, and how such relationships are incorporated into the database design process

• How ERD components affect database design and implementation

• How to interpret the modeling symbols for the four most popular ER modeling tools

• That real-world database design often requires that you reconcile conflicting goals

1


The Entity Relationship (ER) Model

• ER model forms the basis of an ER diagram

• ERD represents the conceptual database as

viewed by end user

• ERDs depict the ER model’s three main

components:

– Entities

– Attributes

– Relationships

1


Entities

• Refers to the entity set and not to a single

entity occurrence

• Corresponds to a table and not to a row in the

relational environment

• In both the Chen and Crow’s Foot models, an

entity is represented by a rectangle

containing the entity’s name

• Entity name, a noun, is usually written in

capital letters

1


Attributes

• Characteristics of entities

• In Chen model, attributes are represented by

ovals and are connected to the entity

rectangle with a line

• Each oval contains the name of the attribute it

represents

• In the Crow’s Foot model, the attributes are

simply written in the attribute box below the

entity rectangle

1


The Attributes of the STUDENT Entity

1


Domains

• Attributes have a domain:

– The attribute’s set of possible values

• Attributes may share a domain

1


Primary Keys

• Underlined in the ER diagram

• Key attributes are also underlined in

frequently used table structure shorthand

• Ideally composed of only a single attribute

• Possible to use a composite key:

– Primary key composed of more than one

attribute

1


The CLASS Table (Entity)

Components and Contents

1


Attributes

• Composite attribute

• Simple attribute

• Single-value attribute

• Multivalued attributes

1


A Multivalued Attribute in an Entity

1


Resolving Multivalued Attribute Problems

• Although the conceptual model can handle

multivalued attributes, you should not implement them in the relational DBMS

– Within original entity, create several new

attributes, one for each of the original

multivalued attribute’s components

• Can lead to major structural problems in the table

– Create a new entity composed of original

multivalued attribute’s components

1


Splitting the Multivalued

Attribute into New Attributes

1


Components of the Multivalued Attribute

1


A New Entity Set Composed of a

Multivalued Attribute’s Components

1


Derived Attributes

• Attribute whose value may be calculated

(derived) from other attributes

• Need not be physically stored within the

database

• Can be derived by using an algorithm

1


Depiction of a Derived Attribute

1


Relationships

• Association between entities

• Participants:

– Entities that participate in a relationship

• Relationships between entities always

operate in both directions

• Relationship can be classified as 1:M

• Relationship classification is difficult to

establish if you only know one side

1


Connectivity and Cardinality

• Connectivity

– Used to describe the relationship classification

• Cardinality

– Expresses the specific number of entity

occurrences associated with one occurrence

of the related entity

• Established by very concise statements

known as business rules

1


Connectivity and Cardinality in an ERD

1


RELATIONSHIP Strength

• Existence dependence

– Entity’s existence depends on the existence of one or more other entities

• Existence independence

– Entity can exist apart from one or more related entities

• Weak (non-identifying) relationships

– One entity is not existence-independent on another entity

• Strong (Identifying) Relationships

– Related entities are existence-dependent

1


A Weak (Non-Identifying) Relationship


1


A Weak Relationship


1


Relationship Participation

• Optional:

– One entity occurrence does not require a

corresponding entity occurrence in a particular

relationship

• Mandatory:

– One entity occurrence requires a

corresponding entity occurrence in a particular

relationship

1


A Strong (Identifying) Relationship


1


An Optional CLASS Entity in the Relationship

PROFESSOR teaches CLASS

1


COURSE and CLASS

in a Mandatory Relationship

1


Relationship Strength and Weak Entities

• Weak entity meets two conditions

– Existence-dependent:

• Cannot exist without entity with which it has a

relationship

– Has primary key that is partially or totally

derived from the parent entity in the

relationship

• Database designer usually determines

whether an entity can be described as weak

based on the business rules

1


A Weak Entity in an ERD

1


A Weak Entity in a Strong Relationship

1


Relationship Degree

• Indicates number of associated entities or

participants

• Unary relationship

– Association is maintained within a single entity

• Binary relationship

– Two entities are associated

• Ternary relationship

– Three entities are associated

1


Three Types of Relationships

1


The Implementation

of a Ternary Relationship

1


Recursive Relationships

• Relationship can exist between occurrences

of the same entity set

• Naturally found within a unary relationship

1


An ER Representation

of Recursive Relationships

1


The 1:1 Recursive Relationship

―EMPLOYEE is Married to EMPLOYEE‖

1


Implementation of the M:N Recursive

―PART Contains PART‖ Relationship

1


Implementation of the 1:M ―EMPLOYEE

Manages EMPLOYEE‖ Recursive Relationship

1


Composite Entities

• Also known as bridge entities

• Composed of the primary keys of each of the

entities to be connected

• May also contain additional attributes that

play no role in the connective process

1


Converting the M:N Relationship

into Two 1:M Relationships

1




1


A Composite Entity in an ERD

1


Entity Supertypes and Subtypes

• Generalization hierarchy

– Depicts a relationship between a higher-level

supertype entity and a lower-level subtype

entity

• Supertype entity

– Contains shared attributes

• Subtype entity

– Contains unique attributes

1


Nulls Created by Unique Attributes

1


A Generalization Hierarchy

1


Disjoint Subtypes

• Also known as non-overlapping subtypes

– Subtypes that contain a subset of the

supertype entity set

– Each entity instance (row) of the supertype

can appear in only one of the disjoint subtypes

• Supertype and its subtype(s) maintain a 1:1

relationship

1


The EMPLOYEE/PILOT

Supertype/Subtype Relationship

1


A Generalization Hierarchy

with Overlapping Subtypes

1


A Comparison of ER Modeling Symbols

1


The Chen Representation

of the Invoicing Problem

1


The Crow’s Foot Representation


1


The Rein85 Representation


1


The IDEF1X Representation


1


Developing an ER Diagram

• Database design is an iterative rather than a

linear or sequential process

• Iterative process

– Based on repetition of processes and

procedures

1


A Supertype/Subtype Relationship

1


A Supertype/Subtype Relationship

in an ERD

1


Components of the ER Model

1


The Completed Tiny College ERD

1


The Challenge of Database Design:

Conflicting Goals

• Database design must conform to design

standards

• High processing speeds are often a top

priority in database design

• Quest for timely information might be the

focus of database design

1


Various Implementations

of a 1:1 Recursive Relationship

1


Summary

• Entity relationship (ER) model

– Uses ER diagrams to represent conceptual

database as viewed by the end user

– Three main components

• Entities

• Relationships

• Attributes

– Includes connectivity and cardinality notations

• Connectivities and cardinalities are based on

business rules

1


Summary (continued)

• ER symbols are used to graphically depict the

ER model’s components and relationships

• ERDs may be based on many different ER

models

• Entities can also be classified as supertypes

and subtypes within a generalization

hierarchy

• Database designers are often forced to make

design compromises

1

247

Chapter 5

Normalization of Database Tables

Database Systems:



1



• What normalization is and what role it plays in the database design process

• About the normal forms 1NF, 2NF, 3NF, BCNF, and 4NF

• How normal forms can be transformed from lower normal forms to higher normal forms

• That normalization and ER modeling are used concurrently to produce a good database design

• That some situations require denormalization to generate information efficiently

1


Database Tables and Normalization

• Normalization

– Process for evaluating and correcting table

structures to minimize data redundancies

• helps eliminate data anomalies

– Works through a series of stages called

normal forms:

• Normal form (1NF)

• Second normal form (2NF)

• Third normal form (3NF)

1


Database Tables and Normalization

(continued)

– 2NF is better than 1NF; 3NF is better than

2NF

– For most business database design purposes,

3NF is highest we need to go in the

normalization process

– Highest level of normalization is not always

most desirable

1


The Need for Normalization

• Example: company that manages building

projects

– Charges its clients by billing hours spent on

each contract

– Hourly billing rate is dependent on employee’s

position

– Periodically, a report is generated that contains

information displayed in Table 5.1

1


A Sample Report Layout

1


A Table in the Report Format

1


The Need for Normalization (continued)

• Structure of data set in Figure 5.1 does not

handle data very well

• The table structure appears to work; report is

generated with ease

• Unfortunately, the report may yield different

results, depending on what data anomaly has

occurred

1


Conversion to First Normal Form

• Repeating group

– Derives its name from the fact that a group of

multiple (related) entries can exist for any

single key attribute occurrence

• Relational table must not contain repeating

groups

• Normalizing the table structure will reduce

these data redundancies

• Normalization is three-step procedure

1


Step 1: Eliminate the Repeating Groups

• Present data in a tabular format, where each

cell has a single value and there are no

repeating groups

• Eliminate repeating groups by eliminating

nulls, making sure that each repeating group

attribute contains an appropriate data value

1


Data Organization: First Normal Form

1


Step 2: Identify the Primary Key

• Primary key must uniquely identify attribute

value

• New key must be composed

1


Step 3: Identify all Dependencies

• Dependencies can be depicted with the help

of a diagram

• Dependency diagram:

– Depicts all dependencies found within a given

table structure

– Helpful in getting bird’s-eye view of all

relationships among a table’s attributes

– Use makes it much less likely that an

important dependency will be overlooked

1


A Dependency Diagram:

First Normal Form (1NF)

1


First Normal Form

• Tabular format in which:

– All key attributes are defined

– There are no repeating groups in the table

– All attributes are dependent on primary key

• All relational tables satisfy 1NF requirements

• Some tables contain partial dependencies

– Dependencies based on only part of the primary key

– Sometimes used for performance reasons, but should be used with caution

– Still subject to data redundancies

1


Conversion to Second Normal Form

• Relational database design can be improved

by converting the database into second

normal form (2NF)

• Two steps

1


Step 1: Identify All Key Components

• Write each key component on separate line,

and then write the original (composite) key on

the last line

• Each component will become the key in a

new table

1


Step 2: Identify the Dependent Attributes

• Determine which attributes are dependent on

which other attributes

• At this point, most anomalies have been

eliminated

1


Second Normal Form (2NF)

Conversion Results

1


Second Normal Form

• Table is in second normal form (2NF) if:

– It is in 1NF and

– It includes no partial dependencies:

• No attribute is dependent on only a portion of

the primary key

1


Conversion to Third Normal Form

• Data anomalies created are easily eliminated

by completing three steps

1


Step 1: Identify Each New Determinant

• For every transitive dependency, write its

determinant as a PK for a new table

– Determinant

• Any attribute whose value determines other

values within a row

1


Step 2: Identify the Dependent Attributes

• Identify the attributes dependent on each

determinant identified in Step 1 and identify

the dependency

• Name the table to reflect its contents and

function

1


Step 3: Remove the Dependent Attributes

from Transitive Dependencies

• Eliminate all dependent attributes in transitive

relationship(s) from each table that has such

a transitive relationship

• Draw a new dependency diagram to show all

tables defined in Steps 1–3

• Check new tables and modified tables from

Step 3 to make sure that each has a

determinant and does not contain

inappropriate dependencies

1


Third Normal Form (3NF)

Conversion Results

1


Third Normal Form

• A table is in third normal form (3NF) if:

– It is in 2NF and

– It contains no transitive dependencies

1


Improving the Design

• Table structures are cleaned up to eliminate

the troublesome initial partial and transitive

dependencies

• Normalization cannot, by itself, be relied on to

make good designs

• It is valuable because its use helps eliminate

data redundancies

1


Improving the Design (continued)

• The following changes were made:

– PK assignment

– Naming conventions

– Attribute atomicity

– Adding attributes

– Adding relationships

– Refining PKs

– Maintaining historical accuracy

– Using derived attributes

1


The Completed Database

1


The Completed Database (continued)

1


Limitations on System-Assigned Keys

• System-assigned primary key may not

prevent confusing entries

• Data entries in Table 5.2 are inappropriate

because they duplicate existing records

– Yet there has been no violation of either entity

integrity or referential integrity

1


Duplicate Entries in the JOB Table

1


The Boyce-Codd Normal Form (BCNF)

• Every determinant in the table is a candidate

key

– Has same characteristics as primary key, but

for some reason, not chosen to be primary key

• If a table contains only one candidate key, the

3NF and the BCNF are equivalent

• BCNF can be violated only if the table

contains more than one candidate key

1


The Boyce-Codd Normal Form (BCNF)

(continued)

• Most designers consider the Boyce-Codd

normal form (BCNF) as a special case of 3NF

• A table is in 3NF if it is in 2NF and there are no

transitive dependencies

• A table can be in 3NF and not be in BCNF

– A transitive dependency exists when one

nonprime attribute is dependent on another

nonprime attribute

– A nonkey attribute is the determinant of a key

attribute

1


A Table That is in 3NF but not in BCNF

1


Decomposition to BCNF

1


Sample Data for a BCNF Conversion

1


Another BCNF Decomposition

1


Normalization and Database Design

• Normalization should be part of design process

• Make sure that proposed entities meet required normal form before table structures are created

• Many real-world databases have been improperly designed or burdened with anomalies if improperly modified during course of time

• You may be asked to redesign and modify existing databases

1


Normalization and Database Design

(continued)

• ER diagram

– Provides the big picture, or macro view, of an

organization’s data requirements and

operations

– Created through an iterative process

• Identifying relevant entities, their attributes and

their relationship

• Use results to identify additional entities and

attributes

1


Normalization and Database Design (continued)

• Normalization procedures

– Focus on the characteristics of specific entities

– A micro view of the entities within the ER diagram

• Difficult to separate normalization process

from ER modeling process

• Two techniques should be used concurrently

1


The Initial ERD for a

Contracting Company

1


The Modified ERD for a

Contracting Company

1


The Incorrect Representation

of a M:N Relationship

1


The Final (Implementable) ERD for a

Contracting Company

1


The Implemented Database for the

Contracting Company

1


Higher-Level Normal Forms

• In some databases, multiple multivalued

attributes exist

1


Tables with Multivalued Dependencies

1


Fourth Normal Form

• Table is in fourth normal form (4NF) if

– It is in 3NF

– Has no multiple sets of multivalued

dependencies

• 4NF is largely academic if tables conform to

the following two rules:

– All attributes are dependent on primary key

but independent of each other

– No row contains two or more multivalued facts

about an entity

1


A Set of Tables in 4NF

1


Denormalization

• Creation of normalized relations is important

database design goal

• Processing requirements should also be a

goal

• If tables decomposed to conform to

normalization requirements

– Number of database tables expands

1


Denormalization (continued)

• Joining larger number of tables takes

additional disk input/output (I/O) operations

and processing logic

– Reduces system speed

• Conflicts among design efficiency,

information requirements, and processing

speed are often resolved through

compromises that may include

denormalization

1



• Unnormalized tables in a production

database tend to have these defects:

– Data updates are less efficient because

programs that read and update tables must

deal with larger tables

– Indexing is much more cumbersome

– Unnormalized tables yield no simple strategies

for creating virtual tables known as views

1



• Use denormalization cautiously

• Understand why—under some

circumstances—unnormalized tables are a

better choice

1


Summary

• Normalization is a table design technique

aimed at minimizing data redundancies

• First three normal forms (1NF, 2NF, and 3NF)

are most commonly encountered

• Normalization is an important part—but only a

part—of the design process

• Continue the iterative ER process until all

entities and their attributes are defined and all

equivalent tables are in 3NF

1


Summary (continued)

• A table in 3NF may contain multivalued

dependencies that produce either numerous

null values or redundant data

• It may be necessary to convert a 3NF table to

the fourth normal form (4NF) by

– splitting such a table to remove multivalued

dependencies

• Tables are sometimes denormalized to yield

less I/O which increases processing speed

1

303

Chapter 6

Introduction to Structured Query

Language (SQL)

Database Systems:



1



• The basic commands and functions of SQL

• How to use SQL for data administration (to

create tables, indexes, and views)

• How to use SQL for data manipulation (to add,

modify, delete, and retrieve data)

• How to use SQL to query a database to extract

useful information

1


Introduction to SQL

• SQL functions fit into two broad categories:

• Data definition language

– SQL includes commands to create

• Database objects such as tables, indexes, and

views

• Commands to define access rights to those

database objects

• Data manipulation language

– Includes commands to insert, update, delete,

and retrieve data within the database tables

1


Introduction to SQL (continued)

• SQL is relatively easy to learn

• Basic command set has a vocabulary of less

than 100 words

• Nonprocedural language

• American National Standards Institute (ANSI)

prescribes a standard SQL

• Several SQL dialects exist

1


SQL Data Definition Commands

1


Data Manipulation Commands

1


Data Definition Commands

• Examine the simple database model and the

database tables that will form the basis for the

many SQL examples

• Understand the data environment

1


The Database Model

1


Creating the Database

• Two tasks must be completed

– create the database structure

– create the tables that will hold the end-user

data

• First task

– RDBMS creates the physical files that will hold

the database

– Tends to differ substantially from one RDBMS

to another

1


The Database Schema

• Authentication

– Process through which the DBMS verifies that only registered users are able to access the database

– Log on to the RDBMS using a user ID and a password created by the database administrator

• Schema

– Group of database objects—such as tables and indexes—that are related to each other

1


Data Types

• Data type selection is usually dictated by the

nature of the data and by the intended use

• Pay close attention to the expected use of

attributes for sorting and data retrieval

purposes

1


Some Common SQL Data Types

1


Creating Table Structures

• Use one line per column (attribute) definition

• Use spaces to line up the attribute characteristics and

constraints

• Table and attribute names are capitalized

• NOT NULL specification

• UNIQUE specification

• Primary key attributes contain both a NOT NULL and a

UNIQUE specification

• RDBMS will automatically enforce referential integrity

for foreign keys

• Command sequence ends with a semicolon

1


Other SQL Constraints

• NOT NULL constraint

– Ensures that a column does not accept nulls

• UNIQUE constraint

– Ensures that all values in a column are unique

• DEFAULT constraint

– Assigns a value to an attribute when a new row is

added to a table

• CHECK constraint

– Validates data when an attribute value is entered

1


SQL Indexes

• When a primary key is declared, DBMS

automatically creates a unique index

• Often need additional indexes

• Using the CREATE INDEX command, SQL

indexes can be created on the basis of any

selected attribute

• Composite index

– Index based on two or more attributes

– Often used to prevent data duplication

1


A Duplicated TEST Record

1


Data Manipulation Commands

• Adding table rows

• Saving table changes

• Listing table rows

• Updating table rows

• Restoring table contents

• Deleting table rows

• Inserting table rows with a select subquery

1


Common SQL Data Manipulation

Commands

1


A Data View and Entry Form

1


Saving Table Changes

• Changes made to table contents are not

physically saved on disk until

– Database is closed

– Program is closed

– COMMIT command is used

• Syntax

– COMMIT [WORK]

• Will permanently save any changes made to

any table in the database

1


Listing Table Rows

• SELECT

– Used to list contents of table

• Syntax

– SELECT columnlistFROM tablename

• Columnlist represents one or more attributes,

separated by commas

• Asterisk can be used as wildcard character to

list all attributes

1


Updating Table Rows

• UPDATE

– Modify data in a table

• Syntax

– UPDATE tablenameSET columnname = expression [, columname = expression]

[WHERE conditionlist];

• If more than one attribute is to be updated in

the row, separate corrections with commas

1


Restoring Table Contents

• ROLLBACK

– Used restore the database to its previous

condition

– Only applicable if COMMIT command has not

been used to permanently store the changes

in the database

• Syntax

– ROLLBACK;

• COMMIT and ROLLBACK only work with

data manipulation commands that are used to

add, modify, or delete table rows

1


Deleting Table Rows

• DELETE

– Deletes a table row

• Syntax

– DELETE FROM tablename[WHERE conditionlist ];

• WHERE condition is optional

• If WHERE condition is not specified, all rows

from the specified table will be deleted

1


Inserting Table Rows with a Select

Subquery

• INSERT

– Inserts multiple rows from another table (source)

– Uses SELECT subquery

• Query that is embedded (or nested) inside another query

• Executed first

• Syntax

– INSERT INTO tablename SELECT columnlist FROM tablename

1


Selecting Rows with Conditional

Restrictions

• Select partial table contents by placing

restrictions on rows to be included in output

– Add conditional restrictions to the SELECT

statement, using WHERE clause

• Syntax

– SELECT columnlistFROM tablelist[ WHERE conditionlist ] ;

1


Selected PRODUCT Table Attributes for

VENDOR Code 21344

1


The Microsoft Access QBE and its SQL

1


Comparison Operators

1


Selected PRODUCT Table Attributes for

VENDOR Codes Other than 21344

1


Selected PRODUCT Table Attributes

with a P_PRICE Restriction

1


Selected PRODUCT Table Attributes:

The ASCII Code Effect

1



Date Restriction

1


SELECT Statement

with a Computed Column

1


SELECT Statement with a Computed

Column and an Alias

1


Arithmetic Operators:

The Rule of Precedence

• Perform operations within parentheses

• Perform power operations

• Perform multiplications and divisions

• Perform additions and subtractions

1



The Logical OR

1



The Logical AND

1



The Logical AND and OR

1


Special Operators

• BETWEEN

– Used to check whether attribute value is within a range

• IS NULL

– Used to check whether attribute value is null

• LIKE

– Used to check whether attribute value matches a given string pattern

• IN

– Used to check whether attribute value matches any value within a value list

• EXISTS

– Used to check if a subquery returns any rows

1


Advanced Data Definition Commands

• All changes in the table structure are made

by using the ALTER command

– Followed by a keyword that produces specific

change

– Three options are available

• ADD

• MODIFY

• DROP

1


Changing a Column’s Data Type

• ALTER can be used to change data type

• Some RDBMSs (such as Oracle) do not

permit changes to data types unless the

column to be changed is empty

1


Changing a Column’s Data

Characteristics

• Use ALTER to change data characteristics

• If the column to be changed already contains

data, changes in the column’s characteristics

are permitted if those changes do not alter

the data type

1


Adding or Dropping a Column

• Use ALTER to add a column

– Do not include the NOT NULL clause for new

column

• Use ALTER to drop a column

– Some RDBMSs impose restrictions on the

deletion of an attribute

1


The Effect of Data Entry into the New

P_SALECODE Column

1


Update of the P_SALECODE Column in

Multiple Data Rows

1


The Effect of Multiple Data Updates in the

PRODUCT Table (MS Access)

1


Copying Parts of Tables

• SQL permits copying contents of selected

table columns so that the data need not be

reentered manually into newly created

table(s)

• First create the PART table structure

• Next add rows to new PART table using

PRODUCT table rows

1


PART Attributes Copied

from the PRODUCT Table

1


Advanced Select Queries

• SQL provides useful functions

– Count

– Find minimum and maximum values

– Calculate averages

• SQL allows the user to limit queries to only

those entries having no duplicates or entries

whose duplicates may be grouped

1



Ordered by (Ascending) P_PRICE

1


Partial Listing of

EMPLOYEE Table Contents

1


Telephone List Query Results

1


A Query Based on Multiple Restrictions

1


A Listing of Distinct (Different) V_CODE

Values in the PRODUCT Table

1


Some Basic SQL Aggregate Functions

1


COUNT Function Output Examples

1


MAX and MIN Function Output Examples

1


The Total Value of All Items

in the PRODUCT Table

1


AVG Function Output Examples

1


GROUP BY Clause Output Examples

1


Incorrect and Correct Use

of the GROUP BY Clause

1


An Application of the HAVING Clause

1


Virtual Tables: Creating a View

• View is a virtual table based on a SELECT

query

– Can contain columns, computed columns,

aliases, and aggregate functions from one or

more tables

• Base tables are tables on which the view is

based

• Create a view by using the CREATE VIEW

command

1


Creating a Virtual Table

with the CREATE VIEW Command

1


Joining Database Tables

• Ability to combine (join) tables on common

attributes is most important distinction

between a relational database and other

databases

• Join is performed when data are retrieved

from more than one table at a time

• Join is generally composed of an equality

comparison between the foreign key and the

primary key of related tables

1


Creating Links Through Foreign Keys

1


The Results of a Join

1


An Ordered and Limited Listing

After a JOIN

1


The Contents of the EMP Table

1


Using an Alias to Join a Table to Itself

1


The Left Outer Join Results

1


The Right Outer Join Results

1


Converting an ER Model

into a Database Structure

• Requires following specific rules that govern

such a conversion

• Decisions made by the designer to govern

data integrity are reflected in the foreign key

rules

• Implementation decisions vary according to

the problem being addressed

1


The Ch06_Artist Database ERD

and Tables

1


A Data Dictionary

for the Ch06_Artist Database

1


A Summary of Foreign Key Rules

1


Summary

• SQL commands can be divided into two

overall categories:

– Data definition language commands

– Data manipulation language commands

• Basic data definition commands allow you to

create tables, indexes, and views

• Many SQL constraints can be used with

columns

• Aggregate functions

– Special functions that perform arithmetic

computations over a set of rows

1


Summary (continued)

• ORDER BY clause

– Used to sort output of a SELECT statement

– Can sort by one or more columns and use

either an ascending or descending order

• Join output of multiple tables with SELECT

statement

• Natural join uses join condition to match only

rows with equal values in specified columns

• Right outer join and left outer join used to

select rows that have no matching values in

other related table

1

382

Chapter 7

Advanced SQL

Database Systems:



1



• About the relational set operators UNION,

UNION ALL, INTERSECT, and MINUS

• How to use the advanced SQL JOIN operator

syntax

• About the different types of subqueries and

correlated queries

• How to use SQL functions to manipulate dates,

strings, and other data

1


In this chapter, you will learn: (continued)

• How to create and use updatable views

• How to create and use triggers and stored

procedures

• How to create embedded SQL

1


UNION Query Result

1


UNION ALL Query Result

1


INTERSECT Query Result

1


MINUS Query Results

1


INTERSECT Alternative

1


MINUS Alternative

1


SQL Join Expression Styles

1


NATURAL JOIN Result

1


JOIN USING Result

1


JOIN ON Result

1


Outer Joins

• Returns not only rows matching join condition

but also rows with unmatched values

• Three types:

– Left

– Right

– Full

1


LEFT JOIN Result

1


RIGHT JOIN Result

1


FULL JOIN Result

1


SELECT Subquery Examples

1


WHERE Subquery Examples

1


IN Subquery Example

1


HAVING Subquery Example

1


Multirow Subquery Operator Example

1


FROM Subquery Example

1


Inline Subquery Example

1


Correlated Subquery Examples

1


EXISTS Correlated Subquery Examples

1


Selected MS Access/SQL Server

Date/Time Functions

1


Selected Oracle Date/Time Functions

1


Selected Oracle Date/Time Functions

(continued)

1


Selected Oracle Numeric Functions

1


Selected Oracle String Functions

1


Selected Oracle Conversion Functions

1


Selected Oracle Conversion Functions

(continued)

1


Oracle Sequence

1


Oracle Sequence Examples

1


The PRODMASTER

and PRODSALES Tables

1


The Oracle UPDATE Error Message

1


Creating an Updatable View in Oracle

1


PRODMASTER Table Update,

Using an Updatable View

1


Anonymous PL/SQL Block Examples

1


SHOW ERRORS

• Can help diagnose errors found in PL/SQL

blocks

• Yields additional debugging information

whenever an error is generated after an

PL/SQL block is created or executed

1


Anonymous PL/SQL Block

with Variables and Loops

1


PL/SQL Basic Data Types

1


The PRODUCT Table

1


Creating the

TRG_PRODUCT_REORDER Trigger

1


Verifying the TRG_PRODUCT_REORDER

Trigger Execution

1


The P_REORDER Value Mismatch After

Update of the P_MIN Attribute

1


Stored Procedures: Advantages

• Substantially reduce network traffic and

increase performance

• No transmission of individual SQL statements

over network

• Help reduce code duplication by means of

code isolation and code sharing

• Minimize chance of errors and cost of

application development and maintenance

1


Creating the PRC_PROD_DISCOUNT

Stored Procedure

1


Results of the PRC_PROD_DISCOUNT

Stored Procedure

1


The PRC_CUS_ADD Stored Procedure

1


The PRC_INV_ADD and

PRC_LINE_ADD Stored Procedures

1


Testing the PRC_INV_ADD and

PRC_LINE_ADD Procedures

1


Cursor Processing Commands

1


Cursor Attributes

1


SQL and Procedural Languages:

Key Differences

• Run-time mismatch:

– SQL executed one instruction at a time

– Host language typically runs at the client side

in its own memory space

• Processing mismatch:

– Host language processes one data element at

a time

• Data type mismatch:

– Data types may not match

1


Embedded SQL Framework

• A standard syntax to identify embedded SQL

code within host language

• A standard syntax to identify host variables

• A communication area used to exchange

status and error information between SQL

and the host language

1


SQL Status and Error Reporting Variables

1


Static SQL

• Embedded SQL in which the programmer

used predefined SQL statements and

parameters

– End users of programs are limited to actions

that were specified in application programs

• SQL statements will not change while

application is running

1


Dynamic SQL

• SQL statement is not known in advance, but

instead is generated at run time

• Program can generate SQL statements at run

time that are required to respond to ad hoc

queries

• Attribute list and the condition are not known

until the end user specifies them

• Tends to be much slower than static SQL

• Requires more computer resources

1


Summary

• SQL provides relational set operators to

combine output of two queries to generate new

relation

• Operations that join tables can be classified as

inner joins and outer joins

• Subqueries and correlated queries are used

when it is necessary to process data based on

other processed data

• SQL functions are used to extract or transform

data

1


Summary (continued)

• Oracle sequences may be used to generate

values to be assigned to a record

• PL/SQL may be used to create triggers,

stored procedures, and PL/SQL functions

• If SQL statements are designed to return

more than one value inside the PL/SQL code,

a cursor is needed

• Embedded SQL refers to the use of SQL

statements within an application

programming language

1

444

Chapter 8

Database Design

Database Systems:



1



• That successful database design must reflect the information system of which the database is a part

• That successful information systems are developed within a framework known as the Systems Development Life Cycle (SDLC)

• That, within the information system, the most successful databases are subject to frequent evaluation and revision within a framework known as the Database Life Cycle (DBLC)

1



• How to conduct evaluation and revision within

the SDLC and DBLC frameworks

• What database design strategies exist: top-

down vs. bottom-up design, and centralized

vs. decentralized design

1


Changing Data into Information

• Information

– Data processed and presented in a

meaningful form

– Can be as simple as tabulating the data,

thereby making certain data patterns more

obvious

• Transformation

– Any process that changes data into

information

1


A Simple Cross-Classification Table:

Transforming Data into Information

1


The Information System

• Provides for data collection, storage, and

retrieval

• Composed of people, hardware, software,

database(s), application programs, and

procedures

• Systems analysis

– Process that establishes need for and extent

of an information system

• Systems development

– Process of creating an information system

1


Applications

• Transform data into information that forms the

basis for decision making

• Usually produce

– Formal report

– Tabulations

– Graphic displays

• Composed of two parts

– Data

– Code by which the data are transformed into

information

1


Generating Information

for Decision Making

1


Information System

• Performance depends on triad of factors:

– Database design and implementation

– Application design and implementation

– Administrative procedures

• Database development

– Process of database design and implementation

– Primary objective is to create complete, normalized, nonredundant (to the extent possible), and fully integrated conceptual, logical, and physical database models

1


The Systems Development Life Cycle

(SDLC)

• Traces history (life cycle) of an information

system

• Provides ―big picture‖ within which database

design and application development can be

mapped out and evaluated

1



(SDLC) (continued)

• Divided into five phases

1. Planning

2. Analysis

3. Detailed systems design

4. Implementation

5. Maintenance

• Iterative rather than sequential process

1


Planning

• Yields general overview of the company and

its objectives

• Initial assessment made of information-flow-

and-extent requirements

• Must begin to study and evaluate alternate

solutions

– Technical aspects of hardware and software

requirements

– System cost

1



(SDLC)

1


Analysis

• Problems defined during the planning phase

are examined in greater detail during analysis

• A thorough audit of user requirements

• Existing hardware and software systems are

studied

• Goal is better understanding of system’s

functional areas, actual and potential

problems, and opportunities

1


Logical Systems Design

• Must specify appropriate conceptual data model, inputs, processes, and expected output requirements

• Might use tools such as data flow diagrams (DFD), hierarchical input process output (HIPO) diagrams, or entity relationship (ER) diagrams

• Yields functional descriptions of system’s components (modules) for each process within database environment

1


Detailed Systems Design

• Designer completes design of system’s

processes

• Includes all necessary technical

specifications

• Steps are laid out for conversion from old to

new system

• Training principles and methodologies are

also planned

1


Implementation

• Hardware, DBMS software, and application

programs are installed, and database design

is implemented

• Cycle of coding, testing, and debugging

continues until database is ready to be

delivered

• Database is created and system is

customized by creation of tables and views,

and user authorizations

1


Maintenance

• Three types:

– Corrective maintenance in response to systems errors

– Adaptive maintenance due to changes in the business environment

– Perfective maintenance to enhance the system

• Computer-assisted systems engineering– Make it possible to produce better systems within

reasonable amount of time and at a reasonable cost

1


The Database Life Cycle (DBLC)

1


The Database Initial Study

• Overall purpose:

– Analyze the company situation

– Define problems and constraints

– Define objectives

– Define scope and boundaries

• Interactive and iterative processes required to

complete the first phase of the DBLC

successfully

1


Summary of Activities in the Database

Initial Study

1


Analyze the Company Situation

• Analysis

– ―To break up any whole into its parts so as to find out their nature, function, and so on‖

• Company situation

– General conditions in which a company operates, its organizational structure, and its mission

• Analyze the company situation

– Discover what the company’s operational components are, how they function, and how they interact

1


Define Problems and Constraints

• Managerial view of company’s operation is

often different from that of end users

• Designer must continue to carefully probe to

generate additional information that will help

define problems within larger framework of

company operations

• Finding precise answers is important

• Defining problems does not always lead to

the perfect solution

1


Define Objectives

• Designer must ensure that database system

objectives correspond to those envisioned by

end user(s)

• Designer must begin to address the following

questions:

– What is the proposed system’s initial objective?

– Will the system interface with other existing or

future systems in the company?

– Will the system share data with other systems

or users?

1


Define Scope and Boundaries

• Scope

– Defines extent of design according to

operational requirements

– Helps define required data structures, type and

number of entities, and physical size of the

database

• Boundaries

– Limits external to the system

– Often imposed by existing hardware and

software

1


Database Design

• Necessary to concentrate on the data

• Characteristics required to build database

model

• Two views of data within system:

– Business view of data as information source

– Designer’s view of data structure, its access,

and the activities required to transform the

data into information

1


Two Views of Data:

Business Manager and Designer

1


Database Design (continued)

• Loosely related to analysis and design of larger system

• Systems analysts or systems programmers are in charge of designing other system components

– Their activities create procedures that will help transform data within the database into useful information

• Does not constitute a sequential process

– Iterative process that provides continuous feedback designed to trace previous steps

1


Procedure Flow in the Database Design

1


Conceptual Design

• Data modeling used to create an abstract

database structure that represents real-world

objects in the most realistic way possible

• Must embody a clear understanding of the

business and its functional areas

• Ensure that all data needed are in the model,

and that all data in the model are needed

• Requires four steps

1


Data Analysis and Requirements

• First step is to discover data element

characteristics

– Obtains characteristics from different sources

• Must take into account business rules

– Derived from description of operations

• Document that provides precise, detailed, up-

to-date, and thoroughly reviewed description of

activities that define an organization’s operating

environment

1


Entity Relationship (ER) Modeling

and Normalization

• Designer must communicate and enforce

appropriate standards to be used in the

documentation of design

– Use of diagrams and symbols

– Documentation writing style

– Layout

– Other conventions to be followed during

documentation

1


Developing the Conceptual Model

Using ER Diagrams

1


A Composite Entity

1


Data Redundancies in the VIDEO Table

1


ER Modeling Is an Iterative Process

Based on Many Activities

1


Conceptual Design Tools

and Information Sources

1


Data Dictionary

• Defines all objects (entities, attributes,

relations, views, and so on)

• Used in tandem with the normalization

process to help eliminate data anomalies and

redundancy problems

1


Data Model Verification

• Model must be verified against proposed system

processes to corroborate that intended processes

can be supported by database model

• Revision of original design starts with a careful

reevaluation of entities, followed by a detailed

examination of attributes that describe these

entities

• Define design’s major components as modules:

– An information system component that handles a

specific function

1


The ER Model Verification Process

1


Iterative ER Model Verification Process

1


Verification Process

• Select the central (most important) entity

– Defined in terms of its participation in most of

the model’s relationships

• Identify the module or subsystem to which the

central entity belongs and define boundaries

and scope

• Place central entity within the module’s

framework

1


DBMS Software Selection

• Critical to the information system’s smooth

operation

• Advantages and disadvantages should be

carefully studied

1


Logical Design

• Used to translate conceptual design into

internal model for a selected database

management system

• Logical design is software-dependent

• Requires that all objects in the model be

mapped to specific constructs used by

selected database software

1


A Simple Conceptual Model

1


Sample Layout for the COURSE Table

1


Physical Design

• Process of selecting data storage and data

access characteristics of the database

• Storage characteristics are a function of

device types supported by the hardware, type

of data access methods supported by system,

and DBMS

• Particularly important in the older hierarchical

and network models

• Becomes more complex when data are

distributed at different locations

1


Implementation and Loading

• New database implementation requires the

creation of special storage-related constructs

to house the end-user tables

1


Physical Organization of a DB2 Database

Environment

1


Performance

• One of the most important factors in certain

database implementations

• Not all DBMSs have performance-monitoring

and fine-tuning tools embedded in their

software

• There is no standard measurement for

database performance

• Not only (nor even main) factor

1


Security

• Data must be protected from access by

unauthorized users

• Must provide for the following:

– Physical security

– Password security

– Access rights

– Audit trails

– Data encryption

– Diskless workstations

1


Backup and Recovery

• Database can be subject to data loss through

unintended data deletion and power outages

• Data backup and recovery procedures

– Create a safety valve

– Allow database administrator to ensure

availability of consistent data

1


Integrity

• Enforced through proper use of primary and

foreign key rules

1


Company Standards

• May partially define database standards

• Database administrator must implement and

enforce such standards

1


Concurrency Control

• Feature that allows simultaneous access to a

database while preserving data integrity

• Failure to maintain can quickly destroy a

database’s effectiveness

1


The Need for Concurrency Control

1


Testing and Evaluation

• Occurs in parallel with applications

programming

• Database tools used to prototype applications

• If implementation fails to meet some of the

system’s evaluation criteria

– Fine-tune specific system and DBMS

configuration parameters

– Modify the physical design

– Modify the logical design

– Upgrade or change the DBMS software and/or

the hardware platform

1


Operation

• Once the database has passed the

evaluation stage, it is considered operational

• Beginning of the operational phase starts the

process of system evolution

1


Maintenance and Evolution

• Required periodic maintenance:

– Preventive maintenance

– Corrective maintenance

– Adaptive maintenance

• Assignment of access permissions and their

maintenance for new and old users

• Generation of database access statistics

• Periodic security audits

• Periodic system-usage summaries

1


Parallel Activities in the

DBLC and the SDLC

1


A Special Note about

Database Design Strategies

• Two classical approaches to database

design:

– Top-down design

• Identifies data sets

• Defines data elements for each of those sets

– Bottom-up design

• Identifies data elements (items)

• Groups them together in data sets

1


Top-Down vs. Bottom-Up Design

Sequencing

1


Centralized vs. Decentralized Design

• Database design may be based on two very different design philosophies:

– Centralized design

• Productive when the data component is composed of a relatively small number of objects and procedures

– Decentralized design

• Used when the data component of system has considerable number of entities and complex relations on which very complex operations are performed

1


Centralized Design

1


Decentralized Design

1


Aggregation Process

• Requires designer to create a single model in

which various aggregation problems must be

addressed:

– Synonyms and homonyms

– Entity and entity subtypes

– Conflicting object definitions

1


Summary of Aggregation Problems

1


Summary

• Transformation from data to information is

produced when programming code operates

on the data, thus producing applications

• Information system is designed to facilitate

transformation of data into information and to

manage both data and information

• SDLC traces the history (life cycle) of an

application within the information system

1


Summary (continued)

• DBLC describes the history of the database

within the information system

• Database design and implementation process

moves through a series of well-defined

stages

• Conceptual portion of the design may be

subject to several variations, based on two

design philosophies

1

513

Chapter 9

Transaction Management and

Concurrency Control

Database Systems:



1



• What a database transaction is and what its

properties are

• How database transactions are managed

• What concurrency control is and what role it

plays in maintaining the database’s integrity

• What locking methods are and how they work

• How database recovery management is used to

maintain database integrity

1


What is a Transaction?

• Any action that reads from and/or writes to a database may consist of

– Simple SELECT statement to generate a list of table contents

– A series of related UPDATE statements to change the values of attributes in various tables

– A series of INSERT statements to add rows to one or more tables

– A combination of SELECT, UPDATE, and INSERT statements

1


What is a Transaction? (continued)

• A logical unit of work that must be either

entirely completed or aborted

• Successful transaction changes the database

from one consistent state to another

– One in which all data integrity constraints are

satisfied

• Most real-world database transactions are

formed by two or more database requests

– The equivalent of a single SQL statement in

an application program or transaction

1



Ch09_SaleCo Database

1


Evaluating Transaction Results

• Not all transactions update the database

• SQL code represents a transaction because database was accessed

• Improper or incomplete transactions can have a devastating effect on database integrity

– Some DBMSs provide means by which user can define enforceable constraints based on business rules

– Other integrity rules are enforced automatically by the DBMS when table structures are properly defined, thereby letting the DBMS validate some transactions

1


Tracing the Transaction in the

Ch09_SaleCo Database

Figure 9.2

1


Transaction Properties

• Atomicity

– Requires that all operations (SQL requests) of

a transaction be completed

• Durability

– Indicates permanence of database’s

consistent state

1


Transaction Properties (continued)

• Serializability

– Ensures that the concurrent execution of

several transactions yields consistent results

• Isolation

– Data used during execution of a transaction

cannot be used by second transaction until

first one is completed

1


Transaction Management with SQL

• ANSI has defined standards that govern SQL

database transactions

• Transaction support is provided by two SQL

statements: COMMIT and ROLLBACK

• ANSI standards require that, when a

transaction sequence is initiated by a user or

an application program,

– it must continue through all succeeding SQL

statements until one of four events occurs

1


The Transaction Log

• Stores

– A record for the beginning of transaction

– For each transaction component (SQL statement)

• Type of operation being performed (update, delete, insert)

• Names of objects affected by the transaction (the name of the table)

• ―Before‖ and ―after‖ values for updated fields

• Pointers to previous and next transaction log entries for the same transaction

– The ending (COMMIT) of the transaction

1


A Transaction Log

1


Concurrency Control

• Coordination of simultaneous transaction

execution in a multiprocessing database

system

• Objective is to ensure transaction

serializability in a multiuser database

environment

1


Concurrency Control

– Important simultaneous execution of

transactions over a shared database can

create several data integrity and consistency

problems

• lost updates

• uncommitted data

• inconsistent retrievals

1


Normal Execution of Two Transactions

1


Lost Updates

1


Correct Execution of Two Transactions

1


An Uncommitted Data Problem

1


Retrieval During Update

1


Transaction Results:

Data Entry Correction

1


Inconsistent Retrievals

1


The Scheduler

• Special DBMS program: establishes order of

operations within which concurrent

transactions are executed

• Interleaves the execution of database

operations to ensure serializability and

isolation of transactions

1


The Scheduler (continued)

• Bases its actions on concurrency control

algorithms

• Ensures computer’s central processing unit

(CPU) is used efficiently

• Facilitates data isolation to ensure that two

transactions do not update the same data

element at the same time

1


Read/Write Conflict Scenarios:

Conflicting Database Operations Matrix

1


Concurrency Control

with Locking Methods

• Lock

– Guarantees exclusive use of a data item to a

current transaction

– Required to prevent another transaction from

reading inconsistent data

• Lock manager

– Responsible for assigning and policing the

locks used by the transactions

1


Lock Granularity

• Indicates the level of lock use

• Locking can take place at the following levels:

– Database

– Table

– Page

– Row

– Field (attribute)

1


Lock Granularity (continued)

• Database-level lock

– Entire database is locked

• Table-level lock

– Entire table is locked

• Page-level lock

– Entire diskpage is locked

1


Lock Granularity (continued)

• Row-level lock

– Allows concurrent transactions to access

different rows of the same table, even if the

rows are located on the same page

• Field-level lock

– Allows concurrent transactions to access the

same row, as long as they require the use of

different fields (attributes) within that row

1


A Database-Level Locking Sequence

1


An Example of a Table-Level Lock

1


Example of a Page-Level Lock

1


An Example of a Row-Level Lock

1


Lock Types

• Binary lock

– Has only two states: locked (1) or unlocked (0)

• Exclusive lock

– Access is specifically reserved for the

transaction that locked the object

– Must be used when the potential for conflict

exists

• Shared lock

– Concurrent transactions are granted Read

access on the basis of a common lock

1


An Example of a Binary Lock

1


Two-Phase Locking

to Ensure Serializability

• Defines how transactions acquire and relinquish locks

• Guarantees serializability, but it does not prevent deadlocks

– Growing phase, in which a transaction acquires all the required locks without unlocking any data

– Shrinking phase, in which a transaction releases all locks and cannot obtain any new lock

1


Two-Phase Locking

to Ensure Serializability (continued)

• Governed by the following rules:

– Two transactions cannot have conflicting locks

– No unlock operation can precede a lock

operation in the same transaction

– No data are affected until all locks are

obtained—that is, until the transaction is in its

locked point

1


Two-Phase Locking Protocol

1


Deadlocks

• Condition that occurs when two transactions

wait for each other to unlock data

• Possible only if one of the transactions wants

to obtain an exclusive lock on a data item

– No deadlock condition can exist among

shared locks

• Control through

– Prevention

– Detection

– Avoidance

1


How a Deadlock Condition Is Created

1


Concurrency Control

with Time Stamping Methods

• Assigns a global unique time stamp to each

transaction

• Produces an explicit order in which

transactions are submitted to the DBMS

• Uniqueness

– Ensures that no equal time stamp values can

exist

• Monotonicity

– Ensures that time stamp values always

increase

1


Wait/Die and Wound/Wait Schemes

• Wait/die

– Older transaction waits and the younger is

rolled back and rescheduled

• Wound/wait

– Older transaction rolls back the younger

transaction and reschedules it

1


Wait/Die and Wound/Wait

Concurrency Control Schemes

1


Concurrency Control

with Optimistic Methods

• Optimistic approach

– Based on the assumption that the majority of

database operations do not conflict

– Does not require locking or time stamping

techniques

– Transaction is executed without restrictions

until it is committed

– Phases are read, validation, and write

1


Database Recovery Management

• Database recovery

– Restores database from a given state, usually

inconsistent, to a previously consistent state

– Based on the atomic transaction property

• All portions of the transaction must be treated

as a single logical unit of work, in which all

operations must be applied and completed to

produce a consistent database

– If transaction operation cannot be completed,

transaction must be aborted, and any changes

to the database must be rolled back (undone)

1


Transaction Recovery

• Makes use of deferred-write and write-

through

• Deferred write

– Transaction operations do not immediately

update the physical database

– Only the transaction log is updated

– Database is physically updated only after the

transaction reaches its commit point using the

transaction log information

1


Transaction Recovery (continued)

• Write-through

– Database is immediately updated by

transaction operations during the transaction’s

execution, even before the transaction

reaches its commit point

1


A Transaction Log for Transaction

Recovery Examples

1


Summary

• Transaction

– Sequence of database operations that access

the database

– Represents real-world events

– Must be a logical unit of work

• No portion of the transaction can exist by itself

– Takes a database from one consistent state to

another

• One in which all data integrity constraints are

satisfied

1


Summary (continued)

• SQL provides support for transactions

through the use of two statements: COMMIT

and ROLLBACK

• Concurrency control coordinates the

simultaneous execution of transactions

• Scheduler is responsible for establishing

order in which concurrent transaction

operations are executed

1


Summary (continued)

• Lock guarantees unique access to a data

item by a transaction

• Database recovery restores the database

from a given state to a previous consistent

state

1

563

Chapter 10

Distributed Database

Management Systems

Database Systems:



1



• What a distributed database management system (DDBMS) is and what its components are

• How database implementation is affected by different levels of data and process distribution

• How transactions are managed in a distributed database environment

• How database design is affected by the distributed database environment

1


The Evolution of Distributed Database

Management Systems

• Distributed database management system

(DDBMS)

– Governs storage and processing of logically

related data over interconnected computer

systems in which both data and processing

functions are distributed among several sites

1


The Evolution of Distributed Database

Management Systems (continued)

• Centralized database required that corporate

data be stored in a single central site

• Dynamic business environment and

centralized database’s shortcomings

spawned a demand for applications based on

data access from different sources at multiple

locations

1


Centralized Database Management

System

1


DDBMS Advantages

• Data are located near ―greatest demand‖ site

• Faster data access

• Faster data processing

• Growth facilitation

• Improved communications

• Reduced operating costs

• User-friendly interface

• Less danger of a single-point failure

• Processor independence

1


DDBMS Disadvantages

• Complexity of management and control

• Security

• Lack of standards

• Increased storage requirements

• Greater difficulty in managing the data

environment

• Increased training cost

1


Distributed Processing Environment

1


Distributed Database Environment

1


Characteristics of Distributed

Management Systems

• Application interface

• Validation

• Transformation

• Query optimization

• Mapping

• I/O interface

• Formatting

• Security

• Backup and recovery

• DB administration

• Concurrency control

• Transaction management

1


Characteristics of Distributed

Management Systems (continued)

• Must perform all the functions of a centralized

DBMS

• Must handle all necessary functions imposed

by the distribution of data and processing

• Must perform these additional functions

transparently to the end user

1


A Fully Distributed Database

Management System

1


DDBMS Components

• Must include (at least) the following components:

– Computer workstations

– Network hardware and software

– Communications media

– Transaction processor (or, application processor, or transaction manager)

• Software component found in each computer that requests data

– Data processor or data manager

• Software component residing on each computer that stores and retrieves data located at the site

• May be a centralized DBMS

1


Distributed Database System

Components

1


Database Systems: Levels of Data and

Process Distribution

1


Single-Site Processing, Single-Site Data

(SPSD)

• All processing is done on single CPU or host computer (mainframe, midrange, or PC)

• All data are stored on host computer’s local disk

• Processing cannot be done on end user’s side of the system

• Typical of most mainframe and midrange computer DBMSs

• DBMS is located on the host computer, which is accessed by dumb terminals connected to it

• Also typical of the first generation of single-user microcomputer databases

1


Single-Site Processing, Single-Site Data

(Centralized)

1


Multiple-Site Processing, Single-Site Data

(MPSD)

• Multiple processes run on different computers

sharing a single data repository

• MPSD scenario requires a network file server

running conventional applications that are

accessed through a LAN

• Many multi-user accounting applications,

running under a personal computer network,

fit such a description

1


Multiple-Site Processing, Single-Site Data

1


Multiple-Site Processing,

Multiple-Site Data (MPMD)

• Fully distributed database management system

with support for multiple data processors and

transaction processors at multiple sites

• Classified as either homogeneous or

heterogeneous

• Homogeneous DDBMSs

– Integrate only one type of centralized DBMS

over a network

1


Multiple-Site Processing,

Multiple-Site Data (MPMD) (continued)

• Heterogeneous DDBMSs

– Integrate different types of centralized DBMSs

over a network

• Fully heterogeneous DDBMS

– Support different DBMSs that may even support

different data models (relational, hierarchical, or

network) running under different computer

systems, such as mainframes and

microcomputers

1


Heterogeneous Distributed

Database Scenario

1


Distributed Database

Transparency Features

• Allow end user to feel like database’s only

user

• Features include:

– Distribution transparency

– Transaction transparency

– Failure transparency

– Performance transparency

– Heterogeneity transparency

1


Distribution Transparency

• Allows management of a physically dispersed

database as though it were a centralized

database

• Three levels of distribution transparency are

recognized:

– Fragmentation transparency

– Location transparency

– Local mapping transparency

1


A Summary of Transparency Features

1


Fragment Locations

1


Transaction Transparency

• Ensures database transactions will maintain

distributed database’s integrity and

consistency

1


Distributed Requests and Distributed

Transactions

• Distributed transaction

– Can update or request data from several different remote sites on a network

• Remote request

– Lets a single SQL statement access data to be processed by a single remote database processor

• Remote transaction

– Accesses data at a single remote site

1


Distributed Requests and Distributed

Transactions (continued)

• Distributed transaction

– Allows a transaction to reference several

different (local or remote) DP sites

• Distributed request

– Lets a single SQL statement reference data

located at several different local or remote DP

sites

1


A Remote Request

1


A Remote Transaction

1


A Distributed Transaction

1


A Distributed Request

1


Another Distributed Request

1


Distributed Concurrency Control

• Multisite, multiple-process operations are

much more likely to create data

inconsistencies and deadlocked transactions

than are single-site systems

1


The Effect of a Premature COMMIT

1


Two-Phase Commit Protocol

• Distributed databases make it possible for a

transaction to access data at several sites

• Final COMMIT must not be issued until all

sites have committed their parts of the

transaction

• Two-phase commit protocol requires each

individual DP’s transaction log entry be

written before the database fragment is

actually updated

1


Performance Transparency

and Query Optimization

• Objective of query optimization routine is to

minimize total cost associated with the

execution of a request

• Costs associated with a request are a

function of the:

– Access time (I/O) cost

– Communication cost

– CPU time cost

1


Performance Transparency

and Query Optimization (continued)

• Must provide distribution transparency as well

as replica transparency

• Replica transparency:

– DDBMS’s ability to hide the existence of

multiple copies of data from the user

• Query optimization techniques:

– Manual or automatic

– Static or dynamic

– Statistically based or rule-based algorithms

1


Distributed Database Design

• Data fragmentation:

– How to partition the database into fragments

• Data replication:

– Which fragments to replicate

• Data allocation:

– Where to locate those fragments and replicas

1


Data Fragmentation

• Breaks single object into two or more

segments or fragments

• Each fragment can be stored at any site over

a computer network

• Information about data fragmentation is

stored in the distributed data catalog (DDC),

from which it is accessed by the TP to

process user requests

1


Data Fragmentation Strategies

• Horizontal fragmentation:

– Division of a relation into subsets (fragments)

of tuples (rows)

• Vertical fragmentation:

– Division of a relation into attribute (column)

subsets

• Mixed fragmentation:

– Combination of horizontal and vertical

strategies

1


A Sample CUSTOMER Table

1


Horizontal Fragmentation of the

CUSTOMER Table by State

1


Table Fragments in Three Locations

1


Vertically Fragmented Table Contents

1


Mixed Fragmentation of the

CUSTOMER Table

1


Data Replication

• Storage of data copies at multiple sites served

by a computer network

• Fragment copies can be stored at several sites

to serve specific information requirements

– Can enhance data availability and response time

– Can help to reduce communication and total

query costs

1


Table Contents After the Mixed

Fragmentation Process

1


Data Replication

1


Replication Scenarios

• Fully replicated database:– Stores multiple copies of each database

fragment at multiple sites

– Can be impractical due to amount of overhead

• Partially replicated database:– Stores multiple copies of some database

fragments at multiple sites

– Most DDBMSs are able to handle the partially replicated database well

• Unreplicated database:

– Stores each database fragment at a single site

– No duplicate database fragments

1


Data Allocation

• Deciding where to locate data

• Allocation strategies:– Centralized data allocation

• Entire database is stored at one site

– Partitioned data allocation• Database is divided into several disjointed parts

(fragments) and stored at several sites

– Replicated data allocation• Copies of one or more database fragments are

stored at several sites

• Data distribution over a computer network is achieved through data partition, data replication, or a combination of both

1


Client/Server vs. DDBMS

• Way in which computers interact to form a

system

• Features a user of resources, or a client, and

a provider of resources, or a server

• Can be used to implement a DBMS in which

the client is the TP and the server is the DP

1


Client/Server Advantages

• Less expensive than alternate minicomputer or mainframe solutions

• Allow end user to use microcomputer’s GUI, thereby improving functionality and simplicity

• More people with PC skills than with mainframe skills in the job market

• PC is well established in the workplace

• Numerous data analysis and query tools exist to facilitate interaction with DBMSs available in the PC market

• Considerable cost advantage to offloading applications development from the mainframe to powerful PCs

1


Client/Server Disadvantages

• Creates a more complex environment, in which

different platforms (LANs, operating systems,

and so on) are often difficult to manage

• An increase in the number of users and

processing sites often paves the way for security

problems

• Possible to spread data access to a much wider

circle of users increases demand for people

with broad knowledge of computers and

software increases burden of training and cost

of maintaining the environment

1


C. J. Date’s Twelve Commandments for

Distributed Databases

1. Local site independence

2. Central site independence

3. Failure independence

4. Location transparency

5. Fragmentation transparency

6. Replication transparency

7. Distributed query processing

8. Distributed transaction processing

9. Hardware independence

10. Operating system independence

11. Network independence

12. Database independence

1


Summary

• Distributed database stores logically related

data in two or more physically independent

sites connected via a computer network

• Database is divided into fragments

• Distributed databases require distributed

processing

• Main components of a DDBMS are the

transaction processor and the data processor

1


Summary (continued)

• Current database systems can be classified by extent to which they support processing and data distribution

• DDBMS characteristics are best described as a set of transparencies

• A transaction is formed by one or more database requests

• A database can be replicated over several different sites on a computer network

• Client/server architecture refers to the way in which two computers interact over a computer network to form a system

1

621

Chapter 11

Object Oriented Databases

Database Systems:



1



• What basic concepts govern OO systems

• How OO features are related to the more

traditional relational and ER models

• What the basic features of an OO database

management system (OODBMS) are

• What effect OO concepts are likely to have on

data modeling and design

1



• About the advantages and disadvantages of

OODBMSs

• How OO concepts have influenced the

relational model

• How Oracle9i implements object extensions

1


Object Orientation and Its Benefits

• A set of design and development principles

based on conceptually autonomous computer

structures known as objects

• Each object represents a real-world entity

with the ability to act upon itself and interact

with other objects

• Modularity is therefore almost inevitable

1


Object Orientation Contributions

1


The Evolution of Object Oriented

Concepts

• Object oriented programming

– Developed as an alternative to traditional

programming methods

– Programmer creates or uses objects:

• Self-contained, reusable modules that contain

data as well as the procedures used to operate

on such data

1



Concepts (continued)

• Object oriented programming languages were developed to:

– Provide an easy-to-use software development environment

– Provide a powerful software modeling tool for application development

– Decrease development time by reducing the amount of code

– Improve programmer productivity by making that code reusable

1



Concepts (continued)

• Object oriented environment has several

important attributes:

– Data set is no longer passive

– Data and procedures are bound together,

creating an object

– Object has an innate ability to act on itself

1


Object Oriented Concepts

• Have their roots in programming languages

• No knowledge of programming is necessary

to understand these concepts

1


Objects: Components and Characteristics

• Object:

– Abstract representation of a real-world entity

– Has:

• Unique identity

• Embedded properties

• Ability to interact with other objects and act

upon itself

– Defining characteristic is its unique identity

1


Real-World Student Objects

1


Object Identity

• Unique to that object

• Assigned by system at moment of object’s

creation

• Cannot be changed under any circumstances

• Can be deleted only if the object is deleted

• Can never be reused

1


Attributes (Instance Variables)

• Attributes:

– Known as instance variables in OO

environment

• Domain:

– Logically groups and describes the set of all

possible values that an attribute can have

1


Object Attributes

1


Object State

• Set of values that object’s attributes have at a

given time

• Can vary, although its OID remains the same

• To change the object’s state, change the

values of the object’s attributes

• To change the object’s attribute values, send

a message to the object

– Message will invoke a method

1


Messages and Methods

• Method:

– Code that performs a specific operation on

object’s data

– Protects data from direct and unauthorized

access by other objects

– Used to change the object’s attribute values or

to return the value of selected object attributes

– Represent real-world actions

1


Depiction of an Object

1


Method Components

1


Objects Send Messages to Each Other

1


Classes

• Collection of similar objects with shared

structure (attributes) and behavior (methods)

• Class instance or object instance

– Each object in a class

1


Class Illustration

1


Protocol

• An object’s public aspect

• How it is known by other objects as well as

end users

• Other objects communicate with the student

object using any of these methods

1


Public and Private Aspects of an Object

1


OO Summary: Object Characteristics

1


Musical Instruments Class Hierarchy

1


Single Inheritance

1


Multiple Inheritance

1


Motor Vehicle and Bicycle Instance

Variables

1


Employee Class Hierarchy Method

Override

1


Employee Class Hierarchy Polymorphism

1


Abstract Data Types

• Differs from conventional data type

– ADT’s operations are user-defined

– ADT does not allow direct access to its

internal data representation or method

implementation

• To create ADT, specify:

– Its name

– Data representation or instance variables of

objects belonging to the abstract data

– ADT operations and constraints, both of

which are implemented through methods

1


Object Classification

• Simple object

• Composite object

• Compound object

• Hybrid object

• Associative object

1


Characteristics of an Object Oriented

Data Model

• Support the representation of complex

objects

• Are extensible:

– Capable of defining new data types as well as

the operations to be performed on them

• Support encapsulation:

– Data representation and method’s

implementation must be hidden from external

entities

1


Characteristics of an Object Oriented

Data Model (continued)

• Exhibit inheritance:

– Object must be able to inherit properties (data

and methods) of other objects

• Support the notion of object identity (OID)

1


Comparing the OO and ER Model

Components

1


Shared Representation for All Objects of

the Class Person

1


State of a Person Object Instance

1


Defining Three Abstract Data Types

1


Object Representation for Instances of

the Class Person with ADTs

1


Object State for an Instance of the Class

Person, Using ADTs

1


Referential Object Sharing

1


Class Hierarchy

1


Employee Object Representation

1


Class Hierarchy for the EDLP Retail

Corporation

1


Representing a 1:M Relationship

1


Representing 1:1 and 1:M Relationships

1


Employee-Dependent Relationship

1


Representing the M:N Relationship

1


Representing the M:N Relationship with

Associated Attributes

1


Representing the M:N Relationship with

Intersection Class

1


Object Space Representation

1


Late and Early Binding:

Use and Importance

• Late binding:

– Data type of an attribute is not known until

execution time or runtime

– Two different object instances of the same

class can contain values of different data

types for the same attribute

• Early binding:

– Allows database to check data type for each of

the attribute’s values at compilation or

definition time

1


INVENTORY Table with Predetermined

(Base) Data Types

1


Inventory Class with Early Binding

1


OODM Inventory Class with Late Binding

1


Support for Versioning

• Allows users to track history of changes in

state of an object

• If the changes do not yield expected results,

they can be undone and the component

restored to its original state

• Reason OODBMS is such a strong player in

the CAD and computer-aided manufacturing

(CAM) arenas

1


OODM and Previous Data Models:

Similarities and Differences

• OODM object resembles entity and tuple in the ER and relational models but has additional characteristics

• Class

• Hierarchies

• Encapsulation

• Object ID (OID) not supported

• Relationships

• OODM produces a schema in which relations form part of the structure of the database

1


An Invoice Representation

1


Object Oriented Database Management

Systems

• Integrate benefits of typical database systems

with the more powerful modeling and

computational (programming) characteristics

of the object oriented data model

• Used to develop complex systems

1



Systems

• Result of combining OO features, such as– class inheritance

– encapsulation, and

– polymorphism,

• With database features such as– data integrity, -- data manipulation,

– security, -- system tuning and

– persistence, -- recovery

– transaction management,

– concurrency control,

– backup,

1



Systems

1


The Thirteen OODBMS Rules

1


How Object Orientation

Affects Database Design

• Relational and ER models sometimes cannot adequately represent some objects

• Operations are not a part of the database model

• Object oriented design requires the database description to include objects and their data representation, constraints, and operations

• Few computerized OODB design tools exist

• Lack of standards affects object oriented database design

1


OODBMS:

Advantages and Disadvantages

• OODBMS occupies a strong niche market

• Vehicle for technological innovation

• Has not been the beneficiary of market share

growth

1


How OO Concepts Have Influenced the

Relational Model

• RDBMS is beginning to reach its limits in a

business data environment that is changing

with the advent of mixed-media data storage

and retrieval

1


How OO Concepts Have Influenced the

Relational Model

• Extended relational model (ERM), or

object/relational model (O/RM)

– Extensibility of new user-defined (abstract)

data types

– Complex objects

– Inheritance

– Procedure calls (rules or triggers)

– System-generated identifiers (OID surrogates)

1


The Next Generation of Database

Management Systems

• Likely to incorporate features borrowed from

object oriented database systems, artificial

intelligence systems, expert systems,

distributed databases, and the Internet

• Enable future DBMSs to handle more

complex problems with both normalized and

nonnormalized data

• OODBMS will probably continue to occupy a

niche within the database market

1


Summary

• Object oriented concepts are derived from OO

programming languages

• An object is a conceptual representation of a

real-world entity

• Similar objects are grouped in classes

• Classes are organized into a class hierarchy

• Abstract data types are implemented through

classes

• The OO data model allows the designer to create

a more authentic representation of real-world

objects

1


Summary (continued)

• OODBMSs combine OO features with

database features

• OODBMSs yield several benefits over

conventional DBMSs

– more semantic information in the database

– support for complex objects

– better performance in complex applications

– reusability of classes

– extensibility of the data types supported by the

database

1

690

Chapter 12

The Data Warehouse

Database Systems:



1



• How operational data and decision support

data differ

• What a data warehouse is and how data for it

are prepared

• What star schemas are and how they are

constructed

• What steps are required to successfully

implement a data warehouse

• What data mining is and what role it plays in

decision support

1


The Need for Data Analysis

• Managers must be able to track daily

transactions to evaluate how the business is

performing

• By tapping into the operational database,

management can develop strategies to meet

organizational goals

• Data analysis can provide information about

short-term tactical evaluations and strategies

1


Solving Business Problems and Adding

Value with Data Warehouse-Based Solutions

1


Solving Business Problems and Adding Value

with Data Warehouse-Based Solutions (continued)

1


Decision Support Systems

• Methodology (or series of methodologies) designed to extract information from data and to use such information as a basis for decision making

• Decision support system (DSS):– Arrangement of computerized tools used to assist

managerial decision making within a business

– Usually requires extensive data ―massaging‖ to produce information

– Used at all levels within an organization

– Often tailored to focus on specific business areas

– Provides ad hoc query tools to retrieve data and to display data in different formats

1


Decision Support Systems (continued)

• Composed of four main components:

– Data store component

• Basically a DSS database

– Data extraction and filtering component

• Used to extract and validate data taken from operational database and external data sources

– End-user query tool

• Used to create queries that access database

– End-user presentation tool

• Used to organize and present data

1


Main Components of a

Decision Support System (DSS)

1


Transforming Operational Data Into

Decision Support Data

1


Contrasting Operational and DSS Data

Characteristics

1


Ten-Year Sales History for a Single

Department, in Millions of Dollars

1


Yearly Sales Summaries, Two Stores and Two

Departments per Store,

in Millions of Dollars

1


The Data Warehouse

• Integrated, subject-oriented, time-variant,

nonvolatile database that provides support for

decision making

1


A Comparison of Data Warehouse and

Operational Database Characteristics

1


Creating a Data Warehouse

1


DSS Architectural Styles

1


Online Analytical Processing

• Advanced data analysis environment that

supports decision making, business

modeling, and operations research

• OLAP systems share four main

characteristics:

– Use multidimensional data analysis

techniques

– Provide advanced database support

– Provide easy-to-use end-user interfaces

– Support client/server architecture

1


Operational vs. Multidimensional

View of Sales

1


Integration of OLAP

with a Spreadsheet Program

1


OLAP Client/Server Architecture

1


OLAP Server Arrangement

1


OLAP Server with Multidimensional Data

Store Arrangement

1


OLAP Server With Local Mini Data Marts

1


Bitmap Representation of REGION

Values

1


Typical ROLAP Client/Server Architecture

1


MOLAP Client/Server Architecture

1


Relational vs. Multidimensional OLAP

1


Star Schemas

• Data modeling technique used to map multidimensional decision support data into a relational database

• Creates the near equivalent of a multidimensional database schema from the existing relational database

• Yield an easily implemented model for multidimensional data analysis, while still preserving the relational structures on which the operational database is built

• Has four components: facts, dimensions, attributes, and attribute hierarchies

1


Simple Star Schema

1


Possible Attributes for Sales Dimensions

1


Three-Dimensional View of Sales

1


Slice and Dice View of Sales

1


Location Attribute Hierarchy

1


Attribute Hierarchies In Multidimensional

Analysis

1


Star Schema for Sales

1


Orders Star Schema

1


Normalized Dimension tables

1


Multiple Fact Tables

1


Implementing a Data Warehouse

• Numerous constraints:

– Available funding

– Management’s view of the role played by an

IS department and of the extent and depth of

the information requirements

– Corporate culture

• No single formula can describe perfect data

warehouse development

1


Factors Common to Data Warehousing • Data warehouse is not a static database

• Dynamic framework for decision support that is always a work in progress

• Data warehouse data cross departmental lines and geographical boundaries

• Must satisfy:

– Data integration and loading criteria

– Data analysis capabilities with acceptable query performance

– End-user data analysis needs

• Apply database design procedures

1


Data Warehouse

Implementation Road Map

1


Data Mining

• Tools that:

– analyze data

– uncover problems or opportunities hidden in

data relationships,

– form computer models based on their findings,

and then

– use the models to predict business behavior

• Require minimal end-user intervention

1


Extraction of Knowledge From Data

1


Data-Mining Phases

1


A Sample of Current Data Warehousing

and Data-Mining Vendors

1


Summary

• Data analysis is used to derive and interpret information from data

• Decision support is a methodology designed to extract information from data and to use such information as a basis for decision making

• Decision support system is an arrangement of computerized tools used to assist managerial decision making within a business

• Data warehouse is an integrated, subject-oriented, time-variant, nonvolatile database that provides support for decision making

1


Summary (continued)

• Online analytical processing is an advanced

data analysis environment that supports

decision making, business modeling, and

operations research

• Star schema is a data-modeling technique used

to map multidimensional decision support data

into a relational database

• The implementation of any company-wide

information system is subject to conflicting

organizational and behavioral factors

1


Summary (continued)

• Data mining automates analysis of operational

data with the intention of finding previously

unknown data characteristics, relationships,

dependencies, and/or trends

• Data warehouse is storage location for decision

support data

1

738

Chapter 13

Databases in Electronic Commerce

Database Systems:



1



• What electronic commerce (e-commerce) is

• About the effect of e-commerce and its

benefits and disadvantages

• About the different electronic commerce styles

• About the Internet architectural components

required to conduct electronic commerce

1



• About database design and implementation

issues for electronic commerce applications

• What Extensible Markup Language (XML) is

and why it is important

1


Orbitz E-Commerce Web Site

1


What is Electronic Commerce?

• Use of electronic networked computer-based technology to:

– Bring new products, services, or ideas to market

– Support and enhance business operations (including sales of products/services over the Web)

• Most e-commerce transactions take place among businesses

• Now recognized as a prime revenue source

1


The Road to Electronic Commerce

• Key to e-commerce is using computer networks, especially the Internet, to automate and streamline business transactions

• 1960s: banks created private telephone network to do electronic funds transfers

• 1970s: banks created services to provide afterhours services to their customers

• Late 1970s and early 1980s: Electronic Data Interchange (EDI) emerged

– Communications protocol that enabled companies to exchange business documents over private phone networks

1


The Road to Electronic Commerce

(continued)

• Early 1980s and through the 1990s: personal

computer facilitated rapid expansion of the

Internet and ultimately provided the spark that

led to the explosive use of the World Wide

Web

• Late 1990s and early 2000s: networking

technologies blossomed and expanded the

reach, speed, and in some cases, security of

Internet-based communications and

transactions

1


Amazon.com Home Page

1


The Impact of E-commerce

• Majority of businesses have a presence on

the Web

• Global market has attracted millions of

businesses and organizations to the Internet

and e-commerce

• E-commerce enables businesses to provide

services to customers, partners, employees,

and the general public

• Internet is driving the development of a new

generation of information systems

1


E-Commerce Benefits

• Easy comparison shopping

• Reduced costs and increased competition

• Convenience

• 24 × 7 × 365 operation

• Global access

• Lower entry barriers

• Increased market (customer) knowledge

1


E-Commerce Disadvantages

• Hidden costs

• Vulnerability to technical failure

• Cost of staying in business

• Lack of security

• Invasion of privacy

• Low service levels

• Legal issues

1


E-commerce Styles

• Transactions can be grouped according to the sellers and buyers:

– Business to business (B2B)

• Electronic commerce between businesses

– Business to consumer (B2C)

• Electronic commerce between business and consumers

– Intra-business

• Internal electronic commerce activities, most of which involve interactions between employers and employees

1


E-Commerce Styles

1


E-Commerce Automation of Supply Chain

1


Covisint.com: Automotive B2B

Marketplace

1


Sample B2C Web Sites

1


E-commerce Architecture

• Deployment of a well-planned architecture is

necessary to support e-commerce business

transactions, both internal and external

• E-commerce architecture can be divided into

a series of layers:

– Basic Internet services

– Business-enabling services

– E-commerce business services

1


E-Commerce Architecture

1


Internet Building Blocks and Basic

Services

1


Internet Building Blocks and Basic

Services (continued)

1


Basic Internet Services

1


Business-Enabling Services

1


Business-Enabling Services (continued)

1


Security

• Encompasses all the activities related to

protecting data and other e-commerce

components against accidental or intentional

(usually illegal) access or use by

unauthorized users

• Privacy

– Deals with the rights of individuals and

organizations to determine the ―who, what,

when, where, and how‖ of data use

1


Security (continued)

• Security (procedures and technology) must

be maintained to:

– Authenticate identity of transaction participants

– Protect transaction data from unauthorized

modifications

– Protect resources (data and computers)

1


A Sample E-Commerce Transaction

1


Registering with a Certification Authority

1


Web Browser Security Settings

1


Web Browser Secure Session

1


Web Browser Proxy Settings

1


Web Payment Processing

• Key function of e-commerce Web sites is their ability to

process online payments for products and/or services

– Digital cash

• Digital equivalent of hard currency

– Online credit card processing

– Electronic wallets

• Equivalent of a physical wallet—can contain credit

card information, digital cash, and other personal

information such as shipping addresses, phone

numbers, and e-mail addresses

1


Setting Up a Microsoft Electronic Wallet

1


Database Design for E-commerce

Applications

• Define scope of database

• Establish some basic business rules and their

effect(s) on the design

• Define tables required to support the e-

commerce activities

• Identify basic attributes for each table

1


Main Tables for E-Commerce Database

1


CUSTOMER Table

1


CUSTOMER Table (Continued)

1


PRODUCT Table

1


PRODUCT Table (Continued)

1


PRODTYPE Table

1


ORDER Table

1


ORDER Table (Continued)

1


ORDLINE Table

1


SHOPCART Table

1


PMTTYPE Table

1


SHIPTYPE Table

1


TAXRATE Table

1


STATE Table

1


PROMOTION Table

1


PRICEWATCH Table

1


PRODPRICE Table

1


Extensible Markup Language (XML)

• Meta-language used to represent and

manipulate data elements

• Designed to facilitate the exchange of

structured documents such as orders or

invoices over the Internet

• World Wide Web Consortium published the

first XML 1.0 standard definition in 1998

1


Contents of the ProductList.xml

Document

1


Contents of the ProductList.dtd Document

1


Contents of the ProductListv2.xml

Document

1


DTD and XML Documents for Order Data

1


The XML Schema Document for the

Order Data

1


Framework for XML Transformations

1


Displaying XML Documents in MSIE 5.0

1


XML Data Binding in MSIE 5.0

1


Summary

• E-commerce is the use of electronic

computer-based technology to

– bring new products, services, or ideas to

market, and to

– support enhanced business operations

• E-commerce enables companies to market

and sell products and/or services to a global

market of millions of users

1


Summary (continued)

• Adoption of e-commerce technologies

enables companies to provide rapid

responses to competitive pressures by

enhancing internal operations and facilitating

business transactions

• E-commerce can be classified as business to

business (B2B), business to consumer (B2C),

and intra-business

1


Summary (continued)

• E-commerce architecture provides a

framework that describes the technical

components of e-commerce Web sites and

their interactions

• Security and privacy of business transactions

and data are crucial for the success of e-

commerce

• Credit card processing and digital cash are

the most common ways to process payments

on the Internet

1


Summary (continued)

• E-commerce databases contain normalized

structures that are similar to typical

operational databases

• Extensible Markup Language (XML)

facilitates the exchange of B2B data over the

Internet

1

801

Chapter 14

Web Database Development

Database Systems:



1



• How Internet databases are typically used

• About the architecture of Web-to-database

middleware

• How Web-to-database middleware

(ColdFusion) is used to integrate databases

with the Internet

• What special considerations govern Web

database development

1


Internet Technologies and Databases

• Web database connectivity allows new

innovative services that:

– Allow rapid response to competitive pressures

by bringing new services and products to

market quickly

– Increase customer satisfaction through

creation of Web-based support services

– Yield fast and effective information

dissemination through universal access from

across the street or across the globe

1


Characteristics and Benefits

of Internet Technologies

1


Typical Uses of Internet Databases

• Share information businesses are willing to make public

• Shared information is likely to be based on non-critical data

• Provide marketing and customer support

• Provide corporate information to users inside the company (intranets)

• Provide relevant information to users of another company with which the company does business (extranets)

• Develop applications

1


A Sample of Applications That Use Web-

Database Technology

1


Web-to-Database Middleware:

Server-side Extensions

• Also known as Web-to-database middleware

• Program that interacts directly with Web

server to handle specific types of requests

• Provides its services to the Web server in a

way that is totally transparent to the client

browser

1


Web-to-Database Middleware

(ColdFusion)

1


Web Server Interfaces

1


Windows Applications Use ODBC to

Access Databases

1


Web-to-Database Middleware Uses

ODBC to Access Databases

1


The Web Browser

• Software that lets users navigate (browse) the

Web

• Located in client computer

• End-user interface to the World Wide Web

• Interprets HTML code received from Web

server

• Presents different page components in a

standard way

1


Client-side Extensions

• Client-side extensions

– Add functionality to Web browser

– Three general types:

• Plug-ins

• Java and JavaScript

• ActiveX and VBScript

1


Using a Web-to-Database

Production Tool: ColdFusion

• Web application server:

– Middleware application that expands Web

server functionality by linking it to a wide range

of services

– Provides consistent run-time environment for

Web applications

1



Production Tool: ColdFusion (continued)

• ColdFusion application middleware can be

used to:

– Connect to and query a database from a Web

page

– Present database data in a Web page, using

various formats

– Create dynamic Web search pages

– Create Web pages to insert, update, and

delete database data

1



Production Tool: ColdFusion (continued)

– Define required and optional relationships

– Define required and optional form fields

– Enforce referential integrity in form fields

– Use simple and nested queries and form

select fields to represent business rules

1


How ColdFusion Works

1


The Ch14_RobCor Database’s Relational

Schema

1


A Simple Query Using CFQUERY and

CFOUTPUT

1


The rc-1.cfm Script Output

(Vertical Listing)

1


CFQUERY with Tabular CFOUTPUT

1



(Horizontal Listing)

1


CFQUERY with CFTABLE

1



(Formatted Horizontal Listing)

1


Dynamic Search Query:

Criteria Entry Form

1


The rc-4a.cfm Script Output

(State Search Criteria Entry Form)

1


The VENDOR Search Results

1


The rc-4b.cfm Script Output

(Vendor Search Results: All States)

1


The Vendor List for the Condition

VEN_STATE = ―GA‖

1


Insert Query: Data Entry Script

1



(Department Data Entry Screen)

1


The Insert Query Form:

Server-Side Validation Error Message

1


Insert Query: Confirmation Script

1



(Department Data Entry Confirmation)

1


The Insert Query:

ODBC Integrity Violation Error

1


Update Query: Record Selection Script

1



(Record Selection Screen)

1


Update Query: Edit Record Script

1



(Edit Record Screen)

1


Update Query: Result Confirmation Script

1


The rc-6c.cfm Script Output

(Update Query Result Confirmation)

1


Delete Query: Record Selection Script

1



(Record Selection Screen)

1


Delete Query: Show Record Script

1



(Show Record Screen)

1


Delete Query: Result Confirmation Script

1


The rc-7c.cfm Script Output

(Delete Query Confirmation Screen)

1


The Delete Record Validation

1


Internet Database Systems:

Special Considerations

• Internet database systems involve more than

just the development of database-enabled

Web applications

• Database systems development requires

sound database design and implementation

• Concurrent database access by multiple

heterogeneous clients affects how

transactions are defined and managed

1


Internet Database Systems:

Special Considerations (continued)

• If database systems are to be developed and

managed intelligently, today’s database

administrator must understand the Internet-

based business environment to successfully

cope with the issues that drive the

development, use, and management of Web-

to-database interfaces

1


Summary

• Internet is a worldwide network of computers

running the TCP/IP suite of network protocols

• Web server provides standard interfaces

such as the Common Gateway Interface

(CGI) and the application programming

interface (API)

• Database access through the Web is

achieved through database-to-middleware

software

1


Summary (continued)

• ColdFusion is a Web application server that

provides database access (among other

services) to the Web

• Developing applications for the

Internet/intranets/extranets means

overcoming limitations of the Web interface

1

853

Chapter 15

Database Administration

Database Systems:



1



• That data are a valuable business asset that

requires careful management

• Why and how the database plays a critical

role in an organization

• That the introduction of a DBMS has

important technological, managerial, and

cultural organizational consequences

1



• What the database administrator’s

managerial and technical roles are

• About several database administration tools

• About various database administration

strategies

• How various database administration

technical tasks are performed with Oracle

1


Data as a Corporate Asset

• Data are accepted as a valuable asset

requiring careful management

• Data are now well understood as a valuable

resource to be translated into information

• If information is accurate and timely, its use is

likely to enhance company’s competitive

position and generate wealth

1


Fig 15.1 The Data-Information-Decision-

Making Cycle

1


The Need for and Role of Databases

in an Organization

• Database’s predominant role is to support

managerial decision making at all levels in

the organization

• DBMS must provide tools that give each level

of management a different view of the data

and support required level of decision making

1


Introduction of a Database:

Special Considerations

• Having a computerized database

management system does not guarantee that

the data will be properly used to provide best

solutions required by managers

1


Introduction of a Database:

Special Considerations (continued)

• Introduction of a DBMS is likely to have a

profound impact, which might be positive or

negative, depending on how it is administered

• Three important aspects

– Technological: DBMS software and hardware

– Managerial: Administrative functions

– Cultural: Corporate resistance to change

1


The Evolution of the Database

Administration Function

• Data administration has its roots in the old, decentralized world of the file system

• Advent of the DBMS and its shared view of data produced a new level of data management sophistication and led the DP department to evolve into an information systems (IS) department

• Data management became an increasingly complex job, thus leading to development of the database administration function

1


The IS Department Internal Organization

1


The Placement of the DBA Function

1


A DBA Functional Organization

1


Multiple Database Administrators

in an Organization

1


The Database Environment’s

Human Component

• Even the most carefully crafted database

system cannot operate without a human

component

• Effective data administration requires both

technical and managerial skills

• DA must set data administration goals

• DBA is the focal point for data/user interaction

• Need for diverse mix of skills

1


Contrasting DA and DBA Activities

and Characteristics

1


A Summary of DBA Activities

1


Desired DBA Skills

1


DBA Activities and Services

1


Database Administration Tools

• Two main types of data dictionaries:

– Integrated

– Standalone

• Main function: store description of all objects

that interact with the database

1


Database Administration Tools (continued)

• Possible to manage use and allocation of all

organization’s information, regardless of

whether it has roots in database data

• Metadata stored in data dictionary are often

basis for monitoring database use and

assignment of access rights to database

users

1


An Example of a CASE Tool:

Visio Professional

1


Developing a Database

Administration Strategy

• Critical step for any organization is to ensure

its information system supports strategic

plans for each of the company’s business

areas

• Database administration strategy must not

conflict with information systems plans

1


Developing a Database

Administration Strategy (continued)

• Information engineering

– Translates strategic company goals into the

data and applications that will help company

achieve those goals

– Output of the IE process is an information

systems architecture that serves as basis for

planning, development, and control of future

information systems

1


Forces Affecting the Development

of the ISA

1


The DBA at Work:

Using Oracle for Database Administration

• Execution of tasks tends to be DBMS-and

operating-system specific

• Brief introduction to the way some typical

DBA tasks would be performed in Oracle

1


The Oracle Enterprise Manager Interface

1


Oracle Edit Local Preferred

Credentials Window

1


Oracle RDBMS Services

1


The Oracle Storage Manager

1


Creating a New Tablespace

1


The Oracle Schema Manager

1


The Oracle Security Manager

1


The Create User Dialog Box

1


The Oracle Instance Manager

1


Creating a New Database with the

Database Configuration Assistant

1


Selecting the New Database Template

1


Naming the Database

1


Selecting the Database Operation Mode

1


Specifying Initialization Parameters

1


Specifying Storage Parameters

1


Database Creation Options

1


Summary of Database Creation Options

1


Database Creation Progress

1


Summary• Data management is critical for any

organization

• Data should be treated as corporate asset with monetary value

• DBMS is most commonly used electronic tool for corporate data management

• Impact of the DBMS on the organization’s managerial and cultural framework must be carefully examined

• Data administration function was developed in response to changes in data management fostered by technological advances in computer systems

1


Summary (continued)

• Database administrator (DBA) is responsible for corporate database management

• Broader data management activity is handled by data administrator (DA)

• DA is more managerially oriented than the more technically oriented DBA

• Development of data administration strategy is closely related to the company’s mission and objectives

• Implementing the overall company strategy is a crucial process influenced by managerial, technological, and cultural issues