Concepts of Relational Databases

Fundamental Concepts Relational data model – A data model representing data in the form of tables Relations – A 2-dimensional table containing rows and columns of data Primary Key: - an attribute (or combination of attributes) that uniquely identifies each row in a relation Composite Key - a primary key consisting of more than one attribute

Fundamental Concepts Foreign Key - an attribute in a table of a database that serves as the primary key of another table in the same database Referential integrity constraint - A rule that states that either each foreign key value must match a primary key value in the other table

An Entity Relationship Diagram for Construction Company SKILL Check # Date BUILDING Bldg-ID Addr Type Q-Level WORKER Worker-ID Name Hourly Rate WORKER Supervises * 1 Status * Has-Skill 1 * Is assigned to *

Transformation to Tables Worker (Worker-ID, Name, Hourly-Rate, Skill- Type, Supv-ID) Assignment (Worker-ID, Bldg-ID, Start-Date, Num-Days) Building (Bldg-ID, Bldg-Address, Type, Q- Level, Status) Skill (Skill-Type, Bonus-Rate, Hours-Per- Week)

Worker Table Rows or tuples Attributes

Sample Tables in Construction Company Assignment Relation Skill Relation Building Relation

Issues in Database Design Null values – Not blank or 0; it is simply unknown or inapplicable and may be supplied at a later time – All workers do not have a supervisor Functional dependence – If you know a value for A, you know a value for B – A --> B - 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.

Relational Definitions Relation Every table has a unique name. Every row is unique. Attributes in tables have unique names. The order of the columns is irrelevant. The order of the rows is irrelevant. EMPLOYEE(EmployeeID, EmployeeName)

Integrity Constraints Domain Constraints – Allowable values for an attribute. However you set up the properties. Entity Integrity – No primary key attribute may be null. Operational Constraints – Business rules. Referential integrity –The value of a non-null foreign key must be an actual key value in some relation

Normalization Normalization is typically a refinement process after the initial exercise of identifying the data objects that should be in the database, identifying their relationships, and defining the tables required and the columns within each table.

Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that avoid unnecessary duplication of data. Normalization is the process of organizing it into tables in such a way that the results of using the database are always unambiguous and as intended. The process of breaking down tables with anomalies to produce smaller, well-structured tables.

Normalization First Normal Form (1NF) Second Normal Form (2NF) Third Normal Form (3NF)

Steps in normalization

First Normal Form (1NF) First normal form (1NF). This is the "basic" level of normalization and generally corresponds to the definition of any database, namely: It contains two-dimensional tables with rows and columns. Each column corresponds to a sub-object or an attribute of the object represented by the entire table. Each row represents a unique instance of that sub-object or attribute and must be different in some way from any other row (that is, no duplicate rows are possible). No multi-valued attributes. All entries in any column must be of the same kind. For example, in the column labeled "Customer," only customer names or numbers are permitted

First Normal Form (1NF) Contains no repeating values If you know the Primary Key, you know values for all other attributes

Second normal form (2NF) 1NF and every non-key attribute is fully functionally dependent on the primary key. If you have 1 primary key, you are automatically in 2NF! Every non-key attribute must be defined by the entire key, not by only part of the key. No partial functional dependencies. If you have 2 fields that make up a composite key – all other fields in the table must be dependent on both keys in the composite key!

Second Normal Form (2NF) For example, in a table with three columns containing: CUSTOMERID PRODUCT PRICE (the price would be a function of the customer ID (entitled to a discount) and the specific product. If PRICE was only related to the PRODUCT – this table would not be in 2NF.

Second Normal Form (2NF) No non-key attribute is dependent on only a part of the Primary Key – If only 1 PK, then relation is automatically in 2NF Decomposed into the following relations: – ASSIGNMENT (Worker-ID, Bldg-ID, Start-Date) – WORKER (Worker-ID, Name)

Third normal form (3NF) 2NF and no transitive dependencies (functional dependency between non-key attributes.) You don’t want any of your attributes to be dependent on other attributes outside of the primary key! At the second normal form, modifications are still possible because a change to one row in a table may affect data that refers to this information from another table.

Third Normal Form For example: Customer Item purchased Purchase price Thomas Shirt $40 Maria Tennis shoes $35 Evelyn Shirt $40 Pajaro Trousers $25 removing a row describing a customer purchase (because of a return perhaps) will also remove the fact that the product has a certain price. Also, if you change the Purchase price of the Shirt, it will have to be changed multiple times within the table

Third Normal Form Normalizing the data would mean understanding this and solving the problem by: dividing this table into two tables, one with information about each customer: CUSTOMER (CustID, CustName, Address) PRODUCT (Item, Purchase Price, CustID) Making additions or deletions to either table would not affect the other.

Third Normal (3NF) Every determinant (left side of a functional dependency) is a key Decomposed into: – SKILL (Worker-ID, Skill-Type) – BONUS (Skill-Type, Bonus-Rate)

Paraphrased from Kent (1983) Each non-key attribute in a relation is dependent on the primary key (1NF), the whole primary key (2NF), and nothing but the primary key (3NF).

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

Goals of Normalization Reduce data redundancy Improve “modify” activities: – create, update, delete, but not read

Price you pay for Normalization degraded query, display, reporting Normalization may have the effect of duplicating data within the database and often results in the creation of additional tables. (While normalization tends to increase the duplication of data, it does not introduce redundancy, which is unnecessary duplication.)

Steps in Normalization 1NF: a table, without multivalued attributes – if not, then decompose 2NF: 1NF and every non-key attribute is fully functionally dependent on the primary key – if not, then decompose 3NF: 2NF and no transitive dependencies – if not, then decompose GENERAL: – Each table should describe a single theme – Modification anomalies are minimized