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

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.

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

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

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.

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.

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.

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

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

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

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. 157-158

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

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

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

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

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.

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

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)

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

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

Works cited Garcia-Molina, Hector. Database Systems (p. 156). Pearson Education. Kindle Edition. https://www.gatevidyalay.com/entity-sets-in-dbms/ http://codesnipts.com/weak-entity-set-in-e-r-model/