Smart Database Tricks
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
CarKey CarID Maker Type Color Datefrom
Dateto
...
Here the CarKey is the Identifier of the state of the entity Car and
this is the
Let we have the following Car table
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
...
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
here we also represent knowledge about attribute Color )
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