📘 Unit 2- Relational Database Design:
1. Introduction to Relational Databases
● Relational Model: Introduced by E.F. Codd in 1970, the relational model structures data
into tables (relations), rows (tuples), and columns (attributes). Each table has a unique
primary key to identify records uniquely.
● Key Components:
○ Relation: A table with rows and columns.
○ Tuple: A single row in a table.
○ Attribute: A column in a table.
○ Domain: The set of allowable values for an attribute.
● Primary Key: A unique identifier for each tuple in a relation.
● Foreign Key: An attribute that links to the primary key of another relation, establishing
relationships between tables.
2. Codd’s 12 Rules
Dr. Edgar F. Codd proposed 12 rules to define what constitutes a relational database
management system (RDBMS). These rules ensure data integrity, consistency, and usability.
1. The Information Rule: All information in a relational database is represented explicitly at
the logical level and in exactly one way—by values in tables.
2. The Guaranteed Access Rule: Each and every datum is logically accessible by
resorting to a combination of table name, primary key value, and column name.
3. Systematic Treatment of Null Values: Null values are supported for representing
missing or inapplicable information in a systematic way, independent of data type.
4. Dynamic Online Catalog Based on the Relational Model: The database description is
represented at the logical level in the same way as ordinary data, so that authorized
users can apply the same relational language to its interrogation as they apply to regular
data.(Relational DB Design)
5. Comprehensive Data Sublanguage Rule: The system must support at least one
relational language that has a linear syntax and supports data definition, data
manipulation, and transaction management operations.
6. View Updating Rule: All views that are theoretically updatable must also be updatable
by the system.
7. High-Level Insert, Update, and Delete: The system must support set-at-a-time insert,
update, and delete operations.
8. Physical Data Independence: Application programs and terminal activities remain
unaffected when any changes are made in the storage structures or access methods.
9. Logical Data Independence: Application programs and terminal activities remain
unaffected when any changes are made in the logical level (e.g., tables, views).
10.Integrity Independence: Integrity constraints specific to the relational model must be
definable in the relational data sublanguage and stored in the catalog, not in the
application programs.
11.Distribution Independence: The distribution of data across different locations should be
invisible to users.
12.Non-Subversion Rule: If a system has a low-level (record-at-a-time) interface, it must
not be able to subvert or bypass the integrity rules and constraints defined at the higher
level.
3. Relational Integrity Constraints
Integrity constraints ensure that data in relational databases remains
accurate, consistent, and reliable by enforcing specific rules.
Types & Real-time Examples:
1.Domain Constraints
○ Rule: Every attribute must have values only from a
defined set (domain).
○ Example:
In an Employee table, the attribute Gender can only
contain values from the domain {Male, Female, Other}.
This prevents invalid values like “M” or “X”.
2.Key Constraints
○ Rule: Each record must have a unique primary key.
○ Example:
In a Customer table, Customer_ID is the primary key,
so no two customers can have the same ID.
3.Entity Integrity Constraints
○ Rule: Primary key attributes cannot be NULL.
○ Example:
In a Product table, Product_ID must always have a
value to uniquely identify each product; it can’t be left
blank.
4.Referential Integrity Constraints
○ Rule: Foreign keys must refer to valid existing records in
another table.
○ Example:
In a Student table, Dept_ID is a foreign key referencing
the Department table.
Every Dept_ID in Student must exist in the Department
table to avoid orphan students with non-existent
departments.
Importance
● Maintains data consistency across tables.
● Prevents orphan records (e.g., a student assigned to a
department that doesn’t exist).
● Enforces meaningful logical relationships between data
entities.
4. Normalization
Normalization organizes data to minimize redundancy and avoid
anomalies (insertion, deletion, update problems).
Forms & Real-time Examples:
1.First Normal Form (1NF)
○ Rule: Eliminate repeating groups; each field contains
atomic (indivisible) values.
○ Example:
Suppose an Orders table stores product IDs like
101,102,103 in a single column. To be 1NF compliant,
each product ID must be stored in a separate row or
column, like separate rows per product order.
2.Second Normal Form (2NF)
○ Rule: Achieve 1NF and remove partial dependencies
(attributes dependent on part of a composite key).
○ Example:
A Sales table with composite key (Order_ID,
Product_ID) might have Product_Name dependent only
on Product_ID. To be in 2NF, move Product_Name to a
separate Product table.
3.Third Normal Form (3NF)
○ Rule: Achieve 2NF and remove transitive dependencies
(non-key attributes depending on other non-key
attributes).
○ Example:
If a Student table has Dept_Name stored along with
Dept_ID, and Dept_Name depends on Dept_ID, then
Dept_Name should be moved to a Department table to
avoid redundancy.
4.Boyce-Codd Normal Form (BCNF)
○ Rule: Every determinant is a candidate key (stronger
form of 3NF).
○ Example:
In a Course table, if a room number determines the
instructor (unique room-instructor pairing), room number
should be a candidate key or decomposed to satisfy
BCNF.
○
5. Entity-Relationship (ER) Modeling
ER modeling is a diagrammatic approach to database design that
visually represents entities and their relationships.
● Entities: Objects or things within the domain that have data
stored about them.(PlanetScale)
● Attributes: Properties or details about entities.
● Relationships: Associations between entities.
● Primary Key: An attribute or set of attributes that uniquely
identifies an entity.
● Foreign Key: An attribute that creates a link between two
tables.
Armstrong's Axioms refer to a set of inference rules, introduced by William
W. Armstrong, that are used to test the logical implication of functional
dependencies. Given a set of functional dependencies F, the closure of F
(denoted as F+) is the set of all functional dependencies logically implied by
F. Armstrong's Axioms, when applied repeatedly, help generate the closure
of functional dependencies.
These axioms are fundamental in determining functional dependencies in
databases and are used to derive conclusions about the relationships
between attributes.
Axioms
Axioms
● Axiom of Reflexivity: If A is a set of attributes and B is a subset of
A, then A holds B. If B⊆A then A→B. This property is trivial
property.
● Axiom of Augmentation: If A→B holds and Y is the attribute set,
then AY→BY also holds. That is adding attributes to dependencies,
does not change the basic dependencies. If A→B, then AC→BC for
any C.
● Axiom of Transitivity: Same as the transitive rule in algebra, if A→B
holds and B→C holds, then A→C also holds. A→B is called A
functionally which determines B. If X→Y and Y→Z, then X→Z.
Example:
Let’s assume the following functional dependencies:
{A} → {B}
{B} → {C}
{A, C} → {D}
1. Reflexivity: Since any set of attributes determines its subset, we can
immediately infer the following:
● {A} → {A} (A set always determines itself).
● {B} → {B}.
● {A, C} → {A}.
2. Augmentation: If we know that {A} → {B}, we can add the same attribute
(or set of attributes) to both sides:
● From {A} → {B}, we can augment both sides with {C}: {A, C} → {B,
C}.
● From {B} → {C}, we can augment both sides with {A}: {A, B} → {C,
B}.
3. Transitivity: If we know {A} → {B} and {B} → {C}, we can infer that:
● {A} → {C} (Using transitivity: {A} → {B} and {B} → {C}).
Although Armstrong's axioms are sound and complete, there are additional
rules for functional dependencies that are derived from them. These rules are
introduced to simplify operations and make the process easier.
Secondary Rules
These rules can be derived from the above axioms.
● Union: If A→B holds and A→C holds, then A→BC holds. If X→Y
and X→Z then X→YZ.
● Composition: If A→B and X→Y hold, then AX→BY holds.
● Decomposition: If A→BC holds then A→B and A→C hold. If X→YZ
then X→Y and X→Z.
● Pseudo Transitivity: If A→B holds and BC→D holds, then AC→D
holds. If X→Y and YZ→W then XZ→W.
Example:
Let’s assume we have the following functional dependencies in a relation
schema:
{A} → {B}
{A} → {C}
{X} → {Y}
{Y, Z} → {W}
Now, let's apply the Secondary Rules to derive new functional
dependencies.
1. Union Rule: If A → B and A → C, then by the Union Rule, we can infer:
● A → BC This means if A determines both B and C, it also
determines their combination, BC.
2. Composition Rule: If A → B and X → Y hold, then by the Composition
Rule, we can infer:
● AX → BY
3. Decomposition Rule: If A → BC holds, then by the Decomposition Rule,
we can infer:
● A → B and A → C
4. Pseudo Transitivity Rule: If A → B and BC → D hold, then by the Pseudo
Transitivity Rule, we can infer:
● AC → D
Armstrong Relation
Armstrong Relation can be stated as a relation that is able to satisfy all
functional dependencies in the F+ Closure. In the given set of dependencies,
the size of the minimum Armstrong Relation is an exponential function of the
number of attributes present in the dependency under consideration.
Why Armstrong Axioms Are Considered Sound and Complete?
Soundness: Armstrong's axioms are sound because any functional
dependency inferred using them will always be valid and hold true in every
relation state that satisfies the original set of dependencies.
Completeness: Armstrong's axioms are complete because applying them
repeatedly will generate all possible functional dependencies that can be
derived from the original set, ensuring no dependencies are missed.
