2. Marco Teórico
2.5 ERP y la Gestión del Conocimiento
Let s = rRENAME{a1ASb1, …, an AS bn }. Then:
• The heading of s is the heading of r except that the attribute named ai, of type ti, is replaced by an attribute named bi, also of type ti (0in).
• The body of s consists of the tuples of r except that in each tuple attribute ai with value υ
is replaced by attribute b with value υ.
Obviously, the result must be such that no two attributes have the same name; otherwise, it wouldn’t be a relation. Note that when more than one attribute is being renamed, the renamings are considered to take place simultaneously, so to speak. Thus, the example R RENAME { A AS B, B AS A } swaps the names of those two attributes.
Syntax note
When describing syntax we use the convenient term commalist for a list of items separated by commas. Thus we can say that an invocation of RENAME consists of a relation expression followed by the key word itself, followed in turn by a renaming commalist enclosed in parentheses. In Tutorial D, wherever the syntax requires a commalist, that commalist is permitted to be empty. Thus, for example, R RENAME { } is a legal expression. (Its value is equal to R.)
Get “Bookboon’s Free Media Advice” Email [email protected]
See the light!
The sooner you realize we are right,
the sooner your life will get better!
A bit over the top? Yes we know!We are just that sure that we can make your media activities more effective.
Download free eBooks at bookboon.com
98
Please do not confuse the RENAME operator with one that might be used for changing the name of an attribute of a relvar. That might be a very useful tool for database designers but in this chapter we are dealing only with read-only operators that yield relations. None of them has any effect on the database’s contents or definition.
Unfortunately, E.F. Codd did not foresee the need for a RENAME operator and so it is missing from some accounts of relational algebra that you may come across.
Using RENAME in combination with JOIN
Suppose we wish to discover pairs of students who have the same name. The result must be a relation with three attributes: two for the student identifiers and one for the name those two students share. All the data we need for that ternary relation is in the binary relvar IS_CALLED. The predicate for IS_CALLED is “Student StudentId is called Name”. What might be a predicate for our desired result? Obviously we cannot just connect “Student StudentId is called Name” to itself using AND, because multiple appearances of the same parameter must all represent the same value. So we must use two different parameter names for the two student identifiers. Example 4.3 shows a suitable predicate, followed by a relational expression that uses RENAME (twice) and JOIN to denote the required relation.
Example 4.3: Renaming and joining
Student Sid1 is called Name and so is student Sid2
( IS_CALLED RENAME { StudentId AS Sid1 } ) JOIN ( IS_CALLED RENAME { StudentId AS Sid2 } )
Note that Name is the only common attribute for the JOIN. Now you can begin to see how relational operators can be used to construct expressions of unlimited complexity. Unfortunately, though, the result obtained from this expression, shown in Figure 4.5, isn’t entirely satisfactory.
Sid1 Name Sid2
S1 Anne S1 S2 Boris S2 S2 Boris S5 S5 Boris S2 S5 Boris S5 S3 Cindy S3 S4 Devinder S4 Figure 4.5: Result of Example 4.3
Download free eBooks at bookboon.com
99
You didn’t really want to be told that Anne has the same name as herself, nor that students S5 and S2 share the same name (Boris) as well as students S2 and S5 sharing that name! We need to look at some more operators before we can begin to address those little problems. The next one is called projection.
4.6
Projection and Existential Quantification
Suppose we need to obtain the student identifiers of all the students who are enrolled on some course. Even though that result perhaps isn’t very interesting in itself, we might need it as part of some more interesting query. The relation we require would represent the predicate derived from the predicate for IS_ENROLLED_ON by existential quantification of CourseId:
Student StudentId is enrolled on some course. or, more formally
There exists a course CourseId such that student StudentId is enrolled on CourseId. Example 4.4 shows how to obtain the relation representing this predicate, using projection.
Example 4.4: Projection
Student StudentId is enrolled on some course. IS_ENROLLED_ON { StudentId } Points to note:
• Like RENAME, projection is monadic (it operates on just a single relation, in this case the current value of IS_ENROLLED_ON).
• Tutorial D uses no key word for projection. You just write a commalist of attribute names (a list of one in the example), enclosed in braces, after the expression denoting the single relation operand.
• The braces indicate that the order of attribute names in the given list is insignificant. Indeed, here it denotes a set (in the example, a set with just one element).
• The attributes named in braces are exactly those that remain if we remove the parameters that are existentially quantified in the predicate. Sometimes it is more convenient to name the attributes to be excluded rather than the remaining ones. With this in mind, Tutorial D supports an alternative formulation, using ALL BUT. Thus Example 4.4 could have been expressed like this instead:
Download free eBooks at bookboon.com
Click on the ad to read more
100