cdt glossary TABLE (was: Base Normal Form)

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Mon, 11 Jul 2005 23:23:26 +0200
Message-ID: <42d2e34c$0$14451$e4fe514c_at_news.xs4all.nl>


David Cressey wrote:
[snip]
> Actually, I didn't think there would be any discussion of the word "table".
>
> All I mean by "table" is the same thing that the word means in common SQL
> parlance. And that's what I expected everyone to understand that I meant.
> Oh, well.
>
> I'd be very surprised if the cdt glossary has no entry for "table". It
> seems a curious omission.

The current (0.0.5) entry is:



  [Table/Row/Column] (SQL-DBMS)
  Table: A collection of columns (the table header) and rows (the body).   Row: A collection of values, conforming to the table header columns.

  One table may contain data about one entity,   about several entities, about one or several   relationships or any combination.
  A column can be seen as the attribute of the   entity/one of the entities/relationships   about which the table is concerned.


After some editing (reaping :-) of the thread (most notably Jan's contributions),
I now propose this:



[Table/Row/Column] (SQL-DBMS)

C Date and H Darwen in The Third Manifesto, 1st ed, p135, footnote: "/Relation/ has a precise (and somewhat abstract) definition;   /table/ by contrast, does not." (italics original)

Nevertheless people (and DBMS's, and SQL) *do* use the words as if they were. Here is what we've come to expect what people mean when they use these words.

Down's law: "People understand tables just fine."

A *table* consists of a table header and a body. The *table header* consists of a list(1) of column names that contains each column name at most once and associates with each column name in that list a certain type. The *body* is a bag(2) of rows where a *row* is a list(1) of values that conforms to the table header.

(1) The column names and the values are ordered. (2) The rows are unordered; duplicates

     are allowed. It is not a mixed bag, though:
     all rows conform to the header.

Note that a representation of a table in memory or on paper will (almost always) introduce an order on the elements. This is similar to how denotations of a set such as {a, b, c} and {c, b, a} also introduce each a different order on the elements of the set.
In the first denotation the order is a < b < c, in the second it is c < b < a. This order, however, is merely an aspect of the representation and not a property of the thing that is represented. In other words, the two different denotations actually represent the same thing. For tables this means that the order in memory of the representation of the body is not really part of the body, or, put in another way, if we change that order in the representation then it would still represent the same body.

One table may contain data about one entity, about several entities, about one or several relationships or any combination.
A column can be seen as the attribute of the entity/one of the entities/relationships about which the table is concerned.

If you can afford to be informal - think of Down's law. If you need to be concise, don't use 'table'. Use 'relation'.


Received on Mon Jul 11 2005 - 23:23:26 CEST

Original text of this message