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
2) Every attribute of an entity can change its value - like in
"Temporal DB"

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?

Vladimir Odrljin

vldm10 wrote:
I have a feeling you are going to need to recast your conditions. If
all the attributes are mutually independent, then the only candidate key
for the relation is the combination of all N attributes, is it not?

Two entities? Where did the second one appear from? You started with
an entity with 200+ attributes, and ... magic'd a second one out of thin
air?

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler (AT) earthlink (DOT) net, jleffler (AT) us (DOT) ibm.com
Guardian of DBD::Informix v2007.0914 -- http://dbi.perl.org/

ptb/PTB-1860 whirlpool2 2007-11-24 00:00:06
88FCD1C504D5345557AF5FEA2991A9138F5D151C781AC5FC29 6732F1BFDA6C7371B115
AB2B27673813EC1EE5320A28C938AA7316F4FCD544113EF4AB D4C9C9A

On Nov 24, 12:38 am, vldm10 <vld... (AT) yahoo (DOT) com> wrote:
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.

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.

A binary relationship, without use of a surrogate, would obviously
require twice the number of attributes that made up the aforementioned
superkey.

Hmmm, why do I get the feeling you're about to try and sell me
something?

On Nov 23, 9:32 pm, Jonathan Leffler <jleff... (AT) earthlink (DOT) net> wrote:
Yes, but at least 200 attributes. I mean it should be more then 200
regarding condition 2). Condition 2) in fact involves "Temporal DB"
considerations.

Let it be the two entities, so that we can make m-n relationship.

Vl. Odrljin

On Nov 23, 10:36 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:
It should be at least 400 attributes by my calculation.
Are you familiar with "Temporal DB" theory?

This is m-n relationship and the key can have more attributes then you
wrote.

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

On Nov 24, 5:38 am, vldm10 <vld... (AT) yahoo (DOT) com> wrote:
You think a relation with 200 attributes should have a superkey
containing 400 attributes? I see.

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.

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 (DOT) nott.ac.uk> wrote:

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.


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

Vladimir Odrljin

"JOG" <jog (AT) cs (DOT) nott.ac.uk> wrote

It cannot be determined whether two representations from two distinct points
in time refer to the same individual--even if all of the attribute values
are identical--unless, of course, one of the attributes is a surrogate;
therefore, your statement that it would be a different entity altogether is
unfounded.

How else could you determine if the butterfly that you're looking at now is
the same individual as the catepillar that you were looking at several
months ago.

I think that it is most important that if you can identify an individual at
multiple points in time, for example, T1 and T6, then it should be possible
to track that invidual through time, noting the changes that occur at each
transition, so that at T6, the individual identified /is/ the individual
that had been tracked. It should be obvious that if prime attributes can be
the target of an update, then it is not necessarily the case that the set of
attribute values that identifies an individual at T1 identifies the same
individual at T6. It may be that the set of attribute values that
identifies an individual at T1 identifies a different individual at T6.

"Brian Selzer" <brian (AT) selzer-software (DOT) com> wrote


Do you mean "surrogate" or "synthetic" ?

"David Cressey" <cressey73 (AT) verizon (DOT) net> wrote

I don't know what you mean by "synthetic." What I mean by a surrogate is a
value that always refers to a particular individual and can never refer to
any other individual. How it comes into being is irrelevant.