Re: Principle of Orthogonal Design

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:nM9lj.2189$Rg1.958_at_nlpi068.nbdc.sbc.com...
>
> "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#})
>

Sorry about that, I hit send before I had completed my thought.

It's not exactly specialization/generalization--at least not in the OO sense--because a serialized part is still a serialized part regardless of whether it is located in the warehouse or not.

The constraints ensure that a serialized part can be referenced in only one of R1, R3 and R4 and also in only one of R1 and R2.

There is still redundancy, since the FD {Part#, Serial#} --> Cost holds in R2, R3 and R4 and since a serialized part can be referenced in both R2 and one of R3 and R4.

>>
>>> > 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 - 15:22:04 CET