Practical tips for creating entity relationship diagrams (ERDs) Chitu Okoli Associate Professor in Business Technology Management John Molson School of Business, Concordia University, Montréal 1

What is an ENTITY in a business case? An entity is a noun (person, place, thing or event) that contains details (the details will be attributes) –If it contains no details whatsoever (not even a name or description), then it might be an attribute of something else, not an entity in its own right Attributes are also nouns (persons, places, things or dates), but they are not entities if they describe other things –E.g. a name or date is a noun, but it describes a thing, e.g. a person or product; therefore name or date is the attribute, and the Person or Product is the entity 2

Common false entities: The Organization that owns or operates the database The organization that owns the database is NEVER modeled as an entity within the database However, its customers, suppliers, and other organizations for which it stores data will be modeled Multiple branches or locations within the organization might be modeled, but never the overall organization itself 3

Common false entities: Forms and reports In general, a form or a report is NOT an entity –A form is an input tool that receives data that needs to go into a database –A report is an output tool that displays data taken from a database –Forms and reports are great sources for identifying entities and attributes, but they normally represent multiple entities at the same time However, the EVENT associated with a form or report is often an entity –E.g. An order form is not an entity, but an Order event is an entity –E.g. A job application form is not an entity, but the JobApplication event is an entity –Even when a form or report represents an event, multiple entities are usually involved Notable exception (which is not really an exception): An Invoice is often expressed as an entity, with InvoiceLine as a bridge entity (M:M) connecting the Invoice to Product –Actually, the “Invoice” entity is just an Order event (an invoice is just a report for a single order), and “InvoiceLine” could just as well be called OrderedProduct 4

What kind of RELATIONSHIP is it? To accurately determine a relationship, you must always test each side in turn. For each side, you must ask: –One instance of EntityA can have zero/one or one/many instance(s) of EntityB? –One instance of EntityB can have zero/one or one/many instance(s) of EntityA? Examples: –One department can employ zero or many employees; one employee can work for one and only one department 1:M: One ( II ) on the department side, many ( O < ) on the employee side –One department can be managed by zero or one managers; one manager can manage zero or one departments 1:1: One ( IO ) on the department side, one ( OI ) on the manager side –One project can employ zero or many employees; one employee can work for zero or many projects M:M: Many ( > O ) on the project side, many ( O < ) on the employee side 5

How COMMON are various kinds of RELATIONSHIP? One-to-many (1:M) is the most common Many-to-many (M:M) is quite common, but in an ERD, it must always be decomposed into two 1:M relationships One-to-one (1:1) is actually rather rare –Most of the time when you think it’s 1:1, you’ve done something wrong –Double- and triple-check to make sure it really is 1:1 6

Legitimate 1:1 relationships IS-A or supertype/subtype: –E.g. A person is a specific type of person: an Employee is an Accountant, a Doctor is a Specialist, a Student is an Employee –E.g. A product is a specific type of product: a Bicycle is a type of Vehicle, a Violin is a type of MusicalInstrument Boss, where you can only have one boss –E.g. Employee manages a Department, Student is president of a Club Some kinds of scarce resource allocation –E.g. one employee can be assigned only one company car Marriage: one person can be married to only one other person at a time NOTE: None of these can store historical information –Once you add dates to track historical changes, it becomes M:M In addition to these, there are other database performance scenarios where 1:1 relationships could make sensedatabase performance scenarios 7

Naming conventions Entities and attributes –Be consistent in your naming style –No spaces allowed in names Use either CamelCaseForAllWords or underscores_between_all_words –Entity and attribute names are always a singular noun, not plural –For bridge/associative entities from M:M relationships, there are two choices: Be creative in forming a noun from the verb of the relationship. E.g. for Employee and Project, name the bridge entity “Assignment” Simply form a name by merging the two constituent entity names. E.g. for Employee and Project, name it EmployeeProject or ProjectEmployee Relationships –Relationship names are mandatory in an ERD! –Do not use “has” to name relationships—it is meaningless E.g. Don’t use “Customer has Order” or “Order has Product” –Relationship names are always verbs, usually lower case; spaces are allowed –Relationships are named from the one side to the many side For 1:1 relationships, they are named from the side with the PK to the side with the FK 8

Major stages for designing an ERD 1.Identify the entities, attributes and relationships from the business case description (paper draft) 2.Verify the attributes, select primary keys, and add foreign keys (paper draft) 3.Draw the ERD using modeling software 9

Designing an ERD: Stage 1 (paper draft) Identify entities, attributes and relationships 1.Identify entities (main nouns) and attributes (nouns that are details of entities) –Analyze the case top-down first (entities, then attributes) –Analyze again, this time bottom-up (attributes, then entities) –Each attribute must apply specifically and only to its own entity –Don't worry about primary keys and foreign keys at this stage 2.Identify relationships between entities –It is never the case that all entities are related to all relationships. You must make sure that the relationship exists. –For a relationship to exist, the description must mention the entities involved together in the same sentence. Otherwise, there is no relationship. –Use the two-step procedure for verifying 1:M, M:M or 1:1 (first verify one side of the relationship, and then the other side) –Verify minimum and maximum cardinalities for each relationship (e.g. minimum 0, maximum many; minimum 1, maximum 1 3.Convert any M:M relationships into two 1:M relationships 10

Designing an ERD: Stage 2 (paper draft) Verify attributes, select PKs, add FKs 1.Populate all your entities with attributes 2.Review and revise attributes –In particular, verify if some of the attributes identified earlier might actually belong in the new bridge entities created for M:M 3.Decide on the primary keys (PK, unique identifiers) for each entity 4.Add any appropriate foreign keys (FK) to all entities 5.Normalize each entity to fourth normal form (4NF) –Normalization might require you to make major revisions to some entities –If revisions are required, reiterate until you are satisfied with all the entities 11

In which entity does the foreign key go? 1:M (including bridge entities): –The PK from the one side must be copied to the many side as a FK 1:1: –Copy the FK to only one of the sides that has mimimum 0, maximum 1 cardinality –(1,1):(0,1): Foreign key goes on (0,1) side –(1,0):(0,1): Foreign key goes on whichever side will cause fewer nulls –(1,1):(1,1): This relationship almost never exists in the real world. You probably made a mistake. Verify your cardinalities, or merge the two tables. Exception: this relationship is sometimes used for database performance optimizationdatabase performance optimization 12

Designing an ERD: Stage 3 (modeling software) Draw the ERD 1.Draw the final ERD using software –Stages 1 and 2 are paper drafts; you don’t touch the software until you’ve got your paper drafts polished –If you draw something in software at the beginning, it is much harder to see and correct your errors 13