1. 1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 Introduction to Conceptual Database Design These slides are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. For more information on how you may use them, please see http://www.openlineconsult.com/db

2. 2© Ellis Cohen 2001-2008 Overview of Lecture Entity Classes Relationships & ER Diagrams 1:M Relationship Design Multiple Relationships & The Fan Traps Conceptual Design Other ER Models Mandatory Participation Reflexive 1:M Relationships Class Identification & Surrogate Keys Redundancy & Anomalies Simple Functional Dependencies Simple Conceptual Normalization

3. 3© Ellis Cohen 2001-2008 Entity Classes

4. 4© Ellis Cohen 2001-2008 Conceptual Modeling Conceptual Modeling is a way of designing systems involving collections of tables by focusing on Entities –an abstraction of tuples Entity Classes –an abstraction of tables Relationships –between entities in different entity classes Using diagrams called ER diagrams (or Entity-Relationship Diagrams)

5. 5© Ellis Cohen 2001-2008 Tables as Themes Every table has a theme -- e.g. Employees Every row represents an instance of that theme -- e.g. a single Employee A row represents a single Employee empno ename sal comm Employees 7499ALLEN1600300 7654MARTIN12501400 7698BLAKE2850 7839KING5000 7844TURNER15000 7986STERN1500

6. 6© Ellis Cohen 2001-2008 Columns as Attributes Every column represents an attribute related to the theme -- e.g. the name or salary of an Employee empno ename sal comm Employees Primary Key is underlined Uniquely identifies an employee 7499ALLEN1600300 7654MARTIN12501400 7698BLAKE2850 7839KING5000 7844TURNER15000 7986STERN1500

7. 7© Ellis Cohen 2001-2008 Rows as Objects/Entities empno: 7654 ename : MARTIN sal : 1250 comm : 1400 an Employee Object It can be useful to think of each row as an object or entity and the table as a collection of these entities. The columns of the table correspond to the instance variables for each object It can be useful to think of each row as an object or entity and the table as a collection of these entities. The columns of the table correspond to the instance variables for each object empno ename sal comm Employees 7499ALLEN1600300 7654MARTIN12501400 7698BLAKE2850 7839KING5000 7844TURNER15000 7986STERN1500

8. 8© Ellis Cohen 2001-2008 Entity Classes In conceptual modeling, we focus on the entity class which represents the class of entities with the same theme. In general (but as we will see, not always), an entity class is implemented by a table in a relational database

9. 9© Ellis Cohen 2001-2008 Modeling Entity Classes Employee empno ename sal comm Employee Sometimes we include all the attributes Sometimes we don't Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText) Employee( empno, ename, sal, comm ) Employee Sometimes we just include the primary key empno

10. 10© Ellis Cohen 2001-2008 Attributes Types Employee empno  a number ename  a string sal  a dollar amount comm  a dollar amount Keep attribute types simple Complex attribute types often mean you need to rethink your design or be more specific

11. 11© Ellis Cohen 2001-2008 Relationships and ER Diagrams

12. 12© Ellis Cohen 2001-2008 ER (Entity-Relationship) Diagrams (Crow Magnum style) The Crow's foot at Employee means … A Dept can have MANY Employees No Crow's foot at Dept, so … An Employee works for no more than ONE Dept Dept works for Crows Foot relationship characterization empno ename sal comm deptno dname Employee Depicts a relationship between Employees and Depts

13. 13© Ellis Cohen 2001-2008 ER & Instance Diagrams DeptEmployee works for 7698BLAKE2850 7499ALLEN1600300 7654MARTIN12501400 7986STERN1500 7844TURNER15000 10SALES 30ACCOUNTING * ER Diagram Entity Class Relationship Corresponds to links between instances of the related classes Instance Diagram Shows example instances and the links between them Entity Instances Links

14. 14© Ellis Cohen 2001-2008 Instance Diagrams & Navigation Links are the basis of navigation between instances. We will see later that there are SQL queries which effectively find the tuples in one entity class which are related to the tuples in another entity class. So we can write SQL to find information about The dept associated with an employee All the employees who work for a department 7698BLAKE2850 7499ALLEN1600300 7654MARTIN12501400 7986STERN1500 7844TURNER15000 10SALES 30ACCOUNTING Links

15. 15© Ellis Cohen 2001-2008 Entities & Links as Persistent Data Every –entity instance of an entity class –link instance of a relationship Represents –data persistently stored in a database –information needed to answer a query (e.g. what’s the salary of ALLEN?, what department does ALLEN work in?) The ONLY reason to represent an entity class or a relationship in a conceptual model is because the requirements clearly indicate they are necessary to provide information needed for some query

16. 16© Ellis Cohen 2001-2008 1:M (1 to Many) Relationships an Employee works for (at most) 1 Dept a Dept has any number (i.e. M) of Employees Dept Employee works for empno deptno Child Entity ClassParent Entity Class

17. 17© Ellis Cohen 2001-2008 Easy Crow Magnum Relationships Dept Employee works for Dept Employee works for empno deptno Easy Crow Magnum is meant for quickly drawing designs on paper or a whiteboard no attributes shown in this example just primary keys shown in this example Visual Conceptual Model (Easy Crow Magnum) In Easy Crow Magnum, don't draw the box outlines on entity classes

18. 18© Ellis Cohen 2001-2008 Visual & Textual Models for Relationships TEXTUAL Conceptual Model (Brief ConText) (*) Employee works for Dept VISUAL Conceptual Model (Crow Magnum) relationship characterization Dept Employee works for relationship characterization

19. 19© Ellis Cohen 2001-2008 Inverse Relationships TEXTUAL Conceptual Model (Brief ConText) Dept contains (*) Employee VISUAL Conceptual Model (Crow Magnum) relationship characterization Dept Employee contains relationship characterization

20. 20© Ellis Cohen 2001-2008 Indicating Relationship Direction Dept Employee works for Must indicate the relationship direction if it is not the natural reading direction (L-to-R, top-to-bottom) Dept Employee works for Dept Employee contains Dept Employee contains Dept Employee contains Dept Employee works for

21. 21© Ellis Cohen 2001-2008 Naming Relationships Entity Classes Employee( empno, ename, addr ) Dept( deptno, dname ) Relationships DeptAssignment DeptAssignment: (*) Employee works for Dept It is useful, though not required, to name relationships in ConText Relationship characterization Choose a relationship name so that it clearly and uniquely identifies the relationship Relationship name

22. 22© Ellis Cohen 2001-2008 M:N (Many-to-Many) Relationships EmployeeProject assigned to (*) Employee assigned to (*) Project Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText) Each employee may be assigned to a number of projects Each project may have a number of employees

23. 23© Ellis Cohen 2001-2008 M:N Related Instances empno ename address empnopno EmployeeProject assigned to 7499ALLEN... 7654MARTIN... 7698BLAKE... 7839KING... 7844TURNER... 7986STERN... 2618… pno pname … 2621… 2622…

24. 24© Ellis Cohen 2001-2008 1:1 (One-to-One) Relationships DeskEmployee assigned to Each employee may be assigned to at most one desk Each desk may be assigned to at most one employee Desk assigned to Employee Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText)

25. 25© Ellis Cohen 2001-2008 1:1 Related Instances empnodeskno 311… deskno … EmployeeDesk assigned to 312… 313… empno ename address 7499ALLEN... 7654MARTIN... 7698BLAKE... 7839KING... 7844TURNER... 7986STERN...

26. 26© Ellis Cohen 2001-2008 1:M Relationship Design

27. 27© Ellis Cohen 2001-2008 1:M Relationship Exercise Come up with an Easy Crow Magnum ER Diagram of a 1:M Relationship between two entity classes (not a 1:1 or M:N relationship, and not Dept/Employee) The diagram must 1.show the name of each entity class 2.show main attributes of each entity class 3.include the primary key (and underline it) 4.show the relationship characterization Dept works for empno ename sal deptno dname Employee

28. 28© Ellis Cohen 2001-2008 Choosing Relationship Characterizations ER diagrams are meant for communicating designs as clearly as possible. It is worth taking the time to choose the best possible relationship characterization. Dept Employee works for Dept Employee employs Dept Employee has Dept Employee has

29. 29© Ellis Cohen 2001-2008 Mistaking 1:M for M:N persid flavid Person Ice Cream Flavor likes persid flavid Person Ice Cream Flavor likes It is common to consider relationships from only one perspective. Think about a person. They like many ice cream flavors. Must be 1:M? But in fact, many persons like the same ice cream flavor, so it is actually M:N. Specifying the relationship characterization is crucial. The "favorite flavor" relationship is 1:M, but in the other direction! persid flavid Person Ice Cream Flavor favorite flavor

30. 30© Ellis Cohen 2001-2008 Choosing the Wrong Key persid title Person Book owns This case is somewhat similar to the previous one. A person owns many books, each one identified by their title. So, it must be 1:M. In fact, may people own a book with a particular title (e.g. there are lots of copies of "Gone with the Wind"). The problem is that the wrong primary key has been used. Imagine that every copy of every book ever published was given a unique serial number which uniquely identifies a single book instance. That's what would be needed to really have a 1:M relationship! persid serialnum Person Book owns

31. 31© Ellis Cohen 2001-2008 Singleton Classes Boston University Building owns bldgno Boston University is a singleton entity class, which only has a single entity (i.e. a single tuple) in it. Either leave it out entirely, or replace it with a more general entity class DON'T DO THIS DO THIS INSTEAD University Building owns bldgno name Building bldgno OR THIS

32. 32© Ellis Cohen 2001-2008 Singleton Classes & M:N Relationships Microsoft Building uses bldgno Generalizing singleton entity classes can result in M:N relationships DON'T DO THIS Company Building uses bldgno name Building bldgno DO THIS INSTEAD OR THIS

33. 33© Ellis Cohen 2001-2008 Entity Classes vs. Attributes Salary Employee makes empno ename salary Employee empno ename salary Don't create an entity class for something that really does not need to have a "life of its own", but ought to simply be an attribute of another entity class DON'T DO THIS DO THIS INSTEAD

34. 34© Ellis Cohen 2001-2008 Attribute vs. Entity Class Principles Dept Employee empno ename deptno Employee empno ename deptno Reasons for upgrading attributes to entity classes: 1.Substance: It emphasizes that a department is something that can and should stand in its own right 2.Extensibility: One might want to add attributes specific to a department (e.g. its name, location, etc.) 3.Multiplicity: It emphasizes that a department can have multiple employees associated with it 4.Association: It emphasizes that an employees cannot have an arbitrary deptno value, but that the employee is associated with a department which has a specific deptno Note that none of these reasons make sense for Salary (though multiplicity suggests that it might be useful to add a PayGrade Class, and make salary an attribute of a PayGrade)

35. 35© Ellis Cohen 2001-2008 Break Up Complex Attributes Employee empno ename assignments Assignment Employee empno ename assnid projnam rate startdate Do NOT use attributes that contain complex sets of details. Break them up into additional entity classes! Moreover, this should probably be replaced by a relationship with a Project entity class

36. 36© Ellis Cohen 2001-2008 Entity Attributes & Relationships Employee does not contain an attribute that identifies the Dept it is associated with (i.e. deptno). An employee is certainly associated with a department – but that is represented by the relationship between Employee and Dept. A deptno attribute in Employee would be an entity attribute (it identifies a Dept entity). This would not only be redundant (with the works for relationship), but wrong to include in a Conceptual Model [no conceptual foreign keys] * DeptEmployee works for deptno dname empno ename addr deptno Does NOT include deptno

37. 37© Ellis Cohen 2001-2008 Relationships & Persistence A relationship represents information which needs to be persistently stored in a database! If the information doesn't need to be stored and queried, don't represent it as a relationship Don't include relationships which simply show what a user can do or keep track of what a user has done, unless it is clear that information will be needed later! *

38. 38© Ellis Cohen 2001-2008 Multiple Relationships & The Fan Traps

39. 39© Ellis Cohen 2001-2008 Multiple Relationships Coach TeamPlayer TeamPlayerHealth Plan TeamPlayerChild has enrolled in works for has What do these diagrams mean?

40. 40© Ellis Cohen 2001-2008 The Fan Trap Employee DivisionDept works for divided into Suppose there are multiple divisions in a company, each divided into departments Every employee works for a division (and is assigned to a particular department in that division) What's wrong with the diagram below?

41. 41© Ellis Cohen 2001-2008 Fan Trap Instances 7698BLAKE 7499ALLEN 7654MARTIN 7986STERN 7844TURNER 10SALES 30ACCOUNTING It is impossible to determine which department an employee is assigned to! DIV A DIV B … …

42. 42© Ellis Cohen 2001-2008 The Reverse Fan Trap Division EmployeeDept employs works for Suppose a company has multiple divisions Every employee is employed by a division, and assigned to a particular department (in that division) What's wrong with this diagram? empnodeptnodivno

43. 43© Ellis Cohen 2001-2008 Reverse Fan Trap Instances 7698BLAKE 7499ALLEN 7654MARTIN 7986STERN 7844TURNER DIV A DIV B … 10SALES 30ACCOUNTING … Two employees in the same department could be assigned to different divisions Is there any way to prevent this when using this model?

44. 44© Ellis Cohen 2001-2008 Business Rules & The Reverse Fan Trap Division EmployeeDept employs works for empnodeptnodivno + Two employees who are in the same department must be in the same division We can prevent this problem by adding the business rule above! But how would this be enforced? Well, we'll see that we can write code that detects every time a change is made to the data in the database which might violate this business rule, and then ensures that the business rule is enforced! Are there any other problems with this model?

45. 45© Ellis Cohen 2001-2008 Deletion Anomalies & The Reverse Fan Trap 7698BLAKE 7499ALLEN 7654MARTIN 7986STERN 7844TURNER DIV A DIV B … 10SALES 30ACCOUNTING … Suppose STERN is the only employee in department 30. If STERN is terminated, there is no longer any way, to determine that dept 30 is in division B! So maybe we should try another model?

46. 46© Ellis Cohen 2001-2008 Resolving the Fan Traps EmployeeDeptDivision works for part of It is now possible to determine each employee's department & each department's division! We can also still tell which division an employee is assigned to, by following the link from the employee to the dept, and then from the dept to the division 7698BLAKE 7499ALLEN 7654MARTIN 7986STERN 7844TURNER 10SALES 30ACCOUNTING DIV A DIV B … …

47. 47© Ellis Cohen 2001-2008 Conceptual Design

48. 48© Ellis Cohen 2001-2008 Database Design Levels Conceptual Design / Model Model of the database design in terms that users will understand Logical Design / Model Description of the design in terms that can be directly used to build a database (This is called a Relational Model, if we are building an RDB) Physical Design / Model Additional design descriptions that specify or affect the data representation in physical storage

49. 49© Ellis Cohen 2001-2008 Database Design Process Requirements Physical Model using DDL & DCL Relational Model Conceptual Model Conceptual Design Relational Mapping Physical Mapping Actual Design of Tables in the Database A model used for communication with system analysts and UI designers

50. 50© Ellis Cohen 2001-2008 Conceptual Modeling (also known as Conceptual Design) starts with two activities Identify Entity Classes Identify Relationships between them

51. 51© Ellis Cohen 2001-2008 Identify Entity Classes Identify the classes of entities called for to support requirements Think of an entity as –a readily identifiable thing A potential entity class should have 1.Multiple instances (i.e. the requirements should imply the need for more than one entity of that class) 2.A clear set of attributes based on the requirements 3.A primary key to uniquely identify tuples

52. 52© Ellis Cohen 2001-2008 Design Exercise A university is divided into departments. Each department is made up of faculty members. Each department may have a number of degree-granting programs. Every student may only declare a major in a single program. Every student may be assigned a faculty member as an advisor. What are the entity classes needed?

53. 53© Ellis Cohen 2001-2008 Entity Classes Needed University: MAYBE, but it sounds like it's a singleton class Department: YES Faculty Member: YES Student: YES Person: MAYBE (ignore for now) (Degree-Granting) Program: YES Major: MAYBE (but it is simpler to just treat major as a relationship) between a student and a program Advisor: MAYBE (but it is simpler to treat advise as a relationship between Faculty Member and Student (also, Advisor is a subclass of Faculty Member, which is a bit too complicated to get into just yet)

54. 54© Ellis Cohen 2001-2008 Identify Relationships If the database needs to persistently keep track of a link/association between an entity of one class and an entity of another class The entity classes are related to one another Draw the Easy Crow Magnum diagram based on the identified entity classes. All 1:M Relationships!

55. 55© Ellis Cohen 2001-2008 Design Solution Faculty Member DepartmentProgram Student made up of offers majors in advises Faculty members sometimes have appointments in more than one department. The relationship would be 1:M if the requirement were " Each department is made up of faculty members; and each faculty member is only in one department, at most" Faculty Member Department

56. 56© Ellis Cohen 2001-2008 Relationship Exercise Bikeshop Bike ModelBike Part ModelPart has in stock part of sells instance of used on The model above describes the parts on bikes sold by a chain of bike-shops (i.e. there are multiple bike-shops). It contains both 1:M and M:N relationships, but the Crow's Feet have all been removed. Put them back where they belong!

57. 57© Ellis Cohen 2001-2008 Relationship Exercise Answer Bikeshop Bike ModelBike Part ModelPart has in stock part of used on sells instance of

58. 58© Ellis Cohen 2001-2008 Uses of 1:M Relationships EmployeeDental Plan enrolled in BikePart part of Part ModelPart instance of 1. Relationship between independent entity classes 2. Aggregation (Part/Whole) Relationship 3. Instance/Category Relationship

59. 59© Ellis Cohen 2001-2008 Entity Class Specificity Whenever we design entity classes, it is important to think VERY CAREFULLY about its specificity When designing the entity class Auto, we could mean –A kind of auto: Individual entities would be identified by model and year: e.g. 1984 Honda Accord. Better to name this class Auto Model –A specific auto: Individual entities would be identified by their VIN (vehicle identification number): e.g. 614HT37994PL7394, but might also have a model and year (or maybe not) Sometimes a design will need multiple levels of specificity (related by a 1:M relationship – e.g. Bike & Bike Model).

60. 60© Ellis Cohen 2001-2008 Other ER Models

61. 61© Ellis Cohen 2001-2008 Chen 1:M ER Model Crow Magnum Chen Key constraint: The primary key of Employee not only uniquely identifies an employee (and their name & addr), but also uniquely identifies their associated department (its deptno & dname) EmployeeDept works for Employee Dept works for empno ename addr deptno dname Child Entity ClassParent Entity Class

62. 62© Ellis Cohen 2001-2008 UML 1:M ER Model UML Crow Magnum Associations (i.e. relationships) reflect the associations that one entity should or needs to have with other entities. EmployeeDept works for * EmployeeDept works for A department needs to be associated with multiple (*) employees – all the employees that work for it An employee only needs to be associated with, at most, a single department – the department it is in Child Entity ClassParent Entity Class 0..1

63. 63© Ellis Cohen 2001-2008 UML with Attributes UML Crow Magnum EmployeeDept works for * EmployeeDept works for 0..1 deptno dname empno ename addr PK empno ename addr PK deptno dname Using UML's icon notation for PK

64. 64© Ellis Cohen 2001-2008 Primary Key Representations in UML UML Dept « PK »deptno dname UML Dept PK deptno dname UML Dept deptno { PK } dname Use UML's stereotype notation, which is a way of associating domain-specific characteristics, enclosed in « guillemets », with a UML element Use UML's icon notation. An icon is a predefined arbitrary graphical symbol, in this case, to be used in place of a stereotype PK Use UML's property notation, which is a way of associating properties, enclosed in { curly braces }, with a UML element

65. 65© Ellis Cohen 2001-2008 UML Aggregation UML PartBike * When a 1:M relationship is a part/whole relationship (e.g. a bicycle part is a part of a bike), then UML uses a special aggregation symbol to depict it Crow Magnum PartBike part of In rare circumstances, UML also allows aggregation with M:N relationships as well 0..1

66. 66© Ellis Cohen 2001-2008 1:M Relationships UML Chen Crow Magnum Easy Crow Magnum EmployeeDept works for EmployeeDept works for EmployeeDept works for * 0..1 Employee Dept works for

67. 67© Ellis Cohen 2001-2008 1:1 Relationships EmployeeDesk sits at UML EmployeeDesk sits at Chen 0..1 EmployeeDesk EmployeeDesk Crow Magnum Easy Crow Magnum sits at

68. 68© Ellis Cohen 2001-2008 M:N Relationships EmployeeProject assigned to Chen No key constraints! EmployeeProject assigned to EmployeeProject Crow Magnum Easy Crow Magnum assigned to EmployeeProject assigned to * * UML

69. 69© Ellis Cohen 2001-2008 Mandatory Participation

70. 70© Ellis Cohen 2001-2008 Child Participation Mandatory: An Employee MUST work for 1 Dept Dept Employee Dept Employee works for Indeterminate Deferred participation design decision Child Entity ClassParent Entity Class

71. 71© Ellis Cohen 2001-2008 Mandatory Child Participation (Every employee is assigned to 1 department) 7698BLAKE2850 7499ALLEN1600300 7654MARTIN12501400 7986STERN1500 7844TURNER15000 10SALES 30ACCOUNTING Dept Employee works for Every Employee participates in a relationship with a Dept Child Entity ClassParent Entity Class

72. 72© Ellis Cohen 2001-2008 Non-Mandatory Child Participation (There may be employees with no dept) 7698BLAKE2850 7499ALLEN1600300 7654MARTIN12501400 7986STERN1500 7844TURNER15000 10SALES 30ACCOUNTING Dept Employee works for There are Employees who don't participate in a relationship with a Dept Child Entity ClassParent Entity Class

73. 73© Ellis Cohen 2001-2008 Mandatory Child Participation in UML UML Crow Magnum EmployeeDept works for * EmployeeDept works for an Employee must be assigned to 1 Dept 1 Child Entity ClassParent Entity Class

74. 74© Ellis Cohen 2001-2008 Parent Participation Mandatory: MUST be 1 Employee in every Dept Dept Employee Dept Employee Indeterminate: Deferred participation design decision works for Child Entity ClassParent Entity Class

75. 75© Ellis Cohen 2001-2008 Mandatory Parent Participation (Every department has at least 1 employee) 7698BLAKE2850 7499ALLEN1600300 7654MARTIN12501400 7986STERN1500 7844TURNER15000 10SALES 30ACCOUNTING Dept Employee works for Every Dept participates in a relationship with an Employee Child Entity ClassParent Entity Class

76. 76© Ellis Cohen 2001-2008 Non-Mandatory Parent Participation (There may be depts with no employees) Dept Employee works for 7698BLAKE2850 7499ALLEN1600300 7654MARTIN12501400 7986STERN1500 7844TURNER15000 10SALES 30ACCOUNTING 20RESEARCH There are Depts who don't participate in a relationship with Employees Child Entity ClassParent Entity Class

77. 77© Ellis Cohen 2001-2008 Mandatory Parent Participation in UML UML Crow Magnum EmployeeDept works for 1..* EmployeeDept works for a Dept must have at least 1 employee Child Entity ClassParent Entity Class 0..1

78. 78© Ellis Cohen 2001-2008 Reflexive 1:M Relationships

79. 79© Ellis Cohen 2001-2008 Reflexive Entity Attributes Employee empno ename addr mgr Suppose an employee can have a manager, (who is another employee) This could identify an employee's manager. Perhaps it would hold the empno or ename of the manager. IS THIS OK OR A BAD IDEA? DON'T DO THIS!

80. 80© Ellis Cohen 2001-2008 Entity Attributes & Relationships What's wrong with adding deptno as an attribute of Employee? DeptEmployee works for deptno dname empno ename addr deptno DON'T DO THIS!

81. 81© Ellis Cohen 2001-2008 Attributes vs Relationships Employee empno ename addr mgr DON'T DO THIS! mgr would be an entity attribute – an attribute whose value identifies some other entity – in this case, some other employee But entity attributes reflect relationships But entity attributes reflect relationships – e.g. an employee is related (by the manages relationship) to the employee who is their manager. The conceptual model is meant to show relationships. Replace entity attributes by relationships!

82. 82© Ellis Cohen 2001-2008 Reflexive Relationships Employee manages Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText) Employee( empno, ename, addr ) Employee manages (*) Employee An employee may manage other employees This does not imply that a manager can manage themselves (which would probably be a bad idea!) It doesn’t disallow it either. We'll see how to do that later. empno ename addr

83. 83© Ellis Cohen 2001-2008 Reflexive Relationships & Instance Hierarchies 7698BLAKE2850 7499ALLEN1600300 7654MARTIN12501400 7566JONES2975 7844TURNER15000 7839KING5000 Reflexive relationships commonly describe entity hierarchies: KING manages BLAKE & JONES BLAKE manages MARTIN & TURNER JONES manages ALLEN, etc.

84. 84© Ellis Cohen 2001-2008 Complete Conceptual Model with Attributes Sometimes, designers draw a more detailed diagram that includes the attributes of an entity class (sometimes JUST the primary key attributes) DeptEmployee works for deptno dname empno ename addr manages

85. 85© Ellis Cohen 2001-2008 Entity Classes Employee( empno, ename, addr ) Dept( deptno, dname ) Relationships WorksFor WorksFor: (*) Employee works for Dept Manages Manages: Employee manages (*) Employee Visual/Textual Conceptual Model DeptEmployee works for manages empnodeptno Note: here we chose to just show the primary keys Note: MUST list all conceptual attributes here Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText)

86. 86© Ellis Cohen 2001-2008 Class Identification & Surrogate Keys

87. 87© Ellis Cohen 2001-2008 Entity Class Identification Exercise A clothing manufacturer identifies each style of item they make by their own unique stylecode. Items within the same style vary by size and color, and each such item is given an itemsku. Each style of item has a category identified by its catid. Create a conceptual model (UML or Easy Crow Magnum ER Diagram) for the manufacturer's database, which includes the following attributes itemsku e.g. 'FX311B-24M' stylecode e.g. '302' stylenam e.g. 'Hunting Bikini Brief' styledate e.g. 1992 (when introduced) catid e.g. 'MU' catnam e.g. 'Mens Underwear' size e.g. 9 color e.g. 'red'

88. 88© Ellis Cohen 2001-2008 Answer to Entity Class Identification Exercise Item( itemsku, size, color ) Style( stylecode, stylenam, styledate ) Category( catid, catnam ) ItemStyle: (*) Item has Style StyleCategory: (*) Style has Category StyleItem has itemsku size color stylecode stylenam styledate Category has catid catnam TEXTUAL Conceptual Model (Brief ConText Entity Classes) VISUAL Conceptual Model (Easy Crow Magnum)

89. 89© Ellis Cohen 2001-2008 Surrogate Primary Key Item itemsku size color Item itemid itemsku size color vs Why would you add a surrogate key? Surrogate primary key: A new attribute added to an entity class or relation and used in place of the original primary key. Note: We often wait to add surrogate keys until we map the conceptual model to a relational model

90. 90© Ellis Cohen 2001-2008 Simple Candidate Keys Item itemid itemsku size color Simple Candidate Keys A simple candidate key is any attribute which uniquely identifies a tuple A designer chooses a primary key from one of the candidate keys Both itemid and itemsku uniquely identify an item

91. 91© Ellis Cohen 2001-2008 Redundancy & Anomalies

92. 92© Ellis Cohen 2001-2008 Normalization Problem In designing a conceptual model for employees with the attributes empno, ename, deptno, dname, addr What's wrong with just using a single entity class: Employee( empno, ename, deptno, dname, addr )?

93. 93© Ellis Cohen 2001-2008 Answer: What's Wrong … Entity Class Principles: substance, extensibility, multiplicity, association argue that there should be a Dept class Redundancy: deptno & dname Extra Work: If changed name of a department, would have to do it in multiple places Anomalies: Could change deptno without changing dname or vice versa.

94. 94© Ellis Cohen 2001-2008 Redundancy: deptno  dname empno deptno dname Employee 7654…30SALES… Entities with the same value for deptno have the same value for dname Including dname in the entity class is redundant, since it can be derived from deptno Redundancy causes duplicate work Suppose the company wants to change deptno 30 to be the Sales & Marketing department. That change must be made to multiple employees 798650SUPPORT 769830SALES 783910ACCOUNTING 784430SALES

95. 95© Ellis Cohen 2001-2008 Redundancy and Anomaly Redundancy can cause anomalies (inconsistencies) if modifications are not done carefully Update Anomaly: –Updating a value in a single cell can make the database inconsistent Insertion Anomaly: –Adding an entity can make the database inconsistent Deletion Anomaly: –Deleting some information can make the database inconsistent or cause unintended loss of information

96. 96© Ellis Cohen 2001-2008 Anomaly Examples Modification Anomaly: Modify 7654's dname to 'SUPPORT' (without changing its deptno) Insert Anomaly: Insert a new employee with a deptno of 20, and a dname of 'SUPPORT' Delete Anomaly: Delete employee 7986 (it’s the only employee in SUPPORT, and no other entity class keeps track that dept 50 is SUPPORT) Employee empno deptno dname 7654…30SALES… 798650SUPPORT 769830SALES 783910ACCOUNTING 784430SALES

97. 97© Ellis Cohen 2001-2008 Simple Functional Dependencies

98. 98© Ellis Cohen 2001-2008 Redundancy and Functional Dependencies Functional Dependencies Specify which attributes in a entity class are determined by other attributes Identify potential redundancies Help us see how to eliminate those redundancies (generating the conceptual model we really should have produced initially!)

99. 99© Ellis Cohen 2001-2008 Functional Dependencies (FD's) Dependencies among attributes A  B A functionally determines B B functionally depends on A The value of A uniquely determines a single value for B If two or more entities (of a specific entity class) have the same value for A, they have the same value for B (e.g. Every employee that has the same value for deptno – e.g. 30 has the same value for dname – e.g. SALES)

100. 100© Ellis Cohen 2001-2008 FD's for a Normalized Example Employee( empno, ename, addr ) empno  ename empno  addr This can also be written as empno  ename, addr orempno  { ename, addr } Also empno  empno (this is a trivial FD, which we usually don't write) empno can be used to lookup (and therefore uniquely determine) all the other attributes of an Employee tuple

101. 101© Ellis Cohen 2001-2008 Determinants & Dependents Determinant Dependent empno  addr

102. 102© Ellis Cohen 2001-2008 FD's for an Example with Redundancy Employee( empno, ename, deptno, dname, addr ) empno  ename empno  deptno empno  dname empno  addr However, also deptno  dname (possibly) dname  deptno This is a problem! deptno is NOT a candidate key It indicates redundancy!

103. 103© Ellis Cohen 2001-2008 Redundancy: deptno  dname Because deptno is not a candidate key, the same deptno value (e.g. 30) can appear multiple times. But deptno  dname, that is, two tuples with the same value of deptno have the same value of dname Voila! REDUNDANCY! empno deptno dname Employee 7654…30SALES… 798650SUPPORT 769830SALES 783910ACCOUNTING 784430SALES

104. 104© Ellis Cohen 2001-2008 Simple FD Exercise Assume you have (foolishly) designed a single Item entity class containing all of the following attributes itemsku e.g. 'FX311B-24M' stylecode e.g. '302' stylenam e.g. 'Hunting Bikini Brief' styledate e.g. 1992 (when introduced) catid e.g. 'MU' catnam e.g. 'Mens Underwear' size e.g. 9 color e.g. 'red' Find all the simple FD's whose determinant is not a candidate key

105. 105© Ellis Cohen 2001-2008 Non-Candidate-Key FD's catid  catnam stylecode  stylenam stylecode  styledate stylecode  catid stylecode  catnam follows by transitive inference, because stylecode  catid & catid  catnam

106. 106© Ellis Cohen 2001-2008 Simple Conceptual Normalization

107. 107© Ellis Cohen 2001-2008 Simple Conceptual Normalization Given an entity class with a (non-trivial) functional dependency whose determinant is NOT a candidate key –Split out a new entity class –Make the determinant the primary key (or at least a candidate key) of the new class –Move all attributes that depend on it Employee( empno, ename, deptno, dname, addr ) deptno  dname Employee( empno, ename, addr ) Dept( deptno, dname ) Note: Most books only discuss Normalization at the Relational Design level. However, Conceptual Normalization, though not complete, is a way to improve a conceptual design. We'll examine Normalization in much more detail later in the term

108. 108© Ellis Cohen 2001-2008 Result of Simple Conceptual Normalization Each simple conceptual normalization step –adds one entity class –adds one 1:M relationship link Employee empno ename deptno dname addr Employee has empno ename addr Dept deptno dname deptno  dname

109. 109© Ellis Cohen 2001-2008 Conceptual Normalization Exercise Assume you have designed an Item entity class with the following attributes itemsku e.g. 'FX311B-24M' stylecode e.g. '302' stylenam e.g. 'Hunting Bikini Brief' styledate e.g. 1992 (when introduced) catid e.g. 'MU' catnam e.g. 'Mens Underwear' size e.g. 9 color e.g. 'red' Find an FD with a non-candidate-key determinant, and use Conceptual Normalization to split out a new entity class. Continue doing this with all of the resulting entity classes until each of them are in Conceptual Normal Form.

110. 110© Ellis Cohen 2001-2008 ER Decomposition (a) StyleItem has itemsku size color stylecode stylenam styledate Category has catid catnam Item itemsku stylecode stylenam styledate catid catnam size color Item has itemsku size color Style stylecode stylenam styledate catid catnam stylecode  stylenam, styledate, catid catnam catid  catnam Each simple conceptual normalization step adds one entity class adds one relationship link Step 1 Step 2

111. 111© Ellis Cohen 2001-2008 ER Decomposition (b) StyleItem has itemsku size color stylecode stylenam styledate Category has catid catnam Item itemsku stylecode stylenam styledate catid catnam size color Item has itemsku stylecode stylenam styledate size color Category catid catnam catid  catnam stylecode  stylenam, styledate Each simple conceptual normalization step adds one entity class adds one relationship link Step 1 Step 2

112. 112© Ellis Cohen 2001-2008 Database Design Process Requirements Physical Model using DDL & DCL Relational Model Conceptual Model Conceptual Design & Conceptual Normalization Relational Mapping & Relational Normalization Physical Mapping