Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Something that puzzled me in that book is that it claims to be math-based but they call "relations" to something that is not a relation in conventional math, and they call "tuples" to something that is unordered, namely a set. In addition, all this so explicitly set-based stuff is depicted using tables.

    Maybe I give it a second chance later, but this together with the overall style made me leave it at chapter 3.
    • Yes, tuples can be ordered while a set is not, even though tuples in the relational model are unordered. I believe the distinction here was to ensure that you don't get "Bob, Paris" (assuming "customer, city") and "Paris, Bob" (assuming "city, customer") in the same query and thus getting a result which is effectively duplicated and having negative impacts on subsequent operations. In this sense, what make a "tuple" a "tuple" is not the ordering of the attributes but the names of them. This is actually fairly common in computer science.

      Given that, how is a 'database relation' different from a mathematical one?

      • Tuples in the body of a relation (in the book's nomenclature) are essentially a set of pairs (attribute, value), where attribute is some pair (type, name) in the header. That's the way the header and the element of the set in each "row" are related, by the attribute coordinate.

        The choice of sets reflects the need to avoid the possibility to refer to columns by index, in opinion of a friend of mine.

        In math a relation is something much more simple. Given a cartesian product S = S1, S2, ..., Sn, a relation is