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

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”

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

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

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

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

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”

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

Example name addr name manf Bars Beers license Preferences Drinkers 28

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

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

In Pictures: many-many 31

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

In Pictures: many-one 33

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

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

In Pictures: one-one 36

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

Example Likes Drinkers Beers Favorite 38

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

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

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

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

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

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

Example: name is Key for Beers manf 45

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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