Relational Database

Dr. Edgar F. (Ted) Codd To fellow pilots and aircrew in the Royal Air Force during World War II and the dons at Oxford: These people were the source of my determination to fight for what I believed was right during the ten or more years in which government, industry, and commerce were strongly opposed to the relational approach to database management.

Relational Definitions Every relation has a unique name. Every attribute value is atomic. Every row is unique. Attributes in tables have unique names. The order of the columns is irrelevant. The order of the rows is irrelevant.

Relational Definitions Tuple Attribute View

Relational Keys and Structures Primary Key Candidate Key Composite Key Foreign Key One-to-Many Relationship Many-to-Many Relationship Intersection Data

Relational Concepts Relational Algebra Relational Calculus Relational Operations SELECT PROJECT JOIN Equijoin - Join field appears twice. Natural Join - Join field appears once.

Schema for four relations (Pine Valley Furniture)

Instance of a relational schema

Integrity Constraints Domain Constraints Allowable values for an attribute. Entity Integrity No primary key attribute may be null. Operational Constraints Business rules.

Referential integrity constraints (Pine Valley Furniture)

Integrity Constraints Referential Integrity For example: Delete Rules Restrict Cascade Set-to-Null

Well-Structured Relations Insertion Anomaly Deletion Anomaly Modification Anomaly

Transforming E-R Diagrams into Relations 1. Map Regular Entities to Relations (Fig. 6-8). Composite attributes: Use only their simple, component attributes (Fig. 6-9). Multi-valued Attribute - Becomes a separate relation with a foreign key taken from the superior entity (Fig. 6-10).

Mapping a composite attribute (a) CUSTOMER entity type with composite attribute

(b) CUSTOMER relation with address detail

Transforming E-R Diagrams Into Relations 2. Map Weak Entities Becomes a separate relation with a foreign key taken from the superior entity (Fig. 6-11).

Example of mapping a weak entity (a) Weak entity DEPENDENT

(b) Relations resulting from weak entity

Transforming E-R Diagrams Into Relations 3. Map Binary Relationships One-to-Many - Primary key on the one side becomes a foreign key on the many side (Fig. 6-12). Many-to-Many - Create a new relation with the primary keys of the two entities as its primary key (Fig. 6-13). One-to-One - Primary key on the mandatory side becomes a foreign key on the optional side (Fig. 6-14).

Example of mapping a 1:M relationship (a) Relationship between customers and orders

(b) Mapping the relationship

Example of mapping an M:N relationship (a) Requests relationship (M:N)

(b) Three resulting relations

Mapping a binary 1:1 relationship

(b) Resulting relations

Transforming E-R Diagrams Into Relations 4. Map Associative Entities Identifier Not Assigned Default primary key for the association relation is the primary keys of the two entities (Fig. 6-15). Identifier Assigned It is natural and familiar to end-users. Default identifier may not be unique. (Fig. 6-16).

Mapping an associative entity with an identifier (a) Associative entity (SHIPMENT)

(b) Three relations

Transforming E-R Diagrams Into Relations 5. Map Unary Relationships One-to-Many - Recursive foreign key in the same relation (Fig. 6-17). Many-to-Many - Bill-of-materials: Two relations: One for the entity type. One for an associative relation in which the primary key has two attributes, both taken from the primary key of the entity. (Fig. 6-18).

Transforming E-R Diagrams Into Relations 6. Map Ternary (and n-ary) Relationships One relation for each entity and one for the associative entity. (Fig. 6-19).

Mapping a ternary relationship (a) Ternary relationship with associative entity

(b) Mapping the ternary relationship

Supertype/subtype relationships

Mapping Supertype/subtype relationships to relations

Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that avoid unnecessary duplication of data. The process of decomposing relations with anomalies to produce smaller, well-structured relations.

Functional Dependencies and Keys Functional Dependency: The value of one attribute (the determinant) determines the value of another attribute. Candidate Key: Each non-key field is functionally dependent on every candidate key. Fig. 6-22.

Steps in normalization

First Normal Form No multi-valued attributes. Every attribute value is atomic. Fig. 6-2a, b.

Second Normal Form 1NF and every non-key attribute is fully functionally dependent on the primary key. Every non-key attribute must be defined by the entire key, not by only part of the key. No partial functional dependencies. Fig. 6-2b, 6-22b.

Third Normal Form 2NF and no transitive dependencies (functional dependency between non-key attributes.) Fig. 6-23, 6-24, 6-25.

Relation with transitive dependency (a) SALES relation with simple data

(b) Transitive dependency in SALES relation

Removing a transitive dependency (a) Decomposing the SALES relation

(b) Relations in 3NF

Merging Relations (View Integration) Synonyms: Different names, same meaning. Homonyms: Same name, different meanings. Transitive Dependencies: e.g. (Stu ID, Major) (Stu ID, Advisor). Supertype/Subtype.