Re: Database design, Keys and some other things

From: Marshall Spight <marshall.spight_at_gmail.com>
Date: 25 Sep 2005 16:23:26 -0700
Message-ID: <1127690606.819864.208560_at_g49g2000cwa.googlegroups.com>


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 didn't find that to be so. There's a small section near the bottom that says "Solutions for two significant problems" but I didn't find any clear problem statement in there. The closest was "recognize who created the data and how it was created" but it's not at all clear what that means. I haven't seen anything in your examples that tracks who created the data.

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

Okay. So you're starting with the relational model and restricting it by disallowing multiple keys or compound keys. That's already not a good sign. You've significantly limited the expressiveness of the model, and you haven't explained what you feel you've gained in return.

> > 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 would not say this qualifies as specific problem statement. You've also introduced a non-standard term ("TransRelational Model") without any definition or references. The only transrelational model that I know of is one occasionally referenced on dbdebunk.com, and as I understand it, it's purely an implementation technique, so I have no idea why you'd be discussing it at the logical level.

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

I don't understand this notation at all. What does the : mean? What is T? I also note that you didn't answer any of my questions in the earlier paragraph.

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

Okay. So you're saying that your area of concern is that we can identify one thing using our knowledge? I'm not sure what that means. Again, a specific problem statement would help.

> So
> there are many way to identify one thing. We can use our knowledge
> instead of the identifier.

SQL already does quite well at this. How do you propose to make it better? Alternatively, what aspects of its current capabilities do you hope to improve?

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

I don't find this kind of analogy very useful. Generally with computers we are trying to solve algorithmic problems, not find cars in parking lots. I don't see the commonality.

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

I'm assuming that since you didn't answer this, you're *not* familiar with any of the current approaches.

The general impression I'm getting of you is of someone who is smart and fairly creative and also lacking in any real-world experience. It might be useful to develop your ideas if you got a job in data management, and thereby collected a set of *really* Real-World problems-- that is, problems that actually come up in business or science. In general, recording different colors of car paint or finding cars in parking lots do not fall into the category of hard problems for computer science; but there are plenty of other problems that *are* hard that a smart and creative person could really help with. But you absolutely need the experience first, and also the education to know what else has been tried. Otherwise you'll just spend years rehashing what everyone else has already thought of.

Good luck!

Marshall Received on Mon Sep 26 2005 - 01:23:26 CEST

Original text of this message