Re: Identity modelling

paul c wrote:
> Gene Wirchenko wrote:
> > On Tue, 30 Aug 2005 13:08:28 +0300, "x" <x@xxxxxxxxxxxxxx> wrote:
> >
> >
> >>"David Cressey" <david.cressey@xxxxxxxxxxxxx> wrote in message
> >>news:wIVQe.3985$_84.3105@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >>
> >>
> >>>One interesting case is that of the URL. Is a URL a key or a pointer?
> >>
> >>Does
> >>
> >>>it name the resource, or does it locate the resource?
> >>
> >>It is a pointer, not a key.
> >>The URL and the resource are not tied together.
> >
> >
> > It is a key since it does not specify the location. In a way,
> > DNS is concerned with translating this key into a pointer.
> > ...
>
> Apologies if I'm taking David's original question above out of context,
> but 'out of context' seems important in this case. As far as the RM is
> concerned, my understanding is that within the RM something (ie.
> attributes) is a key only within a relation. It's a set of attributes
> with some constraint on their values that allows other single-valued
> attributes to be dependent on the key values. There are deeper reasons
> for it, but that's the only essential one I know of.
>
> Some people say a key is an "address" because keys have been described
> as the RM's "addressing mechanism". It doesn't follow that a physical
> storage address is at all the same thing. For example, outside the RM,
> how could a physical address possibly point to a tuple in a relation?
>
> As far as the RM is concerned, once you take it out of the database
> context, it can be anything one might want it to be even if it doesn't
> make sense. You could call it Margaret Thatcher or a kumkwat and the RM
> wouldn't care. This is okay even if it doesn't make sense. It must be,
> witness all the applications that don't make sense.
>
> There was some talk recently to the effect, if I read it right, that a
> generated IDENTITY (perhaps the capitals have some special meaning to
> some particular product) somehow pollutes or entangles or locks-in a
> logical database. Not sure whether this particular IDENTITY was
> intended to be a value that is merely generated somehow or if it refers
> to, say, a storage location of some physical machine.
>
> I'd say whether it is one or the other doesn't matter at all to the RM.
> It may matter to some application that happens to be mapping memory
> but that's neither here nor there for the RM. There's nothing I know of
> in the RM that forbids a certain value. If some user or some program
> inserts it, all the database wants to know are the internal rules it
> should follow in deciding whether to allow the insert. If it is a key,
> then one mandatory rule will be that no tuple with the same value for
> those attributes can be the same. There might be other rules too and a
> designer might write some kind of trigger or procedure that goes outside
> the database to see if it's a real address. That sounds like
> application to me.
>
> Same thing goes for generated keys. If they happen to be sequential,
> the RM won't care, as long as they are 'unique'. Some application could
> depend on sequence but it would have to guarantee the sequence itself.
> Good argument for user domains. Guaranteeing sequence without gaps is a
> bigger problem than many people realize in fact I believe even though I
> can't prove it except anecdotally that there are always situations when
> it won't work. So an application would have to do this itself and make
> whatever conditions it need to stick, stick. It might happen to use
> some DBMS features to make this happen such as locking support, but I
> don't think there is any RM feature it could use or at least any that
> would be the only way to do it.
>
> The arguments about IDENTITY or anything else for that matter, being
> problematic to a 'relational' database because they are physical and not
> logical *outside* the database are apples and oranges and straw at the
> same time. Just noise for consultants and various writers to make when
> they can't think what to say next. Confusing silence with stupidity.

Joe's critic of the INDETITY as a badly written software is okay. He
also wrote "In the Relational Model, you do not invent a key in the
storage. You discover a key (and the other attributes) in the real
world and model it." And this is the most important. However in my
opinion, Joe pays less attention to what a surrogate key is and how it
can be used.
Codd writes "there are three difficulties in employing
user-controlled keys as permanent surrogates..." Actually, in the
RM/T Codd uses surrogate keys which are "system-assigned".

>
> I detect a consultant's trick in the argument that the database must
> contain only the 'logical' values and not 'physical' ones, where
> customers or readers might be confused by all the red herrings thrown up
> into thinking that if values are only "logical" then the corollary
> being that the database that has been designed for them must be logical
> too, a kind of sine qua non for their application being logical to boot.
> This is complete BS.
>
> There's also nothing in the RM, at least what I've read about it, that
> prefers generated keys over 'natural' keys. A generated key might be a
> tell-tale that some designer wasn't capable of considering the uses of
> natural keys in future applications and simply copped out. But it could
> mean the opposite as well - that the designer was fully aware of all
> intentions for the database and was explicitly ruling out natural keys.
>
> There's at least one other time when a generated key could help, for
> example when you've screwed up the design and people have put lots of
> data into the db. Then you could, conceivably, at least append a key,
> take some projections and join / union them into the tables you should
> have designed in the first place.
>
> What a user thinks a key means is something the RM isn't really
> concerned with. It's up to the designer to tell them how it should be
> used, ie. what it means as far as the user doing the user's job is
> concerned. The designer might tell one set of users, say the Human
> Remains people, that there are two sets of departments, one that the
> Payroll users see in the view defined for them and another one that the
> HR people can see as well. Just two attributes in the DEPT table, only
> the Payroll people can't see one of them. Why would you do this? Well,
> the HR people could update one row and move everybody in one department
> to another. Only the HR people would have to remember that the two
> attributes had different meanings. Contrived example, I'll admit, but
> it does show why users have to be educated by the designer.
>
>
> Ah, that feels better,
> thanks,
> p

Vladimir Odrljin

.

Relevant Pages

  • Re: Identity modelling
    ... >> DNS is concerned with translating this key into a pointer. ... > but 'out of context' seems important in this case. ... > As far as the RM is concerned, once you take it out of the database ... > designer might write some kind of trigger or procedure that goes outside ...
    (comp.databases.theory)
  • Re: Identity modelling
    ... As far as the RM is concerned, once you take it out of the database ... designer might write some kind of trigger or procedure that goes outside ... depend on sequence but it would have to guarantee the sequence itself. ... intentions for the database and was explicitly ruling out natural keys. ...
    (comp.databases.theory)
  • Re: Virtex 4 FIFO16 blocks - Corruption ?
    ... I am not asking forgiveness, but asking for some help in how to deal with these issues. ... One minor difference for me may be that when I find unusual behavior and have it isolated to a functional portion of the design, I may check the knowledge database for any information relating to my problem area before spending a few more days to further isolate the cause. ... A simple statement in the user's guide saying that the FIFO16 is an async FIFO and has these particular limitations when used in an application where both clocks are the same would have been sufficient to avoid a heck of a lot of troubleshooting time, and would have put the onus on me the designer. ...
    (comp.arch.fpga)
  • Using Data Environment Designer with VB6-P SP6
    ... My VB6 project is referencing Visual Basic for Applications, ... Microsoft Data Binding Collection VB 6.0, ... Each database set up in the Designer usaes the Connection Source property: ... both use user and password security, but no actual database password is set. ...
    (microsoft.public.data.ado)
  • Re: problem using identity column as primary key
    ... >> I am thinking of creating an identity column to use it as primary key ... More and more programmers who have absolutely no database training are ... the gap in the sequence is not filled in and the sequence ... vin CHARNOT NULL REFERENCES Motorpool); ...
    (microsoft.public.sqlserver.programming)