Re: Principle of Orthogonal Design

"DM Unseen" <dm.unseen_at_gmail.com> wrote in message news:d2df9bb2-1050-495f-82bc-cf7c3704fde4_at_d21g2000prf.googlegroups.com... On 13 jan, 14:54, "Brian Selzer" <br..._at_selzer-software.com> wrote: [snip]

>>
>> I think that the requirement that we inspect table names comes from the
>> correlation between RM and predicate logic. In predicate logic, there are
>> predicate symbols and there are individual symbols, and under an
>> interpretation, both the predicate symbols and the individual symbols are
>> assigned meaning. The two relations,
>>
>> sine {x, y}
>>
>> and
>>
>> cosine {x, y}.
>>
>> have the same heading, but have totally different meanings--even though
>> the
>> same individuals are exemplified in both whenever (x - pi / 4) modulus pi
>> is
>> zero. The tuple, {pi / 4, sqrt(2) / 2}, appears in both relations yet has
>> a
>> different meaning assigned to it from each predicate. Interestingly,
>> though, there is still only one individual represented by that tuple even
>> though it appears in both relations.
>>
>>
>>

[snip]

>Mmm,
>
>I'm not sure using functions is going to help us to understand POOD,
>beacause it is linked to the semantical meaning of types, not the
>syntactical meaning. This is absent in mathematical functions.
>
>DM Unseen
>using relations to simulatie functions

The functions were simple examples that everyone here should have been able to recognize, but the properties exhibited by these mathematical functions can also be exhibited by relations that are not also mathematical functions. For example, suppose that you have a relation for which machines an employee knows how to run, and an relation for which machines each employee is actually running:

MachinesEmployeesAreTrainedOn {Employee, Machine}

and

MachinesEmployeesAreRunning {Employee, Machine}

where in each case Employee draws its values from the domain Employees, Machine draws its values from the domain Machines, and the key is the entire heading.

An employee can be trained on zero to many machines, and an employee can be running zero to many machines. An employee can be trained on a machine that they are not running--there can be a tuple in MachinesEmployeesAreTrainedOn without a tuple in MachinesEmployeesAreRunning, an employee may be being trained on a machine--there can be a tuple in MachinesEmployeesAreRunning without one in MachinesEmployeesAreTrainedOn, or an employee may be running a machine that they're trained on--there can be a tuple in MachinesEmployeesAreRunning that is identical to a tuple in MachinesEmployeesAreTrainedOn.

As in the function example, the above relations have the same heading, but different meanings. So if the relation name corresponds to the predicate symbol and the values from the domains correspond to individual symbols, then under an interpretation, only part of the meaning can come from individual assignments: the balance must be from the assignment of meaning to the predicate symbol. This calls into question the idea that it should be possible to determine which relation an inserted tuple is destined for. Received on Thu Jan 17 2008 - 15:14:39 CET