Re: Principle of Orthogonal Design

"DM Unseen" <dm.unseen_at_gmail.com> wrote in message news: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]

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

This model doesn't capture what mine does.

In mine, one relation is for what employees are trained to do, and one relation is for what employees are currently doing. You're trying to stuff that information into one relation (and failing) so that in order to find out if an employee is trained, on a machine, you would need to check to see if the employee is trained but not running the machine, or trained and running the machine. That's a lot less intuitive than simply doing a select on MachinesEmployeesAreTrainedOn. To see if the employee that is running a machine is also trained on it is also very simple: just select from MachinesEmployeeAreTrainedOn JOIN MachinesEmployeesAreRunning.

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

This model captures the same information, but in my opinion is more complicated. To see if the employee that is running a machine is also trained on it requires a much more complicated self-join.

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

What it brings to my mind are those old legacy RPG systems with multiple record formats.

>From a data-model stability and usability standpoint, these
>alternatives fare better than the original.

I would argue the opposite. Adding an attribute--say, DateTrained--to MachinesEmployeesAreTrainedOn is a simple matter and shouldn't break any existing code. How could that be done with MachinesEmployeesRole? What about the tuples for the machines employees are running? They don't have a DateTrained attribute--or shouldn't, so what do you do? Use NULLs?

Stuffing multiple types of information in the same relation is always a bad option--even if they have exactly the same set of attributes because they may not always have exactly the same set of attributes.

>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 think I've shown that it is definitely NOT easier to maintain, nor is it more stable.

>I supect for real world usage POOD will force you to design better
>data models.
>
>Dm Unseen
Received on Fri Jan 18 2008 - 17:16:41 CET