Re: Database design, Keys and some other things
- From: "Marshall Spight" <marshall.spight@xxxxxxxxx>
- Date: 24 Sep 2005 11:56:32 -0700
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
.
- Follow-Ups:
- Re: Database design, Keys and some other things
- From: vldm10
- Re: Database design, Keys and some other things
- References:
- Database design, Keys and some other things
- From: vldm10
- Re: Database design, Keys and some other things
- From: mAsterdam
- Re: Database design, Keys and some other things
- From: vldm10
- Database design, Keys and some other things
- Prev by Date: Re: Database design, Keys and some other things
- Next by Date: Re: Encoding materialized path in an atomic value.
- Previous by thread: Re: Database design, Keys and some other things
- Next by thread: Re: Database design, Keys and some other things
- Index(es):
Relevant Pages
|
