Database Systems

Functional Dependencies
 Data Modeling Tools
A number of popular tools that cover conceptual
modeling and mapping into relational schema
design. Examples: ERWin, S- Designer (Enterprise
Application Suite), ER- Studio, etc.
POSITIVES: serves as documentation of
application requirements, easy user
interface - mostly graphics editor support

Dr. Ejaz Ahmed 2

 Problems with Current
Modeling Tools
• DIAGRAMMING
– Poor conceptual meaningful notation.
– To avoid the problem of layout algorithms and aesthetics
of diagrams, they prefer boxes and lines and do nothing
more than represent (primary-foreign key) relationships
among resulting tables.(a few exceptions)
• METHODOLGY
– lack of built-in methodology support.
– poor tradeoff analysis or user-driven design preferences.
– poor design verification and suggestions for
improvement.

Dr. Ejaz Ahmed 3

 Some of the Currently Available Automated Database
Design Tools
COMPANY TOOL FUNCTIONALITY
Embarcadero ER Studio Database Modeling in ER and IDEF1X
Technologies
DB Artisan Database administration and space and security
management
Oracle Developer 2000 and Database modeling, application development
Designer 2000
Popkin Software System Architect 2001 Data modeling, object modeling, process modeling,
structured analysis/design
Platinum Platinum Enterprice Data, process, and business component modeling
Technology Modeling Suite: Erwin,
BPWin, Paradigm Plus
Persistence Inc. Pwertier Mapping from O-O to relational model

Rational Rational Rose Modeling in UML and application generation in C++

and JAVA
Rogue Ware RW Metro Mapping from O-O to relational model

Resolution Ltd. Xcase Conceptual modeling up to code maintenance

Sybase Enterprise Application Suite Data modeling, business logic modeling

Visio Visio Enterprise Data modeling, design and reengineering Visual Basic
and Visual C++
Dr. Ejaz Ahmed 4
Database Development
• Requirements Analysis
– Collect and Analyze the requirements of the users.
• Conceptual Design
– Design a conceptual model, e.g., ER model.
• Logical Design
– Translate the ER model into the relational model.
– Normalization.
• Database Building
– Build the database and write application programs.
• Operation, Maintenance, & Tuning
– Use, maintain, and “tune” the database.
Dr. Ejaz Ahmed 5
Normalization
• Decides which attributes should be grouped
together in a relation

• Validates and improves the logical design to

the point before proceeding to physical
design.

• Based on the concept of Functional

dependency. Dr. Ejaz Ahmed 6
Normalization
• Normalization
– To ensure you have a “good” design.
• To prove you have got a “good” one.
• To rescue a “bad” one.
– How?
• Decompose a “bad” table into several “good” ones.
• Move from a lower normal form to a higher (better)
one.

• But what’s a “good” design?

Dr. Ejaz Ahmed 7
Good Database Design

• no redundancy of FACT (!)

• no inconsistency
examples: M/F or 1/0, Ahmed or Ahmad etc.,
this creates anomalies
Anomalies: Abnormal, Deviation from common rule
• no insertion, deletion or update anomalies
• no information loss
• no dependency loss
Dr. Ejaz Ahmed 8
Data Redundancy

• Major aim of relational database design is to group

attributes into relations to minimize data redundancy
and reduce file storage space required by base
relations.

• Problems associated with data redundancy are

illustrated by comparing the following Staff and
Branch relations with the StaffBranch relation.

Dr. Ejaz Ahmed 9

Data Redundancy: Example-1

• StaffBranch relation has redundant data:

details of a branch are repeated for every
member of staff.
Dr. Ejaz Ahmed 10
Example-1 Solution …

Dr. Ejaz Ahmed 11

Anomalies
• Insertion anomalies: how do we
represent the address of a new branch
without there being an employee?
• Deletion anomalies: deleting SA9 makes
us lose the information about branch
B007.
• Update anomalies: if B003 address is
updated, we must change it everywhere.

Dr. Ejaz Ahmed 12

Functional Dependency
• Let R be a table,
– and let X and Y be sets of attributes of R (X is on LHS and Y is on
RHS of an arrow pointing from left to right),

– if the value of X always uniquely determines the value of Y.

then Y is functionally dependent (FD) on X – means TRUE,

– In other words, whenever two rows agree on their X value, they also
agree on their Y value.

– We write: X --> Y
(read “X functionally determines Y”, or “X arrows to Y”)
Or Y is associated with X

– X is called the determinant. Dr.

Y is the
Ejaz dependent.
Ahmed 13
Functional Dependencies
• Functional dependencies (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 inter-relationships of the
data attributes
Dr. Ejaz Ahmed 14
Data Redundancy: example2
• Example 2: SCP{S#, CITY, P#, QTY}

S# CITY P# QTY
SP
S1 London P1 100
S1 London P2 100
S2 Paris P1 200
S2 Paris P2 200
S3 Paris P2 300
S4 London P2 400
S4 London P4 400
S4 London P5 400

• Typical beginner's mistake: use one table for the entire

database
• Problems: Data Redundancy and Data Anomalies.
Dr. Ejaz Ahmed 15
Data Redundancy

• {S#} -> {CITY}

• The city of a supplier is repeated several
times.
• Waste storage.
• More seriously, data redundancy causes
anomalies.

Dr. Ejaz Ahmed 16

Data Anomalies
• Insertion anomaly:
– Until a supplier actually supplies a part, we can’t
record (insert) its city.
• Update anomaly:
– If we want to change the city of a supplier, we
must update all the rows related to this supplier.
If we miss one row, the data is no longer
consistent.
• Deletion anomaly:
– If we delete all the shipments of a supplier, its city
is gone too. Dr. Ejaz Ahmed 17
 FD Example
• In the following revised version of the shipments
table:
– In addition to the usual attributes S#, P#, and QTY,
– an attribute CITY, representing the city of supplier.
SCP {S#, CITY, P#, QTY}

• Functional Dependencies:
– {S#} -> {CITY}
– {S#, P#} -> {QTY}
– {S#, P#} -> {CITY, QTY}
– {S#, P#} -> {S#, P#, CITY, QTY}
– {S#, P#, CITY, QTY} -> {S#, P#, CITY, QTY}
Dr. Ejaz Ahmed 18
FD Example (Cont.)
• A possible value for table SP:
S# CITY P# QTY
SP
S1 London P1 100
• Check whether these FDs hold: S1 London P2 100
S2 Paris P1 200
– {S#} -> {CITY} S2 Paris P2 200
– {S#, P#} -> {QTY} S3 Paris P2 300
S4 London P2 400
– {S#, P#} -> {CITY, QTY} S4 London P4 400
– {S#, P#} -> {S#, P#, CITY, QTY}S4 London P5 400

– {S#, P#, CITY, QTY} -> {S#, P#, CITY, QTY}

TRUE FDS are:
– {S#} -> {CITY}
– {S#, P#} -> {QTY} 3rd is not True; Supplier belongs to City
Dr. Ejaz Ahmed 19
Exercise
• Given the following FD with status FALSE

Cust#, Inv#, Item#TotQTY, Sprice, InvDate, ItemName

Produce all possible TRUE FDs

• Manufacturing_DatePartID, Pname,
Pprice
Identify FDs and give reasons
Dr. Ejaz Ahmed 20
Functional Dependency

Formal Definition: Attribute B is functionally dependant upon

attribute A (or a collection of attributes) if a value of A
determines a single value of attribute B at any one time.
Formal Notation: A  B This should be read as ‘A
determines B’ or ‘B is functionally dependent on A’. A
is called the determinant and B is called the object of the
determinant.
Example: Functional Dependencies
staffNo job dept dname staffNo  job
SL10 Salesman 10 Sales staffNo  dept
SA51 Manager 20 Accounts
DS40 Clerk 20 Accounts
staffNo  dname
OS45 Clerk 30 Operations dept  dname
Dr. Ejaz Ahmed 21