Re: Two relations with the same attributes (was: 3 value logic. Why is SQL so special?)

mAsterdam wrote:
> Cimode wrote:
> > If 2 relations have the same attributes then they should be one
> > relation.
>
> No. As long as the name of the relation and the meaning of the
> propositions differ it is ok to have two relations with the same
> attributes. The meaning of the propositions depends on the external
> predicate.

I see your point...
Thank your for pointing that out but such definition is valid only for SQL systems. I should have stated that the proposed definition assumes an implementation that supports domain derivability (in a word, forget SQL) Keep in mind that the answer was specific to the example of FLIGHT with actual departure time and arrival time. In this specifc example, having 2 relations with these 2 attributes is a mistake EVEN IF they do NOT share the same external predicates. For instance, consider 2 type of FLIGHTS, some SCHEDULED and some UNPLANNED. In order to deal with NULLS properly, you may think of the 2 following entities FLIGHT_SCHEDULED: departure_time, arrival_time, flight_IATA_number and FLIGHT_UNPLANNED: departure_time, arrival_time, reason (code possible reason explaining why the FLIGHT had to leave while not scheduled). You may also argue that both respond to different external predicates. Nevertheless, a better design should be

FLIGHT: departure_time, arrival_time
FLIGHT_SCHEDULED: flight_IATA_number
FLIGHT_UNPLANNED: reason

Both FLIGHT_SCHEDULED and FLIGHT_UNPLANNED being derived from FLIGHT type (and therefore sharing all its attributes) with specific attributes of their own.

Some systems already support domain derivability(Caché from Intersystems). It's just a shame, SQL beats the crap out of them on pretty much everything else...

Regards... Received on Sun Sep 17 2006 - 19:52:53 CEST