Re: Dawn doesn't like 1NF

Marshall Spight wrote:
> Let us propose that the relational engine is the servant of the type
> system.

the other way round, surely?
or you mean the type engine can run a second instance of the relational engine for itself, separate from the main one?

> In that case, when the system sees a relation in the place of an
> attribute, why shouldn't it be able to use the relational operators
> on that attribute?

by "system", you mean the relational engine? Or the system as a whole (relation engine + type engine)?

The relational engine should never see that an attribute is a relation, even if it is - to the relational engine, it's just a black box with a note saying "this attribute is of type id=123456". It's only the type engine that understands the internal details of what type the attribute is.

Relational operators can be used on that attribute, but they are relational operators defined within the type engine's internal DBMS, not within the main relational engine.

>> The problem arises when people think you should be able to access
>> the "inner" relation *directly* from the external database engine.
>> e.g. something like:
>> 
>> SELECT * FROM RELATION (SELECT foo FROM bar WHERE id = 123)
>> 
>> (I'm inventing some syntax here - 'foo' is supposed to be a 
>> relation-valued attribute, and RELATION is some kind of operator
>> that forces a value to be viewed as a relation in the DBMS - i.e.
>> it turns data into metadata)
>> 
>> This way lies madness!

Hmm Ok. Well to start with, you're not going to know what columns foo has, so in the above hypothetical query, a data update (to foo) is going to result in an apparent schema change (to the query results, e.g. if it defines a view).

Basically once you start mixing data and metadata, you're getting into second-order logic. Whilst the relational model rests on first-order logic, things are very nice and work as expected. If you start getting away from this, you're on more shaky ground. Sorry if this is a bit of a handwaving argument - maybe someone with more knowledge can give a concrete example of some problems caused by this kind of thing.

> Going back to strings again, why *shouldn't* we be able to treat
> strings as relations of (int, char) and use the relational algebra on
> them.
 >
> Making up my own syntax:
>
> -- Select the set of vowels out of every user's first name:
 >
> select PersonId, (select c from FirstName where c in ('a', 'e', 'i', 'o',
> 'u')) from Persons
>
> That rules. It's quite powerful.

I think this is slightly different to my example in a few ways: The attribute can't take any relation value, only a restricted range of them (i.e. ones with a single column of type char(1)), . The attribute always remains as data, it never makes the jump to meta-data as my example does. I'd say the inner select is part of the type system, it's really just an operator that takes an argument of a given type and returns a value of that same type. It's not interacting with the external select, which is part of the relational engine.

So I don't really have a problem with that. The data and the meta-data both know their place.

> Now someone poke holes in it. But if all you want to do is assert
> that it's bad without justification, let's save us both the time.

Sorry, I'm just trying to be assertive. You can take my provocative statements to be questions if you like. :)

Suppose I have a relation with a relation-valued attribute. What if I tried to set the attribute in a particular row to be the value of the relation itself? Something like:

   UPDATE earth SET turtle = earth

where "earth" is a relation and "turtle" is a relation-valued attribute of "earth".

I guess most of the logic paradoxes come down to infinity which isn't really applicable to relational database but there must be some of the self-referential kind. Maybe there's a way of using Russell's paradox or the Barber of Seville to illustrate problems with fully relation-valued attributes.

And once you go to second-order logic you lose completeness (in some sense). Again, maybe the finiteness avoids this in some way though.

Paul. Received on Mon Oct 18 2004 - 19:29:29 CEST