1. Entity Relationship Model

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

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

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

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

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

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

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

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

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

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

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

14. Entities
Entity
Entity
Instance

15. Entity
Entity
Instance

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

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

18. Strong vs. Weak Entities

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

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

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

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

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

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

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

26. Entity
Attributes
Entity
Instance

27. Metadata

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

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

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

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

32. An attribute broken into component parts

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

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

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

36. Candidate
Identifiers
Identifier

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

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

39. Multivalued
Attribute

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

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

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

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

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

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

46. Employee
Course

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

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

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

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

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

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

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

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

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

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

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

58. Also called “Mandatory one”

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

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

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

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

63. (normally) Must be mandatory one

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

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

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

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

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

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

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

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

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

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

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

75. Figure 2-18 Cardinality constraints in a ternary relationship36

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

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

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

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

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

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