Let's say operator rename n (r)
returns a table value like r
but with new attribute names like the old ones prefixed with n.
. Then we have:
/* rows where
(cid, sid, grade, gradepoint) in Enroll
and (x.cid, x.sid, x.grade, x.gradepoint) in Enroll
and gradepoint < x.gradepoint and cid = x.cid
*/
restrict gradepoint < x.gradepoint and cid = x.cid (
Enroll times rename x (Enroll)
)
(Which are rows of the form (cid, sid, grade, gradepoint, x.cid, x.sid, x.grade, x.gradepoint)
.)
Unfortunately that comment doesn't say anything about the business situation. So neither does the table. But suppose in our case (cid, sid, grade, gradepoint) in Enroll
when in course
cid
student
sid
got grade
grade
& grade point average
gradepoint
. (This is the table's (characteristic) predicate in business terms.) Then by replacing the in
we get that that query is also:
/* rows where
in course cid student sid got grade grade & grade point average gradepoint
and in course x.cid student x.sid got grade x.grade & grade point average x.gradepoint
and gradepoint < x.gradepoint and cid = x.cid
*/
Each row in a table value (constant/variable or query result) makes a statement from plugging it into the table's predicate. (And each absent row states the negation/not
of the statement from plugging it into the predicate.) The designer gives the constant/variable predicates and the query result predicate comes from those & the relation operators. (restrict
& join
s (including times
& intersect
) introduce and
, project
introduces there exists
, union
introduces or
, minus
introduces and not
, etc.)
Here, the statement involves one course and two gradepoints, each belonging to a different student. So there's no "where the gradepoint is lower than itself".
Forming a relational algebra query from an English description
Is there any rule of thumb to construct SQL query from a human-readable description?
(A so-called "algebra operator" like you mention to "rename" a value is really a programming language non-terminal for assignment to a variable. That is orthogonal to algebra values & operators. Such muddling arises from unclear thinking, typical of SQL apologetics.)