Re: Principle of Orthogonal Design

"David Cressey" <cressey73_at_verizon.net> wrote in message news:wA2lj.4389$YH6.1499_at_trndny03...
>
> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> news:kO1lj.2507$nK5.335_at_nlpi069.nbdc.sbc.com...
>
>> I think that there are times when it makes sense to 'collectivize' under
>> a
>> single predicate, and there are times when it does not. In particular,
>> if
>> the individuals represented are just different kinds of the same sort of
>> thing, such as is the case with the different kinds of phone numbers,
>> then
>> it makes sense to 'collectivize' those attributes that are common to all
> of
>> those individuals under a single predicate. If, on the other hand, the
>> individuals represented are different sorts of things that just happen to
>> have the same attributes, then it doesn't. A disjunctive
>> predicate--something like, for example, each tuple exemplifies an
> individual
>> that is an X or a Y, just doesn't make any sense to me. A conjunctive
>> predicate on the other hand--for a relation that has multiple keys, for
>> example--is not a problem since each tuple would exemplify an individual
>> that is /both/ an X /and/ a Y. So if the predicate can be stated so that
> it
>> is not disjunctive, then 'collectivizing' is to be preferred.
>>
> It seems to me that you are describing the generalization-specialization
> pattern.
> Am I reading you right?
>

Not exactly. For example, some serialized parts have a lot number; some serialized parts have a lot number and an expiration date; some serialized parts have a location in the warehouse (those that haven't already been shipped); but all serialized parts have a cost. So there could be the relations,

R1 {Part#, Serial#, Cost}
R2 {Part#, Serial#, Warehouse, Bin, Cost},
R3 {Part#, Serial#, Lot#, Cost}, and
R4 {Part#, Serial#, Lot#, ExpirationDate, Cost},

where {Part#, Serial#} is the key for each and

IS_EMPTY( R1 JOIN R2 {Part#, Serial#}) AND
IS_EMPTY(R1 JOIN R3 {Part#, Serial#}) AND
IS_EMPTY(R1 JOIN R4 {Part#, Serial#}} AND
IS_EMPTY( R3 JOIN R4 {Part#, Serial#})

>
>> > Either way, I certainly find that appealing to notions of "meaning"
>> > within formal design recommendations seems to head towards very
>> > slippery ground.
>> >
>
> Why? If you called it "the semantics of the data" instead, would that
> make
> it less slippery ground?
>
>
>
>
>
Received on Tue Jan 22 2008 - 00:19:44 CET