Re: Principle of Orthogonal Design

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:

either:

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