Relationship Review

▪ Each time an attribute of one entity type refers to another entity type, some relationship exists. ▪ In ER diagrams, these references should be represented as relationships, rather than attributes. ▪ For example, in the Company database schema, an attribute of employee is the department they work for, rather than representing this information as an attribute of the Employee entity type, it should be represented on a diagram as a relationship between the two entities. ▪ Relationships between entities are represented using a diamond shape. ▪ Relationships are usually given a verb name, which specifies the relationship between two entities. ▪ If we look at the relationship between Employee and Department, an employee works for a department, therefore the relationship would be represented

Degree of Relationship Type

▪ The degree of a relationship type is the number of participating entity types. Meaning if the relationship is between two entity types (Employee and Department), then the relationship is binary, or has a degree of two. ▪ If the relationship is between three participating entities, it has a degree of three, and therefore is a ternary relationship. ▪ For example, if we have three entities, Supplier, Project and Part. Each part is supplied by a unique supplier, and is used for a given project within a company; the relationship “Supplies” is a ternary (degree of three) between Supplier, Project and Part, meaning all three participate in the supplies relationship.

Role Names and Recursive Relationships

▪ Each entity type in a relationship plays a particular role. The role name specifies the role that a participating entity type plays in the relationship and explains what the relationship means. ▪ For example, in the relationship between Employee and Department, the Employee entity type