# Re: Principle of Orthogonal Design

Date: Fri, 18 Jan 2008 01:23:20 -0800 (PST)

Message-ID: <f9a315b5-84a3-4ec5-930c-fa604b067d93_at_i72g2000hsd.googlegroups.com>

On 17 jan, 15:14, "Brian Selzer" <br..._at_selzer-software.com> wrote:

*> "DM Unseen" <dm.uns..._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.- 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}

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'

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