Re: A research effort on a computing model...
Date: Fri, 8 Feb 2008 03:54:31 -0800 (PST)
Message-ID: <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.
> 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)
[Snipped]
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.
> 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