Re: Database design, Keys and some other things

From: Marshall Spight <marshall.spight_at_gmail.com>
Date: 24 Sep 2005 11:56:32 -0700
Message-ID: <1127588192.332053.36050_at_g14g2000cwa.googlegroups.com>


vldm10 wrote:
> The tables are simplified for the purpose paying attention to keys.
> There is the complete explanation of this example, definition of Key
> and others things related to it, on my website www.dbdesign10.com.
> CarKey is Key and in my opinion it has more appropriate definition of
> Key.

I'm not clear what you're setting out to do, or what problems you're setting out to solve. Often these kinds of discussions are best begun with a specific problem statement. Just saying that what you're doing is "more like the Real World(tm)" is not a useful statement; all modelling is an approximation of reality; the question is, what is it about reality that we want to model? Studying the definition of "abstraction" may prove useful.

> Current definition of Key in the database theory and its
> implementation has limitations, especially for the complex database
> projects.

Can you be specific about what these limitations are? And why do you distinguish between the definition and the implementation? The implementations of keys in the databases I've worked with have matched the definition precisely. Are you saying there is a problem with the implementation relative to the existing definition? If you're saying there's a problem with the definition, how does that mean there's a problem with the implementation?

> I would like to emphasizes the relation between CarKey and CarID ( I
> call this E-relation in my Data Model because this is the entity
> level).
> For the table Car following set of the pairs
> (23, vin1), (24, vin1) and (25, vin1)
> identify one car in the Real World.

If (23, vin1), (24, vin1) and (25, vin1) identify one car, that says that vin identifies car.

Your examples suggest that what you're trying to do is capture the history of changes to an entity. Is that your area of concern? Are you familiar with any of the current approaches? What deficiencies do you identify with them that your model overcomes?

Marshall Received on Sat Sep 24 2005 - 20:56:32 CEST

Original text of this message