Re: Principle of Orthogonal Design

From: mAsterdam <>
Date: Fri, 18 Jan 2008 15:20:36 +0100
Message-ID: <4790b477$0$85795$>

DM Unseen wrote:
> Brian Selzer wrote:


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

> Using POOD I would change the model to:
> either:
> MachinesEmployeesSkilledOperation {Employee,
> Machine,Status}PK{Employee, Machine}
> where Status in {Trained,Unskilled Operation,Skilled Operation}

Adding unrequired information as you go. An extra rule how to interpret is needed. How is this an improvement?

> or

> MachinesEmployeesRole {Employee, Machine,Role} PK{Employee,
> Machine,Role}
> where Role in {Trained, Running}
> the example second is sometimes called an 'object to role
> transformation'

One table gone, one table representing more complicated facts. What is won?

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

select Employee, Machine from MachinesEmployeesAreTrainedOn;

> It is a
> more compact version of the eriginal data model.

Less tables is somehow better?

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

Better in what aspects?

What you see depends on where you stand.
Received on Fri Jan 18 2008 - 15:20:36 CET

Original text of this message