Re: Database design
From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Wed, 22 Feb 2006 00:23:08 +0100
Message-ID: <43fba0c5$0$11061$e4fe514c_at_news.xs4all.nl>
>
>
> Which is to say, non-parenthetically:
>
> A relation is NOT a table
> An attribute is NOT a column
> A row is simply NOT a tuple, to the latter of course, I'd agree.
>
>
> The single row is then called - what?
In the context of tables, just that: a row. In the context of relations: a tuple.
>
> Then an entity type is seen as some unique attribute domain?
>
>
> Then an entity type is not some unique attribute domain?
Date: Wed, 22 Feb 2006 00:23:08 +0100
Message-ID: <43fba0c5$0$11061$e4fe514c_at_news.xs4all.nl>
Mark Johnson wrote:
> mAsterdam wrote:
>
>>An entity is a thing of interest (old ISO definition).
>
>>Some prefer to talk about relations (or relational variables), >>attributes and tuples. >>Others about tables, columns and rows. >>Though the concepts are different
>
> Which is to say, non-parenthetically:
>
> A relation is NOT a table
> An attribute is NOT a column
> A row is simply NOT a tuple, to the latter of course, I'd agree.
> A relation is a set, which need not be written as a table, to be sure.
> But in a world of constraints, situation and conditions - in a world a
> databases and a ng devoted to an aspect of same - I also agree it
> would be reasonable to speak of relations as tables, attributes as
> columns, and rows as not . . . entities.
>
>>Yet, neither tables nor relations map to entity types.
>
>
> The single row is then called - what?
In the context of tables, just that: a row. In the context of relations: a tuple.
>>One relation may have attributese from several entitiy types,
>
> Then an entity type is seen as some unique attribute domain?
No. Why?
>>and one entity may have data spread across several relations
>
>
> Then an entity type is not some unique attribute domain?
Indeed not. Why should it? Received on Wed Feb 22 2006 - 00:23:08 CET