Re: The Practical Benefits of the Relational Model

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:ap6fms$ora$1_at_sp15at20.hursley.ibm.com... [snip]

> Date & McGovern allow two relvars in a database to have the same type,
thereby
> rasing the problem of 'orthogonal design'.
>
> I am suggesting that we do not allow two *real* relvars in a database to
have
> the same type, thereby avoiding the 'orthogonal design' problem.
>
> The question I have is; is my restriction on real relvars in a database
> acceptable? I have failed to think of a reason why it would not be
acceptable.

[snip]

It does not seem acceptable to me. It makes sense if a system can fully understand and enforce a predicate (as defined in a relation schema) precisely, but obviously it cannot. Date states that "the predicate for a given table represents the criterion of update acceptability," yet we only get part of the predicate from the definition of a table. Hundreds, thousands, and millions of predicates of varying semantics can work on the same domains, even in the same order, and produce logically equivalent criteria for updates in a database. Until we bridge the gap in communicating the verbs of a predicate statement to a system, I see little hope or sense in betting the farm on the 'Orthogonal Design' principle. Users, in contrast to a system, must rely on getting hints of the full import of the predicate from a table/relvar name in order to bridge the gap in determining whether a tuple meets the criterion of update acceptability. With proper domain enforcement and a way to communicate the full predicate to a system, design orthogonality could be viable as a principle both in theory and in practical application.

Much along the lines of the 'Loves-Hates' example in [1], I see no reason why the concept of 'Orthogonal Design' should limit me from defining multiple tables with the same attributes, and even with identical constraints (i.e. domain, column, table, and database constraints) all being equal:
ISSUES(part_number, warehouse, quantity) RETURNS(part_number, warehouse, quantity) SHORTAGES(part_number, warehouse, quantity) REQUESTS(part_number, warehouse, quantity)

[1] Date, C.J. and McGoveran, David. "The Principle of Orthogonal Design Part I" Taken from the Internet at http://www.pgro.uk7.net/principle1.htm.

Warmest Regards,

Dan Guntermann

>
> Regards
> Paul Vernon
> Business Intelligence, IBM Global Services
>
> P.S. my restriction means that relvar names are not considered to hold any
> meaning, they are just shorthands for a relation type.
>
>
Received on Thu Oct 24 2002 - 05:36:05 CEST