CECS 323

Mimi Opkins
 Introduction UML design
Basic UML & SQL Many-to-Many
Models Many-to-Many 2
Classes & Schemes Subkeys
Rows & Tables Repeated Attributes
Associations Multi-Valued Attributes
Keys Domains
SQL technique Enumerated Domains
SQL and RA Subclasses
DDL & DML Aggregation
Join Recursive Associations
Multiple Joins Normalization
Join Types BCNF
Functions Transactions
Subqueries JDBC
Union & Minus
Views & Indexes
Check Constraints
Introduction
 What is a database?
 Why do we need one?
 Avoid redundancy
duplication of information in multiple tables within a database
 Data integrity
Refers to the validity of data
 Referential Integrity
ensures that relationships between tables remain consistent
 Deletion Anomalies
Deletion of one row of a table results in the deletion of
unintended information
Different Types of Databases
 Paper
 Flatfile
 Hierarchical
 Network
 Relational
 Object
Introduction – Redundancy
 The duplication of information in multiple tables
within a database
 Ex. School Records may all have info about you
 Admissions
 Enrollment Services
 Department
 Student Union
Introduction – Data Integrity
 Refers to the validity of data.
 Data integrity can be compromised in a number
of ways:
 Human errors when data is entered
 Errors that occur when data is transmitted from one
computer to another
 Software bugs or viruses
 Hardware malfunctions, such as disk crashes
 Natural disasters, such as fires and floods
Introduction – Referential Integrity
 Referential integrity ensures that relationships
between tables remain consistent.
 When one table has a foreign key to another
table, the concept of referential integrity states
that you may not add a record to the table that
contains the foreign key unless there is a
corresponding record in the linked table.
 It also includes the techniques known as
cascading update and cascading delete, which
ensure that changes made to the linked table
are reflected in the primary table.
Introduction – Deletion Anomalies
 A situation, usually caused by redundancy in the
database design, in which the deletion of one
row of a table results in the deletion of
unintended information
 Ex. You’re the only student enrolled in CECS
323 and you drop the course. As a result all the
info about CECS 323 is removed from the
catalog
Introduction – Relational Database
What is a relational database?
 Based on Relational Algebra
 Tables and their relationships to each other
 Easily navigated
 Popular
 Standard query language
 Familiar Concepts
Models and Languages
 Database design is a process of modeling an
enterprise in the real world.
 A database itself is a model of the real world that
contains selected information needed by the
enterprise.
 There are many models and languages used for
this modeling. Some of these are mathematically
based. Others are less formal and more intuitive.
Unified Modeling Language (UML)
 The Unified Modeling Language (UML) was designed
for software engineering of large systems using object-
oriented (OO) programming languages.
 UML is a very large language; we will use only a small
portion of it here, to model those portions of an
enterprise that will be represented in the database.
 It is our tool for communicating with the client in terms
that are used in the enterprise.
 Used to describe the conceptual view of a database.
Entity-Relationship (ER)
 The Entity-Relationship (ER) model is used in
many database development systems.
 There are many different graphic standards that
can represent the ER model. Some of the most
modern of these look very similar to the UML
class diagram, but may also include elements of
the relational model.
Relational Model (RM)
 The Relational Model (RM) is the formal model
of a database that was developed for IBM in the
early 1970s by Dr. E.F. Codd.
 It is largely based on set theory, which makes it
both powerful and easy to implement in
computers.
 All modern relational databases are based on
this model.
 We will use it to represent information that does
not (and should not) appear in the UML model
but is needed for us to build functioning
databases.
Relational Algebra (RA)
 Relational Algebra (RA) is a formal language
used to symbolically manipulate objects of the
relational model.
 Terms used to refer to the logical view of the
database.
Table Model
 The table model is an informal set of terms for
relational model objects. These are the terms
used most often by database developers.
 Terms used to refer to the physical view of the
database.
Structured Query Language (SQL)
 The Structured Query Language (SQL,
pronounced sequel or ess-que-ell) is used to
build and manipulate relational databases.
 It is based on relational algebra, but provides
additional capabilities that are needed in
commercial systems.
 It is a declarative, rather than a procedural,
programming language.
 There is a standard for this language, but
products vary in how closely they implement it.
Basic Structures: Classes and
Schemes – UML Class
 UML class (ER term: entity) is anything in the
enterprise that is to be represented in our database
 The first step in modeling a class is to describe it in
natural language.
Example: build a sales database. Let’s start by defining
customer using natural language.
 Attribute (properties) is a piece of information that
characterizes each member of a class
 Descriptive attributes (natural attribute) are those
which actually provide real-world information about the
class.
 UML only uses descriptive attributes
 ID number are not descriptive attributes
Basic Structures: Classes and
Schemes – Class Diagram
 A class diagram shows the class name and list of
attributes that identify data elements we need to know
about each member (instance, occurrence, of a class)
 The Customer class represents any person who has
done business with us or who we think might do
business with us in the future. Its attributes are:
 Customer first name.
 Customer last name.
 Customer phone.
 Customer street.
 Customer zip code.
Basic Structures: Classes and
Schemes – Relation Scheme
 In an OO programming language, each class is
instantiated with objects of that class. In building a
relational database, each class is first translated into a
relation model scheme. The scheme starts with all of
the attributes from the class diagram.

 The Customers relation scheme attributes are:

 Customer first name, a person's first name.
 Customer last name, a person's last name.
 Customer phone, a valid telephone number.
 Customer street, a street address.
 Customer zip code, a zip code designated by the United States Postal
Service.
Basic Structures: Classes and
Schemes – Sets
 In the relational model, a scheme is defined as a set of attributes,
together with an assignment rule that associates each attribute
with a set of legal values that may be assigned to it. These values
are called the domain of the attribute.
Customers Scheme = {cFirstname, cLastname, cPhone,
cStreet, cZipCode}.
 It’s important to recognize that defining schemes or domains as sets
of something automatically tells us a lot more about them:
 They cannot contain duplicate elements.
 The elements in them are unordered.
 We can develop rules for what can be included in them and what is
excluded from them. For example, zip codes don’t belong in the domain
(set) of phone numbers, and vice-versa.
 We can define subsets of them—for example, we can display only a
selected set of attributes from a scheme, or we can limit the domain of
an attribute to a specific range of values.
 They may be manipulated with the usual set operators (union,
intersection).
Basic Structures: Classes and
Schemes – Table Structure
When we actually build the database, each relation
scheme becomes the structure of one table.
CREATE TABLE customers (
cfirstname VARCHAR(20) NOT NULL,
clastname VARCHAR(20) NOT NULL,
cphone VARCHAR(20) NOT NULL,
cstreet VARCHAR(50),
czipcode VARCHAR(5));
Basic Structures: Classes and
Schemes – Data Models
 Conceptual
 Logical
 Physical
Basic Structures: Rows and Tables
- Definitions
 Each real-world individual of a class is
represented by a row of information in a
database table.
 The row is defined in the relational model as a
tuple that is constructed over a given scheme.
 Mathematically, the tuple is a function that
assigns a constant value from the attribute
domain to each attribute of the scheme. Since
the scheme is really a set of attributes, order is
not important.
Basic structures: Rows and Tables
– Assignment

 Each attribute of the Customers scheme is assigned a value from its

domain:
 Customer first name is assigned the value "Tom", from the domain of
people's first names.
 Customer last name is assigned the value "Jewett", from the domain of
people's last names.
 Customer phone is assigned the value "714-555-1212", from the
domain valid telephone numbers.
 Customer street is assigned the value "10200 Slater", from the domain
of street addresses.
 Customer zip code is assigned the value "92708", from the domain of
zip codes designated by the United States Postal Service.
 Each of the assignments results in a data cell of the row or tuple.
Basic Structures: Rows and Tables
– Formal Notation
In formal notation, we could show the assignments
explicitly, where t represents a tuple:
tTJ = ‹cfirstname := 'Tom', clastname := 'Jewett',
cphone := '714-555-1212', cstreet := '10200
Slater', czipcode := '92708'›
Database:
INSERT INTO customers (cfirstname,
clastname, cphone, cstreet, czipcode)
VALUES ('Tom', 'Jewett', '714-555-1212',
'10200 Slater', '92708');
UPDATE customers SET cphone = '714-555-
2323' WHERE cphone = '714-555-1212';
Basic Structures: Rows and Tables
- Database
 A database table is simply a collection of zero or
more rows. This follows from the relational
model definition of a relation as a set of tuples
over the same scheme. Order is not important.

 Additional rows are built on the Customers scheme as before. The table or
relation consists of all rows.
 Three of the attributes in the Customers scheme are now identified as the
primary key, which is explained later on.
Basic Structures: Rows and Tables
- Tuples
Knowing that the relation (table) is a set of tuples (rows)
tells us more about this structure, as we saw with
schemes and domains.
 Each tuple/row is unique; there are no duplicates
 Tuples/rows are unordered; we can display them in any way we
like and the meaning doesn’t change. (SQL gives us the
capability to control the display order.)
 Tuples/rows may be included in a relation/table set if they are
constructed on the scheme of that relation; they are excluded
otherwise. (It would make no sense to have an Order row in the
Customers table.)
 We can define subsets of the rows by specifying criteria for
inclusion in the subset. (Again, this is part of a SQL query.)
 We can find the union, intersection, or difference of the rows in
two or more tables, as long as they are constructed over the
same scheme.
Basic Structures: Rows and Tables
– Insuring Unique Rows
 Each row in a table must be distinct. So
there must be a set of attributes in each
relation that guarantee uniqueness. Any
set of attributes that can do this is called a
super key of the relation.
 The database designer picks of the
possible super key sets to serve as the
primary key or unique identifier of each
row.
Basic Structures: Rows and Tables
– Super Keys
cfirstname,clastname,cphone,cstreet,czipcode
cfirstname,clastname,cphone,cstreet
cfirstname,clastname,cphone,czipcode
cfirstname,clastname,cstreet,czipcode
cfirstname,clastname,cphone
cfirstname,clastname,cstreet
Basic Structures: Rows and Tables
– Insuring Unique Rows - SQL

ALTER TABLE customers

ADD CONSTRAINT customers_pk
PRIMARY KEY (cfirstname, clastname, cphone);
CREATE TABLE customers (
cfirstname VARCHAR(20) NOT NULL,
clastname VARCHAR(20) NOT NULL,
cphone VARCHAR(20) NOT NULL,
cstreet VARCHAR(50),
czipcode VARCHAR(5)),
CONSTRAINT customers_pk
PRIMARY KEY (cfirstname, clastname, cphone);
Basic Structures: Associations –
The UML Association
 UML association (ER term: relationship) is
the way that two classes are functionally
connected to each other.
 Example: relationship between customers and
orders in a sales database. First define orders
then define the relationship.
 UML multiplicity (ER term: cardinality) how
few (at minimum) and how many (at maximum)
individuals of one class may be connected to a
single individual of the other class.
Basic structures: Associations –
Class Diagram
One customer places zero to many orders
One order is placed by one and only one customer
Basic structures: Associations –
Class Diagram Data Dictionary
 The Customer class represents any person who has done business
with us or who we think might do business with us in the future. Its
attributes are:
 Customer first name.
 Customer last name.
 Customer phone.
 Customer street.
 Customer zip code.
 The Order class represents an event that happens when a customer
decides to buy one or more of our products. Its attributes are:
 Order date.
 Sold by, which identifies the sales person.
 The association between customer and order classes is:
 Each customer places zero or more orders.
 Each order is placed by one and only one customer.
Basic Structures: Associations –
Class Diagram Description
 Looking at the maximum multiplicity at each end
of the line (1 and * here), we call this a one-to-
many association.
 The UML representation of the Order class
contains only its own descriptive attributes. The
UML association tells which customer placed
an order.
 In the database, we will need a different way to
identify the customer; that will be part of the
relation scheme.
Basic Structures: Associations –
Relation Scheme
 The relation scheme for the new Orders table
contains all of the attributes from the class
diagram as before. But we also need to
represent the association in the database –
which customer placed each order. This is done
by copying the PK attributes of the Customer
into the Orders scheme.
 The copied attributes are called a foreign key.
Basic Structures: Associations –
Relation Scheme Diagram
Basic structures: Associations –
Relation Scheme Data Dictionary
 The Customers relation scheme attributes are:
 Customer first name, a person's first name.
 Customer last name, a person's last name.
 Customer phone, a valid telephone number.
 Customer street, a street address.
 Customer zip code, a zip code designated by the United States Postal Service.
 The primary key attributes of the Customers relation are the first name, last
name, and phone.
 The Orders relation scheme attributes are:
 Customer first name, foreign key from Customers.
 Customer last name, foreign key from Customers.
 Customer phone, foreign key from Customers.
 Order date, a calendar date possibly with the clock time.
 Sold by, the first name of the sales person taking the order.
 The primary key attributes of the Orders relation are the three foreign key
attributes plus the order date.
Basic Structures: Associations –
Relation Scheme Description
 Since we can’t have an order without a customer, we call
Customers the parent and Orders the child scheme in
this association.
 The “one” side of an association is always the parent,
and provides the PK attributes to be copied.
 The “many” side of an association is always the child,
into which the FK attributes are copied.
 Memorize it: one, parent, PK; many, child, FK.
 An FK might or might not become part of the PK of the
child relation into which it is copied. In this case, it does,
since we need to know both who placed an order and
when the order was placed in order to identify it uniquely.
Basic Structures: Associations –
The Child Table
CREATE TABLE orders (
cfirstname VARCHAR(20) NOT NULL,
clastname VARCHAR(20) NOT NULL,
cphone VARCHAR(20) NOT NULL,
orderdate DATE NOT NULL,
soldby VARCHAR(20));
 The FK attributes must be exactly the same data
type and size as in the PK table
 In some DBMS, DATE is both Date and Time
Basic Structures: Associations –
Uniqueness
 To insure that every row of the Orders table is
unique, we need to know both who the customer
is and what day (and time) the order was placed.
 We specify all of these attributes as the pk:
ALTER TABLE orders
ADD CONSTRAINT orders_pk
PRIMARY KEY (cfirstname, clastname,
cphone, orderdate);
Basic Structures: Associations –
Referential Integrity
In addition, we need to identify which attributes make up
the FK, and where they are found as a PK. The FK
constraint will insure that every order contains a valid
customer name and phone number—this is called
maintaining the referential integrity of the database.
ALTER TABLE orders
ADD CONSTRAINT orders_customers_fk
FOREIGN KEY(cfirstname, clastname,
cphone)
REFERENCES customers (cfirstname,
clastname, cphone);
Basic Structures: Associations –
The Orders Table
Another Example
 Let’s limit this enterprise to consider the
relationship between a University instructor and
the students in one class
Class Definitions
 A teacher is a person that instructs students
taking courses to learn.
 A student is someone enrolled in classes to
receive an education.
Relationship Definitions
 One teacher teaches one to many students.
 One student is taught by one and only one
teacher.
Primary Key
 For the primary key of Teacher, use tname and
tdob.
 Copy these PK attributes from the parent
(Teacher) to the child (Student) and mark them
as Foreign Keys.
 Question: does a Student need a Teacher to be
unique? No, the email itself can be used as the
PK of the student.
 This is an example of when the PK of the parent
is NOT part of the PK of a child.
Relation Scheme
SQL
 Even though in this example, the FK of the
parent does not become part of the PK of the
child, the Students table still needs to have the
FK attributes as part of the table and a FK
constraint must still be created.
CREATE TABLE teachers (
tname VARCHAR(20) NOT NULL,
tdept VARCHAR(20) NOT NULL,
tdob DATE NOT NULL);

ALTER TABLE teachers

ADD CONSTRAINT teachers_pk
PRIMARY KEY (tname,tdob);
Students Table
CREATE TABLE students (
tname VARCHAR(20) NOT NULL,
tdob DATE NOT NULL,
sname VARCHAR(20) NOT NULL,
smajor VARCHAR(20) NOT NULL,
semail VARCHAR(90) NOT NULL);

ALTER TABLE students

ADD CONSTRAINT students_pk
PRIMARY KEY (semail);

ALTER TABLE students

ADD CONSTRAINT students_teachers_fk
FOREIGN KEY (tname,tdob)
REFERENCES teachers (tname,tdob);
Discussion: More About Keys
Discussion: More About Keys –
Super Key
 Remember that a super key is any set of
attributes whose values, taken together,
uniquely identify each row of a table—and that a
primary key is the specific super key set of
attributes that we picked to serve as the unique
identifier for rows of this table.
 We are showing these attributes in the scheme
diagram for convenience, understanding that
keys are a property of the table (relation), not of
the scheme.
Discussion: More About Keys –
Candidate Keys
 Before picking the PK, we need to identify any candidate key or
keys that we can find for the table. A CK is a minimal super key.
Minimal means that if you take away any one attribute from the set,
it is no longer a super key.
If you add one attribute to the set, it is no longer minimal but it’s still
a super key. The word “candidate” simply means that this set of
attributes could be used as the primary key.
Whether a set of attributes constitutes a CK or not depends entirely
on the data in the table – not just on whatever data happens to be in
the table at that moment but on any set of data that could be
realistically be in the table over the life of the database.
 Does the set {cFirstName,cLastName,cPhone} meets the test.
If not, what other attributes might we need in the table to make a
candidate key?
Discussion: More About Keys – PK
Size Might Matter
 Copying three attributes from the parent table to the child
table each time a child record is created can be a lot of
data even if we have a valid candidate key. It may make
sense to “make up” a PK that is small enough. There are
two types of “made up” PKs:
 surrogate PK – a single, small attribute (such as a
number) that has no descriptive value such as an id
number
 substitute PK – a single, small attribute (such as an
abbreviation) that has at least some descriptive value.
Discussion: More About Keys –
Surrogate/Substitute Keys
 Do not automatically add surrogate or substitute keys to
a table until you are sure that
1. there is at least one candidate key before the surrogate is
added
2. the table is a parent in at least one association
3. there is no candidate key small enough for its values to be
copied many times into the child table
 external key – a surrogate or substitute key already
defined by someone else such as a zip code, UPC,
ISBN
 Only use a Social Security Number as a NON-KEY field
if required by law
Discussion: More About Keys –
Revising the Relation Scheme
Discussion: More About Keys –
Customer Joined to Orders
Design Pattern: Many-to-Many
(Order Entry)
 Design patterns are modeling situations that
you will find over and over again as you design
real databases. These become tools that you
use constantly use to build enterprise models.
 The sales database represents one of these
design patterns called “many-to-many.” In order
to complete the pattern we need products to sell.
Design Pattern: Many-to-Many
(Order Entry)–Finishing the Pattern
1. Define the product
2. Define the relationship between orders and products
3. Define the need for orderlines
 Since the maximum multiplicity in each direction is
“many,” this is called a many-to-many association
between Orders and Products.
 Each time an order is placed for a product, we need to
know how many units of that product are being ordered
and what price we are actually selling the product for.
These attributes are a result of the association between
the Order and the Product. We show them in an
association class that is connected to the association
by a dotted line.
Design Pattern: Many-to-Many
(Order Entry) – Class Diagram
Design Pattern: Many-to-Many
(Order Entry) – Junction Table
We can’t represent a many-to-many association
directly in a relation scheme, because two tables
can’t be children of each other—there’s no place
to put the foreign keys. So for every many-to-
many, we will need a junction table in the
database, and we need to show the scheme of
this table in our diagram.
Design Pattern: Many-to-Many
(Order Entry) – Relation Scheme
Design Pattern: Many-to-Many
(Order Entry) – Data Representation
Design Pattern: Many-to-Many With
History (the Library Loan)
 There are times when we need to allow the same two
individuals in a many-to-many association to be paired
more than once. This frequently happens when we need
to keep a history of events over time.
 Example: In a library, customers can borrow many books
and each book can be borrowed by many customers, so
this seems to be a simple many-to-many association
between customers and books. But any one customer
may borrow a book, return it, and then borrow the same
book again at a later time. The library records each book
loan separately; there is no invoice for each set of
borrowed books (that is, there is no equivalent here of
the Order in the order entry example).
Design Pattern: Many-to-Many With
History (the Library Loan) – Classes
The loan is an event that happens in the real world. We need a regular
class to model it correctly. We’ll call this the “library loan” design
pattern. First, we need to understand what the classes and
associations mean:
 “A customer is any person who has registered with the library and
is eligible to check out books.”
 “A catalog entry is essentially the same as an old-fashioned index
card that represents the title and other information about books in
the library, and allows the customers to quickly find a book on the
shelves.”
 “A book is the physical volume that is either sitting on the library
shelves or is checked out by a customer. There can be many
physical books represented by any one catalog entry.”
 “A loan event happens when one customer takes one book to the
checkout counter, has the book and her library card scanned, and
then takes the book home to read.”
Design Pattern: Many-to-Many With
History (the Library Loan)-Associations
 “Each Customer makes zero or more Loans.”
 “Each Loan is made by one and only one
Customer.”
 “Each Loan checks out one and only one Book.”
 “Each Book is checked out by zero or more
Loans.”
 “Each Book is represented by one and only one
CatalogEntry (catalog card).”
 “Each CatalogEntry can represent one or more
physical copies of the same book.”
Design Pattern: Many-to-Many With
History(Library Loan)–Class Diagram
Design Pattern: Many-to-Many With
History (Library Loan)–Keys
 As in the order entry example, the Customers table will need a
surrogate key to save space when it is copied in the Loans.
 The CatalogEntry already has two external surrogate keys: the call
number and the ISBN.
 The first of these is defined by the Library of Congress Classification
system, and contains codes that represent the subject, author, and year
published.
 The second of these is defined by a standard, number 2108. We’ll use
the callNmbr as the primary key, since it has more descriptive value
than the ISBN and is smaller than the descriptive candidate key:
CK {title, pubDate}
 The dateTimeOut is needed as part of the key in the Loans table in
order to pair a customer with the same book more than once.
Design Pattern: Many-to-Many With
History (Library Loan)–Diagram
Design Pattern: Many-to-Many With
History (Library Loan)
 As we would do in a junction table scheme, we’ll copy the primary key
attributes from both the Customers and the BooksOnShelf into the Loans
scheme. This tells us which customer borrowed which book, but it doesn't
tell when it was borrowed. We have to know the dateTimeOut in order to
pair a customer with the same book more than once.
 We can call this a discriminator attribute, since it allows us to discriminate
between the multiple pairings of customer and book. If you refer back to the
UML class diagram, you’ll see that the loan, which would have been a
many-to-many association class between customers and books, has
become a “real” class because of the discriminator attribute.
 Notice that there is actually another CK for the loan:
{dateTimeOut, scannerID}
since it is also physically impossible for the same scanner to read two different
books at exactly the same time.
 We chose {callNmbr, copyNmbr, dateTimeOut} because it has just
a bit more descriptive value and because we don’t care about size here
(since the Loan has no children).
Design Pattern: Subkeys (the Zipcode)
 One of the major goals of relational database design is
to prevent unnecessary duplication of data.
 The Contact class represents any person who is a
business associate, friend, or family member. Its
attributes are:
 Contact first name.
 Contact last name.
 Contact street.
 Contact zip code.
 Contact city.
 Contact state.
Design Pattern: Subkeys (the Zipcode)
- Problem
It may not be obvious that the model has a
problem until you look at the data
Design Pattern: Subkeys (the Zipcode)
– Functional Dependency
 functional dependency is simply a more formal term for
the super key property. If X and Y are sets of attributes,
then the notation X→Y is read “X functionally determines
Y” or “Y is functionally dependent on X.” This means that
if I’m given a table filled with data plus the value of the
attributes in X, then I can uniquely determine the value of
the attributes in Y.
 A super key always functionally determines all of the
other attributes in a relation (as well as itself). This is a
“good” FD. A “bad” FD happens when we have an
attribute or set of attributes that are a super key for some
of the other attributes in the relation, but not a super key
for the entire relation. We call this set of attributes a
subkey of the relation.
Design Pattern: Subkeys (the Zipcode)
– Functional Dependency (con’t).
 A subkey dependency enables us to detect
when a relation scheme has redundancy -- when
a table using the scheme will contain
unnecessary duplication of information.
 A relation scheme has redundancy whenever
there is a subkey dependency.
Design Pattern: Subkeys (the Zipcode)
– Preventing/Removing Redundancy
 There is a very simple way to fix the problem
with a relation scheme that has redundancy, as
detected by the presence of a subkey.
 In the steps given below, the scheme with
redundancy is R and the subkey is represented
by the FD W→Z, where each of W and Z is a set
of attributes that is a subset of the attributes in
R.
Design Pattern: Subkeys (the Zipcode) –
Preventing/Removing Redundancy(con’t).
Replace R by two schema, R1 and R2 as described in
the following steps.
1. Assign R1 the attributes in the union of the
attributes in the subkey FD. That is R1={W ∪ Z}.
Since W→Z, by definition, W is a superkey of R1.
2. Assign R2 the set of attributes {R - Z}, that is, all
the attributes in R except those in Z, the attributes
on the right-hand-side of the subkey FD
3. Both R1 and R2 share W in common. In R1, W is a
superkey and in R2 it becomes a foreign key.
Design Pattern: Subkeys (the Zipcode) –
Preventing/Removing Redundancy(con’t).
 The “bad” subkey dependency has been
removed because we’ve moved the attributes
that were functionally dependent on W to
another scheme, and we’ve made W the super
key of that scheme.
Design Pattern: Subkeys (the Zipcode)
- Solution
In other words:
1. Remove all of the attributes that are dependent on the
subkey. Put them into a new scheme.
2. Duplicate the subkey attribute set in the new scheme,
where it becomes the primary key of the new scheme.
3. Leave a copy of the subkey attribute set in the original
scheme, where it is now a foreign key. It is no longer a
subkey, because you’ve gotten rid of the attributes that
were functionally dependent on it, and you’ve made it
the primary key of its own table. The revised model will
have a many-to-one relationship between the original
scheme and the new one.
Design Pattern: Subkeys (the Zipcode)
- Subkey
In the Contacts table, the zipCode is a subkey. It
functionally determines the city and state. The
opposite is not true, because many cities have
more than one zip code.
Design Pattern: Subkeys (the Zipcode)
– Lossless Join Decomposition
Moving the data to a new table and then joining
the two tables is called lossless join
decomposition of the original table
Design Pattern: Subkeys (the Zipcode)
- Normalization
 Normalization means following a procedure or set of rules to
insure that a database is well designed. Most normalization rules
are meant to eliminate redundant data (that is, unnecessary
duplicate data) in the database.
 Subkeys always result in redundant data, so we need to eliminate
them. If there are no subkeys in any of the tables in your database,
you have a well-designed model according to what is usually called
third normal form, or 3NF.
 Edgar F. Codd was a mathematician and computer scientist who
laid the theoretical foundation for relational databases.
 “The key, the whole key and nothing but the key so help me Codd”
Design Pattern: Subkeys (the Zipcode)
– Class Diagram
 When we find a subkey in a relation scheme or table, we also know
that the original UML class was badly designed. The problem,
always, is that we have actually placed two conceptually different
classes in a single class definition.
 In this example, a zipCode is not just an attribute of the Contact
class. It is part of a ZipLocation class, which we can describe as “a
geographical location whose boundaries have been uniquely
identified by the U.S Postal Service for mail delivery.”
 As with all one-to-many associations, the association itself
identifies which Contact lives in which ZipLocation. If we had
started with this class diagram, we would have produced exactly
the same relation scheme that we developed with the normalization
process above!
Design Pattern: Repeated
Attributes (the Phone Book)
The contact manager example from our preceding
discussion of subkeys is also an excellent
illustration of another problem that is found in
many database designs.
Design Pattern: Repeated Attributes
(the Phone Book) – Weak Entity
 Note the large amount of null values and the
inability of the model to keep up with changing
times. Notice that the phone numbers are
actually repeated attributes. It is essentially a
class within a class.
 This can be called a weak entity since it can’t
exist without the parent entity type.
Design Pattern: Repeated
Attributes (the Phone Book) - Fix
In order to fix this problem we need to create a new table:
1. Remove all of the phone number fields from the
Contacts relation. Create a new scheme that has the
attributes of the phone number structure (phone type
and number).
2. The Contacts relation has now become a parent so we
add a surrogate key and copy it into the new scheme.
There is now a one-to-many relationship between
Contacts and PhoneNumbers.
3. To identify each phone number, we need to know at
least who it belongs to and what type it is. However, a
person can have two cell phones so all three attributes
are needed for the PK. Since this is not a parent relation,
the PK size doesn’t matter.
Design Pattern: Repeated Attributes
(the Phone Book) - Relation Scheme
Design Pattern: Repeated Attributes
(the Phone Book) – Tables
Design Pattern: Repeated Attributes
(the Phone Book) - Employees
The modeling technique shown above is useful where the parent class has
relatively few attributes and the repeated attribute has only one or a very few
attributes of its own. However, you can also model the repeated attribute as a
separate class in the UML diagram. One classic textbook example is an
employee database.
Design Pattern: Repeated Attributes
(the Phone Book) – Employees (cont)
 This is the same example using the “shorthand”
notation. Employee
-empFname
-empLane
-officePhone
-jobTitle
-payGrade
-dependent[0..*]:Dependents
-(depFname)
-(depLname)
-(dateOfBirth)
-(relationship)
Design Pattern: Multi-Valued
Attributes (Hobbies)
 When there are many distinct values entered in
the same column of the table we have another
design problem called multi-valued attributes .
 This makes it difficult to search the table for any
one particular value and it is impossible to
create a query that will individual list the values
in that column. For example: hobbies.
Design Pattern: Multi-Valued
Attributes (Hobbies) – Class Diagram
Design Pattern: Multi-Valued
Attributes (Hobbies) - Corrected
Discussion: More About Domains
 Remember that a domain is the set of legal values that
can be assigned to an attribute. Each attribute in a
database must have a well-defined domain.
 One goal of database developers is provide data
integrity, part of which means insuring that the value
entered in each field of a table is consistent with its
attribute domain.
 Sometimes it’s possible to devise a validation rule to
help with this. Before you can design the data type and
input format for an attribute, you have to understand the
characteristic of its domain.
Discussion: More About Domains -
Validation
 Some domains can only be described with a general
statement of what they contain. Examples: name,
addresses. For this, use a VARCHAR2 string that is
long enough to hold the expected value.
 Some domains have at least some pattern. Examples,
email addresses, URLs, North American phone
numbers. These must be validated programmatically
such as with a regular expression.
 Some domains have precise patterns. For example,
SSNs and zip code.
Discussion: More About Domains –
More Validations
 Easy domains to handle are those which can be
specified by a well-defined, built-in system data type.
These include integers, real numbers, and dates/times.
 You might need a range check.
 In most systems, a Boolean data type is also available
although Oracle does not.
 Finally, there are many domains that may be specified
by a well-defined, reasonably-sized set of constant
values. These are enumerated domains and we’ll cover
these in the next section. For example, departments in
the school, states.
Design Pattern: Enumerated Domains
 Attribute domains that may be specified by a
well-defined, reasonable-size set of constant
values are called enumerated domains. These
values should be kept in a separate table.
Tables that are created for this purpose are
commonly called lookup tables.
 Although it might appear that this technique will
create too many tables and query joins, the
advantages outweigh the disadvantages. You
can always break the rule if you have to for
performance reasons.
Design Pattern: Enumerated Domains
- Advantages
1. Data Integrity – changing the data in one place,
avoiding deletion anomalies
2. You can read the values form the table into a combo
box, list box or similar input control on either a web
page or a GUI form. This allows the user to easily select
only values that are valid in this domain at this time.
3. You can always update the table if new values are
added to the domain, or if existing values are changed.
This is much easier than modifying your user-interface
code or your table structure.
Design Pattern: Enumerated Domains
– Class Diagram
In our earlier ZipLocations example, the state attribute clearly
fits the definition of an enumerated domain. In UML, we can
simply use a data type specification to show this, without
adding a new class type.
Design Pattern: Enumerated Domains
– Relation Scheme
The relation scheme will show the table that
contains the enumerated domain values. This
table might have a single attribute, or it might
have two attributes: one for the true values and
one for a substitute key. The true values always
form a candidate key of the table.
Design Pattern: Enumerated Domains
– Multi-Valued Attributes
Multi-valued attributes might also have enumerated
domains.
Design Pattern: Enumerated Domains
– Many-to-Many Relation Scheme
In the scheme, the relationship between Contacts and Hobbies has
become many-to-many, instead of one-to-many. This is shown in the
scheme by linking an enumeration table to the previous Hobbies
tables (which now functions like an association class).
Design Pattern: Subclasses –Top
Down Design
 As you are developing a class diagram, you might discover that one
or more attributes of a class are characteristics of only some
individuals of that class, but not of others. This probably indicates
that you need to develop a subclass of the basic class type. We call
the process of designing subclasses from “top down”
specialization. A class that represents a subset of another class
type can also be called a specialization of its parent class.
 Example: we will model the graduate students at a university. Some
are employed by the university as teaching associates (TAs). Some
are employed as research associates (RAs). Some are not
employed by the university at all. For the TAs, we need to know
which course they are assigned to teach. For the RAs, we need to
know the grant number of the research project to which they are
assigned.
Design Pattern: Subclasses –Top
Down Design – Class Diagrams

 Note that one of the attributes courseAssignment or

researchGrant will always be null

 Common attributes are in the parent class, unique

attributes are in the subclass
Design Pattern: Subclasses –Top Down
Design–Specialization Constraints
 Rather than with the usual cardinality symbols, the
subclass association line is label with specialization
constraints. Constraints are described along two
dimensions: incomplete vs. complete, and disjoint vs.
overlapping.
 incomplete or partial specialization, only some individuals of
the parent class are specialized.
 complete specialization, all individuals of the parent class have
one or more unique attributes that are not common to the
generalized (parent) class.
 disjoint or exclusive specialization, an individual of the parent
class may be a member of only one specialized subclass.
 overlapping specialization, an individual of the parent class may
be a member of more than one specialized subclass.
Design Pattern: Subclasses –Top
Down Design – Relation Scheme
Note that the PK of the parent is the PK/FK of the
child as this is a one-to-one relationship.
Design Pattern: Subclasses - Bottom
Up Design
 Sometimes, instead of finding unique attributes in a
single class type, you might find two or more classes that
have many of the same attributes. This probably
indicates that you need to develop a superclass of the
classes with common attributes.
 We call the process of designing subclasses from
“bottom up” generalization. A class or entity that
represents a superset of other class types can also be
called a generalization of the child types.
 Example: Consider a brush-clearing service. This is a
fairly specialized business, where dried plant growth
(brush) can present a severe fire hazard if it is not
cleared from around houses and other structures.
Design Pattern: Subclasses – Bottom
Up Design – Class Diagram
 One important class type was the lot (or
property) to be cleared. Some lots were in the
city, with a standard street-and-number address.
 Other lots were not on a city street, but were
described by the county surveyor's section and
tract number.
 It seemed as if there were two class types:
Design Pattern: Subclasses – Bottom
Up Design – Relation Scheme
Actually, a few of the lots were identified by both
address schemes. A closer look at the city and
county lot classes also shows two common
descriptive attributes (the owner and the lot
size). The common attributes should go in a
generalization or superclass that is simply
called a “lot.”
Design Pattern: Aggregation
 An aggregation is when a class type really
represents a collection of individual components.
Although this pattern can be modeled by an
ordinary association, its meaning becomes
much clearer if we use the UML notation for an
aggregation.
 Example: a small business needs to keep track
of its computer systems. They want to record
information such as model and serial number for
each system and its components.
Design Pattern: Aggregation –
Incorrect Model vs. Improved Model
Note that the incorrect model uses repeated
attributes for the components. This is fixed in the
improved model although there are still some
problems – what if there are components on the
shelf that don’t belong to a system
Design Pattern: Aggregation – Model
with UML Aggregation
 The system is an aggregation of components.
 There is an implied multiplicity on the diamond
end of 0..1 with multiplicity of the other end
shown in the diagram.
Design Pattern: Aggregation –
Relation Scheme
 Since the component can exist by itself in this
model the system name can’t be part of its PK.
 We use the only candidate key
{type,mgr,model,SN} as the PK since this
class is not a parent. The system name, will be
filled in if the component is installed as part of a
system, otherwise it will be null.
Design Pattern: Aggregation –
Composition
 A composition is a stronger form of
aggregation. The notation is similar using a
filled-in diamond instead of an open one. In a
composition, a component instance cannot exist
on its own without a parent.
 The implied multiplicity on the diamond end is
1..1.
Design Pattern: Aggregation –
Composition Examples
Design Pattern: Aggregation –
Definitions
 Aggregation – (“has a” relationship)
In an aggregation relationship, the part may be
independent of the whole but the whole requires
the part.
 Composition – (“uses a” relationship)
A composition relationship, also know as a
composite aggregation, is a stronger form of
aggregation where the part is created and
destroyed with the whole.
Design Pattern: Recursive
Associations
 A recursive association connects a single
class type (serving in one role) to itself (serving
in another role).
 Example: employees and their managers
Design Pattern: Recursive
Associations – Incorrect Relationship
The problem with this model is that each manager
is also an employee so the manager table
duplicates information in the employee table.
Design Pattern: Recursive
Associations – Correct Relationship
Normally, we wouldn’t show an FK in the class
diagram; however, including the manager as an
attribute of the employee here (in addition to the
association line) can help in understanding the
model.
Design Pattern: Recursive
Associations – Relation Scheme
In the relation scheme, we can explicitly show the
connection between the surrogate PK
(employeeID) and the managerID (which is an
FK, even though it is in the same scheme).
Design Pattern: Recursive Associations
– Many-to-Many Class Diagram
 In some project-oriented companies, an
employee might work for more than one
manager at a time.
 We also might want to keep a history of the
employees’ supervision assignments over time.
We can model either case by revising the class
diagram to a many-to-many pattern.
Design Pattern: Recursive Associations
– Many-to-Many Relation Scheme
The relation scheme for this model looks exactly
like other many-to-many applications, with the
exception that both foreign keys come from the
same PK table.
Design Pattern: Recursive
Associations – Retrieving Data
SELECT E.lastName AS "Employee",
M.lastName AS "Manager"
FROM Employees E LEFT OUTER JOIN
Employees M
ON E.managerID = M.employeeID
ORDER BY E.lastName
Design Pattern: Recursive Associations
– Retrieving Data Many-to-Many
SELECT E.lastName AS "Employee",
M.lastName AS "Manager"
FROM Employees E LEFT OUTER JOIN
(Supervisions S INNER JOIN
Employees M ON S.managerID =
M.employeeID)
ON E.employeeID = S.employeeID
ORDER BY E.lastName
Appendix: Traditional Normalization
 Normalization is usually thought of as a process of applying a set of
rules to your database design, mostly to achieve minimum
redundancy in the data. Most textbooks present this as a three-step
process, with correspondingly label “normal forms.
 In theory, you could start with a single relation scheme (sometimes
called the universal scheme, or U) that contains all of the attributes
in the database—then apply these rules recursively to develop a set
of increasingly-normalized sub-relation schemes. When all of the
schemes are in third normal form, then the whole database is
properly normalized.
 In practice, you will more likely apply the rules gradually, refining
each relation scheme as you develop it from the UML class diagram
or ER model diagram. The final table structures should be the same
no matter which method (or combination of methods) you’ve used.
Appendix: Traditional Normalization
– Normal Forms
Functional Dependency-FD
 A functional dependency (FD) is a type of
relationship between attributes
 If A and B are sets of attributes of relation R, we
say B is functionally dependent on A if each A
value in R has associated with it exactly one
value of B in R.
 Alternatively, if two tuples have the same A
values, they must also have the same B values
 Write A→B, read A functionally determines B,
or B functionally dependent on A
 FD is actually a many-to-one relationship
between A and B
Example of FDs
Stuid lastName major credits status socSecNo
S1001 Smith History 90 Senior 100429500
S1003 Jones Math 95 Senior 010124567
S1006 Lee CSC 15 Freshman 088520876
S1010 Burns Art 63 Junior 099320985
S1060 Jones CSC 25 Freshman 064624738

 Let R be
NewStudent(stuId, lastName, major, credits, status, socSecNo)
 FDs in R include
{stuId}→{lastName}, but not the reverse
{stuId} →{lastName, major, credits, status, socSecNo,
stuId}
{socSecNo} →{stuId, lastName, major, credits, status,
socSecNo}
{credits}→{status}, but not {status}→{credits}
Trivial Functional Dependency
 The FD X→Y is trivial if set {Y} is a subset of
set {X}

Examples: If A and B are attributes of R,

{A}→{A}
{A,B} →{A}
{A,B} →{B}
{A,B} →{A,B}
are all trivial FDs
 First Normal Form-1NF
 A relation is in 1NF if and only if every attribute is
single-valued for each tuple
 Each cell of the table has only one value in it
 Domains of attributes are atomic: no sets, lists,
repeating fields or groups allowed in domains
Counter-Example for 1NF
Stuid lastName major credits status socSecNo
S1001 Smith History 90 Senior 100429500
S1003 Jones Math 95 Senior 010124567
S1006 Lee Math 15 Freshman 088520876
CSC
S1010 Burns English 63 Junior 099320985
Art
S1060 Jones CSC 25 Freshman 064624738

NewStu(StuId, lastName, major, credits, status,

socSecNo) – Assume students can have more
than one major
The major attribute is not single-valued for each
tuple
Ensuring 1NF

 Best solution: For each multi-valued attribute,

create a new table, in which you place the key
of the original table and the multi-valued
attribute. Keep the original table, with its key
Ex. NewStu2(stuId, lastName, credits,status, socSecNo)
Majors(stuId, major)
Majors
NewStu2 stuId major
Stuid lastName credits status socSecNo S1001 History
S1001 Smith 90 Senior 100429500 S1003 Math
S1003 Jones 95 Senior 010124567 S1006 CSC
S1006 Lee 15 Freshman 088520876 S1006 Math
S1010 Burns 63 Junior 099320985 S1010 Art
S1060 Jones 25 Freshman 064624738 S1010 English
S1060 CSC
Full Functional Dependency
 In relation R, set of attributes B is fully
functionally dependent on set of attributes A of
R if B is functionally dependent on A but not
functionally dependent on any proper subset of
A
 This means every attribute in A is needed to
functionally determine B
 Must have multivalued key for relation to have
FD problem
Partial Functional Dependency
Example
NewClass( courseNo, stuId, stuLastName, facId, schedule, room, grade)

FDs:
{courseNo,stuId} → {lastName}
{courseNo,stuId} →{facId}
{courseNo,stuId} →{schedule}
{courseNo,stuId} →{room}
{courseNo,stuId} →{grade}
courseNo → facId **partial FD
courseNo → schedule **partial FD
courseNo →room ** partial FD
stuId → lastName ** partial FD
…plus trivial FDs that are partial…
Second Normal Form-2NF
 A relation is in second normal form (2NF) if it is
in first normal form and all the non-key attributes
are fully functionally dependent on the key.
 No non-key attribute is FD on just part of the key
 If key has only one attribute, and R is 1NF, R is
automatically 2NF
Converting to 2NF
 Identify each partial FD
 Remove the attributes that depend on each of
the determinants so identified
 Place these determinants in separate relations
along with their dependent attributes
 In original relation keep the composite key and
any attributes that are fully functionally
dependent on all of it
 Even if the composite key has no dependent
attributes, keep that relation to connect logically
the others
2NF Example
NewClass(courseNo, stuId, stuLastName, facId, schedule, room, grade )

FDs grouped by determinant:

{courseNo} → {courseNo,facId, schedule, room}
{stuId} → {stuId, lastName}
{courseNo,stuId} → {courseNo, stuId, facId, schedule,
room, lastName, grade}

Create tables grouped by determinants:

Class2(courseNo,facId, schedule, room)
Stu(stuId, lastName)
Keep relation with original composite key, with attributes FD on it, if any
Register( courseNo, stuId, grade)
2NF Example
courseNo stuId stuLastName facId schedule room grade
ART103A S1001 Smith F101 MWF9 H221 A
First Normal Form Relation
ART103A S1010 Burns F101 MWF9 H221
ART103A S1006 Lee F101 MWF9 H221 B
CSC201A S1003 Jones F105 TUTHF10 M110 A
CSC201A S1006 Lee F105 TUTHF10 M110 C
HST205A S1001 Smith F202 MWF11 H221

Register Stu Class2

courseNo stuId grade stuId stuLastName courseNo facId schedule room

ART103A S1001 A S1001 Smith ART103A F101 MWF9 H221

ART103A S1010 S1010 Burns CSC201A F105 TUTHF10 M110

ART103A S1006 B S1006 Lee HST205A F202 MWF11 H221

CSC201A S1003 A S1003 Jones

CSC201A S1006 C
HST205A S1001

Second Normal Form Relations

Transitive Dependency
 If A, B, and C are attributes of relation R, such
that A → B, and B → C, then C is transitively
dependent on A

Example:
NewStudent (stuId, lastName, major, credits, status)
FD:
credits→status (and several others)

By transitivity:
stuId→credits  credits→status implies stuId→status

Transitive dependencies cause update, insertion, deletion anomalies.

Third Normal Form-3NF
 A relation is in third normal form (3NF) if
whenever a non-trivial functional dependency
X→A exists, then either X is a superkey or A is a
member of some candidate key
 To be 3NF, relation must be 2NF and have no
transitive dependencies
 No non-key attribute determines another non-
key attribute. Here key includes “candidate key”
Example Transitive Dependency
NewStudent

Stuid lastName Major Credits Status

S1001 Smith History 90 Senior
S1003 Jones Math 95 Senior
S1006 Lee CSC 15 Freshman
S1010 Burns Art 63 Junior
S1060 Jones CSC 25 Freshman
Transitive Dependency: Stuid  Credits and Credits  Status
NewStu2 Stats
Stuid lastName Major Credits Credits Status
S1001 Smith History 90 15 Freshman
S1003 Jones Math 95 25 Freshman
S1006 Lee CSC 15 63 Junior
S1010 Burns Art 63 90 Senior
S1060 Jones CSC 25 95 Senior

Removed Transitive Dependency

Making a relation 3NF
 For example,
NewStudent (stuId, lastName, major, credits, status)
with FD credits→status

 Remove the dependent attribute, status, from the

relation
 Create a new table with the dependent attribute and its
determinant, credits
 Keep the determinant in the original table

NewStu2 (stuId, lastName, major, credits)

Stats (credits, status)
Appendix: Traditional Normalization
– Denormalization
 You database will always be part of a larger
system, which will include at least a user
interface and reporting structure or the back-end
of a Web site, with both middle-tier business
logic and front-end presentation code dependent
on it.
 It is not uncommon for developers to “break the
rules” of database design in order to
accommodate other parts of a system. This is
called denormalization.
Appendix: Traditional Normalization
– Denormalization for Efficiency
 An example of denormalization, using our “phone book”
problem, would be to store the city and state attributes in
the basic contacts table, rather than making a separate
zip codes table.
 At the cost of extra storage, this would save one join in a
SELECT statement. Although this would certainly not be
needed in such a simple system, imagine a Web site that
supports thousands of “hits” per second, with much more
complicated queries needed to produce the output.
 With today’s terabyte disk systems, it might be worth
using extra storage space to keep Web viewers from
waiting excessively while a page is being generated.
Boyce-Codd Normal Form-BCNF
 A relation is in Boyce/Codd Normal Form
(BCNF) if whenever a non-trivial functional
dependency X→A exists, then X is a superkey
(trivial means that A is a subset of X)
 Stricter than 3NF, which allows A to be part of a
candidate key
 If there is just one single candidate key, the
forms are equivalent
BCNF Example
NewFac (facName, dept, office, rank, dateHired)

FDs:
office → dept
facName,dept → office, rank, dateHired
facName,office → dept, rank, dateHired

 NewFac is 3NF but not BCNF because office is not a superkey

 To make it BCNF, remove the dependent attributes to a new
relation, with the determinant as the key
 Decompose into
Fac1 (office, dept)
Fac2 (facName, office, rank, dateHired)

Note we have lost a functional dependency in Fac2 – no longer able to

see that {facName, dept} is a determinant, since they are in
different relations
Example Boyce-Codd Normal Form
Faculty
facName dept office rank dateHired
Adams Art A101 Professor 1975
Byrne Math M201 Assistant 2000
Davis Art A101 Associate 1992
Gordon Math M201 Professor 1982
Hughes Mth M203 Associate 1990
Smith CSC C101 Professor 1980
Smith History H102 Associate 1990
Tanaka CSC C101 Instructor 2001
Vaughn CSC C101 Associate 1995

Fac1 Fac2
office dept facName office rank dateHired
A101 Art Adams A101 Professor 1975
C101 CSC Byrne M201 Assistant 2000
C105 CSC Davis A101 Associate 1992
H102 History Gordon M201 Professor 1982
M201 Math Hughes M203 Associate 1990
M203 Math Smith C101 Professor 1980
Smith H102 Associate 1990
Tanaka C101 Instructor 2001
Vaughn C101 Associate 1995
Converting to BCNF
 Identify all determinants and verify that they are
superkeys in the relation
 If not, break up the relation by decomposition
 for each non-superkey determinant, create a separate
relation with all the attributes it determines, also
keeping it in original relation
 Preserve the ability to recreate the original relation by
joins.
 Repeat on each relation until you have a set of
relations all in BCNF
 Normalization Example
 Relation that stores information about projects in
large business
 Work (projName, projMgr, empId, hours, empName,
budget, startDate, salary, empMgr, empDept, rating)

prijName projMgr empId hours Emp budget startDate salary Emp Emp rating
Name Mgr Dept
Jupiter Smith E101 25 Jones 100000 01/15/04 60000 Levine 10 9

Jupiter Smith E105 40 Adams 100000 01/15/04 55000 Jones 12

Jupiter Smith E110 10 Rivera 100000 01/15/04 43000 Levine 10 8

Maxima Lee E101 15 Jones 200000 03/01/04 60000 Levine 10

Maxima Lee E110 30 Rivera 200000 03/01/04 43000 Levine 10

Maxima Lee E120 15 Tanaka 200000 03/01/04 45000 Jones 15

 Normalization Example (cont)

1. Each project has a unique name.

2. Although project names are unique, names of employees
and managers are not.
3. Each project has one manager, whose name is stored in
projMgr.
4. Many employees can be assigned to work on each
project, and an employee can be assigned to more than
one project. The attribute hours tells the number of
hours per week a particular employee is assigned to work
on a particular project.
5. budget stores the amount budgeted for a project, and
startDate gives the starting date for a project.
6. salary gives the annual compensation of an employee.
Normalization Example (cont)

7. empMgr gives the name of the employee’s

manager, who might not be the same as the project
manager.
8. empDept gives the employee’s department.
Department names are unique. The employee’s
manager is the manager of the employee’s
department.
9. rating gives the employee’s performance for a
particular project. The project manager assigns the
rating at the end of the employee’s work on the
project.
Normalization Example (cont)
 Functional dependencies
 projName  projMgr, budget, startDate
 empId  empName, salary, empMgr, empDept
 projName, empId  hours, rating
 empDept  empMgr
 empMgr does not functionally determine empDept since
people's names were not unique (different managers may
have same name and manage different departments or a
manager may manage more than one department
 projMgr does not determine projName
 Primary Key
 projName, empId since every member depends
on that combination
Normalization Example (cont)

 First Normal Form

 With the primary key each cell is single valued,
Work in 1NF
 Second Normal Form
 Partial dependencies
 projName  projMgr, budget, startDate
 empId  empName, salary, empMgr, empDept
 Transform to
 Proj (projName, projMgr, budget, startDate)
 Emp (empId, empName, salary, empMgr, empDept)
 Work1 (projName, empId, hours, rating)
Normalization Example (cont)

Second Normal Form Work1

Proj prijName empId hours rating

Jupiter E101 25 9
prijName projMgr budget startDate
Jupiter E105 40
Jupiter Smith 100000 01/15/04
Jupiter E110 10 8
Maxima Lee 200000 03/01/04
Maxima E101 15
Maxima E110 30
Maxima E120 15

Emp

empId empName salary empMgr empDept

E101 Jones 60000 Levine 10
E105 Adams 55000 Jones 12
E110 Rivera 43000 Levine 10
E101 Jones 60000 Levine 10
E110 Rivera 43000 Levine 10
E120 Tanaka 45000 Jones 15
Normalization Example (cont)

 Third Normal Form

 Proj in 3NF – no non-key atrribute functionally
determines another non-key attribute
 Work1 in 3NF – no transitive dependency
involving hours or rating
 Emp not in 3NF – transitive dependency
 empDept  empMgr and empDept is not a superkey,
nor is empMgr part of a candidate key
 Need two relations
 Emp1 (empId, empName, salary, empDept)
 Dep (empDept, empMgr)
Normalization Example (cont)
Third Normal Form
Emp1 Dept
empId empName salary empDept empDept empMgr
E101 Jones 60000 10 10 Levine
E105 Adams 55000 12 12 Jones
E110 Rivera 43000 10
15 Jones
E120 Tanaka 45000 15

Proj Work1
prijName empId hours rating
prijName projMgr budget startDate Jupiter E101 25 9
Jupiter Smith 100000 01/15/04
Jupiter E105 40
Maxima Lee 200000 03/01/04
Jupiter E110 10 8
Maxima E101 15
Maxima E110 30
Maxima E120 15

This is also BCNF since the only determinant

in each relation is the primary key
Decomposition

 Definition: A decomposition of a relation R is a

set of relations {R1,R2,...,Rn} such that each Ri is
a subset of R and the union of all of the Ri is R.

 Starting with a universal relation that contains all

the attributes of a schema, we can decompose
into relations
Desirable Properties of
Decompositions
 Attribute preservation - every attribute is in
some relation

 Dependency preservation – all FDs are

preserved

 Lossless decomposition – can get back the

original relation by joins
Dependency Preservation
 If R is decomposed into {R1,R2,…,Rn,} so that
for each functional dependency X→Y all the
attributes in X  Y appear in the same relation,
Ri, then all FDs are preserved
 Allows DBMS to check each FD constraint by
checking just one table for each
Example
Sometimes more important to maintain functional dependencies that it is to get
the relation in BCNF

NewFac (facName, dept, office, rank, dateHired)

FDs:
office → dept
facName,dept → office, rank, dateHired
facName,office → dept, rank, dateHired

 NewFac is not BCNF because office is not a superkey

 To make it BCNF, remove the dependent attributes to a new
relation, with the determinant as the key
 Project into
Fac1 (office, dept)
Fac2 (facName, office, rank, dateHired)

Note we have lost a functional dependency in Fac2 – no longer

able to see that {facName, dept} is a determinant, since they
are in different relations
Multi-valued Dependency
 In R(A,B,C) if each A values has associated with
it a set of B values and a set of C values such
that the B and C values are independent of each
other, then A multi-determines B and A multi-
determines C
 Multi-valued dependencies occur in pairs
 Example: JointAppoint(facId, dept, committee)
assuming a faculty member can belong to more
than one department and belong to more than
one committee
 Table must list all combinations of values of
department and committee for each facId
Lossless Decomposition
 A decomposition of R into {R1, R2,....,Rn} is
lossless if the natural join of R1, R2,...,Rn
produces exactly the relation R
 No spurious tuples are created when the
projections are joined.
 always possible to find a BCNF decomposition
that is lossless
Example of Lossy Decomposition
Original EmpRoleProj table: tells what role(s) each employee plays in which project(s)
EmpName role projName
Smith designer Nile
Smith programmer Amazon
Smith designer Amazon
Jones designer Amazon
Project into two tables Table a(empName, role), Table b( role, projname)
Table a Table b
EmpName role role projName
Smith designer designer Nile
Smith programmer programmer Amazon
Jones designer designer Amazon
Joining Table a and Table b produces
EmpName role projName
Smith designer Nile
Smith designer Amazon
Smith programmer Amazon
Jones designer Nile  spurious tuple
Jones designer Amazon
Lossless Decomposition
 Lossless property guaranteed if for each pair of relations
that will be joined, the set of common attributes is a
superkey of one of the relations
 Binary decomposition of R into {R1,R2} lossless iff one of
these holds
R1 ∩ R2 → R1 - R2
or
R1 ∩ R2 → R2 - R1

 If projection is done by successive binary projections,

can apply binary decomposition test repeatedly
Algorithm to Test for Lossless Join
 Given a relation R(A1,A2,…An), a set of functional dependencies, F,
and a decomposition of R into Relations R1, R2, …Rm, to determine
whether the decomposition has a lossless join
 Construct an m by n table, S, with a column for each of the n attributes in
R and a row for each of the m relations in the decomposition
 For each cell S(I,j) of S,
 If the attribute for the column, Aj, is in the relation for the row, Ri, then place the
symbol a(j) in the cell else place the symbol b(I,j)there
 Repeat the following process until no more changes can be made
to Sc for each FD X  Y in F
 For all rows in S that have the same symbols in the columns corresponding to
the attributes of X, make the symbols for the columns that represent attributes
of Y equal by the following rule:
 If any row has an a value,. A(j), then set the value of that column in all the other rows equal to a(j)
 If no row ahs an a value, then pick any one of the b values, say b(I,j), and set all the other rows
equal to b(I,j)

 If, after all possible changes have been made to S, a row is made
up entirely of a symbols, a(1, a(2, …,a(n), then the join is lossless.
If there is no such row, the join is lossy.
Normalization Methods
 Analysis
 Decomposition method shown previously
 Synthesis
 Begin with attributes, combine them into groups
having the same determinant
 Use functional dependencies to develop a set of
normalized relations
 Mapping from ER diagram provides almost-
normalized schema
De-normalization
 When to stop the normalization process
 When applications require too many joins
 When you cannot get a non-loss decomposition that
preserves dependencies
Inference Rules for FDs
 Armstrong’s Axioms
 Reflexivity If B is a subset of A, then A → B..
 Augmentation If A → B, then AC → BC.
 Transitivity If A → B and B → C, then A → C
Additional rules that follow:
 Additivity If A → B and A → C, then A → BC
 Projectivity If A → BC, then A → B and A → C
 Pseudotransitivity If A → B and CB → D, then AC
→D
Closure of Set of FDs
 If F is a set of functional dependencies for a
relation R, then the set of all functional
dependencies that can be derived from F, F+, is
called the closure of F
 Could compute closure by applying Armstrong’s
Axioms repeatedly
Closure of an Attribute
 If A is an attribute or set of attributes of relation
R, all the attributes in R that are functionally
dependent on A in R form the closure of A, A+
 Computed by Closure Algorithm for A
 result ← A;
while (result changes) do
for each functional dependency B → C in F
if B is contained in result then result ← result  C;
end;
A+ ← result;
Uses of Attribute Closure
 Can determine if A is a superkey-if every
attribute in R functionally dependent on A
 Can determine whether a given FD X→Y is in
the closure of the set of FDs. (Find X+, see if it
includes Y)
Redundant FDs and Covers
 Given a set of FDs, can determine if any of them
is redundant, i.e. can be derived from the
remaining FDs, by a simple
 If a relation R has two sets of FDs, F and G
 then F is a cover for G if every FD in G is also in F+
 F and G are equivalent if F is a cover for G and G is a
cover for F (i.e. F+ = G+)
Minimal Set of FDs
 Set of FDs, F is minimal if
 The right side of every FD in F has a single attribute
(called standard or canonical form)
 No attribute in the left side of any FD is extraneous
 F has no redundant FDs
Minimal Cover for Set of FDs
 A minimal cover for a set of FDs is a cover such
that no proper subset of itself is also a cover
 A set of FDs may have several minimal covers
Synthesis Algorithm for 3NF
 Can always find 3NF decomposition that is
lossless and that preserves all FDs
 3NF Algorithm uses synthesis
 Begin with universal relation and set of FDs,G
 Find a minimal cover for G
 Combine FDs that have the same determinant
 Include a relation with a key of R
Basic Queries: SQL and RA
 To look at the data in tables, we use the
SELECT statement. The result of this statement
is always a new table that we can view with our
database client software or use with
programming languages to build dynamic web
pages or desktop applications.
 Although the result table is not stored in the
database we can also use it as part of other
SELECT statements.
Basic Queries: SQL and RA –
Required Clauses
Only the SELECT and FROM clauses are
required.

SELECT <attribute names>

FROM <table names>
WHERE <condition to pick rows>
ORDER BY <attribute names>;
Basic Queries: SQL and RA –
Retrieving Data Step 1
1. Look at all of the relevant data—this is called
the result set of the query, and it is specified in
the FROM clause. We have only one table, so
the result set should consist of all the columns
(* means all attributes) and rows of this table.

SELECT * FROM customers;

Basic Queries: SQL and RA –
Retrieving Data Step 2
2.Pick the specific rows you want from the result
set (for example here, all customers who live in
zip code 90840). Notice the single quotes
around the string you’re looking for—search
strings are case sensitive!
SELECT * FROM customers
WHERE cZipCode = '90840';
Basic Queries: SQL and RA –
Retrieving Data Step 3
3.Pick the attributes (columns) you want. Notice
that changing the order of the columns (like
showing the last name first) does not change
the meaning of the data.
SELECT cLastName, cFirstName, cPhone
FROM customers
WHERE cZipCode = '90840';
 Basic Queries: SQL and RA –
Retrieving Data Step 4
4. In SQL, you can also specify the order in which
to list the results. Once again, the order in
which rows are listed does not change the
meaning of the data in them.
SELECT cLastName,cFirstName,cPhone
FROM customers
WHERE cZipCode = '90840'
ORDER BY cLastName, cFirstName;
Basic queries: SQL and RA – Why
SQL Works
 Like all algebras, Relational Algebra (RA)
applies operators to operands to produce
results. RA operands are relations. Results are
new relations that can be used as operands in
building more complex expressions.
 select(RA) and project(RA) are two RA
operators that were used in the prior example
Basic queries: SQL and RA – Select
and Project Step 1
1. To represent a single relation in RA, we only
need to use its name. We can also represent
relations and schemes symbolically with small
and capital letters, for example relation r over
scheme R. In this case, r = customers and R =
the Customers scheme.
Basic queries: SQL and RA – Select
and Project Step 2
2. The select (RA) operator (written σ) picks tuples, like
the SQL WHERE clause picks rows. It is a unary
operator that takes a single relation or expression as its
operand. It also takes a predicate, θ, to specify which
tuples are required. Its syntax is σθr, or in our example:
σcZipCode='90840'customers.
The scheme of the result of σθr is R—the same
scheme we started with—since we haven’t done
anything to change the attribute list. The result of this
operation includes all tuples of r for which the predicate
θ evaluates to true.
Basic queries: SQL and RA – Select
and Project Step 3
3. The project (RA) operator (written π) picks attributes, confusingly like the
SQL SELECT clause. It is also a unary operator that takes a single relation
or expression as its operand. Instead of a predicate, it takes a subscheme,
X (of R), to specify which attributes are required. Its syntax is πXr, or in our
example:
πcLastName, cFirstName, cPhonecustomers.

The scheme of the result of πXr is X. The tuples resulting from this
operation are tuples of the original relation, r, cut down to the attributes
contained in X.
 For X to be a subscheme of R, it must be a subset of the attributes in R, and
preserve the assignment rule from R (that is, each attribute of X must have the
same domain as its corresponding attribute in R).
 If X is a super key of r, then there will be the same number of tuples in the result
as there were to begin with in r. If X is not a super key of r, then any duplicate
(non-distinct) tuples are eliminated from the result.
Just as in the SQL statement, we can apply the project operator to the
output of the select operation to produce the results that we want: πXσθr or
πcLastName, cFirstName, cPhone σcZipCode='90840'customers.
Basic queries: SQL and RA – Select
and Project Step 4
4. Since RA considers relations strictly as sets of
tuples, there is no way to specify the order of
tuples in a result relation.
Basic SQL Statements: DDL and DML
 SQL statements are divided into two major
categories:
 data definition language (DDL) - used to build and
modify the structure of your tables and other objects
in the database
 data manipulation language (DML) - used to work
with the data in tables
 All of the information about objects in your
schema is contained in a set of tables called the
data dictionary.
Basic SQL Statements: DDL and DML
– DDL- CREATE Statement
 The CREATE TABLE statement does exactly that:
CREATE TABLE <table name> (
<attribute name 1> <data type 1>,
...
<attribute name n> <data type n>);
 The data types that you will use most frequently are
character strings, which might be called VARCHAR or
CHAR for variable or fixed length strings; numeric types
such as NUMBER or INTEGER, which will usually
specify a precision; and DATE or related types.
 Data type syntax is variable from system to system; the
only way to be sure is to consult the documentation for
your own software.
Basic SQL Statements: DDL and DML
– DDL- ALTER TABLE Statement
 The ALTER TABLE statement may be used as you have seen to
specify primary and foreign key constraints, as well as to make other
modifications to the table structure. Key constraints may also be
specified in the CREATE TABLE statement.
ALTER TABLE <table name>
ADD CONSTRAINT <constraint name>
PRIMARY KEY (<attribute list>);
 You get to specify the constraint name. Get used to following a
convention of tablename_pk (for example, Customers_pk), so you
can remember what you did later.
 The attribute list contains the one or more attributes that form this
PK; if more than one, the names are separated by commas.
Basic SQL Statements: DDL and DML
– DDL- Foreign Key Constraint
 The FOREIGN KEY CONSTRAINT is a bit more complicated, since
we have to specify both the FK attributes in this (child) table, and the
PK attributes that they link to in the parent table.
ALTER TABLE <table name>
ADD CONSTRAINT <constraint name>
FOREIGN KEY (<attribute list>)
REFERENCES <parent table name> (<attribute list>);
 Name the constraint in the form childtable_parenttable_fk (for
example, Orders_Customers_fk). If there is more than one attribute
in the FK, all of them must be included (with commas between) in
both the FK attribute list and the REFERENCES (parent table)
attribute list.
 You need a separate foreign key definition for each relationship in
which this table is the child.
Basic SQL Statements: DDL and DML
– DDL- DROP statement
 If you totally mess things up and want to start over, you can always
get rid of any object you’ve created with a drop statement. The
syntax is different for tables and constraints.
DROP TABLE <table name>;

ALTER TABLE <table name>

DROP CONSTRAINT <constraint name>;
 This is where consistent constraint naming comes in handy, so you
can just remember the PK or FK name rather than remembering the
syntax for looking up the names in another table.
 The DROP TABLE statement gets rid of its own PK constraint, but
won’t work until you separately drop any FK constraints (or child
tables) that refer to this one. It also gets rid of all data that was
contained in the table—and it doesn't even ask you if you really want
to do this!
Basic SQL statements: DDL and DML
– DML
 When you are connected to most multi-user
databases (whether in a client program or by a
connection from a Web page script), you are in
effect working with a private copy of your tables
that can’t be seen by anyone else until you are
finished .
 The SELECT statement is considered to be part
of DML even though it just retrieves data rather
than modifying it.
Basic SQL Statements: DDL and DML
– DML – INSERT Statement
 The insert statement is used to add new rows to a table.
INSERT INTO <table name>
VALUES (<value 1>, ... <value n>);
 The comma-delimited list of values must match the table
structure exactly in the number of attributes and the data
type of each attribute.
 Character type values are always enclosed in single quotes
 Number values are never in quotes
 Date values are often (but not always) in the format 'yyyy-mm-dd'
(for example, '2006-11-30')
 You will need a separate INSERT statement for every
row.
Basic SQL Statements: DDL and DML
– DML – UPDATE Statement
 The update statement is used to change values that are already in a
table.
UPDATE <table name>
SET <attribute> = <expression>
WHERE <condition>;
 The update expression can be a constant, any computed value, or
even the result of a SELECT statement that returns a single row and
a single column.
 If the WHERE clause is omitted, then the specified attribute is set to
the same value in every row of the table (which is usually not what
you want to do).
 You can also set multiple attribute values at the same time with a
comma-delimited list of attribute=expression pairs.
Basic SQL Statements: DDL and DML
– DML – DELETE Statement
 The DELETE statement deletes rows in a table.
DELETE FROM <table name>
WHERE <condition>;
 If the WHERE clause is omitted, then every row
of the table is deleted!!!
Basic SQL Statements: DDL and DML
– DML – Transactions
 If you are using a large multi-user system, you may need
to make your DML changes visible to the rest of the
users of the database. Although this might be done
automatically when you log out, you could also just type:
COMMIT;
 If you need to back out your changes and want to restore
your private copy of the database to the way it was
before you started or since the last COMMIT just type:
ROLLBACK;
 Although single-user systems don’t support COMMIT
and ROLLBACK statements, they are used in large
systems to control transactions, which are sequences
of changes to the database.
Basic SQL Statements: DDL and DML
– Privileges
 If you want anyone else to be able to view or
manipulate the data in your tables, and if your
system permits this, you will have to explicitly
GRANT the appropriate privilege or privileges
(SELECT, INSERT, UPDATE, or DELETE) to them.
This has to be done for each table.
 The most common case where you would use
grants is for tables that you want to make available
to scripts running on a Web server, for example:
GRANT select, insert ON customers TO webuser;
Basic Query Operation: the Join
 In order to see data from two or more tables, the
tables must be joined.
 A join operation matches up the right
information from each table.
SELECT * FROM customers
NATURAL JOIN orders;
Basic Query Operation: the Join –
Natural Join
 The NATURAL JOIN keyword specifies that the
attributes are to be matched between the two tables is
those with matching names and matching data types.
These should be the PK/FK attributes. The join attributes
are shown only once in the result along with the
remaining attributes of both tables.
 Notice that all of the customer info is repeated for each
order that the customer has placed. This is expected
because of the one-to-many relationship between
Customers and Orders.
 Notice also that any customer who has not placed an
order is missing from the results. This is also expected
because there is no FK in the Orders table to match that
Customer’s PK in the Customers table.
Basic Query Operation: the Join –
How it Works
 The easiest way to understand the join is to think
of the database software looking one-by-one at
each pair of rows from the two tables.
 Go through each row of the Customers table and
see if it matches each of the rows in the Orders
table.
Basic Query Operation: the Join –
RA Syntax
 The RA join of two relations, r over scheme R and s over scheme S,
is written r s, or in our example, customers orders. The scheme of
the result, exactly as you have seen in the SQL syntax, is the union
of the two relation schemes, R S. The join attributes are found in
the intersection of the two schemes, R∩S. Clearly, the intersection
attributes must inherit the same assignment rule from R and S. This
makes the two schemes compatible.
 The result of the RA join consists of the pairwise paste of all tuples
from the two relations, written paste(t,u) for any tuple t from relation r
over scheme R and u from relation s over scheme S. The result of
the paste operation is exactly as explained in the preceding section.
Basic Query Operation: the Join –
Cross Join
 In the very, very rare case where there is no intersection
between schemes R and S (that is, R∩S = {null}), the
schemes are still compatible and every tuple from
relation r is pasted to every tuple from relation s, with all
of the attributes from both schemes contained in the
resulting tuples.
 In set theory, this is a Cartesian product of the two
relations; in practice, it is almost always nonsense and
not what you want. The Cartesian product can also be
written in RA as r × s, or intentionally specified in SQL
with the CROSS JOIN keyword.
Basic Query operation: the Join –
Paste Operation
SQL Technique: Multiple Joins and
the Distinct Keyword
 It is important to realize that if you have a properly
designed and linked database, you can retrieve
information from as many tables as you want, specify
retrieval conditions based on any data in the tables, and
show the results in any order that you like.
 Example: We’ll use the order entry model. We’d like a list
of all the products that have been purchased by a
specific customer.
π cLastName, cFirstName, prodName
σcFirstName='Alvaro' and cLastName='Monge‘
(customers orders orderlines
products)
SQL Technique: Multiple Joins and the
Distinct Keyword – Relation Scheme
SQL Technique: Multiple Joins and
the Distinct Keyword – Explained
 The needed information is found in the Products table
(“output” from the query). The retrieval condition or
“input” to the query is based on the Customers tables.
These attributes will be needed for the WHERE clause.
They are only included in the SELECT list to be sure that
the query is showing the data that you want.
 You also need to include the intervening tables in the
FROM clause of the query since this is the only way to
correctly associate the Customers data with the Products
data. They can’t be joined directly because they don’t
have any common attributes.
 Another way to think about this is to simply follow the
PK-FK pairs from table to table until you have completely
linked all of the info you need.
SQL Technique: Multiple Joins and
the Distinct Keyword – Step 1
1. Look at the result set (all of the linked data).
SELECT * FROM customers
NATURAL JOIN orders
NATURAL JOIN orderlines
NATURAL JOIN products;
 Your database system might not support the NATURAL
JOIN syntax that we show here.
 The multiple natural joins in our example work correctly
because there are no non-pk/fk attributes in any of our
tables that have the same name. In larger, more
complicated databases, this might not be true.
SQL Technique: Multiple Joins and
the Distinct Keyword – Step 2
2. Pick the rows you want, and be sure that all of
the information makes sense and is really what
you are looking for.
SELECT * FROM customers
NATURAL JOIN orders
NATURAL JOIN orderlines
NATURAL JOIN products
WHERE cFirstName = 'Alvaro' AND
cLastName = 'Monge';
SQL Technique: Multiple Joins and
the Distinct Keyword – Step 3
3. Now pick the columns that you want, and again check
the results. Notice that we are including the retrieval
condition attributes in the SELECT clause, to be sure
that this really is the right answer.
SELECT cFirstName, cLastName, prodName
FROM customers
NATURAL JOIN orders
NATURAL JOIN orderlines
NATURAL JOIN products
WHERE cFirstName = 'Alvaro' AND
cLastName = 'Monge';
SQL Technique: Multiple Joins and
the Distinct Keyword – Results
SQL Technique: Multiple Joins and the
Distinct Keyword – Distinct keyword
 Notice that there are duplicate rows in the
result set. Why?
 The DISTINCT keyword will remove the
duplicate rows
SELECT DISTINCT cFirstName, cLastName, prodName
FROM customers
NATURAL JOIN orders
NATURAL JOIN orderlines
NATURAL JOIN products
WHERE cFirstName = 'Alvaro' AND cLastName = 'Monge‘
ORDER BY prodName;
SQL Technique: Join Types –
Natural Join
 Remember that the NATURAL JOIN is the intersection of
the tables, however, if there are any non-PK/FK attributes
that have the same name, they will also be joined. This is
probably not what you want.
 It also produces only one copy of those attributes in the
result table.
SELECT cFirstName,cLastName,orderDate
FROM customers
NATURAL JOIN orders;
r s
 SQL Technique: Join Types – Inner
Join Using
 The INNER JOIN .. USING specifies the columns to
join.
 It also produces only one copy of the join attributes
in the result set.
SELECT cFirstName,cLastName,orderDate
FROM customers
INNER JOIN orders USING (custID);
r a,b s
 SQL Technique: Join Types – Inner
Join On
 The INNER JOIN .. ON specifies the columns and
the join condition (normally equality).
 It also requires the join attributes to be prefaced with
the table name since both columns will be included
in the result set.
SELECT cFirstName,cLastName,orderDate
FROM customers
INNER JOIN orders
ON customers.custID = orders.custID;
r a=b s
 SQL Technique: Join Types – Inner
Join – Alias
 You can specify an alias for each table name (such
as c and o in this example), then using the alias
instead of the full name when you refer to the
attributes.
 This is the only syntax that will let you join a table to
itself.
SELECT cFirstName,cLastName,orderDate
FROM customers c
INNER JOIN orders o
ON c.custID = o.custID;
 SQL Technique: Join Types – Outer
Join
 One important effect of all natural and inner joins is
that any unmatched PK value simply drops out of the
result. In our example, this means that any customer
who didn’t place an order isn’t shown. Suppose that
we want a list of all customers, along with order
date(s) for those who did place orders. To include
the customers who did not place orders, we will use
an OUTER JOIN.
 An OUTER JOIN allows unmatched rows to be part
of the result set. Undefines values are NULL.
SQL Technique: Join Types – Left
Outer Join
SELECT cFirstName, cLastName, orderDate
FROM customers c
LEFT OUTER JOIN orders o
ON c.custID = o.custID;
r= s
 SQL Technique: Join Types – Right
Outer Join
 The word “left” refers to the order of the tables in the FROM clause (customers
on the left, orders on the right). The left table here is the one that might have
unmatched join attributes—the one from which we want all rows. We could have
gotten exactly the same results if the table names and outer join direction were
reversed:
SELECT cFirstName, cLastName, orderDate
FROM orders o
RIGHT OUTER JOIN customers c
ON o.custID = c.custID; r = s
 An outer join makes sense only if one side of the relationship has a minimum
cardinality of zero (as Orders does in this example). Otherwise, the outer join will
produce exactly the same result as an inner join (for example, between Orders
and OrderLines).
 The SQL standard also allows a FULL OUTER JOIN, in which unmatched join
attributes from either side are paired with null values on the other side. You will
probably not have to use this with most well-designed databases.
r= =s
 SQL Technique: Join Types –
Evaluation Order
 Multiple joins in a query are evaluated left-to-right in the order that you write
them, unless you use parentheses to force a different evaluation order. The
schemes of the joins are also cumulative in the order that they are evaluated; in
RA, this means that
r1 r2 r3 = (r1 r2) r3
 It is especially important to remember this rule when outer joins are mixed with
other joins in a query. For example, if you write:
SELECT cFirstName, cLastName, orderDate, UPC, quantity FROM
customers
LEFT OUTER JOIN orders USING (custID)
NATURAL JOIN orderlines;
you will lose the customers who haven’t placed orders. They will be retained if
you force the second join to be executed first:
SELECT cFirstName, cLastName, orderDate, UPC, quantity
FROM customers
LEFT OUTER JOIN (orders NATURAL JOIN orderlines)
USING (custID);
 SQL Technique: Join Types – Other
Join Types
 If you try to join two tables with no join condition, the result will be that
every row from one side is paired with every row from the other side. It is
easy to do this accidently, by forgetting to put the join condition in the
WHERE clause.
 If you ever have an occasion to really need a Cartesian product of two
tables, use a CROSS JOIN:
SELECT cFirstName, cLastName, orderDate
FROM customers
CROSS JOIN orders;
 It is possible, but confusing, to specify a join condition other than equality
of two attributes; this is called a non-equi-join. If you see such a thing in
older code, it probably represents a WHERE clause or subquery in
disguise.
 You may also hear the term self join, which is nothing but an inner or
outer join between two attributes in the same table.
SQL Technique: Functions
 Sometimes, the information that we need is not
actually stored in the database, but has to be
computed in some way from the stored data.
 In our order entry example, there are two
derived attributes (/subtotal in OrderLines and
/total in Orders) that are part of the class
diagram but not part of the relation scheme. We
can compute these by using SQL functions in
the SELECT statement.
SQL Technique: Functions –
Computed Columns – How To
 We can compute values from information that is
in a table simply by showing the computation in
the SELECT clause. Each computation creates
a new column in the output table, just as if it
were a named attribute.
 Example: We want to find the subtotal for each
line of the OrderLines table.
SELECT custID, orderDate, UPC,
unitSalePrice * quantity
FROM orderlines;
SQL Technique: Functions –
Computed Columns - Result
Notice that the computation itself is shown as the
heading for the computed column. This is
awkward to read, and doesn’t really tell us what
the column means.
SQL Technique: Functions – As
Keyword
We can create our own column heading or alias
using the AS keyword. If your want your column
alias to have spaces in it, you will have to
enclose it in double quote marks.
SELECT custID,orderDate,UPC,
unitSalePrice * quantity AS subtotal
FROM orderlines;
SQL Technique: Functions –
Aggregate Functions
 SQL aggregate functions let us compute values based
on multiple rows in our tables. They are also used as
part of the SELECT clause, and also create new
columns in the output.
 Example: First, let’s just find the total amount of all our
sales. To compute this, all we need is to do is to add up
all of the price-times-quantity computations from every
line of the OrderLines. We will use the SUM function to
do the calculation.
SELECT SUM(unitSalePrice * quantity) AS
totalsales
FROM orderlines;
SQL Technique: Functions –
Aggregate Functions – Group By
 Next, we’ll compute the total for each order. We still need to add up
order lines, but we need to group the totals for each order. We can
do this with the GROUP BY clause.
 This time, the output will contain one row for every order, since the
customerID and orderDate form the PK for Orders, not OrderLines.
 Notice that the SELECT clause and the GROUP BY clause contain
exactly the same list of attributes, except for the calculation. This is
a must!!!!!
SELECT custID, orderDate,
SUM(unitSalePrice * quantity) AS total
FROM orderlines
GROUP BY custID, orderDate;
SQL Technique: Functions – Aggregate
Functions – Common Functions
 Other frequently-used functions that work the
same way as SUM include MIN, MAX, and AVG.
 The COUNT function is slightly different, since it
returns the number of rows in a grouping. To
count all rows, we can use the * .
SELECT COUNT(*) FROM orders;
SQL Technique: Functions –
Aggregate Functions – Count
 We can also count groups of rows with identical
values in a column. In this case, COUNT will
ignore NULL values in the column.
 Here, we’ll find out how many times each
product has been ordered.
SELECT prodname AS "product name", COUNT(prodname)
AS "times ordered"
FROM products
NATURAL JOIN orderlines
GROUP BY prodname;
SQL Technique: Functions –
Aggregate Functions – Having
 If we want to select output rows based on the results of
the group function, the HAVING clause is used instead.
 For example, we could ask for only those products that
have been sold more than once:
SELECT prodname AS "product name",
COUNT(prodname) AS "times ordered"
FROM products
NATURAL JOIN orderlines
GROUP BY prodname
HAVING COUNT(prodname) > 1;
SQL Technique: Functions – Aggregate
Functions – Other Functions
 Most database systems offer a wide variety of functions that deal
with formatting and other miscellaneous tasks. These functions tend
to be proprietary, differing widely from system to system in both
availability and syntax.
 Most are used in the SELECT clause, although some might appear
in a WHERE clause expression or an INSERT or UPDATE
statement. Typical functions include:
 Rounding, truncating, converting, and formatting numeric data types.
 Concatenating, altering case, and manipulating character data types.
 Formatting dates and times, or retrieving the date and time from the
operating system.
 Converting data types such as date or numeric to character string, and
vice-versa.
 Supplying visible values to null attributes, allowing conditional output,
and other miscellaneous tasks.
SQL Technique: Subqueries
 Sometimes you don’t have enough information
available when you design a query to determine
which rows you want. In this case you’ll have to
find the required information with a subquery.
 Example: Find the name of customers who live
in the same zipcode as Wayne Dick.
 Problem: Putting the zipcode in the query
without knowing what it is
SQL Technique: Subqueries –
Finding the Unknown
 First, we to find the right zip code by writing another
query:
SELECT cZipCode
FROM Customers
WHERE cFirstName = 'Wayne' AND cLastName = 'Dick';
 Since this query returns a single column and a single
row. We can use the result as the condition value for
cZipCode in our original query. In effect, the output of the
second query becomes input to the first one.
SQL Technique: Subqueries –
Finding the Unknown
 Syntactically, all we have to do is to enclose the
subquery in parentheses, in the same place where we
would normally use a constant in the WHERE clause.
 We’ll include the zip code in the SELECT line to verify
that the answer is what we want:
SELECT cFirstName, cLastName, cZipCode
FROM customers
WHERE cZipCode =
(SELECT cZipCode FROM customers
WHERE cFirstName = 'Wayne' AND
cLastName = 'Dick');
SQL Technique: Subqueries –
Another Example
 A subquery that returns only one column and one row
can be used any time that we need a single value.
 Subqueries can also be used when we need more than
a single value as part of a larger query.
 Another example would be to find the product name and
sale price of all products whose unit sale price is greater
than the average of all products. The DISTINCT
keyword is needed, since the SELECT attributes are not
a super key of the result set:
SELECT DISTINCT prodName, unitSalePrice
FROM Products NATURAL JOIN OrderLines
WHERE unitSalePrice >
(SELECT AVG(unitSalePrice) FROM
OrderLines);
SQL Technique: Subqueries –
Relation Scheme
SQL Technique: Union and Minus -
Set Operations on Tables
 Union includes members of both sets with no duplicates,
minus includes only those members of the set on the left
side of the expression that are not contained in the set on
the right side of the expression.
 Both sets have to contain objects of the same type. SQL
and RA set operations treat tables as sets of rows.
Therefore both tables must have the same number of
attributes of the same data type.
SQL Technique: Union and Minus -
Union
 Example: add a suppliers table to the order entry model.
Produce a listing that shows the names and phone
numbers of all people we deal with, whether they are
customers or suppliers.
 We need rows from both tables, but they have to have the
same attribute list.
SQL Technique: Union and Minus –
Union – Building the Query
 We can create an extra column in the query output for the Customers
table by simply giving it a name and filling it with a constant value.
Here, we’ll use the value 'Customer' to distinguish these rows from
supplier representatives. SQL uses the column names of the first part
of the union query as the column names for the output, so we will give
each of them aliases that are appropriate for the entire set of data.
 Build and test each component of the union query individually, then
put them together. The ORDER BY clause has to come at the end.
SELECT cLastName AS "Last Name", cFirstName AS
"First Name", cPhone as "Phone", 'Customer' AS
"Company"
FROM customers
UNION
SELECT repLName, repFName, repPhone, sCompanyName
FROM suppliers
ORDER BY "Last Name";
SQL Technique: Union and Minus –
Union – Result
SQL Technique: Union and Minus –
Union – Minus
 Sometimes you have to think about both what you do
want and what you don’t want in the results of a query. If
there is a WHERE clause predicate that completely
partitions all rows of interest into those you want and
those you don’t want, then you have a simple query with
a test for inequality.
 The multiplicity of an association can help you determine
how to build the query. Since each product has one and
only one supplier, we can partition the Products table
into those that are supplied by a given company and
those that are not.
SQL Technique: Union and Minus –
Union – Simple Inequality
 Sometimes you have to think about both what you do want and what
you don’t want in the results of a query. If there is a WHERE clause
predicate that completely partitions all rows of interest into those you
want and those you don’t want, then you have a simple query with a
test for inequality.
 The multiplicity of an association can help you determine how to
build the query. Since each product has one and only one supplier,
we can partition the Products table into those that are supplied by a
given company and those that are not.
SELECT prodName, sCompanyName
FROM Products NATURAL JOIN Suppliers
WHERE sCompanyName <> 'Industrial Tool Supply';
SQL Technique: Union and Minus –
Union – Complications
Contrast this to finding customers who did not make
purchases in 2002. Because of the optional one-to-
many association between Customers and Orders,
there are actually four possibilities:
1. A customer made purchases in 2002 (only).
2. A customer made purchases in other years, but not in
2002.
3. A customer made purchases both in other years and in
2002.
4. A customer made no purchases in any year.
SQL Technique: Union and Minus –
Union – Incorrect Solution
 If you try to write this as a simple test for inequality,
SELECT DISTINCT cLastName, cFirstName,
cStreet, cZipCode
FROM Customers NATURAL JOIN Orders
WHERE TO_CHAR(orderDate, 'YYYY') <>
'2002';
 You will correctly exclude group 1 and include group 2,
but falsely include group 3 and falsely exclude group 4.
 We can show in set notation what we need to do:
{customers who did not make purchases in
2002}
= {all customers} − {those who did}
SQL Technique: Union and Minus –
Union – Correct Solution 1
The easiest syntax in this case is to compare only the
customer IDs. We’ll use the NOT IN set operator in the
WHERE clause, along with a subquery to find the
customer ID of those who did made purchases in 2002.
SELECT cLastName, cFirstName, cStreet,
cZipCode
FROM Customers WHERE custID NOT IN
(SELECT custID FROM Orders
WHERE TO_CHAR(orderDate, 'YYYY') =
'2002');
SQL Technique: Union and Minus –
Union – Correct Solution 2
We can also use the MINUS operator to subtract rows we
don’t want from all rows in Customers. (Some versions of
SQL use the keyword EXCEPT instead of MINUS.) Like
the UNION, this requires the schemes of the two tables to
match exactly in number and type of attributes.
SELECT cLastName, cFirstName, cStreet,
cZipCode
FROM Customers
MINUS
SELECT cLastName, cFirstName, cStreet,
cZipCode
FROM Customers NATURAL JOIN Orders
WHERE TO_CHAR(orderDate, 'YYYY') = '2002';
SQL Technique: Union and Minus –
Union – Other Set Operations
SQL has two additional set operators:
 UNION ALL works like UNION, except it keeps
duplicate rows in the result.
 INTERSECT operates just like you would expect from
set theory.
SQL Technique: Views and Indexes
 A view is simply any SELECT query that has been given
a name and saved in the database.
 A view is also called a named query or a stored query.
CREATE OR REPLACE VIEW <view_name> AS
SELECT <any valid select query>;
 The view query itself is saved in the database, but it is
not actually run until it is called with another SELECT
statement. For this reason, the view does not take up
any disk space for data storage, and it does not create
any redundant copies of data that is already stored in the
tables that it references (which are sometimes called the
base tables of the view).
SQL Technique: Views and Indexes
- Views
 Although it is not required, many database developers
identify views with names such as v_Customers or
Customers_view. This not only avoids name conflicts
with base tables, it helps in reading any query that uses
a view.
 The keywords OR REPLACE in the syntax shown above
are optional. Although you don’t need to use them the
first time that you create a view, including them will
overwrite an older version of the view with your latest
one, without giving you an error message.
 The syntax to remove a view from your schema is
exactly what you would expect:
DROP VIEW <view_name>;
SQL Technique: Views and Indexes
– Using Views
 A view name may be used in exactly the same way as a table name
in any SELECT query. Once stored, the view can be used again and
again, rather than re-writing the same query many times.
 The most basic use of a view would be to simply SELECT * from it,
but it also might represent a pre-written subquery or a simplified way
to write part of a FROM clause.
 In many systems, views are stored in a pre-compiled form. This
might save some execution time for the query, but usually not
enough for a human user to notice.
 One of the most important uses of views is in large multi-user
systems, where they make it easy to control access to data for
different types of users. As a very simple example, suppose that you
have a table of employee information on the scheme
Employees = {employeeID, empFName, empLName, empPhone,
jobTitle, payRate, managerID}
 Obviously, you can’t let everyone in the company look at all of this
information, let alone make changes to it.
SQL Technique: Views and Indexes
– Roles
 Your database administrator (DBA) can define roles to
represent different groups of users, and then grant
membership in one or more roles to any specific user
account (schema). In turn, you can grant table-level or
view-level permissions to a role as well as to a specific
user. Suppose that the DBA has created the roles
managers and payroll for people who occupy those
positions.
 In Oracle®, there is also a pre-defined role named
public, which means every user of the database.
 You could create separate views even on just the
Employees table, and control access to them.
SQL Technique: Views and Indexes
– SQL
CREATE VIEW phone_view AS
SELECT empFName, empLName, empPhone
FROM Employees;
GRANT SELECT ON phone_view TO public;
CREATE VIEW job_view AS
SELECT employeeID, empFName, empLName,
jobTitle, managerID
FROM Employees;
GRANT SELECT, UPDATE ON job_view TO managers;
CREATE VIEW pay_view AS
SELECT employeeID, empFName, empLName, payRate
FROM Employees;
GRANT SELECT, UPDATE ON pay_view TO payroll;
SQL Technique: Views and Indexes
– Privileges
 Only a very few trusted people would have SELECT,
UPDATE, INSERT, and DELETE privileges on the entire
Employees base table; everyone else would now have
exactly the access that they need, but no more.
 When a view is the target of an UPDATE statement, the
base table value is changed. You can’t change a
computed value in a view, or any value in a view that is
based on a UNION query.
 You may also use a view as the target of an INSERT or
DELETE statement, subject to any integrity constraints
that have been placed on the base tables.
SQL Technique: Views and Indexes
– Materialized Views
 Sometimes, the execution speed of a query is so
important that a developer is willing to trade increased
disk space use for faster response, by creating a
materialized view. A materialized view does create and
store the result table in advance, filled with data. The
scheme of this table is given by the SELECT clause of
the view definition.
 This technique is most useful when the query involves
many joins of large tables, or any other SQL feature that
could contribute to long execution times.
 Since the view would be useless if it is out of date, it
must be re-run, at the minimum, when there is a change
to any of the tables that it is based on.
SQL Technique: Views and Indexes
– Indexes
 An index is a data structure that the database
uses to find records within a table more quickly.
 Indexes are built on one or more columns of a
table. Each index maintains a list of values
within that field that are sorted in ascending or
descending order.
 Rather than sorting records on the field or fields
during query execution, the system can simply
access the rows in order of the index.
SQL Technique: Views and Indexes –
Indexes - Unique and Non-Unique
 When you create an index, you may allow the indexed
columns to contain duplicate values. The index will still
list all of the rows with duplicates.
 You may also specify that values in the indexed columns
must be unique, just as they must be with a primary key.
In fact, when you create a primary key constraint on a
table, Oracle and most other systems will automatically
create a unique index on the primary key columns, as
well as not allowing null values in those columns.
 One good reason for you to create a unique index on
non-primary key fields is to enforce the integrity of a
candidate key, which otherwise might end up having
duplicate values in different rows.
SQL Technique: Views and
Indexes – Queries/Insert/Update
 You should not create an index on every column
or group of columns that will ever by used in an
ORDER BY clause.
 Each index will have to be updated every time
that a row is inserted or a value in that column is
updated. Although index structures allow this to
happen very quickly, there still might be
circumstances where too many indexes would
detract from overall system performance.
SQL Technique: Views and
Indexes – SQL
CREATE INDEX <indexname> ON <tablename>
(<column>, <column>...);
 To enforce unique values, add the UNIQUE
keyword:
CREATE UNIQUE INDEX <indexname> ON
<tablename> (<column>, <column>...);
 To specify sort order, add the keyword ASC or
DESC after each column name, just as you
would do in an ORDER BY clause.
 To remove an index, simply enter:
DROP INDEX <indexname>;
SQL Technique: Check
Constraints – What are they
 A check constraint can be used to specify a wide
range of rules for the contents of a table. A
search condition (which is a boolean expression)
is specified for a check constraint.
 This search condition must be satisfied for all
rows in the table.
 The search condition is applied to each row that
is modified on an INSERT or UPDATE at the
time of the row modification.
 The entire statement is aborted if any check
constraint is violated.
SQL Technique: Check
Constraints – Column vs. Table
 If a check constraint is specified as part of a
column-definition, a column reference can only
be made to the same column.
 Check constraints specified as part of a table
definition can have column references
identifying columns previously defined in the
CREATE TABLE statement.
SQL Technique: Check
Constraints – Search Condition
 The search condition must always return the
same value if applied to the same values. Thus,
it cannot contain any of the following:
 Dynamic parameters (?)
 Date/Time Functions (CURRENT_DATE,
CURRENT_TIME, CURRENT_TIMESTAMP)
 Subqueries
 User Functions (such as USER,
SESSION_USER, CURRENT_USER)
SQL Technique: Check
Constraints – SQL
 -- Use a column-level constraint for an arithmetic check
 -- Use a table-level constraint to make sure that an
employee's taxes does not exceed the bonus
CREATE TABLE SAMP.EMP
( EMPNO CHAR(6) NOT NULL CONSTRAINT EMP_PK PRIMARY KEY,
FIRSTNME CHAR(12) NOT NULL,
MIDINIT VARCHAR(12) NOT NULL,
LASTNAME VARCHAR(15) NOT NULL,
SALARY DECIMAL(9,2)
CONSTRAINT SAL_CK CHECK (SALARY >= 10000),
BONUS DECIMAL(9,2),
TAX DECIMAL(9,2),
CONSTRAINT BONUS_CK CHECK (BONUS > TAX)
);
SQL Technique: Check
Constraints – SQL
 -- Use a check constraint to allow only
appropriate abbreviations for the meals
CREATE TABLE FLIGHTS
(
FLIGHT_ID CHAR(6) NOT NULL ,
SEGMENT_NUMBER INTEGER NOT NULL ,
ORIG_AIRPORT CHAR(3),
DEPART_TIME TIME,
DEST_AIRPORT CHAR(3),
ARRIVE_TIME TIME,
MEAL CHAR(1) CONSTRAINT MEAL_CONSTRAINT
CHECK (MEAL IN ('B', 'L', 'D', 'S')),
PRIMARY KEY (FLIGHT_ID, SEGMENT_NUMBER)
);
Transactions –
Why Do We Need Transactions?
 Many enterprises use databases to store
information about their state
 e.g., Balances of all depositors at a bank

 When an event occurs in the real world that

changes the state of the enterprise, a program is
executed to change the database state in a
corresponding way
 e.g., Bank balance must be updated when deposit is
made

262
Transactions - Concurrency
 The goal in a ‘concurrent’ DBMS is to allow multiple
users to access the database simultaneously without
interfering with each other.
 A problem with multiple users using the DBMS is that it
may be possible for two users to try and change data in
the database simultaneously. If this type of action is not
carefully controlled, inconsistencies are possible.
 To control data access, we first need a concept to allow
us to encapsulate database accesses. Such
encapsulation is called a ‘Transaction’.
Transactions - What is a Transaction?

 A sequence of many actions which are

considered to be one atomic unit of work.
 Basic operations a transaction can include are:
 Reads, Writes
 Commits, Rollbacks
Transactions –
What Does a Transaction Do?
 Return information from the database
 RequestBalance transaction: Read customer’s
balance in database and output it
 Update the database to reflect the occurrence
of a real world event
 Deposit transaction: Update customer’s balance in
database
 Cause the occurrence of a real world event
 Withdraw transaction: Dispense cash (and update
customer’s balance in database)
265
Transactions - Outcomes
 After work is performed in a transaction, two
outcomes are possible:
 Commit - Any changes made during the transaction
by this transaction are committed to the database.
 Abort - All the changes made during the transaction
by this transaction are not made to the database. The
result of this is as if the transaction was never started.
Transactions - Commit and Abort
 If the transaction successfully completes it is
said to commit
 The system is responsible for ensuring that all
changes to the database have been saved

 If the transaction does not successfully

complete, it is said to abort
 The system is responsible for undoing, or rolling
back, all changes the transaction has made

267
Transactions - Reasons for Abort
 System crash
 Transaction aborted by system
 Execution cannot be made atomic (a site is down)
 Execution did not maintain database consistency
(integrity constraint is violated)
 Execution was not isolated
 Resources not available (deadlock)

 Transaction requests to roll back

268
Transactions – Problem 1
Ex. Reserving a seat for a flight --
If concurrent access is allowed to data in a DBMS, two users
may try to book the same seat simultaneously

Agent 1 finds
time seat 35G empty
Agent 2 finds
seat 35G empty
Agent 1 sets
seat 35G occupied

Agent 2 sets
seat 35G occupied
Transactions - Schedules
 A transaction schedule is a tabular representation of
how a set of transactions were executed over time. This
is useful when examining problem scenarios. Within the
diagrams various nomenclatures are used:
 READ(a) - This is a read action on an attribute or data item
called ‘a’.
 WRITE(a) - This is a write action on an attribute or data item
called ‘a’.
 WRITE(a[x]) - This is a write action on an attribute or data item
called ‘a’, where the value ‘x’ is written into ‘a’.
 tn (e.g. t1,t2,t10) - This indicates the time at which something
occurred. The units are not important, but tn always occurs
before tn+1.
Transactions – Problem 2
 Problems can occur when concurrent transactions execute in an
uncontrolled manner.
 Examples of one problem.
 A original equals 100, after executing T1 and T2, A is supposed to
be 100+10-8=102 but A is 92

Add 10 To A Minus 8 from A Value of A on

T1 T2 the disk
Read(A) 100

A=A+10 100

Read(A) 100
A=A-8 100
Write(A) 110
Write(A) 92
Transactions – Problem 3
 Consider transaction A, which loads in a bank
account balance X (initially $20) and adds $10 to it.
Such a schedule would look like this:

Time Transaction
t1 TOTAL:=READ(X)
t2 TOTAL:=TOTAL+10
t3 WRITE(X[30])
Transactions – Problem 3
 Now consider that, at the same time as trans A runs, trans B runs.
 Transaction B gives all accounts a 10% increase. Will X be 32 or
33?
Time Transaction A Transaction B
t1 BALANCE:=READ(X)

t2 TOTAL:=READ(X)

t3 TOTAL:=TOTAL+10
t4 WRITE(X[30])
t5 BONUS:=BALANCE*110%
t6 WRITE(X[22])

 Woops… X is 22! Depending on the interleaving, X can also be 32,

33, or 30.
Transactions –
Lost Update Scenario
Time Transaction A Transaction B

t1 READ(R)

t2 READ(R)

t3 WRITE(R)

t4 WRITE(R)

Transaction A’s update is lost at t4, because

Transaction B overwrites it. B missed A’s update
at t4 as it got the value of R at t2.
Transactions –
Uncommitted Dependency
Time Transaction A Transaction B

t1 WRITE(R)

t2 READ(R)

t3 ABORT

Transaction A is allowed to READ (or WRITE)

item R which has been updated by another
transaction but not committed (and in this case
ABORTed).
Transactions –
Inconsistency Scenario
TIME X Y Z TRANSACTION A TRASACTION B
ACTION SUM
t1 40 50 30 SUM:=READ(X) 40
t2 40 50 30 SUM+=READ(Y) 90

t3 40 50 30 READ(Z)
t4 40 50 20 WRITE(Z[20])
t5 40 50 20 READ(X)
t6 50 50 20 WRITE(X[50])
t7 50 50 20 COMMIT
t8 50 50 20 SUM+=READ(Z) 110

SUM should have been 120

Transactions - Requirements

 The execution of each transaction must maintain the

relationship between the database state and the
enterprise state
 Therefore additional requirements are placed on the
execution of transactions beyond those placed on
ordinary programs:
 Atomicity
 Consistency
ACID properties
 Isolation
 Durability
277
Transactions-ACID Properties of
Transactions
 Atomicity: Transaction is either performed in its
entirety or not performed at all.
 Consistency: Transaction must take the database
from one consistent state to another.
 Isolation: Transaction should appear as though it is
being executed in isolation from other transactions.
 Durability: Changes applied to the database by a
committed transaction must persist, even if the system
fails before all changes reflected on disk.
Transactions - Atomicity
 A real-world event either happens or does not
happen
 Student either registers or does not register

 Similarly, the system must ensure that either the

corresponding transaction runs to completion or,
if not, it has no effect at all
 Not true of ordinary programs. A crash could leave
files partially updated on recovery

279
Transactions – Atomicity (cont.)
 Partial effects of a transaction must be undone
when
 User explicitly aborts the transaction using
ROLLBACK
 Application asks for user confirmation in the last step and
issues COMMIT or ROLLBACK depending on the response
 An error, exception, or constraint violation occurs
during a transaction
 The DBMS crashes before a transaction commits
 How is atomicity achieved?
 Logging
Transactions - Isolation
 Serial Execution: transactions execute in sequence
 Each one starts after the previous one completes.
 Execution of one transaction is not affected by the
operations of another since they do not overlap in time
 The execution of each transaction is isolated from all
others.
 If the initial database state and all transactions are
consistent, then the final database state will be
consistent and will accurately reflect the real-world
state, but
 Serial execution is inadequate from a performance
perspective
281
 Transactions – Isolation (cont.)

 Concurrent execution offers performance benefits:

 A computer system has multiple resources capable of
executing independently (e.g., cpu’s, I/O devices), but
 A transaction typically uses only one resource at a time
 Hence, only concurrently executing transactions can make
effective use of the system
 Concurrently executing transactions yield interleaved
schedules

282
Transactions – Isolation (cont.)
 Transactions must appear to be executed in a serial
schedule (with no interleaving operations)
 For performance, DBMS executes transactions using a
serializable schedule
 In this schedule, operations from different transactions can
interleave and execute concurrently
 But the schedule is guaranteed to produce the same effects as a
serial schedule
 How is isolation achieved?
 Locking, multi-version concurrency control (method commonly
used to provide concurrent access to the database)
Transactions – Database Consistency
 Enterprise (Business) Rules limit the occurrence of
certain real-world events
 Student cannot register for a course if the current
number of registrants equals the maximum allowed
 Correspondingly, allowable database states are
restricted
cur_reg <= max_reg
 These limitations are called (static) integrity
constraints: assertions that must be satisfied by all
database states
284
Transactions – Transaction Consistency
 A consistent database state does not necessarily model
the actual state of the enterprise
 A deposit transaction that increments the balance by the
wrong amount maintains the integrity constraint balance  0,
but does not maintain the relation between the enterprise
and database states
 A consistent transaction maintains database consistency
and the correspondence between the database state and
the enterprise state (implements its specification)
 Specification of deposit transaction includes
balance = balance + amt_deposit ,
(balance is the next value of balance)
285
Transactions - Consistency
 Consistency of the database is guaranteed by
constraints and triggers declared in the
database and/or transactions themselves
 When inconsistency arises, abort the transaction or
fix the inconsistency within the transaction
Transactions - Durability

 The system must ensure that once a transaction

commits, its effect on the database state is not
lost in spite of subsequent failures
 Not true of ordinary programs. A media failure after a
program successfully terminates could cause the file
system to be restored to a state that preceded the
program’s execution

287
Transactions – Durability (cont.)
 Effects of committed transactions must survive
DBMS crashes
 How is durability achieved?
 DBMS manipulates data in memory; forcing all
changes to disk at the end of every transaction is very
expensive
 Logging
Transactions – Implementing Durability
 Database stored redundantly on mass storage
devices to protect against media failure
 Architecture of mass storage devices affects type
of media failures that can be tolerated
 Related to Availability: extent to which a (possibly
distributed) system can provide service despite
failure
 Non-stop DBMS (mirrored disks)
 Recovery based DBMS (log)

289
Transactions – Isolation Levels
 Strongest isolation level: SERIALIZABLE
 Complete isolation
 SQL default
 Weaker isolation levels: REPEATABLE READ,
READ COMMITTED, READ UNCOMMITTED
 Increase performance by eliminating overhead and
allowing higher degrees of concurrency
 Trade-off: sometimes you get the wrong answer
Transactions – Example Schema
CREATE TABLE Account
(accno INTEGER NOT NULL PRIMARY KEY,
name CHAR(30) NOT NULL,
balance FLOAT NOT NULL
CHECK(balance >= 0));
Transactions – Read Uncommitted
 Can read dirty data
 A data item is dirty if it is written by an uncommitted
transaction
 Problem: What if the transaction that wrote the dirty data
eventually aborts?
 Example: wrong average
-- T1: -- T2:
UPDATE Account
SET balance = balance - 200
WHERE accno = 142857; SELECT AVG(balance)
FROM Account;
ROLLBACK;
COMMIT;
Transactions – Read Committed
 No dirty reads, but non-repeatable reads possible
 Reading the same data item twice can produce different results
 Example: different averages
-- T1: -- T2:
SELECT AVG(balance)
FROM Account;
UPDATE Account
SET balance = balance - 200
WHERE accno = 142857;
COMMIT;
SELECT AVG(balance)
FROM Account;
COMMIT;
Transactions – Repeatable Read
 Reads are repeatable, but may see phantoms
 A phantom read occurs when, in the course of a transaction, two
identical queries are executed, and the collection of rows returned by
the second query is different from the first.
 Example: different average (still!)
-- T1: -- T2:
SELECT AVG(balance)
FROM Account;
INSERT INTO Account
VALUES(428571, 1000);
COMMIT;
SELECT AVG(balance)
FROM Account;
COMMIT;
Transactions - Serializable
 None of these problems can happen
Transactions – Summary of SQL
Isolation Levels
Isolation Level/Anomaly Dirty Reads Non-Repeatable Reads Phantoms

READ UNCOMMITTED Possible Possible Possible

READ COMMITTED Impossible Possible Possible

REPEATABLE READ Impossible Impossible Possible

SERIALIZABLE Impossible Impossible Impossible
Transactions - Serializability
 A ‘schedule’ is the actual execution sequence of
two or more concurrent transactions.
 A schedule of two transactions T1 and T2 is
‘serializable’ if and only if executing this
schedule has the same effect as either
T1;T2 or T2;T1.
What is JDBC ?
 JDBC stands for “Java DataBase Connectivity”
 The standard interface for communication
between a Java application and a SQL database
 Allows a Java program to issue SQL statements
and process the results.
 JDBC Classes and Interfaces
Steps to using a database query:
• Load a JDBC “driver”
• Connect to the data source
• Send/execute SQL statements
• Process the results
JDBC Driver
 Acts as the gateway to a database
 Not actually a “driver”, just a .jar file

Java application Database Server

JDBC Driver
JDBC Driver Installation
 Must download the driver, then add the .jar file to
your $CLASSPATH or NetBeans project
 To set up your classpath on Windows
 Control panel
 Search for Environment Variables
 Add the jar file to your CLASSPATH variable
JDBC Driver Management
 All drivers are managed by the DriverManager
class
 Example - loading an Oracle JDBC driver:
 In the Java code:
Class.forName(“oracle.jdbc.driver.OracleDriver”)
 Driver class names:
Oracle: oracle.jdbc.driver.OracleDriver
MySQL: com.mysql.jdbc.Driver
MS SQL Server:
com.microsoft.jdbc.sqlserver.SQLServerDriver
 Establishing a Connection
• Create a Connection object
• Use the DriverManager to grab a connection
with the getConnection method
• Necessary to follow exact connection syntax
• Problem 1: the parameter syntax for
getConnection varies between JDBC drivers
• Problem 2: one driver can have several
different legal syntaxes
Establishing a Connection (cont.)
Oracle Example
• Connection con =
DriverManager.getConnection(string,
“username", “password");
• what to supply for string ?
• “jdbc:oracle:thin:@augur.seas.gwu.edu:1521:orcl10g2”

Driver Type Database URL Port # SID

Establishing a Connection (cont.)
MySQL Example
• Connection con =
DriverManager.getConnection(string);
• what to supply for string ?
• “jdbc:mysql://<URL>:3306/<DB>?user=<user>&password=<pw>”

Driver URL Port DB Username Password

Name
Executing Statements
 Obtain a statement object from the
connection:
 Statement stmt = con.createStatement ();
 Execute the SQL statements:
 stmt.executeUpdate(“update table set
field=‘value’”);
 stmt.executeUpdate(“INSERT INTO mytable
VALUES (1, ‘name’)”);
 stmt.executeQuery(“SELECT * FROM mytable”);
Retrieving Data
• ResultSet rs =
stmt.executeQuery(“SELECT id,name
FROM employees where id = 1000”)
• Some methods used in ResultSet:
– next()
– getString()
– getInt()
Using the Results
while (rs.next())
{
int s = rs.getInt("id");
String n = rs.getString("name");
System.out.println(s + " " + n);
}
Executing SQL Statements
 Three different ways of executing SQL
statements:
 Statement (both static and dynamic SQL
statements)
 PreparedStatement (semi-static SQL statements)
 CallableStatment (stored procedures)
PreparedStatement class:Precompiled,
parametrized SQL statements:
 Structure is fixed
 Values of parameters are determined at run-time
The Challenge
 The createStatement objects that you saw in the
example code are OK for simple statements, but
they become cumbersome if you want to prompt the
user for values at runtime.
 Also, the database optimizer (at least in Oracle) will
take the literal string of a statement, and create a
map from that string to the compiled version.
 If you run the same exact statement twice, with the only
difference being the value of a literal, the optimizer will not
recognize that, and parse the statement from scratch each
time you submit it with a new literal.
 Also, it’s cumbersome to have to translate your variables
to String before including them into the statement.
Bind ambition
 The PreparedStatement is an alternative that is somewhat
better.
 For example, to prompt the user for the name of the album
that they wish to query on, you would:
 String stmt = “select * from albums where albumtitle = ?”;
 PreparedStatement pstmt = conn.prepareStatement(stmt);
 What’s going on is that stmt string has a bind variable, that
“?” in it, that stands for a value. In this case, it’s a String,
but it could be any supported primitive datatype.
 The beauty of the prepared statement, even in this case, is
that the value that is substituted in at run time for that “?”
could have embedded quotes.
 The next line creates the pstmt object. It’s not ready to
execute yet, we still need to supply the value that we want
to substitute in for the “?”. That is called binding the
variable.
Mapping from the bind variables to
a value
 pstmt.setString(1, “Please Please Me”); tells
JDBC to map the value “Please Please Me” to
the first (this is where this gets messy) bind
variable in the pstmt statement.
 That’s not too bad if you only have one or two
bind variables, you just have to keep track of
which is in which order, and call the proper set
method with the proper index.
 However, be very careful if you should ever
insert a new bind variable into the middle of your
statement.
A set of sets
 If you go to URL:
http://docs.oracle.com/javase/8/docs/api/, and then click
on the link labeled “java.sql”, you’ll find that there is an
API just for the various JDBC methods.
 Once in the java.sql API, if you select
PreparedStatement, you’ll see a collection of set
methods, like setDate, setFloat (I’ll have root beer in
mine thank you) setInt to name just a few.
 The setDate will take a java Date object (which you can
build once you import the java.util.date package).
The execution
 Once you have prepared the statement, and
bound all of its variables, you’re ready to
execute.
 There is an executeQuery, executeUpdate or
just execute.
 The executeQuery returns a ResultSet object that
you’re already familiar with.
 The executeUpdate method will not just do updates, it
performs inserts and deletes as well, and returns the
integer number of records impacted by your DDL
statement.
Executing SQL Statements (cont.)
String sql=“INSERT INTO Sailors
(SailorID,SailorName,Rating,Age) VALUES(?,?,?,?)”;
PreparedStatment pstmt=con.prepareStatement(sql);
pstmt.clearParameters();
pstmt.setInt(1,sid);
pstmt.setString(2,sname);
pstmt.setInt(3, rating);
pstmt.setFloat(4,age);
// we know that no rows are returned, thus we use
executeUpdate()
int numRows = pstmt.executeUpdate();
ResultSets
 PreparedStatement.executeUpdate only returns
the number of affected records
 PreparedStatement.executeQuery returns data,
encapsulated in a ResultSet object (a cursor)

ResultSet rs=pstmt.executeQuery();
// rs is now a cursor
While (rs.next()) {
// process the data
}
ResultSets (cont.)
A ResultSet is a very powerful cursor:
 previous(): moves one row back
 absolute(int num): moves to the row with the
specified number
 relative (int num): moves forward or backward
 first() and last()
Retrieving the results
 The ResultSet interface sports getDate, getInt,
getString, and so on to convert from the
database representation of the data to a Java
representation of the data.
Matching Java-SQL Data Types
SQL Type Java class ResultSet get method
BIT Boolean getBoolean()
CHAR String getString()
VARCHAR String getString()
DOUBLE Double getDouble()
FLOAT Double getDouble()
INTEGER Integer getInt()
REAL Double getFloat()
DATE java.sql.Date getDate()
TIME java.sql.Time getTime()
TIMESTAMP java.sql.TimeStamp getTimestamp()
Data About the Data
 ResultSetMetaData rsmd = rs.getMetaData();
 Use the import: java.sql.* for the ResultSetMetaData
interface.
 For more information, see the documentation at:
https://docs.oracle.com/javase/8/docs/api/java/sql/Res
ultSetMetaData.html.
 What I’m going to cover is just a fraction of what this
class can do.
 Bear in mind that these methods are all operating on
the entire result set, not any given row in the result
set.
Useful methods
 int – getColumnCount() returns the # of columns in the
result set. Good first call to make when looping through
the meta data for a given result set.
 These utilities all start at 1 for the first column. Do not let
that confuse you with starting at 0 for arrays.
 int – getColumnDisplaySize (int) – returns the
designated column’s maximum width.
 String – getColumnName (int)
 int getColumnType (int) – returns an integer
corresponding to the column type. See java.sql.Types
for the list of valid types that can be returned.
 String getColumnTypeName (int) – returns name of the
column type.
You Also Might be Interested In:
 int isNullable (int) – you receive an integer
{columnNoNulls, columnNullable,
columnNullableUnknown} in return
 String getTableName (int) – returns the table
name from the specified column index
 boolean isReadOnly (int)
 boolean isWriteable (int)
JDBC: Exceptions and Warnings
 Most of java.sql can throw and SQLException if
an error occurs (use try/catch blocks to find
connection problems)
 SQLWarning is a subclass of SQLException; not
as severe (they are not thrown and their
existence has to be explicitly tested)
JDBC MySQL example:
 Excellent instructions can be found at:
 http://www.tutorialspoint.com/jdbc/
 Sample Code can be found at:
 http://www.csulb.edu/~mopkins/cecs323/FirstEx
ample.java