Re: the two questions

My intention in this post is database theory, especially "Temporal DB" theory and the complex databases. I also think that term "Temporal databases" is wrong. Regarding "Temporal DB" theory there are the different groups world-wide with the different approaches to this problem often with strong disagreement among them, the critics etc.
Here is example with huge amount of the attributes. Although a theory don't need to worry about the number of the attributes (usually the theory is general), it is interesting to consider some things, like the keys, or how to represent distinct facts with own relations (6NF) - regarding that key brings the hundreds of information, how to design these databases, etc.
So the first step in this discussion is - how many attributes the key has. But it should be just first step. My main intention here is the following question: is this theoretical problem or technical?

On Nov 24, 8:40 am, JOG <j..._at_cs.nott.ac.uk> wrote:
> On Nov 24, 5:38 am, vldm10 <vld..._at_yahoo.com> wrote:
>
> > On Nov 23, 10:36 pm, JOG <j..._at_cs.nott.ac.uk> wrote:
>
> > > On Nov 24, 12:38 am, vldm10 <vld..._at_yahoo.com> wrote:
>
> > > > Not long time ago on this NG there were few posts which involved an
> > > > entity with 200+ attributes.
> > > > Let all these attributes satisfy the following two conditions:
> > > > 1) All these attributes are mutually independent
>
> > > Then there are no functional dependencies so the entity can only be
> > > identified by the collection of all its attributes - and hence you'd
> > > end up with an equivalent superkey. If any of those attributes
> > > "change" it would also therefore be a different entity altogether.
>
> > It should be at least 400 attributes by my calculation.
>
> You think a relation with 200 attributes should have a superkey
> containing 400 attributes? I see.

Usually in the temporal databases we add two new "attributes": datefrom and dateto to an attribute.
So in general case you will have A1, datefrom1, dateto1,..., A200, datefrom200, dateto200
(this is 600 attributes)
However if you want to represent date as (yy,mm,dd,hh,min,sec) you will have 2600 attributes.
Now we have to construct key. You can notice that one attribute can change its value so that after a period of time the attribute can get same value. This can happened with all other attributes. So we must to add date in key.
In my solution, my key has always one attribute. So I am not so familiar with above constructions which are from "temporal database" theory. I believe that I gave good number of the attributes for a key.

>
> > Are you familiar with "Temporal DB" theory?
>
> Of course, but I don't see what relevance it has here. Temporal
> databases just augment the current key with time data, so the entity
> may be followed over its lifetime. One still needs to be able to
> recognise that entity with a stable identifier.

This about "stable identifier" is direct consequence of my solution which is on www.dbdesign10.com

Vladimir Odrljin

>
>
>
>
>
> > > > 2) Every attribute of an entity can change its value - like in
> > > > "Temporal DB"
>
> > > Nope, not gonna squeeze that one past. If they are all unstable, well
> > > then, you are saying there is not a single attribute that is
> > > consistent over the entity's lifetime? In that case how could you
> > > ever identify it in the real world following change? Perhaps hire
> > > someone to follow it down the street continually pointing at it?
> > > Y'know, Its strange we don't get more of that in daily life, given the
> > > popularity of OID's in IT... oh well, I guess we're stuck with the old
> > > fashioned method of identifying things by looking at them.
>
> > > > Now I have two questions:
>
> > > > 1) How many attributes has a key of the corresponding relation?
> > > > 2) How many attributes has a key of m-n relationship between the two
> > > > mentioned entities?
>
> > > A binary relationship, without use of a surrogate, would obviously
> > > require twice the number of attributes that made up the aforementioned
> > > superkey.
>
> > This is m-n relationship and the key can have more attributes then you
> > wrote.
>
> > > Hmmm, why do I get the feeling you're about to try and sell me
> > > something? ;)
>
> > This is about compex DB and some interesting cases about them.
> > I beleive they will be actual in near future, people start to ask
> > about it.
>
> > Vl. Odrljin
>
> > > > Vladimir Odrljin- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Received on Sat Nov 24 2007 - 20:49:51 CET