Re: On view updating

Mikito Harakiri wrote:
> Perhaps, by "Employee 123 is called (John or Bill) Smith" you have meant
> something other than aliasing, so I misinterpreted your idea. It follows
> then, that the idea of complex predicates is too prone for
> misinterpretations, and should be abandoned altogether [at least in the
> trivial world of business data].

Yes, what I mean is that the external truth is that employee 123 is definitely either called John, or is called Bill. It's just we don't know which at the moment.

In other words, of the following two statements, one and only one is true:

"Employee 123 is called John"
"Employee 123 is called Bill"

But the fact that we don't know exactly which one doesn't make this a useless piece of information.

For example someone could ask:

Tell me all the employees with 4-letter names. List me all the employees who are called either John or Bill.

Even though we don't know their name for certain, we still know enough to be able to answer these questions.

We could also conceive of more complicated statements:

"Employee 123 is either called John or Bill Smith, or else he was called Dave Jones. If he was called John, he definitely worked in department 20".

The idea of complex predicates is only open to misinterpretation because I'm writing them in natural language to get a feel for what they mean. They could easier be written using boolean constructs to be unambiguous.

Having said that though, I agree that it might be too complex for business data. But the point is (as made by Costin) that then we can't claim that the relational model is a full implementation of first-order logic. We are deliberately constraining it to be not so, so that things are easier (on both the user and the DBMS designer).

What I'm exploring as well is whether constraints can be used in any way to store this kind of information.

Paul. Received on Tue Sep 28 2004 - 09:14:32 CEST