Download ERD design tips

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
2
– Notable exception: An Invoice is often expressed as an entity,
with InvoiceLine as a bridge entity (M:M) connecting the invoice
to products
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)
–
–
–
–
2.
Identify relationships between entities
–
–
–
–
3.
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
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
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
–
–
8
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
Designing an ERD: Stage 3 (software)
Draw the ERD
1. Draw the final ERD using software
–
–
9
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