Re: Principle of Orthogonal Design

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:h_mlj.1632$so6.1229_at_newssvr19.news.prodigy.net...
>
> "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.
>

I intended generalization/specialization in the data modeling sense. I think the OO sense is just about the same thing, but I'm not sure.

I don't understand your example about serialized parts.

But "home phone number // work phone number" sure looks like gen-spec to me.
"phone number" is data that can be applied to a "telephone" generically. a "home phone" is a specialized phone. (Actually, it isn't the telephone, but the telephone line or more specifically the associated service contract, that is peculiar to either home or work). Received on Tue Jan 22 2008 - 20:07:43 CET