1. 1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 Dependent & Identifying Relationships 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 Dependent Relationships and Entity Classes Dependent Relationship Issues Composition & Containment Discriminating Dependent Instances Discriminator-Based Identification Identifying Relationships and Weak Entity Classes ER Models for Identifying Relationship Additional Relationships with Weak Entity Classes Weak Cascades Weak Entity Class Design Exercises

3. 3 © Ellis Cohen 2001-2008 Dependent Relationships and Entity Classes

4. 4 © Ellis Cohen 2001-2008 Independent Relationships and Entity Classes DeptEmployee works for PlayerDental Plan enrolled in Entity classes in a 1:M relationship are relatively independent of one another if They exist in their own right If a tuple of the parent entity class is deleted, it is reasonable to expect that the related tuples of the child entity class would survive An independent entity class is not dependent upon any of its parent classes Independent Entity Class Child Entity Class Parent Entity Class Crow Magnum

5. 5 © Ellis Cohen 2001-2008 Mandatory Participation DeptEmployee works for Crow Magnum Suppose we add mandatory child participation: If we allow a department which has employees to be deleted. Do we then expect that all the employees in that department will automatically be deleted as well?

6. 6 © Ellis Cohen 2001-2008 Composition and Dependency an invoice entry 1 … entry 2 entry 3 An invoice is composed of entries Whenever an invoice is deleted, all of its entries are deleted as well Let's consider a relationship which is dependent InvoiceEntry composed of

7. 7 © Ellis Cohen 2001-2008 Dependent Relationship Characteristics of a dependent relationship: 1.Mandatory Child Participation Every entry must be associated with an invoice. There are no unassigned entries. 2.Lifetime Dependency Constraint (a.k.a. Cascading Delete) When an invoice is deleted, all of its entries are deleted.

8. 8 © Ellis Cohen 2001-2008 Invoices & Entries Entries entryid prodnam qty price invid Invoices invid customer invdate Visually represent the relational constraints that would make this a dependent relationship

9. 9 © Ellis Cohen 2001-2008 Dependent Relationship Constraints Entries entryid prodnam qty price ! invid ! Invoices invid customer invdate Mandatory participation Cascading delete Foreign key Entries( entryid, prodnam, qty, price, invid ) invid not null references Invoices on delete cascade Do we have a way of representing all of these relational constraints in the ER model?

10. 10 © Ellis Cohen 2001-2008 ER & Relational Model InvoiceEntry composed of invid customer invdate entryid prodnam qty price Entries entryid prodnam qty price ! invid ! Invoices invid customer invdate Mandatory participation + business rule: deleting an invoice deletes all its entries Cascading delete

11. 11 © Ellis Cohen 2001-2008 Representing Dependent Relationships InvoiceEntry contained in invid customer invdate entryid prodnam qty price Crow Magnum symbol for dependent relationship Dependent Class Child Entity Class Parent Entity Class Owner Class Dependent Relationship Mandatory Participation Lifetime Dependency

12. 12 © Ellis Cohen 2001-2008 Implied Mandatory Participation InvoiceEntry part of InvoiceEntry part of Mandatory participation required and implied with dependent relationships Hollow crow's foot indicates the dependent relationship, which leads to the owner Dependent Entity Class Owner Entity Class dependent relationship (i.e. dependent upon …) Child Entity Class Parent Entity Class Crow Magnum

13. 13 © Ellis Cohen 2001-2008 Easy Crow Magnum Dependent Relationships Crow Magnum Easy Crow Magnum InvoiceEntry part of entryid prodnam qty price invid customer invdate InvoiceEntry part of entryid prodnam qty price invid customer invdate Crow Magnum Easy Crow Magnum

14. 14 © Ellis Cohen 2001-2008 Mapping Dependent Relationships InvoiceEntry contained in invid customer invdate entryid prodnam qty price Entries entryid prodnam qty price invid ! Invoices invid customer invdate Mandatory participation Cascading delete

15. 15 © Ellis Cohen 2001-2008 SQL for Dependent Relationship CREATE TABLE Invoices ( invidnumber(5) primary key, customernumber(8), invdatedate ) CREATE TABLE Entries ( entryidnumber(9) primary key, prodnamvarchar(30), qtynumber(4), pricenumber(8,2), invidnumber(5) not null references Invoices on delete cascade) Entries entryid prodnam qty price invid ! invid customer invdate Invoices

16. 16 © Ellis Cohen 2001-2008 Relational Specification of Dependent Relationships Visual CONCEPTUAL Model (Crow Magnum) InvoiceEntry part of entryid prodnam qty price invid customer invdate BRIEF Textual RELATIONAL Model Entries entryid prodnam qty price invid ! Invoices invid customer invdate Visual RELATIONAL Model (Relational Schema) Invoices( invid, customer, invdate ) Entries( entryid, prodnam, qty, price, invid ) invid not null references Invoices on delete cascade Relational "fingerprint" of a dependent relationship Crow Magnum

17. 17 © Ellis Cohen 2001-2008 Instances in Dependent Relationships Entries 30492… 30493… 30494… invid … Invoices 25961230492… 25961330493 25961430493 25961530493 25961630494 entryid invid … 3 entries of invoice 30493 InvoiceEntry part of entryid prodnam qty price Has own primary key invid customer invdate Dependent Entity Class Owner Entity Class Crow Magnum

18. 18 © Ellis Cohen 2001-2008 Describing Dependent Relationships Entity Classes Invoice( invid, customer, invdate ) [Invoice] Entry( entryid, prodnam, qty, price ) Relationships EntryPart: (*) Entry part of (1) Invoice VISUAL Conceptual Model (Crow Magnum) TEXTUAL Conceptual Model (Brief ConText) Invoice part of invid customer invdate entryid prodnam qty price A bit redundant (implied by the definition of Entry), but it adds the name of the dependent relationship Entry Crow Magnum

19. 19 © Ellis Cohen 2001-2008 1:M Crow Magnum Relationships Independent Mandatory Mandatory Participation Dependent Mandatory Participation Lifetime Dependency

20. 20 © Ellis Cohen 2001-2008 1:M Relational Schema Dept Div deptno divno Dept Div deptno Dept Div deptno divno Depts deptno divno ! Divs divno … Depts deptno divno ! Divs divno … Depts deptno divno Divs divno …

21. 21 © Ellis Cohen 2001-2008 Dependent Relationship Issues

22. 22 © Ellis Cohen 2001-2008 Dependent Entity Class InvoiceEntry contained in invid customer invdate entryid qty price Entries entryid prodnam ! qty price invid ! Invoices invid customer invdate Product prodnam descr purchased in Products prodnam descr A dependent entity class is dependent on (at least one) of its parent classes

23. 23 © Ellis Cohen 2001-2008 Mandatory Parent Participation? InvoiceEntry part of What does this diagram mean? How does it affect the relational schema?

24. 24 © Ellis Cohen 2001-2008 Mandatory Parent Participation InvoiceEntry part of An Entry is dependent upon an Invoice Mandatory Child Participation: An entry must have an associated invoice Lifetime Dependency: If an invoice is deleted, so are all its entries Mandatory Parent Participation: An invoice must have at least one entry. There's no way to represent mandatory parent participation in the standard relational schema. A state assertion is required

25. 25 © Ellis Cohen 2001-2008 M:N Dependent Relationships? ProjectEmployee assigned to Can an M:N Relationship be dependent? Is this LEGAL? If so, what does it mean? If not, why not? ?

26. 26 © Ellis Cohen 2001-2008 No M:N Dependent Relationships ProjectEmployee The most useful possible interpretation is: An employee must be assigned to a project, and An employee is deleted when ALL the projects to which the employee is assigned are deleted. However, because This is rarely needed There is no direct SQL support for it We do NOT allow it. If needed, this deletion integrity constraint must be stated explicitly. X

27. 27 © Ellis Cohen 2001-2008 Composition & Containment

28. 28 © 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 0..1

29. 29 © Ellis Cohen 2001-2008 Composition an invoice entry 1 … entry 2 entry 3 Composition is stronger than dependency It implies aggregation, dependency & participation Aggregation: an invoice is made up of entries (part/whole) Dependency: deleting an invoice deletes all of its entries Mandatory Child Participation: every entry is associated with an invoice

30. 30 © Ellis Cohen 2001-2008 Dependency & UML Composition * UML EntryInvoice Crow Magnum InvoiceEntry part of For part/whole relationships, the corresponding UML construct is called composition, a strengthened form of aggregation with mandatory participation, lifetime dependency, and containment

31. 31 © Ellis Cohen 2001-2008 UML Containment Entry * Invoice UML In UML, composition can be visually represented as containment. Entry* means that an Invoice can contain multiple entries

32. 32 © Ellis Cohen 2001-2008 UML Containment with Attributes UML Entry * PK entryid prodnam qty price Not quite standard. UML doesn't allow attributes in containment diagrams Entry Invoice PK entryid prodnam qty price PK invid customer invdate entries: Entry[*] UML Explicit Containment Invoice PK invid customer invdate Implicit Containment

33. 33 © Ellis Cohen 2001-2008 Crow Magnum Containment Invoice Crow Magnum invid customer invdate Entry entryid prodnam qty price contains * Crow Magnum also uses containment diagrams for composition lifetime dependency mandatory participation aggregation An invoice contains many (*) entries

34. 34 © Ellis Cohen 2001-2008 Discriminating Dependent Instances

35. 35 © Ellis Cohen 2001-2008 Discriminating Entries an invoice entry 1 invid: 30493 … entry 2 entry 3 Different entries in an invoice can be discriminated by their line number Adding a linenum attribute will allow a query to order the entries by their line number

36. 36 © Ellis Cohen 2001-2008 Crow Magnum InvoiceEntry part of invid customer invdate entryid linenum ! prodnam qty price Entries entryid linenum ! prodnam qty price invid ! Invoices invid customer invdate It really should never be NULL Adding Discrimination Attribute

37. 37 © Ellis Cohen 2001-2008 Unique Discrimination an invoice entry 1 invid: 30493 … entry 2 entry 3 Different entries in an invoice can be discriminated by their line number In fact, the line number (in conjunction with the invid) uniquely identifies an entry

38. 38 © Ellis Cohen 2001-2008 Discriminating Identification Example Entries 30492… 30493… 30494… invid customer … Invoices 25961217 …30492 259613130493 259614230493 259615330493 259616130494 entryid linenum … invid 3 entries of invoice 30493 Entries entryid linenum ! prodnam qty price invid ! Invoices invid customer invdate

39. 39 © Ellis Cohen 2001-2008 Relational Uniqueness Constraint Entries entryid linenum ! prodnam qty price invid ! Invoices invid customer invdate An entry is uniquely identified by the combination of an invoice id and line number Entries( entryid, prodnam, qty, price, invid ) invid not null references Invoices on delete cascade linenum not null unique( invid, linenum )

40. 40 © Ellis Cohen 2001-2008 SQL for Discriminating Attributes CREATE TABLE Invoices ( invidnumber(5) primary key, customernumber(8), invdatedate ) CREATE TABLE Entries ( entryidnumber(9) primary key, linenumnumber(4) not null, prodnamvarchar(30), qtynumber(4), pricenumber(8,2), invidnumber(5) not null references Invoices on delete cascade, unique( invid, linenum ) ) Entries entryid linenum ! prodnam qty price invid ! Invoices invid customer invdate

41. 41 © Ellis Cohen 2001-2008 Discrimination Constraint + State Constraint: An Entry's linenum uniquely identifies a particular Entry associated with an Invoice Discrimination in Crow Magnum is explicitly specified as a state constraint Crow Magnum InvoiceEntry part of invid customer invdate entryid linenum ! prodnam qty price

42. 42 © Ellis Cohen 2001-2008 UML Qualifying Association Entry Invoice PK entryid linenum prodnam qty price PK invid customer invdate UML linenum contains 1 0..1 Specifies the state constraint An Entry's linenum uniquely identifies a particular Entry associated with an Invoice Note: While this does reflect the discrimination constraint, it doesn't reflect lifetime dependency!

43. 43 © Ellis Cohen 2001-2008 Qualification & Composition Entry Invoice PK entryid linenum prodnam qty price PK invid customer invdate UML linenum contains 1 0..1 Adding composition adds lifetime dependency *

44. 44 © Ellis Cohen 2001-2008 UML Qualified Composition Entry Invoice PK entryid linenum prodnam qty price PK invid customer invdate UML linenum contains 1 0..1 Combining qualification & composition Not strictly standard UML

45. 45 © Ellis Cohen 2001-2008 Discriminator- Based Identification

46. 46 © Ellis Cohen 2001-2008 Discriminating Attribute Model Crow Magnum InvoiceEntry part of invid customer invdate entryid linenum ! prodnam qty price + State Constraint: An Entry's linenum uniquely identifies a particular Entry associated with an Invoice Entries entryid linenum ! prodnam qty price invid ! Invoices invid customer invdate

47. 47 © Ellis Cohen 2001-2008 Switching Primary Key Entries entryid linenum ! prodnam qty price invid ! Invoices invid customer invdate Entries entryid ! linenum prodnam qty price invid Invoices invid customer invdate Both entryid and invid + linenum are candidate keys. Let's make invid + linenum the primary key instead!

48. 48 © Ellis Cohen 2001-2008 Eliminating Surrogate Key Entries linenum prodnam qty price invid Invoices invid customer invdate Entries entryid ! linenum prodnam qty price invid Invoices invid customer invdate entryid is really unnecessary Let's eliminate it.

49. 49 © Ellis Cohen 2001-2008 Reordering Attributes Entries invid linenum prodnam qty price Invoices invid customer invdate Entries linenum prodnam qty price invid Invoices invid customer invdate List the primary key attributes first invid + linenum uniquely identify an Entry

50. 50 © Ellis Cohen 2001-2008 Discriminating Identification Example Entries 30492… 30493… 30494… invid customer … Invoices 3049217 … 304931 2 3 304941 invid linenum prodnam … 3 entries of invoice 30493 What's the corresponding Crow Magnum model? Entries invid linenum prodnam qty price Invoices invid customer invdate

51. 51 © Ellis Cohen 2001-2008 No Entity Attributes! InvoiceEntry part of invid customer invdate invid linenum prodnam qty price No entity attributes! An entity cannot include an attribute which identifies another entity! NO! Employee Dept empno ename deptno deptno

52. 52 © Ellis Cohen 2001-2008 Linenum is Not Unique! InvoiceEntry part of invid customer invdate linenum prodnam qty price invid also needs to be part of the primary key Entries linenum prodnam qty price invid ! Invoices invid customer invdate NO!

53. 53 © Ellis Cohen 2001-2008 Eliminate the Primary Key InvoiceEntry part of invid customer invdate linenum ! prodnam qty price Now Entries has no primary key, which would allow multiple entries with the same invid + linenum Entries linenum ! prodnam qty price invid ! Invoices invid customer invdate NO!

54. 54 © Ellis Cohen 2001-2008 Require Uniqueness Constraint InvoiceEntry part of invid customer invdate linenum ! prodnam qty price + added state constraint: There is at most one entry for a given invoice and linenum Entries linenum ! prodnam qty price invid ! Invoices invid customer invdate invid + linenum is unique & non-null. Upgrade it to a primary key as part of relational mapping

55. 55 © Ellis Cohen 2001-2008 Identifying Relationships and Weak Entity Classes

56. 56 © Ellis Cohen 2001-2008 Weak Identity Entries invid linenum prodnam qty price Invoices invid customer invdate Entries have weak identity An entry does not have its own identity. It's identity is based on invid, the identity of its parent combined with the linenum attribute which discriminates among multiple entries with the same invid

57. 57 © Ellis Cohen 2001-2008 Identifying Relationship Characteristics of an identifying relationship: 1.Mandatory Child Participation Every entry must be associated with an invoice. There are no unassigned entries. 2.Lifetime Dependency Constraint When an invoice is deleted, all of its entries are deleted. 3.Weak Identity The identity of instances of the child class (the weak entity class) are dependent upon the identity of its parent (the identifying owner) Dependent Relationship

58. 58 © Ellis Cohen 2001-2008 Weak Entity Instance Diagram 1Slop Soup1 $2.50 1Duff Beer10$2.87 2Mint Jam1$4.11 2Sterno4$1.29 3Lamb Leg1$12.99 30493… 30494… entries invoices Each invoice has a number of entries associated with it. An entry is not uniquely identified by its linenum, but only by the combination of the linenum and the invid of its associated invoice linenum invid

59. 59 © Ellis Cohen 2001-2008 Weak Entity Class A weak entity class does not have its own primary key It's identity is based on the identity of its identifying owner InvoiceEntry part of invid customer invdate linenum prodnam qty price Weak Entity Class Identifying Owner Crow Magnum

60. 60 © Ellis Cohen 2001-2008 Crow Magnum Identifying Relationships InvoiceEntry part of invid customer invdate linenum prodnam qty price Crow Magnum uses a dotted underline to indicate an instance discriminator. Instance discriminators discriminate instances associated with the same identifying owner. They can only be used in conjunction with an identifying relationship, which points to the identifying owner, who supplies the rest of the primary key Crow Magnum Crow Magnum symbol for identifying relationship Identifying Owner * Weak Entity Class

61. 61 © Ellis Cohen 2001-2008 Instance Discriminator Rules In a Crow Magnum diagram an instance discriminator is only used in a weak entity class In fact, a 1:M weak entity class is effectively a dependent entity class with an instance discriminator that is distinguished by a dotted underline A Relational schema Never uses dotted underlines. However, it may have a composite primary key which contains its entity class's instance discriminator. *

62. 62 © Ellis Cohen 2001-2008 Relational Mapping of Identifying Relationships Entries invid linenum prodnam qty price Invoices invid customer invdate Composite primary key Visual CONCEPTUAL Model (Crow Magnum) Visual RELATIONAL Model (Relational Schema) Instance Discriminator Relational "fingerprint" of an identifying relationship * InvoiceEntry part of invid customer invdate linenum prodnam qty price

63. 63 © Ellis Cohen 2001-2008 Relational Model for Identifying Relationships CREATE TABLE Invoices ( invidnumber(8) primary key, customernumber(8), invdatedate ) CREATE TABLE Entries ( invidnumber(8) references Invoices on delete cascade, linenumnumber(4), prodnamvarchar(40), qtynumber(3), pricenumber(7,2), primary key( invid, linenum ) ) Entries invid linenum prodnam qty price Invoices invid customer invdate Composite primary key. Part of it (invid) is a foreign key

64. 64 © Ellis Cohen 2001-2008 Nested Relation Implementation 30492…… 30493…… ……… … invid customer invdate entries linenumprodnamqtyprice …WIDGET…… 17GADGET…… 1……… 2… 3……… But not part of standard relational model or SQL. Supported by Oracle (but we won’t say how!) Invoices InvoiceEntry part of invid customer invdate linenum prodnam qty price Crow Magnum

65. 65 © Ellis Cohen 2001-2008 Describing Identifying Relationships Entity Classes Invoice( invid, customer, invdate ) [Invoice] Entry( linenum, prodnam, qty, price ) Relationships EntryPart: (*) Entry part of (1) Invoice VISUAL Conceptual Model (Crow Magnum) TEXTUAL Conceptual Model (Brief ConText) Invoice part of invid customer invdate linenum prodnam qty price Instance Discriminator A bit redundant (implied by the definition of Entry), but it adds the name of the identifying relationship Entry Crow Magnum

66. 66 © Ellis Cohen 2001-2008 1:M Crow Magnum Relationships Independent Mandatory Mandatory Participation Dependent Mandatory Participation Lifetime Dependency Identifying Mandatory Participation Lifetime Dependency Weak Identity

67. 67 © Ellis Cohen 2001-2008 1:M Relational Schema Dept Div deptno divno Dept Div deptno Dept Div deptno Dept Div deptno divno Depts divno deptno Divs divno … Depts deptno divno ! Divs divno … Depts deptno divno ! Divs divno … Depts deptno divno Divs divno …

68. 68 © Ellis Cohen 2001-2008 Composite Discriminators Suppose an invoice was divided into pages, and each page had its own line numbers. Then an entry would only be discriminated by the combination of page number and line number! InvoiceEntry part of invid customer invdate pagenum linenum prodnam qty price Weak Entity Class Identifying Owner Crow Magnum

69. 69 © Ellis Cohen 2001-2008 Relational Mapping of composite Discriminators Entries invid pagenum linenum prodnam qty price Invoices invid customer invdate Composite primary key Visual CONCEPTUAL Model (Crow Magnum) Visual RELATIONAL Model (Relational Schema) InvoiceEntry part of invid customer invdate pagenum linenum prodnam qty price

70. 70 © Ellis Cohen 2001-2008 Weak Identity without Dependency? Entries invid linenum prodnam qty price Invoices invid customer invdate No cascading delete! What's the corresponding conceptual model? Weak Identity

71. 71 © Ellis Cohen 2001-2008 Access Pre-Conditions Eliminate Cascading Delete Entries invid linenum prodnam qty price Invoices invid customer invdate Visual CONCEPTUAL Model (Crow Magnum) Visual RELATIONAL Model (Relational Schema) InvoiceEntry part of invid customer invdate linenum prodnam qty price + business rule: An invoice with entries cannot be deleted No cascading delete!

72. 72 © Ellis Cohen 2001-2008 Weak Identity without Dependency Dept Div deptno Dept Div deptno divno Depts divno deptno Divs divno … + business rule: A division with departments cannot be deleted + state constraint: There is at most one department for a given division & deptno

73. 73 © Ellis Cohen 2001-2008 ER Models for Identifying Relationships

74. 74 © Ellis Cohen 2001-2008 Identifying Relationships in Chen Entry Invoice part of invidlinenum Chen Crow Magnum Easy Crow Magnum linenum InvoiceEntry part of invid linenum Entry invid Invoice part of Note the thickening of the lines around the weak entity class, the identifying relationship and the arrow between them

75. 75 © Ellis Cohen 2001-2008 UML Qualifying Composition Entry Invoice linenum prodnam qty price PK invid customer invdate UML linenum identified by 1 0..1 Crow Magnum InvoiceEntry part of invid customer invdate linenum prodnam qty price Entry doesn’t have a PK of its own, so it must be a weak entity class

76. 76 © Ellis Cohen 2001-2008 UML with Discriminating Keys Crow Magnum InvoiceEntry part of invid customer invdate linenum prodnam qty price EntryInvoice * DK linenum prodnam qty price PK invid customer invdate DK: Discriminating Key (non-standard) UML

77. 77 © Ellis Cohen 2001-2008 UML Identifying Containment with Attributes UML Entry * DK linenum prodnam qty price Entry Invoice DK linenum prodnam qty price PK invid customer invdate entries: Entry[*] UML Explicit Containment Invoice PK invid customer invdate Implicit Containment Not quite standard due to DK & because UML doesn't allow attributes in containment diagrams

78. 78 © Ellis Cohen 2001-2008 Crow Magnum Identifying Containment Invoice Crow Magnum invid customer invdate Entry linenum prodnam qty price contains * An invoice contains many (*) entries Underlining indicates an identifying relationship with Invoice

79. 79 © Ellis Cohen 2001-2008 Alternate Crow's Foot Model InvoiceEntry part of Product for Crow Magnum InvoiceEntry part of Product for Alternate Crow's Foot (ignoring participation) In alternate Crow's Foot representations, all 1:M relationships use the standard Crow's Foot Ordinary independent relationships are drawn with dashed lines, while continuous lines are only used for identifying relationships InvoiceEntryProduct Alternate Crow's Foot (with Participation)

80. 80 © Ellis Cohen 2001-2008 Additional Relationships with Weak Entity Classes

81. 81 © Ellis Cohen 2001-2008 Weak Entity Class Relationships InvoiceEntry part of invid customer invdate linenum qty price Entity Classes Invoice( invid, customer, invdate ) [Invoice] Entry( linenum, quantity, price ) Product( productid, productnam, description ) Relationships EntryPart: (*) Entry part of (1) Invoice ProductEntry: (*) Entry for (0..1) Product Product productid prodnam description for VISUAL Conceptual Model (Crow Magnum) TEXTUAL Conceptual Model (Brief ConText) What is the relational schema?

82. 82 © Ellis Cohen 2001-2008 Relational Schema: Weak Entity Class Relationships Visual CONCEPTUAL Model (Crow Magnum) Visual RELATIONAL Model (Relational Schema) Entries invid linenum productid qty price Invoices invid customer invdate Products productid prodnam description InvoiceEntry part of invid customer invdate linenum qty price Product productid prodnam description for

83. 83 © Ellis Cohen 2001-2008 Deletion Integrity Choices Suppose we want to delete a product when it no longer is available. What kind of deletion integrity rule should be used by the foreign key Entries.productid? Cascading Delete: When the product is deleted, all entries for that product are deleted. Deassignment: When the product is deleted, the productid of entries which reference the product are set to NULL. Restricted Deletion: A product can’t be deleted if there are entries which reference it. Entries invid linenum productid qty price Invoices invid customer invdate Products productid prodnam description Which of these make sense?

84. 84 © Ellis Cohen 2001-2008 Deletion Integrity Choices Assume: Product is deleted when it is no longer available Cascading Delete: When the product is deleted, all entries for that product are deleted. –Probably shouldn't just disappear from the invoice –What about orders which have already been shipped! Deassignment: When the product is deleted, the productid of entries which reference the product are set to NULL. –But then the customer has no idea what the entry was for! Restricted Deletion: A product can’t be deleted if there are products which reference it –But then once it appears in an invoice, it's in the database forever –How do we indicate that a product is no longer available? What to do?

85. 85 © Ellis Cohen 2001-2008 Use Status Fields & Archives Add Entry.status –Has values FILLED, WAITING, UNAVAILABLE Add Invoice.shipDate –Set to date when entire order is actually shipped (no entries can be WAITING) Add Product.dropDate –Set to date when the product becomes available (any entry for the product that is WAITING is set to UNAVAILABLE) Keep a separate table of AllProducts (includes ones which are no longer available), OldInvoices & OldEntries 6 Months after an order is shipped Move the invoice to OldInvoices Move its entries to an OldEntries table, with productid references AllProducts, invid references OldInvoices 12 months after a product is dropped Delete it from the Products table, with restricted deleted

86. 86 © Ellis Cohen 2001-2008 Weak Cascades

87. 87 © Ellis Cohen 2001-2008 Example Weak Cascade Requirements Draw the ER diagram for these requirements: A database keeps track of invoices for customers, identified by a customer id (custid) Invoices are identified by an invoice number (invnum) specific to a customer. Invoice entries are identified by the line number (linenum) of the invoice.

88. 88 © Ellis Cohen 2001-2008 Cascading Weak Entity Classes InvoiceEntry part of invnum invdate linenum qty price prodnam Customer custid name address ordered by Entity Classes Customer( custid, name, address ) [Customer] Invoice( invnum, invdate ) [Invoice] Entry( linenum, qty, price, prodnam ) Relationships EntryPart: (*) Entry part of (1) Invoice CustInvoice: (1) Customer orders via (*) Invoice VISUAL Conceptual Model (Crow Magnum) TEXTUAL Conceptual Model (Brief ConText) What is the relational schema?

89. 89 © Ellis Cohen 2001-2008 Incorrect Mapping VISUAL Conceptual Model (Crow Magnum) Entries invnum linenum qty price prodnam Invoices custid invnum invdate Visual RELATIONAL Model (Relational Schema) Customers custid name address InvoiceEntry part of invnum invdate linenum qty price prodnam Customer custid name address Why is this wrong? ordered by X

90. 90 © Ellis Cohen 2001-2008 Mapping Weak Cascades VISUAL Conceptual Model (Crow Magnum) Entries custid invnum linenum qty price prodnam Invoices custid invnum invdate Visual RELATIONAL Model (Relational Schema) Customers custid name address InvoiceEntry part of invnum invdate linenum qty price prodnam Customer custid name address ordered by An entry is relative to an invoice, but an invid is uniquely identified by custid + invnum

91. 91 © Ellis Cohen 2001-2008 SQL for Weak Cascades Entries custid invnum linenum qty price prodnam Invoices custid invnum invdate Customers custid name address CREATE TABLE Invoices ( custidnumber(7) references Customers on delete cascade, invnumnumber(5), invdatedate, primary key( custid, invnum ) ) CREATE TABLE Entries ( custidnumber(7), invnumnumber(5), linenumnumber(4) not null, qtynumber(4), pricenumber(8,2), prodnamvarchar(30), foreign key( custid, invnum ) references Invoices on delete cascade, primary key( custid, invnum, linenum ) )

92. 92 © Ellis Cohen 2001-2008 Eliminating Composite FKs Visual RELATIONAL Model (Relational Schema) BRIEF Textual RELATIONAL Model Customers( custid, name, address ) Invoices( custid, invnum, invdate ) custid references Customers on delete cascade Entries( custid, invnum, linenum, qty, price, prodnam ) foreign key( custid, invnum) references Invoices on delete cascade How can the composite foreign key be avoided? Entries custid invnum linenum qty price prodnam Invoices custid invnum invdate Customers custid name address

93. 93 © Ellis Cohen 2001-2008 Using Surrogate Primary Keys VISUAL Conceptual Model (Crow Magnum) Entries invid linenum qty price prodnam Invoices invid custid ! invnum ! invdate Visual RELATIONAL Model (Relational Schema) Customers custid name address Added surrogate primary key during mapping to eliminate composite foreign key InvoiceEntry part of invnum invdate linenum qty price prodnam Customer custid name address What if we added the surrogate key directly to the conceptual model? ordered by

94. 94 © Ellis Cohen 2001-2008 Transforming Weak Cascades with Surrogate Primary Keys VISUAL Conceptual Model (Crow Magnum) Visual RELATIONAL Model (Relational Schema) InvoiceEntry part of invid invnum invdate linenum qty price prodnam Customer custid name address Entries invid linenum qty price prodnam Invoices invid custid ! invnum ! invdate Customers custid name address + state constraint: Every Invoice has an invnum which is unique per Customer ordered by

95. 95 © Ellis Cohen 2001-2008 Weak Entity Class Design Exercises

96. 96 © Ellis Cohen 2001-2008 Methodology for Design Exercises 1)Identify Entity Classes 2)Identify Relationships among the Entity Classes with their cardinalities 3)Decide which attribute is part of which entity class (each attribute must be part of exactly one class) 4)Identify the primary keys / instance discriminators, identify which 1:M relationships are dependent or identifying

97. 97 © Ellis Cohen 2001-2008 Weak Entity Design Exercise a Clothing manufacturers identify each style of item they make by an industry-wide stylecode. Items within the same style vary by size and color, and each such item is given an itemsku, unique to the manufacturer. Each style of item has a category. Category names & ids are defined industry-wide. Design the Easy Crow Magnum Diagram & then the Relational Schema for the store's database: itemsku e.g. 'FX311B-24M' manufid e.g. 'TWILCO' manufnam e.g. 'Twill Textile Corp' manufzip e.g. '02445' 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' Do NOT add surrogate primary keys!

98. 98 © Ellis Cohen 2001-2008 StyleItemCategory Manufacturer ER Diagram for Exercise a has itemsku size color stylecode stylenam styledate has catid catnam manufid manufnam manufzip manufactures Now draw the Relational Schema

99. 99 © Ellis Cohen 2001-2008 StyleItemCategory Manufacturer Relational Schema for Exercise a has itemsku size color stylecode stylenam styledate has catid catnam Items Styles manufid itemsku size color stylecode stylenam styledate catid Categories catid catnam manufid manufnam manufzip Manufacturers manufid manufnam manufzip manufactures Visual CONCEPTUAL Model (Easy Crow Magnum) Visual RELATIONAL Model (Relational Schema)

100. 100 © Ellis Cohen 2001-2008 Weak Entity Design Exercise b Clothing manufacturers identify each style of item they make by their own stylecode. Items within the same style vary by size and color, and each such item is given an itemsku, unique to the style. Each style of item has a category. Category names & ids are defined industry-wide. Design the Easy Crow Magnum Diagram & then the Relational Schema for the store's database : itemsku e.g. 'FX311B-24M' manufid e.g. 'TWILCO' manufnam e.g. 'Twill Textile Corp' manufzip e.g. '02445' 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' Do NOT add surrogate primary keys!

101. 101 © Ellis Cohen 2001-2008 ER Diagram for Exercise b StyleItem has itemsku size color stylecode stylenam styledate Category has catid catnam Manufacturer manufid manufnam manufzip determines Now draw the Relational Schema

102. 102 © Ellis Cohen 2001-2008 Relational Schema Exercise b StyleItem has itemsku size color stylecode stylenam styledate Category has catid catnam Items Styles manufid stylecode itemsku size color manufid stylecode stylenam styledate catid Categories catid catnam Manufacturer manufid manufnam manufzip Manufacturers manufid manufnam manufzip determines A good place to add a surrogate primary key