Re: The Practical Benefits of the Relational Model

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:ap8hqe$org$1_at_sp15at20.hursley.ibm.com...
> "D Guntermann" <guntermann_at_hotmail.com> wrote in message
> news:H4GvC4.B9K_at_news.boeing.com...
> [snip]
> > 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.
>
> Why would it be so limiting to use this design ? (attribute names first,
TYPEs
> second)
>

Sorry, I thought that this would be assumed when I indicated domain constraints as well as all other integrity constraints would be the same across all relation variables. What the types were exactly didn't seemed somewhat trivial (and dare I say it, orthogonal) in relation to my main point. I will try to be clearer next time.

> ISSUES(Issued PART_#, warehouse WH_ID, quantity INTEGER)
> RETURNS(Returned PART_#, warehouse WH_ID, quantity INTEGER)
> SHORTAGES(Short_of PART_#, warehouse WH_ID, quantity INTEGER)
> REQUESTS(Requested PART_#, warehouse WH_ID, quantity INTEGER)
>
> BTW I have not yet fully outlined *why* I want my restriction, but for the
> time being the one benefit I am suggesting is the removal of 'Orthogonal
> Design' problems .
>

I'd love hear *why*.
>
> In the first part of your note you were lamenting that "we only get part
of
> the predicate from the definition of a table".
> I feel that we do the best we can to translate whatever grammatically
florid
> predicate sentences we have into attribute names, types and constraints.

I agree with you. This is a viable solution, given what we have ;-)

> work with them. That's the point of formal systems. We formalise a part of
the
> real (or imagined) world, then work within our formulisation. What we
don't do
> is bleat on about 'oh but we have not captured the true meanings'.

But we can still point out shortcomings, even if they are subjective or perceived. If they are not shortcomings, you only have to point to one and only one viable and acceptable formal solution.

The fact of the matter is that the four transaction relations schemas I presented all fit into what I consider and understand to be the aggregation of formal definitions of the relational model (assuming that the orthogonal design principle is categorized not as a system model, but as a design principle, one that implies a framework, but not a formal imperitive).

   If you
> want to propose another formal system that does a better job of
'communicating
> the verbs of a predicate statement to a system', then go for it.

I wish I was that smart. However, I believe that table/relvar names are not as arbitrary as has been categorized. They might not communicate the full semantic meaning of a predicate to a system, but they certainly can be used, in my view, as a mechanism or placeholder that communicates predicate differentation to a system, even when attribute name and types are the same across base relation variables.

Personally,
> I'm happy to work with (and *within*) the relational model pretty much as
it
> stands today (give or take a few tweaks here and there :-)

So am I. Thanks for taking the time to address my points.

The words, lament and bleat being attributed to me. Ouch. I wish I could have conveyed my meaning in a better manner.

> Regards
> Paul Vernon
> Business Intelligence, IBM Global Services
>
>

Warmest regards,

Daniel Guntermann Received on Tue Oct 29 2002 - 21:19:20 CET