1. Session 5: Weak Entity Sets and ER Model to Relational (4.4-4.6)
By: Cyndra and Tyre

2. Weak Entity Sets (4.4)
Weak entity set – Some or all of an entities key belongs to another entity set.
Causes of Weak Entity Sets
Sometimes entity sets fall into hierarchy based classifications unrelated to the “is –a hierarchy”
If entities of a set E are subunits of entities in a set F, then it is possible that the name of E-entities are not unique until we look at the name of f-entity.

3. Weak Entity Sets (4.4)
An example of a weak entity set.
Student loans

4. Weak Entity Sets (4.4) An example of a weak entity set.
Apartment building

5. Requirements for Weak Entity Sets (4.4)
IF a set E is a weak entity set then its key consists of
1.) Zero or more of its own attributes, and
2.) Key attributes from entity sets that are reached by certain many-one relationships from E to other entity sets. These many- one relationships are called supporting relationships for E , and the entity sets reached from E are supporting entity sets.

6. Requirements for Weak Entity Sets (4.4)
In order for R, a many-one relationship from E to some entity F, to be a supporting relationship for E, the following condition must be obeyed.
R must be a binary, many one-relationship from E to F
R must have referential integrity form E to F.
The attributes that F supplies for the key of E must be key attributes of F.
However, if F is itself weak, then some or all of the key attributes of F supplied to E will be key attributes of one or more entity sets G which F is connected by a supporting relationship.

7. Requirements for Weak Entity Sets (4.4)
If there are several different supporting relationships from E to the Same entity set F, then each relationship is used to supply a copy of the key attributes.

8. Weak Entity Set Notation (4.4)
1.) if an entity set is weak it will be shown as a rectangle with a double border.
2.) It’s supporting many-one relationships will be shown as diamonds with a double border.
3.) If an entity set supplies any attributes for its own key, then those attributes will be underlined

9. 4.5 From E/R Diagrams to Relational Designs
Concept: Convert an E/R design to a relational database schema
Remember ER diagrams helps approach database design, now that we have this, we are ready to change to our database schema
Step 1: Turn each entity set into a relation with the same set of attributes
Step 2: Replace a relationship by a relation whose attributes are the keys for the connected entity set

10. Special Cases
The steps on the previous slide work most of the time, but as always there are some special cases we need to know how to handle
They are:
Weak entity sets- they can’t be changed straight to relations
“Isa” relationships and subclasses
An entity set E and a relation that comes from a many-one relationship from E to some other entity set

11. 4.5.1 From Entity Sets to Relations
These are considering entity sets that are not weak
For non-weak entity sets: create a relation of the same name and with the same set of attributes
More examples on pg

12. 4.5.2: From ER Relationships to Relations
Now we will see how to handle ER relationships
For each entity set involved in a relationship R, we take the key attribute or attributes as part of the schema for R
If the relationship has attributes, then these are also attributes of the relation
Must handle if one entity set appears more than once in a relation, key attributes are used as many times as there are roles
More examples on the bottom of pg. 158

13. 4.5.3 Combining Relations
If we have an entity set E with a many-one relationship R from E to F
R will have the key attributes from E and F and any of its own attributes
Since R is many-one, all these attributes are functionally determined by the key for E and can be combined into
All attributes of E
Key attributes from F
Any attributes of R
Risk redundancy in combining many-many relations (Stars-in example)
More examples on pg. 161

14. 4.5.4 Handling Weak Entity Sets
What to do:
The relation for the weak entity set W must include all the attributes in W AND key attributes from any supporting entity sets (recognize by double diamond in ER diagram)
The relation for any relationship that involves the weak entity set W must use a key for W all its key attributes, including those of other entity sets that contribute to W’s key
However a supporting relationship R, from the weak entity set W to a supporting entity doesn’t need to be converted to a relation. (Because of reasons from 4.5.3)
Team example

15. Weak Entity Sets
What we saw in the previous example is that a supporting relationship needs no relation, which is universal for weak entity sets
Modified Rule: If W is a weak entity set, a relation for W will have the schema
All attribute of W
All attributes of supporting relationships for W
All key attributes from E (from the relationship)
Rename attributes to avoid duplication
Do not construct a relation for any supporting relationship of W

16. 4.6 Converting Subclass Structures to Relations
Principal Conversion Strategies for Subclasses
Follow the E/R viewpoint: For each entity set E in the hierarchy, create a relation that includes the key attributes from the root and any attributes belonging to E
Treat entities as objects belonging to a single class: For each possible subtree that includes the root, create one relation, whose schema includes all the attributes of all the entity sets in the subtree
Use null values: Create one relation with all the attributes of all the entity sets. Each entity is represented by one tuple, and the tuple will have null values for whatever attributes it does not have.

17. 4.6.1 Approach 1: ER Style Conversion
Example
Person(id, fname, lname)
Faculty(id, position salary)
Student(id, major, year)
These all include the key attribute of the root and all attributes of its entity set

18. 4.6.2 Approach 2: Object-Oriented
Looking at the previous example, we would make relations for all of the “classes” represented
Person(id, fname, lname)
Faculty(id, fname, lname, position, salary)
Student(id, fname, lname, year, major)
FacultyStudent(id, fname, lname, position, salary, year, major)

19. 4.6.3 Approach 3: Using Null Values
Uses a single relation with all attributes in the hierarchy
Using the same Person example, we would have one single relation
Person(id, fname, lname, position, salary, year, major)
If the person was a faculty member the attributes year and major would have null values
If the person was a student, the attributes position and salary would have null values

20. 4.6.4 Comparison of Approaches
Issues:
It can be expensive to answer queries involving multiple relations, so one relation is ideal. Null values uses one relation so it has advantages in this category
In the ER approach, we use only one relation per entity
In object-oriented, with root and n children, then there are 2^n classes and we will need that many relations
Minimize space and avoid repetition: Object-oriented has one tuple per entity and has components that only make sense for that entity, it is most efficient in minimizing space usage.
Null values have components for attributes even though they are not relevant to it
Although ER approach is better than null because it has several tuples for each entity, but only keys are repeated

21. Works cited
Garcia-Molina, Hector. Database Systems (p. 156). Pearson Education. Kindle Edition.