Using ER Assistant (recommended) or Visio, create an ER diagram (ERD) that has at least 5 entities but no more than 6 entities. Each entity must have a minimum of 5 attributes that full describe that entity. The 5 attribute minimum includes the primary key only (see note below about foreign keys in ER diagrams).

All entities must be connected with suitable relationship that describe not only the cardinality (1:1, 1:M, M:M) but also whether the relationship is mandatory or optional.

Every entity and relationship in your diagram must have comments describing your business rules, i.e. the purpose of the entity and attributes, its relationship cardinality, and if it is mandatory or optional. You may embed these comments into the ERD using 'Design Notes'/'Design Justification' inserts or provide them in a separate Word document.

Crow's Feet notation style is required for all relationships. If you use ER Assistant, this is the default notation style. If you use Visio, you must ensure that you properly set the use of Crow's Feet notation prior to submitting your final ERD.

Your ERD must be free of errors to receive full points. Hint: ER Assistant provides automated checks to ensure the ERD error free using the 'Check Diagram' function.

NOTE:

See Project Learning Demonstration (under Hands-On Resources) for examples on describing entities, attributes, and relationships. Examples -
Entity Name: EMPLOYEE,.,
Entity Description: employees who work in an organization
Main attributes of EMPLOYEE:
Attribute Name: L_NAME
Attribute Description: last name.
Attribute Name: F_NAME
Attribute Description: first name.
Attribute Name: DOB
Attribute Description: date of birth.

Relationship: works between EMPLOYEE and DEPARTMENT
Cardinality: 1:M between DEPARTMENT and EMPLOYEE
Business rule: a department can have zero to many employees; an employee works for one and only one department

Deliverable:

Submit the ER diagram you created as an .ERD (ER Assistant) or .VSD (Visio) file. 

Note: Foreign keys are not explicitly added in ER diagrams because foreign keys are not a construct of entity models but rather relational models. This means that you will not add a foreign key attributes to your entities. Your suitable relationships are all that is needed to determine where the foreign key is designed to go. 

For example, say you have a CUSTOMER and ORDER entity each with their own primary key (CUST_ID and ORDER_ID) with a 1:M relationship such that one and only one customer places zero, one, or many orders. It follows then that CUST_ID is a foreign key within the ORDER entity without explicitly placing a CUST_ID foreign key as an attribute on the ORDER entity.