Databases The theory of relational database design Lectures for m

Transcription

1 Databases The theory of relational database design Lectures for mathematics students April 2, 2017

2 General introduction Look; that s why there s rules, understand? So that you think before you break em. Terry Pratchett, Thief of Time

3 Functional dependencies Notation: X Y, where X i Y are sets of attributes from a relation R, is called functional dependency. We say that X Y is satisfied in R, if each two rows having the same values for all attributes from X must have the same values for all attributes from Y. Formally ( f : X Y )( (x,..., y) R(X,..., Y )) y = f (x) but this function is usually unknown (or sometimes not easy to compute).

4 Splitting A functional dependency X A 1 A 2... A n may be replaced by a set of dependencies X A 1, X A 2,..., X A n Example: A BC may be replaced by A B and A C. Attention: Splitting is only possible for right sides of of dependencies, left sides may not be splitted!

5 Examples of dependencies For the relation Animals(name,species,weight,age) the following dependency is assumed: name species If No two lectures are being taught at the same hour in the same room is true, then we have a functional dependency hour room lecture

6 Trivial dependencies A dependency X Y is trivial, if Y X. Trivial dependencies are always satisfied and do not carry any information.

7 Keys Definition A set of attributes N of a relation R(A 1, A 2,..., A n ) is called its superkey, if the following functional dependency is satisfied N A 1 A 2... A n Definition A set of attributes K of a relation R(A 1, A 2,..., A n ) is called its key, if it is a superkey of R and none of its subsets is a superkey of R. In other words: the keys of a relation are the minimal superkeys of this relation.

8 Examples If in the relation Animals the following dependency is satisfied name species age weight then {name,species} is a superkey of Animals However it is not a key of Animals, because {name} is also a superkey of Animals. So {name} is a key of R. If the above dependency is the only one satisfied for R, then there are no other keys.

9 Where do the keys come from? They may be determined using functional dependencies, or They are arbitrarily set (so called artificial keys), by adding a new attribute KS to the relation R as a key. This means the following additional functional dependency (not reflected in the real world) is added KS A 1 A 2... A n where A 1, A 2,..., A n are all attributes of the relation R.

10 Dependency derivation Some dependencies can be derived from others. Example: if A B is satified and is satisfied, then B C A C must also be satisfied. This could be checked directly from the definition, but there are other methods.

11 Closure of a set of attributes Definition The closure of a set of attributes Y (relatively to a given set of dependencies) is such set of attributes Y + that 1 Y Y + 2 For any dependency U W, if U Y +, then W Y + Remarks: If U V +, then the functional dependency V U is satisfied. Key is such minimal set of attributes, that its closure is equal to the set of all relation attributes.

12 Example Let us compute the closure of the attribute A from our example 1 Base step: A + := A 2 Induction: because A B and A A +, so A + := A + B = AB 3 Induction: because B C and B A +, so A + := A + C = ABC Conclusion: because C A +, so A C is satisfied.

13 Other example For the following set of dependencies AB C, BC AD, D E, CF B the closure {A, B} + equals {A, B, C, D, E}, because AB C C {A, B} + BC AD D {A, B} + D E E {A, B} +

14 Closure of a set of dependencies Definition The closure of a set of dependencies Z (notation Z + ) is the set of all dependencies, which can be derived from Z. Equivalence of sets of dependencis Two sets of dependencies Z 1 and Z 2 are equivalent, if and only if their closures are equal: Z 1 Z 2 iff Z + 1 = Z + 2.

15 Closure of a set of dependencies Minimal set of dependencies A set of dependencies is minimal, if it is not equivalent to any of its proper subsets, and if we try to remove some attribute from the left side of one of its dependences, the resulting set of dependencies will not be equivalent to it. Attention: a minimal set of dependencies of a given set of dependencies is not uniquely determined.

16 Armstrong s inference rules Reflexivity Y X X Y Augmentation X Y XZ YZ Transitivity X Y, Y Z X Z

17 Schema design One of the goals is to avoid redundancy. Redundancy means that in our database the same information is duplicated: copies of it are stored in many places. This leads to anomalies during modification and removal Modification anomaly: information will be updated only in some places Example: changing student s address to a new one in a poorly designed database. Removal anomaly: after the removal of the last detail row the general information associated with it is also lost. If the informations about student s address were stored with all classes, to which she/he is registered, then after the end of teaching period (and before a new registration) the address would be lost.

18 An example of a wrong design Assume we have the relation NewAnimals(species,name,weight,continent) with dependencies name species weight continent species continent The database table could for example contain: species name weight continent Parrot Kropka 3,50??? Parrot Lulu 5,35 America Parrot Hipek 3,50??? Fox Fufu 6,35 Europe Crocodile Czako 75,00 Africa There is a redundancy, because the values for??? can be easily guessed from the dependencies.

19 Normalization There are five formally defined (levels of) normal forms, but only the first three are used during everyday practice when designing databases. The normal forms are numbered succesively (starting from 1), but there exists the intermediate BCNF form between third and fourth level. Each normal form with a higher number contains in its definition the conditions for all lower numbers, so for example a relation in the second normal form is automatically in the first normal form. The reverse is not true: second normal form is obtained from first normal form after applying additional restriction. The normalization process consists in the decomposition of tables until obtaining the most appropriate form.

20 First normal form (1NF) The condition for the first normal form permits each attribute of a relation to take only atomic values. By atomic values we mean such single values, as used in attributes customer number or customer name. The relation in first normal form may not contain an attribute, in which several values are packed, e.g. by separating them with commas. We may treat dates as indivisible values or create the separate attributes for the day, the month and the year.

21 Second normal form (2NF) To check whether the relation in first normal form is also in second normal form, it is necessary to determine all keys. Each value of key should correspond to the unique row in a table. For example, for the relation Customer order, the column order number could be a key. The condition of the second normal form prescribes that each non-key attribute must be functionally dependent on the whole key. In other words, the so called partial dependencies on keys are not allowed.

22 Third normal form (3NF) To check whether a relation in second normal form is also in third normal form, we must look at dependencies between non-key attributes. Non-key attributes should functionally depend only on key (or keys) and on nothing else. Thus we exclude transitive dependencies (on keys).

23 Boyce-Codd normal form (BCNF) Boyce-Codd normal form is ever more restrictive than third normal form. A relation R is in this form, if it is in 1NF and for each nontrivial dependency X Y to be satisfied by R, the left side X of the dependency must be a superkey. Converting a relation to BCNF does not (contrary to 3NF) guarantee preservation of functional dependencies (when the relation has more than one key. For this reason it is less often used in practice.

24 Alternative definition of 3NF 3NF A relation is in 3NF if it is in 1NF and for each nontrivial dependency X Y either: the left side X is a superkey or the right side Y contains only the attributes from some keys (there can be more than one key).

25 Decomposition to BCNF 1 For a relation R select from its set of dependencies F some dependency X Y violating BCNF (if there is no such dependency, the relation is already in BCNF). 2 Compute X + It will contain only a subset of attributes of R, because otherwise X would be a superkey. 3 Replace R by two relations with schemas R 1 = X + R 2 = R (X + X) 4 Project the initial set of dependencies F onto new relations. 5 Repeat until all relations will be in BCNF.

26 Ecology : Dependency preservation There are sometimes troubles with dependencies while converting to BCNF. Let us look at the table Where(address,town,postal-code) and two dependencies address town postal-code postal-code town We have two keys: {address,town} oraz {address,postal-code}. However, the dependency postal-code town violates BCNF. So we should decompose into two tables Where1(address,postal-code) Where2(town,postal-code)

27 Dependency preservation Consider now the following example database contents Where2 address postal-code Banacha Banacha Where1 town postal-code Warszawa Warszawa Superficially everything is ok (no dependency is violated), but after we perform a join the situation changes Gdzie address town postal-code Banacha 2 Warszawa Banacha 2 Warszawa The dependency address town postal-code is now violated.

28 Dependency preservation Such sets of dependencies are not rare, let us look at another examples dependencies for a fictious network of cinemas cinema town film town cinema The first one is obvious: each cinema is obviously located in only one town. The other dependency may result from the politics of repertoire, to avoid the situation, when two cinemas in the same town compete by showing the same movie. The effect is the same as before.

29 Fourth normal form (4NF) In most databases it is enough to decompose up to third normal form. However sometimes insertion anomalies will occur, caused by multivalued dependencies. This may for example mean that some nonkey attributes take for some fixed value of another attribute only a few selected values, independent of other attributes values. For example, on seminar several books may be used. Each seminar has only one name, and the set of books depends on the name. Also each seminar may have more than one teacher. As any row would contain one arbitrarily selected book and one of the teachers (or possibly a null value), one should decompose seminars relation into two separate relations: seminar teachers and seminar texts.

30 Multivalued dependencies The relation Actors(name,street,town,film,year) stores the addresses of actors and movies, in which they performed. Each actor could play in many films and may have several addresses. But in a single row we can only store one film and one address (this is the consequence of insisting on having the 1NF). It makes it hard to find all movies with the actors living in Warsaw. Basically, we should store all the combinations of addresses and films for a given actor.

31 Definition of multivalued dependency Multivalued dependency Multivalued dependency A 1... A k B 1... B l for the relation R(A 1,..., A k, B 1,..., B l, C 1,..., C m ) means that if two tuples coincide on all attributes A i, then we can switch between them the attributes B i and the result tuples will also be in R. In other words, the left side of each such dependency does not determine a single value, but a set of values, e.g. name street,town name film,year

32 Rules for multivalued dependencies Promotion Each functional dependency is also a multivalued dependencies, i.e. if a dependency X Y is satisfied, then the following dependency is also satisfied X Y Unfortunately the reverse implication is false!

33 Rules for multivalued dependencies Complementation If for the relation R(X, Y, Z ) the dependency X Y is satisfied, then X Z will also be satisfied.

34 Rules for multivalued dependencies Transitivity If a relation R(X, Y, Z, V ) satisfies it must also satisfy X Y Y Z X Z

35 Rules for multivalued dependencies Like in the case of functional dependencies, we are not allowed to split the left sides of dependencies. But contrary to the former case, for multivalued dependencies also the right sides may not be splitted!

36 Fourth normal form definition Nontrivial multivalued definition A multivalued dependency X Y for the relation R is nontrivial, if 4NF Y X, and X Y are not all the attributes of R A relation R is in fourth normal form (4NF), if for each nontrivial dependency X Y in R, X is a superkey of R.

37 Conclusions If a relation is in 4NF, it is also in BCNF. The reverse is not true: it is a proper containment.

38 Decomposition to 4NF Like for BCNF, we look for a dependency X Y which violates 4NF. We split the relation R(X, Y, Z ) into two relations: R 2 (X, Y ) R 1 (X, Z ) We stop, when there are no such dependencies.

39 Example decomposition to 4NF We start with the relation and dependencies Actors(name,street,town,film,year) name street,town name film,year The only key contains all columns of the relation. So both dependencies violate 4NF (because they are nontrivial). We select the first dependency as a base for decomposition.

40 Example decomposition to 4NF We are left with two relations Actors1(name,street,town) Actors2(name,film,year) with the same dependencies. Because now both dependencies become trivial, we are done.