Additional Notes for Chapter 2 (Rob & Coronel) The Relational Database Model Please note that Figure

e and Table Numbers are in accordance with PowerPoint slides from 4th edition. Relational Database Keys (Section 2.2- Refer to Table 2.3) 1. Superkey any key that identifies each entity uniquely. it functionally determines all of the entitys attributes. e.g. in Figure 2.1, STU_NUM STU_NUM, STU_LNAME STU_NUM, STU_LNAME, STU_INIT redundant attributes are allowed, e.g. STU_LNAME, STU_INIT 2. Candidate key a superkey without redundant attributes e.g. STU_NUM in Figure 2.1 if we have STU_NUM and PAN_NUM in Figure 2.1, both would have been candidate keys, because either one would identify each student uniquely. choosing STU_NUM over PAN_NUM as the primary key would be driven by the designers choice or by end user requirements. 3. Primary key a superkey as well as a candidate key e.g. STU_NUM 4. Secondary key a key that is used strictly for data retrieval purposes. e.g., a customer may not remember his customer id, i.e. primary key. Data retrieval can be facilitated by using the customers last name and phone number. The secondary key is the combination of the last name and phone number. a secondary key does not necessarily yield a unique outcome, for instance with family members at the same residence. As another example, last name and zip code could yield dozens of matches, which can then be combed for a specific match. a secondary keys effectiveness in narrowing down a search depends on how restrictive it is, e.g. CUS_CITY set to New York or Sydney is not likely to produce a usable return, unless you want to examine millions of possible matches. CUS_CITY however is better than CUS_COUNTRY. Issues with Many-to-Many(M:N)Relationships (Section 2.6) Referring to Figure 2.23, M:N is not implemented due to the following: 1. The tables create many redundancies, e.g. STU_NUM value occurs many times in STUDENT table. In a real word situation, students address, telephone number, etc., would also be included and so would also repeat. CLASS table has similar issues, e.g. ClASS_TIME. Each STUDENT taking the CLASS generates a CLASS record. 1

Therefore, M:N relationships result in update, insert and delete anomalies. 2. Due to structure and contents of the tables, relational operations become very complex and are likely to lead to system efficiency and output errors. The database lacks primary keys and foreign keys, it is difficult to query such a database. We can avoid the problems inherent in the M:N relationship by creating a composite entity or bridge entity. Because such a table is used to link the tables that originally were related in a M:N relationship, the composite entity structure includes as foreign keys at least the primary keys of the tables that are to be linked. (Refer to CLASS_CODE + STU_NUM in ENROLL table in Figure 2.24.) The database designer has two main options to define a composite tables primary key: either use the combination of those foreign keys, or create a new primary key, e.g. as an alternative, ENROLL LINE could have been introduced as a primary key in the ENROLL table, instead of using the composite primary key. Because the ENROLL table links two tables, it is also called a linking table. The linking table is a logical entity created as a means to an end: to eliminate the potential for multiple redundancies in the original M:N relationship. It produces the desired 1:M relationships within the database. (Note as a result, the database now has primary keys and foreign keys, appropriately assigned to tables, whereas in the original M:N relationship, it was not possible to have any primary keys or foreign keys.) N.B. The STUDENT and CLASS tables now contain only one row per entity. N.B. The linking ENROLL table contains multiple occurrences of the foreign key values, but such controlled redundancies are incapable of producing anomalies as long as referential integrity is enforced.