In mathematics, a relation is a set of ordered pairs.
Strictly speaking, the relations of database theory are different objects, but closely related. (Yes, I just made an awesome pun.)
I'm surprised that the author didn't include "a relation is a set of tuples" as a definition in the article. Also, absolutely nothing is said about viewing a relation as a graph.
I suspect that using unordered sets as the foundation for databases might have been a mistake, and ordered lists with allowed repetition would've made a better model, if only because they can model tables and query results equally well (ORDER BY, SELECT without DISTINCT). Is there a good reason why this road was not taken?
In most actual implementations of relational DBs there's nothing to disallow repetition in a table - you just don't specify a primary key (or preferably have a unique primary key that's just an ignored surrogate).
The difficulty with caring about ordering in the relational model is that suddenly you're imposing a lot more constraints: when you're joining two tables, whose order 'wins'? If you say (for example) that left side wins, you then need to keep track of that order through your query.
"The self is a relation that relates itself to itself or is the relation's relating itself to itself in the relation; the self is not the relation but is the relation's relating itself to itself." - Kierkgaard
However, if the employee name in the function is not Daniel Smith but the employee is in marketing, the first predicate is true. How does that fit into relational databases?
The arrow notation here is not material implication, but function evaluation. The function itself can be interpreted as an Indicator Function[1] for the employee set, or alternatively, as simply evaluating the predicate.
In terms of tables, the rows are exactly the subset of predicates that are TRUE. So FALSE statements like the second one are indicated by their absence in the employee table.
Comments
In mathematics, a relation is a set of ordered pairs.
Strictly speaking, the relations of database theory are different objects, but closely related. (Yes, I just made an awesome pun.)
I'm surprised that the author didn't include "a relation is a set of tuples" as a definition in the article. Also, absolutely nothing is said about viewing a relation as a graph.
I suspect that using unordered sets as the foundation for databases might have been a mistake, and ordered lists with allowed repetition would've made a better model, if only because they can model tables and query results equally well (ORDER BY, SELECT without DISTINCT). Is there a good reason why this road was not taken?
In most actual implementations of relational DBs there's nothing to disallow repetition in a table - you just don't specify a primary key (or preferably have a unique primary key that's just an ignored surrogate).
The difficulty with caring about ordering in the relational model is that suddenly you're imposing a lot more constraints: when you're joining two tables, whose order 'wins'? If you say (for example) that left side wins, you then need to keep track of that order through your query.
Would you want bag semantics for things like union and intersection then?
Yes, that sounds reasonable. I don't know very much about the practical uses of union and intersection in SQL, though.
The followup article (http://merrigrove.blogspot.com/2013/12/the-occultation-of-re...) is really good, too. I particularly liked the concrete example of the "projection".
"The self is a relation that relates itself to itself or is the relation's relating itself to itself in the relation; the self is not the relation but is the relation's relating itself to itself." - Kierkgaard
Sorry, had to chime in with that
You have the following material implications:
However, if the employee name in the function is not Daniel Smith but the employee is in marketing, the first predicate is true. How does that fit into relational databases?P.S. Great article!
The arrow notation here is not material implication, but function evaluation. The function itself can be interpreted as an Indicator Function[1] for the employee set, or alternatively, as simply evaluating the predicate.
In terms of tables, the rows are exactly the subset of predicates that are TRUE. So FALSE statements like the second one are indicated by their absence in the employee table.
[1] http://en.wikipedia.org/wiki/Indicator_function
Thanks! I had no idea