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

[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.

> 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:

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 - 12:54:31 CET