1. part 1 with pages 1-32 and part 2 with pages 33-69
Database Principles Constructed by Hanh Pham based on slides from: “Database Processing, Fundamentals, Design, and Implementation”, D. Kroenke, D. Auer, Prentice Hall “Database Principles: Fundamentals of Design, Implementation, and Management”, C. Coronel, S. Morris, P.Rob
Relational Databases
This slide has 2 parts:
part 1 with pages 1-32 and part 2 with pages 33-69

2. Outlines (of part 1) The Problem Relational Model Entity Relation
Functional dependency
Determinant
Keys:
Candidate key
Composite key
Primary key
Surrogate key
Foreign key

3. Chapter Objectives To understand basic relational terminology
To understand the characteristics of relations
To understand alternative terminology used in describing the relational model
To be able to identify functional dependencies, determinants, and dependent attributes
To identify primary, candidate, and composite keys
About relational database operators, the data dictionary, and the system catalog
How data redundancy is handled in the relational database model
Why indexing is important

4. The PROBLEM
We have received one or more tables of existing data.
The data is to be stored in a new database.
QUESTION: Should the data be stored as received, or should it be transformed for storage?

5. How Many Tables?
Should we store these two tables as they are, or should we combine them into one table in our new database?

6. Now the standard model for commercial DBMS products.
The Relational Model
Introduced in 1970
Created by E.F. Codd
He was an IBM engineer
The model used mathematics known as “relational algebra”
Now the standard model for commercial DBMS products.

7. A Logical View of Data Relational model
View data logically rather than physically
Logical view is based on relation
Relation thought of as a table
Table: two-dimensional structure composed of rows and columns
Structural and data independence
Resembles a file conceptually
Relational database model is easier to understand than hierarchical and network models

9. Important Relational Model Terms
Entity
Relation
Functional dependency
Determinant
Keys:
Candidate key
Composite key
Primary key
Surrogate key
Foreign key
Referential integrity constraint
Normal form
Multivalued dependency

10. An entity is some identifiable thing that users want to track:
Customers
Computers
Sales

11. Relation
Relational DBMS products store data about entities in relations, which are a special type of table.
A relation is a two-dimensional table that has the following characteristics:
Rows contain data about an entity.
Columns contain data about attributes of the entity.
All entries in a column are of the same kind.
Each column has a unique name.
Cells of the table hold a single value.
The order of the columns is unimportant.
The order of the rows is unimportant.
No two rows may be identical.

12. Relation

13. Tables That Are Not Relations: Multiple Entries per Cell

14. Tables That Are Not Relations: Table with Required Row Order

15. A Relation with Values of Varying Length

16. Alternative Terminology
Although not all tables are relations, the terms table and relation are normally used interchangeably.
The following sets of terms are equivalent:

17. Functional Dependency
A functional dependency occurs when the value of one (set of) attribute(s) determines the value of a second (set of) attribute(s):
StudentID  StudentName
StudentID  (DormName, DormRoom, Fee)
The attribute on the left side of the functional dependency is called the determinant.
Functional dependencies may be based on equations:
ExtendedPrice = Quantity X UnitPrice
(Quantity, UnitPrice)  ExtendedPrice
Function dependencies are not equations!

18. Functional Dependencies Are Not Equations
ObjectColor  Weight
ObjectColor  Shape
ObjectColor  (Weight, Shape)

19. Composite Determinants
Composite determinant = a determinant of a functional dependency that consists of more than one attribute
(StudentName, ClassName)  (Grade)

20. Functional Dependency Rules
If A  (B, C), then A  B and A C.
If (A,B)  C, then neither A nor B determines C by itself.

21. Functional Dependencies in the SKU_DATA Table

22. Functional Dependencies in the SKU_DATA Table
SKU  (SKU_Description, Department, Buyer)
SKU_Description  (SKU, Department, Buyer)
Buyer  Department

23. Functional Dependencies in the ORDER_ITEM Table

24. Functional Dependencies in the ORDER_ITEM Table
(OrderNumber, SKU) 
(Quantity, Price, ExtendedPrice)
(Quantity, Price)  (ExtendedPrice)

25. What Makes Determinant Values Unique?
A determinant is unique in a relation if and only if, it determines every other column in the relation.
You cannot find the determinants of all functional dependencies simply by looking for unique values in one column:
Data set limitations
Must be logically a determinant

26. Keys
A key is a combination of one or more columns that is used to identify rows in a relation.
A composite key is a key that consists of two or more columns.

27. Candidate and Primary Keys
A candidate key is a key that determines all of the other columns in a relation.
A primary key is a candidate key selected as the primary means of identifying rows in a relation.
There is only one primary key per relation.
The primary key may be a composite key.
The ideal primary key is short, numeric, and never changes.

28. Surrogate Keys
A surrogate key is an artificial column added to a relation to serve as a primary key.
DBMS supplied
Short, numeric, and never changes—an ideal primary key
Has artificial values that are meaningless to users
Normally hidden in forms and reports

29. RENTAL_PROPERTY without surrogate key:
Surrogate Keys
NOTE: The primary key of the relation is underlined below:
RENTAL_PROPERTY without surrogate key:
RENTAL_PROPERTY (Street, City, State/Province, Zip/PostalCode, Country, Rental_Rate)
RENTAL_PROPERTY with surrogate key:
RENTAL_PROPERTY (PropertyID, Street, City,
State/Province, Zip/PostalCode, Country, Rental_Rate)

30. Foreign Keys
A foreign key is the primary key of one relation that is placed in another relation to form a link between the relations.
A foreign key can be a single column or a composite key.
The term refers to the fact that key values are foreign to the relation in which they appear as foreign key values.

31. Foreign Keys
NOTE: The primary keys of the relations are underlined and any foreign keys are in italics in the relations below:
DEPARTMENT (DepartmentName, BudgetCode, ManagerName)
EMPLOYEE (EmployeeNumber, EmployeeLastName,
EmployeeFirstName, DepartmentName)

32. Summary Tables are basic building blocks of a relational database
Keys are central to the use of relational tables
Keys define functional dependencies
Each table row must have a primary key that uniquely identifies all attributes
Tables are linked by common attributes

33. Relational Databases (II)
Database Principles Constructed by Hanh Pham based on slides from: “Database Processing, Fundamentals, Design, and Implementation”, D. Kroenke, D. Auer, Prentice Hall “Database Principles: Fundamentals of Design, Implementation, and Management”, C. Coronel, S. Morris, P.Rob
Relational Databases
(II)

34. Outlines (of part 2) Relational Databases (Cont.)
Referential Integrity Constraint
Relational Set Operators
Dictionary, Catalog
Indexes

35. The Referential Integrity Constraint
A referential integrity constraint is a statement that limits the values of the foreign key to those already existing as primary key values in the corresponding relation.

36. Foreign Key with a Referential Integrity Constraint
NOTE: The primary key of the relation is underlined and any foreign keys are in italics in the relations below:
SKU_DATA (SKU, SKU_Description, Department, Buyer)
ORDER_ITEM (OrderNumber, SKU, Quantity, Price, ExtendedPrice)
Where ORDER_ITEM.SKU must exist in SKU_DATA.SKU

37. Many RDBMs enforce integrity rules automatically
Safer to ensure that application design conforms to entity and referential integrity rules
Designers use flags to avoid nulls
Flags indicate absence of some value

40. Relational Set Operators
Relational algebra
Defines theoretical way of manipulating table contents using relational operators
Use of relational algebra operators on existing relations produces new relations:
SELECT
UNION
PROJECT
DIFFERENCE
JOIN
PRODUCT
INTERSECT
DIVIDE

45. Relational Set Operators
Natural join
Links tables by selecting rows with common values in common attributes (join columns)
Equijoin
Links tables on the basis of an equality condition that compares specified columns
Theta join
Any other comparison operator is used

46. Relational Set Operators
Inner join
Only returns matched records from the tables that are being joined
Outer join
Matched pairs are retained, and any unmatched values in other table are left null

48. Relational Set Operators
Left outer join
Yields all of the rows in the CUSTOMER table
Including those that do not have a matching value in the AGENT table
Right outer join
Yields all of the rows in the AGENT table
Including those that do not have matching values in the CUSTOMER table

50. The Data Dictionary and System Catalog
Provides detailed accounting of all tables found within the user/designer-created database
Contains (at least) all the attribute names and characteristics for each table in the system
Contains metadata: data about data
System Catalog
Contains metadata
Detailed system data dictionary that describes all objects within the database

52. The Data Dictionary and System Catalog
Homonym
Indicates the use of the same name to label different attributes
Synonym
Opposite of a homonym
Indicates the use of different names to describe the same attribute

53. Relationships within the Relational Database
1:M relationship
Relational modeling ideal
Should be the norm in any relational database design
1:1 relationship
Should be rare in any relational database design
M:N relationships
Cannot be implemented as such in the relational model
M:N relationships can be changed into 1:M relationships

54. The 1:M Relationship
Relational database norm
Found in any database environment

56. The 1:1 Relationship
One entity related to only one other entity, and vice versa
Sometimes means that entity components were not defined properly
Could indicate that two entities actually belong in the same table
Certain conditions absolutely require their use

58. Implemented by breaking it up to produce a set of 1:M relationships
The M:N Relationship
Implemented by breaking it up to produce a set of 1:M relationships
Avoid problems inherent to M:N relationship by creating a composite entity
Includes as foreign keys the primary keys of tables to be linked

64. Data Redundancy Revisited
Data redundancy leads to data anomalies
Can destroy the effectiveness of the database
Foreign keys
Control data redundancies by using common attributes shared by tables
Crucial to exercising data redundancy control
Sometimes, data redundancy is necessary

66. Indexes Orderly arrangement to logically access rows in a table
Index key
Index’s reference point
Points to data location identified by the key
Unique index
Index in which the index key can have only one pointer value (row) associated with it
Each index is associated with only one table

68. Codd’s Relational Database Rules
In 1985, Codd published a list of 12 rules to define a relational database system
Products marketed as “relational” that did not meet minimum relational standards
Even dominant database vendors do not fully support all 12 rules

69. Tables are basic building blocks of a relational database
Summary
Tables are basic building blocks of a relational database
Keys are central to the use of relational tables
Keys define functional dependencies
Each table row must have a primary key that uniquely identifies all attributes
Tables are linked by common attributes
The relational model supports relational algebra functions
SELECT, PROJECT, JOIN, INTERSECT UNION, DIFFERENCE, PRODUCT, DIVIDE
Good design begins by identifying entities, attributes, and relationships
1:1, 1:M, M:N