Re: A research effort on a computing model...

On 8 fév, 20:39, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "Cimode" <cim..._at_hotmail.com> wrote in message
>
> news:bd675683-86ad-40a5-9985-a810cef1d2bc_at_y5g2000hsf.googlegroups.com...
>
>
>
> > On Feb 8, 3:56 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> >> "Cimode" <cim..._at_hotmail.com> wrote in message
>
> >>news:aea0bb14-be40-4f56-aada-7edbd4501fd7_at_e23g2000prf.googlegroups.com...
>
> >> > [Snipped]
>
> >> >> Keys are also a logical concept. Keys imply join dependencies
> >> >> (including
> >> >> functional dependencies), and due to the Principle of Full
> >> >> Normalization,
> >> >> join dependencies can imply keys.
>
> >> > Actually Keys are initially a physical concept in IBM mainframes that
> >> > Codd reused to clarify the relational model. I do not believe it to
> >> > be such a determining factor. On the other hand, domains are a much
> >> > more powerful concept to describe functionnal dependencies.
>
> >> What does it matter that the physical concept in IBM mainframes uses the
> >> same term? I don't think Codd's use was merely for clarification. Keys
> >> and
> >> foreign keys are fundamental. I suggest you read Ronald Fagin's paper on
> >> DKNF.
> > Done thanks.
>
> > I have not stated that keys were useless but simply that the concepts
> > they underline can be expressed differently. Their importance in RM
> > seems overrated.
>
> >> >> Also, you're assumption that foreign keys should be implicit is
> >> >> misguided.
> >> >> Consider:
>
> >> >> MachinesEmployeesAreTrainedOn {Employee, Machine}
> >> >> KEY{Employee, Machine};
>
> >> >> MachinesEmployeesAreRunning {Employee, Machine}
> >> >> KEY{Employee, Machine}.
>
> >> > I do not see any real contradiction, except on the imperative use of
> >> > KEY terminology to clarify JOIN dependency, using your example...
>
> >> > Assuming a M:N cardinality between Machines and Employee, associative
> >> > relations such as MachinesEmployeesAreTrainedOn and
> >> > MachinesEmployeesAreRunning are simply sub types of Machine_Employee
> >> > domain defined according to relation/type Employee and Machine. In
> >> > other words, MachinesEmployeesAreTrainedOn and
> >> > MachinesEmployeesAreRunning relations are subsets of Machine_Employee
> >> > cartesian product.
>
> >> >> Without any foreign key, the two are unrelated: an employee can be
> >> >> running a
> >> >> machine that he /is not/ trained on, an employee can be running a
> >> >> machine
> >> >> that he /is/ trained on, or an employee can be trained on a machine
> >> >> that
> >> >> he
> >> >> is not running. (Or neither, assuming, of course, that there is an
> >> >> Employees relation.)
> >> > I do see your point. Fair enough. Suppose the following relations
>
> >> > EMPLOYEE
> >> > MACHINES
> >> > EMPLOYEE_MACHINE (representing the associative relation between
> >> > EMPLOYEE and MACHINES)
>
> >> > Nothing prevents from declaring MachinesEmployeesAreTrainedOn and
> >> > MachinesEmployeesAreRunning as independet subsets of EMPLOYEE_MACHINE
> >> > or as subset of one another. In the case they would not be
> >> > independent functional dependency can simply be expressed by adding
> >> > additional constraints on both MachinesEmployeesAreTrainedOn and
> >> > MachinesEmployeesAreRunning relation definition. At definition time
> >> > we can simply write:
>
> >> How far do you want to go?
> > Quite frankly: as far as possible from current implementations. I
> > have nevertheless answered your question based on an example. As I
> > have mentionned in the header, some choices I made are not
> > conventional among which the fact that I do not place so much emphasis
> > on the concept of key.
>
> >> Any juxtaposition of two attribute values could
> >> refer to an individual in the Universe of Discourse. Consider the case
> >> of a
> >> relation that is in 3NF but not in BCNF due to overlapping keys. If A,
> >> B,
> >> and C are prime attributes in a relation,
> >> {A, B, C, D} with keys {A, B}, {B, C} and {A, C},
> >> would you have a separate relation for A*B, a separate relation for B*C,
> >> and
> >> a separate relation for A*C so that the result would be {AB, BC, AC, D}?
> > The above reason and questions only applies when keys are central to
> > the problem. When this is not the case, BCNF somehow becomes moot
> > concept. The overlapping example is a specific problem I have not yet
> > adressed but it is in my top list for next year (as well as temporal
> > data).
>
> >> What would be the point? Why not just use IDENTITY fields.
> > Why use them if we can simply use custom made typing and superkeys.
>
> I brought that up because it appears that you're going to require that every
> key be unary. Whether you call it a unique identifier or whatever, there
> are problems associated with forcing all keys to be unary, and I think that
> before there can be general acceptance of your ideas, you will have to
> address those issues thoroughly.
Noted. I just have not mentionned that I was forcing use of un-ary keys...The example provided of associative entity certainly is not an un-ary key.

> On the one hand, unique identifiers bear a
> striking resemblance to object identifiers, and on the other hand, there are
> issues, particulary due to redundancy, with nested relations. How to you
> propose to get around those?
What are these issues. Providing an example I can attempt bringing an anwser to may help. As I mentionned, dupplicates are systematically rejected. They are inherently impossible. as a part of the logical model for the system. Received on Fri Feb 08 2008 - 21:19:04 CET