Entity Relationship Model

What Does a Data Analyst Do? Identify and understand business rules that govern data. Represent those rules so that they can be unambiguously understood by information systems developers and users. Implement those rules in database technology.

Data Modeling Documenting business rules and policies of an organization that govern data. E-R (entity-relationship) Model: Entity, Relationship, and Attribute A tool for communications between database designers and end users during database development Expressed as an E-R diagram.

Business Rules Are statements that define or constrain some aspect of the business Foundation of data models

Business Rules Are statements that define or constrain some aspect of the business Are derived from policies, procedures, events, functions Represent fundamental structure of an organization Control/influence business behavior Govern how data are handled and stored Foundation of data models Are automated through DBMS software

Examples of Business Rules Naming: STUDENT Definition: A student is any person who has applied for admission or taken a course or training program from any credit or noncredit unit of the university. Constraint: Every student in the university must have a faculty adviser. A student may register for a section of a course only if he or she has successfully completed the prerequisites for that course.

A Good Business Rule Is: Declarative–what, not how Precise–clear, agreed-upon meaning Atomic–one statement Consistent–internally and externally Expressible–structured, natural language [Entity A] [Minimum] [Relationship] [Maximum] [Entity B] [A student] [may] [take] [at most five] [courses] Distinct–non-redundant Business-oriented–understood by business people Statement of Enforcement not how Only one interpretation Indivisible No conflict statements

E-R Model Constructs Entities: Relationships: Attribute A person, place, object, event, concept Relationships: Link between entities Attribute property or characteristic of an entity or relationship type (often corresponds to a field in a table) 2

E-R Model Constructs Entities: Relationships: Entity instance–person, place, object, event, concept (often corresponds to a row in a table) Entity Type–collection of entities (often corresponds to a table) Relationships: Relationship instance–link between entities (corresponds to primary key-foreign key equivalencies in related tables) Relationship type–category of relationship…link between entity types Attribute–property or characteristic of an entity or relationship type (often corresponds to a field in a table) 2

Figure 1-3 Comparison of enterprise and project level data models Segment of a project-level data model Segment of an enterprise data model

Sample E-R Diagram (Figure 2-1) Two rules each relationship 3

Basic E-R notation (Figure 2-2) Entity symbols Attribute symbols A special entity that is also a relationship Relationship symbols Relationship degrees specify number of entity types involved Relationship cardinalities specify how many of each entity type is allowed 8

Entities A person, place, object, event, concept. For example: An entity has a noun name For example: Person: EMPLOYEE, STUDENT, PATIENT Place: STORE, UNIVERSITY Object: MACHINE, BUILDING, AUTOMOBILE Event: SALE, REGISTRATION, SHIPMENT Concept: ACCOUNT, COURSE Entity instance: A single occurrence of an entity

Entities Entity Entity Instance

Entity Entity Instance

An Entity… SHOULD BE: SHOULD NOT BE: An object that will have many instances in the database An object that will be composed of multiple attributes An object that we are trying to model SHOULD NOT BE: A user of the database system An output of the database system (e.g., a report)

Inappropriate entities Figure 2-4 Example of inappropriate entities System user System output Inappropriate entities Appropriate entities

Strong vs. Weak Entities

Strong vs. Weak Entities Strong entity exists independently of other types of entities Ex. STUDENT, EMPLOYEE, AUTOMOBILE, COURSE has its own unique identifier (attribute) identifier underlined with single line Most of real world entities are strong entities.

More about Identifier An identifier is an attribute whose value distinguishes individual instances of an entity. No two instances of the entity may have the same value for the identifier attribute For example STUDENT: Student ID COURSE: Course ID CUSTOMER: Customer ID AUTOMOBILE: VIN Inappropriate identifiers STUDENT: Lastname COURSE: Classroom CUSTOMER: Date of purchase AUTOMOBILE: Make

Strong vs. Weak Entities Weak entity (aka: dependent entity) dependent on a strong entity (identifying owner)…cannot exist on its own Ex. Dependents of an Employee Connect to identifying owner through identifying relationship does not have a unique identifier (only a partial identifier) partial identifier underlined with double line entity box has double line

Figure 2-5 Example of a weak identity and its identifying relationship Strong entity Weak entity

More Examples BUILDING APARTMENT TEXTBOOK EDITION COURSE Assignment Has Building Name Apartment Number TEXTBOOK EDITION Title Includes Edition Number COURSE Assignment Course id Is Assigned Assignment Number

Attributes Attribute–property or characteristic of an entity (or relationship) Attribute has a noun name 5

Entities Attributes STUDENT AUTOMOBILE EMPLOYEE Student ID, Student Name, Home Address, Phone Number, E-mail VIN, Make, Model, Color, Plate Number Employee ID, Employee Name, Department, Dependent ID

Entity Attributes Entity Instance

Metadata

E-R Diagram EMPLOYEE AUTOMOBILE Employee ID FirstName LastName Entity Identifier EMPLOYEE Employee ID FirstName LastName Department Phone Num E-Mail AUTOMOBILE VIN Make Attributes Model Year Color Plate Num

Classifications of attributes Required versus Optional Attributes Simple versus Composite Attributes Identifier Attributes Single-Valued versus Multi-valued Attributes Stored versus Derived Attributes

Required versus Optional Attributes Required attribute An attribute that must be present for each entity instance An identifier is also an required attribute (Boldface in an E-R diagram) Optional attribute An attribute that may not have a value

Simple versus Composite Attributes Simple attribute An attribute that cannot be broken down into smaller components VIN, Color, Make, Model Composite attribute An attribute that has meaningful component parts (which are simple attributes) Address (Street Address, City, State, Postal Code) Name (First name, Middle, Last name)

An attribute broken into component parts

Composite Attributes (Employee Address) Composite Attributes (Employee Name) You can decide whether to create a composite attribute or a single attribute as a whole. The choice depends on whether users will need to refer to both the composite attribute and its components.

Identifiers (Keys) Identifier (Key)–an attribute (simple or composite) that uniquely identifies individual instances of an entity Candidate Identifier–an attribute that could be a key. It satisfies the requirements for being an identifier 6

Figure 2-9 Simple and composite identifier attributes The identifier is boldfaced and underlined Composite Identifier: An identifier that consists of a composite attribute 14

Candidate Identifiers Identifier

Criteria for Identifiers Choose Identifiers that Will not change in value Will not be null Substitute simple keys for long, composite keys 7

Single-Valued versus Multi-valued Attributes An attribute that may take on more than one value for a given entity instance Indicated by using curly brackets around attrubute names. Single-valued attribute An attribute that can only take on one value for a give entity instance

Multivalued Attribute

Stored versus Derived Attributes An attribute whose values can be calculated from related attribute values Ex. “Years Employed” attribute Can be calculated from the Date Employed attribute and current date Indicated by using square brackets around the attribute name.

from date employed and current date Multivalued an employee can have more than one skill Derived from date employed and current date Order total

Figure 2-7 A composite attribute An attribute broken into component parts Figure 2-8 Entity with multivalued attribute (Skill) and derived attribute (Years Employed) Multivalued an employee can have more than one skill Derived from date employed and current date 12

Figure 2-19 Simple example of time-stamping This attribute is both multivalued and composite 37

Relationships Relationship is an association representing and interaction among (the instances of) one or more entities. A relationship has a verb phrase name

More on Relationships Relationship vs. Relationship Instances The relationship is modeled as lines between entities The relationship instance is between specific entity instances

Employee Course

Figure 2-10 Relationship types and instances a) Relationship b) Relationship instances 17

Relationships can have attributes These describe features pertaining to the association between the entities in the relationship In other words, these attributes describe features for EACH relationship instances. Normally associate with many-to-many relationship (not one-to-many) => WHY?

Relationship Instances Employee Name Date Completed Course Title Chen 1/1/2011 C++ Chen 1/8/2011 Java Melton 1/7/2011 C++ Melton 1/15/2011 COBOL Melton 2/1/2011 SQL Celko 1/20/2011 Perl Celko 2/3/2011 SQL

Why only Many-to-Many relationships can be associated with attributes? Employee Course Employee Course Employee Course

Why only Many-to-Many relationships can be associated with attributes? Date Completed ???

Associative Entities An entity that associates the instances of one or more entities and contains attributes that are peculiar to the relationship between those entity instances. It is an entity – has attributes You can also regard it as a relationship – links entities together Associative Entity

Figure 2-11b An associative entity (CERTIFICATE) EQUALS TO Associative entity is like a relationship with an attribute, but it is also considered to be an entity in its own right Note that the many-to-many cardinality between entities in Figure 2-11a has been replaced by two one-to-many relationships with the associative entity 21

When should a relationship with attributes instead be an associative entity? All relationships for the associative entity should be many-to-many The associative entity could have meaning independent of the other entities (Certificate in the previous example) The associative entity preferably has a unique identifier, and should also have other attributes The associative entity may participate in relationships other than the entities of the associated relationship

Cardinality of Relationships One-to-One Each entity in the relationship will have exactly one related entity One-to-Many An entity on one side of the relationship can have many related entities, but an entity on the other side will have a maximum of one related entity Many-to-Many Entities on both sides of the relationship can have many related entities on the other side

Cardinality Constraints Cardinality Constraints—the number of instances of one entity that can or must be associated with each instance of another entity Minimum Cardinality If zero, then optional If one or more, then mandatory Maximum Cardinality The maximum number of entity instances can be involved in the relationship 29

Employee Project Maximum, Many Is assigned to Minimum, Mandatory Optional

Also called “Mandatory one”

Figure 2-17 Examples of cardinality constraints A patient history is recorded for one and only one patient A patient must have recorded at least one history, and can have many 1

Figure 2-17 Examples of cardinality constraints (cont.) b) One optional, one mandatory A project must be assigned to at least one employee, and may be assigned to many An employee can be assigned to any number of projects, or may not be assigned to any at all 1

Figure 2-17 Examples of cardinality constraints (cont.) c) Optional cardinalities A person is married to at most one other person, or may not be married at all 1

Team Student of INF202 Maximum number of team members (5) 5 3 Participate Minimum number of team members (3)

(normally) Must be mandatory one

Cardinality constraints are difficult to specify. You should always convert a ternary relationship into associative entity Cardinality constraints are difficult to specify. 36

Multiple relationships Two entities can have more than one type of relationship between them

Figure 2-21 Examples of multiple relationships a) Employees and departments Entities can be related to one another in more than one way 40

Figure 2-21 Examples of multiple relationships (cont.) b) Professors and courses (fixed lower limit constraint) Here, min cardinality constraint is 2. At least two professors must be qualified to teach each course. Each professor must be qualified to teach at least one course. 40

Business Rule (try it yourself) A company has a number of employees. The attributes of EMPLOYEE include Employee ID (identifier), Name, Address, and Birthdate. The company also has several projects. Attributes of PROJECT include Project ID (identifier), Project Name, and Start Date. Each employee may be assigned to one or more projects, or may not be assigned to a project. A project must have at least one employee assigned and may have any number of employee assigned.

A company has a number of employees A company has a number of employees. The attributes of EMPLOYEE include Employee ID (identifier), Name, Address, and Birthdate. The company also has several projects. Attributes of PROJECT include Project ID (identifier), Project Name, and Start Date. Each employee may be assigned to one or more projects, or may not be assigned to a project. A project must have at least one employee assigned and may have any number of employee assigned. An employee’s billing rate may vary by project, and the company wishes to record the applicable billing rate (Billing Rate ) for each employee when assigned to a particular project.

Figure 2-15a and 2-15b Multivalued attributes can be represented as relationships simple composite

Associative Entities An entity–has attributes A relationship–links entities together When should a relationship with attributes instead be an associative entity? All relationships for the associative entity should be many The associative entity could have meaning independent of the other entities The associative entity preferably has a unique identifier, and should also have other attributes The associative entity may participate in other relationships other than the entities of the associated relationship Ternary relationships should be converted to associative entities

Figure 2-11a A binary relationship with an attribute Here, the date completed attribute pertains specifically to the employee’s completion of a course…it is an attribute of the relationship 20

Figure 2-11b An associative entity (CERTIFICATE) Associative entity is like a relationship with an attribute, but it is also considered to be an entity in its own right Note that the many-to-many cardinality between entities in Figure 2-11a has been replaced by two one-to-many relationships with the associative entity 21

Figure 2-13c An associative entity – bill of materials structure This could just be a relationship with attributes…it’s a judgment call 27

Figure 2-18 Cardinality constraints in a ternary relationship 36

Multiple relationships Two entities can have more than one type of relationship between them

Figure 2-21 Examples of multiple relationships a) Employees and departments Entities can be related to one another in more than one way 40

Figure 2-21 Examples of multiple relationships (cont.) b) Professors and courses (fixed lower limit constraint) Here, min cardinality constraint is 2. At least two professors must be qualified to teach each course. Each professor must be qualified to teach at least one course. 40

A company has a number of employees A company has a number of employees. The attributes of EMPLOYEE include Employee ID (identifier), Name, Address, and Birthdate. The company also has several projects. Attributes of PROJECT include Project ID (identifier), Project Name, and Start Date. Each employee may be assigned to one or more projects, or may not be assigned to a project. A project must have at least one employee assigned and may have any number of employee assigned. An employee’s billing rate may vary by project, and the company wishes to record the applicable billing rate (Billing Rate ) for each employee when assigned to a particular project.

A Student has ID, Name, and Major as attributes. Each Student need to take at least three Courses. Each Course has ID, Name, and Classroom as its attributes. Each Course needs to be taken by 5 to 25 students. Each Course can be offered by different Departments. Each Department offers at least one Course. Each Course keeps its Course history. Attributes of Course history include Semester and Num. of students. Each Course is offered for at least one Semester. Attributes of Department include Code, Name, and Location. Each Student is assigned to one Professor for advice. Each Professor can advise up to 3 students (may be 0). Each Professor is kept track of his/her ID, Name, and Area of Interest. A Professor can have multiple Areas of Interest. For each Area of Interest, Level of Expertise is specified. (Please represent these rules in one Entity) Each Professor belongs to one or two Departments. Each Department has more than one Professor. A Course is taught by one or two Professors. A Professor may teach up to three courses.

The firm has a number of sales offices in several states The firm has a number of sales offices in several states. Attributes of sales office include Office Number and Location. Each sales office is assigned one or more employees. Attributes of employee include Employee ID and Employee Name. An employee must be assigned to only one sales office. Each employee is supervised by one and only one supervisor (who is also an employee). Each supervisor may supervise at most five employees. For each sales office, there is always one employee assigned to manage that office. An employee may manage only the sales office to which he or she is assigned. The firm lists property for sale. Attributes of property include Property ID and Location. Components of Location include Address, City, State, and Zip code. Each unit of property must be listed with one (and only one) of the sales offices. A sales office may have any number of properties listed or may have no properties listed. Each unit of property has one or more owners. Attributes of owners are Owner ID and Owner Name. An owner may own one or more units of property. An attribute of the relationship between property and owner is Percent Owned.