MTE.1

CSE4701

CSE255 Midterm Exam Advice and Hints

Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department

The University of Connecticut191 Auditorium Road, Box U-155

Storrs, CT 06269-3155steve@engr.uconn.edu

http://www.engr.uconn.edu/~steve(860) 486 - 4818

MTE.2

CSE4701

Background Information

SQL and Relational Algebra may involve: Computer Inventory Schema

http://www.engr.uconn.edu/~steve/Cse4701/cse4701inventory.doc

Chinook or Northwind Homework 3 and 4 Solutions Posted by

Thursday’s Class Won’t Take HW 4 late submissions once posted

MTE.3

CSE4701

Core Material

No Questions on … Chapter 1 and 2 Chapter 3: ER Model

Conceptual Database Design Chapter 4: Extended ER Model

Extension with Inheritance and other Features Chapter 7: Relational Model and Algebra Chapter 8: SQL DML Chapter 9: ER to Relational Translation

Detailed Algorithm for Translation Chapter 14: FDs and Normalization

Guidelines for “Good” Design Normal Forms and Normalization Through Slide … (set in class!)

MTE.4

CSE4701

Hints for Taking Exam

Read the Questions Carefully! Ask Questions if you are Confused! Answer Questions in Any Order

Organized to fit on minimum number of pages Answer “Easiest” questions for you!

Assess Points per Time Unit 75 minutes = 75 points 15 points = 15 minutes

For Essay/Short Answer Questions - Length Answer Matches Points 5 points = 1/4 page = 3 or 4 sentences 30 points - if 1/4 page - likely few points!

Exam Designed to be Longer than 75 Minutes!

MTE.5

CSE4701

Hints for Taking Exam

Don't Define Concepts E.G., Ask About Concept X, Don't Explain

Concept X, Just Answer the Question and I'll Know If You Know Concept X

Don't Panic, Read and Review Course Materials Prior to Exam!

Don't Be Afraid to Not Answer a Question 60% Correct for 100 Points = 60 Points 90% Correct F0r 80 Points = 72 Points

Partial Credit Is the Norm If I Ask You to Pick and Analyze a Concept -

for a 5 Pt Problem You Get 1 for the Concept and 4 for the Analysis.

MTE.6

CSE4701

Possible Questions

Open Notes, Book, and Online (Web) 5 Total Questions Possibilities…

Constructive and Algorithm Questions Relational Algebra and SQL Defining Concepts and Understanding Their

Significance Problem Solving

Know your Algorithms and Constructs Show All Work to Receive Partial (Any) Credit Do Not Jump to Final Answer Avoid Run-on Explanations Covered Material - See Remaining Slides!

MTE.7

CSE4701

Chapters 3 and 4: ER and EER

Chapter 3: ER Model Conceptual Database Design Basic ER Concepts 1-1, 1-m, and m-n Relationships

Chapter 4: Extended ER Model Extension with Inheritance Understanding the Differences and their Usage

Disjoint vs. Overlapping Specialization vs. Generalization Constraints: Partial and Disjoint Categories

Focus on Understanding Various ER and EER Concepts and Constructs

MTE.8

CSE4701

Chapters 3 and 4: ER and EER

No Questions on … Min/Max Notation ER Complications

Recursive Relationship Multiple Relationships Between Two Entity Types Participation Constraints (Existence Constraints) Strong and Weak Entities Relationships Among More than two Entity Types Connection Traps Simplification Techniques

MTE.9

CSE4701

Chapter 7: Relational Model and Algebra

Covered Material Definition of a Relation Relation Algebra Including Select, Project,

Join, Theta-Join, Natural Join, Union, Intersection, etc.

Key Concepts (Superkey, Candidate key, etc.) Referential Integrity Equivalence of Various Relational Operations

No Questions … Insert, Delete and Modify Operations on

Relations Semi and Outer Join

MTE.10

CSE4701

Chapter 8: SQL DML ONLY

Covered Material Ability to write SQL DML Statements Basic SELECTS Nested SELECTS SELECTS with EXISTS/NOT EXISTS UNION-Based SELECTS AGGREGATE Operations SET-Oriented SELECTS (IN/NOT IN) ANY RETRIEVE STATEMENT

No Questions on … DDL (CREATES) VIEWS DELETE, UPDATE, INSER OUTER JOIN, LEFT JOIN, etc.

MTE.11

CSE4701

Chapter 9: ER Model to Relational Model

Covered Material Detailed Algorithm for Translation All Eight Steps and Their Application For Step 8, Focus on Different Approaches that

are Utilized to Map Different Type of EER Inheritance

Make sure that you Clearly Understand the Translation Process!

MTE.12

CSE4701

Chapter 14: Functional Dependenciesand Normalization

Covered Topics Include … Four Guidelines for “Good” Design Update Anomalies (Insert, Delete, Modify) Functional Dependencies (FDs)

Single and Multi-Valued Dependencies Ability to Define FDs for a Relational Schema Normal Forms and Normalization 1st, 2nd, and 3rd Normal Forms (no BCNF)

MTE.13

CSE4701

More Detailed Summary/Study Guide

MTE.14

CSE4701

Chapters 3 and 4: ER and EER

Chapter 3: ER Model Conceptual Database Design Basic ER Concepts 1-1, 1-m, and m-n Relationships

Chapter 4: Extended ER Model Extension with Inheritance Understanding the Differences and their Usage

Disjoint vs. Overlapping Specialization vs. Generalization Constraints: Partial and Disjoint Categories

Focus on Understanding Various ER and EER Concepts and Constructs

MTE.15

CSE4701

Chapters 3 and 4: ER and EER

No Questions on … Chapter 1 and 2 Min/Max Notation

(slides 31-33 of cse4701chap3and4.pptx) ER Complications

(slides 45-55 of cse4701chap3and4.pptx) Recursive Relationship Multiple Relationships Between Two Entity Types Participation Constraints (Existence Constraints) Strong and Weak Entities Relationships Among More than two Entity Types Connection Traps Simplification Techniques

MTE.16

CSE4701

Summary of ER-Diagram NotationMeaning

ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE

DERIVED ATTRIBUTE

TOTAL PARTICIPATION OF E2 IN R

CARDINALITY RATIO 1:N FOR E1:E2 IN R

STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION OF E IN R

Symbol

E1 R E2

E1 RN E2

R(min,max)

E

N

MTE.17

CSE4701

Example COMPANY Database (Cont.)

Store Each Employee’s Social Security Number, Address, Salary, Sex, and Birthdate Each Employee Works for One Department but

May Work on Several Projects We Track of the Number of Hours Per Week that an

Employee Currently Works on Each Project We Track of the Direct Supervisor of Each

Employee Each Employee May have a Number of

Dependents For Each Dependent, We Track of their Name, Sex,

Birthdate, and Relationship to Employee

MTE.18

CSE4701

ER Diagram for the Company Database

MTE.19

CSE4701

Enhanced ER Model

Object-Oriented Extensions to E-R Model EER Concepts

Specialization Attribute Inheritance Generalization Subclasses Superclasses Constraints on Specialization and

Generalization Categorization

MTE.20

CSE4701

Enhanced ER Constructs and Notation

MTE.21

CSE4701

Specialization/Attribute Inheritance

An Entity Type E1 is a Specialization of another Entity Type E2 if E1 has the Same Properties of E2 and Perhaps Even More.

E1 IS-A E2

MANAGER

EMPLOYEE

EMPLOYEE

Employee No EmployeeName

Salary

Title Address

MANAGER

Employee No EmployeeName

Salary

Title Address

Expense Act. Condo

MTE.22

CSE4701

Generalization

ENGINEER SECRETARY SALESPERSON

EMPLOYEE

Employee No EmployeeName

Salary

Title Address

Project Office Specialty Office CarRegion

d

MTE.23

CSE4701

Constraints disjoint, total

disjoint, partiald

d

o

o

overlapping, total

overlapping, partial

Part

Manufactured_Part

Purchased_Part

o

PartNo Description

SupplierName ListPrice

BatchNo

M_date

DrawingNo

MTE.24

CSE4701

Total and Partial Disjoint

EMPLOYEE

Employee No EmployeeName

Salary

Title Address

SECRETARYENGINEER

Project Office Specialty Office

SALESPERSON

CarRegion

dd

HOURLY_EMP

SALARIED_EMP

Hourly Rate

Salary

MTE.25

CSE4701

Total Overlapping

PART

Part No PartName

QTY

WGT

o

MANUFACTURED_PART PURCHASED_PART

Batch No Drawing No Price

MTE.26

CSE4701

Categories A Category is a Subclass

of a Union of Two or More Entity Types.

The Concept of Category Superclass

Relationship with Two or More Superclasses

A Category Can Be Total or Partial

PERSON BANK COMPANY

OWNER

u

REG_VEHICLE

CAR TRUCK

u

OWNS

N

M

OWNER and REG_VEHICLE

are both categories

MTE.27

CSE4701

MTE.28

CSE4701

Chapter 7: Relational Model and Algebra

Covered Material Definition of a Relation Relation Algebra Including Select, Project,

Join, Theta-Join, Natural Join, Union, Intersection, etc.

Key Concepts (Superkey, Candidate key, etc.) Referential Integrity Equivalence of Various Relational Operations

No Questions … Insert, Delete and Modify Operations on

Relations Slides 36-43 of cse4701chap7.pptx Semi and Outer Join

Slides 86-89 of cse4701chap7.pptx

MTE.29

CSE4701

STUDENT (s#, sname, email, dept)Domain(s#): Number(9) Domain(sname): Char(30)Domain(email): Char(20) Domain(dept): Char(15)

Basic Concepts - Relation Schema

A Schema of a Relation Denoted as R(A

1:D

1, A

2:D

2 , ..., A

n:D

n)

Set of Attributes That Describe a Relation Denoted by {A

1:D

1, A

2:D

2 , ..., A

n:D

n}, where A

i

(i=1, …, n) is Attribute Name and Di is Domain

Over Which Ai is Defined

Domain The Set of Values From which the Values of an

Attribute Aj are Drawn, Denoted by Domain(Aj) Example

MTE.30

CSE4701

A Relation (Relation Instance) An Occurrence of a Relation Scheme

R( A1:D

1, A

2 :D

2 , ..., A

n :D

n);

Defined as a Subset of the Cartesian Product of the Domains that Define its Schema, Denoted by R(r) = {T1, T2, ..., Tm}

Ti (i=1,…,m) is a Member of the Cartesian Product Domain(A1) Domain(A2) … Domain(An). R is also Called the Intension of a Relation r is also Called the Extension of a Relation

Relation Instances

MTE.31

CSE4701

Relation Instances

ENO ENAME TITLE

E1 J. Doe Elect. Eng.E2 M. Smith Syst. Anal.E3 A. Lee Mech. Eng.E4 J. Miller ProgrammerE5 B. Casey Syst. Anal.E6 L. Chu Elect. Eng.E7 R. Davis Mech. Eng.E8 J. Jones Syst. Anal.

EMP

ENO PNO RESP

E1 P1 Manager 12

DUR

E2 P1 Analyst 24E2 P2 Analyst 6E3 P3 Consultant 10E3 P4 Engineer 48E4 P2 Programmer 18E5 P2 Manager 24E6 P4 Manager 48E7 P3 Engineer 36

E8 P3 Manager 40

WORKS

E7 P5 Engineer 23

PROJ

PNO PNAME BUDGET

P1 Instrumentation 150000

P3 CAD/CAM 250000P2 Database Develop. 135000

P4 Maintenance 310000P5 CAD/CAM 500000

PROJ[PNO] P1P2P3P4P5

EMP[TITLE]

Elect.EngSyst. AnalMech. Eng

Programmer

MTE.32

CSE4701

Key Constraints

Superkey (SK): Any Subset of Attributes Whose Values are

Guaranteed to Distinguish Among Tuples Candidate Key (CK):

A Superkey with a Minimal Set of Attributes (No Attribute Can Be Removed Without Destroying the Uniqueness -- Minimal Identity)

A Value of an Attribute or a Set of Attributes in a Relation That Uniquely Identifies a Tuple

There may be Multiple Candidate Keys

MTE.33

CSE4701

Key Constraints

Primary Key (PK): Choose One From Candidate Keys The Primary Key Attributed are Underlined

Foreign Key (FK): An Attribute or a Combination of Attributes

(Say A) of Relation R1 Which Occurs as the Primary Key of another Relation R2 (Defined on the Same Domain)

Allows Linkages Between Relations that are Tracked and Establish Dependencies

Useful to Capture ER Relationships

MTE.34

CSE4701

A Constraint Involving Two Relations Used to Specify a Relationship Among Tuples in Referencing Relation and Referenced Relation

Definition: R1and R2 have a Referential Integrity

Constraint If Tuples in the Referencing Relation R1 have a Set

of Foreign Key (FK) Attributes That Reference the Primary Key PK of the Referenced Relation R2

A Tuple T1 in R1( A1, A

2 , ..., A

n) is Said to

Reference a Tuple T2 in R2 if $ FK {A1, A

2 , ...,

An} such that T1[fk] = T2[pk]

Referential Integrity Constraints

MTE.35

CSE4701

Examples

ENO ENAME TITLE

E1 J. Doe Elect. Eng.E2 M. Smith Syst. Anal.E3 A. Lee Mech. Eng.E4 J. Miller ProgrammerE5 B. Casey Syst. Anal.E6 L. Chu Elect. Eng.E7 R. Davis Mech. Eng.E8 J. Jones Syst. Anal.

EMPWORKS

PROJ

PNO PNAME BUDGET

P1 Instrumentation 150000

P3 CAD/CAM 250000P2 Database Develop. 135000

P4 Maintenance 310000P5 CAD/CAM 500000

ENO PNO RESP DUR

E1 P1 Manager 12E2 P1 Analyst 24E2 P2 Analyst 6E3 P3 Consultant 10E3 P4 Engineer 48E4 P2 Programmer 18E5 P2 Manager 24E6 P4 Manager 48E7 P3 Engineer 36

E8 P3 Manager 40E7 P5 Engineer 23

E9 P3 Engineer 30

MTE.36

CSE4701

ENO ENAME TITLE

ENO PNO RESP DUR

PNO PNAME BUDGET

WORK

EMP PROJ

WORK[ENO] is a subset of EMP[ENO]

WORK[PNO] is a subset of PROJ[PNO]

Referential Integrity Constraints A Referential Integrity Constraint Can Be Displayed in

a Relational Database Schema as a Directed Arc From R1.FK to R2.PK

MTE.37

CSE4701

Basic Relational Operations: Unary Operations

SELECT s PROJECT or P.

Binary Operations Set operations:

UNION INTERSECTION DIFFERENCE –

CARTESIAN PRODUCT JOIN operations

What is Relational Algebra?

Relational Algebra is a Procedural ParadigmYou Need to Tell What/How to Construct the Result

Consists of a Set of Operators Which, When Applied to Relations, Yield Relations (Closed Algebra)

MTE.38

CSE4701

Relational Algebra

R S unionR S intersectionR \ S set differenceR S Cartesian

product

A1, A2, ..., An (R) projection

F (R) selection

R S natural join

R S theta-joinRS division[A1 B1,.., An Bn] rename

MTE.39

CSE4701

Relational Algebra

Fundamental OperatorsDerivable from the fundamental operators

Selection Projection Union Difference Cartesian Product

Intersection Join, Equi-join, Natural

Join

MTE.40

CSE4701

A Set of Relational Algebra Operations Is Called a Complete Set, If and Only If Any Relational Algebra Operator in the Set Cannot

be Derived in Terms of a Sequence of Others in Set Any Relational Algebra Operator Not in the Set

Can Be Derived in Terms of a Sequence of Only the Operators in the Set

Important Concepts: The Set of Algebra Operations {S ,P , , –, } is a

Complete Set of Relational Algebra Operations

Any Query Language Equivalent to These Five Operations is Called Relationally Complete

All Relational Algebra Operations

MTE.41

CSE4701

Fundamental Operators Selection Projection Union Set Difference Cartesian Product

Relational Algebra: Summary

Form:

<Operator><Operand(s)> Result>

Relation (s) Relation

Additional Operators Join Intersection Quotient (Division)

Union Compatibility Same Degree Corresponding

Attributes Defined Over the Same Domain

MTE.42

CSE4701

Chapter 8: SQL DDL and DML

Covered Material Ability to write SQL DML Statements Basic SELECTS Nested SELECTS SELECTS with EXISTS/NOT EXISTS UNION-Based SELECTS AGGREGATE Operations SET-Oriented SELECTS (IN/NOT IN) ANY RETRIEVE STATEMENT

No Questions on topics in cse4701chap8.pptx … DDL (CREATES) (slides 14-54, 105-107) VIEWS (slides 97-102) DELETE, UPDATE, INSERT (slides 92-96) OUTER JOIN, LEFT JOIN, etc.

MTE.43

CSE4701

Data Manipulation Language - DML

SQL has the SELECT Statement for Retrieving Info. from a Database (Not Relational Algebra Select)

SQL vs. Formal Relational Model SQL Allows a Table (Relation) to have Two or

More Identical Tuples in All Their Attribute Values

Hence, an SQL Table is a Multi-set (Sometimes Called a Bag) of Tuples; it is Not a Set of Tuples

SQL Relations Can Be Constrained to Sets by PRIMARY KEY or UNIQUE Attributes Using the DISTINCT Option in a Query

MTE.44

CSE4701

Interactive DML - Main Components

Select-from-where Statement Contains: Select Clause - Chosen Attributes/Columns From Clause - Involved Tables Where Clause - Constrain Tuple Values Tuple Variables - Distinguish Among Same

Names in Different Tables String Matching - Detailed Matching Including

Exact Starts With Near

Ordering of Rows - Sorting Tuple Results

MTE.45

CSE4701

Interactive DML - Main Components

Select-from-where Statement Contains: Set Operations - Search to See if a Value is in

Set Built-in Functions - Count, Mix, Max, Sum,

Avg Nested Subqueries - Queries within Queries Joins - As Discussed for Relational Algebra Recursive Queries (Defer - Part of SQL3) Modification-Based Selects for

Insert - Create a New Tuple Delete - Remove Existing Tuple(s) Update - Change Existing Tuple(s)

MTE.46

CSE4701

SELECT target-listFROM relation-listWHERE condition or subqueryGROUP BY attribute-listHAVING conditionORDER BY attribute-list

Skeleton Query:

SELECT - relational “project” WHERE - relational “select” and/or “join”

In principle, a SQL query equals to an algebra expression

attributesconditionrelation-list

SQL Data Manipulation

MTE.47

CSE4701

Built-in Aggregate Functions Count (COUNT), Sum (SUM), Average (AVG),

Minimum (MIN), Maximum (MAX) Count Books Ordered on 2/16 SELECT COUNT( *) FROM ORDER WHERE ORDER.DATE = “2/16/2000”; Find the Average Price of Books by each Publisher SELECT PUBLISHER, AVG(PRICE) FROM BOOK GROUP BY PUBLISHER;

MTE.48

CSE4701

Nested Subqueries

Nested Subqueries Allow us to Ask More Complex Questions Regarding the Database Content

Queries are Nested and Involve Set Relationships Relationships Supported Include:

Set Membership: IN, NOT IN Set Comparison

(=, <, <=, >, >=, <>) ALL (=, <, <=, >, >=, <>) SOME

Test Empty Relation: EXISTS, NOT EXISTS Let’s see Some Examples…

MTE.49

CSE4701

Set Membership: IN, NOT IN Find Title of the Books Ordered on Mondays SELECT DISTINCT TITLE FROM BOOK WHERE ISBN IN (SELECT ISBN FROM ORDER WHERE WEEKDAY = “MON”); Find Titles of Books ordered on Wednesday to Friday SELECT DISTINCT ISBN FROM BOOK WHERE WEEKDAY NOT IN (“MON”, “TUE”);

MTE.50

CSE4701

Set Comparison Operators

(=, <, <=, >, >=, <>) ALL (=, <, <=, >, >=, <>) SOME

Find ISBN of Books Published by ACM, which are Cheaper than all Books Ordered by Smith

SELECT ISBN FROM BOOK WHERE PUBLISHER LIKE “%ACM%” AND PRICE < ALL (SELECT B.PRICE FROM BOOK B, ORDER O WHERE CUST_NAME LIKE “%SMITH%” AND B.ISBN = O.ISBN);

MTE.51

CSE4701

EXISTS, NOT EXISTS Find ISBN of Books with a Price so low That There is

not any Cheaper Books from ACM SELECT B.ISBN FROM BOOK B WHERE B.PUBLISHER LIKE “%ACM%” AND NOT EXISTS (SELECT T.ISBN FROM BOOK T WHERE T.PUBLISHER LIKE “%ACM%” AND T.PRICE < B.PRICE);

MTE.52

CSE4701

Chapter 9: ER Model to Relational Model

Covered Material Detailed Algorithm for Translation All Eight Steps and Their Application For Step 8, Focus on Different Approaches that

are Utilized to Map Different Type of EER Inheritance

You are Responsible for All Slides in cse4701chap9.pptx

Make sure that you Clearly Understand the Translation Process!

No Questions on … Does not apply

MTE.53

CSE4701

ER-to-Relational Mapping Algorithm

Step 1: For Each Regular Entity Type E Create a Relation RE Include only the Simple Attributes of a

Composite Attribute Step 2: For Each Weak Entity Type W with Owner

Entity Type E Create a Relation RW Include as Attributes

All Simple Attributes of W Primary Key attribute(s) of the Relation that

Corresponds to W’s Owner Entity Type E

MTE.54

CSE4701

ER-to-Relational Mapping Algorithm

Step 3: For Each 1:1 Relationship Identify the Relations R1 and R2 Include as Foreign Key of one Relation the

Primary Key of the Other Relation Step 4: For each Regular 1:n Relationship

Include as Foreign Key in the Entity Type at the n-side of the Relationship, the Primary Key of the Entity Type at the 1-side of the Relationship

MTE.55

CSE4701

ER-to-Relational Mapping Algorithm

Step 5: For Each Binary n:m Relationship Create a New Relation, whose Attributes

Include All Simple Attributes of the n:m Relationship as

Non-key Attributes PKs of the Relations that Represent the

Participating Entity Types, as FK Attributes in this New Relation

Step 6: For Each Multi-valued Attribute A Create a New Relationship R that Includes

An Attribute Corresponding to A The PK Attribute of the Relation Whose

Corresponding Entity Type or Relationship Has A as an Attribute

MTE.56

CSE4701

ER-to-Relational Mapping Algorithm

Step 7: For Each n-ary Relationship R, n>2 Create a New Relation to Represent R

Step 8: Convert Each Specialization for Superclass C with Attributes {k, A1, …, An} (k is the PK), where C has n Subclasses {S1, ..., Sn} Create a Relation Si for each Subclass Entity

(1<= i <= n) with Attributes Attrs(Si) = {k} {attributes of Si}, and PK{Si} = k

Note that the Relation for C was created in an Earlier Step

Note also that there are Three Other Options for Mapping Specialization Hierarchies

MTE.57

CSE4701

Transformation of EER to ...

EMPLOYEE

PROJECT

Responsibility

Duration

BudgetProjectName

Project No

Employee No

EmployeeName

SalaryTitle

WORKS ON

Address

CityApt. #

Street #

Location

1

N

MANAGES

BALANCEExpenses

1RECORDSACCOUNT

Income

1

DateAmount

SUPPLYSUPPLIER

Supplier No SupplierName

LocationCredit

N M

PART

LPart No

PartName

Weight

Color

CONTAIN

M N

Made-up of Consists of

1

1

QTY

SALESPERSON

Car

Region

SECRETARY

Specialty

Office

ENGINEER

Project

Office

Acount #

d

o

MANUFACTURED_PART PURCHASED_PART

Batch No Drawing No Price

MTE.58

CSE4701

EMPLOYEE(ENO, ENAME, TITLE, SALARY, APT#, STREET, CITY, PJNO, DURATION, RESP)

PROJECT(PJNO,PNAME,BUDGET,MGR)SUPPLIER(SNO,SNAME,CREDIT,LOCATION)PART(PNO, PNAME, WGT, COLOR, MAN, PURC,

BATCH#, DRAWING#, PRICE)

ENGINEER(ENO, PROJECT,OFFICE)SECRETARY(ENO, OFFICE, SPECIALTY)SALESPERSON(ENO, CAR, REGION)SUPPLY(SNO, PJNO, PNO, AMOUNT,DATE) LOC(PJNO, LOCATION) CONTAIN(PNO, CPNO,QTY)ACCOUNT(PJNO, ACNO, INCOME, EXPENSES,

BALANCE)

… Final Set of Relations

MTE.59

CSE4701

Chapter 14: Functional Dependencies

Covered Topics Include … Four Guidelines for “Good” Design Update Anomalies (Insert, Delete, Modify) Functional Dependencies (FDs) Ability to Define FDs for a Relational Schema Normalization 1, 2, 3NF Multi-Valued Dependencies

No Questions on … FD Closure, Equivalence

MTE.60

CSE4701

Guideline 1

GUIDELINE 1: Informally, Each Tuple in a Relation Should Represent One Entity or Relationship Instance (Applies to Individual Relations and their Attributes)

Attributes of Different Entities should not be Mixed in the Same Relation

Only FKs should be used to Refer to Other Entities Entity and Relationship Attributes should be Kept

Apart as Much as Possible Bottom Line:

Design a Schema that can be Explained Easily Relation by Relation

The Semantics of Attributes should be Easy to Interpret

MTE.61

CSE4701

Guideline 2

Guideline 2: Design a Schema that does not Suffer from

Insertion, Deletion and Update Anomalies If There are any Present, then Note them so that

Applications can take them into Account Reasons for Update Anomalies

Dependencies Caused by One Relation used to Represent Two or More Entities/Relationships

Redundancy Caused by Dependencies/Other Factors

Strive for Independence (Double Edged Sword) Eliminates the Anomalies Query Performance May Suffer

(e.g., Always Require Many Joins for Queries)

MTE.62

CSE4701

Redundant Information/Update Anomalies

Mixing Attributes of Multiple Entities (see Prior Two Slides) May Cause Problems

Key Problem: Information is Stored Redundantly There are Two Consequences:

Wasting Storage Problems with Update Anomalies

Insertion Anomalies - Inserting New Tuples Deletion Anomalies - Removing Existing Tuples Modification Anomalies - Changing Existing Tuples

MTE.63

CSE4701

Guideline 3

Guideline 3: Relations should be Designed such that their Tuples will have as Few NULL Values as Possible

Attributes that are NULL Frequently Could Be Placed in Separate Relations (With the Primary Key)

Reasons for Null Values Attribute Not Applicable or Invalid Attribute Value Unkown (May Exist) Value Known to Exist, but Unavailable

MTE.64

CSE4701

Guideline 4

Guideline 4: The Relations should be Designed to Satisfy the

Lossless Join Condition No Spurious Tuples Should Be Generated by

Doing a Natural-join of Any Relations Two Important Properties of Decompositions:

a. Non-additive(Losslessness) of Corresponding Join

b. Preservation of the Functional Dependencies Property (a) is Extremely Important and Cannot

Be Sacrificed Property (b) is Less Stringent and May Be

Sacrificed

MTE.65

CSE4701R = (A, B, C) S = (D, C)

b2b2b4

c1c1c2

A B C

c1c2c2c3

d1d2d4d5

D C

a1a2a3a3

a1a2a3

b2b2b4b4

c1c1c2c2

d1d1d2d4

A B C D

RS(A, B, C, D)

lost info.

Guideline 4: Lost Information

A First Example of Lost Information What is Lost in the Join of R and S?

MTE.66

CSE4701

Guideline 4: Spurious Tuples

A Second Example of Spurious Tuples What are Spurious in the Join of R1and R2?

a1a2a3a4

b1b2b1b2

c1c2c1c2

d1d1d2d3

A B C D

R(A, B, C, D) R1(B, D)

B C

b1b2b1b2

d1d1d2d3

D

d1d1d2d3

A

a1a2a3a4

R2(A, D)

a1a2a1a2a3a4

b1b1b2b2b1b2

c1c2c2c2c1c2

d1d1d1d1d2d3

A B C D

R1 and R2 Join

MTE.67

CSE4701

Functional Dependencies (FDs)

FDs are used to Specify Formal Measures of the "Goodness" of Relational Designs

FDs and Keys are used to Define Normal Forms for Relations

FDs are Constraints that are Derived from the Meaning and Interrelationships of the Data Attributes

A Set of Attributes X Functionally Determines a Set of Attributes Y if the Value of X Determines a Unique Value for Y

FDs are Derived from the Real-World Constraints on the Attributes

A Relational Schema is Relations with Keys and FDs!

MTE.68

CSE4701

Example of FDs

Social Security Number Determines Employee Name SSN ENAME

Project Number Determines Project Name and Location PNUMBER {PNAME, PLOCATION}

SSN and Project Number Determines the Hours Per Week That the Employee Works on the Project

{SSN, PNUMBER} HOURS Notes:

An FD is a Property of Attributes in the Schema FDs Must Hold on Every Relation Instance R If K is a Key of R, then K Functionally

Determines All Attributes in R (Since we Never have Two Distinct Tuples with T1[k]=t2[k])

MTE.69

CSE4701

SSN EName SSN BDate SSN SSNSSN Address SSN DNumber

DNumber Dname DNumber DMGRSSN

Inference Rules for FDs

Given a set of FDs F, we can Infer Additional FDs that Hold whenever the FDs in F Hold

For Example, Consider:F = {SSN {EName, BDate, Address, DNumber},

DNumber {DName, DMGRSSN} } What are Additional FDs?

MTE.70

CSE4701

Inference Rules

Armstrong’s Inference Rules

Derived Inference Rules

1. Reflective: If X Y, then X Y.

2. Augmentation: If { X Y} then XZYZ.

3. Transitive: If { XY, YZ } then X Z.

4. Decomposition: If { XYZ } then X Y.

5. Additive (Union): If {XY, XZ } then X YZ.

6. Pseudotransitive: If {XY, WYZ } then W X Z.

CSE4701

Chapter 14-71

Summary of 1NF, 2NF, 3NF ConceptsTest Remedy (Normalization)

1NF Relation should have Form new relations for each nonatomic no nonatomic attributes attribute or nested relation. or nested relations.

2NF For relations where primary Decompose and set up a new relation key contains multiple for each partial key with its dependent attributes, no nonkey attribute(s). Make sure to keep a attribute should be relation with the original primary key functionally dependent on and any attributes that are fully a part of the primary key. functionally dependent on it.

3NF Relation should not have a Decompose and set up a relation that nonkey attribute functionally includes the nonkey attribute(s) that determined by another nonkey functionally determine(s) other attribute (or by a set of nonkey nonkey attribute(s). attributes.) That is, there should be no transitive dependency of a nonkey attribute on the primary key.

CSE4701

Chapter 14-72

Comparing the Normal Forms

1NF

2NF

3NF

BCNF

Eliminate the non-trivial functional

dependencies of non-key

attributes to key

Eliminate partial FDs of non-key attributes to key

Eliminate transitive FDs of non-key attributes to key

Eliminate partial and transitive FDs of key attributes to key

Poor Relational Schema DesignDeveloped as Stepping Stone

Most 3NF are in BCNF - BCNF Eliminates All Update Anomalies

CSE4701

Chapter 14-73

Summary of Normalization

2NF

3NF

BCNF

1NF

Eliminate the Partial Functional Dependencies of Non-prime Attributes to Key Attributes

Eliminate the Transitive Functional Dependencies of Non-prime Attributes to Key Attributes

Eliminate the Partial and Transitive Functional Dependencies of Prime (Key) Attributes to Key

Lossless Decompositionbut not Dependency Preserving

Lossless Decompositionand Dependency Preserving

CSE4701

Chapter 14-74

What are Multi-Valued Dependencies?

Focused on the Concept of Multi-Valued Dependencies A MVD X Y Indicates that a Value of X

Corresponds to Multiple Values of Y Consider EMP with MVDs:

ENAME PNAME (E works on many P) ENAME DNAME (E has many Dependents)