Re: Database design, Keys and some other things

vldm10 wrote:
> 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 took a quick look. I like your focus on events triggering changes to information. I'm still happy with 70's lingo talking about "master data" "history data" and "transaction data" that adds, changes, or deletes data in the master or history "files". (This is just a subset of data, uh, types? ;-) but a significant subset)

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

You give no rationale for that. The model I work with most closely does what you suggest. I give an "after the fact" rational for why I like that -- because the relation is more obviously a function of that ID. In IBM's UniData product that is referred to by the non-standard name of _at_ID. Every "file" has a unique @ID. But since it makes little sense to gen a key for every relationship file, you can specify all "dimensions" (if you have OLAP blood) for a relationship table in that single key with delimiters. You can do this in XML too, by having a parent tag of <ID> and then identify the components as <CarID> and <ColorID> for example.

So, what is your rationale for choosing a single, often meaningless, identifier for each relation rather than working with a more natural candidate key in a relationship table?

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

I don't like the way you confuse (IMO) entities with entities in a particular state. State properties are properties like others. You can track my mood, but if you have a Person relation and you include my mood in there, then you are going to duplicate my name in every one of those Person rows, one per mood over time? That's a lot of duplicate data.

Now you decide that you want to also track the colors I'm wearing over time? Now you have multvalued state information that would need to be somehow combined with the mood information so you can ask questions such as "Is there a correlation between the colors worn and the mood?" Would you have cartesian cross-product with the person-mood, the person-attire and the attire-colors all modeled in one relation?

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

I don't track with this. I can't recall what the TransRelational model is right now to understand the relevance -- remind me if you can. What do you mean by splitting your compound key?

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

No doubt. You can model that with a SELECT statement, right?

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

It almost sounds like you are modeling views of the data for retrieval which is a good thing to do, but not quite the same as modeling for quality transaction processing, for example. If you are modeling read-only data that would be different from data that will be maintained. If I change my name, you don't want to zip through all my attrire color mood rows to make (or neglect) that change. That is the reason for "master data" including modeling entities and current attributes/properties -- change it in one place and now we can ask questions about moods using my new name in the search criteria.

>
> > Are you familiar with any of the current approaches? What
> > deficiencies do you identify with them that your model overcomes?

I, too, am interested in what problems or opportunities you are addressing. It isn't yet clear to me. --dawn  

> >
> > Marshall
Received on Sun Sep 25 2005 - 23:59:01 CEST