Re: 3 value logic. Why is SQL so special?

From: Alexandr Savinov <spam_at_conceptoriented.com>
Date: Wed, 13 Sep 2006 10:46:56 +0200
Message-ID: <ee8gi2$tl4$1@f1node01.rhrz.uni-bonn.de>

David Portas schrieb:
> Paul wrote:

>> Now, if the field "Actual_Departure_Time" is not null, then it has to
>> be something - yes?

>
> I think you did not read or understand JOG's reply. If the entity does
> not have an Actual_Departure_Time attribute then it should be
> represented by a table that does not have an Actual_Departure_Time
> attribute. Your alternative is unsound in several ways.

That is a naive position because moving an attribute in another table does not mean that this attribute does not describe the entities from the original table. In other words:

*an attribute does not need to be in a table in order to describe entities from this table*

So if you put Actual_Departure_Time in table A, B, C or whatever other table you find appropriate then it will still describe entities from Flights table (if linked appropriately of course). Moreover, formally these alternative schemas are equivalent (again, if we link the tables appropriately).

In this sense there are two extremes:

putting all the data in one wide table (a kind of canonical representation), and
putting all the data in separate tables (a kind of "one table - one attribute" approach)

In the first case all absent attributes will (have to) be denoted by nulls. In the second case the absent attributes are denoted by the physical absence of the records. From the point of view of users (data semantics) nothing changes.

Real world schemas are normally somewhere in between because both extreme designs are not efficient: the first due to space, the second because of time.

--
http://conceptoriented.com

Received on Wed Sep 13 2006 - 03:46:56 CDT