Scribd
Upload
55 views

Rules of Thumbs and Tips For Normalization

Rules and Tips for Normalization provides guidance on normalizing relational databases and representing them graphically. Key points include: 1. Functional dependencies (FDs) relate attributes within a single relation or table. 2. The left side of an FD can appear as a primary key and foreign key across two tables, but the right side will only appear in one table. 3. Arrows between tables in a schema must correspond to FDs. Primary keys point outward from tables while foreign keys point inward, referencing the primary key.

Uploaded by

indraindra31
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
55 views

Rules of Thumbs and Tips For Normalization

Rules and Tips for Normalization provides guidance on normalizing relational databases and representing them graphically. Key points include: 1. Functional dependencies (FDs) relate attributes within a single relation or table. 2. The left side of an FD can appear as a primary key and foreign key across two tables, but the right side will only appear in one table. 3. Arrows between tables in a schema must correspond to FDs. Primary keys point outward from tables while foreign keys point inward, referencing the primary key.

Uploaded by

indraindra31
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Rules and Tips for Normalization

Dr. Ye Jeff Zhang, November 6~7, 2011


1. A FD goes into one relation/table.
All boxes in a FD represented in a

(You can put an example of yours in this


column)

graphical schema go into one


relation/table. In an ERD, a FD is an
entity (regular, or associative).
a) A FD is a regular entity in ERD
unless the determinants form a
composite key, when the FD is
an associative entity
2. The left-hand side (LHS) in a FD may
appear in two relations (tables): as PK
in one table (Table 1), and as FK in
another table (Table 2). In the latter
(Table 2), it could also be part of
the PK (where there is a composite
key), and at the same time the FK.
3. The right-hand side (RHS) in a FD will
never appear in two relations
(tables), if it is not on LHS of any FD.
4. An arrow in the relational schema
linking two relations/tables must
correspond to an arrow in a FD.
5. PK-FK relationship constraint: the
arrowhead always goes out from the
FK and ends at PK.
a) In terms of tables/relations, FK
always goes out from the
relation/table on the M-side,
pointing/referencing the
relation/table on the 1-side.
6. Two outgoing arrows mean composite
key; an incoming and an out-going
arrow at the same attribute
means transitive dependency.
7. Differentiate Partial vs Transitive
dependency:
Ye Jeff Zhang, CSU-Northridge, 2011-2012

a)

Partial FD: when there is a


composite key, this FD has ONE
PART of the composite key as
the determinant of some other
non-key attribute(s). In graphical
schema, this is the case where
two/three boxes determine some
other boxes, while one of the
two/three boxes itself also
determines some other

(different) boxes.
b) Transitive FD: A non-key
attribute (not the PK, not part of
the composite key, but totally
non-key attribute) determines
other attribute(s). In graphical
schema, this is when theres an
incoming and an outgoing
arrow into and from the
same box.
8. Decomposition does not drop
attributes: every attribute must
find its home table
somewhere.
9. Decomposition does not drop a
FD either: every FD must appear as
a relation/table FDs wont disappear
or emerge from nowhere.
10.If there is a FD, then there must be
an entity or relationship in the ERD;
and vice versa.
11.Identify FKs: Those who are not key
(or part of a composite key) in the big
relation, and later become key in the
independent relations. In the big
relation, these attributes either have
an incoming and an outgoing arrow
(transitive FD), or are part of a
Ye Jeff Zhang, CSU-Northridge, 2011-2012

composite key.
12.A non-key attribute will NEVER
appear in two relations/tables.
(FK is non-key, but it is the PK of
another table so its not always
non-key attribute).
13.Two tables will NOT point to
(reference) each other (because they
cannot be simultaneously on the M
side of a 1:M relationship).
14.One attribute may appear in one
table (very common), two tables (PK
in one and FK in another), three
tables (PK in one, FK in two),
HOWEVER, the SAME TWO attributes
will NOT appear in the SAME TWO
TABLES.
15.(1) ERD, (2) schema with FDs, and (3)
schemas after normalization must all
agree to one another in logic. (3)
must be derived from (2).
16.The intersection relation/table is
advised to be plotted in between the
other two tables that it (the
intersection) references, so that the
references arrows will be easy to plot
17.
18.

Ye Jeff Zhang, CSU-Northridge, 2011-2012

You might also like