Re: The Practical Benefits of the Relational Model

Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message news:<3D9DBF26.30101_at_hotmail.com>...

> If I understood correctly that it runs on top of a SQL DBMS.
> In this case I'd call it a Data Access Engine, not a DBMS

Dataphor is designed to run on _any_ data source, SQL being a useful special case. As for being a Data Access Engine or a Database Management System, this is a matter of perspective. By the reasoning you are using you would also have to call Oracle, DB2, and SQL Server all Data Access Engines because they "run on top of" the host OS's file system. Nonetheless, the product is actually called the Dataphor Data Access Engine.

If you look closer, you would find that Dataphor has all elements necessary to qualify as a DBMS. The ability to utilize existing data sources, and even offload supported workload is a benefit. The natural byproduct of this design allows the system to be the ultimate data integration solutions, and we can utilize years of existing DBMS research and development.

> > Thus far this conversation has yielded very little agreement, and I
> > hope it is not because we are trying to out-argue each other. The
> > cause, I think, is that we have differing assumptions. I have taken a
> > kind of mental step back and I think I see where you are coming from.
>
> Of course I knew where you came from, but you should have known of the
> other perspectives before you made your claims.

My original assertion is that the concept of "type inheritance" is also possible within the context of the relational model. I still maintain that position. If you "knew where [I] came from," then why did you insist on bringing other logic systems (in the guise of "type systems") into the discussion when the context was clearly the relational model. The other "type systems" you keep referring to are not merely specific type models within the RM, they completely redefine the otherwise bounding system. This became clear when I realized we did not agree on what "kind" of type we were discussing.

> Why do you assume that ? The 1st order predicate logic provides the
> semantic for the RM.

You answered your question. :-)

> Relational model is based on relational algebra and relational calculus.

The algebra and calculus are merely languages for expression and construction. The RM is a logic system based on n-ary relations and 1st order predicate logic.

> Both are orthogonal to the type system as Mr. Date noted, why do you
> bring back the topic ?

Not the kind of "type system" you have been referring to. In order for a "type system" to qualify for use within the RM it must be defined within the RM's existing definition of a type--namely a set or domain of values.

> It is the semantic (interpretation, significance)
> of the RM that is within the 1st order logic, when you say that a tuple
> is to be _interpreted_ as a proposition.

...yes, with "parameters" (in the logic sense), each containing a value from a possible domain of values (type).

> I believe this confusion also led you to talk past each other with Paul
> vernon on the subject of view updates.

Paul seems to understand the RM very well and I think there is reasonable consensus on the subject.

> Then, if you are not logician, you surely can get a book on mathematical
> logic and find out that 1st order logic doesn't deal with types _at
> all_. Types were introduced especially to go past the limitations of FOL.

Types (under the name domain) _were_ introduced as part of first-order predicate logic to overcome the limitations of propositional logic.

> Or at least that's what I was tought at university, and I just check
> another book (Henderton's Mathematical Introduction to Logic) to make
> sure. I'd be surprised to find out of a logic discipline that deal with
> type systems and call itself 1st order logic.

You are looking for the wrong thing. The "type system" is just a byproduct of the logic system requiring a "domain of values." What you are calling a "type system" is, again, it's own logic system.

> > With this perspective, you can see that any other definition of type
> > does not correspond with the one by the same name in the relational
> > model.
>
> Haven't we established that the RM is orthogonal to types ? Then why are
> you referring to "the type" or the "type system" defined in the
> relational model.

I am referring to the _definition_ of type WITHIN the relational model. So long as we don't change the basic definition of type, type _is_ orthogonal to the relational model. We can build types and type generators for relations, sets, arrays, scalars, matrices, whatever--so long as each type and type generator fulfills the role of defining a set of values. Once again, any "type system" that does not define type as a set of named values would alter or extend the relational model itself, not merely provide domain possibilities.

> > To clarify an earlier statement: The specific domains of possible
> > values are orthogonal to the relational model. Alternative "type
> > systems" and other alternative logic systems are explicitly excluded.
>
> I guess here you are at odds with Date in Introduction to Database
> Systems, D&D in TTM, Abiteboul, Vianu, and Hull in Foundations of
> Databases.

I doubt that I am at odds with Date in this respect. He has repeatedly stated his feeling that there is no need to "extend" the RM, and what you suggest with alternate logic systems does exactly that.

> Can you substantiate your claim ?

In An Introduction to Database Systems (7th ed.), Date defines type: "A type is a named set of values (i.e., all possible values of the type in question), along with an associated set of operators that can be applied to values and variables of the type in question."

[re interfaces]
> It *is* a type.

Perhaps in some logic system, but not by the RM definition. Not that you couldn't introduce the concept of "interface" into a relational system, but I doubt it would be considered a type.

> > Again, now that I understand where you are
> > coming from, these arguments are irrelevant.
>
> Kind of fallacious don't you think ?

No. The arguments have been made under false assumptions and therefore are now at least partly irrelevant.

> > Certainly I can make no
> > rational argument against new logic systems that define type as
> > whatever.
>
> What logic system ? What logic system are you using that operates on types ?

The alternative "type systems" you have brought up are indeed logic systems. The RM is a logic system that operates on types.

> I'm quite certain that it's not FOL as you claim, because otherwise
> you'd have to rewrite some books on logic.

Too bad because I was hoping to get real work done. ;-)

> But regardless of your claims about logic, let me explain to you why the
> arguments about higher order logic and proper type systems are relevant:
>
> It's been already recognized that RM should be extended with user
> defined types and user defined functions.

I assure you that this "recognition" is far from universal. You are basically making a classic OO argument that can no doubt have only stemmed from ignorance of the RM. The RM doesn't need to be extended to support user defined types and functions.

> Those thingies have to be
> written (implemented, defined) in a kind of computational thing called a
> programming language. The DBMS has to manage that code, and verify it's
> correctness and safety in as much as possible.

Yep.

> Therefore all the concepts of programming languages suddenly become
> _relevant_ to DBMS.

Yep.

> If you don't want to have redundancy in data, you
> also don't want to have redundacy in code (the code to be stored, and
> managed by the DBMS and that will extend the DBMS),

Yep... code reuse is a good thing.

> youi want to have
> quality code in there.

Agreed.

> If you make difficult for the user to provide
> quality code, then UDT and UDF will become a nightmare.

Agreed.

 [snipped from other posting]
> Of course, this also implies : "adieux to FOL". It's been already understood
> for decades that 1st order logic, 1st order functions are not adequate for a
> good structuring of code.

1st order predicate logic forms the basis for tuple interpretation. Part of the relation type. What does this have to do with "good" structuring of code. Keep in mind that the relational realm merely forms the basis for the expressive subset of the outer, imperative language.

> If you are confined within 1st order functions you
> end up with a lot of redundancy in code.

1st order functions are really just integrity constraints in the RM. Code can certainly be re-used, so long as the system ensures that all used code for constraints is both functional and deterministic (something the system can manage).

> Object oriented programming,
> generic programming, functional programming all these are based on higher
> order functions and higher order types .

None of which are necessary... all of which increase complexity. ;-)

> You need to write programs that
> are not dependent on a particular type or a particuklar functions, but are
> parameterized by types and functions. Or you want to express the most
> generic types as a logical equation (any type that has a set of properties),
> for example this is how you define the type Field, and most other
> mathematical types. So that in the end you write only one program that deals
> with any Field, instead of writing different programs for Q, Z2, Z13,.. or
> any otherr particular field .

This type of code re-use is _exactly_ what Date and Darwen have spelled out how to do with their type inheritance mode. Without extending the RM I might add.

> This why I presented Nathan the challenge: how do you define the type
> "Finite Field", within D4 or TTM' tutorial D for that matter ?

Simple, define an operator that "takes" a "Finite Field" type. All things that are "Finite Fields" proper or not can be passed to that functional operator. No need for any added complexity.

> >>Let's see an example ("real world" :) ). I have a cryptographic
> >>algorithm that works over finite fields. Let's rather say informally:
> >> P(private_key)= public_key.
> >>
> >>Now I have the mathematical algoithm for P. Obviously, I don't want to
> >>write that code again and again, for different finite fields, therefore
> >>I'd say that the algorithm should be written *once* and for all for the
> >>most generic type FINITE FIELD.

Okay, at this point we have a type with the necessary operators and representations necessary for our P() to operate.

> >>Now do you accept that FINITE FIELD is a type ?

Sure.

> >>If you construct for me a set of elements, can I verify that they indeed
> >>form a finite field, in other words, can you really separate the set
> >>from the structure defined over it ?

The very construction of a "set of elements" (aka values) in the RM is done through "selectors" (or constructors) of a specific type. If we select a value that "is" a finite field, then yes we "know" that it is indeed finite.

Your next point is likely to be "okay, so how does the system 'know' what types are finite files and which aren't." The answer, as I have stated several times, is that type designer "told" it so as part of the definition of the type. Anything else would involve non trivial theorem proving. Unless you have something very significant to contribute to the industry, it can be safely asserted that there is NO system that can do this in finite time so why are you so hung up on the fact that a "D" cannot do this. Surely you cannot point me to a type system that can! Before you bring up ML, read further.

> >>By the way, how would you declare such a program in D4 ?

[simplified]

create domain FiniteField is { Alpha }
{

	representation Stream
	...

create domain Integer is { FiniteField } ...

> Your unsubstantiated opinion that is.

Have you not given your share of unsubstantiated opinions. ;-)

> > Let's be fair, the domain (pun excused) of our product is that of the
> > relational model of data which is a logic system based on 1st order
> > predicate logic. Within the RM, we have not encountered any general
> > logical or practical problems. To the contrary, we actually
> > gravitated to the RM as a _solution_ to many practical problems before
> > encountered. We are particularly happy with the simple but capable
> > definition of type within the RM.
>
> This sounds like a marketing brochure.

Okay, upon re-reading it does.

> It is totally unimportant. It is important that you agree on evaluation
> criteria that you use to judge the usefulness of various type systems to
> be "plugged-into" and extend the RM.

I am not interested in extending the RM until I see convincing evidence that a practical task can not be done within the model. No need to introduce complexity if it is unnecessary.

> For example in DB2 (ok, it's not relational but you can use it as a
> RDBMS) I can create UDT, UDF in Java. Not the perfect type system by
> far, but at least I can define what a Field is, and then define
> functions that operates on elements of a Field as in the example above

If you are implying that they are able to add data types because they _extend_ the model then I would refer you to our product. You can create types in our relational system. Real types as powerful as the intrinsic ones.

> In your system I'd have to do that in D4. By well established criteria
> (again referring to Cardelli's type system), I'd say that it would be
> even more cumbersome than in Java.

First of all, operators in Dataphor can be built in D4 or any .NET language (including Java the language), so your first statement is incorrect. As for your statement that D4 is more "cumbersome" than Java, this is highly subjective. D4 has the same logical imperative capabilities as Java for looping, branching, exception handling. I would further argue that D4 is much LESS cumbersome than Java as soon as operations on sets of tuples are required, due to the intrinsic relational capabilities.

> By your criteria (which I wasn't able to figure out past some marketing
> smelling claims abotu modeling the "real world", and some strange
> references to FOL that I find confusing ) it looks like it's the ideal
> to strive for, while you look down your nose to the "existing systems".

Do you have some kind of exclusive on looking down the nose? :-)

> Kind of puzzling.

What do you suggest? We can't say much of anything good about it without sounding like weasely sales people--but so what, if the product is good, it's good!

> > I am certainly not qualified to speak for them, but I think their
> > position is that there is no need for another logic system. The RM
> > has everything that is sufficient and necessary, so why come up with
> > another "model."
>
> No, it doesn't have everything that is sufficient and necessary, unless
> you restrict yourself to a ceratin class of practical problems.

That certain class is database management, which is exactly the one we are interested in. I have seen no convincing argument showing the need for any other model than the relational model for database management. Furthermore, I can't imagine (nor have I seen) a simpler model, so IMO that puts the RM in a sort of "sweet spot."

> For more specific problems you can have deductive databases, OODBs and
> other varieties. RM doesn't cover that, at least about constraint
> databases you can be sure.

I disagree, the same problems those "databases" are designed to handle _can_ be handled within the RM.

> How can a user express the knowledge "Either A or B" ? He can't in your
> model as pointed out by Paul Vernon. This proves that RM doesn't have
> "everything that is sufficient and necessary".

Judging from Paul's sarcasm, he does not seem to feel he made such a statement. Are you stating that the RM cannot represent a logical OR!

> So let's set the
> marketing claims aside, and let's acknowledge there's room for other
> varieties of databases to solve the problems for which the RM is not
> well suited. This leaves RDBMS with the lion's share of the market anyways.

I certainly believe that different _implementations_ are applicable in varying situations, but I resist the notion that the _logical model_ for those systems must differ. Surely any new "models" needed can be inferred from the simplest complete one.

> > I think (hope) there is consensus on what a type is
> > in the RM.
>
> We had a consensus that type systems are orthogonal to RM until you
> change your mind.

Clearly a case of varying definitions.

> > Within that definition, what Date and Darwen have done is
> > to spell out how to do type inheritance.
>
> Subtyping :) Within the definition they proposed and which have to be
> judged on its merits. It's not within the one and only definition
> possible for RM as you are claiming.

Their handling of type inheritance (I'll use their term for it :) for scalar domains (I will avoid the T word) seems to merely take the implications of set theory to their logical conclusions (not to take away from what they accomplished). Date & Darwen's type model could possibly even be viewed as a generalization of other type models also based on the set definition of type. If you disagree with the model, please suggest an alternative to take it's place. And please pick something that does not require extending the relational model.

As for the type model's overall merit, the fact that I haven't seen one good demerit is the best one I can think of. Certainly your argument that the system should enforce something that never has, and possibly never will be possible to generally solve is not a good demerit.

> >>In the meantime TTM has come up with a
> >> partial theory and no practical results. Where by result I mean a
> >>practical implementation of the system that is able to prove its
> >>usefulness.
> >
> > We have seen _many_ practical benefits from our implementation of TTM.
>
> That's an entire different claim.

How can that be "an entirely different claim" when you said that the TTM can only be judged by an implementation and I said, we have an implementation and so far so good.

> >>Ideally, as in the case of ML, the actual type systems
> >>should be _provable_ safe and sound.
> >
> > It is not provable in general that a loop will ever terminate, but we
> > don't argue the usefulness of them.
>
> But it is provable that ML's type system is safe and sound.

Only by limiting the power by restricting to certain subsets... we could do that too!

> And it is
> provable that particular loops terminate. As Dijkstra pointed out the
> highest art of programming is to write a program with its proof in mind.

Particular loops, right, but that isn't the general case. A type system must either: a) limit the available supertypes to enforce correctness or b) be general and allow any type, but leave correctness up to the type developer. I see no reason within the type inheritance model in TTM why a system couldn't enforce the correctness of subtypes of (non-alpha) system types. Perhaps something we will even do in our implementation at some point.

> >>A precise definition of type will be different in different systems,
> >>each with its own benefits.
> >
> >
> > As pointed out by the original posting the RM yields many benefits, so
> > my vote is for a type system that works within the grounds of the RM.
>
> Your "vote" is entirely another matter altogether. You started by making
> quite some bold claims.

My vote is based on the fact that I would rather do less mundane work than more. :-) To rephrase: when considering logic systems, the simplest complete system will result in the least work and will be easiest to comprehend. To date, no simpler complete system for data management has been proposed than the RM.

> >>But we have to agree what are the essential
> >>roles and benefits of having a type system. And you can evaluate how Mr.
> >>Date's proposal compare with other type systems.
> >
> >
> > I suppose the "essential roles and benefits of having a type system"
> > are best illustrated by the classic problems with propositional
> > calculus.
>
> ??
>
> Again, I refer you to Cardelli's "Type Systems". Maybe you should buy
> the whole book in which it was published to be able to see the proper (
> and larger ) context.

Problems in propositional calculus were solved by the introduction of domains (what I am calling a type), so how possibly can an alternate version of the definition of "type" (such as the "interface" example above) solve such problems?

> >>So far you have avoided to acknowledge even the most obvious limitations
> >>of Mr. Date's proposal, like subtyping is undecidable.
> >
> >
> > I have not avoided acknowledging them, there simply is nothing more to
> > say about them then "yes, the system cannot enforce that I define my
> > types correctly. Yes, this means the type developer can break things.
> > I am okay with that."
>
> Than why check types after all ? Let the developer take that
> responsibility also.

The system can and should do this to the fullest extent. Where it can't (such as in the general case of determining type/subtype relationships), it should do what can be done and hand the task to the developer.

> The first role of type systems is to oprevent developer from making type
> errors. That's a class of errors that should be preventable by the way
> we construct our programs, or otherwise type systems are useless and we
> can use an untyped perspective like that of Smalltalk.

I agree, and I see nothing in TTM's model that disallows the utmost possibly type checking.

> >>>Type and value are inextricably linked. You can't talk about one
> >>>without the other.
> >>
> >>"Inextricably linked" sounds very informal to me. You can't say in
> >>Mathematics that 2 definitions (type and value) are "inextricably
> >>linked". Whenever you have a recursive definition or a system of
> >>recursive definitions, you have to actually show the way out of recursion.
> >
> >
> > It was meant to be informal. If you would like a formal treatment,
> > consult references on 1st order predicate logic.
>
> That's what I strongly suggest you to do.

I don't think you recognized the "type" concept when it emerged by another name.

> And because you won't find much thing about types in there, I suggest
> you take a look at Constable's Naive Type Theory.

There are types in there, look again.

> If you construct a product that you claim is based on "theory" and a
> better theory for that matter then the pooh existing OO system (did I
> hear legacy?), you have to be able to offer better than that or admit
> you were wrong.

Here are a few references:
 H. Delong: A Profile of Mathematical Logic  G. Massey: Understanding Symbolic Logic.  Patrick Suppes: Introduction to Logic

> > For example, were the implementation to restrict user defined types
> > such that they could only be subtypes of "system" types, than I
> > imagine that the system could go much further (if not all the way) in
> > ensuring and inferring the "lattice".
>
> Then the whole thing breaks down and becomes unuseful.

No, it "breaks down" to where it compares with other "type systems" you mention.

> >>Or to say it more bluntly, is it implementable ?
> >
> > So far, so good. :-)
>
> How far ? :)

We simply have only partly implemented the type model. Thus far, we have found nothing in their model that is either impossibly to implement (though we had our doubts at first) or doesn't seem logically correct; we simply have not completed the task. I hope that when we do (or even before then), you play with it and tell us what you think. (no I am not trying to take your money, download the free eval ;).

Regards,

--
Nathan Allan