Re: cdt glossary TABLE

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Thu, 14 Jul 2005 20:17:17 +0200
Message-ID: <42d6ac29$0$35706$e4fe514c@news.xs4all.nl>

dawn wrote:
> 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."

Downs' law. I'll try to remember.

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

"[Table]" (unqualified) is in the ToDo part of 0.0.5

The heading is (unchanged from 0.0.4):

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

If there would also be a [Table] entry without qualification the implied context would stand out some more. I'll try reaping some of your text for that below.

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

                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Same here, see below.
> 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?

In a discussion long time ago a kind of rigid mapping from entities, attributes and
relationships to tables, columns and
foreign keys was assumed as broadly accepted. I dont' remember exactly when.
This statement challenges the automatism of such a mapping and IMO implies that design of tables takes intelligent effort, even when there is an agreed upon ER-model.

BTW this is from the unchanged (from 0.0.4) part of the proposal.

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

:-)

[snip]

for [Table] I reaped:

I know I've seen tables with two column names the same. I think of a table as a representation.
I have certainly seen tables where the values do not conform to the header. There are definitely tables without values in some cells.

It's a start. Received on Thu Jul 14 2005 - 13:17:17 CDT