Smart Database Tricks

From: vldm10 <vldm10_at_yahoo.com>
Date: Mon, 18 Jun 2007 11:59:28 -0700
Message-ID: <1182193168.613162.100340_at_w5g2000hsg.googlegroups.com>


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 Received on Mon Jun 18 2007 - 20:59:28 CEST

Original text of this message