Re: Smart Database Tricks

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.
> Yes, I did read your web page, and, no, it is not precise enough. 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.
>
> 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. If this is a relation then
> all columns are attributes and since you have represented all the
> 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.

No, I am not doing normalization, rather it is a construction. Example1 is presented in the three steps because of better understanding what I am doing. In real situation I have only step2 or step 3 i.e. I immediately construct table1, table2, table3, table4 and a data entry screen(s). This is based on the corresponding entity (conceptual level). This entity should have 1) simple key 2) the mutually independent attributes 3) the attributes only from one entity.

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

There are some advantages in my approach. I will mention one. It has representation on attribute level or on information/data level. I beleive that this aproach is more natural and better for DBs and RM then for example XML approach.

>
> -- 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 Sun Jun 24 2007 - 21:01:45 CEST