Database Systems

Chapter 1

Database Systems

Database Systems:

Design, Implementation, and Management,

Sixth Edition, Rob and Coronel

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

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

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

Sales per Employee for Each of

ROBCOR’s Two Divisions

Introducing the Database

and the DBMS

• Database—shared, integrated computer

structure that houses:

– End user data (raw facts)

– Metadata (data about data)

Introducing the Database

and the DBMS (continued)

• DBMS (database management system):

– Collection of programs that manages

database structure and controls access to

– Possible to share data among multiple

applications or users

– Makes data management more efficient and

effective

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

The DBMS Manages the Interaction

Between the End User and the Database

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

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

Location of Databases

• Centralized:

– Supports data located at a single site

• Distributed:

– Supports data distributed across several sites

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

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

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

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

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)

Contents of Customer File

Basic File Terminology

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

(continued)

• Other departments requested databases be

written for them

– SALES database created for sales department

– AGENT database created for personnel

department

Contents of the Agent File

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

A Simple File System

(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

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

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

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

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

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

Field Definitions

and Naming Conventions

• Flexible record definition anticipates reporting

requirements by breaking up fields into their

component parts

Sample Customer File Fields

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

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

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

Contrasting Database and File Systems

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

The Database System Environment

(continued)

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

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

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

Illustrating Metadata

with Microsoft Access

Illustrating Data Storage Management

with Oracle

Summary

• Information is derived from data, which is stored

in a database

• To implement and manage a database, use a

• Database design defines its structure

• Good design is important

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

Chapter 2

Data Model

Database Systems:

• 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

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

Importance of Data Modeling

• End-users have different views and needs for

• Data model organizes data for various users

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

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

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

Sources of Business Rules

• Company managers

• Policy makers

• Department managers

• Written documentation

– Procedures

– Standards

– Operations manuals

• Direct interviews with end users

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

The Evolution of Data Models

• Hierarchical

• Network

• Relational

• Entity relationship

• Object oriented

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

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

A Hierarchical Structure

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

The Hierarchical Model

• Advantages

– Conceptual simplicity

– Database security

– Data independence

– Database integrity

– Efficiency

The Hierarchical Model (continued)

• Disadvantages

– Complex implementation

– Difficult to manage

– Lacks structural independence

– Complex applications programming and use

– Implementation limitations

– Lack of standards

Child with Multiple Parents

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)

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

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

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

A Network Data Model

The Network Data Model

• Advantages

– Conceptual simplicity

– Handles more relationship types

– Data access flexibility

– Promotes database integrity

– Data independence

– Conformance to standards

The Network Data Model (continued)

• Disadvantages

– System complexity

– Lack of structural independence

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

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

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

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

A Relational Schema

Linking Relational Tables

The Relational Model

• Advantages

– Structural independence

– Improved conceptual simplicity

– Easier database design, implementation,

management, and use

– Ad hoc query capability

– Powerful database management system

The Relational Model (continued)

• Disadvantages

– Substantial hardware and system software

overhead

– Can facilitate poor design and implementation

– May promote ―islands of information‖ problems

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

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

Relationships: The Basic Chen ERD

Relationships:

The Basic Crow’s Foot ERD

The Entity Relationship Model

• Advantages

– Exceptional conceptual simplicity

– Visual representation

– Effective communication tool

– Integrated with the relational data model

The Entity Relationship Model (continued)

• Disadvantages

– Limited constraint representation

– Limited relationship representation

– No data manipulation language

– Loss of information content

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)

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

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

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

A Comparison of the OO Model

and the ER Model

The Object Oriented Model

• Advantages

– Adds semantic content

– Visual presentation includes semantic content

– Database integrity

– Both structural and data independence

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

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

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

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

The Development of Data Models

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

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

– A powerful DBMS graphical user interface

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

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

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

Data Abstraction Levels

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

A Conceptual Model for Tiny College

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

The Internal Model

• Representation of the database as ―seen‖ by

the DBMS

• Adapts the conceptual model to the DBMS

• Software dependent

• Hardware independent

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

A Division of an Internal Model into

External Models

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

The External Model

• DBMS dependent

• Hardware independent

The External Models for Tiny College

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

Levels of Data Abstraction

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

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

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

Chapter 3

The Relational Database Model

Database Systems:

• 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

• 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

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

Tables and Their Characteristics

• Table: two-dimensional structure composed of

rows and columns

• Contains group of related entities an entity

– Terms entity set and table are often used

interchangeably

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

Characteristics of a Relational Table

Table 3.1

STUDENT Table Attribute Values

• 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

Student Classification

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

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

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

An Example of a

Simple Relational Database

The Relational Schema for the

CH03_SaleCo Database

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

Relational Database Keys

Integrity Rules

An Illustration of Integrity Rules

A Dummy Variable Value Used as a Flag

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

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

Intersect

• 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

Difference

Product

• 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

Select

Project

• 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

Two Tables That Will Be Used

in Join Illustrations

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

Natural Join, Step 1: PRODUCT

Natural Join, Step 2: SELECT

Natural Join, Step 3: PROJECT

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

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

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

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

Left Outer Join

Right Outer Join

Divide

• DIVIDE requires the use of one single-column

table and one two-column table

DIVIDE

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

A Sample Data Dictionary

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

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

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

The 1:1 Relationship Between

PROFESSOR and DEPARTMENT

The Implemented 1:1 Relationship Between

PROFESSOR and DEPARTMENT

The 1:M Relationship

Between PAINTER and PAINTING

The Implemented 1:M Relationship

Between PAINTER and PAINTING

The 1:M Relationship

Between COURSE and CLASS

The Implemented 1:M Relationship

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

The ERD’s M:N Relationship

Between STUDENT and CLASS

Sample Student Enrollment Data

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

Converting the M:N Relationship

into Two 1:M Relationships

Changing the M:N Relationship

to Two 1:M Relationships

The Expanded Entity Relationship Model

Ch03_TinyCollege Database

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

A Small Invoicing System

The Relational Schema

for the Invoicing System

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

Components of an Index

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

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

Chapter 4

Entity Relationship (ER) Modeling

Database Systems:

• 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

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

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

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

The Attributes of the STUDENT Entity

Domains

• Attributes have a domain:

– The attribute’s set of possible values

• Attributes may share a domain

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

The CLASS Table (Entity)

Components and Contents

Attributes

• Composite attribute

• Simple attribute

• Single-value attribute

• Multivalued attributes

A Multivalued Attribute in an Entity

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

Splitting the Multivalued

Attribute into New Attributes

Components of the Multivalued Attribute

A New Entity Set Composed of a

Multivalued Attribute’s Components

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

Depiction of a Derived Attribute

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

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

Connectivity and Cardinality in an ERD

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

A Weak (Non-Identifying) Relationship

A Weak Relationship

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

A Strong (Identifying) Relationship

An Optional CLASS Entity in the Relationship

PROFESSOR teaches CLASS

COURSE and CLASS

in a Mandatory Relationship

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

A Weak Entity in an ERD

A Weak Entity in a Strong Relationship

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

Three Types of Relationships

The Implementation

of a Ternary Relationship

Recursive Relationships

• Relationship can exist between occurrences

of the same entity set

• Naturally found within a unary relationship

An ER Representation

of Recursive Relationships

The 1:1 Recursive Relationship

―EMPLOYEE is Married to EMPLOYEE‖

Implementation of the M:N Recursive

―PART Contains PART‖ Relationship

Implementation of the 1:M ―EMPLOYEE

Manages EMPLOYEE‖ Recursive Relationship

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

Converting the M:N Relationship

into Two 1:M Relationships

A Composite Entity in an ERD

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

Nulls Created by Unique Attributes

A Generalization Hierarchy

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

The EMPLOYEE/PILOT

Supertype/Subtype Relationship

A Generalization Hierarchy

with Overlapping Subtypes

A Comparison of ER Modeling Symbols

The Chen Representation

of the Invoicing Problem

The Crow’s Foot Representation

The Rein85 Representation

The IDEF1X Representation

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

A Supertype/Subtype Relationship

in an ERD

Components of the ER Model

The Completed Tiny College ERD

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

Various Implementations

of a 1:1 Recursive Relationship

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

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

Chapter 5

Normalization of Database Tables

Database Systems:

• 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

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)

Database Tables and Normalization

(continued)

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

– 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

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

A Sample Report Layout

A Table in the Report Format

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

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

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

Data Organization: First Normal Form

Step 2: Identify the Primary Key

• Primary key must uniquely identify attribute

• New key must be composed

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

A Dependency Diagram:

First Normal Form (1NF)

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

Conversion to Second Normal Form

• Relational database design can be improved

by converting the database into second

normal form (2NF)

• Two steps

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

Step 2: Identify the Dependent Attributes

• Determine which attributes are dependent on

which other attributes

• At this point, most anomalies have been

eliminated

Second Normal Form (2NF)

Conversion Results

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

Conversion to Third Normal Form

• Data anomalies created are easily eliminated

by completing three steps

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

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

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

Third Normal Form (3NF)

Conversion Results

Third Normal Form

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

– It is in 2NF and

– It contains no transitive dependencies

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

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

The Completed Database

The Completed Database (continued)

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

Duplicate Entries in the JOB Table

The Boyce-Codd Normal Form (BCNF)

• Every determinant in the table is a candidate

– 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

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

A Table That is in 3NF but not in BCNF

Decomposition to BCNF

Sample Data for a BCNF Conversion

Another BCNF Decomposition

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

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

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

The Initial ERD for a

Contracting Company

The Modified ERD for a

Contracting Company

The Incorrect Representation

of a M:N Relationship

The Final (Implementable) ERD for a

Contracting Company

The Implemented Database for the

Contracting Company

Higher-Level Normal Forms

• In some databases, multiple multivalued

attributes exist

Tables with Multivalued Dependencies

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

A Set of Tables in 4NF

Denormalization

• Creation of normalized relations is important

database design goal

• Processing requirements should also be a

• If tables decomposed to conform to

normalization requirements

– Number of database tables expands

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

• 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

• Use denormalization cautiously

• Understand why—under some

circumstances—unnormalized tables are a

better choice

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

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

Chapter 6

Introduction to Structured Query

Language (SQL)

Database Systems:

• 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

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

• 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

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

SQL Data Definition Commands

Data Manipulation Commands

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

The Database Model

Creating the Database

• Two tasks must be completed

– create the database structure

– create the tables that will hold the end-user

• First task

– RDBMS creates the physical files that will hold

the database

– Tends to differ substantially from one RDBMS

to another

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

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

Some Common SQL Data Types

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

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

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

A Duplicated TEST Record

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

Common SQL Data Manipulation

Commands

A Data View and Entry Form

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

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

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

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

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

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

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 ] ;

Selected PRODUCT Table Attributes for

VENDOR Code 21344

The Microsoft Access QBE and its SQL

Comparison Operators

Selected PRODUCT Table Attributes for

VENDOR Codes Other than 21344

Selected PRODUCT Table Attributes

with a P_PRICE Restriction

Selected PRODUCT Table Attributes:

The ASCII Code Effect

Date Restriction

SELECT Statement

with a Computed Column

SELECT Statement with a Computed

Column and an Alias

Arithmetic Operators:

The Rule of Precedence

• Perform operations within parentheses

• Perform power operations

• Perform multiplications and divisions

• Perform additions and subtractions

The Logical OR

The Logical AND

The Logical AND and OR

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

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

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

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

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

The Effect of Data Entry into the New

P_SALECODE Column

Update of the P_SALECODE Column in

Multiple Data Rows

The Effect of Multiple Data Updates in the

PRODUCT Table (MS Access)

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

PART Attributes Copied

from the PRODUCT Table

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

Ordered by (Ascending) P_PRICE

Partial Listing of

EMPLOYEE Table Contents

Telephone List Query Results

A Query Based on Multiple Restrictions

A Listing of Distinct (Different) V_CODE

Values in the PRODUCT Table

Some Basic SQL Aggregate Functions

COUNT Function Output Examples

MAX and MIN Function Output Examples

The Total Value of All Items

in the PRODUCT Table

AVG Function Output Examples

GROUP BY Clause Output Examples

Incorrect and Correct Use

of the GROUP BY Clause

An Application of the HAVING Clause

Virtual Tables: Creating a View

• View is a virtual table based on a SELECT

– Can contain columns, computed columns,

aliases, and aggregate functions from one or

more tables

• Base tables are tables on which the view is

• Create a view by using the CREATE VIEW

command

Creating a Virtual Table

with the CREATE VIEW Command

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

Creating Links Through Foreign Keys

The Results of a Join

An Ordered and Limited Listing

After a JOIN

The Contents of the EMP Table

Using an Alias to Join a Table to Itself

The Left Outer Join Results

The Right Outer Join Results

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

• Implementation decisions vary according to

the problem being addressed

The Ch06_Artist Database ERD

and Tables

A Data Dictionary

for the Ch06_Artist Database

A Summary of Foreign Key Rules

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

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

Chapter 7

Advanced SQL

Database Systems:

• 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

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

UNION Query Result

UNION ALL Query Result

INTERSECT Query Result

MINUS Query Results

INTERSECT Alternative

MINUS Alternative

SQL Join Expression Styles

NATURAL JOIN Result

JOIN USING Result

JOIN ON Result

Outer Joins

• Returns not only rows matching join condition

but also rows with unmatched values

• Three types:

– Left

– Right

– Full

LEFT JOIN Result

RIGHT JOIN Result

FULL JOIN Result

SELECT Subquery Examples

WHERE Subquery Examples

IN Subquery Example

HAVING Subquery Example

Multirow Subquery Operator Example

FROM Subquery Example

Inline Subquery Example

Correlated Subquery Examples

EXISTS Correlated Subquery Examples

Selected MS Access/SQL Server

Date/Time Functions

Selected Oracle Date/Time Functions

(continued)

Selected Oracle Numeric Functions

Selected Oracle String Functions

Selected Oracle Conversion Functions

(continued)

Oracle Sequence

Oracle Sequence Examples

The PRODMASTER

and PRODSALES Tables

The Oracle UPDATE Error Message

Creating an Updatable View in Oracle

PRODMASTER Table Update,

Using an Updatable View

Anonymous PL/SQL Block Examples

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

Anonymous PL/SQL Block

with Variables and Loops

PL/SQL Basic Data Types

The PRODUCT Table

Creating the

TRG_PRODUCT_REORDER Trigger

Verifying the TRG_PRODUCT_REORDER

Trigger Execution

The P_REORDER Value Mismatch After

Update of the P_MIN Attribute

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

Creating the PRC_PROD_DISCOUNT

Stored Procedure

Results of the PRC_PROD_DISCOUNT

Stored Procedure

The PRC_CUS_ADD Stored Procedure

The PRC_INV_ADD and

PRC_LINE_ADD Stored Procedures

Testing the PRC_INV_ADD and

PRC_LINE_ADD Procedures

Cursor Processing Commands

Cursor Attributes

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

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

SQL Status and Error Reporting Variables

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

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

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

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

Chapter 8

Database Design

Database Systems:

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

• 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

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

A Simple Cross-Classification Table:

Transforming Data into Information

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

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

Generating Information

for Decision Making

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

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

(SDLC) (continued)

• Divided into five phases

1. Planning

2. Analysis

3. Detailed systems design

4. Implementation

5. Maintenance

• Iterative rather than sequential process

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

(SDLC)

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

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

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

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

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

The Database Life Cycle (DBLC)

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

Summary of Activities in the Database

Initial Study

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

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

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?

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

Database Design

• Necessary to concentrate on the data

• Characteristics required to build database

• 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

Two Views of Data:

Business Manager and Designer

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

Procedure Flow in the Database Design

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

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

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

Developing the Conceptual Model

Using ER Diagrams

A Composite Entity

Data Redundancies in the VIDEO Table

ER Modeling Is an Iterative Process

Based on Many Activities

Conceptual Design Tools

and Information Sources

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

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

The ER Model Verification Process

Iterative ER Model Verification Process

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

DBMS Software Selection

• Critical to the information system’s smooth

operation

• Advantages and disadvantages should be

carefully studied

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

A Simple Conceptual Model

Sample Layout for the COURSE Table

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

Implementation and Loading

• New database implementation requires the

creation of special storage-related constructs

to house the end-user tables

Physical Organization of a DB2 Database

Environment

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

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

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

Integrity

• Enforced through proper use of primary and

foreign key rules

Company Standards

• May partially define database standards

• Database administrator must implement and

enforce such standards

Concurrency Control

• Feature that allows simultaneous access to a

database while preserving data integrity

• Failure to maintain can quickly destroy a

database’s effectiveness

The Need for Concurrency Control

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

Operation

• Once the database has passed the

evaluation stage, it is considered operational

• Beginning of the operational phase starts the

process of system evolution

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

Parallel Activities in the

DBLC and the SDLC

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

Top-Down vs. Bottom-Up Design

Sequencing

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

Centralized Design

Decentralized Design

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

Summary of Aggregation Problems

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

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

Chapter 9

Transaction Management and

Concurrency Control

Database Systems:

• 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

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

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

Ch09_SaleCo Database

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

Tracing the Transaction in the

Ch09_SaleCo Database

Figure 9.2

Transaction Properties

• Atomicity

– Requires that all operations (SQL requests) of

a transaction be completed

• Durability

– Indicates permanence of database’s

consistent state

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

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

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

A Transaction Log

Concurrency Control

• Coordination of simultaneous transaction

execution in a multiprocessing database

system

• Objective is to ensure transaction

serializability in a multiuser database

environment

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

Normal Execution of Two Transactions

Lost Updates

Correct Execution of Two Transactions

An Uncommitted Data Problem

Retrieval During Update

Transaction Results:

Data Entry Correction

Inconsistent Retrievals

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

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

Read/Write Conflict Scenarios:

Conflicting Database Operations Matrix

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

Lock Granularity

• Indicates the level of lock use

• Locking can take place at the following levels:

– Database

– Table

– Page

– Row

– Field (attribute)

Lock Granularity (continued)

• Database-level lock

– Entire database is locked

• Table-level lock

– Entire table is locked

• Page-level lock

– Entire diskpage is locked

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

A Database-Level Locking Sequence

An Example of a Table-Level Lock

Example of a Page-Level Lock

An Example of a Row-Level Lock

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

An Example of a Binary Lock

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

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

Two-Phase Locking Protocol

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

How a Deadlock Condition Is Created

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

• Monotonicity

– Ensures that time stamp values always

increase

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

Wait/Die and Wound/Wait

Concurrency Control Schemes

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

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)

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

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

A Transaction Log for Transaction

Recovery Examples

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

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

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

Chapter 10

Distributed Database

Management Systems

Database Systems:

• 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

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

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

Centralized Database Management

System

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

DDBMS Disadvantages

• Complexity of management and control

• Security

• Lack of standards

• Increased storage requirements

• Greater difficulty in managing the data

environment

• Increased training cost

Distributed Processing Environment

Distributed Database Environment

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

Characteristics of Distributed

Management Systems (continued)

• Must perform all the functions of a centralized

• Must handle all necessary functions imposed

by the distribution of data and processing

• Must perform these additional functions

transparently to the end user

A Fully Distributed Database

Management System

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

Distributed Database System

Components

Database Systems: Levels of Data and

Process Distribution

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

Single-Site Processing, Single-Site Data

(Centralized)

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

Multiple-Site Processing, Single-Site Data

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

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

Heterogeneous Distributed

Database Scenario

Distributed Database

Transparency Features

• Allow end user to feel like database’s only

• Features include:

– Distribution transparency

– Transaction transparency

– Failure transparency

– Performance transparency

– Heterogeneity transparency

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

A Summary of Transparency Features

Fragment Locations

Transaction Transparency

• Ensures database transactions will maintain

distributed database’s integrity and

consistency

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

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

A Remote Request

A Remote Transaction

A Distributed Transaction

A Distributed Request

Another Distributed Request

Distributed Concurrency Control

• Multisite, multiple-process operations are

much more likely to create data

inconsistencies and deadlocked transactions

than are single-site systems

The Effect of a Premature COMMIT

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

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

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

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

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

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

A Sample CUSTOMER Table

Horizontal Fragmentation of the

CUSTOMER Table by State

Table Fragments in Three Locations

Vertically Fragmented Table Contents

Mixed Fragmentation of the

CUSTOMER Table

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

Table Contents After the Mixed

Fragmentation Process

Data Replication

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

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

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

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

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

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

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

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

Chapter 11

Object Oriented Databases

Database Systems:

• 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

• About the advantages and disadvantages of

OODBMSs

• How OO concepts have influenced the

relational model

• How Oracle9i implements object extensions

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

Object Orientation Contributions

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

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

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

Object Oriented Concepts

• Have their roots in programming languages

• No knowledge of programming is necessary

to understand these concepts

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

Real-World Student Objects

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

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

Object Attributes

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

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

Depiction of an Object

Method Components

Objects Send Messages to Each Other

Classes

• Collection of similar objects with shared

structure (attributes) and behavior (methods)

• Class instance or object instance

– Each object in a class

Class Illustration

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

Public and Private Aspects of an Object

OO Summary: Object Characteristics

Musical Instruments Class Hierarchy

Single Inheritance

Multiple Inheritance

Motor Vehicle and Bicycle Instance

Variables

Employee Class Hierarchy Method

Override

Employee Class Hierarchy Polymorphism

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

Object Classification

• Simple object

• Composite object

• Compound object

• Hybrid object

• Associative object

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

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)

Comparing the OO and ER Model

Components

Shared Representation for All Objects of

the Class Person

State of a Person Object Instance

Defining Three Abstract Data Types

Object Representation for Instances of

the Class Person with ADTs

Object State for an Instance of the Class

Person, Using ADTs

Referential Object Sharing

Class Hierarchy

Employee Object Representation

Class Hierarchy for the EDLP Retail

Corporation

Representing a 1:M Relationship

Representing 1:1 and 1:M Relationships

Employee-Dependent Relationship

Representing the M:N Relationship

Representing the M:N Relationship with

Associated Attributes

Representing the M:N Relationship with

Intersection Class

Object Space Representation

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

INVENTORY Table with Predetermined

(Base) Data Types

Inventory Class with Early Binding

OODM Inventory Class with Late Binding

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

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

An Invoice Representation

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

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,

Systems

The Thirteen OODBMS Rules

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

OODBMS:

Advantages and Disadvantages

• OODBMS occupies a strong niche market

• Vehicle for technological innovation

• Has not been the beneficiary of market share

growth

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

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)

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

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

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

Chapter 12

The Data Warehouse

Database Systems:

• 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

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

Solving Business Problems and Adding

Value with Data Warehouse-Based Solutions

Solving Business Problems and Adding Value

with Data Warehouse-Based Solutions (continued)

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

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

Main Components of a

Decision Support System (DSS)

Transforming Operational Data Into

Decision Support Data

Contrasting Operational and DSS Data

Characteristics

Ten-Year Sales History for a Single

Department, in Millions of Dollars

Yearly Sales Summaries, Two Stores and Two

Departments per Store,

in Millions of Dollars

The Data Warehouse

• Integrated, subject-oriented, time-variant,

nonvolatile database that provides support for

decision making

A Comparison of Data Warehouse and

Operational Database Characteristics

Creating a Data Warehouse

DSS Architectural Styles

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

Operational vs. Multidimensional

View of Sales

Integration of OLAP

with a Spreadsheet Program

OLAP Client/Server Architecture

OLAP Server Arrangement

OLAP Server with Multidimensional Data

Store Arrangement

OLAP Server With Local Mini Data Marts

Bitmap Representation of REGION

Values

Typical ROLAP Client/Server Architecture

MOLAP Client/Server Architecture

Relational vs. Multidimensional OLAP

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

Simple Star Schema

Possible Attributes for Sales Dimensions

Three-Dimensional View of Sales

Slice and Dice View of Sales

Location Attribute Hierarchy

Attribute Hierarchies In Multidimensional

Analysis

Star Schema for Sales

Orders Star Schema

Normalized Dimension tables

Multiple Fact Tables

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

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

Data Warehouse

Implementation Road Map

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

Extraction of Knowledge From Data

Data-Mining Phases

A Sample of Current Data Warehousing

and Data-Mining Vendors

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

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

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

Chapter 13

Databases in Electronic Commerce

Database Systems:

• 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

• About database design and implementation

issues for electronic commerce applications

• What Extensible Markup Language (XML) is

and why it is important

Orbitz E-Commerce Web Site

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

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

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

• Late 1990s and early 2000s: networking

technologies blossomed and expanded the

reach, speed, and in some cases, security of

Internet-based communications and

transactions

Amazon.com Home Page

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

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

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

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

E-Commerce Styles

E-Commerce Automation of Supply Chain

Covisint.com: Automotive B2B

Marketplace

Sample B2C Web Sites

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

E-Commerce Architecture

Internet Building Blocks and Basic

Services

Internet Building Blocks and Basic

Services (continued)

Basic Internet Services

Business-Enabling Services

Business-Enabling Services (continued)

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

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)

A Sample E-Commerce Transaction

Registering with a Certification Authority

Web Browser Security Settings

Web Browser Secure Session

Web Browser Proxy Settings

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

Setting Up a Microsoft Electronic Wallet

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

Main Tables for E-Commerce Database

CUSTOMER Table

CUSTOMER Table (Continued)

PRODUCT Table

PRODUCT Table (Continued)

PRODTYPE Table

ORDER Table

ORDER Table (Continued)

ORDLINE Table

SHOPCART Table

PMTTYPE Table

SHIPTYPE Table

TAXRATE Table

STATE Table

PROMOTION Table

PRICEWATCH Table

PRODPRICE Table

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

Contents of the ProductList.xml

Document

Contents of the ProductList.dtd Document

Contents of the ProductListv2.xml

Document

DTD and XML Documents for Order Data

The XML Schema Document for the

Order Data

Framework for XML Transformations

Displaying XML Documents in MSIE 5.0

XML Data Binding in MSIE 5.0

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

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

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

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

Chapter 14

Web Database Development

Database Systems:

• 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

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

Characteristics and Benefits

of Internet Technologies

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

A Sample of Applications That Use Web-

Database Technology

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

Web-to-Database Middleware

(ColdFusion)

Web Server Interfaces

Windows Applications Use ODBC to

Access Databases

Web-to-Database Middleware Uses

ODBC to Access Databases

The Web Browser

• Software that lets users navigate (browse) the

• 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

Client-side Extensions

• Client-side extensions

– Add functionality to Web browser

– Three general types:

• Plug-ins

• Java and JavaScript

• ActiveX and VBScript

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

Production Tool: ColdFusion (continued)

• ColdFusion application middleware can be

used to:

– Connect to and query a database from a Web

– 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

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

How ColdFusion Works

The Ch14_RobCor Database’s Relational

Schema

A Simple Query Using CFQUERY and

CFOUTPUT

The rc-1.cfm Script Output

(Vertical Listing)

CFQUERY with Tabular CFOUTPUT

(Horizontal Listing)

CFQUERY with CFTABLE

(Formatted Horizontal Listing)

Dynamic Search Query:

Criteria Entry Form

The rc-4a.cfm Script Output

(State Search Criteria Entry Form)

The VENDOR Search Results

The rc-4b.cfm Script Output

(Vendor Search Results: All States)

The Vendor List for the Condition

VEN_STATE = ―GA‖

Insert Query: Data Entry Script

(Department Data Entry Screen)

The Insert Query Form:

Server-Side Validation Error Message

Insert Query: Confirmation Script

(Department Data Entry Confirmation)

The Insert Query:

ODBC Integrity Violation Error

Update Query: Record Selection Script

(Record Selection Screen)

Update Query: Edit Record Script

(Edit Record Screen)

Update Query: Result Confirmation Script

The rc-6c.cfm Script Output

(Update Query Result Confirmation)

Delete Query: Record Selection Script

(Record Selection Screen)

Delete Query: Show Record Script

(Show Record Screen)

Delete Query: Result Confirmation Script

The rc-7c.cfm Script Output

(Delete Query Confirmation Screen)

The Delete Record Validation

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

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

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

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

Chapter 15

Database Administration

Database Systems:

• 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

• 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

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

Fig 15.1 The Data-Information-Decision-

Making Cycle

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

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

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

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

The IS Department Internal Organization

The Placement of the DBA Function

A DBA Functional Organization

Multiple Database Administrators

in an Organization

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

Contrasting DA and DBA Activities

and Characteristics

A Summary of DBA Activities

Desired DBA Skills

DBA Activities and Services

Database Administration Tools

• Two main types of data dictionaries:

– Integrated

– Standalone

• Main function: store description of all objects

that interact with the database

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

An Example of a CASE Tool:

Visio Professional

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

• Database administration strategy must not

conflict with information systems plans

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

Forces Affecting the Development

of the ISA

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

The Oracle Enterprise Manager Interface

Oracle Edit Local Preferred

Credentials Window

Oracle RDBMS Services

The Oracle Storage Manager

Creating a New Tablespace

The Oracle Schema Manager

The Oracle Security Manager

The Create User Dialog Box

The Oracle Instance Manager

Creating a New Database with the

Database Configuration Assistant

Selecting the New Database Template

Naming the Database

Selecting the Database Operation Mode

Specifying Initialization Parameters

Specifying Storage Parameters

Database Creation Options

Summary of Database Creation Options

Database Creation Progress

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

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

Database Systems

Documents

Systems Database

04/20/2005Yan Huang - CSCI5330 Database Implementation – Distributed Database Systems Distributed Database Systems

1 Database Management Systems (DBMS). 2 Database Management Systems (DBMS) n Overview of: ä Database Management Components ä Database Systems Architecture

Database Systems - Database Design

Database Fundamentals Introduction Introduction to database systems Database Management Systems (DBMS) Type of Database Database Design Database Design

DATABASE MANAGEMENT SYSTEMS CMAM301. Introduction to database management systems What is Database? What is Database Systems? Types of Database

IMS1907 Database Systems Week 2 Types of Database Systems

Database Systems: Today Database Systems Today

Database Systems

Succeeding with Technology Database Systems Basic Data Management Concepts Organizing Data in a Database Database Management Systems Using Database Systems

Database Management Systems/Managing Database

04/18/2005Yan Huang - CSCI5330 Database Implementation – Distributed Database Systems Distributed Database Systems