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

"Cimode" <cimode_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.
>> 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? 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}? What would be the point? Why not just use IDENTITY fields.

> 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 - 16:56:34 CET