Practical tips for creating entity relationship diagrams (ERDs)

Chitu OkoliAssociate Professor in Business Technology ManagementJohn Molson School of Business, Concordia University, Montréal

1

2

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

3

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

4

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

5

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

6

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

7

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 sense

8

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

Major stages for designing an ERD1. 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

10

Designing an ERD: Stage 1 (paper draft)

Identify entities, attributes and relationships1. 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

11

Designing an ERD: Stage 2 (paper draft)

Verify attributes, select PKs, add FKs

1. Populate all your entities with attributes2. 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

12

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 optimization

13

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