COMM 226 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) 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 In general, a form or a report is NOT an entity –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 –Notable exception: An Invoice is often expressed as an entity, with InvoiceLine as a bridge entity (M:M) connecting the invoice to products 2

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 have zero or many employees; one employee can have one and only one department 1:M: One ( II ) on the department side, many ( O< ) on the employee side –One department can have zero or one managers; one manager can manage zero or one departments 1:1: One ( OI ) on the department side, one ( OI ) on the manager side –One project can have zero or many employees; one employee can have zero or many projects M:M: Many ( O< ) on the project side, many ( O< ) on the employee side 3

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 the 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 –Verify with the instructor or tutor to make sure –Most common valid 1:1 cases: IS-A: A person is a specific type of person. E.g. an Employee is an Accountant, a Doctor is a Specialist, a Student is an Employee, etc. Boss, where you can only have one boss. E.g. Employee manages a Department, Student is president of a Club, etc. 4

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 –Bridge/associative entities from M:M relationships, 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 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 5

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

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 7

Designing an ERD: Stage 2 (paper draft) Verify attributes, add PKs and 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 –In a 1:M relationship (including bridge entities), the PK from the one side must be added to the many side as a FK –In a 1:1 relationship, add the FK to only one of the sides that has mimimum 0, maximum 1 cardinality 8

Designing an ERD: Stage 3 (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 9