Re: Database design, Keys and some other things

dawn wrote:

>

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 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 Tue Sep 27 2005 - 03:00:10 CEST