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

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.

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

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

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

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

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

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

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

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

Chapter 4: High-Level Database models

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Sources DATABASE SYSTEMS The Complete Book Second Edition. http://infolab.stanford.edu/~ullman/fcdb/aut07/slides/er.pdf http://infolab.stanford.edu/~ullman/fcdb/aut07/slides/mvds.pdf