Re: Principle of Orthogonal Design

On Feb 5, 4:55 am, thesabote..._at_gmail.com wrote:
> On Feb 3, 1:02 pm, Jan Hidders <hidd..._at_gmail.com> wrote:
>
> > On 2 feb, 13:50, mAsterdam <mAster..._at_vrijdag.org> wrote:
> > [huge snips]
> > > I think 'named perspective' was just an unfamiliar
> > > label to a familiar concept.
>
> > Yes. The named perspective is the usual perspective where tuples are
> > defined as functions from attribute names to domain values, and the
> > unnamed perspective is where they are defined as sequences. The latter
> > is sometimes preferred in theoretical work because it is closer to how
> > logicians formalize things (in P(x,y,z) there are no attribute names,
> > just the 1st, 2nd and 3rd place in the predicate) and it simplifies
> > notation sometimes.
>
> I would echo that this is an important distinction to be aware of. I
> personally favour the named perspective for a couple of reasons:
> first, when Codd introduced attribute names there was an implicit
> shift from a traditional ordered mathematical tuple, to a "tuple"
> being viewed as an (unordered) partial function. Second, without the
> attribute name a datum is in fact no datum at all, but rather simply
> noise. Attributes are as much a component of the data under
> consideration as the value they are mapped to. Hence, to disregard (or
> rather externalize) attributes from a mathematical model of data seems
> rather imprudent.

It is a tricky issue. The approach usually used in predicate logic is to leave attributes unnamed and bind them to names with specific constructs within the context of a single sentence. If we bind the attributes directly to names, we get some convenience in the common case, but we also raise some issues.

A common case in SQL is that we want to join two tables via an attribute that is the primary key of one table and a foreign key in another table, and they have the same name. Often the join is written out longhand anyway:

  SELECT ... from R, S WHERE R.RId = S.Rid

The WHERE clause here is annoyingly boilerplate. Natural join, and named attributes, seem the obvious antidote to this boilerplate.

However, suppose we have a binary predicate P over domain X and we want to assert it is reflexive? In predicate logic we can use the same name twice and express this very conveniently:

  Ax in X: P(x,x)

How would we do this if P's attributes were already bound to the names "x" and "y"? Renaming? Joining with the equality predicate? It seems messy, but perhaps I am overthinking it.

If we have a trinary predicate P, how do we express that it is commutative? Associative?

Any thoughts welcome.

Marshall Received on Tue Feb 05 2008 - 22:06:47 CET