5.

Multivalued Dependencies 4NF: A problem with multi-valued dependencies (MVD) occurs when you are trying to express two independent 1:N relations, or multi-valued attributes, in the same relation. For example, in your initial design process, you may have seen something like:

Example:

Where, the manager is associated (multi-determines) a set of phone numbers, and also a set of employees, but the phone numbers and the employees have nothing to do with each other. Of course, you cant have a relation that looks like the ones above it is excluded by 1NF. You are trying to express the idea that the manager is associated with a set of employees, and a set of phone numbers, but that the employees and the phone numbers are independent of one another. So, you might design a relation that looks like:

But that implies a relationship (connection) between 999-1212 and George. To avoid that appearance, you would have to store all combinations of phone# and employee. Two 1:N relations (or multivalued attributes), A:B, A:C, where B and C are independent of each other. A->>B A->>C A determines a set of (Multiple) values B A determines a set of (Multiple) values C

The only time a multi-valued dependency (mvd) is a problem is when you have more than one mvd, and the B and C values are independent.

A trivial mvd is one where: 1. The B attribute(s) are a subset of the A attributes. That is, if you made them distinct from each other, there would no longer be an mvd. E.g., ABC->>B. 2. The union of A and B make up the entire relation there are no other attributes in the table. Otherwise, you have a nontrivial mvd, and these are the potential problems. There are lots of redundancies allow room for anomalies. Note that the relations with non-trivial mvds tend to be all-key relations, where the key is the entire relation. The cure: 4NF A relation is in 4NF if for every nontrivial mvd A->>B, C is a superkey (any combination of attributes) that is a unique ID in the relation (non-minimal) for the relation. The manager table used as an example above is not in 4NF. mgr, phone# is a nontrivial mvd because phone# is not a subset of mgr, and there is also employee. Similarly, mgr, employee is a nontrivial mvd. As usual, the way to get a relation into 4NF is to decompose it, to get the mvds into separate relations:

Which are now trivial mvds, making up the entire table? This decomposition will have the lossless join property. 6. Fifth Normal Form (5NF) and Join Dependencies : 5NF, also known as Project-join normal form (PJ/NF) is based on the idea of a lossless JOIN or the lack of a join-projection anomaly. This problem occurs when you have an n-way relationship, where n>2. A quick check for 5NF is to see if the table is in 3NF and all the candidate keys are single columns. Join dependency A join dependency (JD), denoted by JD(R1, R2, ..., Rn), specified on relation schema R, specifies a constraint on the states r of R. The constraint states that every legal state r of R should have a non-additive join decomposition into R1, R2, ..., Rn; that is, for every such r we have

Note: an MVD is a special case of a JD where n = 2.

Lossless-join property refers to when we decompose a relation into two relations - we can rejoin the resulting relations to produce the original relation.

Consider a table of supply with no MVD is in 4NF but not in 5NF if it has JD(R1,R2,R3).

The SUPPLY relation with the join dependency is decomposed into three relations R1,R2, and $3 that are each in 5NF.

Applying a natural join to any two of these relations produces spurious tuples, but applying a natural join to all three together does not.