Re: Smart Database Tricks

From: vldm10 <vldm10_at_yahoo.com>
Date: Thu, 21 Jun 2007 12:17:17 -0700
Message-ID: <1182453437.505388.258560_at_c77g2000hse.googlegroups.com>


On Jun 18, 7:41 pm, Jan Hidders <hidd..._at_gmail.com> wrote:
> On 18 jun, 20:59, vldm10 <vld..._at_yahoo.com> wrote:
>
>
>
>
>
> > On Jun 15, 8:42 pm, Jan Hidders <hidd..._at_gmail.com> wrote:
>
> > > On 15 jun, 21:42, vldm10 <vld..._at_yahoo.com> wrote:
>
> > > > On Jun 14, 10:23 am, Jan Hidders <hidd..._at_gmail.com> wrote:
>
> > > > > On 14 jun, 12:55, vldm10 <vld..._at_yahoo.com> wrote:
>
> > > > > > Here I believe that you misunderstand what is key. I have
> > > > > > 1. the identifier of the state of an entity or relationship
> > > > > > 2. the identifier of the entity or relationship.
> > > > > > [...big snip...]
>
> > > > > [....] So how about
> > > > > you giving some proper definition and/or explanation of what they
> > > > > mean?
>
> > > > The names of these identifiers are with exact meaning. This is reason
> > > > why the names are so long.
> > > > You can find it on my website, where I presented this model. So
> > > > theoretical background you can find there (No needs to write it
> > > > twice). All terms are very precisely defined or I gave their
> > > > construction.
>
> > > Well, what you give is a description of how they behave, but you do
> > > not really define them in terms of the universe of discourse.
>
> > Once again, all terms are precisely defined or I gave their
> > construction.
>
> Well, it that is going to be your position I'm afraid the discussion
> has to stop here. I've indicated already which terms I think are not
> well-defined and you have refused to give any further clarification.

I didn't have time to respond.
As I told you, your question is right and I believe my answer is good. Maybe your question can be expressed on another way as well as my answer, but at this moment, I believe it is OK. On my web site I define construction of these identifiers as well as some other things related to the identifiers.

> Yes, I did read your web page, and, no, it is not precise enough.

This confuse me. For example you asked me " How do you define the state of an entity?".
I have this definition on my web. It is given in 5.7 . Also in 5.8. I gave definition of change of the state of an entity.

> So,
> since I don't understand your terminology well enough it is simply not
> possible for me to continue this discussion in a meaningful way.

Before we complete the discussion about the conceptual level I have one question.
Here in example1 I gave the identifier of an entity Car. It is about VIN = "vehicle identification number".
The identifier is not local for Car entity. It is global. Let me say we have here global lawful information, which is completely accepted as successful solution in the reality and in every country. You state that "...adding such artificial implementation concepts are usually a bad idea..." Can you explain why VIN is a bad idea? Otherwise I can't accept your position about the identifiers.

Here are some notices related to the identifiers. These notices are not related to your question mentioned above, they are additional aspects about the identifiers.

1)
I use identifier in sense just to identify something. I didn't use term like name, which can draw much more things. For example a name of somebody parents, can draw memories, emotions etc.

2)
This example is about Sir Walter Scott who is the author of Waverley. The example is due to B. Russell.
At diner at which W. Scott was present, a person X asked W. Scott "Are you the author of Waverley"?
W. .Scott answered: "Sire, I am not the author of Waverley". (W. Scott didn't want to say the truth, that he is the author of Waverley) Now we have the two semantics. The person X thinks that this is not Sir Walter Scott.
However W. Scott didn't want to say that he is not W. Scott. He didn't want to say "I am not I", despite he didn't say the truth regarding the author of Waverley.
This well known example says that identifying by role of an object can be a bad idea. Here the role is "the author of". With this example I didn't mean to speak about the role of an object in NIAM/ORM theory. This is about identifying.

3)
In recent time I noticed in this NG the sentences like "numeric id column". As id is in fact identifier, we can set the question - what is numeric identifier. Are we use the numbers as the identifiers. And which numbers? Is it possible to use real numbers for identifiers? For example "pi". Or we can use integers? Theoretically it can be much identifiers. So there is question regarding construction of much numbers.
Maybe here we can't speak about the numbers as the identifiers, but we can speak about using the names of the numbers as the identifiers. And again, which numbers - real or integers - and there is question about the construction, this time it is the construction of the names of the numbers. If we are speaking about the identifiers related to the entities or to the events or to knowledge, then in my opinion this matter can be very complicated.

>
> However, in the following part you seem to start from the relational
> model, which is terminology I understand. So I will try to continue
> from there.
>
>
>
>
>
> > Example1
> > Let we have the following Car table
>
> > CarKey CarID Maker Type Color Datefrom
> > Dateto
>
> > ...
> > 23 vin1 Buick sedan silver
> > 1.1.2000. 12.31.2000.
> > 24 vin1 Buick sedan blue
> > 1.1.2001 8.1.2001
> > 25 vin1 Buick sedan red
> > 8.2.2001 1.1.2005.
> > 26 vin1 Buick sedan silver
> > 1.2.2005 999999
> > 27 vin2 Honda sedan silver
> > 3.15.2006 999999
> > 28 vin3 Ford sedan black
> > 1.1.2005 999999
> > ...
>
> > 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. Car ID is an Identifier of the entity Car. We use
> > VIN values
> > for this attribute. Maker and Color are the attributes of the entity
> > Car.
> > "999999" means that corresponding data is current.
> > Here Datefrom and Dateto are strictly related to attribute Color (not
> > to entity car).
> > Datefrom and Dateto are not the attributes. They are a part of our
> > actual
> > knowledge about the attribute color.
> > (so here the "The information principle" is not appropriate, because
> > the entire
> > information content is not represented as values in attribute
> > positions, i.e.
> > here we also represent knowledge about attribute Color )
>
> That depends on what you call an attribute.

I am using my definition of the attribute. This definition is on my web site under 5.2.

> If this is a relation then
> all columns are attributes and since you have represented all the

Can you please, tell me what is the definition of the attribute in RM. I didn't notice this definition in RM.

> information in them you are, as far as the relational model is
> concerned, completely faithful to the information principle.
>
>
>
>
>
> > Now from table Car I will construct the following four tables:
>
> > Table1 Table2 Table3
> > ... ... ...
> > 23 vin1 23 Buick 23 sedan
> > 24 vin1 24 Buick 24 sedan
> > 25 vin1 25 Buick 25 sedan
> > 26 vin1 26 Buick 26 sedan
> > 27 vin2 27 Honda 27 sedan
> > 28 vin3 28 Ford 28 sedan
> > ... ... ...
>
> > Table4
> > ...
> > 23 silver 1.1.2000. 12.31.2000.
> > 24 blue 1.1.2001 8.1.2001
> > 25 red 8.2.2001 1.1.2005.
> > 26 silver 1.2.2005 999999
> > 27 silver 3.15.2006 999999
> > 28 black 1.1.2005 999999
> > ...
>
> > Basically, here I made four "column-based" or "attribute-based"
> > relations
> > from the relation in step one.
> > (the first three tables in fact have one column and key)
> > Table4 as addition has knowledge about attribute color which is
> > represented
> > with two columns (datefrom and dateto). One can add some other
> > "knowledge-column" related to Color
>
> > Table1 Table2 Table3
> > 23 vin1 23 Buick 23 sedan
> > 24 vin1 27 Honda 27 sedan
> > 25 vin1 28 Ford 28 sedan
> > 26 vin1
> > 27 vin2
> > 28 vin3
>
> > Table4
> > 23 silver 1.1.2000. 12.31.2000.
> > 24 blue 1.1.2001 8.1.2001
> > 25 red 8.2.2001 1.1.2005.
> > 26 silver 1.2.2005 999999
> > 27 silver 3.15.2006 999999
> > 28 black 1.1.2005 999999
>
> It seems that you are attempting to normalize the relation, but the
> result is not exactly the same as that of the standard normalization
> procedure. Can you explain why you depart from the standard procedure
> and why your procedure gives a better result? Do you think it is
> simpeler than the normal procedure?
>
> -- Jan Hidders
>
>
>
>
>
> > Vladimir Odrljin- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

Vladimir Odrljin Received on Thu Jun 21 2007 - 21:17:17 CEST

Original text of this message