Use the boxes above to navigate between slides.
Press the N or P keys on your keyboard to access the Next and Previous Slides.
Press the B key to return to the top of the page.
If there is audio associated with a slide, you will see an audio controller appear.
If the audio controls are present press the play button to start the audio, and the pause button to stop it.
If you exit a slide before the audio is complete do not worry. The audio will stop playing, and will be ready for you the next time you access the slide.
An Entity-Relationship (E-R) Diagram visually depicts an organization's entities, the entities' relationships to each other, and the business rules (i.e., cardinality and dependency) associated with the relationships. It describes the data or information aspects of a business domain or its process requirements, in an abstract way.
There are three basic elements in an ER Diagram: entity, attribute, relationship. There are more elements which are based on the main elements. They are weak entity, multivalued attribute, derived attribute, weak relationship and recursive relationship. Cardinality is also used in ER diagrams to further define relationships. ERDs are usually drawn in top-to-bottom and left-to-right fashion.
Symbols and Notation
An entity can be a person, place, event, or object that is relevant to a given system. It is a thing that either exists physically or logically. For example, a gym may include customers, trainers, courses, classes, fees, transaction, order, and other items. Entities are represented in ER diagrams by a rectangle and named using a singular noun. Every entity (unless it is a weak entity) must have a minimal set of uniquely identifying attributes, which is called the entity's primary key.
Use the following guidelines:
An entity type name is a singular noun (such as CUSTOMER, STUDENT, or AUTOMOBILE).
An entity type name should be descriptive and specific to the organization. For example, a PURCHASE_ORDER for orders placed with suppliers is distinct from CUSTOMER_ORDER for orders placed by customers. Both of these entity types cannot be named ORDER.
An entity type name should be concise; for example, in a university database, use REGISTRATION for the event of a student registering for a class rather than STUDENT_REGISTRATION_FOR_CLASS.
A weak entity is an entity that depends on the existence of another entity. In more technical terms it can defined as an entity that cannot be identified by its own attributes. It uses a foreign key combined with its attributes to form the primary key. An entity like LINE ITEM on a SALES RECEIPT is a good example of this. The LINE ITEM is meaningless without a SALES RECEIPT so it depends on the existence of the SALES RECEIPT.
An attribute is a property, trait, or characteristic of an entity, relationship, or another attribute that is of interest to the organization. For example, the attribute Inventory_Item_Name is an attribute of the entity INVENTORY ITEM. An entity can have as many attributes as necessary. Meanwhile, attributes can also have their own specific attributes. For example, the attribute “Customer_Address” can have the attributes Number, Street, City, And State. These are called composite attributes. Note that some top level ER diagrams do not show attributes for the sake of simplicity. In those that do, however, attributes are represented by oval shapes. Attributes are named with singular noun.
Use the following guidelines:
An attribute name is a noun (such as Customer_ID, Age, or Product_Minimum_Price).
An attribute name should be unique. No two attributes of the same entity type may have the same name, and it is desirable, for clarity, that no two attributes across all entity types have the same name.
To make an attribute name unique and for clarity, each attribute name should follow a standard format. For example, a school may establish Student_GPA, as opposed to GPA_of_Student, as an example of the standard format for attribute naming.
Similar attributes of different entity types should use similar but distinguishing names; for example, the city of residence for faculty and students should be, respectively, Faculty_Residence_City_Name and Student_Residence_City_Name.
If an attribute can have more than one value it is called a multivalued attribute. It is important to note that this is different from an attribute having its own attributes. For example, a professor entity can have multiple course values – a PROFESSOR Teaches multiple COURSE. It is an oval shape just like an attribute, except it has two solid lines, one inside the other.
A derived attribute is an attribute based on another attribute. This is found rarely in ER diagrams. For example, for a PERSON, their Age can be determined from their birthdate. It is depicted by an oval shape with dashed lines instead of solid lines.
A relationship describes how entities interact. For example, the entity PROFESSOR may be related to the entity CLASS by the relationship Teaches. Relationships are represented by diamond shapes and are labeled using verbs. They link two entities (nouns).
If the same entity participates more than once in a relationship it is known as a recursive relationship. The classic example is that an employee can be a supervisor and be supervised, so there is a recursive relationship.
Use the following guidelines:
A relationship is a verb phrase (such as Assigned_to, Supplies, or Teaches).
Relationships represent actions, usually in the present tense. A relationship states the action taken, not the result of the action (e.g., use Assigned_to, not Assignment).
Avoid vague names, such as Has or Is_related_to. Use descriptive verb phrases taken from the action verbs found in the definition of the relationship.
Cardinality further defines relationships between entities by placing the relationship in the context of numbers. In an email system, for example, one account can have multiple contacts. The relationship in this case follows a “one to many” model. There are number of notations used to present cardinality in ER diagrams. Chen, UML, Crow’s foot, Bachman are some of the popular notations. In this class we will use UML.
The three types of relationships that can exist between entities are:
One-to-one (1:1). A 1:1 relationship exists when exactly one of the second entity occurs for each instance of the first entity. Example: PERSON Is_Married_To PERSON.
One-to-many (1:M). A 1:M relationship exists when one occurrence of the first entity can relate to many instances of the second entity, but each instance of the second entity can associate with only one instance of the first entity. Example: PROFESSOR Teaches STUDENT.
Many-to-many (M:N). A M:N relationship exists when one instance of the first entity can relate to many instances of the second entity, and one instance of the second entity can relate to many instances of the first entity. It should be noted that a M:N relationship is different from 1:1 or 1:M relationships because the event or transaction that links the two entities is actually a third entity, called an associative entity, that has its own characteristics. Example: EMPLOYEE Completes COURSE. Because many EMPLOYEE can Completes many COURSE, the Completes relationship will have an associative entity called CLASS.
Tips on How to Draw ER Diagrams
Identify all the relevant entities in a given system and determine the relationships among these entities.
An entity should appear only once in a particular diagram.
Provide a precise and appropriate name for each entity, attribute, and relationship in the diagram. Terms that are simple and familiar always beats vague, technical-sounding words. In naming entities, remember to use singular nouns. However, adjectives may be used to distinguish entities belonging to the same class (part-time employee and full-time employee, for example). Meanwhile attribute names must be meaningful, unique, system-independent, and easily understandable.
Remove vague, redundant or unnecessary relationships between entities.
Never connect a relationship to another relationship.
Back to Top