Re: Database design, Keys and some other things

From: vldm10 <vldm10_at_yahoo.com>
Date: 29 Sep 2005 13:02:33 -0700
Message-ID: <1128024153.556718.36300_at_g43g2000cwa.googlegroups.com>


vldm10 wrote:
> dawn wrote:
> >
> > So, what is your rationale for choosing a single, often meaningless,
> > identifier for each relation rather than working with a more natural
> > candidate key in a relationship table?
>
>
> I do not generate only a key; it is also the attribute which is the
> name of the relation's instance. In current RM, typically, you do not

Here I made mistake it is not a name it is the key and the attribute. So it is as I wrote in my text at www.dbdesign10.com Sorry about this The point was that in my definition it is a key and an attribute. In current RM it is key. It can be an attribut but not in case of a compaund key.

> have an attribute which is the name of the relation's instance, you
> have only the key. The key can be compound - meaning a key can be a set
> of the attributes; i.e. the key is not an attribute. So my solution is
> the attribute and it can't be meaningless because attribute has
> origins in Conceptual Model and meaning in the Real World. A key which
> has number as value is annoying, but we always use some additional
> information to get meaning in the Real World. It is same case with SSN,
> VIN etc.
> If we have the Car table with the cars which attributes are all the
> time same, it is okay to use existing RM solutions. However the RM's
> definition of the key can't support cases which we discussed. In
> these cases we need maybe to split the table. This involves a FK and
> the data integrity or we need some additional "fields" which are
> not the attributes, or we need some additional attributes. If an
> entity has an attribute which repeats its value then I prefer my
> solution. Relationships repeat their values more frequently then the
> entities.
> Finally current implementation of the Relational Model causes some
> problems.
> The TransRelational™ Model is what the database world is waiting. It
> provides a completely new approach to implementation. In this Model
> columns are stored separately. But the key definition in the RM should
> be changed. The logic of the compound key is directly opposite to the
> logic of this model.
> In 2.4 under 2. on my website I set more general representation of
> storing the columns separately. An example 2.5 shows how knowledge can
> be represented regarding one data (column Amount) and using the key
> which is related to the state.
>
>
> Vladimir Odrljin
Received on Thu Sep 29 2005 - 22:02:33 CEST

Original text of this message