Re: Surrogate Keys: an Implementation Issue

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 22 Jul 2006 16:14:58 GMT
Message-ID: <6aswg.13587$pu3.314383@ursa-nb00s0.nbnet.nb.ca>

David Cressey wrote:
> "Paul Mansour" <paul_at_carlislegroup.com> wrote in message
> news:1153486989.391427.38540_at_m79g2000cwm.googlegroups.com...
>

>>paul c wrote:
>>
>>>I feel like my mouth has been taped over, hands cuffed and head tied to
>>>a bouncing ball and my neck is aching from trying to follow it.
>>
>><snip>
>>
>>>"produce the result" is a tricky phrase because it hints at both logical
>>>and physical.  We must separate how we produce from what results.
>>>
>>
>>paul c,
>>
>>Sorry if I've given you a headache, and thanks for your patience!
>>
>>I may be mixing logical and physical models in the discussion. I think
>>part of the problem is that there may well be a third,intemediate level
>>that I'm really attempting to discuss. Sort of like the TRM -- it's a
>>layer bewtween the logical and physical.
>>
>>In the below discussion, I'll use "table" and "row" for this
>>intermediate level, and resort to "relation" and "tuple" when refering
>>to the logical model. Considers the following "table":

>
> PMFJI. The substance of this discussion is generally more abstract than I'm
> comfortable with. I don't intend to distract.
>
> I think you are right about the third level, and I think your choice of
> "table" and "row" is useful nomenclature for that level.
>
> I'd like to suggest a name for that level, namely "Database Language". SQL
> is a database language, and possibly the most widely used, and it uses the
> nomenclature "table", "row", and "column". Since 1992, it's also used the
> term "domain", although some SQL diealects used it in 1986 or earlier.
> That's NOT to suggest that every discussion about tables rows and columns is
> necessarily guided by the syntax and semantics of SQL. However, avoiding
> mentioning it is like not talking about the elephant in the room.
>
> I'd also like to suggest that the "logical vs physical" distinction has
> evolved over the last 30 years, and in particular over the last six years,
> while I've been reading this newsgroup.
>
> My first exposure to these terms in a database context was, IIRC, in an
> early book by James Martin. IIRC, that book didn't even discuss relational
> databases, or, if it did, I skipped over that part. In any event, the
> "logical vs physical" distinction there resembled the distinction that in
> OO parlance is referred to as "public features vs private features". That
> is, if the programmer (really the programmer's program) can see it, then
> its logical, but if not, then it's physical.

Replace programmer or program with user, and what you have stated is a decent goal. It is not really a definition of physical, because some products do a poorer job of hiding the physical from users. One prefers to hide all physical information from non-expert users and let them deal only with the much simpler logical design.

The physical level of discourse deals with physical locations on disk or in memory etc. That's what defines it.

 From the perspective of a DBA, some of the physical design is external and available for manipulation while most of it is internal to the dbms. Thus the physical encoding of a pointer is internal to the dbms, while the DBA can specify how to physically arrange pointers into indexes, lists etc. Likewise, the DBA can specify what data to cluster together without dealing directly with the internal representations. The DBA does this by specifying some sort of mapping between the logical and the physical.

I suspect what people refer to as an intermediate level is the external physical level of discourse as opposed to the internal physical level of discourse. Received on Sat Jul 22 2006 - 11:14:58 CDT