Common Data Model Patterns Ray Lockwood 1 Points: Certain patterns recur in data models. We should recognize and name these patterns.

Transcription

1 Data Modeling and Implementation Common Data Model Patterns Pg 1 Common Data Model Patterns Ray Lockwood 1 Points: Certain patterns recur in data models. We should recognize and name these patterns. Reusable data patterns There are recurring patterns in data models they're building blocks to make new models. Learn to recognize them, and they make data modeling easier. 1. Strong Entity Patterns. a. 1:1 b. 1:M c. M:M 2. ID-Dependent Relationships. a. Association b. Multivalued Attribute c. Archetype/Instance 3. Mixed Identifying and Non-Identifying Relationships. a. Line-item Pattern b. Other Mixed 4. For-Use-By Pattern. 5. Recursive Patterns. a. 1:1 Recursive Relationship b. 1:M Recursive Relationship c. M:M Recursive Relationship Peter Chen describing a pattern. 1 A Strategy for Analyzing an Organization The purpose of patterns is to help model a real-world organization. To do this, we need to see its structure. One approach is to work from the bottom-up. In the bottom-up approach we look at the forms and reports that the organization uses. We determine the entities they represent, and their relationships with each other. From this, we can build much of the organization s data model. You can also validate a data model by the using forms and reports built from the model. Users will understand forms and reports, and can offer feedback. This is much more constructive than showing them an ER diagram. In the Bottom- Up approach, we examine an organization s forms and reports to determine its important entities. The data model patterns that follow are those that correspond to structures found in forms and reports. 1 Photo from Peter Chen s interview on MSDN s channel 9 found at Goin+Deep/Dr-Peter-Chen-Entity-Relationship-Model-Past-Present-and-Future/

2 Data Modeling and Implementation Common Data Model Patterns Pg 2 Strong Entity Patterns (Plain Old Entities Important) First, let s recall the tests for recognizing a strong entity: 1. It has an identifier of its own. 2. It is logically different from other entities. There are three kinds of relationships between two strong entities: 1:1, 1:M, and M:M. How To Determine the Maximum Cardinality of Strong Entity Patterns How do you determine if a relationship is to-one or to-many? Examine a form or report to determine the cardinality in one direction. Examine a different one for the other direction. Combining the two will give the cardinality ratio: 1:1, 1:M, or M:M. You can communicate your design to the user by showing him a form or report which demonstrates the cardinality. The user can tell whether your choice of cardinality is appropriate by recognizing whether the form or report fits his needs. These are the most common, garden variety relationships. The M:M pattern can exist in the data model, but only indirectly in the database. Strong relationships involve independent, freestanding entities. ID-Dependent Relationships (Standard ID-Dependent Entities Important) ID-dependent relationships are the most obvious type of weak entity. Many data modeling tools don t even recognize other types of weak entities. There are three patterns in which an ID-dependent entity may participate: Association Pattern (Important) This example represents a price quotation from a supplier. There's a list of suppliers in the Supplier entity, a list of items in the Item entity, and a list of price quotations in the Quotation entity. Quotation Three ID-dependent patterns. The Association Pattern has the M:M intersection table with extra attributes. SupplierID ItemID Price An Association Table is similar to an Intersection Table, but contains additional information. Supplier SupplierID Street City State ItemID ListPrice Item Here, the intersection table is called an Association Table. Association Pattern

3 Data Modeling and Implementation Common Data Model Patterns Pg 3 A supplier can quote many items, and an item can be quoted by many suppliers. This is a M:M relationship, and the association table records the fact that a supplier has quoted an item, as well as the amount of the quote, and any other details. The Price attribute applies to the relationship and not to either of the entities being linked. This changes the relationship from a simple Many-to-Many Strong Entity Pattern to an Association Pattern. Multivalued Attribute Pattern (Important, happens all the time) Suppose you have a Customer entity which contains details including phone number. You realize you need to keep more than one phone number per customer. You might not know in advance how many phone numbers a customer might have. An Association Table is just an intersection table with additional attributes describing the relationship. Use this when an attribute needs to be a list. You could think of PhoneNum as being a multivalued attribute this is an attribute that, though it is a single attribute, has multiple values. The way to make this work is to put phone number into its own entity and link it to Customer by CustomerID. You might see this as obvious, but now we have a name to call it by. Customer Customer ID Street City State Zip PhoneNum Customer ID PhoneNum Multivalued Attribute Pattern Archetype/Instance Pattern (Important) An archetype is the original model from which instances are copied. When you're shopping for a house in a new subdivision, you might say I like this floor plan. Let s get one built like this but down the road on the corner. The builder might say You picked the Caledonia. It will be ready in three months. Afterwards you can tell your new neighbors that you have a Caledonia, and they'll know how your house is laid out. An master, plus duplicates. A classic ID-dependent relationship. The floor plan is the archetype for the houses built from it. Caledonia is the archetype of your new house instance. Notice that this pattern it has the same structure as the Multivalued Attribute pattern, but its purpose is different.

4 Data Modeling and Implementation Common Data Model Patterns Pg 4 FloorPlan FloorPlanID SquareFeet ID-Dependent House FloorPlanID BuildSequence Address How the Builder sees the house. ID Dependency depends on how you choose the key. Either way, the entity is still weak. FloorPlan FloorPlanID SquareFeet Weak but not ID-Dependent House Address FloorPlanId BuildSequence How the Owner sees the house. Archetype/Instance Pattern The top example shows how the builder might view the house. He would say That s the fifth house built with the Caledonia floor plan. The second example shows how everyone else would identify the house, by its address. In the first instance, House is IDdependent on FloorPlan. In the second instance, House is not ID-dependent but it is still weak. Both are examples of the Archetype/Instance model. The one you chose depends on how the user views the entities.

5 Data Modeling and Implementation Common Data Model Patterns Pg 5 Mixed Identifying and Non-Identifying Relationships There are some patterns that contain both ID-dependent and non ID-dependent relationships. Line Item Pattern This is a common pattern. A purchase order (or sales order, service order, or anything that has a list of items) has a structure that puts a header at the top of the order, and repeating line items below: ABC INC. PURCHASE ORDER Date: 05/04/2007 PO Num 8332 Comes from PurchaseOrder. Comes from Vendor. Supplier: Acme Purchasing Agent: John Smith 123 Main Street Anytown, NY Qty Item Num Description Unit Price Extended Price mm bolt Flange Comes from Buyer. Header area Line items Comes from Item. (Strong) Comes from LineItem. (ID-dependent on the header) Vendor VendorId City Buyer BuyerId Header and the LineItem are the critical entities. The other entities provide incidental relationships. PurchaseOrder PO Header PoNum Date VendorID BuyerID Product ProdNum Description Price PO Line Item Weak LineItem PoNum LineNum ProdNum UnitPrice Qty Line Item Pattern Strong

6 Data Modeling and Implementation Common Data Model Patterns Pg 6 LineItem is ID-dependent on PurchaseOrder. The other entities are strong. The reason it's called a Mixed Identifying/Non-Identifying pattern is that LineItem has two relationships. The first is the ID-dependent (weak) relationship with PurchaseOrder, and the second is the strong relationship with Product. Each line item is made up of attributes from both an ID-dependent entity and a strong entity. If a particular PurchaseOrder is deleted, we ll want to delete the line items that go along with it. It would make no sense to have line items for a purchase order that didn t exist. But if we delete a particular Product, we wouldn't delete any LineItem entities. (The line item isn't part of the same object as the product). Deleting a Product may leave some foreign key values of LineItem invalid, but we don t want the LineItem to disappear. Other Mixed ID-Dependent / Non-Dependent Patterns A mixed identifying and non-identifying relationship occurs when a strong entity (such as PurchaseOrder) has a group of rows associated with it (like LineItem) in an identifying relationship, and one of the attributes of the group is a foreign key to some other strong entity (like Item). Below is another example involving Students, Courses, and Transcripts. There are many more involving recipes, parts lists, inventory, etc. Anything with a list might be a mixed pattern. Student StudentNum First Last StartDate Course CourseNum Description Credits LineItem is weak to one entity, and strong to another. If the entity it is weak to is deleted, LineItem must be deleted, too. If the entity it is strong to is deleted, LineItem will not be deleted. Two ways of saying the same thing. If an instance in a determining relationship is deleted, the dependent instance must be deleted, too. But not so if an instance that is not in a determining relationship is deleted. Identifying (ID-Dependent) relationship In this relationship, the identifier of one entity is part of the identifier of another Weak Transcript StudentNum Semester Grade CourseNum Strong Foreign Key Non-identifying (non-id-dependent) relationship In this relationship, both keys are Identifiers of strong entities. Mixed Identifying/Non-Identifying Pattern Transcript is weak to Student, but strong to Course. If a student is deleted, all his transcript instances should be deleted, too. (You wouldn't be able to identify who once owned the transcript). But if a course is deleted, you wouldn't delete the corresponding transcript instance.

7 Data Modeling and Implementation Common Data Model Patterns Pg 7 For-Use-By Pattern The main use for subtypes is to avoid nulls for inappropriate attributes in a form. If you come across a form that says For Use By Only then you've found a candidate for the For-Use-By pattern. Here is an example: Hunting License License Number Street City State Zip For Use By Firearms Hunters Only Number of years resided in State Safety course ID For Use By Primitive Weapons Hunters Weapon type Subtypes are used to prevent large groups of nulls. Here is the ER diagram using the exclusive subtype connector symbol and the subtype/supertype relationship: HuntingLicense LicenseNum Street Supertype SafetyCourse SafetyCrsNum Date Firearm Primitive YearsReside WeaponType SafetyCrsNum Exclusive subtypes (One or the other) Subtypes are ID-dependent. For-Use-By Pattern Subtypes

8 Data Modeling and Implementation Common Data Model Patterns Pg 8 Below is an alternative diagram of the subtypes: Hunting License Firearm Primitive Supertype with subtypes This notation is much simpler but not well supported by modeling tools. SafetyCourse For-Use-By Pattern (Alternate subtype representation) Recursive Patterns (These are very handy) In a recursive relationship an, entity has a relationship with itself. There are 1:1, 1:M, and M:M varieties of these. 1:1 Recursive Pattern. (List) This pattern makes a list. Suppose we have a waiting list of people wanting to buy a new Lamborghini at their local dealer. We have the first person in the list, then the second, and so on. Each person will have one person before him and one person after him, except for the people at the head of the line and at the end of the line. This models a List. Ed John Alice Joe Queue Person PersonID First Last Address Person Ahead 1:1 Recursive Pattern

9 Data Modeling and Implementation Common Data Model Patterns Pg 9 The minimum cardinality is zero (optional) because the first person in line will have no one ahead of him, and the last person will have no one behind him. The relationship named Person Ahead could just as well be called Person Behind. When implementing this pattern, add an attribute named PersonAhead as a foreign key and give this attribute the Unique constraint. This holds the key value of the person ahead in the line. The rows will link together as though they were nodes in a linked list. Person PersonID PersonAhead First Last Address 001 Ed Smith 124 Main John Jones 21 Elm Alice Doe 16 1st Joe Watson 33 Vine 1:M Recursive Pattern (Tree) This pattern makes a tree, for example an organization chart. Each employee has one manager, and may, himself, manage many other employees. This makes the cardinality among employees 1:M (or manager-to-employees). A child has only one parent. This models a Tree. Bill Tom Fred Sue Ed John Alice Joe Harry Organizational Chart Employee EmployeeNum First Last Address Manages 1:M Recursive Pattern

10 Data Modeling and Implementation Common Data Model Patterns Pg 10 The implementation uses a foreign key, just like the 1:1 pattern. Here, we add an attribute named ManagedBy to the Employee entity as a foreign key, but in this case, without the Unique constraint. Employee EmployeeNum ManagedBy First Last Address 001 Bill Smith 124 Main Tom Jones 21 Elm Fred Doe 16 1st Sue Watson 33 Vine Ed Banks 65 Oak John Benson 42 Park Alice Jenkins 84 Maple Joe Hopkins 94 Center Harry Cramer 70 44th M:M Recursive Pattern (Network) This pattern makes a network. A bill of materials (parts list) is a good example, because a particular type of part may be used by multiple assemblies. The idea behind a bill of materials is that an assembly is composed of parts and is itself a part in a larger assembly. A network looks similar to the tree structure above, except that a child may have many parents. Television This models a Network. Cabinet Power Supply Circuit Board Front Back Knobs Transformer Parts List Resistor Capacitor Part PartNum Remember, we can t directly implement a M:M relationship. Contains This is a M:M relationship and requires an intersection table. M:M Recursive Pattern

11 Data Modeling and Implementation Common Data Model Patterns Pg 11 The minimum cardinality is zero (optional) on both sides of the relationship because a top-level assembly has no assemblies above it, and a bottom level part has no parts below it. This is implemented the same as any other M:M relationship, by adding an intersection table having two key attributes, one for the parent and one for the child. Intersection Table Part PartNum BillOfMaterials PartNum Contains Can either point upward to where the part is used, or downward to the parts it contains just be consistent. M:M Recursive Implementation Part PartNum Television Cabinet PwrSupply CircuitBrd Front Back Knobs Transformer Resistor Capacitor Etc BillOfMaterials PartNum Contains Television Cabinet Television PowerSupply Television CircuitBoard Cabinet Front Cabinet Back Cabinet Knobs PwrSupply Transformer PwrSupply Resistor PwrSupply Capacitor CircuitBrd Resistor CircuitBrd Capacitor