Database Management

EE4791
Database Systems
Chapter 0:
Course Information
A/P Wang Lipo
Chapter 0 Course Information
This Course Has 2 Parts

Part 1: Logic Design
Lectures: Weeks 1 6
Tutorials: Weeks 2 - 7
Lecturer / Tutor: A/P Wang Lipo

Part 2: Physical Design
Lectures: Weeks 7 12
Tutorials: Weeks 8 - 13
Lecturer / Tutor: A/P Tan Hee Beng Kuan

Course Outline
Part I: A/P Wang Lipo
Database Concepts (Chapter 1)
Database Design (Chapters 3 - 5)
Structured Query Language (SQL) (Chapters 7
& 8)
Part II: A/P Tan Hee Beng Kuan
Physical Design
DB Administration
Client/Server DB
Data Warehousing
Wang Lipos Contact

Office: S1-B1C-98
Office Phone: 6790 6372
Email: elpwang@ntu.edu.sg
(NTU email alias: Lipo Wang)
Please dont send email to Wang Libo
Textbook
Modern Database Management
11th Edition
Jeffrey A. Hoffer, et al
Prentice Hall
(other editions should be OK, too)
LOTS of reference books on databases !!!
Assessment
Continuous Assessment (CA) (20%)
Part 1, 10%, an assignment on database
design & implementation (to be announced)
Part 2, 10%, to be announced
Examination (80%)
4/4 questions
Consulting Hours
Monday 13:30 15:30
Tuesday 10:30 11:30
Or by appointment
Or just drop by at any time
Your suggestions/comments are always
welcome!
Chapter 1:
The Database Environment
11th Edition
Jeffrey A. Hoffer, Ramesh Venkataraman,
Heikki Topi
Chapter 1 The Database Environment
Objectives
Definitions
Limitations of conventional file processing
Advantages of databases
Evolution of database systems
Definitions
Database: organized collection of logically
related data
Data: stored objects and events
Structured: numbers, text, dates
Unstructured: images, video
Information: data processed to become

knowledge
Metadata: data that describes the properties and
context of user data
Figure 1-1a Data Examples
Figure 1-1b Processed data - Information
Graphical displays turn data into useful

information that managers can use for
decision making and interpretation
Descriptions of the properties or characteristics of the

data, including data types, field sizes, allowable
values, and data context
10
11
Disadvantages of File Processing

Program-Data Dependence
All programs maintain metadata for each file they use

Own routines for reading, inserting, updating, and deleting data
Lengthy development times
Excessive program maintenance
Duplication of Data
Different systems/programs have separate copies of the same data
12
Figure 1-3 Old file processing systems at Pine Valley

Furniture Company
Duplicate Data
13
Problems with Data

Redundancy
Waste of space
The biggest problem:
Data changes in one file could cause
inconsistencies
14
SOLUTION:
The DATABASE Approach
Central repository of shared data
Minimum data redundancy
A standard software
Database Management System (DBMS)
15
Advantages of the Database Approach

Program-data independence
Increased application development
productivity
Reduced program maintenance
Planned data redundancy

Improved data consistency
16
Evolution of DB Systems
17
Why Relational Database?

It works very well
Although it doesnt handle images/videos
Not much to gain in changing database
technology
Most companies are using relational database
High cost of changing to another database

Cost for database software
Risk for downtime
Risk for data loss
18
Regarding Relational DB Products (1)

A big party is being held to honor relational database
systems and their impact on modern society.
Outside the venue, the host awaits the guests.
The first limousine arrives and out steps Oracle
followed by 4 people.
Host: Who have you brought along?
Oracle: I have 4 DBAs in tow. One to install me, one
to design the databases, one to administer me, and
the other to justify the cost.
19

A second limo arrives and out steps DB2 (from IBM)
followed by 40 people.
Host: Who have you bought along?
DB2: I have 2 DBAs, 2 hardware specialists, and 36
consultants.
20

A third limo arrives and out steps SQL Server (from
Microsoft) all on his own.
Host: Why havent you brought anyone?
SQL Server: I didnt bring anyone because I am easy
to install and am basically self managing. But I did
bring the #sqlhelp Twitter hashtag for when the
excrement hits the fan.
21

20 minutes later, up rushes MySQL (a free product),
unshaved, hair a mess.
Host: Where have you been MySQL?
MySQL: Sorry, I thought it was February 31st.
22
Chapter 3:
Entity-Relationship (ER)
Modeling
11th Edition
Heikki Topi
Chapter 3 Modeling Data in the Organization
Objectives
Write good names and definitions for entities,
relationships, and attributes
Distinguish unary, binary, and ternary relationships
Model different types of attributes, entities, relationships,
and cardinalities
Draw Entity-Relationship (ER) diagrams for common
business situations
Convert many-to-many relationships to associative
entities
A Good Data Name is:

Related to business, not technical,
characteristics
Meaningful and self-documenting
Unique
Entity-Relationship (ER)
Model
Entities:
Entity instance: a person, a place, an object, an event (often
corresponds to a row in a table)
Entity Type: collection of entity instances, a type of persons, a type
of places, (often corresponds to a table)
Relationships:
Relationship instance: link between entity instances
Relationship type: category of relationshiplink between entity
types
Attribute: property or characteristic of an entity type or relationship

type (often corresponds to a column or field in a table)
Pine Valley Furniture
(Figure 2-11)
Figure 2-12 Four tables (Pine Valley Furniture)

Entity Type
Attribute
Entity Instance
6
Figure 2-12 Four relations (Pine Valley Furniture)

Relationship Type
Relationship Instance
Figure 3-10 Relationship types and instances

a) Relationship type
b) Relationship
instances
What Should an Entity Be?

SHOULD BE something:
with multiple instances
with multiple attributes
for which we are interested in storing data
SHOULD NOT BE:

A user of the database system
An output of the database system (e.g., a
report)
Figure 3-4 Example

Inappropri
ate entity:
System
user
Inappropriate
entities
Appropriate
entity
Inappropriate
entity: System
output
Appropriate
entity
10
Attributes
Classifications of attributes:
Required versus Optional Attributes
Simple versus Composite Attribute
Single-Valued versus Multivalued Attribute
Stored versus Derived Attributes
Identifier Attributes
11
Identifiers (Keys)
Identifier (Key): An attribute (or combination
of attributes) that uniquely identifies
individual instances of an entity type
Simple identifier (a single attribute) versus
Composite Identifier (a combination of
multiple attributes)
Candidate Identifier: an attribute or a
combination of attributes that could be a
keysatisfies the requirements for being an
identifier
12
Characteristics of Identifiers
Will not be null
No intelligent identifiers (e.g., containing
locations or phone numbers that might
change)
Substitute new, simple keys for long,
composite keys, when worthwhile
13
Figure 3-7 A composite attribute

An attribute
broken into
component parts
Figure 3-8 Entity with multivalued attribute (Skill)
and derived attribute (Years_Employed)
Multivalued
an employee can have
more than one skill
Derived
from date
employed and
current date
14
Figure 3-9 Simple and composite identifier attributes

The identifier is boldfaced and underlined
15
More on Relationships
Relationships can have attributes
These describe features pertaining to the association
between the entities in the relationship

16
More on Relationships
Two entities can have more than one type of
relationship between them (multiple
relationships)
17
Degree of Relationships
Degree of a relationship is the
number of entity types that
participate in it
Unary Relationship
Binary Relationship
Ternary Relationship
18
Degree of relationships (Figure 3-2)
One entity
instance
related to
another of
the same
entity type
Entities of
two different
types related
to each other
Entities of three
different types
related to each
other
19
Cardinality of Relationships
One-to-One
An instance in an entity type in the relationship is
related to at most 1 instance in another entity type
One-to-Many
An instance in the entity type on one-side of the
relationship can be related to many instances in the
many-side entity type, but an entity instance on the
many-side of the relationship can be related to a
maximum of 1 entity instance in the one-side entity
type
Many-to-Many
Entity instances on both sides of the relationship can
be related to many entity instances on the other side
20
Cardinality Constraints
Cardinality Constraints - the number of
instances of one entity that can or must be
associated with each instance of another
entity
Minimum Cardinality
If zero, then optional
If one or more, then mandatory
Maximum Cardinality
The maximum number
21
Figure 3-12 Examples of relationships of different relationship degrees

a) Unary relationships
22

(cont.)
b) Binary relationships
23

(cont.)
c) Ternary relationship (many-to-many)
These attributes belong to the relationship Supplies

24
Figure 3-17 Examples of cardinality constraints
a) Mandatory cardinalities
A patient history is
recorded for one and
only one patient
A patient must have recorded

at least one history, and can
have many
25
Figure 3-17 Examples of cardinality constraints (cont.)
b) One optional, one mandatory
A project must be
assigned to at least one
employee, and may be
assigned to many
An employee can be assigned

to any number of projects, or
may not be assigned to any
at all
26
Figure 3-17 Examples of cardinality constraints (cont.)
a) Optional cardinalities
A person is is
married to at most
one other person,
or may not be
married at all
27
Figure 3-11b An associative entity (CERTIFICATE)
A many-to-many relationship (top) can be replaced by two oneto-many relationships with an associative entity (CERTIFICATE
at bottom).
28
Figure 3-21 Examples of multiple relationships (cont.)

b) Professors and courses (fixed lower limit constraint)
Here, min
cardinality
constraint is 2
29
Figure 3-15a and 3-15b Multivalued attributes can be represented as relationships
simple
Course Table
Pre-Requisite
Course ID
Course Title
Course ID
Pre-Req ID
EE4791
Database
EP122
EE4791
EP122
Accounting
EP233
EP122
EP233
Finance
EP233
EE4791
PH321
Physics
30
Figure 3-15a and 3-15b Multivalued attributes can be represented as relationships
EMPLOYEE
POSSESSES
Employee
_ID
Employee_
Name
Employee
_ID
Skill_Code
981
Wang
122
C98
122
Singh
233
C98
233
Uno
233
E98
981
E98
981
C98
SKILL
Skill Code
Skill-Type
E98
Programming
C98
Writing
31
Strong vs. Weak Entities, and

Identifying Relationships
Strong entities
Each instance in a strong entity exists independently of instances in
other entity types
A strong entity has its own unique identifier
identifier underlined with single-line
Weak entity
The existence of an instance in a weak entity depends on the
existence of an intance in a strong entity (identifying
owner)cannot exist on its own
A weak entity does not have a unique identifier (only a partial
identifier)
Partial identifier underlined with double-line
Entity box has double line
Identifying relationship
links strong entities to weak entities
32
Strong entity and weak entity relationship
Strong entity
Weak entity
33
Figure 3-13c An associative entity: bill of materials structure
This could just be a relationship (unary, many-to-many)

with attributesits a judgment call
34
Figure 3-18 Ternary relationship as an associative entity
35
Microsoft Visio
Notation for Pine
Valley Furniture
ER diagram
Different modeling
software tools may have
different notation for the
same constructs
36
Chapter 4:
Supertype/Subtype
Relationship and Business
Rules
11th Edition
Heikki Topi
Chapter 4 More on ER Model and Business Rules
Objectives
Use of supertype/subtype relationships
Use of generalization and specialization techniques
Specification of completeness and disjointness
constraints
Name categories of business rules
Define operational constraints graphically and in English
Supertypes and Subtypes

Subtype: A subgrouping of the entities in an entity
type that has attributes distinct from those in other
subgroupings
Supertype: A generic entity type that has one or

more subtypes
Attribute Inheritance:
Subtype entities inherit values of all attributes of
the supertype
An instance of a subtype is also an instance of the
supertype
Relationships and Subtypes

Relationships at the supertype level
indicate that all subtypes will participate in
the relationship
The instances of a subtype may
participate in a relationship unique to that
subtype.
In this situation, the relationship is shown at
the subtype level
Figure 4-1 Basic notation for supertype/subtype notation
a) ER
notation
Figure 4-2 Employee supertype with three subtypes

All employee subtypes
will have employee
number, name, address,
and date-hired
Each employee subtype

will also have its own
attributes
Figure 4-3 Supertype/subtype relationships in a hospital

Both
outpatients
and resident
patients are
cared for by
a responsible
physician
Only resident patients are

assigned to a bed
Generalization and
Specialization
Generalization: defining a more general
entity type from a set of more specialized
entity types.
BOTTOM-UP
Specialization: defining one or more

subtypes of the supertype and forming
supertype/subtype relationships.
TOP-DOWN
Figure 4-4 Example of generalization

a) Three entity types: CAR, TRUCK, and MOTORCYCLE
All these types of vehicles have common attributes

Figure 4-4 Example of generalization (cont.)

b) Generalization to VEHICLE supertype
So we put
the shared
attributes in
a supertype
Note: no subtype for motorcycle, since it has no unique attributes

10
Figure 4-5 Example of specialization

a) Entity type PART
Only applies to
manufactured parts
Applies only to purchased parts
11
Figure 4-5 Example of specialization (cont.)

b) Specialization to MANUFACTURED PART and PURCHASED PART
Created 2
subtypes
Note: multivalued attribute was replaced by an

associative entity relationship to another entity
12
Constraints in Supertype/
Completeness Constraint
Completeness Constraints: Whether an
instance of a supertype must also be a
member of at least one subtype (in other
words, whether the instances in the subtypes
completely cover the instances in the
supertype)
Yes: Total Specialization Rule (double line)
No: Partial Specialization Rule (single line)
13
Figure 4-6 Examples of completeness constraints

a) Total specialization rule
A patient must be either

an outpatient or a
resident patient
14
Figure 4-6 Examples of completeness constraints (cont.)

b) Partial specialization rule
A vehicle
does not
need to be
a car or a
truck
15
Disjointness constraint
Disjointness Constraints: Whether
an instance of a supertype may
simultaneously be a member of two (or
more) subtypes (in other words, whether
overlap exists between subtypes)
Yes: Overlap Rule (o)
No: Disjoint Rule (d)
16
Figure 4-7 Examples of disjointness constraints

a) Disjoint rule
A patient cannot be both

outpatient and resident
simultaneously
17
Figure 4-7 Examples of disjointness constraints (cont.)

b) Overlap rule
A part may be both

purchased and
manufactured
18
Subtype Discriminators
Subtype Discriminator: An attribute of the
supertype whose values determine the target
subtype(s)
Disjoint a simple attribute (scalar) with alternative
values to indicate the possible subtypes
Overlapping a composite attribute whose subparts
pertain to different subtypes (vector). Each subpart
contains a boolean value to indicate whether or not
the instance belongs to the associated subtype
19
Figure 4-8 Introducing a subtype discriminator (disjoint rule)
A simple attribute with

different possible values
indicating the subtype
20
Figure 4-9 Subtype discriminator (overlap rule)

A composite
attribute with
sub-attributes
indicating yes
or no to
determine
whether it is of
each subtype
21
Figure 4-10 Example of supertype/subtype hierarchy
22
Business rules
Statements that define or constrain some aspect of
the business
Automated through DBMS software
A Good Business Rule is:
Precise: clear, agreed-upon meaning

Atomic: one statement on a single issue
Consistent: internally and externally
Expressible: structured, natural language
Distinct: non-redundant
Business-oriented: understood by business people
23
Categories of Business Rules

Derivation
rule derived from other knowledge, often in the form of a
formula using attribute values
E.g., years employed derived from date_hired
Structural assertion
rule expressing static structure. Includes attributes,
relationships, and definitions
E.g., each 2nd year student must have a major
Action assertion
rule expressing constraints/control of organizational actions
24
Stating an Action Assertion

Anchor Object: an object on which actions
are limited
Action: creation, deletion, update, or read
Corresponding Objects: an object
influencing the ability to perform an action
on another business rule
Action assertions identify corresponding objects that
constrain the ability to perform actions on anchor objects
25
Figure 4-19 Data model segment for class scheduling
26
Figure 4-20 Business Rule 1: For a faculty member to be assigned to

teach a section of a course, the faculty member must be qualified to
teach the course for which that section is scheduled
Corresponding object
In this case, the

action assertion
is a Restriction
Action assertion
Anchor object
Corresponding object
27
Figure 4-21 Business Rule 2: For a faculty member to be assigned to

teach a section of a course, the faculty member must not be assigned to
teach a total of more than three course sections
In this case, the

action assertion
is an
Corresponding
object
Upper LIMit
Action assertion
Anchor object
28
Chapter 5:
Logical Database Design and
the Relational Model
11th Edition
Heikki Topi
Chapter 5 Logical Database Design and the Relational Model
Objectives
Properties of relations
Properties of candidate keys
First, second, and third normal form
Transform ER diagrams to relations
Create tables with entity and relational integrity
constraints
Use normalization to convert anomalous tables
to well-structured relations
Relation
Definition: A relation is a named, two-dimensional table of
data
Table consists of rows (records) and columns (attribute or
field)
Requirements for a table to qualify as a relation:

It must have a unique name
Every attribute value must be atomic (not multivalued, not
composite)
Every row must be unique (cant have two rows with exactly the
same values for all their fields)
Attributes (columns) in tables must have unique names
The order of the columns must be irrelevant
The order of the rows must be irrelevant
The word relation (in relational database) is NOT

the same as the word relationship (in ER model)
Definition: all relations are in
1st Normal form
Example of a Relation with Data
Key Fields
Keys are special fields that serve two main purposes:
Primary keys are unique identifiers of the relation in question.
Examples include employee numbers, passport numbers, etc.
This is how we can guarantee that all rows are unique
Foreign keys are identifiers that enable a dependent relation
(on the many side of a relationship) to refer to its parent relation
(on the one side of the relationship)
Keys can be simple (a single field) or composite (more

than one field)
Keys usually are used as indexes to speed up the
response to user queries
Figure 5-3 Schema for four relations (Pine Valley Furniture Company)
Primary Key
Foreign Key
(implements 1:N relationship
between customer and order)
Combined, these are a composite

primary key (uniquely identifies the
order line)individually they are
foreign keys (implement M:N
relationship between order and product)
An Example in Microsoft Access with Data:
Integrity Constraints
Domain Constraints
Allowable values for an attribute
Metadata
Entity Integrity
No primary key attribute may be null: All
primary key fields MUST have data
Action Assertions
Business rules. Recall from Chapter 4
Domain definitions enforce domain integrity constraints
10
Integrity Constraints
Referential Integrity: any foreign key value (on the relation of
the many side) MUST match a primary key value in the relation
of the one side. Or the foreign key can be null.
For example: Delete Rules
Restrict: dont allow delete of parent side if related rows
exist in dependent side
Cascade: automatically delete dependent side rows that
correspond with the parent side row to be deleted (e.g.,
in weak entities)
Set-to-Null: set the foreign key in the dependent side to
null if deleting from the parent side not allowed for
weak entities
11
Figure 5-5
Referential integrity constraints (Pine Valley Furniture)
Referential
integrity
constraints are
drawn via arrows
from dependent to
parent table
12
Transforming ER Diagrams into

Relations
Mapping Regular Entities to Relations
1. Simple attributes: entity attributes become
column names in table
2. Composite attributes: break them into simple
attributes, which become column names
3. Multivalued Attribute: break into a new table
with a 1:N relationship with the original table,
with a foreign key taken from the superior
entity (the 1-side entity)
13
Figure 5-8 Mapping a regular entity
(a) CUSTOMER
entity type with
simple
attributes
(b) CUSTOMER relation
14
Figure 5-9 Mapping a composite attribute

(a) CUSTOMER
entity type with
composite
attribute
(b) CUSTOMER relation with address detail
15
Figure 5-10 Mapping an entity with a multivalued attribute

(a)
Multivalued attribute becomes a separate relation with foreign key

(b)
Onetomany relationship between original entity and new relation

16

Relations (cont.)
Mapping Weak Entities
Becomes a relation with a foreign key
taken from the superior entity
Primary key composed of:
Partial identifier of weak entity
Primary key of identifying relation (strong
entity)
17
Figure 5-11 Example of mapping a weak entity

a) Weak entity DEPENDENT
18
Figure 5-11 Example of mapping a weak entity (cont.)

b) Relations resulting from weak entity
NOTE: the domain constraint
for the foreign key should
NOT allow null value if
DEPENDENT is a weak
entity
Foreign key
Composite primary key
19

Relations (cont.)
Mapping Binary Relationships
One-to-Many: Primary key on the one side
becomes a foreign key on the many side
Many-to-Many: Create a new relation with
the primary keys of the two entities as its
primary key
One-to-One: Primary key on the mandatory
side becomes a foreign key on the optional
side
20
Figure 5-12 Example of mapping a 1:M relationship

a) Relationship between customers and orders
Note the mandatory one
b) Mapping the relationship
Foreign key
21
22
Figure 5-13 Example of mapping an M:N relationship

a) Completes relationship (M:N)
The Completes relationship will need to become a separate relation

23
Figure 5-13 Example of mapping an M:N relationship (cont.)

b) Three resulting relations
Foreign key
Foreign key
New
relationship
table
24
Figure 3-11b An associative entity (CERTIFICATE)
An equivalent E-R with an associative entity CERTIFICATE:
25
The equivalent ER with associate entity in the previous

slide will result in exactly the same 3 tables:
Foreign key
Foreign key
26
Example of Mapping an M:N Relationship, with Data
27
28
Figure 5-14 Example of mapping a binary 1:1 relationship
Often in 1:1 relationships, one direction is optional.
29
Figure 5-14 Example of mapping a binary 1:1 relationship (cont.)

b) Resulting relations
Foreign key goes in the relation on the optional side,

Matching the primary key on the mandatory side.
Nurse_in_charge is the Nurse_ID of the nurse in charge.
30
Mandatory side primary key going into the optional side as

foreign key:
Nurse_ID
Nurse_Name Birth_Date
1001
Jane
1973.2.2
1002
Mary
1977.2.1
1003
Irene
1979.2.5
Center_ID
Location
Nurse_in_Charg
Date_Assigned
201
Jurong
1002
2014.12.20
works better than the other way around:

Nurse_ID Nurse_Name Birth_Date
1001
Jane
1973.2.2
1002
Mary
1977.2.1
1003
Irene
1979.2.5
Center_ID
Center_ID Date_Assigned
201
2014.12.20
Location
201 5 LogicalJurong
Chapter
Database Design and the Relational Model
31

Relations (cont.)
Mapping Associative Entities
If identifier is not assigned
Default primary key for the association
relation is composed of the primary keys of
the two entities (as in M:N relationship)
If identifier is already assigned

Treat as 2 1:N relationships: insert primary
keys from 1-side into N-side as foreign
keys
32
Figure 5-15 Example of mapping an associative entity

a) An associative entity
33
Figure 5-15 Example of mapping an associative entity (cont.)

Composite primary key formed from the two foreign keys

34
Figure 5-16 Example of mapping an associative entity with

an identifier
a) SHIPMENT associative entity
35
Figure 5-16 Example of mapping an associative entity with

an identifier (cont.)
Primary key differs from foreign keys
36

Relations (cont.)
Mapping Unary Relationships
One-to-Many: Recursive foreign key in the
same relation
Many-to-Many: Two relations:
One for the entity type
One for an associative relation in which the
primary key has two attributes, both taken
from the primary key of the entity
37
Figure 5-17 Mapping a unary 1:N relationship
(a) EMPLOYEE entity with

unary relationship
(b) EMPLOYEE relation with recursive foreign key

Manager_ID is the Employee_ID of the manager.
38
39
Figure 5-18 Mapping a unary M:N relationship
(a) Bill-of-materials
relationships (M:N)
(b) ITEM and

COMPONENT
relations
40
41

Relations (cont.)
Mapping Ternary (and n-ary)
Relationships
One relation for each entity and one for
the associative entity
Associative entity has foreign keys to
each entity in the relationship
42
Figure 5-19 Mapping a ternary relationship

a) PATIENT TREATMENT Ternary relationship with
associative entity
43
Figure 5-19 Mapping a ternary relationship (cont.)

b) Mapping the ternary relationship PATIENT TREATMENT
Remember
that the
primary key
MUST be
unique
This is why
But this makes a
treatment date and
very
time are included in
cumbersome
the composite
key
primary key
It would be
better to create a
surrogate key
like Treatment#
44
Mapping a similar ternary relationship, with data
45
46
47
48
Transforming ER Diagrams
into Relations (cont.)
Mapping Supertype/Subtype Relationships
1:1 relationship established between supertype
and each subtype, with supertype as primary
table:
One relation for supertype and for each subtype
Supertype attributes (including identifier and
subtype discriminator) go into supertype relation
Subtype attributes go into each subtype;
primary key of supertype relation also becomes
primary key of subtype relation
49
Figure 5-20 Supertype/subtype relationships
50
Figure 5-21
Mapping Supertype/subtype relationships to relations
These are implemented as one-to-one

relationships
51
Normalization
Primarily a tool to validate and improve a logical
design so that it satisfies certain constraints that
avoid unnecessary duplication of data

The process of decomposing relations with
anomalies to produce smaller, wellstructured relations
Correct ER designs should make decomposition
unnecessary
The need for decomposition usually indicates errors
in ER designs
52
Well-Structured Relations
A relation that contains minimal data redundancy and
allows users to insert, delete, and update rows
without causing data inconsistencies
Goal is to avoid anomalies
Insertion Anomalyadding new rows forces user
to create duplicate data
Deletion Anomalydeleting rows may cause a
loss of data that would be needed for other future
rows
Modification Anomalychanging data in a row
forces changes to other rows because of
duplication
General rule of thumb: one thing, one table !

53
ExampleFigure 5-2b
AnswerYes: Unique rows and

no multivalued attributes
QuestionWhats the primary key? AnswerComposite: Emp_ID,
Course_Title
QuestionIs this a relation?
54
Anomalies in this Table

Insertioncant enter a new employee without
having the employee take a class
Deletionif we remove employee 140, we lose
information about the existence of a Tax Acc class
Modificationgiving a salary increase to employee
100 forces us to update multiple records
Why do these anomalies exist?
Because there are two themes (entity types) in this
one relation. This results in data duplication and an
unnecessary dependency between the entities
55
Functional Dependencies and Keys

Functional Dependency: The value of one
attribute (the determinant) determines the
value of another attribute
Candidate Key:
A unique identifier. One of the candidate
keys will become the primary key
E.g., if both credit card number and NRIC # are
in a table, both are candidate keys
Each non-key field is functionally

dependent on every candidate key
56
Figure 5.22 Steps in normalization
57
First Normal Form

Satisfies the conditions for a relation
It must have a unique name
Every attribute value must be atomic (not
multivalued, not composite)
Every row must be unique (cant have two rows
with exactly the same values for all their fields)
Attributes (columns) in tables must have unique
names
The order of the columns must be irrelevant
The order of the rows must be irrelevant
58
Table with multivalued attributes, not in 1st normal form
Note: this is NOT a relation

59
Table with no multivalued attributes and unique rows, in 1st

normal form
Note: this is relation, but not a well-structured one

60
Anomalies in this Table

Insertionif new product is ordered for order 1007
of existing customer, customer data must be reentered, causing duplication
Deletionif we delete the Dining Table from Order
1006, we lose information concerning this item's
finish and price
Updatechanging the price of product ID 4 requires
update in several records
Why do these anomalies exist?
Because there are multiple themes (entity types) in
one relation. This results in duplication and an
unnecessary dependency between the entities
61
Second Normal Form

1NF PLUS every non-key attribute is fully
functionally dependent on the ENTIRE
primary key
Every non-key attribute must be defined by the
entire key, not by only part of the key
No partial-key dependencies
AB means
an A value uniquely gives a B value, or
A uniquely determines B or
B is functionally dependent on A
62
Third Normal Form

2NF PLUS no transitive dependencies
(functional dependencies on non-primary-key
attributes)
Note: This is called transitive, because the
primary key is a determinant for another attribute,
which in turn is a determinant for a third
Solution: Non-key determinant with transitive
dependencies go into a new table; non-key
determinant becomes primary key in the new
table and stays as foreign key in the old table
63
Figure 5-27 Functional dependency diagram for INVOICE
Order_ID Order_Date, Customer_ID, Customer_Name, Customer_Address

Customer_ID Customer_Name, Customer_Address
Product_ID Product_Description, Product_Finish, Unit_Price
Order_ID, Product_ID Order_Quantity
Therefore, NOT in 2nd Normal Form

64
Figure 5-28 Removing partial dependencies
Getting it into
Second Normal
Form
Partial dependencies are removed, but there are
still transitive dependencies
65
Figure 5-28 Removing partial dependencies
Getting it into
Third Normal
Form
Transitive dependencies are removed
66
Finally, we end up with 4 3NF tables:
67
Chapter 7:
Introduction to SQL
11th Edition
Heikki Topi
Chapter 7 Introduction to SQL
Objectives
Define a database using SQL data
definition language
Establish referential integrity using SQL
Write single table queries using SQL
SQL Overview
Structured Query Language (SQL)
The standard for relational database
management systems (RDBMS)
RDBMS: A database management system
that manages data as a collection of tables in
which all relationships are represented by
common values in related tables
History of SQL
1970: E. Codd develops relational database
concept
1974: System R with Sequel (later SQL)
created at IBM Research Lab
1979: Oracle markets first relational DB with
SQL
1986: ANSI (American National Standards
Institute) SQL standard released
Current: SQL is supported by most major
database vendors
Benefits of a Standardized
Relational Language
Reduced training costs

Productivity
Application portability
Application longevity
Reduced dependence on a single vendor
Cross-system communication
SQL Environment
Schema
The structure that contains descriptions of objects created
by a user (base tables, views, constraints)
Catalog
A set of schemas that constitute the description of a
database
Data Definition Language (DDL)

Commands that define a database, including creating,
altering, and dropping tables and establishing constraints
Data Manipulation Language (DML)

Commands that maintain and query a database
Data Control Language (DCL)

Commands that control a database, including administering
privileges and committing data
SQL Database Definition

Data Definition Language (DDL)
Major CREATE statements:
CREATE TABLE: defines a table and its columns
CREATE VIEW: defines a logical table from one or
more tables/views
The following slides create tables for

this enterprise data model
Overall table
definitions
10
Defining attributes and their data types
11
Non-nullable specification
Identifying primary key

Primary keys
can never have
NULL values
12
Non-nullable specifications
Primary key
Some primary keys are composite:

composed of multiple attributes
13
Controlling the values in attributes

Default value
Domain constraint
14
Identifying foreign keys and establishing relationships
Primary key of
parent table
Foreign key of
dependent table
Referential integrity constraint
15
Data Integrity Controls

Referential integrityconstraint that
ensures that foreign key values of a
table must match primary key values of
a related table in 1:M relationships
Restricting:
Deletes of primary records
Updates of primary records
Inserts of dependent records
16
17
Insert Statement
Adds data to a table
Inserting an entire row into a table
INSERT INTO CUSTOMER_T VALUES (001, Contemporary
Casuals, 1355 S. Himes Blvd., Gainesville, FL, 32601);
Inserting a record that has some null attributes

requires identifying the fields that actually get data
INSERT INTO PRODUCT_T (PRODUCT_ID, PRODUCT_DESCRIPTION,
PRODUCT_FINISH) VALUES (1, End Table, Cherry);
(PRICE column is NULL)
Inserting from another table

INSERT INTO CA_CUSTOMER_T
SELECT * FROM CUSTOMER_T
WHERE STATE = CA;
18
Update Statement
Modifies data in existing rows
Change the unit price of the product whose
product id is 7 to 775:
UPDATE PRODUCT_T SET UNIT_PRICE = 775
WHERE PRODUCT_ID = 7;
19
Delete Statement
Removes rows from a table
Delete certain rows
Delete all customers from Hawaii:
DELETE FROM CUSTOMER_T
WHERE STATE = HI;
Delete all rows

Delete all rows in the customer table:
DELETE FROM CUSTOMER_T;
20
Removing Tables
DROP TABLE statement allows you to
remove tables from your schema:
DROP TABLE CUSTOMER_T
Be careful:
Both the data and the table structure will be deleted !!!
21
22
SELECT Statement
Used for queries on single or multiple tables
Clauses of the SELECT statement:
SELECT
List the columns (and expressions) that should be returned from the query
FROM
Indicate the table(s) or view(s) from which data will be obtained
WHERE
Indicate the conditions under which a row will be included in the result
GROUP BY
Indicate categorization of results
HAVING
Indicate the conditions under which a category (group) will be included
ORDER BY (ASC or DESC)

Sorts the result according to specified criteria
23
SELECT Example
Find products with standard price less than
$275
SELECT PRODUCT_NAME, STANDARD_PRICE
FROM PRODUCT_T
WHERE STANDARD_PRICE < 275;
24
SELECT Example Using Alias

Alias is an alternative column or table name
SELECT CUST.CUSTOMER AS NAME,
CUST.CUSTOMER_ADDRESS
FROM CUSTOMER_T AS CUST
WHERE NAME = Home Furnishings;
Same as:
SELECT CUSTOMER_T.CUSTOMER,
CUSTOMER_T.CUSTOMER_ADDRESS
FROM CUSTOMER_T
WHERE CUSTOMER_T.CUSTOMER = Home
Furnishings;
25
SELECT Example Using a Function

Using the COUNT aggregate function to find totals
Count the number of rows with ORDER_ID = 1004
(i.e., find the number of products ordered in
ORDER_ID 1004) :
SELECT COUNT(*)
FROM ORDER_LINE_T
WHERE ORDER_ID = 1004;
The output of the SQL for the
table on the right is 2.
26
SELECT ExampleBoolean Operators

AND, OR, and NOT Operators for customizing
conditions in WHERE clause
SELECT PRODUCT_DESCRIPTION, PRODUCT_FINISH,
STANDARD_PRICE
FROM PRODUCT_T
WHERE (PRODUCT_DESCRIPTION LIKE %Desk
OR PRODUCT_DESCRIPTION LIKE %Table)
AND UNIT_PRICE > 300;
Note: the LIKE operator allows you to compare strings using wildcards.
For example, the % wildcard in %Desk indicates that all strings that
have any number of characters preceding the word Desk will be allowed
27
Venn Diagram from Previous

Query
28
SELECT Example
Sorting Results with the ORDER BY Clause
Sort the results first by STATE, and within a state by
CUSTOMER_NAME
SELECT CUSTOMER_NAME, CITY, STATE
FROM CUSTOMER_T
WHERE STATE IN (FL, TX, CA, HI)
ORDER BY STATE, CUSTOMER_NAME DESC;
Note: the IN operator in this example allows you to include rows
whose STATE value is either FL, TX, CA, or HI. It is more
efficient than separate OR conditions
29
SELECT Example
Categorizing Results Using GROUP BY
List all states and the number of customers in
each state
SELECT CUSTOMER_STATE, COUNT(CUSTOMER_ID)
FROM CUSTOMER_T
GROUP BY CUSTOMER_STATE;
30
SELECT Example
Qualifying Results by Categories
Using the HAVING Clause
List all states and the number of customers in each
state (limit to only states with more than 1 customer)
SELECT CUSTOMER_STATE, COUNT(CUSTOMER_ID)
FROM CUSTOMER_T
GROUP BY CUSTOMER_STATE
HAVING COUNT(CUSTOMER_ID) > 1;
Like a WHERE clause, but it operates on groups (categories),
not on individual rows. WHERE clause operates on
individual rows.
31
Using and Defining Views

Results of SQL SELECT statement on base tables or
other views
Base Table: table containing the raw data
Views provide users controlled access to tables
Dynamic View
A virtual table created dynamically upon request by a user
No data actually stored; instead data from base table made
available to user
Materialized View
Copy or replication of data: Data actually stored
Must be refreshed periodically to match the corresponding
base tables
32
Sample CREATE VIEW

CREATE VIEW EXPENSIVE_STUFF_V AS
SELECT PRODUCT_ID, PRODUCT_NAME, UNIT_PRICE
FROM PRODUCT_T
WHERE UNIT_PRICE >300;
View has a name
33
Pros and Cons of Views

Advantages
Simplify query commands
Assist with data security
Provide customized view for user
Disadvantages
Use processing time each time view is referenced
34
Chapter 8:
Advanced SQL
11th Edition
Heikki Topi
Chapter 8 Advanced SQL
Objectives
Write multiple table SQL queries

Define and use three types of joins
Write correlated and noncorrelated subqueries
Concepts of Embedded and Dynamic SQL
Processing Multiple TablesJoins

Join: a relational operation that causes two or more tables with a
common domain to be combined into a single table or view
Natural Join: a join in which the joining condition is based on

equality between values in the common columns (the common
columns appear only once in the SQL result)
Left Outer Join: a join in which rows that do not have matching
values in common columns are nonetheless included in the result
table
Union Join: includes all columns from each table in the join, and
an instance for each row of each table
The common columns in joined tables are usually the primary

key of the dominant table and the foreign key of the dependent
table in 1:M relationships
Example
These tables are used in queries that follow

Natural Join Example

For each customer who placed an order, what is the
customers name and order number?
Join involves multiple tables in FROM clause
SELECT CUSTOMER_T.CUSTOMER_ID, CUSTOMER_NAME, ORDER_ID
FROM CUSTOMER_T NATURAL JOIN ORDER_T
ON CUSTOMER_T.CUSTOMER_ID = ORDER_T.CUSTOMER_ID;
ON clause performs the

equality check for common
columns of the two tables
Note: from Fig. 1, you see

that only 9 Customers have
made a total of 10 orders.
Only 10 rows will be
returned from this Natural
Join.
6
Left Outer Join Example

List the customer name, ID number, and order number
for all customers. Include customer information even
for customers that do not have an order
SELECT CUSTOMER_T.CUSTOMER_ID, CUSTOMER_NAME,
ORDER_ID
FROM CUSTOMER_T LEFT OUTER JOIN ORDER_T
ON CUSTOMER_T.CUSTOMER_ID = ORDER_T.CUSTOMER_ID;
LEFT OUTER JOIN syntax with ON
causes: customer data to appear even
if there is no corresponding order data,
unlike NATURAL JOIN
Unlike
natural join,
this will
include
customer
rows with
no matching
order rows
Multiple Table Join Example

Assemble all information necessary to create an
invoice for order number 1006 4 tables involved in this join
SELECT CUSTOMER_T.CUSTOMER_ID, CUSTOMER_NAME,
CUSTOMER_ADDRESS, CITY, SATE, POSTAL_CODE,
ORDER_T.ORDER_ID, ORDER_DATE, QUANTITY,
PRODUCT_DESCRIPTION, STANDARD_PRICE,
(QUANTITY *STANDARD_PRICE)
FROM CUSTOMER_T, ORDER_T, ORDER_LINE_T, PRODUCT_T
WHERE CUSTOMER_T.CUSTOMER_ID =
ORDER.CUSTOMER_ID
AND ORDER_T.ORDER_ID = ORDER_LINE_T.ORDER_ID
AND ORDER_LINE_T.PRODUCT_ID = PRODUCT.PRODUCT_ID
AND ORDER_T.ORDER_ID = 1006;
Each pair of tables requires an equality-check condition in the
WHERE clause, matching primary keys against foreign keys
10
Figure 8-2 Results from a four-table join
From CUSTOMER_T table
From ORDER_T table
From PRODUCT_T table

11

A SQL Query walks into a bar. In one corner of
the bar are two tables. The Query walks up to
the tables and asks:
- Mind if I join you?
12
Processing Multiple Tables

Using Subqueries
Subquery: placing an inner query (SELECT
statement) inside an outer query
Subquery locations:
As a table of the FROM clause
In a WHERE clause: condition for a row
Within the HAVING clause: condition for a group
13
Subquery Example
Show the names of all customers who have
placed an order
SELECT CUSTOMER_NAME
FROM CUSTOMER_T
WHERE CUSTOMER_ID IN
(SELECT DISTINCT CUSTOMER_ID FROM ORDER_T);
Subquery returns a list that will be
used in the WHERE clause of the
outer query
14
Correlated vs. Noncorrelated

Subqueries
Noncorrelated subqueries:
Do not depend on data from the outer query
Execute only once for the entire outer query
Correlated subqueries:
Make use of data from the outer query
Execute once for each row of the outer query
Can use the EXISTS operator
15
These tables are again used in queries that follow

16
SELECT CUSTOMER_NAME FROM CUSTOMER_T

The subquery (in the box) is processed first and

an intermediate result table created:
CUSTOMER_ID
1
8
15
5
3
2
11
12
4
9 rows selected.
The subquery executes and returns

the customer IDs from the ORDER_T
table
No reference to data in outer query,
so subquery executes once only
17
SELECT CUSTOMER_NAME FROM CUSTOMER_T

The outer query (in the box) is processed next and

returns the customer name for each customer listed in
the intermediate result table:
CUSTOMER_NAME
Contemporary Casuals
Value Furniture
Home Furnishings
Eastern Furniture
Impressions
California Classics
American Euro Lifestyles
Battle Creek Furniture
Mountain Scenes
9 rows selected.
These are the only customers that

have IDs in the ORDER_T table
18
Correlated Subquery Example

Show all orders that include furniture finished in
natural ash
The EXISTS operator will return a TRUE
value if the subquery resulted in a nonempty set, otherwise it returns a FALSE
SELECT DISTINCT ORDER_ID FROM ORDER_LINE_T
WHERE EXISTS
(SELECT * FROM PRODUCT_T
WHERE PRODUCT_ID = ORDER_LINE_T.PRODUCT_ID
AND PRODUCT_FINISH = Natural ash);
The subquery tests for a value that

comes from the outer query and
executes once for each row of
outer query
19
OrderLine_T
Subquery refers
to outer-query
data, so
executes once
for each row of
outer query
Note: only the
Product_T
orders that
involve products
with Natural
Ash will be
included in the
final results
Query
Result:
1001
1002
1003
1007
1008
1009
20
Execution Steps of the Previous Query

1.
2.
3.
4.
5.
6.
7.
The outer query reads row 1 in OrderLine_T, with ProductID 1; The

subquery executes to see if product with ProductID 1 has a natural ash
finish. It doesnt, so nothing is put from subequery. EXISTS is false. No
output in outer query for row 1 in OrderLine_T
The outer query reads row 2 in OrderLine_T, with ProductID 2.
EXISTS is valued as true and OrderID 1001 is added to the query
result.
The outer query reads row 3 in OrderLine_T, EXIST is false, no output.
The outer query reads row 4 in OrderLine_T, The outer query reads
the next OrderID 1002; The subquery executes to see if any product in
that order has a natural ash finish. Product 3 does. EXISTS is valued
as true and OrderID 1002 is added to the query result
OrderID 1003 is added to the query result
OrderID 1004 is NOT added to the query result
21
Alternative Solution: NonCorrelated Subquery

Show all orders that include furniture finished in
natural ash
SELECT DISTINCT ORDER_ID FROM ORDER_LINE_T

WHERE PRODUCT_ID IN
(SELECT DISTINCT PRODUCT_ID
FROM PRODUCT_T
WHERE PRODUCT_FINISH = Natural ash);
22
Subquery in FROM Clause

Show all products whose standard price is higher than
the average price
Subquery forms the derived
table used in the FROM
clause of the outer query
One column of the subquery

is an aggregate function that
has an alias name
SELECT PRODUCT_DESCRIPTION, STANDARD_PRICE, AVGPRICE

FROM
(SELECT AVG(STANDARD_PRICE) AS AVGPRICE FROM PRODUCT_T),
PRODUCT_T
WHERE STANDARD_PRICE > AVGPRICE;
The WHERE clause normally cannot include aggregate functions, but

because the aggregate is performed in the subquery its result can be
used in the outer querys WHERE clause
23
Union Queries
Combine the output (union of multiple queries)
together into a single result table
First query
Combine
Second query
24
Embedded and Dynamic SQL

Embedded SQL
Including hard-coded SQL statements in a
program written in another language such as
C or Java
Dynamic SQL
Ability for an application program to generate
SQL code on the fly, as the application is
running
25
More Examples for SQL
SQL Database Table
Persons
LastName
Hansen
Svendson
Pettersen
table
FirstName
Ola
Tove
Kari
Address
Timoteivn 10
Borgvn 23
Storgt 20
City
Sandnes
Sandnes
Stavanger
SQL Queries
With SQL, we can query a database and have a result set
returned.
A query like this:
SELECT LastName
FROM Persons;
Gives a result set like this:
LastName
Hansen
Svendson
Pettersen
3
To select the columns named "LastName" and "FirstName",

use a SELECT statement like this:
SELECT LastName, FirstName
FROM Persons;
Query Result
LastName
Hansen
Svendson
Pettersen
FirstName
Ola
Tove
Kari
Select All Columns

To select all columns from the "Persons" table, use a *
symbol instead of column names, like this:
SELECT *
FROM Persons;
Query Results
LastName
Hansen
Svendson
Pettersen
FirstName
Ola
Tove
Kari
Address
Timoteivn 10
Borgvn 23
Storgt 20
City
Sandnes
Sandnes
Stavanger
5
Semicolon after SQL Statements?

Semicolon is the standard way to separate each SQL statement in
database systems that allow more than one SQL statement to be
executed in the same call to the server.
Some SQL tutorials end each SQL statement with a semicolon. Is
this necessary? We are using MS Access and SQL Server 2000
and we do not have to put a semicolon after each SQL statement,
but some database programs force you to use it.
DISTINCT
To select ALL values from the column named "Company" we use
a SELECT statement like this:
SELECT Company
FROM Orders;
Orders
Company
Sega
W3Schools
Trio
W3Schools
OrderNumber
3412
2312
4678
6798
Company
Sega
W3Schools
Trio
W3Schools
Note that "W3Schools" is listed twice in the result-set.

To show only DIFFERENT values from the column named
"Company" we use a SELECT DISTINCT statement like this:
SELECT DISTINCT Company
FROM Orders;
Orders
Company
Sega
Company
OrderNumber
Sega
3412
W3Schools 2312
Trio
W3Schools
Trio
4678
W3Schools 6798
Using the WHERE Clause

To select only the persons living in the city "Sandnes", we add a
WHERE clause to the SELECT statement:
SELECT *
FROM Persons
Persons table
WHERE City='Sandnes' ;
LastName
Hansen
Svendson
Svendson
Pettersen
FirstName
Ola
Tove
Stale
Kari
Address
Timoteivn 10
Borgvn 23
Kaivn 18
Storgt 20
City
Sandnes
Sandnes
Sandnes
Stavanger
Year
1951
1978
1980
1960
Query Results
LastName
Hansen
Svendson
Svendson
FirstName
Ola
Tove
Stale
Address
Timoteivn 10
Borgvn 23
Kaivn 18
City
Sandnes
Sandnes
Sandnes
Year
1951
1978
1980
What does this mean

SELECT *
FROM Professors
WHERE fun > 0 ;
No records found.
10
Insert a New Row

Persons
table
LastName
FirstName
Address
City
Pettersen
Kari
Storgt 20
Stavanger
INSERT INTO Persons

VALUES ('Hetland', 'Camilla', 'Hagabakka 24', 'Sandnes');
Persons
table
LastName
FirstName
Address
City
Pettersen
Kari
Storgt 20
Stavanger
Hetland
Camilla
Hagabakka 24
Sandnes
11
Insert Data in Specified Columns

LastName FirstName Address
City
Pettersen
Kari
Storgt 20
Stavanger
Hetland
Camilla
Hagabakka 24 Sandnes
INSERT INTO Persons (LastName, Address)

VALUES ('Rasmussen', 'Storgt 67');
LastName
Pettersen
Hetland
Rasmussen
FirstName
Kari
Camilla
Address
Storgt 20
Hagabakka 24
Storgt 67
City
Stavanger
Sandnes
12
Update one Column in a Row

LastName
Nilsen
Rasmussen
FirstName
Fred
Address
Kirkegt 56
Storgt 67
City
Stavanger
We want to add a first name Nina to the person with a last

name of "Rasmussen":
UPDATE Person SET FirstName = 'Nina'
WHERE LastName = 'Rasmussen'
LastName
Nilsen
Rasmussen
FirstName
Fred
Nina
Address
Kirkegt 56
Storgt 67
City
Stavanger
13
Update several Columns in a Row

LastName
FirstName
Address
City
Nilsen
Fred
Kirkegt 56
Stavanger
Rasmussen
Nina
Storgt 67
We want to change the address and add the name of the city:
UPDATE Person
SET Address = 'Stien 12', City = 'Stavanger'
WHERE LastName = 'Rasmussen' ;
LastName
FirstName
Address
City
Nilsen
Fred
Kirkegt 56
Stavanger
Rasmussen
Nina
Stien 12
Stavanger
14
Updates
Example:
UPDATE PRODUCT
SET price = price/2
WHERE Product.name IN
(SELECT product
FROM Purchase
WHERE Date =Oct. 25, 1999);
15
Delete a Row
LastName
FirstName
Address
City
Nilsen
Fred
Kirkegt 56
Stavanger
Rasmussen
Nina
Stien 12
Stavanger
Everyone with last name Rasmussen will be deleted:

DELETE FROM Person
WHERE LastName = 'Rasmussen;
LastName
FirstName
Address
City
Nilsen
Fred
Kirkegt 56
Stavanger
16
Keys and Foreign Keys

Company
Key
CName
StockPrice
Country
GizmoWorks
25
USA
Canon
65
Japan
Hitachi
15
Japan
Product
PName
Price
Category
Manufacturer
Gizmo
$19.99
Gadgets
GizmoWorks
Powergizmo
$29.99
Gadgets
GizmoWorks
SingleTouch
$149.99
Photography
Canon
MultiTouch
$203.99
Household
Hitachi
Foreign
key
17
Joins
Product (pname, price, category, manufacturer)
Company (cname, stockPrice, country)
Find all products under $200 manufactured in Japan;
return their names and prices.
Join
between Product
SELECT PName, Price
and Company
FROM
Product, Company
WHERE Manufacturer=CName AND Country=Japan
AND Price <= 200;
18
Joins
Product
Company
PName
Price
Category
Manufacturer
Cname
StockPrice
Country
Gizmo
$19.99
Gadgets
GizmoWorks
GizmoWorks
25
USA
Powergizmo
$29.99
Gadgets
GizmoWorks
Canon
65
Japan
SingleTouch
$149.99
Photography
Canon
Hitachi
15
Japan
MultiTouch
$203.99
Household
Hitachi
SELECT PName, Price

FROM Product, Company
WHERE Manufacturer=CName AND Country=Japan
AND Price <= 200;
PName
Price
SingleTouch
$149.99
19
Subqueries
Company(name, city)
Product(pname, maker)
Purchase(id, product, buyer)
Return cities where one can find companies that manufacture
products bought by Joe Blow
SELECT Company.city
FROM Company
WHERE Company.name IN
(SELECT Product.maker
FROM Purchase , Product
WHERE Product.pname=Purchase.product
AND Purchase .buyer = Joe Blow);
20
Subqueries
Is it equivalent to this ?
SELECT Company.city
FROM
Company, Product, Purchase
WHERE Company.name= Product.maker
AND Product.pname = Purchase.product
AND Purchase.buyer = Joe Blow;
Beware of duplicates !
21
Removing Duplicates
SELECT DISTINCT Company.city
FROM Company
WHERE Company.name IN
(SELECT Product.maker
FROM Purchase , Product
WHERE Product.pname=Purchase.product
AND Purchase .buyer = Joe Blow);
SELECT DISTINCT Company.city
FROM
Company, Product, Purchase
WHERE Company.name= Product.maker
AND Product.pname = Purchase.product
AND Purchase.buyer = Joe Blow;
Now
they are
equivalent
22
Subqueries
ALL
ANY
EXISTS
Find products that are more expensive than all those produced
By Gizmo-Works
SELECT name
FROM Product
WHERE price > ALL (SELECT price
FROM Purchase
WHERE maker=Gizmo-Works); 23
Correlated Queries
Movie (title, year, director, length)
Find movies whose title appears more than once (in different years).
SELECT DISTINCT title
FROM Movie AS x
WHERE year <> ANY
(SELECT year
FROM Movie
WHERE title = x.title);
correlation
24
Complex Correlated Query

Product ( pname, price, category, maker, year)
Find products (and their manufacturers) that are more expensive
than all products made by the same manufacturer before 1972
SELECT DISTINCT pname, maker
FROM Product AS x
WHERE price > ALL (SELECT price
FROM Product AS y
WHERE x.maker = y.maker AND y.year < 1972);
25
Aggregation
SELECT avg(price)
FROM
Product
WHERE maker=Toyota;
SELECT count(*)
FROM Product
WHERE year > 1995;
SQL supports several aggregation operations:

sum, count, min, max, avg
Except count, all aggregations apply to a single attribute

26
Aggregation: Count
COUNT applies to duplicates, unless otherwise stated:
SELECT Count(category)
FROM Product
WHERE year > 1995;
same as Count(*)
We probably want:
SELECT Count(DISTINCT category)
FROM Product
WHERE year > 1995;
27
More Examples
Purchase(product, date, price, quantity)
SELECT Sum(price * quantity)

FROM
Purchase;

FROM
Purchase
WHERE product = bagel;
28
Purchase
Simple Aggregations
Product
Date
Price
Quantity
Bagel
10/21
20
Banana
10/3
0.5
10
Banana
10/10
10
Bagel
10/25
1.50
20

FROM
Purchase
WHERE product = bagel;
50 (= 20+30)
29
Grouping and Aggregation

Purchase(product, date, price, quantity)
Find total sales after 10/1/2005 per product.
SELECT
FROM
WHERE
GROUP BY
product, Sum(price*quantity) AS TotalSales

Purchase
date > 10/1/2005
product;
Lets see what this means
30
Product
Date
Price
Quantity
Bagel
10/21
20
Bagel
10/25
1.50
20
Banana
10/3
0.5
10
Banana
10/10
10
SELECT
FROM
WHERE
GROUP BY
Product
TotalSales
Bagel
50
Banana
15
product, Sum(price*quantity) AS TotalSales

Purchase
date > 10/1/2005
product;
31
HAVING Clause
SELECT
product, Sum(price * quantity)
FROM
Purchase
WHERE
date > 10/1/2005
GROUP BY product
HAVING
Sum(price * quantity) > 30;
HAVING clause contains conditions on aggregates
(outputs Bagel only).
32
Product ( pname, price, company)

Company( cname, city)
1. Find companies with some product prices 100
SELECT DISTINCT Company.cname
FROM Company
WHERE Company.cname IN (SELECT Product.company
FROM Product
WHERE Product.price >= 100;
2. Find all companies with all their products having prices < 100
SELECT DISTINCT Company.cname
FROM Company
WHERE Company.cname NOT IN (SELECT Product.company
FROM Product
WHERE Produc.price >= 100;
33
Group-by
Author(login, name)
Wrote(login, url)
Mentions(url, word)
Find authors with vocabulary 10000 words:

SELECT
Author.name
FROM
Author, Wrote, Mentions
WHERE
Author.login=Wrote.login AND Wrote.url=Mentions.url
GROUP BY Author.name
HAVING
count(distinct Mentions.word) > 10000;
34
Group-by
Find all authors who wrote at least 10
documents:
SELECT
Author.name
FROM
Author, Wrote
WHERE
Author.login=Wrote.login
GROUP BY Author.name
HAVING
count(wrote.url) > 10;
No need for DISTINCT: automatically from GROUP BY
35
Store(sid, sname)
Product(pid, pname, price, sid)
For each store, find its most expensive product
SELECT Store.sname, x.pname
FROM Store, Product x
WHERE Store.sid = x.sid and
x.price >=
ALL (SELECT y.price
FROM Product y
WHERE Store.sid = y.sid)
GROUP BY Store.sname;
36
NULLS in SQL
Whenever we dont have a value, we can put a NULL
Can mean many things:
Value does not exists
Value exists but is unknown
Value not applicable
Etc.
The schema specifies for each attribute if it can be null
(nullable attribute) or not
How does SQL cope with tables that have NULLs ?
37
Null Values
If x= NULL then 4*(3-x)/7 is still NULL
If x= NULL then (x=Joe) is UNKNOWN
In SQL there are three boolean values:
FALSE
UNKNOWN
TRUE
=
=
=
0
0.5
1
38
Null Values
Unexpected behavior:
SELECT *
FROM Person
WHERE age < 25 OR age >= 25;
Some Persons are not included !
39
Null Values
Can test for NULL explicitly:
x IS NULL
x IS NOT NULL
SELECT *
FROM Person
WHERE age < 25 OR age >= 25 OR age IS NULL ;
Now it includes all Persons
40

Database Management

Uploaded by

Database Management

Uploaded by

EE4791

This Course Has 2 Parts

Lecturer / Tutor: A/P Wang Lipo

Lecturer / Tutor: A/P Tan Hee Beng Kuan

Wang Lipos Contact

Chapter 0 Course Information

Chapter 0 Course Information

Chapter 0 Course Information

Chapter 1 The Database Environment

Information: data processed to become

Figure 1-1a Data Examples

Chapter 1 The Database Environment

Figure 1-1b Processed data - Information

Graphical displays turn data into useful

Descriptions of the properties or characteristics of the

Chapter 1 The Database Environment

Chapter 1 The Database Environment

Chapter 1 The Database Environment

Chapter 1 The Database Environment

Chapter 1 The Database Environment

Disadvantages of File Processing

All programs maintain metadata for each file they use

Chapter 1 The Database Environment

Figure 1-3 Old file processing systems at Pine Valley

Chapter 1 The Database Environment

Problems with Data

Chapter 1 The Database Environment

Chapter 1 The Database Environment

Advantages of the Database Approach

Planned data redundancy

Chapter 1 The Database Environment

Chapter 1 The Database Environment

Why Relational Database?

High cost of changing to another database

Regarding Relational DB Products (1)

Regarding Relational DB Products (2)

Chapter 1 The Database Environment

Regarding Relational DB Products (3)

Chapter 1 The Database Environment

Regarding Relational DB Products (4)

Chapter 1 The Database Environment

Chapter 3 Modeling Data in the Organization

A Good Data Name is:

Chapter 3 Modeling Data in the Organization

Attribute: property or characteristic of an entity type or relationship

Pine Valley Furniture

Figure 2-12 Four tables (Pine Valley Furniture)

Figure 2-12 Four relations (Pine Valley Furniture)

Chapter 3 Modeling Data in the Organization

Figure 3-10 Relationship types and instances

Chapter 3 Modeling Data in the Organization

What Should an Entity Be?

SHOULD NOT BE:

Chapter 3 Modeling Data in the Organization

Figure 3-4 Example

Chapter 3 Modeling Data in the Organization

Chapter 3 Modeling Data in the Organization

Chapter 3 Modeling Data in the Organization

Figure 3-7 A composite attribute

Chapter 3 Modeling Data in the Organization

Figure 3-9 Simple and composite identifier attributes

Chapter 3 Modeling Data in the Organization

Chapter 3 Modeling Data in the Organization

Chapter 3 Modeling Data in the Organization

Degree of relationships (Figure 3-2)

Chapter 3 Modeling Data in the Organization

Figure 3-12 Examples of relationships of different relationship degrees

Chapter 3 Modeling Data in the Organization

Figure 3-12 Examples of relationships of different relationship degrees

Chapter 3 Modeling Data in the Organization

Figure 3-12 Examples of relationships of different relationship degrees

These attributes belong to the relationship Supplies

Figure 3-17 Examples of cardinality constraints

A patient must have recorded

Chapter 3 Modeling Data in the Organization

Figure 3-17 Examples of cardinality constraints (cont.)