Re: Smart Database Tricks

On Jun 18, 2:59 pm, 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. They define my vision of Conceptual Model.
> Maybe we don't understand each other, because of that here are some my
> notice.
> In my opinion sometimes *construction* is more important then a
> definition or a theorem.
> Maybe you didn't pay attention on all details in my model.
> Many things in my model are related to your question.
> I will mention for example that I defined "constructor" and I think
> that on this way
> should be created every information which is at attribute level. The
> idea is to create
> let me say lawful information, not some random information. Same for
> the identifier of an entity.
> Of course I don't think that we should solve simple DB cases on
> complicated way. This is model mostly for complex DBs. My example1 can
> be useful for further discussion.
>
>
>
>
>
> >This is
> > important if you want to claim that you are presenting a conceptual
> > model because that should satisfy the so-called Conceptualization
> > Principle which states that conceptual model deals only and
> > exclusively with aspects of the Universe of Discourse. This excludes
> > for example implementation concepts. In other words, you should not
> > introduced artificial identifiers that do not have some kind of well-
> > defined meaning in the Universe of Discourse. So it is this definition
> > that I was asking you about.
>
> > Of course, perhaps I misunderstand and you are not trying to present a
> > conceptual model. But even then adding such artificial implementation
> > concepts is usually a bad idea unless they cannot be avoided or there
> > are direct and clear benifits. So I first want to establish whether
> > your concepts are outside the Universe of Discourse or not. So, are
> > they?
>
> > -- Jan Hidders- Hide quoted text -
>
> > - Show quoted text -
>
> 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 )
>
> 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
>
> Vladimir Odrljin- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

This is additional explanation for Example1 (by mistake, I didn't copy my last version of example1)
So there are three steps in the example. First step is the starting table (with columns CarKey, CarID, Maker, Type, Color, Datefrom, Dateto)
Second step is decomposition from starting relation to the four binary relations.
Third step is a try to cat "vertical redundancy" in Table2 and Table3. This third step is posted more as a problem. For example - is it possible to move from step3 to step2 using relational algebra technique?
I can do this using procedural approach and table1

Vladimir Odrljin Received on Mon Jun 18 2007 - 21:58:17 CEST