Examples of Relational Value Assignments

Transcription

1 Examples of Relational Value Assignments Example Relvars - First Set Let relvar EMP contain sample data of the ID number and name of employees, displayed in tabular format as :- No Name 1 Jack 2 Jill Example Assignments Insertion Tuples may be inserted into EMP as follows :- EMP Insert Relational_Expression where Relational_Expression can be any relational expression whose value is of the same type as that of EMP. This can include relational literal values and relvar names, on their own or as part of a larger relational expression. or EMP <--Insert { { No <-- 3; Name <-- Fred } { No <-- 4; Name <-- Jane EMP <--Insert { { 3; Fred } { 4; Jane These two insertions, of a relvalue of 2 tuples, are logically equivalent. The former is a long-hand syntax; it specifies which value is assigned to which attribute within each tuple value. The latter is an abbreviated form; it requires the attribute values to be written in the default order, which is always the same order as that in which the attributes were specified in the declaration of the relvar; thus it is assumed that in the declaration of EMP, attribute No was specified first followed by attribute Name. The longhand forms allow the attribute values to be specified in any order, e.g. :- or Another example :- EMP <--Insert { { Name <-- Fred ; No <-- 3 } { No <-- 4; Name <-- Jane EMP <--Insert { { Name <-- Fred ; No <-- 3 } { Name <-- Jane ; No <-- 4 EMP <--Insert TempEMP Restrict[ No > 21 ] Page 1 of 14

2 Here a restriction is used to extract some tuples (the number is indeterminable from the expression alone) from relvar TempEMP and insert them into EMP. (TempEMP and EMP must have the same type). These two kinds of insertion could be combined, as follows :- or EMP <--Insert TempEMP Restrict[ No > 21 ] Union { { Name <-- Fred ; No <-- 3 } { No <-- 4; Name <-- Jane EMP <--Insert TempEMP Restrict[ No > 21 ] Intersect { { Name <-- Fred ; No <-- 3 } { No <-- 4; Name <-- Jane Note that the relvalue of the RH operand must be disjoint from the relvalue of the LH operand; otherwise an error will be returned instead of an insertion being carried out. Deletion Tuples may be deleted from EMP as follows :- EMP Delete Relational_Expression where Relational_Expression is defined as before. If EMP has received insertions similar to those above, then the following might be possible deletions :- or EMP <--Delete TempEMP Restrict[ No > 21 ] Union { { Name <-- Jack ; No <-- 1 } { No <-- 2; Name <-- Jill EMP <--Insert TempEMP Restrict[ No > 21 ] Intersect { { Name <-- Jack ; No <-- 1 } { No <-- 2; Name <-- Jill Note that the relvalue of the RH operand must be a subset, not necessarily a proper subset, of the relvalue of the LH operand; otherwise an error will be returned instead of a deletion being carried out. Another example :- EMP <--Delete EMP Restrict[ No < 2 ] This assignment deletes all tuples from EMP whose No attribute value is less than 2. This example would cause the deletion of one tuple, i.e. { No <-- 1; Name <-- Jack }. This assignment could also be expressed as :- Page 2 of 14

3 EMP Restrict[ No < 2 represents the value of the LH operand - whatever its nature - before the deletion. It can therefore always be used; indeed it is preferable to use it because it is simpler to write and avoids errors in copying out the LH operand 1. Amendment Tuples may be amended in EMP as follows :- EMP Amend[ attribute-assignment(s) ] where attribute-assignment(s) are a set of value assignments to named attributes. For each such assignment, every tuple in EMP has that attribute s value replaced as specified by the assignment. EMP Amend[ No <-- No + 1 ] This increments the No attribute value by one in every attribute of EMP. Multiple attributes, all of those in the relvar if required, can have their values amended in one assignment. EMP Amend[ No <-- No + 1; Name <-- Name Cat Joyous ] additionally concatenates Joyous to the end of the Name attribute in every tuple of EMP. For :- EMP Amend[ No <-- 1 ] every tuple in EMP would be amended to have 1 as the value of its No attribute, because the value to be assigned no longer depends on the attribute s original value. If No is a Candidate Key of EMP, then this would generate an error (unless EMP contains only zero or one tuples). Sometimes only certain of a relvar s tuples are to be updated. In this case the LH operand should comprise a relational expression that evaluates to the set of tuples to be amended. ( EMP Restrict[ No = 1 ] ) Amend[ Name <-- Joyous ] amends the Name attribute to have the value Joyous in the tuple whose No attribute has the value 1. If No is not a Candidate Key of EMP, then this would change the Name attribute value in every tuple whose No attribute has the value 1. The parentheses are required around the LH operand expression to avoid the assignment attempting to amend a Restrict operation, thereby causing a semantic error. If the LH operand is not a relvar name but a relational algebra expression involving more than a relvar name, then the LH operand is treated as an unnamed view. Thus any expression can occur as the LH operand, as long as it is logically possible to amend the underlying relvar(s) of the unnamed view. can be used as (part of) the RH operand of any relational assignment, but is of most practical use in deletions. Page 3 of 14

4 ( EMP Join[[ No ] OtherEMP ) Amend[ Name <-- Joyous ] Here a left semijoin with OtherEMP is used to specify the tuples of EMP to be amended. In the following examples, the LH operand specifies just those attributes whose values are to be amended :- ( EMP Project[ No ] ) Amend[ No <-- No + 1 ] ( EMP Restrict[ No = 1 ] Project[ Name ] ) Amend[ Name <-- Joyous ] However this is not necessary as long as all the attributes named in the <--Amend parameter exist within the LH operand. Example Relvars - Second Set Since it is possible for a relvar to contain nested relvalues as attribute values, it is worthwhile to consider how the value assignments operate when they are present, and how they can be applied to nested relvalue parts of a relvar. Thus the example data is expanded to the following :- Let relvar EMP1 contain sample data of the ID number, name, and salary history of employees :- No Name SalHist 1 Jack Start Sal Date[ 1; 3;1998 ] Date[ 1; 2; 2003 ] Date[ 1; 10; 2009 ] Jill Start Sal Date[ 1; 12; 2004 ] Date[ 1; 11; 2007 ] Let relvar EMP2 contain sample data of the ID number, name, and project history of employees :- Page 4 of 14

5 No Name ProjHist 1 Jack ProjNo P7 Time Start End Date[ 1; 12; 2004 ] Date[ 20; 4; 2005 ] Date[ 1; 11; 2007 ] Date[ 9; 8; 2008 ] 2 Jill ProjNo P7 P8 Time Start End Date[ 1; 9; 2002 ] Date[ 1; 9; 2004 ] Start End Date[ 1; 2; 2005 ] Date[ 8; 4; 2006 ] Overview In handling nested relvalues and part-relvars, it can be convenient to use the Nest and/or Unnest operators to handle nested relvalues and ensure that the same level of nesting applies within the RH relvalue and the LH relvar. In general, it is possible to assign to a specific nested relvalue. For example, to insert into a relvalue that is nested one level down :- ( R Restrict[ Key = 1 ] Project[ A ] Unnest[ A ] ) <--Insert relexpression The relevant tuple of the relvar is picked out using a restriction on the key attribute, the attribute holding the nested relvalue projected out, and the nested relvalue unnested to allow the insertion directly into it. This strategy can be continued for a relvalue two levels of nesting down as follows :- ( R Restrict[ Key = 1 ] Project[ A ] Unnest[ A ] Restrict[ KeyN = 1 ] Project[ AN ] Unnest[ AN ] ) <--Insert relexpression And so on down to any required depth :- Page 5 of 14

6 ( R Restrict[ Key = 1 ] Project[ A ] Unnest[ A ] Restrict[ KeyN = 1 ] Project[ AN ] Unnest[ AN ] Restrict[ KeyNN= 1 ] Project[ ANN ] Unnest[ ANN ].... ) <--Insert relexpression And similarly for deletion and amendment. Where insertion and deletion to nested relvalues are concerned, there are in fact two categories of assignment : the assignment of a single relvalue to a single relvar, the assignment of a single relvalue to n part-relvars that are nested within a single relvar. The second category can allow a layer of unnesting to be omitted. The variations in assignment of relvalues to relvars can in general terms be illustrated graphically as follows :- Assign a relvalue to a relvar. Assign a relvalue to 2 nested part-relvars. Assign a relvalue to a relvar. Both have the same nested relational structure. Page 6 of 14

7 Two assignments to a relvar : 1. A relvalue to a single relvalue nested at the deepest level within the relvar. 2. A relvalue to a single relvalue nested one level down inside the relvar. Note that when an amendment is to be carried out on an attribute value, and that attribute value is a nested relvalue, that amendment can be : 1. an amendment to attribute values within the nested relvalue, 2. an insertion of tuples into the nested relvalue, 3. a deletion of tuples from the nested relvalue. Examples involving nested relvalues are now given. Insertion Insert a single relvalue into a single relvar. 1. Insert a third tuple into EMP1. The following two insertions use the abbreviated and the long-hand equivalents of relation-valued literals to insert the same third tuple :- EMP1 <--Insert { { 3; Fred ; { { Date[ 10; 9; 2006 ]; } { Date[ 6; 8; 2009 ]; EMP1 <--Insert { { No <-- 3; Name <-- Fred ; SalHist <--Insert { { Start <-- Date[ 10; 9; 2006 ]; Sal < } { Start <-- Date[ 6; 8; 2009 ]; Sal < A relvalue of one tuple is inserted into EMP1; the attribute SalHist in the tuple is a nested relvalue of 2 tuples. Page 7 of 14

8 2. Insert a third tuple into EMP2. The following two insertions use the abbreviated and the long-hand equivalents of relation-valued literals to insert the same third tuple :- EMP2 <--Insert { { 3; Fred ; { { P6 ; { { Date[ 10; 5; 2006 ]; Date[ 19; 8; 2008 ] EMP2 <--Insert { { No <-- 3; Name <-- Fred ; ProjHist <--Insert { { ProjNo <-- P6 ; Time <--Insert { { Start <-- Date[ 10; 5; 2006 ]; End <-- Date[ 19; 8; 2008 ] A relvalue of one tuple is inserted into EMP2; the tuple s ProjHist attribute is a nested relvalue of one tuple, which itself consists of the scalar attribute ProjNo and the relation-valued attribute Time which also has a relvalue of one tuple. Insert a single relvalue into each nested relvalue of a relvar. 3. Insert two tuples into each of the SalHist nested relvalues of EMP1. The following two insertions use the abbreviated and the long-hand equivalents of relation-valued literals to insert the same two tuples into every SalHist nested relvalue :- ( EMP1 Project[ SalHist ] ) <--Insert { { Date[ 8; 7; 2003 ]; } { Date[ 11; 4; 2007 ]; ( EMP1 Project[ SalHist ] ) <--Insert { { Start <-- Date[ 8; 7; 2003 ]; Sal < } { Start <-- Date[ 11; 4; 2007 ]; Sal < The LHS of the insertion is an unnamed view (based on EMP1) whose type is a set of unary tuples, each of whose attribute values consists of a relvalue of binary tuples. The RHS relvalue has the same type as the nested relvalues of the unnamed view. Therefore the RHS relvalue is inserted into each of the nested SalHist part-relvars. (A part-relvar is a component part of a relvar). This is an example of where one RHS relvalue is inserted into n LHS partrelvars, in this case where n = 3 (after the previous insertion). The question may be raised as to what would happen if the RHS relvalue had consisted of 3 tuple values of the correct type, as opposed to the 2 in the above example. Would each of the 3 tuples of the RHS relvalue be inserted into its own corresponding LHS part-relvar because there is now the same number of tuple values on the RHS as there are nested part-relvars on the LHS. The answer is no. The question is a red herring. Assignments assign Page 8 of 14

9 relvalues to relvars or part-relvars, and the number of tuples in a relvalue is irrelevant. Insert a single relvalue into a particular nested relvalue of a relvar. 4. Insert two tuples into one specific SalHist nested relvalue. ( EMP1 Restrict[ No = 1 ] Project[ SalHist ] ) <--Insert { { Date[ 10; 9; 2006 ]; } { Date[ 6; 8; 2009 ]; ( EMP1 Restrict[ No = 1 ] Project[ SalHist ] ) <--Insert { { Start <-- Date[ 10; 9; 2006 ]; Sal < } { Start <-- Date[ 6; 8; 2009 ]; Sal < The unnamed view on the LHS represents a part-relvar consisting of one attribute of one tuple, whose value is a nested relvalue. These statements insert a relvalue of 2 tuples into that part-relvar. The LH operand is an unnamed view expressing a relvalue nested within a relvalue; i.e. the LH operand is a set of n part-relvars where n = 1. Therefore the ability to assign to a nested relvalue is still useful even in this case, as it obviates the need to Unnest the LH operand so as to ensure the LHS and RHS have identical types. Of course, Unnest could be used if required to execute the logically equivalent insertion as follows (abbreviated version) :- ( EMP1 Restrict[ No = 1 ] Project[ SalHist ] Unnest[ SalHist ] ) <--Insert { { Date[ 10; 9; 2006 ]; } { Date[ 6; 8; 2009 ]; This inserts a single relvalue into a single part-relvar. 5. Insert one tuple into one specific Time nested relvalue. ( EMP2 Restrict[ No = 2 ] Project[ ProjHist ] Unnest[ ProjHist ] Restrict[ ProjNo = P7 ] Project[ Time ] ) <--Insert { { Date[ 15; 3; 2004 ]; Date[ 19; 12; 2008 ] ( EMP2 Restrict[ No = 2 ] Project[ ProjHist ] Unnest[ ProjHist ] Restrict[ ProjNo = P7 ] Project[ Time ] ) <--Insert { { Start <-- Date[ 15; 3; 2004 ]; End <-- Date[ 19; 12; 2008 ] As the nested relvalues of the Time attribute are nested two levels down, the Unnest operation is required so that the second restriction is applied to a relational valued attribute whose own attributes are called ProjNo and Time. Note a second Unnest could be applied to the LH operand but it is not necessary; instead the RH relvalue is inserted into a set of one nested relvalue. If a second Unnest were used, the logically equivalent insertion would be (abbreviated version) :- Page 9 of 14

10 ( EMP2 Restrict[ No = 2 ] Project[ ProjHist ] Unnest[ ProjHist ] Restrict[ ProjNo = P7 ] Project[ Time ] Unnest[ Time ] ) <--Insert { { Date[ 15; 3; 2004 ]; Date[ 19; 12; 2008 ] Note that inserting a relvalue into every Time nested part-relvar cannot be reliably carried out. Consider how it might be written :- ( EMP2 Project[ ProjHist ] Unnest[ ProjHist ] Project[ Time ] Unnest[ Time ] ) <--Insert { { Date[ 15; 3; 2004 ]; Date[ 19; 12; 2008 ] The lack of restrictions picking out individual tuples means the unnesting of ProjHist and of Time may result in duplicate tuples of attributes Start and End arising, and the duplicates being removed; thus the view update mechanism cannot guarantee to carry out the correct insertions into EMP2. Deletion The deletion examples given are the direct inverses of the above insertion examples. Delete a single relvalue from a single relvar. 1. Delete a tuple from EMP1. The following are equivalent ways of expressing the same deletion :- EMP1 <--Delete { { 3; Fred ; { { Date[ 10; 9; 2006 ]; } { Date[ 6; 8; 2009 ]; EMP1 <--Delete { { No <-- 3; Name <-- Fred ; SalHist <--Insert { { Start <-- Date[ 10; 9; 2006 ]; Sal < } { Start <-- Date[ 6; 8; 2009 ]; Sal < EMP1 <--Delete EMP1 Restrict[ No = 3 ] EMP1 Restrict[ No = 3 ] The first two statements use relation-valued literals. Despite a deletion being carried out, the long-hand relation-valued literal uses an insertion within the RH operand because the <--Insert is here the set equivalent of a scalar value assignment - 2 tuples are being put into the SalHist empty relation. The 3 rd and 4 th statements use a relational algebra expression to pick out the 1-tuple relvalue that is to be deleted from EMP1, rather than writing out its literal value. Any suitable restriction condition could be used. It is here assumed that attribute No is a candidate key and so can be reliably used to pick out a single tuple. The 4 th statement instead of EMP1. 2. Delete a tuple from EMP2. The following are equivalent ways of expressing the same deletion :- Page 10 of 14

11 EMP2 <--Delete { { 3; Fred ; { { P6 ; { { Date[ 10; 5; 2006 ]; Date[ 19; 8; 2008 ] EMP2 Restrict[ No = 3 ] For convenience here and from now on, the use of a long-hand relation-valued literal is omitted, as is the use of a restriction Both the omitted variants can always be used if preferred. Note that the RH operand does not need to refer to the LH operand, either directly or indirectly. EMP2 <--Delete Special1EMP Join[ ProjHist ] Special2EMP Nest[ Time <-- Start, End ] Here Special1EMP and Special2EMP are 2 completely different relvars that are joined together and restructured by the nest operation so that the result has the same type as EMP2. (The result of the join must include one level of nesting corresponding to ProjHist so that only one more level of nesting must be applied after the join). The result of the RH expression comprises the relvalue of tuples to be deleted from EMP2. Delete a single relvalue from each nested relvalue of a relvar. 3. Delete tuples from each of the SalHist nested relvalues of EMP1. The following two deletions correspond to the insertion of two tuples into every SalHist nested relvalue :- ( EMP1 Project[ SalHist ] ) <--Delete { { Date[ 8; 7; 2003 ]; } { Date[ 11; 4; 2007 ]; ( EMP1 Project[ SalHist ] ) Restrict[ Sal = Or ( Sal = ) ] The RHS relvalue has the same type as the nested relvalues of the unnamed view. In the latter example, this is deduced from the attribute names used in the restriction condition; if there is no way of doing this, a restriction cannot be used. The RHS relvalue is deleted from each of the nested SalHist part-relvars in parallel; all the deletions must succeed or the deletion as a whole fails and EMP1 is left unaffected. Therefore in the case where the RH operand is a literal relvalue, that relvalue must exist in every nested part-relvar so that it may be deleted. In the case of the restriction expression, it likewise must always evaluate to a relvalue which exists in every nested part-relvar so that it may be deleted. However the restriction will always succeed, even though it may delete different tuples from each nested SalHist relvalue or even delete no tuples at all from any or all of them. This is because the restriction may yield a different relvalue for each of the nested SalHist relvalues. (@ represents each nested SalHist relvalue Page 11 of 14

12 for each restriction, which logically occur in parallel). Furthermore, even if the restriction yields an empty relvalue, that relvalue is still a valid subset of the nested SalHist relvalue and so may be deleted from it. Delete a single relvalue from a particular nested relvalue of a relvar. 4. Delete tuples from one specific SalHist nested relvalue. ( EMP1 Restrict[ No = 1 ] Project[ SalHist ] ) <--Delete { { Date[ 10; 9; 2006 ]; } { Date[ 6; 8; 2009 ]; ( EMP1 Restrict[ No = 1 ] Project[ SalHist ] ) Restrict[ Sal = Or ( Sal = ) ] 5. Delete tuples from one specific Time nested relvalue. ( EMP2 Restrict[ No = 2 ] Project[ ProjHist ] Unnest[ ProjHist ] Restrict[ ProjNo = P7 ] Project[ Time ] ) <--Delete { { Date[ 15; 3; 2004 ]; Date[ 19; 12; 2008 ] ( EMP2 Restrict[ No = 2 ] Project[ ProjHist ] Unnest[ ProjHist ] Restrict[ ProjNo = P7 ] Project[ Time ] ) Restrict[ Start = Date[ 15; 3; 2004 ] ] The restriction condition assumes that the values of Start can be used to pick out the required tuples for deletion. Amendment For convenience, the examples assume the initial relvalues of EMP1 and EMP2 - in fact the example deletions will have reversed the example insertions anyway. Amend an entire relvar. 1. Amend all tuples in EMP1. EMP1 <--Amend[ No <-- No + 1; SalHist <--Amend[ Start <-- Start + Day[2] ] ] Note that an amendment applies to the whole of the LH operand, in this case to every tuple in EMP1. All No attribute values are increased by 1, and all SalHist attribute values have all their Start attribute values increased by 2 days. Because the entire amendment to EMP1 has to succeed, or the entire amendment fail, then the amendments themselves need to be of such a nature that they can be applied to every tuple in the relvalue. Thus if the amendment of the No attribute value had been No <-- 1 then all the No attribute values in EMP1 would have been changed to 1; if Page 12 of 14

13 attribute No is a candidate key of EMP1, then this would have triggered an error and the entire statement would have failed. 2. Amend all tuples in EMP2. EMP2 <--Amend[ ProjHist Restrict[ ProjNo = P7 ] ] In this case, the amendment is to all the ProjHist attribute values of EMP1, and consists in deleting all tuples in every ProjHist relvalue whose ProjNo attribute value is P7. This statement will succeed even if no ProjHist attribute value contains a tuple whose ProjNo attribute value is P7, because in such cases the RH operand of the deletion will be an empty set that can always be deleted from the LH operand (and will not affect its value). Amend each nested relvalue of a relvar. 3. Amend tuples in each of the SalHist nested relvalues of EMP1. ( EMP1 Project[ SalHist ] ) <--Amend[ SalHist <--Amend[ Start <-- Start + Day[2] ] ] This amends every SalHist attribute relvalue in the LH operand by adding 2 days to every Start scalar value in every SalHist attribute relvalue. EMP1 <--Amend[ SalHist Restrict[ Start < Date[ 1; 1; 2000 ] ] Every SalHist attribute relvalue in the LH operand that contains any tuples whose Start date is earlier than 1 st January 2000 is amended by having those tuples deleted from it. Amend a particular nested relvalue of a relvar. 4. Amend one specific SalHist nested relvalue. ( EMP1 Restrict[ No = 1 ] Project[ SalHist ] ) <--Amend[ SalHist <--Insert { { Date[ 10; 5; 2006 ]; Date[ 19; 8; 2008 ] ] One SalHist attribute value is amended by having a 1-tuple relvalue inserted into it. If Unnest is included in the LH operand as follows :- ( EMP1 Restrict[ No = 1 ] Project[ SalHist ] Unnest[ SalHist ] ) <--Amend[ SalHist <--Insert { { Date[ 10; 5; 2006 ]; Date[ 19; 8; 2008 ] ] Page 13 of 14

14 then the view updating mechanism when applied to the LH operand will execute the same amendment as the previous case. 5. Amend one specific Time nested relvalue. ( EMP2 Restrict[ No = 2 ] Project[ ProjHist ] Unnest[ ProjHist ] Restrict[ ProjNo = P7 ] Project[ Time ] ) <--Amend[ End <--Amend[ End <-- End - Month[1] ] ] For employee number 2 s P7 project, this moves the End date forward by a month in all tuples (actually only one in this case) of nested relvalue Time. The following does the same but using a second unnest operation :- ( EMP2 Restrict[ No = 2 ] Project[ ProjHist ] Unnest[ ProjHist ] Restrict[ ProjNo = P7 ] Project[ Time ] Unnest[ Time ] ) <--Amend[ End <--Amend[ End <-- End - Month[1] ] ] Complex Example The examples conclude with a complex example to demonstrate the power of the assignments. Every employee is given a 10% pay rise on 28 th February Update the SalHist attribute of EMP1 to reflect this. EMP1 <--Amend[ SalHist <--Insert { { Start <-- Date[ 28; 2; 2010 ] ; Sal <-- SalHist GroupBy[ ] With[ Result <-- Bag[ Sal ] Max ] Unnest * 1.1 ] For each tuple in EMP1, the SalHist nested relvalue has another tuple inserted into it. That tuple consists of the date of the 28 th February 2010, and the new salary. Assuming the highest salary of each employee is the current salary, the new salary is calculated by using a GroupBy operation to determine the highest salary and multiplying that by 1.1. Note that the result of the GroupBy operation is a relvalue of a single tuple and a single attribute; therefore it needs to be unnested to yield a scalar value which can be multiplied by 1.1 and then assigned as a scalar value to Sal within the SalHist nested relvalue. Finally, since a RAQUEL statement can incorporate multiple assignments, it is possible to check the result of a relvalue assignment is what is expected by retrieving that result. For example (retrieving the result to a sink s ) :- s <--Retrieve ( EMP2 Restrict[ No = 2 ] Project[ ProjHist ] Unnest[ ProjHist ] Restrict[ ProjNo = P7 ] Project[ Time ] ) <--Amend[ End <--Amend[ End <-- End - Month[1] ] ] Page 14 of 14