Re: foundations of relational theory?

#41

(I've moved some posts around to give better context)

Chandru wrote:
"Never saw the presentation either... do you have it, Laura?"

Laura wrote:
"Yup I do..."

I'd really like to see that.

Earlier, Laura had written:
"Unfortunately, Ultimate senior management didn't think that the
relationship with Codd and Date was worth persuing. <Heavy sigh>"

THERE IS ALTOGETHER TOO MUCH MISMANAGEMENT IN THE "PICK" WORLD!!!
Really pisses me off! It "could have been a contender"! Make that
"should".

Mike.

#42

Quote:

The "Pick" data model was developed by a think-tank within TRW

Don't know about the origin of triad, but the nucleus at TRW who developed the
DBMS included Dick Pick, Don Nelson and T. Dwight Buettell.

#43

Bob, I was on the verge of adding you as the very first entry of my
ignore-list when you posted the text below. Except for this bit of
insight, almost all of your posts read as nothing more than useless
personal attacks. Consider for a moment that your industry-specific
knowledge is worthless when all you do is to tell people they're
stupid and/or wrong. You yourself have no credibility at this point,
simply because you're a loudmouthed ass. If you'd temper your
attitude and argue constructively then maybe someone would listen to
your message, which once in a blue moon contains something worth
reading.

About your posting, I think it's correct that most people will create
structures without understanding which NF is being employed at any
given time. Most Pick people, and developers in general, are not
DBA's, they are mostly specialists in horizonal or vertical business
applications. People who work with databases at the application level
don't need to be DBA's any more than someone driving a car needs to be
a mechanic. Understanding the internals helps, but it's not required.
Perhaps this basic difference between the CDP and CDT members is
what's causing some friction; CDP people approach databases from an
applied usage perspective, and CDT people are more inclined to the
theoretical perspective.

Take note, however - we've been using the same model for a long time
and it DOES work well regardless of the judgements you pass on the
model or the people who use it. This inarguable fact is the one point
which should convince relational people to take a more serious look at
understanding WHY the Pick model works so well from a theoretical
perspective. A good database can't be judged entirely on its sound
mathematics (and Dawn is questioning even that point). Databases
serve a purpose and they must be judged on how well they ultimately
serve that purpose, regardless of the underlying asthetics.

Your statement about perfection being the direction in which to move
bears unusual insight. It would seem to be the responsibility of any
true database theoretician to truly understand the model before
dismissing it so passionately as we often see here an in other media.

Tony Gravagno, Nebula R&D
TG (AT) idratherbecodingNebula-RnD (DOT) com

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote:

Quote:

My point is that most existing systems out there are not 5nf.

With all due respect, without demonstrating any understanding of 1NF let
alone 5NF, you lack credibility in regard to what exists in most systems
with respect to normalization.

My point is
that most existing systems out there would requite the modifications that
I
said.

Are you telling me that the average system out there right now is 5nf?

Many are. Most people designing them or using them have no idea what normal
form their database exhibits. Your own statements are simply a paradigm for
the profound confusion and misconception pervading our industry.

You need to stop dismissing the foundations of your profession as an
unattainable and unimportant ideal. Regardless whether perfection is
attainable, it identifies the direction in which to move.

#44

Quote:

Googling "arithmetic algorithm triad" and alike leads nowhere.

Try this:

"Symbolic Algorithms for Infinite-state Systems"
www-cad.eecs.berkeley.edu/~rupak/ Powerpoint/SECTALK.ppt

The triad algorithm (attitude determination) used with satellites, GPS:
- Three-axis attitude determination from two vector observations
- Attitude Determination for Small Satellites withModest Pointing Constraints
www.aria.seas.wustl.edu/SSC02/papers/vi-1.pdf

#45

"Mike Preece" <michael (AT) preece (DOT) net> wrote

Quote:

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

[snip]
Few people want needless
complexity without benefit.

And fewer still respect those that criticise what they don't understand.

Yes, I know. This is the major reason I have no respect for you and your
ilk.

#46

Thank you, Tony, for your insight, clarity, and civility.

Your summation should pretty well conclude this thread.

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Quote:

Bob, I was on the verge of adding you as the very first entry of my
ignore-list when you posted the text below. Except for this bit of
insight, almost all of your posts read as nothing more than useless
personal attacks. Consider for a moment that your industry-specific
knowledge is worthless when all you do is to tell people they're
stupid and/or wrong. You yourself have no credibility at this point,
simply because you're a loudmouthed ass. If you'd temper your
attitude and argue constructively then maybe someone would listen to
your message, which once in a blue moon contains something worth
reading.

About your posting, I think it's correct that most people will create
structures without understanding which NF is being employed at any
given time. Most Pick people, and developers in general, are not
DBA's, they are mostly specialists in horizonal or vertical business
applications. People who work with databases at the application level
don't need to be DBA's any more than someone driving a car needs to be
a mechanic. Understanding the internals helps, but it's not required.
Perhaps this basic difference between the CDP and CDT members is
what's causing some friction; CDP people approach databases from an
applied usage perspective, and CDT people are more inclined to the
theoretical perspective.

Take note, however - we've been using the same model for a long time
and it DOES work well regardless of the judgements you pass on the
model or the people who use it. This inarguable fact is the one point
which should convince relational people to take a more serious look at
understanding WHY the Pick model works so well from a theoretical
perspective. A good database can't be judged entirely on its sound
mathematics (and Dawn is questioning even that point). Databases
serve a purpose and they must be judged on how well they ultimately
serve that purpose, regardless of the underlying asthetics.

Your statement about perfection being the direction in which to move
bears unusual insight. It would seem to be the responsibility of any
true database theoretician to truly understand the model before
dismissing it so passionately as we often see here an in other media.

Tony Gravagno, Nebula R&D
TG (AT) idratherbecodingNebula-RnD (DOT) com

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote:
My point is that most existing systems out there are not 5nf.

With all due respect, without demonstrating any understanding of 1NF let
alone 5NF, you lack credibility in regard to what exists in most systems
with respect to normalization.

My point is
that most existing systems out there would requite the modifications
that
I
said.

Are you telling me that the average system out there right now is 5nf?

Many are. Most people designing them or using them have no idea what
normal
form their database exhibits. Your own statements are simply a paradigm
for
the profound confusion and misconception pervading our industry.

You need to stop dismissing the foundations of your profession as an
unattainable and unimportant ideal. Regardless whether perfection is
attainable, it identifies the direction in which to move.

#47

Bob Badour wrote:

Quote:

"SixFtWabbit" <dragoninbabylon (AT) cox (DOT) net> wrote in message
news:HQXib.34578$La.22247 (AT) fed1read02 (DOT) ..

The relational model is applied mathematics. Pick is applied religion.

Your

thinking is as confused and idiotic as Dawn's.

The "Pick" data model was developed by a think-tank within TRW (I think it
was the actual brain-child of Don Nelson) based on an arithmetic algorithm
called a triad. It was specifically designed to handle a "Christmas

tree",

that is a bill of materials explosion, efficiently and easily.

As I said, Pick is applied religion. In what important way does the history
given above differ from a group of cardinals or bishops sitting down to
resolve dogma?

Sorry Bob, actually it would be the *Pope* that would declare dogma. But

you seem to make a habit of speaking on topics you don't fully comprehend.

HTH, Patrick <;=)

--
"Wrong is wrong, even if everyone is doing it.
Right is right, even if no one is doing it." ~ St. Augustine

#48

(Patrick Latimer)" <"(Patrick Latimer) wrote:
<snip>

Right is right, even if no one is doing it." ~ St. Augustine

What's left? :-)

Ed

#49

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

Quote:

Albert, with all due respect, you have failed to recognize that adding
multiple phone numbers will potentially invalidate all of the pre-existing
pick/aql queries that reference phone numbers. We have already established
quite clearly that changes in cardinality and even logically equivalent
physical changes have profound effects on the meaning of queries.

Potentially is the key here. Many times the allowing of a multiple value
causes little, or no effects.

I recall in the early 90's when I was staying a campground (that was using
MY MV database reservation system). The rule for this campground was one
vehicle per site, and any additional people booked into the site had to
leave their car in a overflow lot down the way (outside of the campground).
It turned out that sometimes people needed to change vehicles, and allow a
different vehicle into the campground (they would move the pass from one car
to the other). Of course, the campground asked me if it was possible to
modify the system to allow more then one vehicle (licence# etc) to entered
into the system. I said sure, and proceeded to simply allow the licence
field to be multi-valued. Instantly, the screen editor now would let users
enter more then one value for the licence# field.

The result was that now more then one vehicle could be allowed into a
campsite. Further, this change was DONE LIVE while bookings were being made,
and cars were lined up outside of the front gate. The system did NOT have to
halted, and bookings continued as normal. Further, all repost, and even
search prompts (that asked for what license#) etc ALL continued to function
correctly. This is simply one example of a live modification made to a
system in use, and no code, forms, reports and queries needed to be changed.
I have never used any sql based system that would allow such changes with
ease, and further even less of those systems would allow this change WHILE
IN USE. For the MV database, this change was a non event, but changed the
functionality of the system to the end user. Total time for the change was
less then 5 minutes, and with no down time.

For sure, not all changes are so slick and easy...but some certainly are. In
a sql based system, both the forms, code, reports and even quires that
search for a license# would all have to be changed. Quite a bit of work, and
certainly not the kind of change one would make to system with cars lined up
at the front gate.

--
Albert D. Kallal
Edmonton, Alberta Canada
kallal (AT) msn (DOT) com
http://www.attcanada.net/~kallal.msn

#50

"Albert D. Kallal" <NOOSSPAMkallal (AT) msn (DOT) com> wrote

<Some snippage>

Quote:

The result was that now more then one vehicle could be allowed into a
campsite. Further, this change was DONE LIVE while bookings were
being made, and cars were lined up outside of the front gate. The
system did NOT have to halted, and bookings continued as normal.
Further, all repost, and even search prompts (that asked for what
license#) etc ALL continued to function correctly. This is simply one
example of a live modification made to a system in use, and no code,
forms, reports and queries needed to be changed. I have never used
any sql based system that would allow such changes with ease, and
further even less of those systems would allow this change WHILE IN
USE. For the MV database, this change was a non event, but changed
the functionality of the system to the end user. Total time for the
change was less then 5 minutes, and with no down time.

For sure, not all changes are so slick and easy...but some certainly
are. In a sql based system, both the forms, code, reports and even
quires that search for a license# would all have to be changed. Quite
a bit of work, and certainly not the kind of change one would make to
system with cars lined up at the front gate.

Ah, but what we really need to know now is how many of those cars lined up
at the front gate were RED or BLUE? <vbg>

Mike Wooding

[comp.databases.theory x-post removed]