Entity Life Cycle College of Alameda Copyright © 2008 Patrick McDermott Caspar David Friedrich ( ) The Stages of Life, c. 1835

Cycle Status: OR Reincarnation: Order is Received  Allocated  Filled  Shipped  Paid  Closed. Requisition  PO  Payable Order  Shipment  Receivable Lead  Prospect  Applicant  Employee  Retiree

SQL Create: INSERT Read: SELECT Update: UPDATE Delete: DELETE

Insertion Constraints 1. Dependent—Permit insertion of child entity occurrence only when matching parent entity occurrence already exists. 2. Automatic—Always permit insertion of child entity occurrence. If parent entity occurrence does not already exist, create it. 3. Nullify—Always permit insertion of child entity occurrence. If matching parent entity occurrence does not exist, set foreign key in child to null. 4. Default—Always permit insertion of child entity occurrence. If matching parent entity occurrence does not exist, set foreign key in child to a previously defined default value. 5. Customized—Permit insertion of child entity occurrence only if certain cus­tomized validity constraints are met. 6. No Effect—Always permit insertion of child entity occurrence. No match­ing parent entity occurrence need exist, and thus no validity checking need be done.

Insertion Examples 1. The user must issue the order to an existing supplier (dependent insert rule). 2. The user may issue the order to an existing or new supplier. If the supplier is new, the user adds that supplier to the approved list of suppliers (automatic insert rule). 3. The user must either issue the order to an existing supplier or record the order without any supplier specification (nullify insert rule). 4. The user must either issue the order to an existing supplier or place it with McD, Inc., the default supplier (default insert rule). 5. The user must issue orders to a supplier who has no more than four orders currently outstanding (customized insert rule). There are, of course, many possible customized insert rules. 6. The user may issue orders even to suppliers not on the approved list. No validity checking is necessary (no effect insert rule). Someone should monitor these supplier numbers.

Parent Deletion Constraints 1. Restrict—Permit deletion of parent entity occurrence only when there are no matching child entity occurrences. 2. Cascade—Always permit deletion of parent entity occurrence and cascade the deletion to any matching child entity occurrences (i.e., delete all matching child entity occurrences). 3. Nullify—Always permit deletion of parent entity occurrence. If any matching child entity occurrences exist, set their foreign keys to null. 4. Default—Always permit deletion of parent entity occurrence. If any matching child entity occurrences exist, set their foreign keys to a previously fined default value. 5. Customized—Permit deletion of parent entity occurrence only if certain customized validity constraints are met. 6. No Effect—Always permit deletion of parent entity occurrence. Matching child entity occurrences mayor may not exist, and thus no validity checking need be done.

Parent Examples 1. The user may not terminate suppliers if the supplier has outstanding orders (restrict delete rule). 2. The user cancels any outstanding orders when terminating a supplier (cascade delete rule). 3. The user retains outstanding orders on file after terminating a supplier, but updates the orders to reflect their unassigned status (nullify delete rule). 4. The user reassigns outstanding orders to Jones, Inc., the default supplier, after terminating the original supplier (default delete rule). 5. The user does not immediately terminate suppliers with outstanding orders, but instead flags them for review at a subsequent date (customized delete rule). Again, there are many possible customized delete rules. 6. The user terminates suppliers regardless of whether the supplier has outstanding orders. No validity checking is necessary (no effect delete rule). Someone should monitor these supplier numbers.

New Key Domain too Small Phones B/L’s Must Change Primary Key for all records Must Change All Foreign Keys Must change all screens Must change all reports