CP1500 – Revision Notes

Introduction to Database Systems – Chapter 1

Week 1

Database: A large, integrated collection of data

DBMS: A software package, which manages and stores a database on a computer.

Data: Available but unsorted information  raw facts and figures with no meaning.
Information: Data that has been organized so that it can be understood as having meaning.

Information System Resources: (Smart People Never Do Homework)

 People resources  end users, IS specialists (DB administrators, DBMS vendors, system analysts,
DB designers, application programmers)
 Hardware resources  machines & media
 Software resources  program & procedures
 Data resources  databases (collection of logically related records) & knowledge bases
 Network resources  communications media

Types of Information Systems: (TEEPOID)

 Transaction processing systems (TPS)  record/process data from business transactions.
 Process control systems (PCS)  controls a physical production process (eg: automated assembly
line).
 Office automation systems (OAS)  applications which support (not necessarily automate) typical
office work (eg: word processing, e-mail).
 Expert systems (ES)  use knowledge (programmed) about a specific problem domain to provide
expert advice to decision makers working within that limited domain.
 Information reporting systems (IRS) (MIS)  provide managers with information products, which
support their decision-making requirements.
 Decision support systems (DSS)  provide interactive, computer-based support for decision
making. DSS can assist in a number of ways beyond a simple MIS (eg: providing a problem
solving approach, helping analysis/visualisation of data)
 Executive information systems (EIS)  an MIS targeted at top management – provides
information in a more graphical and summarised form than needed by middle management.

The advantages of using a DBMS: (RUDECD)

 Data independence (data representation and storage concealled)
 Efficient data access
 Data integrity and security (validation rules prevent mistakes and access restrictions exist)
 Uniform data administration (centralised data administration by experts)
 Concurrent access, recovery from crashes (database seemingly accessed by only one person)
 Reduced application development time (eg: quick to create/print reports)

Data Model: a collection of concepts for describing data.

Schema: describes data collection using data model (note: relational data model most common). Every
relation or table has a schema describing each field.
Conceptual (Logical) Schema: defines logical structure (shows entities and attributes)
Physical Schema: describes files and indexes used

note: Many views, single conceptual schema and physical schema.

eg: For a university database:
 Conceptual schema: Students (sid: string, name: string, age: integer)
 Physical schema: index on first column of students

Important Features of DBMS

Logical Data Independence: protected from change in logical structure
Physical Data Independence: protected from change in physical (way data stored) structure
Concurrency Control: interleaving actions of different user programs can lead to inconsistency (eg:
check is cleared while account balance is computed). DBMS ensures such problems don’t arise; instead
database appears to be a single-user system.

1
 CP1500 – Revision Notes

Scheduling Concurrent Transactions & Ensuring Atomicity

Transaction: an atomic sequence of database actions (reads/writes).
 Transaction processing involves a workstation requesting a lock on an object, and if granted the
transaction is processed. Once finished, the lock is released. Meanwhile a log ensures atomicity
(all-or-nothing property). These layers
 After a crash, the effects of partially executed transactions are Query Optimisation must consider
undone using the log. (Thanks to WAL, if log entry wasn’t and Execution concurrency
saved before the crash, corresponding change was not applied control and
Relational Operators recovery
to DB!)
Files and Access Methods
Structure of DBMS
note: A typical DBMS has a layered architecture. The figure does Buffer Management
not show the concurrency control and recovery components. This
Disk Space Management
is one of several possible architectures; each system has its own
variations.

DB Structure of DBMS

The Entity-Relation Ship Model – Chapter 2

Week 3

 Attribute: Field – describes an entity

 Domain: Field datatype – what type of data an attribute represents
 Entity: Tuple – an collection of attributes – a real word object
 Entity set: Table – a collection of similar entities
 Relationship: An association among two or more entities
 Relationship set: A collection of similar relationships

 One-to-one relationship: One occurrence of an entity can associate with only one occurrences of
another entity
 One-to-many relationship: One occurrence of an entity can associate with many occurrences of
another entity
 Many-to-many relationship: Many occurrences of an entity can associate with many occurrences
of another entity

 Participation constraint: An entity must maintain a relationship with another entity

 Overlap constraint: Determines whether two subclasses are allowed to contain the same entity
 Covering constraint: Determine whether the entities in the subclasses collectively include all
entities in the superclass.
 Weak entity set: Is an entity without a primary key – a given entity can only be uniquely identified
through a relationship with anther entity.
 Aggregation: Indicates that a relationship participates in another relationship set
 Role indicator: If an entity set plays more than one role, the role indicator joined with the attribute
name from the entity set gives a unique name for each attribute

name

ssn lot since

name since dname
ssn name
lot did dname
budget
Employees
ssn lot did budget
super- subor- Works_In
Employees Departments
visor dinate
Employees Manages Departments
Reports_To

1-to-1 1-to Many Many-to-1 Many-to-Many

 CP1500 – Revision Notes

ER Model Basics
 A database “schema” in the ER Model can be represented pictorially using an ER diagrams.
Entity: An entity is described (in DB) using a set of attributes
Entity Set: All entities in an entity set have the same set of attributes (unless ISA hierarchy applies)
 Each entity set has a key.
 Each attribute has a domain.

Key Constraints
 Consider Works_In: An employee can work in many departments; a dept can have many employees.
 In contrast, each dept has at most one manager, according to the key constraint on Manages.

Participation Constraints since

name dname
 Does every department have a manager?
ssn lot did budget
 If so, this is a participation constraint: the
participation of Departments in Manages
Employees Manages Departments
is said to be total (as opposed to partial).
  Every did value in Departments
table must appear in a row of the Works_In
Manages table (with a non-null ssn
value!)
since
Weak Entities
 A weak entity can be identified uniquely name
only by considering the primary key of ssn lot
cost pname age
another (owner) entity.
 Owner entity set and weak entity set
must participate in a one-to-many Employees Policy Dependents

relationship set (one owner, many weak

entities).
 Weak entity set must have total participation in this identifying relationship set.
name
ssn lot
ISA (‘is a’) Hierarchies
 2 constraint types exist: Employees
 Overlap constraints: Can Joe be an Hourly_Emps as well as a
Contract_Emps entity? (Allowed/disallowed) hourly_wages hours_worked
 Covering constraints: Does every Employees entity have to ISA
contractid
be an Hourly_Emps or a Contract_Emps entity? (Yes/no)
 Reasons for using ISA:
Hourly_Emps Contract_Emps
 To add descriptive attributes specific to a subclass.
 To identify entitities that participate in a relationship.

name
Aggregation ssn lot
 Used when we have to model a relationship involving entity sets
and a relationship set. Employees
 Aggregation: indicates that a relationship participates in another
relationship set.
Monitors until
 Aggregation allows us to treat a relationship set as an entity
set for purposes of participation in (other) relationships.
started_on since
dname
pid pbudget did budget

Projects Sponsors Departments

3
 CP1500 – Revision Notes

Aggregation vs. Ternary Relationship

 Monitors a distinct relationship with a descriptive attribute
 Also, can say that each sponsorship is monitored by at most one employee

Conceptual Design Using the ER Model

 Design choices:
from to
 Should a concept be modeled as an entity or an attribute? name dname
 Should a concept be modeled as an entity or a ssn lot did budget
relationship?
 Identifying relationships: Binary or ternary? Employees Works_In2 Departments
Aggregation?
 Constraints in the ER Model:
name dname
 A lot of data semantics can (and should) be captured. ssn lot did budget
 But some constraints cannot be captured in ER diagrams.
Employees Works_In3 Departments
Entity vs. Attribute
eg: Should Address be an attribute of Employees or an entity Duration to
from
(connected by a relationship)?
 It depends upon the use we want to make of address information, and the semantics of the data:
 If we have several addresses per employee, address must be an entity (since attributes
cannot be set-valued).
 If the structure (city, street, etc.) is important, (eg: we want to retrieve employees in a given
city) then address must be modeled as an entity (since attribute values are atomic).
 Works_In2 does not allow an employee to work in a department for ≥2 periods.
 Similar to the problem of wanting to record several
addresses for an employee: we want to record several since dbudget
name dname
values of the descriptive attributes for each instance of ssn lot did budget
this relationship.
Employees Manages2 Departments

Entity vs. Relationship

 First ER diagram okay if a manager gets a separate name dname
ssn lot did budget
discretionary budget for each dept.
 What if a manager gets a discretionary budget that Employees Manages3 Departments
covers all managed depts?
 Redundancy of dbudget, which is stored for each
dept managed by the manager. since
apptnum Mgr_Appts
dbudget

Binary vs. Ternary Relationships

 If each policy is owned by just one employee: name
 Key constraint on Policies would mean policy can ssn lot pname age
only cover one dependent! Employees Covers Dependents
 What are the additional constraints in the 2nd
diagram? Bad design Policies
 This example illustrated a case when 2 binary
relationships are better than 1 ternary relationship. policyid cost
 An example in the other direction: a ternary relation name pname age
Contracts relates entity sets Parts, Departments and ssn lot
Suppliers, and has descriptive attribute qty. No Dependents
Employees
combination of binary relationships is an adequate
substitute: Purchaser
Beneficiary
 S “can-supply” P, D “needs” P, and D “deals-
with” S does not imply that D has agreed to buy P
from S. Also how do we record qty? Better design Policies

policyid cost
Summary of Conceptual Design
 Conceptual design follows requirements analysis,

4
 CP1500 – Revision Notes

 Yields a high-level description of data to be stored

 ER model popular for conceptual design
 Constructs are expressive, close to the way people think about their applications.
 Basic constructs: entities, relationships, and attributes (of entities and relationships).
 Some additional constructs: weak entities, ISA hierarchies, and aggregation.
 note: There are many variations on ER model.
 Several kinds of integrity constraints can be expressed in the ER model: key constraints (arrow in
direction of many-to-one), participation constraints (thick line for total participation), and
overlap/covering constraints for ISA hierarchies. Some foreign key constraints are also implicit in
the definition of a relationship set.
 Some constraints (notably, functional dependencies) cannot be expressed in the ER model.
 Constraints play an important role in determining the best database design for an enterprise.
 ER design is subjective. There are often many ways to model a given scenario! Analyzing
alternatives can be tricky, especially for a large enterprise. Common choices include:
 Entity vs. attribute, entity vs. relationship, binary or n-ary relationship, whether or not to use
ISA hierarchies, and whether or not to use aggregation.
 Ensuring good database design: resulting relational schema should be analyzed and refined further.
FD information and normalization techniques are especially useful.

Constraints
 Entity Integrity Constraint: states that no primary key value can be null. This is because the primary
key value is used to uniquely identify individual tuples.
 Entity constrains can be violated if the primary key of the new tuple is null.
 Referential Integrity Constraint: specified between two relations and is used to maintain the
consistency among tuples of the two relations.
 Referential integrity can be violated if the value of any foreign key in refers to a tuple that does
not exist in the referenced relation.
 Domain constraints can be violated if an attribute value is given that does not appear in the
corresponding domain.
 Key constraints can be violated if a key value in the new tuple already exists in another tuples in
the same relation.

Types of Sets
 Subset: A set S2 is a subset of another set S1 if every element in S2 is in S1. S1 may have exactly
the same elements as S2.
 Proper Subset: A set S2 is a proper subset of another set S1 if every element in S2 is in S1 and S1
has some elements, which are not in S2.

5
 CP1500 – Revision Notes

Key Information
 Primary Key: A set of attributes that uniquely identify a particular entity (or relationship)
 Candidate Key: The primary key is the key selected by the DBA from among the group of candidate
keys.
 Foreign Key: (a foreign key can refer to its own relation)
 Super key: A set of attributes that properly contains a key.

ER Diagrams to Conceptual Schema

 Each entity set maps to a new table
 Each attribute maps to a new table column
 Each relationship set maps to either new columns or a new table (depending on relationship type)

name
name cost
ssn lot pname age
ssn lot

Employees Employees Policy Dependents

Monitors until
Dependents
pname ssn age
started_on since
dname
pid pbudget did budget

Projects Sponsors Departments

name

ssn lot

Sponsors pid did since

Employees

super-
Monitors ssn pid did until visor
subor-
dinate
Reports_To
Projects pid Started_on pbudget

Departments did dname budget Reports_To

supervisor_ssn subordinate_ssn
Employees ssn name lot

since
since name dname
name dname ssn lot did budget
ssn lot did budget

Works_In2 Departments Employees Works_In Departments

Employees

address Locations capacity

Works_In

ssn did since

Works_In2 Employees
ssn did address since ssn name lot

6
 CP1500 – Revision Notes

Relational Model – Chapter 3

Week 2

 note: The relational model is the most widely used model. A recent competitor  object-oriented
model & the object-relational model is also starting to emerge.

Relational Database: Definitions

 Relational database: a set of relations sid name login age gpa
 Relation: (note: can think of as a set of rows) made up of 2 parts:
 Instance: a table, with rows and columns. 53666 Jones jones@cs 18 3.4
 Schema: specifies name of relation, plus name and type of 53688 Smith smith@eecs 18 3.2
each column. 53650 Smith smith@math 19 3.8
note: #Rows = cardinality, #fields = degree/arity.

Relational Query Languages (SQL)  Cardinality =3, degree =5, all rows distinct
 A major strength of the relational model: supports simple, powerful querying of data.
 Queries can be written intuitively, and the DBMS is responsible for efficient evaluation.
 The key: precise semantics for relational queries.
 Developed by IBM (system R) in the 1970s
 Need for a standard since it is used by many vendors:
 Standards: SQL-86, SQL-89 (minor revision), SQL-92 (major revision, current standard), SQL-
99 (major extensions)

eg. Find all 18-year-old students: eg. Find A grade enrolled students (multiple
SELECT * query relation):
FROM Student S SELECT S.name, E.cid
WHERE S.age = 18 FROM Student S, Enrolled E
note: renaming for simplification WHERE S.sid = E.sid AND E.grade = ‘A’

Modifying Relations in SQL

eg. Insert single turple: eg. Create table:
INSERT INTO Students (sid, name, age) CREATE TABLE Students
VALUES (53688, ‘Smith’, 18) (sid: CHAR(20); name: CHAR(30); age:
REAL)
eg. Delete single turple: note: they datatype (domain) for each field is
DELETE specified and enforced by DBMS
FROM Students S
WHERE S.name = smith

Integrity Constraints (ICs)

 Integrity Constraint: condition that must be true for any instance of the database (eg: domain
constraints)
 ICs are specified when schema is defined and checked/enforced whenever relations are
modified.
 A legal instance of a relation satisfies all specified ICs.
 Avoids data entry errors, too!
 ICs are based on the semantics of real-world enterprise, being described in the DB relations.
 We can check a database instance to see if an IC is violated, but we can’t infer that an IC is true by
looking at a single instance.

7
 CP1500 – Revision Notes

Primary Key Constraints

 A set of fields is a key for a relation if:
1. No two distinct tuples can have same values in all key fields.
2. This is not true for any subset of the key.
 If part 2 is false  superkey. (ie. {sid} is a key for Students. The set {sid, gpa} is a superkey)
 If there’s more than 1 key for a relation, one of the keys is chosen (by DBA) to be the primary
key.

eg: Students take only one course; further, no two students in the course are given the same grade.
CREATE TABLE Enrolled
(sid: CHAR(20); cid: CHAR (20); grade: CHAR(2)
PRIMARY KEY (sid, cid)
UNIQUE (cid, grade))
note: unique clause illustrates another possibility for key.
Enrolled
Foreign Keys, Referential Integrity sid cid grade Students
 Foreign key: Set of fields in one relation used to 53666 Carnatic101 C sid name login age gpa
‘refer’ to a tuple in another relation (note: must 53666 Reggae203 B 53666 Jones jones@cs 18 3.4
correspond to primary key of the second 53650 Topology112 A 53688 Smith smith@eecs 18 3.2
53650 Smith smith@math 19 3.8
relation). Like a ‘logical pointer’. 53666 History105 B
eg. sid is a foreign key referring to Students:
CREATE TABLE Enrolled
(sid CHAR(20), cid CHAR(20), grade CHAR(2),
PRIMARY KEY (sid,cid),
FOREIGN KEY (sid) REFERENCES Students)
note: Only students listed in the Students relation should be allowed to enroll for courses.
 If all foreign key constraints are enforced, referential integrity is achieved (ie no dangling
references).

Enforcing Referential Integrity

Consider Students and Enrolled; sid in Enrolled is a foreign key that references Students.
 If an Enrolled tuple with a non-existent student id is inserted?  (Reject it!)
 If a Students tuple is deleted?
 Also delete all Enrolled tuples that refer to it.
 Disallow deletion of a Students tuple that is referred to.
 Set sid in Enrolled tuples that refer to it to a default sid.
 (In SQL, also: Set sid in Enrolled tuples that refer to it to a special value null, denoting
`unknown’ or `inapplicable’.)
note: similar if primary key of Students tuple is updated.

Referential Integrity in SQL/92

 SQL/92 supports all 4 options on deletes and updates.
 Default is NO ACTION (delete/update is rejected)
 CASCADE (also delete all tuples that refer to deleted tuple)
 SET NULL / SET DEFAULT (sets foreign key value of referencing tuple)
eg. CREATE TABLE Enrolled
(sid CHAR(20), cid CHAR(20), grade CHAR(2),
PRIMARY KEY (sid,cid),
FOREIGN KEY (sid)
REFERENCES Students
ON DELECTE CASCADE
ON UPDATE SET DEFAULT)

8
 CP1500 – Revision Notes

Views
 A view is just a relation, but we store a definition, rather than a set of tuples. (note: views can be
dropped using DROP VIEW command)
eg. CREATE VIEW YoungActiveStudent (name,grade)
AS SELECT S.name, E.grade
FROM Student S, Enrolled E
WHERE S.sid=E.sid and S.age<21
note: Views can be used to present necessary information (a summary), while hiding details in
underlying relation.

Review of tables and equivalent SQL  see chapter 3

Relational Model: Summary

 A tabular representation of data.
 Simple and intuitive, currently the most widely used.
 Integrity constraints can be specified by the DBA, based on application semantics. DBMS checks
for violations.
 Two important ICs: primary and foreign keys
 In addition, we always have domain constraints.
 Powerful and natural query languages exist.
 Rules to translate ER to relational model

9
 CP1500 – Revision Notes

Relational Algebra – Chapter 4

Week 2

Relational Query Languages

 Query languages: Allow manipulation and retrieval of data from a database.
 Relational model supports simple, powerful QLs:
 Strong formal foundation based on logic.
 Allows for much optimization.
 Query Languages are not programming languages!
 QLs not intended to be used for complex calculations.
 QLs support easy, efficient access to large data sets.
Formal Relational Query Languages
Two mathematical QLs form the basis for “real” languages (eg. SQL), and for implementation:
1. Relational Algebra: More operational, very useful for representing execution plans.
2. Relational Calculus: Lets users describe what they want, rather than how to compute it. (Non-
operational, declarative.)

Preliminaries R1 sid bid day

 A query is applied to relation instances, and the result of a query is also a 22 101 10/10/96
relation instance. 58 103 11/12/96
 Schemas of input relations for a query are fixed (but query will run
regardless of instance!) S1 sid sname rating age
 The schema for the result of a given query is also fixed! Determined by 22 dustin 7 45.0
definition of query language constructs. 31 lubber 8 55.5
 Positional vs. named-field notation (note: both used in SQL): 58 rusty 10 35.0
 Positional notation easier for formal definitions, named-field notation
more readable. S2 sid sname rating age
28 yuppy 9 35.0
Relational Algebra 31R1 lubber
sid bid 8 day
55.5
 Basic operations: 44 guppy 5 35.0
22 101 10/10/96
 Selection () Selects a subset of rows from relation. 58 rusty 10 35.0
58 103 11/12/96
 Projection (π) Deletes unwanted columns from relation.
 Cross-product (X) Allows us to combine two relations. S1 sid sname rating age
 Set-difference (–) Tuples in reln. 1, but not in reln. 2. 22 dustin 7 45.0
 Union () Tuples in reln. 1 and in reln. 2. 31 lubber 8 55.5
 Additional operations: 58 rusty 10 35.0
 Intersection (), join (), division, renaming  useful, not essential.
 Since each operation returns a relation, operations can be composed! S2 sid sname rating age
(Algebra is “closed”.) 28 yuppy 9 35.0
31 lubber 8 55.5
Projection 44 guppy 5 35.0
 Deletes attributes that are not in projection list. 58 rusty 10 35.0
 Schema of result contains exactly the fields in the projection list, with the age
same names that they had in the (only) input relation. (note: duplicates are eliminated)
35.0
55.5
Selection
 Selects rows that satisfy selection condition. (note: duplicates are eliminated)  age(S2)
 Schema of result identical to schema of (only) input relation. sname rating
 Result relation can be the input for another relational algebra operation yuppy 9
(operator composition). rusty 10

 sname,rating( rating 8(S2))

10
 CP1500 – Revision Notes

sid sname rating age

Union, Intersection, Set-Difference 22 dustin 7 45.0
 All these operations take two input relations  must be union-compatible: 31 lubber 8 55.5
58 rusty 10 35.0
 Same number of fields. 44 guppy 5 35.0
 ‘Corresponding’ fields have the same data type. 28 yuppy 9 35.0
S1S2
Cross-Product sid sname rating age
 Each row of S1 is paired with each row of R1. 31 lubber 8 55.5
 Result schema has one field per field of S1 and R1, with field names `inherited’ 58 rusty 10 35.0
if possible. S1S2
note: Both S1 and R1 have a field called sid  conflict sid sname rating age
(sid) sname rating age (sid) bid day 22 dustin 7 45.0

22 dustin 7 45.0 22 101 10/ 10/ 96 S1 S2

22 dustin 7 45.0 58 103 11/ 12/ 96
31 lubber 8 55.5 22 101 10/ 10/ 96
31 lubber 8 55.5 58 103 11/ 12/ 96 R1 sid bid day
58 rusty 10 35.0 22 101 10/ 10/ 96 22 101 10/10/96
58 rusty 10 35.0 58 103 11/ 12/ 96 58 103 11/12/96

 (C(1 sid1, 5  sid 2), S1R1) S1 sid sname rating age

22 dustin 7 45.0
31 lubber 8 55.5
Joins 58 rusty 10 35.0
(sid) sname rating age (sid) bid day
22 dustin 7 45.0 58 103 11/ 12/ 96 S2 sid sname rating age
31 lubber 8 55.5 58 103 11/ 12/ 96 28 yuppy 9 35.0
31 lubber 8 55.5
S1  R1
S1. sid  R1. sid 44 guppy 5 35.0
58 rusty 10 35.0
 Condition Join: (eg: RcS = c (RxS))
 Result schema same as that of cross-product.
 Fewer tuples than cross-product, might be able to compute more efficiently
 Sometimes called a theta-join.
 Equi-Join: A special case of condition join where the condition c contains only equalities.
sid sname rating age bid day
22 dustin 7 45.0 101 10/ 10/ 96
58 rusty 10 35.0 103 11/ 12/ 96
S1  R1
sid
 Result schema similar to cross-product, but only one copy of fields for which equality is specified.
 Natural Join: Equi-join on all common fields.

Division
 Not supported as a primitive operator, but useful for sno pno p n o pno pno
expressing certain queries (eg. Find sailors who have reserved s1 p1 p 2 p2 p1
s1 p2 p4 p2
all boats) B1
s1 p3 p4
 Let A have 2 fields, x and y; B have only field y: B2
s1 p4
 ie. A/B contains all x tuples (sailors) such that for every y s2 p1 sno B3
tuple (boat) in B, there is an xy tuple in A. s2 p2 s1
 Or: If the set of y values (boats) associated with an x s3 p2 s2 sno
s4 p2 s3 s1 sno
value (sailor) in A contains all y values in B, the x value is
s4 p4 s4 s4 s1
in A/B.
 In general, x and y can be any lists of fields; y is the list of A A/B1 A/B2 A/B3
fields in B, and x y is the list of fields of A.
 Division is not essential operator; just a useful shorthand (also true of joins, but joins are so
common that systems implement joins specially)
 idea: For A/B, compute all x values that are not `disqualified’ by some y value in B.
 x value is disqualified if by attaching y value from B, we obtain an xy tuple that is not in A.

11
 CP1500 – Revision Notes

Query Examples
eg. Find names of sailors who’ve reserved boat #103
 1: π sname (( bid=103 Reserves)  Sailors)
 2: π sname ( bid=103 (Reserves  Sailors))

eg. Find names of sailors who’ve reserved a red boat

note: Information about boat color only available in Boats; so need an extra join:
 1: π sname { π sid ({π bid  color=‘red’ Boats}  Reserves)  Sailors)}

eg. Find sailors who’ve reserved a red or a green boat

note: can identify all red or green boats, then find sailors who’ve reserved one of these boats:
p (Tempboats, color=‘red’ v color = ‘green’ Boats)
π sname (Tempboats  Reserves  Sailors)

eg. Find sailors who’ve reserved a red and a green boat

note: Previous approach won’t work! Must identify sailors who’ve reserved red boats, sailors who’ve
reserved green boats, then find the intersection:
 1: p (Temp_red, π sid (( color=‘red’ Boats)  Reserves)
p (Temp_green, π sid (( color=‘green’ Boats)  Reserves)
π sname ((Temp_red  Temp_green)  Sailors)

eg. Find the names of sailors who’ve reserved all ‘interlake’ boats
note: Uses division; schemas of the input relations to must be carefully chosen:
 1: p (Temp_sids, (π sid,bid Reserves) / (π bid (π btype=’interlake’ Boats))
π sname (Temp_sids  Sailors)

Summary
 The relational model has rigorously defined query languages that are simple and powerful.
 Relational algebra is more operational; useful as internal representation for query evaluation plans.
 Several ways of expressing a given query; a query optimizer should choose the most efficient
version.

12
 CP1500 – Revision Notes

SQL: Queries, Programming, Triggers – Chapter 5

Week 3

Basic SQL Query SELECT [DISTINCT] target-list

 Target-list: A list of attributes (fields) of relations in relation-list FROM relation-list
 Relation-list: A list of relation names possibly with a range-variable WHERE qualification
(field abbreviated as letter) after each name.
 Qualification: Comparisons (Attr op const or Attr1 op Attr2, where op is
one of (<, >, ≤, ≥, =, ) combined using (AND, OR and NOT). R1 sid bid day
DISTINCT  optional keyword indicating no duplicates. By default 22 101 10/10/96
duplicates are not eliminated! 58 103 11/12/96

Conceptual Evaluation Strategy S1 sid sname rating age

 Semantics of an SQL query are defined in terms of the following conceptual 22 dustin 7 45.0
evaluation strategy: 31 lubber 8 55.5
 Compute the cross-product of relation-list. 58 rusty 10 35.0
 Discard resulting tuples if they fail qualifications.
 Delete attributes that are not in target-list. S2 sid sname rating age
note: This strategy is probably the least efficient way to compute a query! An 28 yuppy 9 35.0
optimizer will find more efficient strategies to compute the same answers. 31 lubber 8 55.5
44 guppy 5 35.0
58 rusty 10 35.0
Expressions and Strings
AS and =  two ways to name/rename fields in results.
LIKE  used for string matching. ‘_’ stands for any one character. ‘%’ for ≥0 characters.
eg. SELECT S.sname, S.age AS yearsold
FROM Sailors S
WHERE S.sname LIKE “Mc_%”

UNION  used to compute the union of any two union-compatible sets of tuples (from SQL queries).
eg. Find sid’s of sailors who’ve reserved a red or a green boat
1: 2:
(SELECT S.sid SELECT S.sid
FROM Sailors S, Boats B, Reserves R FROM Sailors S, Boats B, Reserves R
WHERE S.sid=R.sid AND R.bid=B.bid AND WHERE S.sid=R.sid AND R.bid=B.bid
B.color=‘red’) AND (B.color=‘red’ OR
UNION B.color=‘green’)
(
SELECT S.sid
FROM Sailors S, Boats B, Reserves R
WHERE S.sid=R.sid AND R.bid=B.bid AND
B.color=‘green’)

INTERSECT: Can be used to compute the intersection of any two union-compatible sets of tuples.
Included in the SQL/92 standard, but some systems don’t support it.
Contrast symmetry of the UNION and INTERSECT queries with how much the other versions differ.
eg. Find sid’s of sailors who’ve reserved a red and a green boat
1: 2:
SELECT S.sid SELECT S.sid
FROM Sailors S, Boats B, Reserves R FROM Sailors S, Boats B1, Reserves R1,
WHERE S.sid=R.sid AND R.bid=B.bid Boats B2, Reserves R2
AND B.color=‘red’ WHERE S.sid=R1.sid AND R1.bid=B1.bid
INTERSECT AND S.sid=R2.sid AND R2.bid=B2.bid
SELECT S.sid AND (B1.color=‘red’ AND B2.color=‘green’)
FROM Sailors S, Boats B, Reserves R
WHERE S.sid=R.sid AND R.bid=B.bid
note: Also possible using IN

13
 CP1500 – Revision Notes

eg: SELECT Tagnum, Comp_Id

FROM PC
WHERE EXISTS
(SELECT *
FROM Software S
WHERE PC.Tagnum = S.Tagnum AND Pack_Id = ‘A205’)
Nested Queries
 Powerful SQL feature: WHERE, FROM and HAVING clauses can contain their own queries.
 To understand semantics of nested queries, think of a nested loops evaluation (eg. For each sailors
tuple, check the qualification by computing the subquery).
eg. Find sailors who haven’t reserved #103. eg: Find name and age of the oldest sailor(s)
SELECT S.sname SELECT S.sname, S.age
FROM Sailors S FROM Sailors S
WHERE S.sid NOT IN (SELECT R.sid WHERE S.age = (SELECT MAX (S2.age)
FROM Reserves R FROM Sailors S2)
WHERE R.bid=103)

Nested Queries with Correlation

 EXISTS is another set comparison operator, like IN.
 If UNIQUE is used, and * is replaced by R.bid, finds sailors with at most one reservation for boat
#103. (UNIQUE checks for duplicate tuples; * denotes all attributes. Why do we have to replace *
by R.bid?)
 Illustrates why, in general, subquery must be re-computed for each Sailors tuple.
More on Set-Comparison Operators
 We’ve already seen IN, EXISTS and UNIQUE. Can also use NOT IN, NOT EXISTS and NOT
UNIQUE.
 Also available: op ANY, op ALL, op IN
eg: Find sailors whose rating is better than that anyone with surname ‘Lucas’:
SELECT *
FROM Sailors S
WHERE S.rating > ANY (SELECT S2.rating
FROM Sailors S2
WHERE S2.sname=‘Lucas’)

note: INTERSECT queries  rewritten using IN.

note: EXCEPT queries re-written using NOT IN.

Division in SQL
eg. Find sailor’s who have reserved all boats
SELECT S.sname
FROM Sailors S
WHERE NOT EXISTS ((SELECT B.bid
FROM Boats B)
EXCEPT
(SELECT R.bid
FROM Reserves R
WHERE R.sid=S.sid))

Aggregate Operators
 Significant extension of relational algebra.
COUNT (*)
COUNT ( [DISTINCT] A)
SUM ( [DISTINCT] A)
AVG ( [DISTINCT] A)
MAX (A)
MIN (A)

14
 CP1500 – Revision Notes

SELECT [DISTINCT] target-list

GROUP BY and HAVING FROM relation-list
 So far, we’ve applied aggregate operators to all (qualifying) tuples. WHERE qualification
Sometimes, we want to apply them to each of several groups of tuples. GROUP BY grouping-list
 A group is a set of tuples that have the same value for all attributes in the HAVING group-qualification
grouping-list.
eg: Find the maximum student percentile for each year with ≥10 students with ≥90 percentiles.
SELECT S.year, MAX (S.percentile)=highest
FROM Students S
WHERE S.percentile >=90
GROUP BY S.year
HAVING COUNT (*) >=10
note: The target-list contains attribute names and terms with aggregate operations (eg: MIN (S.age)).
 The attribute list must be a subset of grouping-list. Intuitively, each answer tuple corresponds
to a group, and these attributes must have a single value per group.

Conceptual Evaluation
 The cross-product of relation-list is computed, tuples that fail qualification are discarded,
‘unnecessary’ fields are deleted, and the remaining tuples are partitioned into groups by the value of
attributes in grouping-list.
 The group-qualification is then applied to eliminate some groups. (note: Expressions in group-
qualification must have a single value per group)
 In effect, an attribute in group-qualification that is not an argument of an aggregate op also
appears in grouping-list. (SQL does not exploit primary key semantics here!)
 One answer tuple is generated per qualifying group.

eg: For each red boat, find the number of reservations

SELECT B.bid, COUNT (*) AS no_reservations
FROM Sailors S, Boats B, Reserves R
WHERE S.sid=R.sid AND R.bid=B.bid AND B.color=‘red’
GROUP BY B.bid
eg: Find those ratings for which the average age is the minimum over all ratings
SELECT Temp.rating, Temp.avg_age
FROM (SELECT S.rating, AVG (S.age) AS avg_age
FROM Sailors S
GROUP BY S.rating) AS Temp
WHERE Temp.avg_age = (SELECT MIN (Temp.avg_age)
FROM Temp)
Null Values
 Field values in a tuple are sometimes unknown (eg: a rating has not been assigned) or inapplicable
(eg: no spouse’s name).
 SQL provides a special value IS NULL for such situations.
 The presence of null complicates many issues  special operators needed to check if value is null.
note: Is rating>8 true or false if rating = null?  A 3-valued logic (true, false and unknown) is
needed. AND, OR and NOT connectives can be used.
note: Meaning of constructs must be defined carefully (eg: WHERE clause eliminates rows ≠ true).
New operators (in particular, outer joins) possible/needed.

Embedded SQL
 SQL commands can be called from within a host language (eg: C or COBOL) program.
 SQL statements can refer to host variables (including special variables used to return status).
 Must include a statement to connect to the right database.
 SQL relations are (multi-) sets of records, with no a priori bound on the number of records. No
such data structure in C.
 SQL supports a mechanism called a cursor to handle this.

15
 CP1500 – Revision Notes

Cursors
 Can declare a cursor on a relation or query statement (which generates a relation).
 Can open a cursor, and repeatedly fetch a tuple then move the cursor, until all tuples have been
retrieved.
 Can use a special clause, called ORDER BY, in queries that are accessed through a cursor, to
control tuple order. (note: fields in ORDER BY clause must appear in SELECT clause)
 The ORDER BY clause, which orders answer tuples, is only allowed in the context of a cursor.
 Can also modify/delete tuple pointed to by a cursor.
eg: Cursor that gets names of sailors who’ve reserved a red boat, in alphabetical order
EXEC SQL DECLARE sinfo CURSOR FOR
SELECT S.sname
FROM Sailors S, Boats B, Reserves R
WHERE S.sid=R.sid AND R.bid=B.bid AND B.color=‘red’
ORDER BY S.sname DESC

Integrity Constraints (Review)

 An IC describes conditions that every legal instance of a relation must satisfy.
 Inserts/deletes/updates that violate IC’s are disallowed.
 Ensure application semantics (eg: sid is a key), or prevent inconsistencies (eg: s.name  string,
age  < 200)
Types of IC’s: Domain constraints, primary key constraints, foreign key constraints, general
constraints.
 Domain constraints: Field values must be of right type. Always enforced.

General Constraints
 Useful when more general ICs than keys are involved.
 Can use queries to express constraint.
note: Constraints can be named.
eg: CREATE TABLE Reserves eg: CREATE TABLE Sailors
( sname CHAR(10), ( sid INTEGER,
bid INTEGER, sname CHAR(10),
day DATE, rating INTEGER,
PRIMARY KEY (bid,day), age REAL,
CONSTRAINT noInterlakeRes PRIMARY KEY (sid),
CHECK (`Interlake’ <> CONSTRAINT ratingValue
( SELECT B.bname CHECK ( rating >= 1
FROM Boats B AND rating <= 10 )
WHERE B.bid=bid)))
Constraints Over Multiple Relations
eg: Number of boats + sailors <100
CREATE TABLE Sailors
( sid INTEGER,
sname CHAR(10),
rating INTEGER,
age REAL,
PRIMARY KEY (sid),
CREATE ASSERTION smallClub
CHECK
( (SELECT COUNT (S.sid) FROM Sailors S)
+ (SELECT COUNT (B.bid) FROM Boats B) < 100 )
note: If Sailors is empty, the number of Boats tuples can be anything!  ASSERTION is the right
solution; not associated with either table.
Triggers
 Trigger: procedure that starts automatically if specified changes occur to the DBMS. Three parts:
 Event (activates the trigger)
 Condition (tests whether the triggers should run)
 Action (what happens if the trigger runs)

16
 CP1500 – Revision Notes

eg:
CREATE TRIGGER youngSailorUpdate
AFTER INSERT ON SAILORS
REFERENCING NEW TABLE NewSailors
FOR EACH STATEMENT
INSERT
INTO YoungSailors(sid, name, age, rating)
SELECT sid, name, age, rating
FROM NewSailors N
WHERE N.age <= 18

Summary
 SQL was an important factor in the early acceptance of the relational model; more natural than
earlier, procedural query languages.
 Relationally complete; in fact, significantly more expressive power than relational algebra.
 Even queries that can be expressed in RA can often be expressed more naturally in SQL.
 Many alternative ways to write a query; optimizer should look for most efficient evaluation plan.
 In practice, users need to be aware of how queries are optimized and evaluated for best results.
 NULL for unknown field values brings many complications
 Embedded SQL allows execution within a host language; cursor mechanism allows retrieval of one
record at a time
 APIs such as ODBC and ODBC introduce a layer of abstraction between application and DBMS
 SQL allows specification of rich integrity constraints
 Triggers respond to changes in the database

17
 CP1500 – Revision Notes

Schema Refinement and Normal Forms – Chapter 15

Week 1

Normalized: Is done to minimize redundancy and minimize the insertion, deletion and update in a
database.

First Normal Form (1NF): All values are atomic. All attributes of a relation must contain only one
value per tuple.
Second Normal Form (2NF): All non-key attributes must be fully functionally dependant on the
primary key.
Third Normal Form (3NF): There must be no transitive dependencies between non-key-attributes.
Boyce-Codd Normal Form (BCNF): All keys must be determinants.

Functional Dependency: is a many-to-one relationship from one set of attributes to another

(eg: Student_number  Student_name. Student_name is functionally dependency on
Student_number).

The Evils of Redundancy

 Redundancy is at the root of several problems associated with relational schemas:
 Redundant storage, insert/delete/update anomalies
 Integrity constraints, in particular functional dependencies, can be used to identify schemas with
such problems and to suggest refinements.
 Main refinement technique: decomposition (replacing ABCD with, say, AB and BCD, or ACD and
ABD).
 Decomposition should be used wisely:
 Is there reason to decompose a relation? note:
 What problems (if any) does the decomposition cause?  Determinant  Dependant
 XY
Functional Dependencies (FDs)  X is functionally dependant on Y
 A functional dependency X  Y holds over relation R if, for every  X determines Y
allowable instance r of R:
 t1 Є r, t2 Є r, X (t1) = X (t2) implies Y (t1) =Y (t2)
 ie: given two tuples in r, if the X values agree, then the Y values must also agree. (X and Y are
sets of attributes.)
 An FD is a statement about all allowable relations.
 Must be identified based on semantics of application.
 Given some allowable instance r1 of R, we can check if it violates some FD f, but we cannot tell
if f holds over R!
 K is a candidate key for R means that K  R
 However, K  R does not require K to be minimal!

Example: Constraints on Entity Set

 Consider relation obtained from Hourly_Emps:
 Hourly_Emps (ssn, name, lot, rating, hrly_wages, hrs_worked)
 Notation: We will denote this relation schema by listing the attributes: SNLRWH
 This is really the set of attributes {S,N,L,R,W,H}.
 Sometimes, we will refer to all attributes of a relation by using the relation name. (eg:
Hourly_Emps for SNLRWH)
 Some FDs on Hourly_Emps:
 ssn is the key: S  SNLRWH
 rating determines hrly_wages: R  W
 Problems due to R  W:
 Update anomaly: Can we change W in just the 1st tuple of SNLRWH?
 Insertion anomaly: What if we want to insert an employee and don’t know the hourly wage for
his rating?

18
 CP1500 – Revision Notes

 Deletion anomaly: If we delete all employees with rating 5, we lose the information about the
wage for rating 5!
Before:
since
Refining an ER Diagram name dname
ssn lot did budget
 1st diagram translated: Workers(S,N,L,D,S) Departments(D,M,B)
 Lots associated with workers. Employees Works_In Departments
 Suppose all workers in a dept are assigned the same lot: D  L
 Redundancy; fixed by: Workers2(S,N,D,S) Dept_Lots(D,L)
 Can fine-tune this: Workers2(S,N,D,S) Departments(D,M,B,L)
After:
budget
since
name dname
ssn did lot

Employees Works_In Departments

19
 CP1500 – Revision Notes

Reasoning About FDs

 Given some FDs, we can usually infer additional FDs:
 ssn  did, did  lot implies ssn  lot
 An FD f is implied by a set of FDs F if f holds whenever all FDs in F hold.
 F+ = closure of F is the set of all FDs that are implied by F.
 Armstrong’s Axioms (X, Y, Z are sets of attributes):
 Reflexivity: If X ⊆ Y, then X  Y
 Augmentation: If X  Y, then XZ  YZ for any Z
 Transitivity: If X  Y and Y  Z, then X  Z
 These are sound and complete inference rules for FDs!

 Couple of additional rules (that follow from AA):

 Union: If X  Y and X  Z, then X  YZ
 Decomposition: If X  YZ, then X  Y and X  Z

eg: Contracts (cid, sid, jid, did, pid, qty, value), and:
 C is the key: C  CSJDPQV
 Project purchases each part using single contract: JP  C
 Dept purchases at most one part from a supplier: SD  P
 JP  C, C  CSJDPQV imply JP  CSJDPQV (transitivity)
 SD  P implies SDJ  JP (augmentation)
 SDJ  JP, JP  CSJDPQV imply SDJ  CSJDPQV (transitivity)

 Computing the closure of a set of FDs can be expensive. (Size of closure is exponential in # attrs!)
 Typically, we just want to check if a given FD (X  Y) is in the closure of a set of FDs F. An
efficient check:
 Compute attribute closure of X (denoted X+) write F:
 Set of all attributes A such that X  A is in F+
 There is a linear time algorithm to compute this.
 Check if Y is in
 Does F = {A  B, B  C, C D  E } imply A  E?
 ie: is A  E in the closure F+ ? Equivalently, is E in A+?

Normal Forms
 Returning to the issue of schema refinement, the first question to ask is whether any refinement is
needed!
 If a relation is in a certain normal form (BCNF, 3NF etc.), it is known that certain kinds of problems
are avoided/minimized. This can be used to help us decide whether decomposing the relation will
help.
 Role of FDs in detecting redundancy:
 Consider a relation R with 3 attributes, ABC.
 No FDs hold: There is no redundancy here.
 Given A  B: Several tuples could have the same A value, and if so, they’ll all have the
same B value!

Boyce-Codd Normal Form (BCNF) X Y A

 Reln R with FDs F is in BCNF if, for all X  A in F +
x y1 a
 A Є X (called a trivial FD), or
x y2 ?
 X contains a key for R.
 In other words, R is in BCNF if the only non-trivial FDs that hold over R are key
constraints.
 No dependency in R that can be predicted using FDs alone.
 If we are shown two tuples that agree upon the X value, we cannot infer the A value in one tuple
from the A value in the other.
 If example relation is in BCNF, the 2 tuples must be identical (since X is a key).

20
 CP1500 – Revision Notes

Third Normal Form (3NF)

 Reln R with FDs F is in 3NF if, for all X A in F+
 A Є X (called a trivial FD), or
 X contains a key for R, or
 A is part of some key for R.
 Minimality of a key is crucial in third condition above!
 If R is in BCNF, obviously in 3NF.
 If R is in 3NF, some redundancy is possible. It is a compromise, used when BCNF not achievable
(eg: no “good” decomp, or performance considerations).
 Lossless-join, dependency-preserving decomposition of R into a collection of 3NF relations
always possible.

What Does 3NF Achieve?

 If 3NF violated by X  A, one of the following holds:
 X is a subset of some key K
 We store (X, A) pairs redundantly.
 X is not a proper subset of any key.
 There is a chain of FDs K  X  A, which means that we cannot associate an X value
with a K value unless we also associate an A value with an X value.
 But: even if reln is in 3NF, these problems could arise.
 e.g., Reserves SBDC, S  C, C  S is in 3NF, but for each reservation of sailor S, same
(S, C) pair is stored.
 Thus, 3NF is indeed a compromise relative to BCNF.

Decomposition of a Relation Scheme

 Suppose that relation R contains attributes A1 ... An. A decomposition of R consists of replacing R
by two or more relations such that:
 Each new relation scheme contains a subset of the attributes of R (and no attributes that do not
appear in R), and
 Every attribute of R appears as an attribute of one of the new relations.
 Intuitively, decomposing R means we will store instances of the relation schemes produced by the
decomposition, instead of instances of R.
 eg: Can decompose SNLRWH into SNLRH and RW.

Example Decomposition
 Decompositions should be used only when needed.
 SNLRWH has FDs S  SNLRWH and R  W
 Second FD causes violation of 3NF; W values repeatedly associated with R values. Easiest way
to fix this is to create a relation RW to store these associations, and remove W from the main
schema:
 ie: we decompose SNLRWH into SNLRH and RW
 The information to be stored consists of SNLRWH tuples. If we just store the projections of these
tuples onto SNLRH and RW, are there any potential problems that we should be aware of?

Problems with Decompositions

 There are three potential problems to consider:
1. Some queries become more expensive.
 eg: How much did sailor Joe earn? (salary = W*H)
2. Given instances of the decomposed relations, we may not be able to reconstruct the corresponding
instance of the original relation!
 Fortunately, not in the SNLRWH example.
3. Checking some dependencies may require joining the instances of the decomposed relations.
 Fortunately, not in the SNLRWH example.
 Tradeoff: Must consider these issues vs. redundancy.

21
 CP1500 – Revision Notes

Lossless Join Decompositions

 Decomposition of R into X and Y is lossless-join w.r.t. a set of FDs F if, for every instance r that
satisfies F:
 X (r)  Y (r) = r
 t1 Є r, t2 Є r, X (t1) = (t2) implies Y (t1) (t2)
 It is always true that r ⊆ X (r)  Y (r)
 In general, the other direction does not hold! If it does, the decomposition is lossless-join.
 Definition extended to decomposition into 3 or more relations in a straightforward way.
 It is essential that all decompositions used to deal with redundancy be lossless! (Avoids Problem 2)

More on Lossless Join

 The decomposition of R into X and Y is lossless-join wrt F if and only if the closure of F contains:
 X  Y  X, or
 XYY
 In particular, the decomposition of R into UV and R - V is lossless-join if U  V holds over R.

Dependency Preserving Decomposition

 Consider CSJDPQV, C is key, JP  C and SD  P.
 BCNF decomposition: CSJDQV and SDP
 Problem: Checking JP  C requires a join!
 Dependency preserving decomposition (Intuitive)
 If R is decomposed into X, Y and Z and we enforce the FDs that hold on X, on Y and on Z,
then all FDs that were given hold on R must also hold. (Avoid Problem 3)
 Projection of set of FDs F: If R is decomposed into X, … projection of F onto X (denoted FX)
is the set of FDs U  V in F+ (closure of F) such that U,V are in X.
 Decomposition of R into X and Y is dependency preserving if (FX union FY)+ = F+
 ie: if we consider only dependencies in the closure F + that can be checked in X without
considering Y, and in Y without considering X, these imply all dependencies in F +.
 Important to consider F +, not F, in this definition:
 ABC, A  B, B  C, C  A, decomposed into AB and BC.
 Is this dependency preserving? Is C  A preserved?????
 Dependency preserving does not imply lossless join:
 ABC, A  B, decomposed into AB and BC.
 And vice-versa! (Example?)

Decomposition into BCNF

 Consider relation R with FDs F. If X C  A Y violates BCNF, decompose R into R - Y and XY.
 Repeated application of this idea will give us a collection of relations that are in BCNF; lossless
join decomposition, and guaranteed to terminate.
 eg: CSJDPQV, key C, JP  C, SD  P, J  S
 To deal with SD  P, decompose into SDP, CSJDQV.
 To deal with J  S, decompose CSJDQV into JS and CJDQV
 In general, several dependencies may cause violation of BCNF. The order in which we ``deal
with’’ them could lead to very different sets of relations!

BCNF and Dependency Preservation

 In general, there may not be a dependency preserving decomposition into BCNF.
 eg: CSZ, CS  Z, Z  C
 Can’t decompose while preserving 1st FD; not in BCNF.
 Similarly, decomposition of CSJDQV into SDP, JS and CJDQV is not dependency preserving
(w.r.t. the FDs JP  C, SD  P and J  S).
 However, it is a lossless join decomposition.
 In this case, adding JPC to the collection of relations gives us a dependency preserving
decomposition.
 JPC tuples stored only for checking FD! (Redundancy!)

22
 CP1500 – Revision Notes

Decomposition into 3NF

 Obviously, the algorithm for lossless join decomp into BCNF can be used to obtain a lossless join
decomp into 3NF (typically, can stop earlier).
 To ensure dependency preservation, one idea:
 If X  Y is not preserved, add relation XY.
 Problem is that XY may violate 3NF! eg: consider the addition of CJP to `preserve’ JP C.
What if we also have J  C ?
 Refinement: Instead of the given set of FDs F, use a minimal cover for F.
Minimal Cover for a Set of FDs
 Minimal cover G for a set of FDs F:
 Closure of F = closure of G.
 Right hand side of each FD in G is a single attribute.
 If we modify G by deleting an FD or by deleting attributes from an FD in G, the closure
changes.
 Intuitively, every FD in G is needed, and “as small as possible” in order to get the same closure as
F.
 eg: A  B, ABCD  E, EF  GH, ACDF  EG has the following minimal cover:
 A  B, ACD  E, EF  G and EF  H
 M.C. ® Lossless-Join, Dep. Pres. Decomp!!! (in book)

Summary of Schema Refinement

 If a relation is in BCNF, it is free of redundancies that can be detected using FDs.
 If a relation is not in BCNF, we can try to decompose it into a collection of BCNF relations.
 Must consider whether all FDs are preserved. If a lossless-join, dependency preserving
decomposition into BCNF is not possible (or unsuitable, given typical queries), should
consider decomposition into 3NF.
 Decompositions should be carried out and/or re-examined while keeping performance
requirements in mind.

23