Re: Principle of Orthogonal Design

"David Cressey" <cressey73_at_verizon.net> wrote in message news:3arlj.6283$YH6.85_at_trndny03...
>
> "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).
>

Yes, the generalization/specialization pattern applies for phone numbers, but it isn't the only pattern that can apply for sets of individuals. An individual can exemplify many different properties. For example, a particular part may have a shelf life. That same part may be located in a warehouse or it may have been shipped (but not both). How is that represented in a database? By tuples in relations, right? So if there is a serialized part that has a shelf life, then there is a tuple in R4 above, and if that part is in a warehouse, then there is also a tuple in R2 above. Now if at a later point in time that part had already been shipped to a customer, then there wouldn't be a tuple in R2. So, that an individual can be referenced in only one of R1, R3 and R4 is an example of the generalization/specialization pattern, but that that individual can also be referenced in R2 is not an example of generalization/specialization. A serialized part can have a location, yet that it has a location doesn't necessarily define that part. Only when a serialized part does not have a lot number does its location define it. So it is not about identifying a generalization/specialization pattern, but rather about identifying whether or not the same individuals exemplify different properties. Received on Wed Jan 23 2008 - 01:07:20 CET