Entity-Relationship Model
•	Business rules
•	Entities
•	Attributes
•	Relationships
Business rules
•	By end of project, need detailed document of requirements
•	Requirements must be testable -- why?
•	Testing should be based on requirements
•	Comparison with programming
•	How do you know if a variable can be const or final?
Entity
•	Objects: data + methods
•	Entity: only data
•	Not an object
•	Leads to a  entity type (serves same purpose as OO class)
•	Ex: Student, Account, Book
•	Usually a noun in requirements
Attribute
•	Entity defined as a set of attributes
•	Attributes are the "fields" of the record
•	Ex: Name, Height, Birth date
•	Attributes are not a specific value
•	Ex: Male, Sophomore
•	Compare with data members of a class
Kinds of Attributes
•	Composite -- made of simpler values
•	Ex: Address, Name
•	Does it matter if we treat these as one or several attributes? 
Multi-valued attributes
•	Attribute may consist of multiple values
•	Ex: Color of a shirt (what other attributes of a shirt?)
•	Why isn't shirt color a composite attribute?
•	Ex: Definition of a word
•	Can an attribute be both composite and multi-valued?
Uniqueness
•	Every entity is unique : has a unique set of attribute values
•	Ex: every student record must be unique
•	By this definition, are OO objects unique?
•	How do you guarantee uniqueness?
Keys
•	Key: for an entity type, a set of attributes with unique values for each entity
•	Ex: SSN for student
•	Ex: State + license plate number for car
•	For one entity type, may have more than one candidate key
•	Primary key: the chosen key
Choosing Keys
•	Why does it matter?
•	Usually data organized to improve performance when using primary key
•	One entity type refers to another using the 2nd's primary key [see Relationships]
•	Efficiency: ex: int vs. float
•	Usability: ex: ID (like SSN) vs. Name
Weak Entities
•	Entity type without a key
•	Need owner entity to identify
•	Usually lack of a key is due to business rules (check this)
•	Ex: Dependent - first name, gender
•	Ex: Section - section #, instructor last name
•	What would we need to add to make these entities regular?
Relationship
•	Connection between 2 or more entities
•	Ex: Employee works for Department
•	Ex: Student registered in Section
•	Ex: Employee is supervised by Employee
•	Last example is a recursive relationship
N-ary Relationships
•	Connection between more than 2 entities
•	Ex: Instructor teaches Course in Quarter
•	Ex: Product made of Material (outer) and Material (lining)
•	Usually easier if replaced by binary relationships
•	Ex: Product exterior made of Material
•	and Product lining made of Material
•	Can we do the same for teaches?
Relationship Properties (Cardinality)
•	# times entities from each entity type may participate
•	Ex: Employee works for Department
•	N:1 -- Many (N) employees work for one department
•	Other possibilities -- 1:1, 1:N, M:N
Determining cardinality
•	To work this out, try a sample table
Employee |  Department
Patel	         |  Sales
Smith         |  Marketing
Wu	         |  Sales
•	Duplicates in a column mean other column has “many” cardinality
Cardinality (continued)
•	What about the other example relationships?
•	Often determined by business rules
•	Sometimes possible to specify exact numbers
•	1:(8..35) -- what relationship might have this cardinality?
•	Cardinality does matter -- helps determine database schema
Relationship Properties (Participation)
•	Does every entity of the type participate?
•	Ex: Employee leads Department
•	Optional (partial) participation -- Employee might lead Department
•	Mandatory (total) participation -- Department must have leader
•	What about the example relationships?
•	Again business rules affect this
Determining Participation
•	Drawing a table helps
•	If every entity occurrence must appear, mandatory participation
•	If it might not, optional participation