Re: cdt glossary - TABLE

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sun, 10 Jul 2005 12:32:27 +0200
Message-ID: <42d0f93d$0$7682$e4fe514c_at_news.xs4all.nl>


Jan Hidders wrote:
> mAsterdam wrote:

>>
>> The current (0.0.4) glossary entry,
>>
>>> [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.
>>
>>  
>> , says nothing about the rows being ordered or not.
>> Should it?

>
>
> Yeah, I think we could be a bit more explicit here. It would say
> something like:
>
> A *table* consists of a table header and a body. The *table header*
> consists of a list 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 of rows where a *row* is a list of values that
> conforms to the table header.

The bag you speak of is not a mixed bag. Just the "unorderedness" of bag is crucial here, right?

Another thing bugging me is: every representation of a table /has/ order - but the tables we speak about have none - or do we pretend they have none? I would apreciate it if we would have a friendly explanation for that - it confuses anyone when starting to think about tables at first.

> You might use the notion of "ordered set" to simplify the definition of
> "table header" but that might make it less clear to some people.

*We* might :-) I invite everybody to join in trying to improve this glossary entry - as always: preferrably in a copy&pastable way.

One warning: we should not try to define table as concise as relvar. If you want to be concise just use relvar. We should just aim to pinpoint some commonly occuring confusions so we can help avoiding them. Received on Sun Jul 10 2005 - 12:32:27 CEST

Original text of this message