Re: Principle of Orthogonal Design

From: DM Unseen <>
Date: Fri, 18 Jan 2008 01:23:20 -0800 (PST)
Message-ID: <>

On 17 jan, 15:14, "Brian Selzer" <> wrote:
> "DM Unseen" <> wrote in message
> On 13 jan, 14:54, "Brian Selzer" <> 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.- Tekst uit oorspronkelijk bericht niet weergeven -
> - Tekst uit oorspronkelijk bericht weergeven -

Using POOD I would change the model to:


MachinesEmployeesSkilledOperation {Employee, Machine,Status}PK{Employee, Machine}
where Status in {Trained,Unskilled Operation,Skilled Operation}


MachinesEmployeesRole {Employee, Machine,Role} PK{Employee, Machine,Role}
where Role in {Trained, Running}

the example second is sometimes called an 'object to role transformation'

From a data-model stability and usability standpoint, these alternatives fare better than the original. The first alternative answers the question of who is a skilled operator in one simple query, the original model does not. It is a more compact version of the eriginal data model. The second alternative is easier to maintain and is a more stable data model than the original due to the 'object to role transformation', but is not more compact than original model.

I supect for real world usage POOD will force you to design better data models.

Dm Unseen Received on Fri Jan 18 2008 - 10:23:20 CET

Original text of this message