Re: cdt glossary TABLE (was: Base Normal Form)

mAsterdam wrote:
<snip old def>
> 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.

I think I'm flunking Down's law because starting with this statement, I disagree with the def of table if we are trying to use the term the way that a person who has worked with tables before, but never with databases or data modeling, would understand the term. I see no reason to define tables in a way that html tables don't at least come close to matching the definition, for example.

Can we change to "consists of an optional table header and a body"? Tables in web pages or spreadsheets might have a table header and might not. We could define an SQL TABLE as something more precise, but it would be good to define "table" as commonly used if we can.

> The *table header* consists of a list(1) of column names

so far, so good (as the description of an optional table header)

> that contains
> each column name at most once

that might be some sort of well-formed table, but I know I've seen tables with two column names the same. I think of a table as a representation (unless someone qualifies it by saying "SQL TABLE") and the table header as column headers in that representation. The digital media industry could define a video to be a file in mpeg3 format that includes credits, but that would be silly since the rest of the world knows what a video is and it need not conform to mpeg3 format and it need not have credits at all.

> 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.

I have certainly seen tables where the values do not conform to the header. I would say that such a table has some quality issues, but it is a table, none-the-less, as in "could you fix the headers on that table?" rather than "could you fix those headers so that will be a table?"

Tables in Excel or HTML can have two columns in one row and four in the next, but I'm OK with leaving such possibilities out of the definition.  There are definitely tables without values in some cells, however. And this isn't a "nulls" discussion, just an indication that a table, unlike a relation, need not have a value in every cell.

> (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.

Does this last statement add anything? Does it exclude anything?

> A column can be seen as the attribute of the
> entity/one of the entities/relationships
> about which the table is concerned.

I don't think that it is necessary nor helpful to put the words "entity" "relationship" or even "attribute" in the def of a table.

Feel free to overrule me -- I'm sortof "every man" on this one, in an effort to reduce unnecssary jargon. If we want to define a SQL TABLE this way, that's fine, but "people understand tables just fine". cheers! --dawn

> 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 Thu Jul 14 2005 - 02:46:37 CEST