1. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 1-1 COS 346 Day 3

2. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 1-2 Agenda Questions? Assignment 1 not corrected –1 MIA Assignment Two is posted –Marcia’s Dry Cleaning Project on page 97 & 98, questions A through F –Due Feb 12 at 2:05 PM Finish Intro to SQL Begin discussions on the relational model and normalization

3. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-3 Agenda Questions? Assignment 1 Is DUE Discussion on The Relational Model and Normalization

4. 4 RELATIONAL OPERATIONS: OVERVIEW SQL operations for creating new tables, inserting table rows, updating table rows, deleting table rows, and querying databases are the primary means of interfacing with relational databases.SQL operations for creating new tables, inserting table rows, updating table rows, deleting table rows, and querying databases are the primary means of interfacing with relational databases. The SELECT statement is used primarily to write queries that extract information from the database, which is a collection of related tables.The SELECT statement is used primarily to write queries that extract information from the database, which is a collection of related tables.

5. 5 RELATIONAL OPERATIONS The ability to select specific rows and columns from one or more tables is referred to as the fundamental relational operations, and there are three of these operations:The ability to select specific rows and columns from one or more tables is referred to as the fundamental relational operations, and there are three of these operations: –Selection –Projection –Join The purpose of the next few slides is just to familiarize you with each of these operations. We will study these operations in detail in later chapters.The purpose of the next few slides is just to familiarize you with each of these operations. We will study these operations in detail in later chapters.

6. 6 Selection Operation A selection operation selects a subset of rows in a table (relation) that satisfy a selection condition. That subset can range from no rows to all rows in a table. The SELECT statement below selects a subset of rows through use of a WHERE clause.A selection operation selects a subset of rows in a table (relation) that satisfy a selection condition. That subset can range from no rows to all rows in a table. The SELECT statement below selects a subset of rows through use of a WHERE clause. SELECT emp_ssn, emp_last_name, emp_first_name FROM employee WHERE emp_ssn = '999111111'; emp_ssn emp_last_name emp_first_name ------------- --------------------- -------------- 999111111 Bock Douglas

7. 7 Projection Operation A projection operation selects only certain columns from the table, thus producing a subset of all available columns.A projection operation selects only certain columns from the table, thus producing a subset of all available columns. The result table can include anything from a single column to all the columns in the table.The result table can include anything from a single column to all the columns in the table.

8. 8EXAMPLE This SELECT statement selects a subset of columns from the employee table by specifying the columns to be listed.This SELECT statement selects a subset of columns from the employee table by specifying the columns to be listed. SELECT emp_ssn, emp_first_name, emp_last_name FROM employee; emp_ssn emp_first_name emp_last_name --------- ---------------- -------------- 999111111 Douglas Bock 999222222 Hyder Amin 999333333 Dinesh Joshi more rows will display…

9. 9 Join Operation A join operation combines data from two or more tables based upon one or more common column values.A join operation combines data from two or more tables based upon one or more common column values. The relational join is a very powerful operation because it allows users to investigate relationships among data elements.The relational join is a very powerful operation because it allows users to investigate relationships among data elements. The following SELECT statement displays column information from both the employee and department tables.The following SELECT statement displays column information from both the employee and department tables. This SELECT statement also completes both selection and projection operations.This SELECT statement also completes both selection and projection operations.

10. 10 Join Operation: Example

11. 11 JOIN: Example The tables are joined upon values stored in the department number columns named emp_dpt_number in the employee table and dpt_no in the department table.The tables are joined upon values stored in the department number columns named emp_dpt_number in the employee table and dpt_no in the department table. SELECT emp_ssn, emp_first_name, emp_last_name, dpt_name FROM employee, department WHERE emp_dpt_number = dpt_no; emp_ssn emp_first_name emp_last_name dpt_name ------------- ---------------- -------------------- -------------- 999111111 Douglas Bock Production 999222222 Hyder Amin Admin and Records 999333333 Dinesh Joshi Production more rows will display…

12. 12 SQL Syntax Now that you've seen some basic SQL statements, you may have noticed that SQL requires you to follow certain syntax rules; otherwise, an error message is returned by the system and your statements fail to execute.Now that you've seen some basic SQL statements, you may have noticed that SQL requires you to follow certain syntax rules; otherwise, an error message is returned by the system and your statements fail to execute.

13. 13 T-SQL Naming Rules The rules for creating identifiers in T-SQL differ slightly from those in the ANSI/ISO- 92 SQL standard.The rules for creating identifiers in T-SQL differ slightly from those in the ANSI/ISO- 92 SQL standard. Identifiers are the names given by information system developers and system users to database objects such as tables, columns, indexes, and other objects as well as the database itself.Identifiers are the names given by information system developers and system users to database objects such as tables, columns, indexes, and other objects as well as the database itself.

14. 14 T-SQL Naming Rules Contd. There are several rules for naming database objects that must be followed: Ide ntifiers must be no more than 128 characters. Ide ntifiers must be no more than 128 characters. Identifiers can consist of letters, digits, or the symbols #, @, $, and _ (underscore).Identifiers can consist of letters, digits, or the symbols #, @, $, and _ (underscore). The first character of an identifier must be either a letter (a-z, A- Z) or the #, @ or _ (underscore) symbol. After the first character, you may use digits, letters, or the symbols $, #, or _ (underscore).The first character of an identifier must be either a letter (a-z, A- Z) or the #, @ or _ (underscore) symbol. After the first character, you may use digits, letters, or the symbols $, #, or _ (underscore). Temporary objects are named by using the # symbol as the first character of the identifier. Avoid using this symbol as the leading character when naming permanent database objects.Temporary objects are named by using the # symbol as the first character of the identifier. Avoid using this symbol as the leading character when naming permanent database objects. The @ symbol as the first character of an identifier denotes a variable name. Avoid using this symbol as the leading character when naming other database objects.The @ symbol as the first character of an identifier denotes a variable name. Avoid using this symbol as the leading character when naming other database objects. SQL keywords such as SELECT and WHERE cannot be used as an identifier.SQL keywords such as SELECT and WHERE cannot be used as an identifier.

15. 15 SELECT Statement Syntax Overview Each select statement must follow precise syntactical and structural rules.Each select statement must follow precise syntactical and structural rules. For example, you cannot place the FROM clause before the SELECT clause, or place the FROM clause after the WHERE clause or the ORDER BY clause, and so on.For example, you cannot place the FROM clause before the SELECT clause, or place the FROM clause after the WHERE clause or the ORDER BY clause, and so on. The basic syntax (including the order of various clauses) is as follows:The basic syntax (including the order of various clauses) is as follows:

16. 16 SELECT Statement Syntax Overview Contd. SELECT [DISTINCT | ALL] [TOP n [PERCENT][WITH TIES]] {* | select_list} [INTO {table_name} ] [INTO {table_name} ] [FROM {table_name [alias] | view_name} [{table_name [alias] | view_name}]]... [{table_name [alias] | view_name}]]... [WHERE condition | JOIN_type table_name ON (join_condition) ] [WHERE condition | JOIN_type table_name ON (join_condition) ] [GROUP BY condition_list] [HAVING condition] [ORDER BY {column_name | column_# [ ASC | DESC ] }...

17. 17 SELECT Statement Syntax you will learn the various clauses of the SELECT statement throughout your study of this text.you will learn the various clauses of the SELECT statement throughout your study of this text. Welcome to the study of SQL!Welcome to the study of SQL!

18. 18 SUMMARY This chapter: Introduced you to the basics of relational database, DBMS, and SQL.Introduced you to the basics of relational database, DBMS, and SQL. Familiarized you with the features of the SQL Server DBMS including its GUI, the SQL Query Analyzer.Familiarized you with the features of the SQL Server DBMS including its GUI, the SQL Query Analyzer. Familiarized you with the basic relational operations including the selection, projection, and join operations.Familiarized you with the basic relational operations including the selection, projection, and join operations. Familiarize with the basic syntax of the SELECT statement.Familiarize with the basic syntax of the SELECT statement.

19. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-19 David M. Kroenke’s Chapter Three: The Relational Model and Normalization Database Processing: Fundamentals, Design, and Implementation

20. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-20 Chapter Premise 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?

21. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-21 How Many Tables? Should we store these two tables as they are, or should we combine them into one table in our new database?

22. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-22 But first - We need to understand: –The relational model –Relational model terminology

23. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-23 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

24. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-24 Important Relational Model Terms Entity Relation Functional Dependency Determinant Candidate Key Composite Key Primary Key Surrogate Key Foreign Key Referential integrity constraint Normal Form Multivalued Dependency

25. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-25 Entity An entity is some identifiable thing that users want to track: –Customers –Computers –Sales Rows is a table are a specific instance of some identifiable thing (entity)

26. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-26 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: 1.Rows contain data about an entity 2.Columns contain data about attributes of the entity 3.All entries in a column are of the same kind 4.Each column has a unique name (unique to the relation!) 5.Cells of the table hold a single value 6.The order of the columns is unimportant 7.The order of the rows is unimportant 8.No two rows may be identical

27. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-27 A Relation

28. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-28 A Relation with Values of Varying Length

29. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-29 Tables That Are Not Relations: Multiple Entries per Cell

30. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-30 Tables That Are Not Relations: Table with Required Row Order

31. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-31 Alternative Terminology Although not all tables are relations, the terms table and relation are normally used interchangeably The following sets of terms are equivalent: Old Skool Theoretical Practice

32. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-32 Functional Dependency A functional dependency occurs when the value of one (a 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!

33. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-33 Functional Dependencies Are Not Equations ObjectColor  Weight ObjectColor  Shape ObjectColor  (Weight, Shape)

34. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-34 Composite Determinants Composite determinant: A determinant of a functional dependency that consists of more than one attribute (StudentName, ClassName)  (Grade)

35. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-35 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

36. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-36 Functional Dependencies in the SKU_DATA Table

37. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-37 Functional Dependencies in the SKU_DATA Table SKU  (SKU_Description, Department, Buyer) SKU_Description  (SKU, Department, Buyer) Buyer  Department

38. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-38 Functional Dependencies in the ORDER_ITEM Table

39. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-39 Functional Dependencies in the ORDER_ITEM Table (OrderNumber, SKU)  (Quantity, Price, ExtendedPrice) (Quantity, Price)  (ExtendedPrice) SKU  Price ???

40. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-40 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

41. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-41 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

42. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-42 Candidate and Primary Keys A candidate key is a key that determines all of the other columns in a relation (Unique Determinant) A primary key is a candidate key selected as the primary means of identifying rows in a relation: –There is one and only one primary key per relation –The primary key may be a composite key –The ideal primary key is short, numeric and never changes

43. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-43 Surrogate Keys A surrogate key as 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

44. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-44 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)

45. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-45 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

46. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-46 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, EmployeeName, DepartmentName)

47. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-47 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

48. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-48 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

49. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-49 Modification Anomalies Deletion Anomaly Insertion Anomaly Update Anomaly

50. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-50 Deletion Anomalies Deleting facts about one entity causes the deletion of facts about another entity

51. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-51 Insertion Anomalies We cannot store facts about entity until we have another entity of different type to store –Add scuba to following

52. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-52 Modification Anomalies The EQUIPMENT_REPAIR table before and after an incorrect update operation on AcquisitionCost for Type = Drill Press:

53. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-53 Fixing Anomalies Split the relation

54. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-54 Normalization Normalization eliminates modification anomalies –Deletion anomaly: deletion of a row loses information about two or more entities –Insertion anomaly: insertion of a fact in one entity cannot be done until a fact about another entity is added Anomalies can be removed by splitting the relation into two or more relations; each with a different, single theme However, breaking up a relation may create referential integrity constraints Normalization works through classes of relations called normal forms

55. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-55 Relationship of Normal Forms

56. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-56 Normal Forms Relations are categorized as a normal form based on which modification anomalies or other problems that they are subject to:

57. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-57 Normal Forms 1NF – A table that qualifies as a relation is in 1NF 2NF – A relation is in 2NF if all of its nonkey attributes are dependent on all of the primary key 3NF – A relation is in 3NF if it is in 2NF and has no determinants except the primary key Boyce-Codd Normal Form (BCNF) – A relation is in BCNF if every determinant is a candidate key “I swear to construct my tables so that all nonkey columns are dependent on the key, the whole key and nothing but the key, so help me Codd.”

58. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-58 Normal Forms (Part 2) Any table of data is in 1NF if it meets the definition of a relation A relation is in 2NF if all its non-key attributes are dependent on all of the key (no partial dependencies) –If a relation has a single attribute key, it is automatically in 2NF A relation is in 3NF if it is in 2NF and has no transitive dependencies A  B & B  C QED A  C A relation is in BCNF if every determinant is a candidate key A relation is in fourth normal form if it is in BCNF and has no multi-value dependencies A  B Fifth Normal form is too theoretical to bother with To be in Domain/Key Normal Form (DK/NF) every constraint on the relation must be a logical consequence of the definition of keys and domains.

59. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-59 Eliminating Modification Anomalies from Functional Dependencies in Relations Put all relations into Boyce-Codd Normal Form (BCNF):

60. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-60 Putting a Relation into BCNF: EQUIPMENT_REPAIR

61. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-61 Putting a Relation into BCNF: EQUIPMENT_REPAIR EQUIPMENT_REPAIR (ItemNumber, Type, AcquisitionCost, RepairNumber, RepairDate, RepairAmount) ItemNumber  (Type, AcquisitionCost) RepairNumber  (ItemNumber, Type, AcquisitionCost, RepairDate, RepairAmount) ITEM (ItemNumber, Type, AcquisitionCost) REPAIR (ItemNumber, RepairNumber, RepairDate, RepairAmount) Where REPAIR.ItemNumber must exist in ITEM.ItemNumber

62. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-62 Putting a Relation into BCNF: New Relations

63. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-63 Putting a Relation into BCNF: SKU_DATA

64. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-64 Putting a Relation into BCNF: SKU_DATA SKU_DATA (SKU, SKU_Description, Department, Buyer) SKU  (SKU_Description, Department, Buyer) SKU_Description  (SKU, Department, Buyer) Buyer  Department SKU_DATA (SKU, SKU_Description, Buyer) BUYER (Buyer, Department) Where BUYER.Buyer must exist in SKU_DATA.Buyer

65. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-65 Putting a Relation into BCNF: New Relations

66. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-66 Multivaled Dependencies A multivalued dependency occurs when a determinant determines a particular set of values: Employee  Degree Employee  Sibling PartKit  Part The determinant of a multivalued dependency can never be a primary key

67. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-67 Multivalued Dependencies

68. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-68 Eliminating Anomalies from Multivalued Dependencies Multivalued dependencies are not a problem if they are in a separate relation, so: –Always put multivalued dependencies into their own relation –This is known as Fourth Normal Form (4NF)

69. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-69 Fixing 4thNF (Generally Speaking) A relation R(A,B,C) –A   B –A   C –B and C are independent Create R(A,B) andR1(A,C)

70. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-70 Fifth Normal Form (5NF) The Fifth Normal Form concerns dependencies that are obscure and beyond the scope of this text. Punt!

71. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-71 Domain/Key Normal Form (DK/NF) To be in Domain/Key Normal Form (DK/NF) every constraint on the relation must be a logical consequence of the definition of keys and domains. Ultimate Normal Form –1981 Fagin NO possible anomalies

72. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-72 DK/NF Terminology Constraint –A rule governing static values of attributes Key –A unique identifier of a tuple Domain –A description of an attribute’s allowable values

73. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-73 De-normalized Designs When a normalized design is unnatural, awkward, or results in unacceptable performance, a de-normalized design is preferred Example –Normalized relation CUSTOMER (CustNumber, CustName, Zip) CODES (Zip, City, State) –De-Normalized relations CUSTOMER (CustNumber, CustName, City, State, Zip)

74. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-74 David M. Kroenke’s Database Processing Fundamentals, Design, and Implementation (10 th Edition) End of Presentation: Chapter Three