Re: Objects and Relations
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 15 Feb 2007 21:25:57 GMT
Message-ID: <Fd4Bh.6942$R71.103943_at_ursa-nb00s0.nbnet.nb.ca>
>
> Thanks Jim. I've been trying to keep a low profile until I'd read a bit
> more. This thread got one of the points that I found interesting,
> thought, so I thought I might jump in.
>
> [...]
>
>
> Interesting. This, I guess, is part of the perspective you can get when
> the details become more familiar.
>
> [...]
>
>
>
>
> Ok.
>
>
>
> I guess I was thinking along these lines. Say, for example, social
> security fraud. When you see some tuples in some PEOPLE relation, with a
> primary key SSN.
>
> Person: {<SSN:12345, Name:"Fred">, <SSN:23456, Name:"Bill">}
>
> it is safe to assume that
>
> - there is an entity we are modelling, call him entity_fred,
> with a name "Fred", and
> an SSN 1234.
> No other entity exists with a SSN 12345.
>
> - there is an entiry we are modelling, call him entity_bill,
> with a name "Bill" and,
> an SSN 2345.
> No other entity exists with a SSN 12345.
>
> However, the relation, taken alone, does NOT mean that the entity_fred
> and entity_bill are distinct entities.
>
> Sure.
>
>
> This seems like a really useful, concise description of the difference.
> Especially in light of you comment above, i.e. programming construct vs
> logical attribute. Did you mean obstruse, or obtuse, though?
>
> I'll have more questions, of course.
>
> Thanks muchly,
> Joe
Received on Thu Feb 15 2007 - 22:25:57 CET
Date: Thu, 15 Feb 2007 21:25:57 GMT
Message-ID: <Fd4Bh.6942$R71.103943_at_ursa-nb00s0.nbnet.nb.ca>
> JOG wrote:
>
>> On Feb 15, 3:54 am, Joe Thurbon <use..._at_thurbon.com> wrote: >> >> Hi Joe, good to see you are still about.
>
> Thanks Jim. I've been trying to keep a low profile until I'd read a bit
> more. This thread got one of the points that I found interesting,
> thought, so I thought I might jump in.
>
> [...]
>
>> >> Remember we need something *in the real world* to identify the things >> we talk about. The problem has to be dealt with way before we even get >> to the database.
>
> Interesting. This, I guess, is part of the perspective you can get when
> the details become more familiar.
>
> [...]
>
>
>> > Would I be correct in saying that all OIDs are surrogate identifiers, >> > but that not all surrogate identifiers are OIDs?
>
>> No. OID's are a programming mechanism - they are pointers.
>
> Ok.
>
>
>>> BUT one entity can have two values for the surrogate identifier. >> >> No. Well it is /possible/ but it is a mistake outside the database- >> one person could have two employee ID's for example, but this would >> cause a lot of confusion. I once ended up with two payroll numbers and >> it caused havoc.
>
> I guess I was thinking along these lines. Say, for example, social
> security fraud. When you see some tuples in some PEOPLE relation, with a
> primary key SSN.
>
> Person: {<SSN:12345, Name:"Fred">, <SSN:23456, Name:"Bill">}
>
> it is safe to assume that
>
> - there is an entity we are modelling, call him entity_fred,
> with a name "Fred", and
> an SSN 1234.
> No other entity exists with a SSN 12345.
>
> - there is an entiry we are modelling, call him entity_bill,
> with a name "Bill" and,
> an SSN 2345.
> No other entity exists with a SSN 12345.
>
> However, the relation, taken alone, does NOT mean that the entity_fred
> and entity_bill are distinct entities.
Person is just a name for a predicate. Whether and how it describes anything in 'the real world' is part of the external predicate. The dbms neither knows nor cares about the meaning of the word 'Person'. One could replace the name 'Person' with 'Hornswoggle' or 'x' and the dbms wouldn't care or notice. Hornswoggle would work exactly like Person.
>>> (2) No two entities can share the same OID, AND no entity can have >>> two OIDs. >> >> Again thinking in terms of entities is the path to confusion. Take a >> step back and think about what we are actually communicating and >> recording - propositions.
>
> Sure.
>
>>> Cheers, >>> Joe >> >> >> OID's and surrogates are both mechanisms to represent uniquencess. >> Surrogates are externally visible attribute values (goodness). OID's >> are obtuse, hidden pointers (badness), >>
>
> This seems like a really useful, concise description of the difference.
> Especially in light of you comment above, i.e. programming construct vs
> logical attribute. Did you mean obstruse, or obtuse, though?
>
> I'll have more questions, of course.
>
> Thanks muchly,
> Joe
Received on Thu Feb 15 2007 - 22:25:57 CET