3.6.3 Database System-Schema Decomposition: Whether to Keep Functional Dependency, Keep Functional Dependency Decomposition Definition, Lossless Decomposition, Table Method, Formula Method

3.6.3 Database System-Schema Decomposition: Whether to Keep Functional Dependency, Keep Functional Dependency Decomposition Definition, Lossless Decomposition, Table Method, Formula Method

Whether to maintain functional dependencies

Functional dependency is a function that can determine another part through a certain dimension. Here, in the relational schema, the functional dependency must exist between attributes. As long as the attribute exists, the functional dependency exists between the attribute and the attribute. In the process of considering schema decomposition , there is a relation schema before decomposition,

For example, the attribute set is as follows: the relationship pattern of
students (student number, name, department number, department name, department location) before decomposition is: F{student number → name, department number → department name, department number → department location}

This relationship model can be decomposed into the following relationship model:
when the attribute exists, the functional dependency will be preserved, and the split attribute is the functional dependency relationship.
学(student number, name) F1{student number→name}
department( Department number, department name, department position) F2{department number→department name, department number→department position}

In the process of decomposing the entire relational schema, have functional dependencies been maintained?
It is necessary to first list the functional dependency set of the original relational schema F, and the decomposed relational schema will generally be decomposed into multiple F1 and F2, and the relational schema in it will have its own functional dependency set.

The so-called preservation of functional dependencies is to merge the decomposed sets of functional dependencies. As long as they are equivalent to the original set of functional dependencies after merging, we will say that they are functional dependencies.

In this process, some functional dependencies can be derived through the axiom system, and those that can be derived are called redundant functional dependencies. Redundant functional dependencies do not need to be considered in the judgment of whether to maintain the decomposition of functional dependencies, because they can be obtained through derived from.

Keep Functional Dependency Decomposition Definitions

Suppose the database schema ρ={R1, R2,...,Rk} is a decomposition of the relational schema R, F is the functional dependency set on R, and the FD set on each schema Ri in ρ is Fi. If {F1, F2, ..., Fk} and F are equivalent (that is, mutual logical implication), then the decomposition ρ is said to preserve FD.

example

Example 1 : There is a relational pattern R (A, B, C), F={A→B, B→C}, split it into: R1{A, B}, R2{B, C}, whether to keep the function rely.

R1{A,B},F1{A→B}
R2{B,C},F2{B→C}

F1, F2 and F are equivalent, so the functional dependency decomposition is maintained.

Example 2 : There is a relational schema R(A, B, C), F={A→B, B→C, A→C}, split it into: R1{A, B}, R2{B, C} , whether to maintain functional dependencies.

R1{A,B},F1{A→B}
R2{B,C},F2{B→C}

F1 and F2 can deduce A→C, so A→C is a redundant functional dependency, which is not considered.

F1, F2 and F are equivalent, so the functional dependency decomposition is maintained.

lossless decomposition

What is lossy and what is lossless?
Lossy: Cannot be restored
Lossless: Can be restored

Lossless join decomposition: After decomposing a relational schema into several relational schemas, the original relational schema can still be restored through operations such as natural joins and projections.

Generally, the table method or formula method is used to verify whether it is non-destructive decomposition.

table method

First draw an initial table, write all the attributes before decomposing as column names, and then draw √ for all the attributes that appear in the decomposed relational schema. In this way, it is very convenient to judge the attribute column with the same name, and the column with √ in the same column is the attribute column with the same name.

example

There is a relational model: grade (student number, name, course number, course name, score)
function dependency: student number → name, course number → course name, (student number, course number) → score, if it is decomposed into:
grade (student number, course number, score)
student (student number, name)
course (course number, course name)
Is the decomposition lossless?

Analysis:
(1) First look at whether to maintain functional dependencies? This looks no problem
(2) See if it is a lossless decomposition?
We do natural joins for these three relational schemas. There are two things to do naturally:
①The condition of natural connection is that there are attribute columns with the same name, and there are attribute columns with the same name, and the values ​​are equal. First of all, in terms of attributes, duplicate attribute columns with the same name do not need to be recorded.
② The attribute with the same name is listed in the restoration process, and some non-primary attributes need to be restored accordingly. The non-main attribute must be determined by the attribute column with the same name, otherwise the attribute column with the same name obtained by the equivalent value does not know who took it. (That is to say, one of the functional dependencies with the attribute of the same name as the determinant on the left side is preserved, and the preserved result can restore the determined factor on the right side)

Grade⋈Student
Since there are: student number → name, so:
grade (student number, course number, score, name)
grade ⋈ student ⋈ course
because there are:
, so:
grade (student number, course number, score, name, course name )
Please add a picture description
and then judge whether to maintain functional dependencies for the number of rows marked with √.

formula method

The formula method can only be applied to the situation where it is decomposed into two relational patterns, and the formula method cannot be used if there are more than two relational patterns. But the table method is universal. The formula method generally only needs to prove the intersection and difference set (difference set in two directions) .

Theorem: If the decomposition of R is ρ={R1, R2}, and F is the set of functional dependencies satisfied by R, the necessary and sufficient condition for the lossless connectivity of the decomposition ρ is: R1∩R2→(R1-R2) or
R1∩R2
→ (R2-R1)

Among them, R1∩R2 represents the intersection of patterns, which is composed of common attributes of R1 and R2, R1-R2 or R2-R1 represents the difference set of patterns, and R1-R2 represents the composition of common attributes of R1 and R2 removed from R1. When schema R is decomposed into two relational schemas R1 and R2, if the common attributes of R1 and R2 can functionally determine other attributes in R1 or R2, such decomposition has lossless connectivity.

example

Suppose R=ABC, F={A→B}, then the decomposition ρ1={R1(AB), R2(AC)}, and the decomposition ρ2={R1(AB), R3(BC)} are lossless decomposition?
Analysis:
R1∩R2=A
R1-R2=B
R2-R1=C
A→B or A→C
R1∩R3=B
R1-R3=A
R3-R1=C
B→A or B→C

Guess you like

Origin blog.csdn.net/qq_41929714/article/details/130014442