1. Spring 2013 CS 103 Computer Science – Business Problems Lecture 14: Entity-Relationship Model
Instructor: Zhe He
Department of Computer Science
New Jersey Institute of Technology
9/19/2018

2. Entities
An entity is anything that can be identified by a fixed number of its characteristics (attributes)
The attributes have names and values
The values are the data that is stored in the table
In relational databases, an attribute is a “column of a table”

3. Entities The attribute’s name is the tag used in the Identity role
The attribute values are the content enclosed in the tags
An entity is a group of attributes collected together by the tag used in the Affinity role
The entity is that object that is being described by all the tags

4. Entities
In addition to having a name, attributes also have a data type (such as number, text, image)
The data type defines the form of the information that can be stored in a field
By specifying the data type, database software prevents us from accidentally storing bad information in a table

5. Entities and Table
Entity defines a table...the name of the entity is the name of the table
Each column is one of the possible attributes
The values in the columns are the attributes’ values, and the rows are the entity instances
A specific set of values for the attributes of an entity is an entity instance
Any table containing specific rows is said to be a table instance

6. Entities
In addition to having a name, attributes also have a data type (such as number, text, image)
The data type defines the form of the information that can be stored in a field
By specifying the data type, database software prevents us from accidentally storing bad information in a table

7. Properties of Entities
A relational database table can be empty
It is a table with no rows
An entity is anything defined by a specific set of attributes
A table exists with a name and column headings
Once entity instances have been specified, there will be rows
Among the instances of any table is the “empty instance”

8. Instances Are Unordered
Each distinct table is a different table instance
Two table instances will have a different set of rows
Tables with the same rows (but reordered) are the same table instance
The order of the rows doesn’t matter in databases

9. Instances Are Unordered
The attributes (columns) are also considered to be unordered
The attributes or column heading have a name, they are not tracked by position
Column information stays in columns
They cannot switch to being a row
Row information stays in rows
They cannot switch to being a column

10. Uniqueness There are few limits on what an entity can be
Things that can be identified from each other qualify as entities
Entities can be distinguished by their attributes they are unique
No two rows in a database table can be the same
Unique instances is what is intended when a database is setup

11. Keys What attributes distinguish the rows in a database table?
Single attributes might be sufficient
Multiple attributes might be required to ensure uniqueness
Any set of attributes for which all entities are different is called a candidate key
Database tables usually have several candidate keys

12. Keys One of the candidate keys is the primary key
The primary key is the one that the database system will use to decide uniqueness
Candidate keys qualify only if they distinguish among all entities forever
If no combination of attributes qualifies as a candidate key, then a unique ID must be assigned to each entity

13. Atomic Data Databases treat the information as atomic
The information cannot be decomposed into smaller parts
The “only atomic data” rule is usually relaxed for certain types of data:
Dates, time, and currency
A date value 01/01/1970 must be treated as a single unity
The format of the data attribute, say dd/mm/yyyy, allows the program to understand how the field decomposes 13

14. Database Schemes Tags are a cumbersome way to define a table
Database systems specify a table as a database scheme or database schema
The scheme is a collection of table definitions that gives the name of the table, lists the attributes, their data types, and identifies the primary key

15. Database Schemes
Each database system has specific requirements for how a scheme is presented
There are no universal rules

16. An example of a table name manf Winterbrew Pete’s
Attributes
(column
headers)
name manf
Winterbrew Pete’s
Bud Lite Anheuser-Busch
Beers
Tuples
(rows)

17. Schemas Relation schema = relation name and attribute list.
Optionally: types of attributes.
Example: Beers(name, manf) or Beers(name: string, manf: string)
Database = collection of relations.
Database schema = set of all relation schemas in the database. 17

18. Why Relations? Very simple model.
Often matches how we think about data.
Abstract model that underlies SQL, the most important database language today. 18

19. From E/R Diagrams to Relations
Entity set -> relation.
Attributes -> attributes.
Key -> Primary Key
Relationships -> relations whose attributes are only:
The keys of the connected entity sets.
Attributes of the relationship itself. 19

20. Entity Set -> Relation
Relation: Beers(name, manf)
name
manf
Beers 20

21. Entity Set - Example Emp Emp Job EmpNo Name Hire Date Salary Comm
EmpNo Number(4)
Name Varchar2(10)
Job Varchar2(9)
Sal Number(7,2)
Comm Number(7,2)
HireDate Date
Emp
Primary Key 21

22. Relationships A relationship connects two or more entity sets.
It is represented by a diamond, with lines to each of the entity sets involved. 22

23. Relationship -> Relation
name
name
addr
manf
Drinkers
Likes
Likes(drinker, beer)
Beers
Married
husband
wife
Married(husband, wife)
Buddies
Buddies(name1, name2)
Favorite
Favorite(drinker, beer) 23

24. Example name name Logins At Hosts location billTo
Hosts(hostName, location)
Logins(loginName, hostName, billTo)
At(loginName, hostName, hostName2)
At becomes part of
Logins
Must be the same 24

25. Example Bars name license addr Beers manf name Sells Bars sell some
Note:
license =
beer, full,
none
Beers
manf
name
Sells
Bars sell some
beers.
Frequents
Drinkers frequent
some bars.
Likes
Drinkers like
some beers.
Drinkers
addr
name 25

26. Example
For the relationship Sells, we might have a relationship set like:
Bar Beer
Joe’s Bar Bud
Joe’s Bar Miller
Sue’s Bar Bud
Sue’s Bar Pete’s Ale
Sue’s Bar Bud Lite 26

27. Multi-way Relationships
Sometimes, we need a relationship that connects more than two entity sets.
Suppose that drinkers will only drink certain beers at certain bars.
Our three binary relationships Likes, Sells, and Frequents do not allow us to make this distinction.
But a 3-way relationship would. 27

28. Example name addr name manf Bars Beers license Preferences Drinkers28

29. A Typical Relationship Set
Bar Drinker Beer
Joe’s Bar Ann Miller
Sue’s Bar Ann Bud
Sue’s Bar Ann Pete’s Ale
Joe’s Bar Bob Bud
Joe’s Bar Bob Miller
Joe’s Bar Cal Miller
Sue’s Bar Cal Bud Lite 29

30. Many-Many Relationships
Focus: binary relationships, such as Sells between Bars and Beers.
In a many-many relationship, an entity of either set can be connected to many entities of the other set.
E.g., a bar sells many beers; a beer is sold by many bars. 30

31. In Pictures:
many-many 31

32. Many-One Relationships
Some binary relationships are many -one from one entity set to another.
Each entity of the first set is connected to at most one entity of the second set.
But an entity of the second set can be connected to zero, one, or many entities of the first set. 32

33. In Pictures:
many-one 33

34. Example Favorite, from Drinkers to Beers is many-one.
A drinker has at most one favorite beer.
But a beer can be the favorite of any number of drinkers, including zero. 34

35. One-One Relationships
In a one-one relationship, each entity of either entity set is related to at most one entity of the other set.
Example: Relationship Best-seller between entity sets Manfs (manufacturer) and Beers.
A beer cannot be made by more than one manufacturer, and no manufacturer can have more than one best-seller (assume no ties). 35

36. In Pictures:
one-one 36

37. Representing “Multiplicity”
Show a many-one relationship by an arrow entering the “one” side.
Show a one-one relationship by arrows entering both entity sets.
Rounded arrow = “exactly one,” i.e., each entity of the first set is related to exactly one entity of the target set. 37

38. Example
Likes
Drinkers
Beers
Favorite 38

39. Example Consider Best-seller between Manfs and Beers.
Some beers are not the best-seller of any manufacturer, so a rounded arrow to Manfs would be inappropriate.
But a beer manufacturer has to have a best-seller. 39

40. In the E/R Diagram
Best-
seller
Manfs
Beers 40

41. Attributes on Relationships
Sometimes it is useful to attach an attribute to a relationship.
Think of this attribute as a property of tuples in the relationship set. 41

42. Example Sells Bars Beers price
Price is a function of both the bar and the beer,
not of one alone. 42

43. Keys
A key is a set of attributes for one entity set such that no two entities in this set agree on all the attributes of the key.
It is allowed for two entities to agree on some, but not all, of the key attributes.
We must designate a key for every entity set. 43

44. Keys in E/R Diagrams
Underline the key attribute(s). 44

45. Example: name is Key for Beers
manf 45

46. Example: a Multi-attribute Key
dept
number
hours
room
Courses
Note that hours and room could also serve as a
key, but we must select only one key. 46

47. Weak Entity Sets
Occasionally, entities of an entity set need “help” to identify them uniquely.
Entity set E is said to be weak if in order to identify entities of E uniquely, we need to follow one or more many-one relationships from E and include the key of the related entities from the connected entity sets. 47

48. Example
name is almost a key for football players, but there might be two with the same name.
number is certainly not a key, since players on two teams could have the same number.
But number, together with the team name related to the player by Plays-on should be unique. 48

49. In E/R Diagrams name number name Plays- on Players Teams
Double diamond for supporting many-one relationship.
Double rectangle for the weak entity set. 49

50. Weak Entity-Set Rules
A weak entity set has one or more many-one relationships to other (supporting) entity sets.
Not every many-one relationship from a weak entity set need be supporting.
The key for a weak entity set is its own underlined attributes and the keys for the supporting entity sets.
E.g., (player) number and (team) name is a key for Players in the previous example. 50

51. Design Techniques Avoid redundancy. Limit the use of weak entity sets.
Don’t use an entity set when an attribute will do. 51

52. Avoiding Redundancy
Redundancy occurs when we say the same thing in two or more different ways.
Redundancy wastes space and (more importantly) encourages inconsistency.
The two instances of the same fact may become inconsistent if we change one and forget to change the other. 52

53. Example: Good name name addr ManfBy Beers Manfs
This design gives the address of each manufacturer exactly once. 53

54. Example: Bad name name addr ManfBy Beers Manfs manf
This design states the manufacturer of a beer twice: as an attribute and as a related entity. 54

55. Example: Bad name manf manfAddr Beers
This design repeats the manufacturer’s address once for each beer and loses the address if there are temporarily no beers for a manufacturer. 55

56. Entity Sets Versus Attributes
An entity set should satisfy at least one of the following conditions:
It is more than the name of something; it has at least one nonkey attribute. or
It is the “many” in a many-one or many-many relationship. 56

57. Example: Good name name addr ManfBy Beers Manfs
Manfs deserves to be an entity set because of the nonkey attribute addr.
Beers deserves to be an entity set because it is the “many” of the many-one relationship ManfBy. 57

58. Example: Good name manf Beers
There is no need to make the manufacturer an entity set, because we record nothing about manufacturers besides their name. 58

59. Example: Bad name name ManfBy Beers Manfs
Since the manufacturer is nothing but a name, and is not at the “many” end of any relationship, it should not be an entity set. 59

60. Don’t Overuse Weak Entity Sets
Beginning database designers often doubt that anything could be a key by itself.
They make all entity sets weak, supported by all other entity sets to which they are linked.
In reality, we usually create unique ID’s for entity sets.
Examples include social-security numbers, automobile VIN’s etc. 60

61. When Do We Need Weak Entity Sets?
The usual reason is that there is no global authority capable of creating unique ID’s.
Example: it is unlikely that there could be an agreement to assign unique player numbers across all football teams in the world. 61