1. Chapter 3
The Relational Database Model

2. A Logical View of Data Relational model Table
Enables programmer to view data logically rather than physically
Table
Has advantages of structural and data independence
Resembles a file from conceptual point of view
Easier to understand than its hierarchical and network database predecessors

3. Tables and Their Characteristics
Table: two-dimensional structure composed of rows and columns
Contains group of related entities = an entity set
Terms entity set and table are often used interchangeably
entity set ≒ table ≒ relation

4. Tables and Their Characteristics
Table also called a relation because the relational model’s creator, Codd, used the term relation as a synonym for table
Think of a table as a persistent relation:
A relation whose contents can be permanently saved for future use

5. Tables and Their Characteristics

6. Table Characteristics
Two-dimensional structure with rows and columns
Row (tuple) represent a single entity occurrence within the entity set.
Columns represent attributes
Row/column intersection represents single value
Column values all have same data format
Each column has range of values called attribute domain
Order of the rows and columns is immaterial to the DBMS
Tables must have an attribute or a combination of attributes that uniquely identifies each row

7. Tables and Their Characteristics

8. Keys
A key Consists of one or more attributes that determine other attributes
Primary key (PK) is an attribute (or a combination of attributes) that uniquely identifies any given entity (row)
Key’s role is based on determination
If you know the value of attribute A, you can look up (determine) the value of attribute B

9. Keys (continued) HOURS_COMPLETED → CLASSIFICATION Freshman Sophomore
Junior
Freshman
Sophomore
Junior
Senior
Senior
HOURS_COMPLETED → CLASSIFICATION

10. Keys Composite key Key attribute Superkey Candidate key Primary key
Composed of more than one attribute
Key attribute
Any attribute that is part of a key
Superkey
Any key that uniquely identifies each row
Candidate key
A superkey without redundancies
Minimal superkey
Does not contain a subset of attributes that itself a superkey.
Primary key
Candidate key selected to uniquely identify all other attributes in a given row.
Cannot contains null entries.

11. Secondary key not necessarily yield a unique outcome
Super key
STU_NUM
(STU_NUM, STU_LNAME)
Candidate key
(STU_LNAME, STU_FNAME, STU_INIT, STU_PHONE)
Primary key
Secondary key not necessarily yield a unique outcome
CUSTOMER table:
Primary key : Customer number
Secondary key : Customer last name, Customer phone number
A secondary key’s effectiveness in narrowing down a search depends on how restrictive it is.

12. Null Values No data entry Not permitted in primary key
Should be avoided in other attributes
Can represent
An unknown attribute value
A known, but missing, attribute value
A “not applicable” condition
Can create problems when functions such as (COUNT, AVERAGE, and SUM)
Can create logical problems when relational tables are linked

13. Keys (continued) Controlled redundancy :
Makes the relational database work
Tables within the database share common attributes that enable the tables to be linked together
Multiple occurrences of values in a table are not redundant when they are required to make the relationship work
Redundancy exists only when there is unnecessary duplication of attribute values

14. Keys
Controlled redundancy (shared common attributes) makes the relational database work.
The primary key of one table appears again as the link (foreign key) in another table.
VEND_CODE in PRODUCT table (Figure 3.2)
referential integrity : if the foreign key contains a value, that value refers to an existing valid tuple in another relation.
referential integrity : if the foreign key contains a value, that value refers to an existing valid tuple in another relation.

17. Keys (continued) Foreign key (FK) Referential integrity Secondary key
An attribute whose values match primary key values in the related table
Referential integrity
FK contains a value that refers to an existing valid tuple (row) in another relation
Secondary key
Key used strictly for data retrieval purposes

18. Keys (continued)

19. Integrity Rules

20. Integrity Rules Entity integrity
(unique and no null) All Primary key entries are unique , and no part of a Primary key may be null .
CUS_CODE
AGENT_CODE

21. Integrity Rules Referential integrity
(null or matching) A Foreign key may have either a null entry or an entry that matches the primary key value in a table to which it is related.
AGENT_CODE
Every non-null foreign key value must reference an existing primary key value.

22. -99
null or matching

23. Integrity Rules (continued)
To avoid nulls, some designer use special codes, known as flags, to indicate the absence of some value.
The code -99 could be used as the AGNET_CODE of 4th row of the CUSTOMER table to indicate that customer Paul does not yet have an agent assigned to him.

24. Relational Database Operators
Relational algebra defines the theoretical way of manipulating table contents using relational operators:
UNION
INTERSECT
DIFFERENCE
PRODUCT
SELECT
PROJECT
JOIN
DIVIDE
Use of relational algebra operators on existing tables (relations) produces new relations

25. Relational Database Operators
UNION combines all rows from two tables, excluding duplicate rows. The two tables must be union compatible. (share the same columns and domains)

26. INTERSECT yields only the rows that appear in both tables
INTERSECT yields only the rows that appear in both tables. The two tables must be union compatible.

27. DIFFERENCE yields all rows in one table that are not found in the other table; i.e., it subtracts one table from the other. The tables must be union compatible.

28. PRODUCT yields all possible pairs of rows from two tables
PRODUCT yields all possible pairs of rows from two tables. (Cartesian product)

29. SELECT Figure 2.9 yields values for all rows found in a table.
Can be used to list either all row values or it can yield only those row values that match a specified criterion
It yields a horizontal subset of a table.
Figure 2.9

30. PROJECT yields all values for selected attributes
PROJECT yields all values for selected attributes. yields a vertical subset of a table.

31. JOIN allows information to be combined from two or more tables.
Real power behind the relational database, allowing the use of independent tables linked by common attributes.

32. Relational Database Operators
Natural JOIN links tables by selecting only the rows with common values in their common attribute(s). It is the result of a 3-stage process:
PRODUCT of the tables is created. (Figure 3.12)
SELECT is performed on Step 1 output to yield only the rows for which the common attribute values match. (Figure 3.13) Common column(s) are called join column(s)
PROJECT is performed to yield a single copy of each attribute, thereby eliminating the duplicate column. (Figure 3.14)

33. PRODUCT

34. SELECT
PROJECT

35. Relational Algebra Operators (continued)
Natural Join:
Final outcome yields table that
Does not include unmatched pairs
Provides only copies of matches

36. Relational Algebra Operators
The column on which the join was made occurs only once in the new table (AGENT_CODE)
If no match is made between the table rows
the new table does not include the unmatched row (AGENT_CODE 421)
So, we need another form of join

37. Relational Algebra Operators
EquiJOIN
links tables based on an equality condition that compares specified columns of each table.
Outcome does not eliminate duplicate columns
condition or criteria to join the tables must be explicitly defined.
Theta JOIN is an equiJOIN that compares specified columns of each table using a comparison operator other than the equality(=) comparison operator.

38. equiJOIN criteria(C=E)B C 1 X 10 2 20 3 y D E m 10 n 20 p 40 A B C D E 1 x 10 m 3 y 2 20 n

39. theta JOIN criteria(C<E)B C 1 X 10 2 20 3 y D E m 10 n 20 p 40 A B C D E 1 x 10 n 20 p 40 2 3 y

40. Relational Algebra Operators
Outer join:
Matched pairs are retained and any unmatched values in other table are left null
In outer join for tables CUSTOMER and AGENT, two scenarios are possible:
Left outer join
Yields all rows in CUSTOMER table, including those that do not have a matching value in the AGENT table
Right outer join
Yields all rows in AGENT table, including those that do not have matching values in the CUSTOMER table

41. CUSTOMER Full Outer JOINCUSTOMER.AGENT_CODE=AGENT.AGENT_CODE AGENT

42. CUSTOMER Left Outer JOINCUSTOMER.AGENT_CODE=AGENT.AGENT_CODE AGENT

43. CUSTOMER Right Outer JOINCUSTOMER.AGENT_CODE=AGENT.AGENT_CODE AGENT

44. DIVIDE requires the use of one single-column table and one two-column table.

45. This is not an uncommon situation, but the solution is not straightforward since the SQL SELECT statement does not directly support relational division.
There are numerous ways to achieve the same results as a relational division, however. The easiest method is to rephrase the request. Instead of "list the suppliers who provide all product categories,“ which is difficult to process, try "list all suppliers where the count of their product categories is equal to the count of all product categories."

46. The Data Dictionary and System Catalog
Contains metadata — data about data
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
Sometimes described as “the database designer’s database” because it records the design decisions about tables and their structures

48. The Data Dictionary and System Catalog
Contains metadata
Detailed system data dictionary that describes all objects within the database
Terms “system catalog” and “data dictionary” are often used interchangeably
Can be queried just like any user/designer-created table

49. Relationships within the Relational Database
E-R Diagram (ERD)
Rectangles are used to represent entities.
Entity names are nouns and capitalized.
Diamonds are used to represent the relationship(s) between the entities.
“1” side of relationship
Number 1 in Chen Model
Bar crossing line in Crow’s Feet Model
“Many” relationships
Letter “M” and “N” in Chen Model
Three pronged “Crow’s foot” in Crow’s Feet Model

50. 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 two 1:M relationships

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

52. The 1:M Relationship Between PAINTER and PAINTING

53. Example 1:M Relationship

54. The Implemented 1:M Relationship Between PAINTER and PAINTING
PAINTER (PAINTER_NUM)
PAINTING (PAINTING_NUM) (PAINTER_NUM)

55. The 1:M Relationship Between COURSE and CLASS

56. The Implemented 1:M Relationship Between COURSE and CLASS
COURSE (CRS_CODE)
CLASS (CLASS_CODE) (CRS_CODE)

57. The 1:1 Relationship
One entity can be 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
As rare as 1:1 relationships should be, certain conditions absolutely require their use

58. The 1:1 Relationship Between PROFESSOR and DEPARTMENT

59. The 1:1 Relationship (continued)
1:M
1:1

60. The M:N Relationship
Can be implemented by breaking it up to produce a set of 1:M relationships
Can avoid problems inherent to M:N relationship by creating a composite entity or bridge entity

61. The M:N Relationship Between STUDENT and CLASS

62. Sample Student Enrollment Data

63. The M:N Relationship Between STUDENT and CLASS
321452
10014

64. Composite Entity The tables (Figure 3.25) creates many redundancies.
Composite Entity ( Bridge Entity)
Links the tables originally were related in a M:N relationship
Includes at least the primary keys of the tables that are to be linked.
In Chen’s ERD, represented by a diamond within a rectangle

65. Converting the M:N Relationship into Two 1:M Relationships
STUDENT (STU_NUM)
ENROLL (CLASS_CODE+STU_NUM) (CLASS_CODE,STU_NUM)
CLASS (CLASS_CODE) (CRS_CODE)

66. Changing the M:N Relationship to Two 1:M Relationships

67. The Expanded Entity Relationship Model

68. The Relational Schema for the Ch03_TinyCollege Database

69. Data Redundancy Revisited
Data redundancy leads to data anomalies
Such anomalies can destroy database effectiveness
Foreign keys
Control data redundancies by using common attributes shared by tables
Foreign keys can reduce redundancy
Sometimes, data redundancy is necessary

70. Changing the M:N Relationship to Two 1:M Relationships
INVOICE
PRODUCT
INVOICE
LINE
PRODUCT

71. A Small Invoicing System
CUSTOMER (CUS_CODE)
INVOICE (INV_NUM) (CUS_CODE)
A Small Invoicing System
LINE (INV_NUM+LINE_NUM) (INV_NUM, PROD_CODE)
PRODUCT (PROD_CODE)

72. The Relational Schema for the Invoicing System

73. Why Data Redundancies ? Sometimes, data redundancy is necessary
Product price (LINE_PRICE in LINE table) : Data redundancies !
The redundancy is crucial to the system’s success. Copying the product price from PRODUCT table to the LINE table means that it is possible to maintain the historical accuracy of the transactions. Product price may change.

74. Indexes
An index is an orderly arrangement used to logically access rows in a table of keys and pointers.
An index is composed of
an index key (the index’s reference point) (PAINTER_NUM)
a set of pointers.
Each pointer points to the location of the data identified by the key.
Makes retrieval of data faster
Each index is associated with only one table

75. Indexes

76. Codd’s Relational Database Rules
In 1985, Codd published a list of 12 rules to define a relational database system
The reason was the concern that many vendors were marketing products as “relational” even though those products did not meet minimum relational standards

77. Codd’s Relational Database Rules

78. Summary Tables are basic building blocks of a relational database
Keys are central to the use of relational tables
Keys define functional dependencies
Superkey
Candidate key
Primary key
Secondary key
Foreign key

79. Summary (continued)
Each table row must have a primary key which uniquely identifies all attributes
Tables can be linked by common attributes. Thus, the primary key of one table can appear as the foreign key in another table to which it is linked
The relational model supports relational algebra functions: SELECT, PROJECT, JOIN, INTERSECT, UNION, DIFFERENCE, PRODUCT, and DIVIDE.
Good design begins by identifying appropriate entities and attributes and the relationships among the entities. Those relationships (1:1, 1:M, and M:N) can be represented using ERDs.

80. Logical View of Data Relational Database
Designer focuses on logical representation rather than physical
Use of table advantageous
Structural and data independence
Related records stored in independent tables
Logical simplicity

81. A Logical View of Data
Relational database model’s structural and data independence
allow us to ignore the structure’s physical complexity.
enables us to view data logically rather than physically.
The logical view allows a simpler file concept of data storage.
The use of logically independent tables is easier to understand.
Logical simplicity yields simpler and more effective database design methodologies.

82. A Logical View of Data Entities and Attributes
An entity is a person, place, event, or thing for which we intend to collect data.
University -- Students, Faculty Members, Courses
Each entity has certain characteristics known as attributes.
Student -- Student Number, Name, GPA, Date of Enrollment, Data of Birth, Home Address, Phone Number, Major
A grouping of related entities becomes an entity set.
The STUDENT entity set contains all student entities.
The FACULTY entity set contains all faculty entities.

83. A Logical View of Data entity set ≒ table ≒ relation
Tables and Their Characteristics
A table contains a group of related entities -- i.e. an entity set.
The terms entity set and table are often used interchangeably.
A table is also called a relation.
entity set ≒ table ≒ relation

84. Immaterial 無關緊要的

86. Keys
The key’s role is based on a concept known as determination, which is used in the definition of functional dependence.
The attribute B is functionally dependent on A if A determines B. ( A → B )
An attribute that is part of a key is known as a key attribute.
A multi-attribute key is known as a composite key.
If the attribute (B) is functionally dependent on a composite key (A) but not on any subset of that composite key, the attribute (B) is fully functionally dependent on (A) (A is minimal !)