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

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.

> > EMPLOYEE: fname(string), lname(string)
> > MACHINES: model(string), number(string)
> > EMPLOYEE_MACHINE: employee(employee), machine(machine)
> > MachinesEmployeesAreTrainedOn: employee_machine(employee_machine WITH
> > first set of constraints) and assuming Employee can run only machines
> > they have been trained on, simply define
> > MachinesEmployeesAreRunning:employee_machine(MachinesEmployeesAreTrainedOn)
> > and in this case MachinesEmployeesAreRunning is necessarily a subset
> > of MachinesEmployeesAreTrainedOn. Functional dependencies is
> > preserved without having to use the KEY concept.
>
> > [Snipped]
> >> With the foreign key, on the other hand, each tuple in
> >> MachinesEmployeesAreRunning represents an instance where an employee is
> >> running a machine that he is trained on.
> > See above.
>
> > I believe mentionned that the unique identifier (equivalent of primary
> > key) necessarily constitutes a superkey and that I express the foreign
> > key concept implicitely through subtyping.
Received on Fri Feb 08 2008 - 17:14:36 CET