Re: Database design, Keys and some other things

JOG wrote:
> Very interesting post, as I think the effect you have produced is
> simliar to transclusion. Consider that a car cannot simultaneously be
> silver and blue. Let us also agree, that despite its current colour the
> buick vin1 is the same car throughout its life, despite its changing
> characteristics.
>
> So now you have an interesting problem - you want to record the same
> entity in a set multiple times (it has the same carID right, and this
> is its primary key?),

The primary key is the CarKey attribute. CarKey and CarID together provide a things related to the Real World, CarKey alone is related to the database i.e. CarKey is the Primary Key or simple Key. So CarKey and CarID together provide identification, meanig and some knowledge about the Real World entity's (or relationship's) instance.

Vladimir Odrljin

>but the definition of a set precludes this. Yet
> your overall aim seems reasonable. Something, somewhere is awry.
>
> Philosophically, according to the constructivist approach anyhow, the
> answer lies in the fact that the car now and after its new paint job,
> are different items (this seems counterintuitive at first) - yet two
> items obviously extremely closely related to each other. From this
> viewpoint an object is not defined by some magical, universal
> fingerprint, for there is none. Rather it can be decomposed
> (or deconstructed) into a combination of:
>
> (1) an entity, representing the concept of the car, which is
> irreducible (a chosen, human artifice).
> (2) this instance's relations with other items in the world.
>
> What is chosen as irreducible for (1) and at what level you are
> deconstructing (2) is up to what level of detail is useful for you and
> your users - for a driver, colour, interior style, top speed, etc, seem
> fine, a mechanic might deconstruct down to engine specs and lengths of
> nuts and bolts, a physicist down its atoms, and so on ad infinitum.
>
> Ok, the point of this is not to try and be clever or existential, but
> rather because there is a practical result to this line of thought:
>
> Your car now and a year ago are the same item (1 is the same), however
> its defining relations to the world (2) have changed. It is in one
> sense the same item, yet in another sense a different item, as it is
> existing in a different context. In computer science this is analagous
> to Ted Nelson's concept of transclusion, and is a potentially powerful
> mechanism.
>
> This concept however does not fit particularly neatly into RDBMS as,
> because of the constructivist approach, a car entity has no physical
> representation - and so no value for relational calculus to reference
> against. However in RM, giving the entity item an artificial key and
> you have an effective fudge, doing the job.
>
> In your example this car entity is represented by its (carID and Make),
> but its instance is represented by its (CarKey).
>
> J. Goulding
>
>
> (This sort of approach is in early stages of development at University
> of Nottingham, UK, but I'd be interested to hear any critiques -
> throughout, the use of the word instance is obviously distinct from any
> programming connotations of the term. For constructivism see
> http://en.wikipedia.org/wiki/Constructivist_epistemology and for
> transclusion see google)
>
>
> vldm10 wrote:
> > Here is a simple example about two entities and one relationship - Car,
> > Person and Owner. It tries to describe more realistically Real World
> > situations. A car had its color changed twice. In the Real World
> > attributes are often changed. In another entity, the person Mary
> > changed her last name because she got married. In the relationship
> > Owner it can happen that one person buys the same car twice during a
> > period of time. It can also happen that two entities can be in the same
> > relationship many times. So,I believe that this new approach is more
> > appropriate.
> >
> > Given the table Car :
> > CarKey CarID Make Color ...
> > ______________________________________________________
> > ...
> > 23 vin1 Buick silver ...
> > 24 vin1 Buick blue ...
> > 25 vin1 Buick red ...
> > 26 vin2 Honda silver ...
> > 27 vin3 Ford black ...
> > ...
> >
> > In the Car table VIN = Vehicle Identification Number
> >
> > Now, let Person be the following table:
> > PersonKey PersonID PersonName ...
> > _______________________________________________________
> > ...
> > 208 ssn1 Mary Jones ...
> > 209 ssn1 Mary Adams ...
> > 210 ssn2 John Stewart ...
> > ...
> >
> > In the Person table SSN = Social Security Number
> >
> > Then the relationship Owner, which is the act of owning a car, can have
> > the following
> > values:
> > OwnerKey Person Key CarKey Year ...
> > ___________________________________________
> > ...
> > 54 210 26 2003 ...
> > 55 210 24 2004 ...
> > 56 210 26 2005 ...
> > ...
> >
> > More details about this example can be found on my website
> > www.dbdesign10.com
> > where I gave a new definition of Key and tried to develop a new Data
> > Model.
> > Any feedback is greatly appreciated.
> >
> > Vladimir Odrljin
Received on Mon Sep 26 2005 - 04:18:05 CEST