Entity Relationship ModelEntity 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.

5

Business RulesBusiness Rules

• Are statements that define or constrain some aspect Are statements that define or constrain some aspect of the businessof the business

• Are derived from policies, procedures, events, Are derived from policies, procedures, events, functionsfunctions

• Represent fundamental structure of an organizationRepresent fundamental structure of an organization• Control/influence business behaviorControl/influence business behavior• Govern how data are handled and storedGovern how data are handled and stored• Foundation of data modelsFoundation of data models• Are automated through DBMS softwareAre 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.

7

A Good Business Rule Is:A Good Business Rule Is:

• Declarative–what, not howDeclarative–what, not how• Precise–clear, agreed-upon meaningPrecise–clear, agreed-upon meaning• Atomic–one statementAtomic–one statement• Consistent–internally and externallyConsistent–internally and externally• Expressible–structured, natural languageExpressible–structured, natural language

• [Entity A] [Minimum] [Relationship] [Maximum] [Entity B][Entity A] [Minimum] [Relationship] [Maximum] [Entity B]• [A student] [may] [take] [at most five] [courses][A student] [may] [take] [at most five] [courses]

• Distinct–non-redundantDistinct–non-redundant• Business-oriented–understood by business Business-oriented–understood by business

peoplepeople

8

E-R Model ConstructsE-R Model Constructs

• Entities:Entities:– A person, place, object, event, conceptA person, place, object, event, concept

• Relationships:Relationships:– Link between entitiesLink between entities

• AttributeAttribute– property or characteristic of an entity or relationship type property or characteristic of an entity or relationship type

(often corresponds to a field in a table)(often corresponds to a field in a table)

Segment of an enterprise data model

Segment of a project-level data model

Figure 1-3 Comparison of enterprise and project level data models

11

Sample E-R Diagram (Figure 2-1)

12

Relationship degrees specify number of entity types involved

Entity symbols

A special entity that is also a relationship

Relationship symbols

Relationship cardinalities specify how many of each entity type is allowed

Attribute symbols

Basic E-R notation (Figure 2-2)

EntitiesEntities

• A person, place, object, event, concept.A person, place, object, event, concept.– An entity has a noun nameAn entity has a noun name

• For example:For example:– Person: EMPLOYEE, STUDENT, PATIENTPerson: EMPLOYEE, STUDENT, PATIENT– Place: STORE, UNIVERSITYPlace: STORE, UNIVERSITY– Object: MACHINE, BUILDING, AUTOMOBILEObject: MACHINE, BUILDING, AUTOMOBILE– Event: SALE, REGISTRATION, SHIPMENTEvent: SALE, REGISTRATION, SHIPMENT– Concept: ACCOUNT, COURSEConcept: ACCOUNT, COURSE

• Entity instance: A single occurrence of an entity

EntitiesEntities

Entity

EntityInstance

Entity

EntityInstance

An Entity…An Entity…• SHOULD BE:SHOULD BE:

– An object that will An object that will have many instances have many instances in the in the databasedatabase

– An object that will be An object that will be composed of multiple composed of multiple attributesattributes

– An object that we are trying to modelAn object that we are trying to model• SHOULD NOT BE:SHOULD NOT BE:

– A user of the database system A user of the database system – An output of the database system (e.g., a An output of the database system (e.g., a

report)report)

Inappropriate entities

System System useruser

System System outputoutput

Figure 2-4 Example of inappropriate entities

Appropriate entities

Strong vs. Weak EntitiesStrong vs. Weak Entities

• Strong entity Strong entity – exists independently of other types of entitiesexists independently of other types of entities

• Ex. STUDENT, EMPLOYEE, AUTOMOBILE, COURSEEx. STUDENT, EMPLOYEE, AUTOMOBILE, COURSE

– has its own unique identifier (attribute)has its own unique identifier (attribute)• identifier underlined with single lineidentifier underlined with single line

More about IdentifierMore about Identifier

• An identifier is an attribute whose value distinguishes An identifier is an attribute whose value distinguishes individual instances of an entity.individual instances of an entity.– No two instances of the entity may have the same value for the No two instances of the entity may have the same value for the

identifier attributeidentifier attribute• For exampleFor example

– STUDENT: Student IDSTUDENT: Student ID– COURSE: Course IDCOURSE: Course ID– CUSTOMER: Customer IDCUSTOMER: Customer ID– AUTOMOBILE: VINAUTOMOBILE: VIN

• Inappropriate identifiersInappropriate identifiers– STUDENT: LastnameSTUDENT: Lastname– COURSE: ClassroomCOURSE: Classroom– CUSTOMER: Date of purchaseCUSTOMER: Date of purchase– AUTOMOBILE: MakeAUTOMOBILE: Make

Strong vs. Weak EntitiesStrong vs. Weak Entities

• Weak entity (aka: Weak entity (aka: dependent entitydependent entity))– dependent on a strong entity (dependent on a strong entity (identifying owneridentifying owner)…)…

cannot exist on its owncannot exist on its own• Ex. Dependents of an EmployeeEx. Dependents of an Employee

– Connect to identifying owner through Connect to identifying owner through identifying identifying relationshiprelationship

– does not have a unique identifier (only a does not have a unique identifier (only a partial partial identifieridentifier))• partial identifier underlined with double linepartial identifier underlined with double line

– entity box has double lineentity box has double line

Strong entity Weak entity

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

More Examples

BUILDING APARTMENTBuilding Name Apartment Number

TEXTBOOK EDITIONTitle Edition Number

Has

Includes

COURSE AssignmentCourse id Assignment NumberIs Assigned

AttributesAttributes

• Attribute–property or characteristic of an Attribute–property or characteristic of an entity (or relationship)entity (or relationship)

• Attribute has a noun nameAttribute has a noun name

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

Entities

Entity

EntityInstance

Attributes

Metadata

E-R Diagram

EMPLOYEE

Employee IDFirstNameLastNameDepartmentPhone NumE-Mail

AUTOMOBILE

VINMakeModelYearColorPlate Num

Entity

Attributes

Identifier

Classifications of attributesClassifications of attributes

• Required versus Optional AttributesRequired versus Optional Attributes• Simple versus Composite AttributesSimple versus Composite Attributes• Identifier AttributesIdentifier Attributes• Single-Valued versus Multi-valued AttributesSingle-Valued versus Multi-valued Attributes• Stored versus Derived AttributesStored versus Derived Attributes

Required versus Optional AttributesRequired 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 AttributesSimple 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

• 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.

CompositeAttributes

(Employee Address)

CompositeAttributes

(Employee Name)

Identifiers (Keys)Identifiers (Keys)

• Identifier (Key)–an attribute (simple or Identifier (Key)–an attribute (simple or composite) that uniquely identifies individual composite) that uniquely identifies individual instances of an entityinstances of an entity

• Candidate Identifier–an attribute that could Candidate Identifier–an attribute that could be a key. It satisfies the requirements for be a key. It satisfies the requirements for being an identifierbeing an identifier

Figure 2-9 Simple and composite identifier attributes

The identifier is boldfaced and underlined

Composite Identifier:An identifier that consists of a composite attribute

CandidateIdentifiers

Identifier

Criteria for IdentifiersCriteria for Identifiers

• Choose Identifiers thatChoose Identifiers that– Will not change in valueWill not change in value– Will not be nullWill not be null

• Substitute simple keys for long, composite Substitute simple keys for long, composite keyskeys

Single-Valued versus Multi-valued Single-Valued versus Multi-valued AttributesAttributes

• Multi-valued attribute– 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

MultivaluedAttribute

Stored versus Derived AttributesStored versus Derived Attributes

• Derived attribute– 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.

Multivaluedan employee can have more than one skill

Derivedfrom date employed and current date

Figure 2-19 Simple example of time-stamping

This attribute is both multivalued and composite

RelationshipsRelationships

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

name

More on RelationshipsMore on Relationships

• Relationship vs. Relationship InstancesRelationship vs. Relationship Instances– The The relationshiprelationship is modeled as lines between is modeled as lines between

entitiesentities– The The relationship instance relationship instance is between specific is between specific

entity instancesentity instances

Employee Course

Figure 2-10 Relationship types and instances

a) Relationship

b) Relationship instances

Relationships can have attributesRelationships can have attributes• These describe features pertaining to the association These describe features pertaining to the association

between the entities in the relationshipbetween the entities in the relationship• In other words, these attributes describe features for EACH In other words, these attributes describe features for EACH

relationship instancesrelationship instances..

• Normally associate with many-to-many relationship (not one-Normally associate with many-to-many relationship (not one-to-many) => WHY?to-many) => WHY?

Relationship InstancesEmployee 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

Associative EntitiesAssociative Entities

• An entity that associates the instances of one or An entity that associates the instances of one or more entities and contains attributes that are more entities and contains attributes that are peculiar to the relationship between those entity peculiar to the relationship between those entity instances.instances.

• It is an entity – has attributesIt is an entity – has attributes• You can also regard it as a relationship – links entities You can also regard it as a relationship – links entities

togethertogether

AssociativeEntity

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

EQUALS TO

When should a When should a relationship with attributesrelationship with attributes instead be an instead be an associative entityassociative entity? ?

• All relationships for the associative entity should be many-to-All relationships for the associative entity should be many-to-manymany

• The associative entity could have meaning independent of the The associative entity could have meaning independent of the other entities (Certificate in the previous example)other entities (Certificate in the previous example)

• The associative entity preferably has a unique identifier, and The associative entity preferably has a unique identifier, and should also have other attributesshould also have other attributes

• The associative entity may participate in relationships other The associative entity may participate in relationships other than the entities of the associated relationshipthan the entities of the associated relationship

Cardinality of RelationshipsCardinality of Relationships

• One-to-OneOne-to-One– Each entity in the relationship will have exactly one related Each entity in the relationship will have exactly one related

entityentity• One-to-ManyOne-to-Many

– An entity on one side of the relationship can have many An entity on one side of the relationship can have many related entities, but an entity on the other side will have a related entities, but an entity on the other side will have a maximum of one related entitymaximum of one related entity

• Many-to-ManyMany-to-Many– Entities on both sides of the relationship can have many Entities on both sides of the relationship can have many

related entities on the other siderelated entities on the other side

Cardinality ConstraintsCardinality Constraints

• Cardinality Constraints—the number of Cardinality Constraints—the number of instances of one entity that can or must be instances of one entity that can or must be associated with each instance of another entityassociated with each instance of another entity

• MinimumMinimum Cardinality Cardinality– If zero, then If zero, then optionaloptional– If one or more, then If one or more, then mandatorymandatory

• MaximumMaximum Cardinality Cardinality– The maximum number of entity instances can be The maximum number of entity instances can be

involved in the relationshipinvolved in the relationship

EmployeeIs assigned to

Project

Minimum,MandatoryMinimum,Mandatory

Minimum,Optional

Minimum,Optional

Maximum,Many

Maximum,Many

Figure 2-17 Examples of cardinality constraints

A patient must have recorded at least one history, and can have many

A patient history is recorded for one and only one patient

Figure 2-17 Examples of cardinality constraints (cont.)

b) One optional, one mandatory

An employee can be assigned to any number of projects, or may not be assigned to any at all

A project must be assigned to at least one employee, and may be assigned to many

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

Student of INF20235

ParticipateTeam

Minimum number of team members (3)

Minimum number of team members (3)

Maximum number of team members (5)

Maximum number of team members (5)

(normally) Must be mandatory one

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

Multiple relationshipsMultiple relationships

• Two entities can have more than one Two entities can have more than one type of relationship between themtype of relationship between them

Entities can be related to one another in more than one way

Figure 2-21 Examples of multiple relationships

a) Employees and departments

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.

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. 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.

Multiple relationshipsMultiple relationships

• Two entities can have more than one Two entities can have more than one type of relationship between themtype of relationship between them

Entities can be related to one another in more than one way

Figure 2-21 Examples of multiple relationships

a) Employees and departments

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.

• 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. 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.