Chapter 1
1
File Systems and Databases
Database Systems: Design, Implementation, and
Management, 4th Edition
Peter Rob & Carlos Coronel
Introducing the Database
Major Database Concepts
1
 Data
and information

Data - Raw facts

Information - Processed data
 Data
management
 Database
 Metadata
 Database
management system (DBMS)
Sales per Employee for Each of ROBCOR’S Two Divisions
1
Figure 1.1
Introducing the Database
 Importance of DBMS
1

It helps make data management more efficient
and effective.

Its query language allows quick answers to ad
hoc queries.

It provides end users better access to more and
better-managed data.

It promotes an integrated view of organization’s
operations -- “big picture.”

It reduces the probability of inconsistent data.
The DBMS Manages the Interaction
Between the End User and the Database
1
Figure 1.2
Introducing the Database
 Why Database Design Is Important?
1

A well-designed database facilitates data
management and becomes a valuable information
generator.

A poorly designed database is a breeding ground
for uncontrolled data redundancies.

A poorly designed database generates errors that
lead to bad decisions.
Historical Roots
 Why Study File Systems?
1

It provides historical perspective.

It teaches lessons to avoid pitfalls of data
management.

Its simple characteristics facilitate understanding
of the design complexity of a database.

It provides useful knowledge for converting a file
system to a database system.
Contents of the CUSTOMER File
1
Figure 1.3
Table 1.1 Basic File Terminology
1
Data
“Raw” facts that have little meaning unless they have been
organized in some logical manner. The smallest piece of data
that can be “recognized” by the computer is a single
character, such as the letter A, the number 5, or some
symbol such as; ‘ ? > * +. A single character requires one
byte of computer storage.
Field
A character or group of characters (alphabetic or numeric)
that has a specific meaning. A field might define a telephone
numbers, a birth date, a customer name, a year-to-date
(YTD) sales value, and so on.
Record
A logically connected set of one or more fields that describes
a person, place, or thing. For example, the fields that
comprise a record for a customer named J. D. Rudd might
consist of J. D. Rudd’s name, address, phone number, date
of birth, credit limit, unpaid balance, and so on.
File
A collection of related records. For example, a file might
contain data about ROBCOR Company’s vendors; or, a file
might contain the records for the students currently enrolled
at Gigantic University.
Contents of the AGENT File
1
Figure 1.4
A Simple File System
1
Figure 1.5
File System Critique
 File System Data Management
1

File systems require extensive programming in a
third-generation language (3GL).

As the number of files expands, system
administration becomes difficult.

Making changes in existing file structures is
important and difficult.

Security features to safeguard data are difficult to
program and usually omitted.

Difficulty to pool data creates islands of
information.
File System Critique
 Structural and Data Dependence

1
Structural Dependence
A change in any file’s structure requires the
modification of all programs using that file.

Data Dependence
A change in any file’s data characteristics requires
changes in all data access programs.


Significance of data dependence is the difference
between the data logical format and the data
physical format.
Data dependence makes file systems extremely
cumbersome from a programming and data
management point of view.
File System Critique
 Field Definitions and Naming Conventions

1
A good (flexible) record definition anticipates
reporting requirements by breaking up fields into
their components.

Example:
– Customer Name  Last Name, First Name, Initial
– Customer Address  Street Address, City, State
FIELD
CONTENTS
CUS_LNAME
Customer last name
CUS_FNAME
Customer first name
CUS_INITIAL
Customer initial
CUS_AREACODE
Customer area code
CUS_PHONE
Customer phone
CUS_ADDRESS
Customer street address or box number
CUS_CITY
Customer city
CUS_STATE
Customer state
File System Critique
 Field Definitions and Naming Conventions
1

Selecting proper field names is very important.


Names must be as descriptive as possible within
restrictions.
Naming must reflect designer’s documentation needs
and user’s reporting and processing requirements.
File System Critique
1
 Data Redundancy:
Uncontrolled data redundancy sets the
stage for

Data Inconsistency (lack of data integrity)

Data anomalies

Modification anomalies

Insertion anomalies

Deletion anomalies
Figure 1.6
1
The Database System Environment
1
Figure 1.7
Figure 1.7
Database Systems
 The Database System Components

1
Hardware



Computer
Peripherals
Software



Operating systems software
DBMS software
Applications programs and utilities software
Database Systems
 The Database System Components

People

1





Procedures


Systems administrators
Database administrators (DBAs)
Database designers
Systems analysts and programmers
End users
Instructions and rules that govern the design and use of
the database system
Data

Collection of facts stored in the database
Database Systems
 The Database System Components

1

The complexity of database systems depends on
various organizational factors:

Organization’s size

Organization’s function

Organization’s corporate culture

Organizational activities and environment
Database solutions must be cost effective AND
strategically effective.
Database Systems
 Types of Database Systems

Number of Users

1
Single-user
– Desktop database

Multiuser
– Workgroup database
– Enterprise database

Scope



Desktop
Workgroup
Enterprise
Database Systems
 Types of Database Systems

1
Location



Centralized
Distributed
Use



Transactional (Production)
Decision support
Data warehouse
Database Systems
 DBMS Functions
1. Data Dictionary Management
1
2. Data Storage Management
3. Data Transformation and Presentation
4. Security Management
5. Multi-User Access Control
6. Backup and Recovery Management
7. Data Integrity Management
8. Database Access Languages (DDL and DML) and
Application Programming Interfaces
9. Database Communication Interfaces
Database Models
1
 A database model is a collection of logical
constructs used to represent the data
structure and the data relationships found
within the database.
 Two Categories of Database Models

Conceptual models focus on the logical nature of the
data representation. They are concerned with what is
represented rather than how it is represented.

Implementation models place the emphasis on how
the data are represented in the database or on how
the data structures are implemented.
Database Models
 Three Types of Relationships

1
One-to-many relationships (1:M)

A painter paints many different paintings, but each one
of them is painted by only that painter.
– PAINTER (1) paints PAINTING (M)

Many-to-many relationships (M:N)

An employee might learn many job skills, and each job
skill might be learned by many employees.
– EMPLOYEE (M) learns SKILL (N)

One-to-one relationships (1:1)

Each store is managed by a single employee and each
store manager (employee) only manages a single store.
– EMPLOYEE (1) manages STORE (1)
Database Models
 Three Types of Implementation Database
Models
1

Hierarchical database model

Network database model

Relational database model
A Hierarchical Structure
1
Figure 1.8
Database Models
 Hierarchical Database Model

1
Basic Structure

Collection of records logically organized to conform to
the upside-down tree (hierarchical) structure.

The top layer is perceived as the parent of the segment
directly beneath it.

The segments below other segments are the children of
the segment above them.

A tree structure is represented as a hierarchical path on
the computer’s storage media.
Database Models
 Hierarchical Database Model

Advantages

1





Conceptual simplicity
Database security
Data independence
Database integrity
Efficiency dealing with a large database
Disadvantages






Complex implementation
Difficult to manage
Lacks structural independence
Applications programming and use complexity
Implementation limitations
Lack of standards
Child with Multiple Parents
1
Figure 1.9
Database Models
 Network Database Model

1
Basic Structure

Set -- A relationship is called a set. Each set is
composed of at least two record types: an owner
(parent) record and a member (child) record.

A set is represents a 1:M relationship between the
owner and the member.
A Network Database Model
1
Figure 1.10
Database Models
 Network Database Model

1

Advantages

Conceptual simplicity

Handles more relationship types

Data access flexibility

Promotes database integrity

Data independence

Conformance to standards
Disadvantages

System complexity

Lack of structural independence
Database Models
 Relational Database Model

1
Basic Structure

RDBMS allows operations in a human logical
environment.

The relational database is perceived as a collection of
tables.

Each table consists of a series of row/column
intersections.

Tables (or relations) are related to each other by
sharing a common entity characteristic.

The relationship type is often shown in a relational
schema.

A table yields complete data and structural
independence.
Linking Relational Tables
1
Figure 1.11
Database Models
 Relational Database Model

Advantages

1





Structural independence
Improved conceptual simplicity
Easier database design, implementation, management,
and use
Ad hoc query capability (SQL)
Powerful database management system
Disadvantages



Substantial hardware and system software overhead
Possibility of poor design and implementation
Potential “islands of information” problems
A Relational Schema
1
Figure 1.12
Database Models
 Entity-Relationship Data Model
1

It is one of the most widely accepted graphical data
modeling tools.

It graphically represents data as entities and their
relationships in a database structure.

It complements the relational data model concepts.
Database Models
 Entity Relationship Data Model

1
Basic Structure




E-R models are normally represented in an entity
relationship diagram (ERD).
An entity is represented by a rectangle.
Each entity is described by a set of attributes. An
attribute describes a particular characteristics of the
entity.
A relationship is represented by a diamond connected
to the related entities.
Figure 1.13 Relationship Depiction: The ERD
1
Figure 1.14
1
Relationship Depiction: The Crow’s Foot
Database Models
 Entity-Relationship Data Model

1

Advantages

Exceptional conceptual simplicity

Visual representation

Effective communication tool

Integrated with the relational database model
Disadvantages

Limited constraint representation

Limited relationship representation

No data manipulation language

Loss of information content
Database Models
 Object-Oriented Database Model

1
Characteristics

An object is described by its factual content.

An object includes information about relationships
between the facts within the object, as well as with other
objects.

An object is a self-contained building block for
autonomous structures.
Database Models
 Object-Oriented Database Model

1
Basic Structure

Objects are abstractions of real-world entities or
events.

Attributes describe the properties of an object.

Objects that share similar characteristics are grouped in
classes.

A class is a collection of similar objects with shared
structure (attributes) and behavior (methods).

Classes are organized in a class hierarchy.

An object can inherit the attributes and methods of the
classes above it.
A Comparison: The OO Data Model and the ER Model
1
Figure 1.15
Database Models
 Object-Oriented Database Model

1

Advantages

Add semantic content

Visual presentation includes semantic content

Database integrity

Both structural and data independence
Disadvantages

Lack of OODM standards

Complex navigational data access

Steep learning curve

High system overhead slows transactions
The Development of Data Models
1
Figure 1.16
Wrap-Up: The Evolution of
Data Models
1
 Common characteristics required for data
models:

A data model must show some degree of conceptual
simplicity without compromising the semantic
completeness.

A data model must represent the real world as closely as
possible.

The representation of the real-world transformations
(behavior) must be in compliance with the consistency and
integrity characteristics of any data model.
Wrap-Up: The Evolution of
Data Models
 Database Models and the Internet
1
The use of the Internet as a prime business tool is
shifting focus to database products that interface
efficiently and easily with the Internet.

Successful “Internet age” databases are
characterized by:






Flexible, efficient, and secure Internet access.
Support for complex data types and relationships.
Seamless interfacing with multiple data sources and
structures.
Simplicity of the conceptual database model.
An abundance of available database tools.
A powerful DBMS to help make the DBA’s job easier.
Chapter
1
The
Relational Database Mode
Database
4th
2
Systems: Design, Implementation, and Manageme
Edition
Peter
Rob & Carlos Coronel
A Logical View of Data
1
 Relational database model’s structural and
data independence enables us to view data
logically rather than physically.
 The logical view allows a simpler file
concept of data storage.
 The use of logically independent tables is
easier to understand.
 Logical simplicity yields simpler and more
effective database design methodologies.
A Logical View of Data
 Entities and Attributes

1
An entity is a person, place, event, or thing for
which we intend to collect data.



University -- Students, Faculty Members, Courses
Airlines -- Pilots, Aircraft, Routes, Suppliers
Each entity has certain characteristics known as
attributes.


Student -- Student Number, Name, GPA, Date of
Enrollment, Data of Birth, Home Address, Phone
Number, Major
Aircraft -- Aircraft Number, Date of Last Maintenance,
Total Hours Flown, Hours Flown since Last
Maintenance
A Logical View of Data
 Entities and Attributes

1
A grouping of related entities becomes an entity
set.

The STUDENT entity set contains all student entities.

The FACULTY entity set contains all faculty entities.

The AIRCRAFT entity set contains all aircraft entities.
A Logical View of Data
 Tables and Their Characteristics
1

A table contains a group of related entities -- i.e.
an entity set.

The terms entity set and table are often used
interchangeably.

A table is also called a relation.
Summary
of the Characteristics of a Relational Table
1
Table
2.1
A Listing
of the STUDENT Table Attribute Values
1
Figure
2.1
Keys
1
 Controlled redundancy (shared common
attributes) makes the relational database
work.
 The primary key of one table appears again
as the link (foreign key) in another table.
 If the foreign key contains either matching
values or nulls, the table(s) that make use of
such a foreign key are said to exhibit
referential integrity.
Figure
1
2.2
An Example of a Simple Relational Database
The
Relational Schema for the CH2_SALE_CO Database
1
Figure
2.3
Keys
1

A key helps define entity relationships.

The key’s role is based on a concept known as
determination, which is used in the definition of
functional dependence.

The attribute B is functionally dependent on A if A
determines B.

An attribute that is part of a key is known as a key
attribute.

A multi-attribute key is known as a composite key.

If the attribute (B) is functionally dependent on a
composite key (A) but not on any subset of that
composite key, the attribute (B) is fully functionally
dependent on (A).
Student
Classification
1
Table
2.2
Relational
Database Keys
1
Table
2.3
Integrity
Rules Revisited
1
Table
2.4
Figure
1
2.4
An Illustration of Integrity Rules
Relational Database Operators
1
 The degree of relational completeness can
be defined by the extent to which relational
algebra is supported.
 Relational algebra defines the theoretical
way of manipulating table contents using
the eight relational functions: SELECT,
PROJECT, JOIN, INTERSECT, UNION,
DIFFERENCE, PRODUCT, and DIVIDE.
Relational Database Operators
 UNION combines all rows from two tables.
The two tables must be union compatible.
1
Figure
2.5
UNION
Relational Database Operators
1
 INTERSECT produces a listing that contains
only the rows that appear in both tables. The
two tables must be union compatible.
Figure
2.6 INTERSECT
Relational Database Operators
1
 DIFFERENCE yields all rows in one table
that are not found in the other table; i.e., it
subtracts one table from the other. The
tables must be union compatible.
Figure
2.7
DIFFERENCE
Relational Database Operators
 PRODUCT produces a list of all possible
pairs of rows from two tables.
1
Figure
2.8
PRODUCT
Relational Database Operators
1
 SELECT yields values for all attributes
found in a table. It yields a horizontal subset
of a table.
Relational Database Operators
 PROJECT produces a list of all values for selected
attributes. It yields a vertical subset of a table.
1
Relational Database Operators
1
 JOIN allows us to combine information from
two or more tables. JOIN is the real power
behind the relational database, allowing the
use of independent tables linked by
common attributes.
Relational Database Operators
 Natural
1
JOIN links tables by selecting
only the rows with common values in
their common attribute(s). It is the result
of a three-stage process:

A PRODUCT of the tables is created. (Figure
2.12)

A SELECT is performed on the output of the
first step to yield only the rows for which the
common attribute values match. (Figure 2.13)

A PROJECT is performed to yield a single
copy of each attribute, thereby eliminating the
duplicate column. (Figure 2.14)
Natural
Join, Step 1: PRODUCT
1
Figure
2.12
1
Figure
2.13 Natural Join, Step 2: SELECT
Figure
2.14 Natural Join, Step 3: PROJECT
Relational Database Operators

EquiJOIN links tables based on an equality
condition that compares specified columns of
each table. The outcome of the EquiJOIN does not
eliminate duplicate columns and the condition or
criteria to join the tables must be explicitly
defined.

Theta JOIN is an equiJOIN that compares
specified columns of each table using a
comparison operator other than the equality
comparison operator.

In an Outer JOIN, the unmatched pairs would be
retained and the values for the unmatched other
tables would be left blank or null.
1
Outer
JOIN
1
Figure
2.15
Relational Database Operators
 DIVIDE requires the use of one singlecolumn table and one two-column table.
1
Figure
2.16
DIVIDE
The Data Dictionary and the
System Catalog
1
 Data dictionary contains metadata to provide detailed
accounting of all tables within the database.
 System catalog is a very detailed system data
dictionary that describes all objects within the
database.

System catalog is a system-created database whose
tables store the database characteristics and contents.

System catalog tables can be queried just like any other
tables.

System catalog automatically produces database
documentation.
A Sample
1
Table
2.6
Data Dictionary
Relationships within the
Relational Database
 E-R Diagram (ERD)
1

Rectangles are used to represent entities.

Entity names are nouns and capitalized.

Diamonds are used to represent the
relationship(s) between the entities.

The number 1 is used to represent the “1” side of
the relationship.

The letter M is used to represent the “many” sides
of the relationship.
The
Relationship Between Painter and Paintin
1
Figure
2.17
An Alternate
Between
Way to Present the Relationship
Painter and Painting
1
Figure
2.18
A 1:M
Relationship: The CH2_MUSEUM Database
1
Figure
2.19
The
1:M Relationship Between Course and Cla
1
Figure
2.20
1
The
M:N Relationship Between Student and Class
1
Figure
2.22
Sample
1
Table
2.7
Student Enrollment Data
A Many-to-Many
1
Figure
2.23
Relationship Between Student and Class
1
Changing
the M:N Relationship to Two 1:M Relationships
1
Figure
2.25
The
Expanded Entity Relationship Model
1
Figure
2.26
The
in
Relational Schema for the Entity Relationship Diagram
Figure 2.26
1
Figure
2.27
Data Redundancy Revisited
 Proper use of foreign keys is crucial to
exercising data redundancy control.
1
 Database designers must reconcile three
often contradictory requirements: design
elegance, processing speed, and
information requirements. (Chapter 4)
 Proper data warehousing design even
requires carefully defined and controlled
data redundancies, to function properly.
(Chapter 13)
1
Figure
2.28
A Small
Invoicing System
Figure
The
2.29
Relational Schema for the Invoicing System in Figure 2.28
1
The
redundancy is crucial to the system’s success.
Copying the product price from the PRODUCT table to
the LINE table means that it is possible to maintain the
historical accuracy of the transactions.
Indexes
 An index is composed of an index key and a
set of pointers.
1
Figure
2.30 Components of an Index
Chapter
1
3
Structured
Database
4th
Query Language (SQL)
Systems: Design, Implementation, and Management
Edition
Peter
Rob & Carlos Coronel
99
Introduction to SQL
 SQL meets ideal database language
requirements:
1

SQL coverage fits into two categories:

Data definition

Data manipulation

SQL is relatively easy to learn.

ANSI prescribes a standard SQL.
100
Data Definition Commands
 The Database Model

1
Simple Database -- PRODUCT and VENDOR tables


Each product is supplied by only a single vendor.
A vendor may supply many products.
Figure
3.1
101
Data Definition Commands
 The Tables and Their Components
1

The VENDOR table contains vendors who are not
referenced in the PRODUCT table. PRODUCT is
optional to VENDOR.

Existing V_CODE values in the PRODUCT table must
have a match in the VENDOR table.

A few products are supplied factory-direct, a few are
made in-house, and a few may have been bought in a
special warehouse sale. That is, a product is not
necessarily supplied by a vendor. VENDOR is
optional to PRODUCT.
102
1
103
Data Definition Commands
 Creating the Database Structure
1
CREATE SCHEMA AUTHORIZATION <creator>;
Example:
CREATE SCHEMA AUTHORIZATION
JONES;
CREATE DATABASE <database name>;
Example:
CREATE DATABASE CH3;
104
A Data
Dictionary for the CH3 Database
1
Table
3.1
105
Some
Data
1
Common SQL Data Types
Type
Format
Numeric
NUMBER(L,D)

INTEGER

SMALLINT

DECIMAL(L,D)
Character
CHAR(L)

VARCHAR(L)
106
Data Definition Commands
 Creating Table Structures
1
CREATE TABLE <table name>(
<attribute1 name and attribute1 characteristics,
attribute2 name and attribute2 characteristics,
attribute3 name and attribute3 characteristics,
primary key designation,
foreign key designation and foreign key
requirements>);
107
Data Definition Commands
1
CREATE TABLE VENDOR
(V_CODE
FCHAR(5)
V_NAME
VCHAR(35)
V_CONTACT
VCHAR(15)
V_AREACODE
FCHAR(3)
V_PHONE
FCHAR(3)
V_STATE
FCHAR(2)
V_ORDER
FCHAR(1)
PRIMARY KEY (V_CODE));
NOT
NOT
NOT
NOT
NOT
NOT
NOT
NULL UNIQUE,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
108
Data Definition Commands
1
CREATE TABLE PRODUCT(
P_CODE
VCHAR(10)
NOT NULL
UNIQUE,
P_DESCRIPT
VCHAR(35)
NOT NULL,
P_INDATE
DATE
NOT NULL,
P_ONHAND
SMALLINT
NOT NULL,
P_MIN
SMALLINT
NOT NULL,
P_PRICE
DECIMAL(8,2) NOT NULL,
P_DISCOUNT
DECIMAL(4,1) NOT NULL,
V_CODE
SMALLINT,
PRIMARY KEY (P_CODE),
FOREIGN KEY (V_CODE) REFERENCES VENDOR
ON DELETE RESTRICT
ON UPDATE CASCADE);
109
Data Definition Commands
 SQL Integrity Constraints
1

Entity Integrity



PRIMARY KEY
NOT NULL and UNIQUE
Referential Integrity



FOREIGN KEY
ON DELETE
ON UPDATE
110
SQL Command
Coverage
1
Table
3.3
111
Basic Data Management
 Data Entry
1
INSERT INTO <table name> VALUES (attribute 1
value, attribute 2 value, … etc.);
INSERT INTO VENDOR
VALUES(‘21225, ’Bryson,
Inc.’, ’Smithson’,
’615’,’223-3234’, ’TN’,
’Y’);
INSERT INTO PRODUCT
112
Figure
3.3
A Data View and Entry Screen
1
113
Basic Data Management
 Saving the Table Contents
1
COMMIT <table names>;
COMMIT PRODUCT;
 Listing the Table Contents
SELECT * FROM PRODUCT;
SELECT P_CODE, P_DESCRIPT,
P_INDATE, P_ONHAND, P_MIN,
114
Figure
1
The
the
3.4
Contents of
PRODUCT
Table
115
Basic Data Management
 Making a Correction
1
UPDATE PRODUCT
SET P_INDATE = ‘12/11/96’
WHERE P_CODE = ‘13-Q2/P2’;
UPDATE PRODUCT
SET P_INDATE = ‘12/11/96’,
P_PRICE = 15.99, P_MIN=10
WHERE P_CODE = ‘13-Q2/P2’;
116
Basic Data Management
 Deleting Table Rows
1
DELETE FROM PRODUCT
WHERE P_CODE = ‘2238/QPD’;
DELETE FROM PRODUCT
WHERE P_MIN = 5;
117
Queries
 Partial Listing of Table Contents
1
SELECT <column(s)>
FROM <table name>
WHERE <conditions>;
SELECT P_DESCRIPT, P_INDATE,
P_PRICE, V_CODE
FROM PRODUCT
WHERE V_CODE = 21344;
Figure
3.5
118
Figure
1
3.6
The
Microsoft
Access QBE and
Its SQL
119
Queries
Mathematical
Operators
1
Table
3.4
120
Queries
1
SELECT P_DESCRIPT, P_INDATE,
P_PRICE, V_CODE
FROM PRODUCT
WHERE V_CODE <> 21344;
Figure
3.7
121
Queries
1
SELECT P_DESCRIPT, P_ONHAND,
P_MIN, P_PRICE
FROM PRODUCT
WHERE P_PRICE <= 10;
Figure
3.8
122
Queries
 Using Mathematical Operators on
Character Attributes
1
SELECT P_DESCRIPT, P_ONHAND,
P_MIN, P_PRICE
FROM PRODUCT
WHERE P_CODE < ‘1558-QWI’;
Figure
3.9
123
Queries
 Using Mathematical Operators on Dates
1
SELECT P_DESCRIPT, P_ONHAND,
P_MIN, P_PRICE, P_INDATE
FROM PRODUCT
WHERE P_INDATE >=
‘08/15/1999’;
Figure
3.10
124
Queries
 Logical Operators: AND, OR, and NOT
1
SELECT P_DESCRIPT, P_INDATE,
P_PRICE, V_CODE
FROM PRODUCT
WHERE V_CODE = 21344
OR V_CODE = 24288;
Figure
3.11
125
Queries
1
SELECT P_DESCRIPT, P_INDATE,
P_PRICE, V_CODE
FROM PRODUCT
WHERE P_PRICE < 50
AND P_INDATE >
‘07/15/1999’;
Figure
3.12
126
Queries
1
SELECT P_DESCRIPT, P_INDATE,
P_PRICE, V_CODE
FROM PRODUCT
WHERE (P_PRICE < 50 AND
P_INDATE > ‘07/15/1999’)
OR V_CODE = 24288;
Figure
3.13
127
Queries
 Special Operators
1

BETWEEN - used to define range limits.

IS NULL - used to check whether an attribute
value is null

LIKE - used to check for similar character strings.

IN - used to check whether an attribute value
matches a value contained within a (sub)set of
listed values.

EXISTS - used to check whether an attribute has a
value. In effect, EXISTS is the opposite of IS
NULL.
128
Queries
1
 Special Operators
BETWEEN is used to define range limits.
SELECT *
FROM PRODUCT
WHERE P_PRICE BETWEEN 50.00
AND 100.00;
SELECT *
FROM PRODUCT
WHERE P_PRICE > 50.00
AND P_PRICE < 100.00;
129
Queries
 Special Operators
1
IS NULL is used to check whether an attribute value
is null.
SELECT P_CODE, P_DESCRIPT
FROM PRODUCT
WHERE P_MIN IS NULL;
SELECT P_CODE, P_DESCRIPT
FROM PRODUCT
WHERE P_INDATE IS NULL;130
Queries
 Special Operators
1
LIKE is used to check for similar character strings.
SELECT * FROM VENDOR
WHERE V_CONTACT LIKE
‘Smith%’;
SELECT * FROM VENDOR
WHERE V_CONTACT LIKE
‘SMITH%’;
131
Queries
 Special Operators
1
IN is used to check whether an attribute value
matches a value contained within a (sub)set of
listed values.
SELECT * FROM PRODUCT
WHERE V_CODE IN (21344,
24288);
EXISTS is used to check whether an attribute has
value.
DELETE FROM PRODUCT
WHERE P_CODE EXISTS;
132
Advanced Data Management
Commands
1
 Changing Table Structures
ALTER TABLE <table name>
MODIFY (<column name> <new
column characteristics>);
ALTER TABLE <table name>
ADD (<column name> <new column
characteristics>);
133
Advanced Data Management
Commands
 Changing a Column’s Data Type
1
ALTER TABLE PRODUCT
MODIFY (V_CODE CHAR(5));
 Changing Attribute Characteristics
ALTER TABLE PRODUCT
MODIFY (P_PRICE
DECIMAL(9,2));
 Adding a New Column to the Table
ALTER TABLE PRODUCT
134
Advanced Data Management
Commands
1
UPDATE PRODUCT
SET P_SALECODE = ‘2’
WHERE P_CODE = ‘1546-QQ2’;
Figure
Selected
3.14
PRODUCT Table Attributes: Multiple Data Entry
135
Advanced Data Management
Commands
UPDATE PRODUCT
SET P_SALECODE = ‘1’
WHERE P_CODE IN
(‘2232/QWE’, ‘2232/QTY’);
1
Figure

3.15 Selected PRODUCT Table Attributes:
Multiple Data Entry
136
Advanced Data Management
Commands
1
UPDATE PRODUCT
SET P_SALECODE = ‘2’
WHERE P_INDATE <
‘07/10/1999’;
UPDATE PRODUCT
SET P_SALECODE = ‘1’
WHERE P_INDATE >=
‘08/15/1999’
137
Advanced Data Management
Commands
Selected
PRODUCT Table Attributes: Multiple Update Effect
1
Figure
3.16
138
The Arithmetic
Operators
1
Table
3.5
139
Advanced Data Management
Commands
 Copying Parts of Tables
1
CREATE TABLE PART
PART_CODE CHAR(8) NOT NULL
UNIQUE,
PART_DESCRIPT CHAR(35),
PART_PRICE
DECIMAL(8,2),
PRIMARY KEY(PART_CODE));
INSERT INTO PART (PART_CODE,
140
PART_DESCRIPT, PART_PRICE)
The
Part Attributes Copied from the PRODUCT Table
1
Figure
3.17
141
Advanced Data Management
Commands
 Deleting a Table from the Database
1

DROP TABLE <table name>;
DROP TABLE PART;
142
Advanced Data Management
Commands
 Primary and Foreign Key Designation
1
ALTER TABLE PRODUCT
ADD PRIMARY KEY (P_CODE);
ALTER TABLE PRODUCT
ADD FOREIGN KEY (V_CODE) REFERENCES
VENDOR;
ALTER TABLE PRODUCT
ADD PRIMARY KEY (P_CODE)
ADD FOREIGN KEY (V_CODE) REFERENCES
VENDOR;
143
1
Chapter 4
Entity Relationship (E-R) Modeling
Database
4th
Systems: Design, Implementation, and Management
Edition
Peter
Rob & Carlos Coronel
Basic Modeling Concepts
 Database design is both art and science.
1
 A data model is the relatively simple representation,
usually graphic, of complex real-world data
structures. It represents data structures and their
characteristics, relations, constraints, and
transformations.
 The database designer usually employs data models
as communications tools to facilitate the interaction
among the designer, the applications programmer,
and the end user.
 A good database is the foundation for good
applications.
1
Figure
4.1 Four Modified (ANSI/SPARC) Data Abstraction Models
Data Models: Degrees of Data Abstraction
 The Conceptual Model
1

The conceptual model represents a global view of the
data. It is an enterprise-wide representation of data as
viewed by high-level managers.

Entity-Relationship (E-R) model is the most widely used
conceptual model.

The conceptual model forms the basis for the
conceptual schema.

The conceptual schema is the visual representation of
the conceptual model.

The conceptual model is independent of both software
(software independence) and hardware (hardware
independence).
Tiny
College Entities
1
Figure
4.2
A Conceptual
1
Figure
4.3
Schema for Tiny College
Data Models: Degrees of Data Abstraction
 The Internal Model
1

The internal model adapts the conceptual model to a
specific DBMS.

The internal model is software-dependent.

Development of the internal model is especially
important to hierarchical and network database models.
1
Figure
4.4
Data Models: Degrees of Data Abstraction
 The External Model
1

The external model is the end user’s view of the
data environment.

Each external model is then represented by its
own external schema.
CREATE VIEW CLASS_VIEW AS
SELECT (CLASS_ID, CLASS_NAME, PROF_NAME,
CLASS_TIME, ROOM_ID)
FROM CLASS, PROFESSOR, ROOM
WHERE CLASS.PROF_ID = PROFESSOR.PROF_ID
AND CLASS.ROOM_ID = ROOM.ROOM_ID;
1
Figure
The
for
4.5
External Models
Tiny College
Data Models: Degrees of Data Abstraction
 The External Model

1
Advantages of Using External Schemas

It makes application program development much
simpler.

It facilitates the designer’s task by making it easier
to identify specific data required to support each
business unit’s operations.

It makes the designer’s job easier by providing
feedback about the conceptual model’s adequacy.

It helps to ensure security constraints in the
database design.
Data Models: Degrees of Data Abstraction
 The Physical Model
1

The physical model operates at the lowest level of
abstraction, describing the way data is saved on
storage media such as disks or tapes.

It requires the definition of both the physical
storage devices and the access methods required
to reach the data within those storage devices.

The physical model is both software and
hardware-dependent.

It requires detailed knowledge of hardware and
software used to implement the database design.
The Entity Relationship (E-R) Model
 E-R model is commonly used to:
1

Translate different views of data among
managers, users, and programmers to fit into a
common framework.

Define data processing and constraint
requirements to help us meet the different views.

Help implement the database.
The Entity Relationship (E-R) Model
 E-R Model Components

1
Entities



Attributes






In E-R models an entity refers to the entity set.
An entity is represented by a rectangle containing the
entity’s name.
Attributes are represented by ovals and are connected to
the entity with a line.
Each oval contains the name of the attribute it represents.
Attributes have a domain -- the attribute’s set of possible
values.
Attributes may share a domain.
Primary keys are underlined.
Relationships
The Attributes
1
Figure
4.6
of the STUDENT Entity
Basic
E-R Model Entity Presentation
1
Figure
4.7
The
CLASS Table (Entity) Components and Contents
1
Figure
4.8
The Entity Relationship (E-R) Model
 Classes of Attributes

1
A simple attribute cannot be subdivided.


Examples: Age, Sex, and Marital status
A composite attribute can be further subdivided
to yield additional attributes.

Examples:
– ADDRESS Street, City, State, Zip
– PHONE NUMBER  Area code, Exchange
number
The Entity Relationship (E-R) Model
 Classes of Attributes

A single-valued attribute can have only a single value.

1

Examples:
– A person can have only one social security number.
– A manufactured part can have only one serial
number.
Multivalued attributes can have many values.

Examples:
– A person may have several college degrees.
– A household may have several phones with different
numbers

Multivalued attributes are shown by a double line
connecting to the entity.
The Entity Relationship (E-R) Model
 Multivalued Attribute in Relational DBMS

1
The relational DBMS cannot implement multivalued
attributes.
 Possible courses of action for the designer


Table
Within the original entity, create several new attributes,
one for each of the original multivalued attribute’s
components (Figure 4.9).
Create a new entity composed of the original multivalued
attribute’s components (Figure 4.10).
4.1
Splitting
the Multivalued Attributes into New Attributes
1
Figure
4.9
A New
Entity Set Composed of Multivalued
Attribute’s
Components
1
Figure
4.10
The Entity Relationship (E-R) Model

A derived attribute is not physically stored within the
database; instead, it is derived by using an algorithm.

1
Figure
Example: AGE can be derived from the data of birth and
the current date.
4.11 A Derived Attribute
The Entity Relationship (E-R) Model
 Relationships

1
A relationship is an association between entities.
 Relationships are represented by diamond-shaped
symbols.
Figure
4.12 An Entity Relationship
The Entity Relationship (E-R) Model
 A relationship’s degree indicates the number of associated
entities or participants.

1
A unary relationship exists when an association is maintained
within a single entity.
 A binary relationship exists when two entities are associated.
 A ternary relationship exists when three entities are
associated.
The
Implementation of a Ternary Relationship
1
Figure
4.14
The Entity Relationship (E-R) Model
 Connectivity

1
The term connectivity is used to describe the
relationship classification (e.g., one-to-one, one-tomany, and many-to-many).
Figure
4.15 Connectivity in an ERD
The Entity Relationship (E-R) Model
 Cardinality

1
Cardinality expresses the specific number of entity
occurrences associated with one occurrence of the
related entity.
Figure
4.16 Cardinality in an ERD
1
Figure
4.17
 Existence Dependency

If an entity’s existence depends on the existence of one
or more other entities, it is said to be existencedependent.
1
Figure
4.18
The Entity Relationship (E-R) Model
 Relationship Participation
1

The participation is optional if one entity occurrence
does not require a corresponding entity occurrence in a
particular relationship.

An optional entity is shown by a small circle on the side
of the optional entity.
Figure
4.19 An ERD With An Optional Entity
Figure
4.20 CLASS is Optional to COURSE
1
Figure
4.21 COURSE and CLASS in a Mandatory Relationship
The Entity Relationship (E-R) Model
 Weak Entities

1
A weak entity is an entity that

Is existence-dependent and

Has a primary key that is partially or totally derived
from the parent entity in the relationship.

The existence of a weak entity is indicated by a
double rectangle. (Figure 4.22)

The weak entity inherits all or part of its primary
key from its strong counterpart.
A Weak
Entity in an ERD
1
Figure
4.22
An
Illustration of the Weak Relationship Between
DEPENDENT
and EMPLOYEE
1
Figure
4.23
The Entity Relationship (E-R) Model
 Recursive Entities
1

A recursive entity is one in which a relationship can
exist between occurrences of the same entity set.

A recursive entity is found within a unary relationship.
Figure
4.24 An E-R Representation of Recursive Relationships
1
Figure
4.25
Figure
4.26
The
Implementation of the M:N Recursive
“PART
Contains PART” Relationship
1
Figure
4.27
Implementation
Recursive
of the M:N “COURSE Requires COURSE”
Relationship
1
Figure
4.28
Implementation
Recursive
of the 1:M “EMPLOYEE Manages EMPLOYEE”
Relationship
1
Figure
4.29
The Entity Relationship (E-R) Model
 Composite Entities
1

A composite entity is composed of the primary
keys of each of the entities to be connected.

The composite entity serves as a bridge between
the related entities.

The composite entity may contain additional
attributes.
Converting
the M:N Relationship Into Two 1:M Relationships
1
Figure
4.30
The
M:N Relationship Between STUDENT and CLAS
1
Figure
4.31
A Composite
1
Figure
4.32
Entity in the ERD
The Entity Relationship (E-R) Model
 Entity Supertypes and Subtypes
1
Figure
4.33 Nulls Created by Unique Attributes
The Entity Relationship (E-R) Model
 Entity Supertypes and Subtypes
1

The generalization hierarchy depicts the parentchild relationship.

The supertype contains the shared attributes,
while the subtype contains the unique attributes.

A subtype entity inherits its attributes and its
relationships from the supertype entity.
A Generalization
1
Figure
4.34
Hierarchy
The Entity Relationship (E-R) Model
 Entity Supertypes and Subtypes
1

The supertype entity set is usually related to
several unique and disjointed (nonoverlapping)
subtype entity sets.

The supertype and its subtype(s) maintain a 1:1
relationship.
The
EMPLOYEE/PILOT Supertype/Subtype Relationship
1
Figure
4.35
The Entity Relationship (E-R) Model
 Entity Supertypes and Subtypes
1

The generalization hierarchy depicts the parentchild relationship. (Figure 4.34)

The supertype contains the shared attributes,
while the subtype contains the unique attributes.

The supertype entity set is usually related to
several unique and disjointed (nonoverlapping)
subtype entity sets.

The supertype and its subtype(s) maintain a 1:1
relationship.
A Generalization
1
Figure
4.36
Hierarchy With Overlapping Subtype
1
Figure
4.37
Chapter 4
1
Entity Relationship (E-R) Modeling
Database
4th
Systems: Design, Implementation, and Management
Edition
Peter
Rob & Carlos Coronel
Developing an E-R Diagram
 The process of database design is an iterative rather
than a linear or sequential process.
1
 It usually begins with a general narrative of the
organization’s operations and procedures.
 The basic E-R model is graphically depicted and
presented for review.
 The process is repeated until the end users and
designers agree that the E-R diagram is a fair
representation of the organization’s activities and
functions.
Developing an E-R Diagram
 Tiny College Database (1)
1

Tiny College (TC) is divided into several schools.
Each school is administered by a dean. A 1:1
relationship exists between DEAN and SCHOOL.

Each dean is a member of a group of
administrators (ADMINISTRATOR). Deans also
hold professorial rank and may teach a class
(PROFESSOR). Administrators and professors are
also Employees. (Figure 4.38)
1
Developing an E-R Diagram
 Tiny College Database (2)

1
Each school is composed of several departments.
 The smallest number of departments operated by a
school is one, and the largest number of departments is
indeterminate (N).
 Each department belongs to only a single school.
Figure
4.40 The First Tiny College ERD Segment
Developing an E-R Diagram
 Tiny College Database (3)

Each department offers several courses.
1
Figure
4.41 The Second Tiny College ERD Segmen
Developing an E-R Diagram
 Tiny College Database (4)

1
A department may offer several sections (classes) of
the same course.
 A 1:M relationship exists between COURSE and CLASS.
 CLASS is optional to COURSE
Figure
4.42 The Third Tiny College ERD Segment
Developing an E-R Diagram
 Tiny College Database (5)

1
Each department has many professors assigned to it.
 One of those professors chairs the department. Only
one of the professors can chair the department.
 DEPARTMENT is optional to PROFESSOR in the
“chairs” relationship.
Figure
4.43 The Fourth Tiny College ERD Segment
Developing an E-R Diagram
 Tiny College Database (6)

1

Each professor may teach up to four classes,
each one a section of a course.
A professor may also be on a research contract
and teach no classes.
Figure
4.44 The Fifth Tiny College ERD Segment
Developing an E-R Diagram
 Tiny College Database (7)

1
A student may enroll in several classes, but (s)he takes
each class only once during any given enrollment
period.
 Each student may enroll in up to six classes and each
class may have up to 35 students in it.
 STUDENT is optional to CLASS.
Figure
4.45 The Sixth Tiny College ERD Segment
Developing an E-R Diagram
 Tiny College Database (8)

1
Each department has several students whose major is
offered by that department.
 Each student has only a single major and associated
with a single department.
Figure
4.46 The Seventh Tiny College ERD Segme
Developing an E-R Diagram
 Tiny College Database (9)

1
Each student has an advisor in his or her department;
each advisor counsels several students.
 An advisor is also a professor, but not all professors
advise students.
Figure
4.47 The Eighth Tiny College ERD Segment
Developing an E-R Diagram
Entities
1
for the Tiny College Database
 SCHOOL
 COURSE
 DEPARMENT
 CLASS
 EMPLOYEE
 ENROLL (Bridge between
STUDENT and CLASS)
 PROFESSOR
 STUDENT
Components
1
Table
4.2
of the E-R Model
1
Figure
4.48
Developing an E-R Diagram
 Converting an E-R Model into a Database Structure
1

A painter might paint many paintings. The
cardinality is (1,N) in the relationship between
PAINTER and PAINTING.

Each painting is painted by one (and only one)
painter.

A painting might (or might not) be exhibited in a
gallery; i.e., the GALLERY is optional to
PAINTING.
1
Figure
4.49
Developing an E-R Diagram
 Summary of Table Structures and Special
Requirements for the ARTIST database
1
PAINTER(PRT_NUM, PRT_LASTNAME, PRT_FIRSTNAME,
PRT_INITIAL, PTR_AREACODE, PRT_PHONE)
GALLERY(GAL_NUM, GAL_OWNER, GAL_AREACODE,
GAL_PHONE, GAL_RATE)
PAINTING(PNTG_NUM, PNTG_TITLE, PNTG_PRICE,
PTR_NUM, GAL_NUM)
A Data
Dictionary for the ARTIST Database
1
Table
4.3
Developing an E-R Diagram
SQL Commands to Create the PAINTER Table
1
CREATE TABLE PAINTER (
PTR_NUM
CHAR(4)
PRT_LASTNAME
CHAR(15)
PTR_FIRSTNAME CHAR(15),
PTR_INITIAL
CHAR(1),
PTR_AREACODE
CHAR(3),
PTR_PHONE
CHAR(8),
PRIMARY KEY(PTR_NUM));
NOT NULL UNIQUE,
NOT NULL,
Developing an E-R Diagram
SQL Commands to Create the GALLERY Table
1
CREATE TABLE GALLERY (
GAL_NUM
CHAR(4)
NOT NULL UNIQUE,
GAL_OWNER
CHAR(35),
GAL_AREACODE
CHAR(3)
NOT NULL,
GAL_PHONE
CHAR(8)
NOT NULL,
GAL_RATE
NUMBER(4,2),
PRIMARY KEY(GAL_NUM));
Developing an E-R Diagram
SQL Commands to Create the PAINTING Table
1
CREATE TABLE PAINTING (
PNTG_NUM
CHAR(4)
NOT NULL UNIQUE,
PNTG_TITLE
CHAR(35),
PNTG_PRICE
NUMBER(9,2),
PTR_NUM
CHAR(4)
NOT NULL,
GAL_NUM
CHAR(4),
PRIMARY KEY(PNTG_NUM)
FOREIGN KEY(PTR_NUM) RERERENCES PAINTER
ON DELETE RESTRICT
ON UPDATE CASCADE,
FOREIGN KEY(GAL_NUM) REFERENCES GALLERY
ON DELETE RESTRICT
ON UPDATE CASCADE);
Developing an E-R Diagram
 General Rules Governing Relationships
among Tables
1
1. All primary keys must be defined as NOT NULL.
2. Define all foreign keys to conform to the following
requirements for binary relationships.

1:M Relationship

Weak Entity

M:N Relationship

1:1 Relationship
Developing an E-R Diagram
 1:M Relationships

1
Create the foreign key by putting the primary key of the
“one” (parent) in the table of the “many” (dependent).
 Foreign Key Rules:
Null
On Delete
On Update
If both sides are
MANDATORY
NOT NULL
RESTRICT
CASCADE
If both sides are
OPTIONAL
NULL
ALLOWED
SET NULL
CASCADE
If one side is
OPTIONAL and
the other
MANDATORY
NULL
ALLOWED
SET NULL
or
RESTRICT
CASCADE
Developing an E-R Diagram
 Weak Entity

1
Put the key of the parent table (strong entity) in the
weak entity.
 The weak entity relationship conforms to the same
rules as the 1:M relationship, except foreign key
restrictions:
NOT NULL
ON DELETE CASCADE
ON UPDATE CASCADE
 M:N Relationship

Convert the M:N relationship to a composite (bridge)
entity consisting of (at least) the parent tables’ primary
keys.
Developing an E-R Diagram
 1:1 Relationships

1
If both entities are in mandatory participation in
the relationship and they do not participate in
other relationships, it is most likely that the two
entities should be part of the same entity.
Developing an E-R Diagram
 CASE 1: M:N, Both Sides MANDATORY
1
Figure
4.50 Entity Relationships, M:N, Both Sides Mandatory
Developing an E-R Diagram
 CASE 2: M:N, Both Sides OPTIONAL
1
Figure
4.51 Entity Relationships, M:N, Both Sides Optional
Developing an E-R Diagram
 CASE 3: M:N, One Side OPTIONAL
1
Figure
4.52 Entity Relationships, M:N, One Side Optional
Developing an E-R Diagram
 CASE 4: 1:M, Both Sides MANDATORY
1
Figure
4.53 Entity Relationships, 1:M, Both Sides Mandatory
Developing an E-R Diagram
 CASE 5: 1:M, Both Sides OPTIONAL
1
Figure
4.54 Entity Relationships, 1:M, Both Sides Optional
Developing an E-R Diagram
 CASE 6: 1:M, Many Side OPTIONAL, One Side
MANDATORY
1
Figure
4.55 Entity Relationships, 1:M, Many Side Optional, One Side Mandator
Developing an E-R Diagram
 CASE 7: 1:M, One Side OPTIONAL, One Side
MANDATORY
1
Figure
4.56 Entity Relationships, 1:M, One Side Optional, Many Side Mandator
Developing an E-R Diagram
 CASE 8: 1:1, Both Sides MANDATORY
1
Figure
4.57 Entity Relationships, 1:1, Both Sides Mandatory
Developing an E-R Diagram
 CASE 9: 1:1, Both Sides OPTIONAL
1
Figure
4.58 Entity Relationships, 1:1, Both Sides Optional
Developing an E-R Diagram
 CASE 10: 1:1, One Side OPTIONAL, One Side
MANDATORY
1
Figure
4.59 Entity Relationships, 1:1, One Side Optional, One Side Mandatory
Developing an E-R Diagram
 CASE 11: Weak Entity (Foreign key located in weak
entity)
1
Figure
4.60 Entity Relationships, Weak Entity
Developing an E-R Diagram
 CASE 12: Multivalued Attributes
1
Figure
4.61 Entity Relationships, Multivalued Attributes
1
The
Chen Representation of the Invoicing Problem
1
Figure
4.63
The
Crow’s Foot Representation of the Invoicing Problem
1
Figure
4.64
1
Figure
4.65 The Rein85 Representation of the Invoicing Problem
The
IDEF1X Representation of the Invoicing Problem
1
Figure
4.66
The Challenge of Database Design:
Conflicting Goals
 Conflicting Goals
1



Design standards (design elegance)
Processing speed
Information requirements
 Design Considerations





Logical requirements and design conventions
End user requirements; e.g., performance,
security, shared access, data integrity
Processing requirements
Operational requirements
Documentation
1
Chapter 5
Normalization of Database Tables
Database
4th
Systems: Design, Implementation, and Management
Edition
Peter
Rob & Carlos Coronel
Database Tables and Normalization
 Normalization is a process for assigning attributes to
entities. It reduces data redundancies and helps
eliminate the data anomalies.
1
 Normalization works through a series of stages
called normal forms:

First normal form (1NF)
 Second normal form (2NF)
 Third normal form (3NF)
 Fourth normal form (4NF)
 The highest level of normalization is not always
desirable.
Database Tables and Normalization
 The Need for Normalization

1
Case of a Construction Company

Building project -- Project number, Name,
Employees assigned to the project.

Employee -- Employee number, Name, Job
classification

The company charges its clients by billing the
hours spent on each project. The hourly billing rate
is dependent on the employee’s position.

Periodically, a report is generated.

The table whose contents correspond to the
reporting requirements is shown in Table 5.1.
1
A Table
Whose Structure Matches the Report Format
1
Figure
5.1
Database Tables and Normalization
 Problems with the Figure 5.1
1

The project number is intended to be a primary
key, but it contains nulls.

The table displays data redundancies.

The table entries invite data inconsistencies.

The data redundancies yield the following
anomalies:

Update anomalies.

Addition anomalies.

Deletion anomalies.
Database Tables and Normalization
 Conversion to First Normal Form
1

A relational table must not contain repeating groups.

Repeating groups can be eliminated by adding the
appropriate entry in at least the primary key column(s).
Figure
5.2 The Evergreen Data
Data
Organization: First Normal Form
1
Figure
5.3
Database Tables and Normalization
 Dependency Diagram

1
The primary key components are bold, underlined, and
shaded in a different color.
 The arrows above entities indicate all desirable
dependencies, i.e., dependencies that are based on PK.
 The arrows below the dependency diagram indicate
less desirable dependencies -- partial dependencies
and transitive dependencies.
Figure
5.4
Database Tables and Normalization
 1NF Definition

1
The term first normal form (1NF) describes the
tabular format in which:



All the key attributes are defined.
There are no repeating groups in the table.
All attributes are dependent on the primary key.
Database Tables and Normalization
 Conversion to Second Normal Form

1
Starting with the 1NF format, the database can be
converted into the 2NF format by


Writing each key component on a separate line, and
then writing the original key on the last line and
Writing the dependent attributes after each new key.
PROJECT (PROJ_NUM, PROJ_NAME)
EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS,
CHG_HOUR)
ASSIGN (PROJ_NUM, EMP_NUM, HOURS)
Second
Normal Form (2NF) Conversion Results
1
Figure
5.5
Database Tables and Normalization
 2NF Definition

1
A table is in 2NF if:

It is in 1NF and

It includes no partial dependencies; that is, no
attribute is dependent on only a portion of the
primary key.
(It is still possible for a table in 2NF to exhibit transitive
dependency; that is, one or more attributes may be
functionally dependent on nonkey attributes.)
Database Tables and Normalization
 Conversion to Third Normal Form

1
Create a separate table with attributes in a
transitive functional dependence relationship.
PROJECT (PROJ_NUM, PROJ_NAME)
ASSIGN (PROJ_NUM, EMP_NUM, HOURS)
EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS)
JOB (JOB_CLASS, CHG_HOUR)
Database Tables and Normalization
 3NF Definition

1
A table is in 3NF if:


It is in 2NF and
It contains no transitive dependencies.
1
Figure
The
5.6
Completed Databas
Database Tables and Normalization
 Boyce-Codd Normal Form (BCNF)

1
A table is in Boyce-Codd normal form (BCNF) if every
determinant in the table is a candidate key.
(A determinant is any attribute whose value determines
other values with a row.)

If a table contains only one candidate key, the 3NF and
the BCNF are equivalent.

BCNF is a special case of 3NF.

Figure 5.7 illustrates a table that is in 3NF but not in
BCNF.

Figure 5.8 shows how the table can be decomposed to
conform to the BCNF form.
A Table
That Is In 3NF But Not In BCNF
1
Figure
5.7
The
Decomposition of a Table Structure to Meet
BCNF
Requirements
1
Figure
5.8
Sample
Data for a BCNF Conversion
1
Table
5.2
Decomposition
1
Figure
5.9
into BCNF
Database Tables and Normalization
 BCNF Definition

1
A table is in BCNF if every determinant in that
table is a candidate key. If a table contains only
one candidate key, 3NF and BCNF are equivalent.
Normalization and Database Design
 Database Design and Normalization Example:
(Construction Company)
1

Summary of Operations:

The company manages many projects.

Each project requires the services of many employees.

An employee may be assigned to several different
projects.

Some employees are not assigned to a project and
perform duties not specifically related to a project. Some
employees are part of a labor pool, to be shared by all
project teams.

Each employee has a (single) primary job classification.
This job classification determines the hourly billing rate.

Many employees can have the same job classification.
Normalization and Database Design
 Two Initial Entities:
1
PROJECT (PROJ_NUM, PROJ_NAME)
EMPLOYEE (EMP_NUM, EMP_LNAME, EMP_FNAME,
EMP_INITIAL, JOB_DESCRIPTION,
JOB_CHG_HOUR)
Figure
5.10 The Initial ERD for a Contracting Company
Normalization and Database Design
 Three Entities After Transitive Dependency
Removed
1
PROJECT (PROJ_NUM, PROJ_NAME)
EMPLOYEE (EMP_NUM, EMP_LNAME, EMP_FNAME,
EMP_INITIAL, JOB_CODE)
JOB (JOB_CODE, JOB_DESCRIPTION,
JOB_CHG_HOUR)
The
Modified ERD For A Contracting Company
1
Figure
5.11
Normalization and Database Design
 Creation of the Composite Entity ASSIGN
1
Figure
5.12 The Final (Implementable) ERD for the Contracting Company
Normalization and Database Design
 Attribute ASSIGN_HOUR is assigned to the
composite entity ASSIGN.
1
 “Manages” relationship is created between
EMPLOYEE and PROJECT.
PROJECT (PROJ_NUM, PROJ_NAME, EMP_NUM)
EMPLOYEE (EMP_NUM, EMP_LNAME, EMP_FNAME,
EMP_INITIAL, EMP_HIREDATE, JOB_CODE)
JOB (JOB_CODE, JOB_DESCRIPTION,
JOB_CHG_HOUR)
ASSIGN (ASSIGN_NUM, ASSIGN_DATE, PROJ_NUM,
EMP_NUM, ASSIGN_HOURS)
The
Relational Schema For The Contracting Company
1
Figure
5.13
Higher-Level Normal Forms
 4NF Definition

1
A table is in 4NF if it is in 3NF and has no multiple sets
of multivalued dependencies.
Figure
5.14 Tables with Multivalued Dependencies
A Set
of Tables in 4NF
1
Figure
5.15
Denormalization
 Normalization is only one of many database design
goals.
1
 Normalized (decomposed) tables require additional
processing, reducing system speed.
 Normalization purity is often difficult to sustain in the
modern database environment. The conflict between
design efficiency, information requirements, and
processing speed are often resolved through
compromises that include denormalization.
The
Initial 1NF Structure
1
Figure
5.16
Identifying
the Possible PK Attributes
1
Figure
5.17
Table
Structures Based On The Selected PKs
1
Figure
5.18