Re: Basic question?What 's the key if there 's no FD(Functional Dependencies)?

From: vldm10 <vldm10_at_yahoo.com>
Date: 5 Nov 2006 07:01:19 -0800
Message-ID: <1162738879.388515.119010_at_f16g2000cwb.googlegroups.com>


paul c wrote:
> vldm10 wrote:
> > paul c wrote:
> >> David Cressey wrote:
> >>> "paul c" <toledobythesea_at_dbms.yuc> wrote in message
> >>> news:a2c2h.242940$R63.209531_at_pd7urf1no...
> >>>> vldm10 wrote:
> >>>>> saturnlee_at_yahoo.com wrote:
> >>>>>> What 's the key for it? ABC or nothing???
> >>>>> ABC is not the key.
> >>>>> Example: Let one partricular entity has A,B,C atributes
> >>>>> and let these atributes take the following values:
> >>>>>
> >>>>> A B C
> >>>>> -----------------------------
> >>>>> 2 4 6
> >>>>> 8 4 6
> >>>>> 2 4 6
> >>>>>
> >>>>> ( ABC can be the key only in the trivial cases i.e if an entity has
> >>>>> the atributes whose values never change)
> >> ...
> >>>> 2) I don't know why entities need to be mentioned, either, nor what a
> >>>> non-"trivial" entity might possibly be.
> >>>>
> >>>> p
> >>> I think he was referring to "trivial functional dependencies". A key
> >>> determines any subset of itself, trivially. In current parlance, "well,
> >>> duh!"
> >> I still don't get what entities have to do with FD's. I thought Codd
> >> came up with functional dependencies for relations, not entities and
> >> that it is dangerous to mix those terms up, whatever we might think an
> >> entity is, once we've made a relation to deal with it, we should suspend
> >> the term as it can lead to all kinds of subjective confusions and just
> >> talk about tuples or predicates (when people start talking about the
> >> "real world", for me it's usually a clue that they are about to lapse
> >> into mysticism!).
> >>
> >> p
> >
> >
> > Let me clarify this more.
> > We have the real world and the RM.
> > Simply speaking we have the following schema:
> >
> > Entities,attributes,.. ---------> Relations, columns,... (*)
> >
> > If you thing that (*) is a simple thing and somehow automatic,
> > I don't. It is very complex correspondence.
> > ...

>

> No, I don't either. Only a mystic could.
>
>

> > 1)
> > Now if we put on left side of (*) ...
>
>

> Stop right there. You haven't defined whatever kind of 'schema' or
> correspondence you are intending with the nine hyphens and the right
> arrow, so I don't see how you can start putting entities on one side of
> it. Just because you feel like it?

I wrote "simply speaking" in front of (*). If you insist then you can find about mapping between the real world and the RM on my website. In the chapter 4 I define it.

>
>

> the entity from my example with
> > its three states and try to apply given relation R(A,B,C) it doesn't
> > work.
>
>

> This is mixing up terms, equating states of entities with values of
> relations.

This is not mixing up terms (in the example there are only the entities with their states and its attributes, I wrote that (*) is a correspondence).
It is important that designer must think first about the real world.

There are the two cases regarding the real word entities: (i) trivial - an entity has the attributes whose values never change (ii) general - an entity has the attributes whose values can be changed

ABC key doesn't work in general case, only in trivial. In general case
we can use one of the "temporary DB theories". There is the problem - which one.
These theories don't work for online databases. They are also bad for some advanced database concepts, for example for the knowledge representation. These solutions are often bulky with very complex keys - as in case 4) from these message. I also don't think that time is only possible measure for the events.

>
>

> > Here we assume that ABC is the "natural" key.
> >
> > 2)
> > If you try to apply just the last two states from my example into given
> > relation R(A,B,C), that is case when values are not repeated,
> > you will get something like:
> >
> > R: A B C
> > ------------
> > 8 4 6
> > 2 4 6
> > If you have millions of the rows in this relation, I don't know how
> > you
> > will determine what keys determine same entity (with different states).
>

> I believe you are talking about bags, which RT says nothing about as far
> as I know.

Here we have relation, so there are no bags. The tuples are different in
this example. We have here one car which first attribute A is changed from value 8 to value 2 (this is an example without repeating same attribute's value)
The question here is how do you know that above two tuples are not about one car? How end user can use this relation if it
has millions of rows?
Maybe this example shows why mostly of the relations have "artificial" key
either as "surrogate" or as part of composite key. I believe that 99% of
the applications use "artificial" key.

>
>

> >
> > 3)
> > I wrote about this earlier:
> > Honda store received group of new Honda Civic, all of them with same
> > attributes
> > and we concluded that in this case "natural" key doesn't work.
> >
>

> Never had a Civic but all my Honda two-wheelers had unique serial
> numbers. None of them had all the same attributes but if they had, I
> would have made up my own serial numbers. I believe Codd called this
> the information principle. Without it, some applications are
> impossible, such as the one you are making up. I believe this is called
> a straw man.

If we understand that not only Honda civic has "surrogate" key, but

almost every product has this key, then it seems the matter is not unimportant.
 In this example we can see that we are capable to distinguish entities even with the same attributes. We can express this by "surrogate" key but not by the attributes. We can abstract, generalized, give a name, be aware about the objects, etc. This matter is also fundamental. However there is almost nothing in the relation theory about "surrogate" key.
For the beginning, here is the following problem: How to prove that "surrogate" key is the attribute? Otherwise it is not the key

by definition.
I am using my attribute definition.

>
>
> p

Vladimir Odrljin Received on Sun Nov 05 2006 - 16:01:19 CET

Original text of this message