1. Chapter 3: Multivalued Dependencies
By: Tay Cavett and Jalyn Cosby

2. Multivalued dependencies
2 attributes or set of attributes that are independent of one another
a generalization of the notion of a functional dependency
every FD implies the corresponding multivalued dependency. However, there
are some situations involving independence of attribute sets that cannot be
explained as FD’s.

3. Definition of multivalued dependency
is a statement about some relation R that when you fix the values for one set of attributes, then the values in certain other attributes are independent of the values of all the other attributes in the relation.
A1 A2 ... A n --->--->4 B 1 B2 ... B m
holds for a relation R if when we restrict ourselves to the tuples of R that have particular values for each of the attributes among the ,4’s, then the set of value we find among the B ’s is independent of the set of values we find among the attributes of R that are not among the ,4’s or B ’s.
Definition of multivalued dependency

4. Reasoning about mvds Trivial mvds Transitive Fd promotion
If right side is a subset of left side
Transitive
If a->B , b->c, then a->c
Fd promotion
Every fd is a mvd
Complementation rule
If A1 A2 … A n ->-> B1 B2 Bm is an MVD for relation R, then R also satisfies A 1 A2 … An >- > C1 C2…Ck, where the C ’s are all attributes of R not among the A.’s and B ’s.
More trivial mvds
If all the attributes of relation R are {Ai,A2,... ,An->->Bi,B2,... ,Bm}
then A1A2.. An ->-> B1 B2… Bm holds in R.
*********doesn’t follow combining/splitting rules

6. Fourth normal form
When you use mvd you get redundancies that cannot be eliminated using bcnf
So we use a new normal form, 4nf (fourth normal form) to eliminate all nontrivial mvds and fds that violate bcnf

7. Decomposition into 4nf
Requires every nontrivial mvd to be fd with a superkey on the left side
Algorithm is very similar to bcnf
1. find a 4nf violation (since every fd is a mvd, every bcnf violation is a 4nf violation) where left side is not a super key
2. if there is a violation, break down the relation schema into two schemas
A : all attributes of the left plus ones on the right
B : all attributes of the left plus ones not among the left or the right side
3. Find fds and mvds that hold in A and B. then recursively decompose the schemas (A and B) with respect to their projected dependencies
So when we decompose a relation because a mvd, it gives us enough to reconstruct the original relation from the relations of the decomposition

8. Relationships among normal forms
Since bcnf eliminates redundancy and other anomalies caused by fd, 4nf does too
Only 4nf eliminates additional redundancy caused by mvds

9. Algorithm for discovering mvds
Extend chase algorithm to incorporate mvds and fds
We do this to solve problems about mvds and fds like finding whether a mvd follows from a given dependencies or projecting mvds and fds onto the relations of a decomposition
We use a tableau to evaluate all inferences from the given set to see if we can prove the targeted dependency

10. Why do we care 4nf technically requires a violation
We need to infer mvds from given fds and mvds that may not be violations themselves
When we decompose , we need to project the fds and mvds

13. To complete chase test
We apply all given fds and mvds until we can’t change the table anymore
If we meet our goal of concluding that the fd or mvd works then the dependency is inferred
If we never reach out goal, then the table serves as a counter example

14. Chapter 4: High-Level Database models

15. Why High-level database models?
The simplicity of concepts in the relational model is a great strength of the model, especially when it comes to efficient implementation of database operations.
Yet that strength becomes its weakness when we do preliminary design, which is why it is helpful to begin by using a high-level design model.

16. Entity Relationship model
In the E/R Model the structure of data is represented graphically as an ‘entity-relation diagram’ using 3 principal element types:
Entity Sets- a collection of similar entities (things/objects)
Ex. Entity- student Entity Set- set of all students
2. Attributes- properties of entities in that set.
3 type of attributes:
- A primitive type.
- A “struct”, or a tuple with a fixed number of primitive components.
- A set of values of 1 type: either primitive or a “struct” type.
Ex. Students might be given attributes such as name and age.
3. Relationships- connections among two or more entity sets.
Ex. A Student attends a school, the relationship would be attends.

17. E/R diagram
A graph representing entity sets, attributes, and relationships.
Notation:
-Entity Sets are represented by rectangles.
- Attributes are represented by ovals.
- Relationships are represented by diamonds.
Ex.

18. Multiplicity of binary relationships
A binary relationship can connect any member of one of it entity sets to any number of members of the other entity set.
3 types Of Relationships:
1. Many-One: Each entity of the first set is connected to at most 1 entity of the 2nd set. But an entity of the 2nd can be connected to zero or many entities of the 1st set.
2. One-One: An entity of either set can be associated with at most 1 entity of the other set
3. Many-Many: An entity of either set can be connected to any entities of the other set.

19. Multiway Relationships
The E/R Model makes it convenient to define multiway relationships involving more than 2 entity sets.
A multiway relationship is represented in an E/R Diagram by lines from the relationship diamond to each of the involved entity sets.

20. Attributes On Relationships
Sometimes it is useful to attach an attribute to a relationship.
Think of this attribute as a property of tuples in a relationship set.
Ex.

21. Subclasses
Are special-case entity sets with its own attributes and/or relationships. Has fewer entities and more properties.
We connect an entity Set to its subclass using a relationship called ‘isa’.
‘ISA’ relationship is special and unlike any other kind of relationship and is one- one , we use a triangle for it notation.

22. Design principals Faithfulness Avoid Redundancy Simplicity Counts
-The design should be faithful to the specification of the application.
-Meaning the entity sets and their attributes should reflect reality.
Avoid Redundancy
-Say everything once as mentioned in the earlier sections.
Simplicity Counts
-Avoid introducing more elements into your design than is absolutely necessary.
Choosing The Right Relationships
-Adding every possible relationship to our design is not often a good idea. This can lead to redundancy and anomalies.
Picking the Right Kind of Element
-In general an attribute is simpler to implement than an entity set or relationship. However, making everything an attribute can and probably will lead to trouble.

23. Constraints on E/r Model
Keys
-For notation we underline the attributes belonging to a key for an entity set
Ex.
Referential Integrity
-For notation we use an arrow to indicate whether a relationship is expected to support referential integrity in 1 or more directions.

24. Degree Constraints
We can attach a bounding number to the edges that connect a relationship to an entity set, indicating a limit on the number of entities that can be connected to any 1 entity of the related entity set.
Ex.

25. Sources DATABASE SYSTEMS The Complete Book Second Edition.