Re: Database design
From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Wed, 22 Feb 2006 01:12:15 +0100
Message-ID: <43fbac43$0$11074$e4fe514c_at_news.xs4all.nl>
>
>
> Only because:
>
>
>
>
> But, okay
>
>
>
>
>
>
> And because a single table may have columns, each of which have
> different - types? What your definition of - entity? and "entity
> type"?
>
>
> It appears definitional.
Date: Wed, 22 Feb 2006 01:12:15 +0100
Message-ID: <43fbac43$0$11074$e4fe514c_at_news.xs4all.nl>
Mark Johnson wrote:
> mAsterdam wrote:
>
>>>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.
>
>>Not to the first two?
>
> Only because:
>
>>>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.
I really do not understand what you are trying to say.
>>>>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.
>
> But, okay
?
>>>>One relation may have attributese from several entitiy types,
>
>
>>>Then an entity type is seen as some unique attribute domain?
>
>
>>No. Why?
>
>
> And because a single table may have columns, each of which have
> different - types? What your definition of - entity? and "entity
> type"?
I don't think it is nice to snip a definition, then ask for it again, and ask for antoher one.
>>>>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?
>
>
> It appears definitional.
What is your definition of the relevant terms? Received on Wed Feb 22 2006 - 01:12:15 CET