Properties of Relations
A relation has the following properties:
n the relation has a name that is distinct from all other relation names in the relational
schema;
n each cell of the relation contains exactly one atomic (single) value;
n each attribute has a distinct name;
n the values of an attribute are all from the same domain;
n each tuple is distinct; there are no duplicate tuples;
n the order of attributes has no significance;
n the order of tuples has no significance, theoretically. (However, in practice, the order
may affect the efficiency of accessing tuples.)
To illustrate what these restrictions mean, consider again the Branch relation shown in
Figure 3.1. Since each cell should contain only one value, it is illegal to store two postcodes
for a single branch office in a single cell. In other words, relations do not contain
repeating groups. A relation that satisfies this property is said to be normalized or in first
normal form. (Normal forms are discussed in Chapters 13 and 14.)The column names listed at the tops of columns correspond to the attributes of the
relation. The values in the branchNo attribute are all from the BranchNumbers domain;
we should not allow a postcode value to appear in this column. There can be no duplicate
tuples in a relation. For example, the row (B005, 22 Deer Rd, London, SW1 4EH) appears
only once.
Provided an attribute name is moved along with the attribute values, we can interchange
columns. The table would represent the same relation if we were to put the city attribute
before the postcode attribute, although for readability it makes more sense to keep the
address elements in the normal order. Similarly, tuples can be interchanged, so the records
of branches B005 and B004 can be switched and the relation will still be the same.
Most of the properties specified for relations result from the properties of mathematical
relations:
n When we derived the Cartesian product of sets with simple, single-valued elements
such as integers, each element in each tuple was single-valued. Similarly, each cell of a
relation contains exactly one value. However, a mathematical relation need not be normalized.
Codd chose to disallow repeating groups to simplify the relational data model.
n In a relation, the possible values for a given position are determined by the set, or
domain, on which the position is defined. In a table, the values in each column must
come from the same attribute domain.
n In a set, no elements are repeated. Similarly, in a relation, there are no duplicate tuples.
n Since a relation is a set, the order of elements has no significance. Therefore, in a relation
the order of tuples is immaterial.
However, in a mathematical relation, the order of elements in a tuple is important. For
example, the ordered pair (1, 2) is quite different from the ordered pair (2, 1). This is not
the case for relations in the relational model, which specifically requires that the order of
attributes be immaterial. The reason is that the column headings define which attribute
the value belongs to. This means that the order of column headings in the intension is
immaterial, but once the structure of the relation is chosen, the order of elements within
the tuples of the extension must match the order of attribute names.
A relation has the following properties:
n the relation has a name that is distinct from all other relation names in the relational
schema;
n each cell of the relation contains exactly one atomic (single) value;
n each attribute has a distinct name;
n the values of an attribute are all from the same domain;
n each tuple is distinct; there are no duplicate tuples;
n the order of attributes has no significance;
n the order of tuples has no significance, theoretically. (However, in practice, the order
may affect the efficiency of accessing tuples.)
To illustrate what these restrictions mean, consider again the Branch relation shown in
Figure 3.1. Since each cell should contain only one value, it is illegal to store two postcodes
for a single branch office in a single cell. In other words, relations do not contain
repeating groups. A relation that satisfies this property is said to be normalized or in first
normal form. (Normal forms are discussed in Chapters 13 and 14.)The column names listed at the tops of columns correspond to the attributes of the
relation. The values in the branchNo attribute are all from the BranchNumbers domain;
we should not allow a postcode value to appear in this column. There can be no duplicate
tuples in a relation. For example, the row (B005, 22 Deer Rd, London, SW1 4EH) appears
only once.
Provided an attribute name is moved along with the attribute values, we can interchange
columns. The table would represent the same relation if we were to put the city attribute
before the postcode attribute, although for readability it makes more sense to keep the
address elements in the normal order. Similarly, tuples can be interchanged, so the records
of branches B005 and B004 can be switched and the relation will still be the same.
Most of the properties specified for relations result from the properties of mathematical
relations:
n When we derived the Cartesian product of sets with simple, single-valued elements
such as integers, each element in each tuple was single-valued. Similarly, each cell of a
relation contains exactly one value. However, a mathematical relation need not be normalized.
Codd chose to disallow repeating groups to simplify the relational data model.
n In a relation, the possible values for a given position are determined by the set, or
domain, on which the position is defined. In a table, the values in each column must
come from the same attribute domain.
n In a set, no elements are repeated. Similarly, in a relation, there are no duplicate tuples.
n Since a relation is a set, the order of elements has no significance. Therefore, in a relation
the order of tuples is immaterial.
However, in a mathematical relation, the order of elements in a tuple is important. For
example, the ordered pair (1, 2) is quite different from the ordered pair (2, 1). This is not
the case for relations in the relational model, which specifically requires that the order of
attributes be immaterial. The reason is that the column headings define which attribute
the value belongs to. This means that the order of column headings in the intension is
immaterial, but once the structure of the relation is chosen, the order of elements within
the tuples of the extension must match the order of attribute names.
No comments: