Re: Database design, Keys and some other things

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.

At that page, you say:
> Here the CarKey is the Identifier of the state of the entity Car
> and this is the only column of the table which has unique values.
> So the attribute CarKey is the primary key.

If you 'ld instead have said:
"Here the CarStateKey is the Identifier of the state of the entity Car" I would have thought: "Ha, nice, an investigation into modeling state, and the difficult key issues which arise when attempting such an endevour" and I would have been interested to read on - but you didn't. Now my first reaction was: this can't be at all very interesting, because the first example starts with lies due to misnaming things - just another sign of disrespect of /meaning/. This happens a lot when one is in a state of overrating form/structure at the cost of substance/meaning. Building on that he'll just run into all the obvious errors.

The only purpose of formal reasoning is to support meaning. Ignoring that is a basic mistake.

> CarKey is Key and in my opinion it has more appropriate definition of
> Key. Current definition of Key in the database theory and its
> implementation has limitations, especially for the complex database
> projects.
> 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. (much better then the pair (23,
> vin1))
> And for these values it is "True" that they are in the relation.

Shlaer, S., and Mellor, S., Object Lifecycles: Modeling the World in States, Prentice-Hall, NJ (1992) is pre-UML, but it is a nice read. Received on Sat Sep 24 2005 - 23:47:12 CEST