Talk:Relational algebra

message: Today I pretty well completely rewrote the introduction.  The most signficant changes I made are as follows:
* I emphasise the possible use of relational algebra in database query languages (the previous introduction  gave the impression it was only for internal purposes!), and I give examples of concrete syntaxes that have been devised and implemented on computers.
* I hope this isn't controversial, but I changed all uses of "operation" to "operator" and "binary operation" to "dyadic operator".  If it is controversial, I am willing to bow to a superior authority.
** I think binary operator is a more generally understood term than dyadic operator. I would be in favor of changing that use of terminology back to the way it was. I do, however, agree that operator is more appropriate than operation. Davidfstr 18:48, 26 September 2007 (UTC)
thread_title:  Reworked Introduction 

message: Trying to split each of the operations into their own articles, as follows:
* Selection (relational algebra)
* Projection (relational algebra)
:: I notice that this operator is strangely missing from the article. AndrewWarden 17:16, 31 January 2006 (UTC)
replies: text:  I notice that this operator is strangely missing from the article. AndrewWarden 17:16, 31 January 2006 (UTC)
replies: text:  I hope this won't give Codd's division, which turned out to be a degenerate case of a much more interesting operator, first defined by Stephen Todd for ISBL and further developed by C.J. Date and myself. AndrewWarden 17:16, 31 January 2006 (UTC)

text: Yeah, page stays as overview while each article of the different operations explains in depth.  —Joseph | Talk 04:33, 11 October 2005 (UTC)
thread_title: Split

message: The statement currently describing the expressive power of the given operators where it equates these with First-order logic can not be true.  Look at the page for First-order logic.  You will find that First-order logic is undecidable.  I believe that with the relational operators given we have something isomorphic to Datalog or first order logic without complex function symbols, i.e. only zero-ary function symbols.
--Gavin Mendel-Gleason
Actualy Datalog is more expressive than relational algebra applyied to DB. This is due to the introduction of operators expressin the complement in term of negation as failure. Anyway it is true that Datalog is the logic programming language more close to relational algebra.
--Paolo Ceravolo
: Satisfiability of relational algebra expressions is also undecidable in the sense that you cannot decide  whether the result is always empty, but nevertheless you are right that the power of FOL with function symbols is greater than that of the relational algebra. -- Jan Hidders 10:34, 24 January 2006 (UTC)
replies: text: A suitable relation algebra is known to be equivalent to FOL on infinite domains (this is a result of Tarski and Givant).  However, the algebra described in this article is not the standard relation algebra used by mathematians; I'm not certain of the precise strength of this scheme. Randall Holmes 01:50, 28 January 2006 (UTC)

text: There are so many problems with this paragraph that I've removed it. First, it conflated the mathematical meanings with the relational database meanings (see the section Tuple ≠ tuple, relation ≠ relation below. The extension of a predicate is not a relation in the sense of the relational model. Then, logical conjunction is an operation on truth values, not on predicates. In standard mathematics, you can have the pointwise conjunction of two predicates, but applied to has-father and has-mother, (for example Abel has-father Adam, and Abel has-mother Eve), you then get the everywhere-false predicate. The join of a FATHER relation with a tuple (child: Abel, father: Adam) and a MOTHER relation with a tuple (child: Abel, mother: Eve), on the other hand, contains a tuple (child: Abel, father: Adam, mother: Eve).  --Lambiam 20:03, 24 August 2008 (UTC)

text: Indeed, the equivalence between relational algebra and relational calculus should be detailed. Feel free to do so :) Rp (talk) 21:30, 18 April 2017 (UTC)
thread_title:  Correspondence with first-order logic 

message: The first example given between the employee and dept is not that great: it suggest a loop in the dependencies for the foreign keys: employee depends on dept, dept depends on employee. Loops in dependencies have to be avoided as they make the entities hard to save and the foreign key fields have to be nullable in all but one entity participating in the loop depencency. Please correct this example, by for example removing Manager from Dept and adding a column 'ManagesDept' to Employee which is another FK to dept.
--Frans Bouma
: These considerations don't seem very relevant to me. The purpose of the example is just to illustratie the operations, not how to model. Besides, avoiding circular dependencies is not really part of the theoretical model as it is an artefact of the limitations of certain SQL DBMSs. Moreover, your fix is actually not that uncontroversial either as it introduces a column that must have null values. -- Jan Hidders 10:34, 24 January 2006 (UTC)
thread_title:  Circular inclusion dependencies / foreign keys 

message: The symbol of the natural join in this article doesn't appear correctly in some machines (it appears as a square), as the author initially used some special symbol fonts that some systems may not have. Perhaps the author should consider changing the natural join symbol into an image, so that it can be displayed correctly in all system  (previous comment originally left on main article page by )
:Or, we could use ×. It looks almost like the bow-tie symbol, and fits with the =×= syntax for outer joins. -- Mikeblas 00:39, 28 January 2006 (UTC)
replies: text: I am unable to see the symbol as well; I am using Chrome and it is unable to auto-detect a good encoding. What character set is the symbol under? -- J.Dong820 (talk) 14:26, 17 December 2011 (UTC)
thread_title:  Natural join symbol 

message: The statement "In Codd's 1970 paper, selection is called restriction[1]" is wrong. 
The "restriction" operator defined by Codd is nowadays called "semijoin". (Indeed
a semijoin reduces the number of tuples of a relation, as a selection does. However, 
it makes use of a second table but not of a booelean function to do so.)  
I've moved the statement to the semijoin section. --Kowarschick (talk) 11:36, 10 August 2018 (UTC)
thread_title: Selection

message: * JA: I just reorganized the gangly projection disambig page and chunked out projection (mathematics) to its own page.  Jon Awbrey 17:32, 31 January 2006 (UTC)
replies: text: But I still don't see a definition of the relational algebra operator called projection, which should be equated to existential quantification in predicate logic. AndrewWarden 18:52, 1 February 2006 (UTC)

text: AW: I've just noticed projection (relational algebra) for the first time, with a history indicating that it's been there for quite some time.  I'm puzzled, as I couldn't find it until today.  Sorry for any confusion. Now that I've seen it, I see that there are some minor changes I'd like to make.  The SQL reference isn't quite right, and there ought to be a note about implementations of projection in computer languages (in particular, the possibility to mention the attributes to be excluded rather than those to be included, the exclusion case being slightly closer, psychologically, to existential quantification).  But I'll hang fire until I hear that you've finished what you want to do.
* JA: I don't think I'll be touching the relational algebra or relational model articles, except cosmetically, anytime soon, as I'm still refreshing my memory and reviewing newer literature on these more concrete aspects that I last worked with many odd years ago.  The relation (mathematics), projection (set theory), and related articles will be pretty standard stuff, from a slightly combinatorial perspective, and so should be pretty independent of what you need here, though I will eventually want to think a little more about the relation between what I think of as "abstract types", that have shapes like X_1 x … x X_k, and "concrete types", where you have meaningful attributes to worry about.  But it's way too soon for that.  Jon Awbrey 16:22, 2 February 2006 (UTC)
thread_title: Projection

message: From Right Outer Join:
The right outer join can be simulated using the natural join and set union as follows:
: R X= S  =  S ∪ (R\bowtieS)
From Set Operators:
Although three of the six basic operators are taken from set theory, there are additional constraints that are present in their relational algebra counterparts: for set union and set difference, the two relations involved must be union-compatible — that is, the two relations must have the same set of attributes.
The two clauses above are incompatible. What is the correct way of simulating the outer joins with the more primitive operators?
Jon Thoroddsen 14:42, 24 February 2006 (UTC)
replies: text: Use \bowtie: \bowtie —Drowne | Talk 00:00, 7 July 2006 (UTC)
thread_title: Joins, natural and otherwise

message: * JA: Here's the best that I could do for the θ-join after a day's fiddling with TeX.  For some reason the negative space trick does not work in a matrix format, so the center does not hold the two vortices together!
\begin{matrix}R\ \triangleright\!\triangleleft\ S \\ \ i\ \theta\ j \end{matrix}
\begin{matrix} R\ |\!>\!<\!|\ S \\ i\ \theta\ j \end{matrix}
* JA: Jon Awbrey 18:56, 1 February 2006 (UTC)
thread_title: Joins, natural or else

message: I think the sentence "and we wish to find the branch name with the highest balance, we would write Branch_NameGMax(Balance)(Account)" is incorrect. From what I understand, this will find the max balance in each branch. —The preceding unsigned comment was added by 72.94.106.67 (talk) 03:15, 19 February 2007 (UTC)
thread_title:  Aggregation 

message: Something seems wrong -- Ulricp (talk) 09:46, 17 May 2016 (UTC)
replies: text: A (Database1, Database2) x B (Fred, Sara) does NOT give us C (Completed)! Original contributor, please fix that.
Why is Eugene missing? --Weedrat 14:18, 6 May 2007 (UTC)

text: The division (Completed ÷ DBProject) gives the Students who have entries (in the Completed table) for all the tasks in the DBProject table. In this case the DBProject table only contains two tasks: Database1 and Database2. You see that (Fred, Database1) and (Fred, Database2) are both in the Completed table, therefore Fred is in the result. Similarly, (Sara, Database1) and (Sara, Database2) are both in the Completed table, therefore Sara is in the result. Eugene doesn't have an entry for Database2, so Eugene is not in the result. Egriffin 22:01, 9 November 2007 (UTC)
replies: text:  So, there's a mistake here, then? The result table shows Fred and Eugene, not Fred and Sara. I'll change it. 155.97.198.74 (talk) 05:57, 8 February 2011 (UTC)
thread_title:  Division Results 

message: Shouldn't the "Manager" column be there as well or am I wrong here? -Weedrat 13:34, 8 May 2007 (UTC)
thread_title:  Semi Join and anti join 

message: Is the code point for a bowtie really notable? It's the only occurrence of "Unicode" and "U+" in the article. Should we mention code points for every symbol used? I don't think it belongs in an article about mathematics — I can't recall other articles about maths mentioning code points (equally we could have "In LaTeX, it's \bowtie"). ⇌Elektron 14:44, 13 September 2007 (UTC)
thread_title:  Unicode code points 

message: Relational algebra has numerous analogies in SQL implementations. As a large number of database developers are well-versed in the SQL language, and that it's likely that this page would be visited by people who are very familiar with industry language knowledge, it would be useful, where direct analogies exist, to add SQL equivalents to the relational algebra examples. 
I would be happy to do this pending approval of each example here in "Talk."
:Please note that this is a property of SQL itself, given the semantics of SQL, and not specifically of SQL implementations. The term "analogy" is a bit out of place. Languages like FORTRAN and Java incorporate operations from arithmetic like addition and multiplication; these are not "analogies" of the arithmetic operations. Likewise, SQL incorporates operations from the theory of relational databases, which is based on relational algebra.  --Lambiam 08:59, 17 January 2008 (UTC)
thread_title:  SQL Analogies 

message: In a mathematical context, a tuple is an element of some Cartesian product, and a relation is a set of tuples forming a subset of some Cartesian product.
In relational database theory, these terms have related but different meanings. Each of the components of a tuple (also known as its fields) has a unique field name associated with it. Where (34, true) is a mathematical tuple, (age: 34, male: true) is a database tuple, also known as "record" or "row". It can be formally defined as a finite function that maps names to values, essentially the same as an assignment. A relation in relational database theory is then a set of such rows, all with the same set of component names, and for a given component name normally all with the same type of value. Where {(34, true), (40, false), (66, true)} is a mathematical relation, {(age: 34, male: true), (age: 40, male: false), (age: 66, male: true)} is a database relation.
Unfortunately, the article does not carefully distinguish between these meanings where it should.  --Lambiam 19:37, 24 August 2008 (UTC)
replies: text: An important distinction worth correcting, I'll see what I can do. Kareeser|Talk! 04:29, 5 February 2010 (UTC)
replies: text:  Actually there is both a named and unnamed perspective for tuples in the relational model. See the "Alice" book , pp. 32-33. There's caveat though: "this leads to different but equivalent sets of natural primitive algebra operators for the two perspectives." Tijfo098 (talk) 17:46, 9 November 2012 (UTC)
thread_title:  Tuple ≠ tuple, relation ≠ relation 

message: In the section on "Selection and projection", "elided" seems like a rather obscure word to use in the sentence "since projection may produce fewer tuples due to the elimination of duplicates resulting from elided fields". Would it not be clearer to simply use the word "omitted"?  —Preceding unsigned comment added by 142.58.133.238 (talk) 00:07, 30 January 2009 (UTC)
replies: text: Done. Tijfo098 (talk) 02:33, 22 November 2012 (UTC)
thread_title:  Question 

message: The article (as of 13 Jan 2011) says that the theta-join is only defined if the attributes of R and S are disjoint.  This may not be the case, since any particular theta-join on R and S will simply produce a subset of the relational Cartesian product R x S.  Usually columns in R and S that share the same name are disambiguated in the new relation (R x S), by naming columns R.colname, S.colname, so the issue where the attributes of R and S being disjoint doesn't seem to arise at all.
See for example: athena.comp.rgu.ac.uk/staff/rab/Databases/Slides/Lecture5-Relational-Algebra-and-SQL.ppt  —Preceding unsigned comment added by 24.205.19.130 (talk) 21:59, 13 January 2011 (UTC)
thread_title:  Theta join 

message: [I am Hugh Darwen, who is mentioned in the implementations section of this article.  I see that I did some work on this article back in 2006 but I had forgotten that when I wrote these comments.]
The article is quite good but I have some comments that I think should be addressed.  I might have a go at editing the article myself but I'm not sure I'm up to that yet because the notation it uses is awkward for me.
1. The section on natural join is incorrect in equating that operator to "equijoin".  I think the statement should just be deleted.  Equijoin is correctly covered in the section on theta-join.
2. Extension (like rename and others, added by ISBL) is arguably needed for completeness--just as arguably as selection is, for that matter.  Without it, we would have to achieve the same effect using natural join with relations representing operators such as "+", and such relations are infinite (or at best hopelessly large if we assume finite domains).  If extension is taken as primitive, then attribute renaming can be expressed in terms of extension and projection.
3. Selection is the term originally used by Codd but since SQL came along and used the key word SELECT for a different purpose, this operator is usually referred to as restriction (and spelled WHERE in English notations).
4. I think the mention of foreign keys in the section on natural join is de trop.  The mention of the use of rename to make common attributes is good, but the impression should not be given that it's applicable only when the common attributes constitute a foreign key.  In any case, relational algebra is not concerned with database constraints.
5. The example given for selection is needlessly clumsy.  "=true" can simply be omitted wherever it appears. It would be much clearer to use a simple comparison such as "birthdate<hiredate" for the restriction condition.
6. If non-primitives such as outer joins and semijoins are to be included, then I would add composition, where the composition of r1 and r2 is their natural join projected on all but the common attributes.
7. The section on projection fails to mention its connection with existential quantification in logic.  Also, it should perhaps be mentioned that in a computer language we would expect projection to be alternatively expressible in terms of attributes to be excluded (corresponding to predicate variables being bound by quantification), as it was in ISBL.
8. In general, the operator definitions are rather imprecise.  For example, the definition of projection seems to state that each tuple in the result is a set of attribute names (rather than attribute values).
9. The formal definition for natural join puzzles me where it states "where Fun is a predicate that is true for a relation r if and only if r is a function."  The argument to the invocation of Fun in the definition appears to be a tuple (the union of tuples t and s), not a relation. I normally teach that the union of those tuples must be a tuple, meaning that it can't contain more than one attribute value for the same attribute name.  I suppose it is regarding a tuple as a binary relation mapping attribute names to attribute values, in which case we do require that relation to be a function of attribute names, but the definition would allow it to be a function of attribute values, which is neither sufficient nor necessary.  In any case it is a bit confusing to treat a tuple as both a relation and a member of a relation.
10. The section on natural join uses the term "columns" when referring to attributes.
Enough for now.  I haven't scrutinised all of the text and I may come back with more later.
Hugh Darwen (AndrewWarden (talk) 12:48, 15 March 2012 (UTC)
thread_title:  Some comments 

message: That's apparently a Tutorial D keyword  (also PL/SQL one, but it does something else in PL/SQL: extends collections, which are obviously not relations). The Tutorial D keyword is stuff nobody cares about but Date. Tijfo098 (talk) 02:05, 22 November 2012 (UTC)
replies: text: Actually, the section did have a point; I hope I have expressed it more clearly now. Tijfo098 (talk) 21:09, 22 November 2012 (UTC)
thread_title:  Deleted section on EXTEND 

message: The Symbols for the three different types of outer join do not display in the latest version of Chrome. I don't know Wikipedia well enough to know if there's a potential way to fix this, perhaps someone else does? They display fine in IE. ChrisInUK (talk) 11:56, 4 April 2013 (UTC)
thread_title:  Outer Joins 

message: The formal definition of semijoin given does not seem like a well-formed set description:
: R \ltimes S = { t \in R, s \in S, Fun (t \cup s) }
Would not it be better to define semijoin like the following, i.e. as antijoin with unnegated existence quantifier (which also seems to connect well with the informal description of semijoin given in the text)?
: R \ltimes S = { t : t \in R \and \existss \in S : Fun (t \cup s) }
KarlPettersson81 (talk) 20:18, 21 January 2014 (UTC)
thread_title:  Definition of semijoin 

message: I deleted two paragraphs that were out of context and related to best practices around schema design, rather than relational algebra specifically.  — Preceding unsigned comment added by WKALT (talk • contribs) 04:09, 25 March 2015 (UTC)
thread_title:  deleted content in introduction 

message: I read the symbol used is usually γ (gamma) and sometimes 𝒢. Galzigler (talk) 14:43, 22 December 2019 (UTC)
thread_title:  aggregate operation symbol 

message: The article entirely misses an definition for unions of relations, but uses them to describe joins. I think without a defintion for a\cup b it's not clear what the resulting relation would look like. I'm not sure if that's even correct.
What do the authors want to say, if they write:
I think it should mean:
r \cup s = (r_1,\ldots,r_n) \cup (s_1,\ldots,s_n) = (r_1,\ldots,r_n,s_1,\ldots,s_n). But the article should mention that or provide a link to an article with the defintion of "unions" in terms of relations, because usually a union would mean something like \{r,s\} = \{(r_1,\ldots,r_n),(s_1,\ldots,s_n)\} (The index denotes the n-th attribute of a relation).
-- 79.205.3.15 (talk) 12:06, 15 April 2020 (UTC)
replies: text: Isn't it more of a something like that: 
For relations r(R), s(S), that is relation R with schema r,
R \bowtie S = \left\{t \in R \times S \ \vert \ \forall f \in r \cap s : t_{R.f} = t_{S.f} \right\}
Galzigler (talk) 02:00, 31 July 2020 (UTC)
thread_title:  Union operator on relations 

message: The section on joins is very long and detailed, and this article is approaching the 50kB mark. Projection (relational algebra) and Selection (relational algebra) already have their own pages. Arguably, join is even more notable than either of these two operations; join algorithms are extensively studied in the literature. For all of these reasons, I propose we split out the section "Joins and join-like operators", add a summary to the "Introduction" section as is done for the other operators, and possibly also move the section on outer joins to the new page. siddharthist (talk) 17:29, 5 March 2023 (UTC)
replies: text: Support I agree that this should go somewhere else  there is already Join (SQL), but I think that this is sufficiently distinct to coexist with a theoretical treatment on a separate page. I would certainly also move the section on outer joins, to prevent that from overwhelming this article. Felix QW (talk) 19:33, 18 November 2023 (UTC)
thread_title:  Split join into its own article