Relational Database
Design
Pitfall of relational model
The main goal of relational database is to create / find good collection of relational schemas.
Such that database should allow us to store data / information without unnecessary
redundancy and should also allow to retrieve information easily.
That is the goal of relational database design should concentrated
• To avoid redundant data from database.
• To ensure that relationships among attributes are represented.
• To facilitate the checking of updates for the violation of database integrity constraints.
A bad relational database design may lead to:
• Repetition of information. - That is, it leads data redundancy in database, so obviously it
requires much space.
• Inability to represent certain information.
Example 1: Consider the
relational schema
Branch_loan = ( beranch_name, branch_city, assets, customer_name,
loan_no, amount)
Redundancy
• Data for branch_name, branch_city, assets are repeated for each loan that
provides by bank.
• Storing information several times leads waste of storage space / time.
• Data redundancy leads problem in Insertion, deletion and update.
Insertion problem
• We cannot store information about a branch without loan information, we can
use null values for loan information, but they are difficult to handle.
Deletion problem
• In this example, if we delete the information of Manoj
(i.e. DELETE FROM branch_loan WHERE customer_name = ‘Manoj’;),
we cannot obtain the information of pokhara branch (i.e. we don’t know branch
city of pokhara, total asset of pokhara branch etc.
Update problem
Since data are duplicated so multiple copies of same fact need to update
while updating one.
It increases the possibility of data inconsistency.
When we made update in one copy there is possibility that only some
of the multiple copies are update but not all, which lead data/database
in inconsistent state.
Functional dependencies
Functional dependency plays a key role in differentiating good database design
from bad database design.
It describes the relationship between attributes (columns) in a table.
Let X and Y are attributes of a relation R.
If each value of Y is associated with exactly one value of X then Y is said to be
functionally dependent on X.
it is denoted by . So the functional dependency holds if whenever two tuples
have the same value for X, they must have the same value for Y.
For any two tuples t1 and t2 in any relation instance r(R):
If t1[X] = t2[X], then t1[Y] = t2[Y]
Example: in the relation Customer (Cid, Cname, Age, salary)
Inference Rules for FDs
Closure of Set of Functional
Dependencies
• It is not sufficient to consider the given set of functional
dependencies.
• Rather, we need to consider all functional dependencies that hold.
We shall see that, given a set F of functional dependencies, we can
prove that certain other functional dependencies hold.
• We say that such functional dependencies are “logically implied” by F.
More formally, given a relational schema R, a functional dependency f
on R is logically implied by a set of functional dependencies F on R if
every relation instance r(R) that satisfies F also satisfies f.
In brief the set of dependencies that is logically implies by F is called
the closure of F and it’s closure is written as F+
F= {A→B, A→C, BC→D}.
Closure of attributes sets functional
dependency
Decomposition
The idea of decomposition is break down large and complicated relation in no. of simple and small
relations which minimized data redundancy.
It can be consider principle to solve the relational model problem.
Definition
The decomposition of relation schema R= (A1, A2, . ,An) is a set of relation schema { R1, R2, ---- Rm},
such that Ri ⊆ R ∀1 ≤ i≤ m and R 1 U R2 U . . URm = R.
That is all attributes of an original schema (R) must appear in the decomposition (R1, R2). That is, R=
R1UR2.
if R ≠ R1UR2 then such decomposition called lossey join decomposition.
That is, R≠∏R1(R) natural join ∏R2(R).
Decomposition should lossless join decomposition.
A decomposition of relation schema R into R1 and R2 is lossless join iff at least one of the following
dependencies is in F+.
R1 intersection R2→R1
R1 intersection R2→R2
