Re: cdt glossary TABLE
Date: Thu, 14 Jul 2005 20:17:17 +0200
Message-ID: <42d6ac29$0$35706$e4fe514c_at_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 - 20:17:17 CEST