Re: Database design, Keys and some other things

Marshall Spight wrote:
> vldm10 wrote:
> > Let the data from the relation Car be represented with the following
> > relations:
>
> It looks to me like what you're doing is ordinary data modelling.
> (Although I will add you are doing it somewhat formally and quite
> well.) I am not sure if you are claiming to be doing anything more.
> Are you?

Here the database was implemented so that the relation's columns are stored separately, similarly as in the TransRelation™ Model. I used my Data Model 2.4 under 2 ( without a knowledge). All the relations are made by the queries, except K,E,S-Relations i.e. the relations data are derived. It is also solution related to some very important things. Key K identifies the tuple and K is part of this tuple.

S-Relation:

a) Determines the keys in the database
b) Shows relationship among P and E
c) Associates knowledge related to P

This c) case is important because here user can to determine which key is "close", which one was maybe wrong, who open this key, when, by which procedure etc. Using knowledge columns we can precisely determine keys so that we can exactly say which RM's and CM's keys are correspondent, and which keys are out of this mapping. Using S-Relation it is easy to get all P or All E.

> For example, the three relations you describe strike me as
> overly complex unless the application has a requirement to
> store past values of the color of the car. Without that requirement,
> you could simply collapse the three relations into one, keep

I agree. However we can say that now CarKey = CarID. (It is possible to work with both in case, if you need to hide the CarID, but then we need the normalisation regarding possible transitive FD) It is also problem to work with the knowledge columns as well as with the database which columns of the relation are stored separately.

> only the current color, use VIN as the key, and lose the
> CarKey. (I know this happens in the real world, because
> my wife sometimes loses her CarKeys.)
>
>
> Marshall
Received on Sun Oct 02 2005 - 07:59:45 CEST