Re: the two questions
From: Brian Selzer <brian_at_selzer-software.com>
Date: Tue, 27 Nov 2007 15:49:05 GMT
Message-ID: <R%W2j.71504$YL5.33622_at_newssvr29.news.prodigy.net>
>> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
>>
>> news:ba48040b-485c-483c-9e1d-5cff82845c62_at_e6g2000prf.googlegroups.com...
>>
>>
>>
>> > On Nov 25, 7:16 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>> >> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
>>
>> >>news:8505d954-cdc3-4bf8-9107-b307563be0e8_at_r60g2000hsc.googlegroups.com...
>>
>> >> > 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 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.
>>
>> >> >> 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.
>>
>> >> 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.
>>
>> > Oh lets not do the dance all over again brian. Its got the same
>> > gene's, whatever. Something has to be consistent for them to be the
>> > same thing. Even if it just ends up being the fact that they share the
>> > same path of x,y locations over time (I'd use a surrogate for that one
>> > hey, otherwise it be a hell of a long attribute), there has to be
>> > something.
>>
>> > There just is no great big invisible pointing hand amigo.
>>
>> From a given database value D, you can arrive at a new database value D'
>> in
>> one of two ways: (1) by simply stating D', or (2) by stating how D must
>> be
>> transformed to produce D'. Either way, you still arrive at the same
>> answer,
>> D', but there can be a great many possible transformations from D to D'.
>> Identifying which transformation is actually occurring makes it possible
>> to
>> track an individual across database transitions: this is--in effect--the
>> great big invisible pointing hand!
>>
>>
>> >> 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.
>>
>> > If it helps, why don't you view your butterfly/caterpillar as a little
>> > "insect life" entity. Identify that. Then you might start to see that
>> > T1-T6 are just different snapshots of it. But for any snapshot, to
>> > recognize it as our "insect life" entity, we need that identifier.
>>
>> Not if T1-T6 are not just snapshots but also successive snapshots. If
>> the
>> identification at T1 is known, and the assertions that yield the values
>> at
>> T2, T3, T4, T5 and T6 are known, then the identification at any snapshot
>> can
>> be derived from the available information.
>>
>>
>>
>> >> >> 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.
>>
>> >> > Hmmm, why do I get the feeling you're about to try and sell me
>> >> > something? ;)
>>
>> >> >> Vladimir Odrljin
> Received on Tue Nov 27 2007 - 16:49:05 CET
Date: Tue, 27 Nov 2007 15:49:05 GMT
Message-ID: <R%W2j.71504$YL5.33622_at_newssvr29.news.prodigy.net>
"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:64389199-45c3-4c6d-99e6-1c6a89736d72_at_j44g2000hsj.googlegroups.com...
> On Nov 26, 2:38 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
>>
>> news:ba48040b-485c-483c-9e1d-5cff82845c62_at_e6g2000prf.googlegroups.com...
>>
>>
>>
>> > On Nov 25, 7:16 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>> >> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
>>
>> >>news:8505d954-cdc3-4bf8-9107-b307563be0e8_at_r60g2000hsc.googlegroups.com...
>>
>> >> > 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 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.
>>
>> >> >> 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.
>>
>> >> 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.
>>
>> > Oh lets not do the dance all over again brian. Its got the same
>> > gene's, whatever. Something has to be consistent for them to be the
>> > same thing. Even if it just ends up being the fact that they share the
>> > same path of x,y locations over time (I'd use a surrogate for that one
>> > hey, otherwise it be a hell of a long attribute), there has to be
>> > something.
>>
>> > There just is no great big invisible pointing hand amigo.
>>
>> From a given database value D, you can arrive at a new database value D'
>> in
>> one of two ways: (1) by simply stating D', or (2) by stating how D must
>> be
>> transformed to produce D'. Either way, you still arrive at the same
>> answer,
>> D', but there can be a great many possible transformations from D to D'.
>> Identifying which transformation is actually occurring makes it possible
>> to
>> track an individual across database transitions: this is--in effect--the
>> great big invisible pointing hand!
> > > I'm sure your a lovely chap brian, but I just don't seem to be able to > keep things on track with you... you asked me about a caterpillar - > butterfly. I told you that they still have to have some characteristic > that is observably consistent to recognize they are the same thing, > and now your talking about database values. Lets get the conceptual > level cleared up first hey before we dive into the logical one! > > Look, ride with me on this - are we agreed in /the real world/ there > is no big invisible pointing hand? I'm sort of envisioning one of > those big foam things that fans wear at baseball matches now ;) In > other words, are we agreed that the caterpillar and butterfly have to > share some attribute to be viewed as two snapshots of the same entity > (in order to identify that entity as one consistent thing). Forget > database encodings, I'm just talking about in the real world. >
Each individual that existed, exists, or can exist has a property that distinguishes it from all other individuals that existed, exist or can exist; so, yes, there is a property that the caterpillar and butterfly share. The problem is: I don't think haecceity can be observed directly. If one were able to examine the history of the butterfly, one should be able to determine that it coincides with the history of the caterpillar--up to the point of the initial snapshot. The problem is: I don't think history can appear in a snapshot.
>
>>
>>
>> >> 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.
>>
>> > If it helps, why don't you view your butterfly/caterpillar as a little
>> > "insect life" entity. Identify that. Then you might start to see that
>> > T1-T6 are just different snapshots of it. But for any snapshot, to
>> > recognize it as our "insect life" entity, we need that identifier.
>>
>> Not if T1-T6 are not just snapshots but also successive snapshots. If
>> the
>> identification at T1 is known, and the assertions that yield the values
>> at
>> T2, T3, T4, T5 and T6 are known, then the identification at any snapshot
>> can
>> be derived from the available information.
>>
>>
>>
>> >> >> 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.
>>
>> >> > Hmmm, why do I get the feeling you're about to try and sell me
>> >> > something? ;)
>>
>> >> >> Vladimir Odrljin
> Received on Tue Nov 27 2007 - 16:49:05 CET