Re: Database design, Keys and some other things

Marshall Spight wrote:
> I'm not clear what you're setting out to do, or what problems

You can find this on my website.
I added Events and the new way of construction of the entities and relationships to the Conceptual Model. The intention is that there is only one key in the Conceptual Model. No the candidate keys, and no the compound keys. The same intention is in the Logical Model. The definition of key is also new.
I included the knowledge which is related to data in this Data Model.

> 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.
>
> Can you be specific about what these limitations are? And why

The limitations are basically related to above mention. Let me give you one example.
Let Key for a relation be a compound key which has two attributes. If you want to build TransRelational Model then you should "split" your compound key. This can complicate the reconstruction of the "record".
(I will replay to dawn also regarding some limitations )

> 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?
>
> If (23, vin1), (24, vin1) and (25, vin1) identify one car, that
> says that vin identifies car.

vin1, also can determine the set S = {x: tE(x, vin1) = T} where E(x, vin1) is the sentence: " the x is in the relation E with the vin1"

>
> 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?

No. The idea is that we can identify one thing using our knowledge. So there are many way to identify one thing. We can use our knowledge instead of the identifier. For example, if you ask your friend to bring your car from a parking lot then he will rather use his knowledge to find your car than look for VIN. One person can be identified as father of his son or as husband of his wife or a man who is living in that house or by his name.
Set of CarKeys which are in a relation with one CarID, forms better knowledge to identify one car.

> Are you familiar with any of the current approaches? What
> deficiencies do you identify with them that your model overcomes?
>
>
> Marshall
Received on Sun Sep 25 2005 - 22:42:02 CEST