foundations of relational theory?

32 views
Skip to first unread message

Seun Osewa

unread,
Oct 13, 2003, 4:54:38 PM10/13/03
to
dw...@iserv.net (Dawn M. Wolthuis) wrote in message news:<6db906b2.03101...@posting.google.com>...
> "Anith Sen" <an...@bizdatasolutions.com> wrote in message news:<b56ib.32551$mQ2....@newsread1.news.atl.earthlink.net>...
> > BTW, it is hard to provide quick references to rectify every conceptual
> > misunderstanding and counterpoint each fallacious MV arguments. Generally,
> > it just warrants the invocation of the Principle of Incoherence.
> >
> > If the "XML doc specifiers" are proposing an alternative data model, yes,
> > they are taking a path, which was proven wrong already, but they aren't
> > aware of it yet.
>
> PROVEN? I would LOVE to see the proof -- I have begged to see a
> proof. There IS NO PROOF OF WHICH I AM AWARE or can you point me to
> one? In fact, persisting data with a model that is influenced by an
> understanding of language (since the idea is that we not just store
> it, but also retrieve it again) does employ a more complex structure
> by some measures (mathematical relations, for example) but it does so
> for a reason and, as I understand it, there is emperical evidence from
> contests performed over a decade ago (so we need to do these again) to
> show that systems that persist data with XML-like models (that what
> PICK is) provide a more agile development environment.
>
> Coming from a DBMS background, I was surprised to find that from my
> experience, my developers who used PICK-based systems also had a more
> agile environment for maintaining applications over time. That,
> however, is anecdotal evidence and therefore requires some emperical
> evidence or mathematical proof before I claimn that I KNOW it to be
> the case that it is always better to persist data outside of the RDBMS
> model.
[.....]

Ok, I think what we need to do is come up with an illustrative
example. A particular simple application which Dawn can use to
demonstrate the advantages of the MV model. And then our knowledgeable
relational model advocates can use the same example to "debunk" her
claims. And perhaps I can use it to show how some of my PlayDB
concepts might prove useful.

Dawn is not thinking in terms of "Large Shared Data Banks" that must
survive several generations of applications. She is thinking in terms
of productivity of application developers, who are also responsible
for the data model. The relational model is designed for flexibility
and data that is used for a long time by a host of different
applications.

So, in summary, how about a sample application which we use to compare
the models?

Seun Osewa

Dawn M. Wolthuis

unread,
Oct 13, 2003, 11:29:55 PM10/13/03
to
seun...@inaira.com (Seun Osewa) wrote in message news:<ba87a3cf.03101...@posting.google.com>...

>
> Ok, I think what we need to do is come up with an illustrative
> example. A particular simple application which Dawn can use to
> demonstrate the advantages of the MV model. And then our knowledgeable
> relational model advocates can use the same example to "debunk" her
> claims. And perhaps I can use it to show how some of my PlayDB
> concepts might prove useful.
>
> Dawn is not thinking in terms of "Large Shared Data Banks" that must
> survive several generations of applications. She is thinking in terms
> of productivity of application developers, who are also responsible
> for the data model. The relational model is designed for flexibility
> and data that is used for a long time by a host of different
> applications.
>
> So, in summary, how about a sample application which we use to compare
> the models?
>
> Seun Osewa

Good idea, Seun. One thing that might be of note is that many
PICK/MultiValue applications have survived well over 20 years -- NOT
JUST THE DATABASE, BUT THE ENTIRE APPLICATION! I was just asked to
review a D3 (PICK) application that was written in 1981 (and
maintained and enhanced in 82 - 2003 as well). The software company
is going to stick with a MV database solution and even retain some of
their existing data structures. This is NOT the exception -- it is
the NORM in the MV space. That is because of the ability to make
significant changes to applications without ditching them completely
and THAT is because of the approach used for persisting data. So,
while I agree that the relational model was intended to provide
flexibility and maintainability for large amounts of data over time
and that it DOES provide for application-development-environment
independence that is also true of other models such as PICK.

The big difference is where one codes the database integrity
constraints and whether they are all encoded as global constraints or
permit local constraints. In PICK, the same development environment
is used to encode integrity constraints as is used to build an
application, which means that a developer can change them to match new
application requirements. While this makes a typical DBA shudder,
there is simply no need for a typical DBA within the PICK environment
-- it runs lean and mean. If a new application will be using the same
persisted data, but not the same development environment, then
integrity constraints must be encoded in the new environment too.
That sounds terrible at the outset, but ends up acknowledging that
constraints mean nothing outside of the context of an application
anyway -- what one DOES with the data is part of what defines it.

Each new application ends up with many LOCAL constraints -- those that
were not present or might even contradict what was coded as a global
constraint when the data structures were initially defined. Within
the relational model, application developers must encode local
constraints and must also get any contradicting global constraints
changes AND the applications that originally forced these global
constraints must now encode them locally else they will be gone
entirely from that application (was that clear enough?)

Once it is clear that data is not useful in a vacuum, just as a human
memory is not useful outside of the I-O processing of the brain, then
the data and the applications can be seen as parts of the whole,
without such a separation as that introduced with (old-fashioned)
databases, such as network, hierarchical, or relational. PICK is also
old-fashioned, but within PICK, code is really data (source and object
code are items in files, just like any other database "record") and
data is really code (it is typeless/strings as stored data, but shown
as a type -- such as a date -- for output purposes; also you define
derived data as you would other application logic) and the data is
constrained by code, not by some database specs.

Take something seemingly simple like Names (perhaps including former
names) and phone numbers (or others can choose something) and we can
compare how this would be handled by the database plus an application
used to maintain such data and report against it in both an RDBMS and
in PICK. I'm game to try and if I can't find the time, I can see if
some real PICK developers could help me out. Alternatively or
additionally, we might want to see how the Berkely DB-XML contest
turns out -- there should be some good applications coming out of that
where a relational database is nowhere in sight.

--dawn

Jonathan Leffler

unread,
Oct 14, 2003, 2:38:11 AM10/14/03
to
Dawn M. Wolthuis wrote:

> [...snip...] but ends up acknowledging that


> constraints mean nothing outside of the context of an application
> anyway -- what one DOES with the data is part of what defines it.

> [...snip...]

Can you clarify what you mean by application? Is it a single program
executable, or a suite of programs forming an integrated unit? Or
something else...

So, from your point of view, each application (under any meaning
defined in answer to the previous question) defines and enforces its
own set of constraints on the data? And if more than one application
needs to use the data (developed, for the purposes of this discussion,
by different teams of programmers), how do the developers in any one
team ensure that the rules that they apply agree with the rules
applied by all the other teams? And when the people in one team need
to apply new rules to the existing data, how do they ensure that the
same rules are applied by all the other teams?

Your (heavily snipped) discussion mentioned local constraints and
global constraints and conflicts between the two. But I'm not sure I
followed how an MV system avoids problems between two mutually
incompatible views of the constraints on the data - could you clarify
that.

One of the things that vexes me in the context of databases
(especially those where the DBMS is in a separate process from the
application) is how an application can remain up to date with the
validation that is performed by the DBMS. The DBMS *must* (IMO) check
the data that it is asked to store for validity according to the rules
it has been told to enforce. (Obviously, if the DBMS has no rules to
enforce, any data is valid, but that is seldom going to be the case.)
The application obtains information from the user and would like to
be able to validate before presenting it to the DBMS for storage.
Applying basic rules (like domain constraints) is not usually a
problem; but more complex rules such as referential integrity etc are
much harder to deal with if the rules change.

--
Jonathan Leffler #include <disclaimer.h>
Email: jlef...@earthlink.net, jlef...@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Albert D. Kallal

unread,
Oct 14, 2003, 5:41:55 AM10/14/03
to
"Jonathan Leffler" <jlef...@earthlink.net> wrote in message
news:nRMib.566$7a4...@newsread4.news.pas.earthlink.net...

> Dawn M. Wolthuis wrote:
>
> > [...snip...] but ends up acknowledging that
> > constraints mean nothing outside of the context of an application
> > anyway -- what one DOES with the data is part of what defines it.
> > [...snip...]
>
> Can you clarify what you mean by application? Is it a single program
> executable, or a suite of programs forming an integrated unit? Or
> something else...
>
> So, from your point of view, each application (under any meaning
> defined in answer to the previous question) defines and enforces its
> own set of constraints on the data? And if more than one application
> needs to use the data (developed, for the purposes of this discussion,
> by different teams of programmers), how do the developers in any one
> team ensure that the rules that they apply agree with the rules
> applied by all the other teams?

Good question. When you look at the old dbase programs of the 1980's, they
all ran fine and of course any constraints in the data had to be in the
code. However, who wants to go back 20 years in the IT industry?

In the case of MV systems there is no question that some data constraints do
exist in the code. Thus, there is for sure the problem of communicating the
rules to the developers. And, of course the obvious problem of discovering
those rules existing in the code. Thus, each application will, and often
does have some constraints in the application. We would all agree this is
not good. However, even in applications today, we often see little, or no
use of data engine constraints anyway. The bulk of applications that use
MySql is a good example of this. Not to be un-kind to the many old dbase
programs, or MySql programs, but the fact is that many applications don't
need much constraints anyway. The popular success of dBase years ago, and
the popularity of MySql today proves this (MySql has not had any engine
constraints for that long of a period). Need we mention the popular of
Excel? It is perhaps the most wildly used tool for data managing (this is
not good...but is a fact of life!).

However, having noted this lack of constraints, I did say that a "portion"
of the constraints do exist in MV databases. In fact, you actually get a LOT
of RI (referential integrity) for free in a MV database. The other poster
mentioned there is LOTS of MV databases that have survived more then 20
years. One the reasons for this is that MV systems did, and do incorporate a
good deal of RI by their design. Something that most systems 20 years ago
did not have. While dbase programs have gone mostly by the way side, MV
systems continue to function today.

Lets me give you an example of what I mean by constraints for free:

Let assume we have the classic invoice. That means a bunch of fields like
date, time, customer, method of shipping etc. (you know...the whole deal
here). The other thing you need of course is the invoice details. (the
classic related child table with stuff like product number, quantity,
description, unit price etc). In MV land, that "set" of invoice details is
defined in the dictionary. The result of this MV set is a number of RI
constraints for free:

Some of them are:
** If the invoice record is deleted, then the invoice details are also
deleted for you. This is simply the way the MV systems have worked for the
last 30 years. You get this feature for free.


** You can't add, or save invoice details without first creating a invoice
id. Again, this RI feature comes for free in a MV system. The design of
system is such that you can't even write code, nor save the record to disk
without first creating the invoice id.

** You don't have to create or have some index that connects the invoice,
and the invoice details together. This also means that you do not need to
read multiple child records here, since the invoice is in fact one record.
This fact increases performance by a large amount, and eliminates the need
for relational join.

** For each line of invoice details you add, no foreign key is needed to
relate back to the parent record (the invoice record). Again, this feature
is free as result of the design. Virtually all modern sql based systems
today STILL require some code to set this foreign key value. We have don't
have to do this for MV data sets. It is amazing that modern systems sill
require the developers to set this key value. Note that RI might prevent the
developers from adding a foreign key that does not exist, but the developers
and the code still has to set this foreign key value. In the case of a
multi-valued set of data...we don't have to code this, or even have to use a
foreign key! Thus, in some cases, I can argue that MV systems has less code
required for RI.

So, you actually do get a lot of RI for free in a MV system. In fact, that
invoice may have several sets data related, and all the above free benefits
applies. So, if I have a list of who edited, or viewed the invoice, and then
we delete the invoice, those lists also get deleted just like the invoice
details do. No special coding again is required.

As mentioned, not all RI is free in a MV system, but surprisingly amount is.
In fact, the problem is that MOST of the MV community does not realize the
above! It is only when you spend time in sql land do you realize the above
points.

Since the MV system does thus have a good deal of RI for free, then this is
no doubt one reason why MV systems have stood the test of time.

Further, even more important is that the addition of these child data sets
were far more easier to implement in MV systems then most systems, and
existing data AND CODE DID not have to be modified when a "child data set"
is added.

For example, many old systems only needed one phone number field. today, we
have cell phones, pagers etc. (the list is huge). In a mv system, these
additional phone numbers can be added, BUT EXISTING REPORTS and even code
can still function. In a sql relational system, all of the reports, code and
even the data entry screens will have to be EXTENSIVELY modified to add
additional phone fields. I am assuming that those additional fields would of
course be moved into a child table and related back to the parent table.
This large change in design that does not occur in a MV system. Thus, again,
this is why so many are pointing out the benefiting of long term
maintenance, and why the MV system has stood the test of time.

--
Albert D. Kallal
Edmonton, Alberta Canada
kal...@msn.com
http://www.attcanada.net/~kallal.msn

Tony Gravagno

unread,
Oct 14, 2003, 7:42:09 AM10/14/03
to
This discussion has bled over into comp.databases.pick from
comp.databases.theory. I recommend CDPers check the full thread for
context before posting.

Kudos to Dawn for challenging the church of relational thinking. I
see what she's talking about when I read books and articles. Look at
any introduction/definition of databases or the history of databases:
Everyone assumes nested values are invalid or don't exist (but they
don't say why they're bad), and no one mentions Pick which has been a
successful model for over 30 years. It's as though the church has
decided that there is only one way to the holy database and to even
mention alternatives is blasphemous.

I started to respond to questions and misconceptions in this thread
but there's just too many. No offense intended, but in reviewing this
thread and others, I see a lack of knowledge, and misconceptions about
the Pick model. It's difficult for Dawn to make comparisons in her
arguments when relational people have a fundamentally different view
of what a database is supposed to look like. For example, relational
people are database-centric and Pick people are more focused on the
application software that maintains and queries the database. Also,
relational people want the DBMS to maintain referential integrity,
while Pick people assume that's the responsibility of the app
developer - neither view is "right" in terms long-lasting, quality
solutions, they're just different.

Someone needs to document the misunderstandings and answer the
questions so that everyone at least understands the view of the people
arguing the other side. I'm thinking a website is the most
appropriate place. Documenting points like this in an open forum is
cumbersome and too subject to bickering.

Tony Gravagno, Nebula R&D, Pick guy for over 20 years,
Former DBMS Product Manager,
(Raining Data, formerly Pick Systems)
T...@removethisNebula-RnD.com

Mecki Foerthmann

unread,
Oct 14, 2003, 8:56:27 AM10/14/03
to

"Jonathan Leffler" <jlef...@earthlink.net> wrote in message
news:nRMib.566$7a4...@newsread4.news.pas.earthlink.net...
<snip>

> And if more than one application
> needs to use the data (developed, for the purposes of this discussion,
> by different teams of programmers), how do the developers in any one
> team ensure that the rules that they apply agree with the rules
> applied by all the other teams? And when the people in one team need
> to apply new rules to the existing data, how do they ensure that the
> same rules are applied by all the other teams?
>
Communication!


Paul Vernon

unread,
Oct 14, 2003, 6:30:21 AM10/14/03
to
"Dawn M. Wolthuis" <dw...@iserv.net> wrote in message
news:6db906b2.0310...@posting.google.com...
[snip]

> That is because of the ability to make
> significant changes to applications without ditching them completely
> and THAT is because of the approach used for persisting data.

I suggest it is because of the tight integration between application and
database that exists in a (nowadays isolated) environment such as PICK that
allows 'significant changes to applications' to be made relatively easily.
It is not due to the 'approach used for persisting data' (or at least,
relational would be even better if only we had good relational systems that
tightly integrate with applications. Maybe Dataphor is the best example we
currently have).

In otherwords, the 'data sub-language' idea of SQL is arguably the biggest
hindrance to easy schema evolution in SQL systems. This is absolutely, not a
problem of the Relational Model itself however. In fact the logical data
independence of the relational model provides amble support for schema
evolution, it's just that no-one has done any kind of semi-decent
implementation AKAIK.


[snip]


> In PICK, the same development environment
> is used to encode integrity constraints as is used to build an
> application, which means that a developer can change them to match new
> application requirements.

[snip]


>While this makes a typical DBA shudder,
> there is simply no need for a typical DBA within the PICK environment
> -- it runs lean and mean.

[snip]


> If a new application will be using the same
> persisted data, but not the same development environment, then
> integrity constraints must be encoded in the new environment too.
> That sounds terrible at the outset, but ends up acknowledging that
> constraints mean nothing outside of the context of an application
> anyway -- what one DOES with the data is part of what defines it.

All of the above are arguments about the pros/cons of particular
implementations, they say nothing about the inherent capabilities of
different logical models of data (which is what we are meant to be talking
about yes?)

Having said that, I agree that relational implementations should exhibit the
kinds of things you mention above. In particular not *requiring* a DBA would
be a huge step forward for implementations of the relational model .

[snip]


> Once it is clear that data is not useful in a vacuum, just as a human
> memory is not useful outside of the I-O processing of the brain, then
> the data and the applications can be seen as parts of the whole,
> without such a separation as that introduced with (old-fashioned)
> databases, such as network, hierarchical, or relational.

Just to be clear, the relational (or network or hierarchical..) models
themselves do not mandate any particular large or small separation between
applications and data. It is only that some implementations of them choose
to do so.


Regards
Paul Vernon
Business Intelligence, IBM Global Services


Paul Vernon

unread,
Oct 14, 2003, 7:18:17 AM10/14/03
to
"Albert D. Kallal" <NOOSSPA...@msn.com> wrote in message
news:DxPib.92732$pl3.2925@pd7tw3no...
[snip]

> For example, many old systems only needed one phone number field. today,
we
> have cell phones, pagers etc. (the list is huge). In a mv system, these
> additional phone numbers can be added, BUT EXISTING REPORTS and even code
> can still function. In a sql relational system, all of the reports, code
and
> even the data entry screens will have to be EXTENSIVELY modified to add
> additional phone fields. I am assuming that those additional fields would
of
> course be moved into a child table and related back to the parent table.

Agreed. Although that is a SQL problem (e.g. lack of updatable views, lack
of relation valued attributes etc) rather than a problem of the relational
model.

Good post though.

Bob Badour

unread,
Oct 14, 2003, 9:17:35 AM10/14/03
to
"Tony Gravagno" <g6q3x9...@sneakemail.com.invalid> wrote in message
news:u7gnov0pe694d7hdn...@4ax.com...

> This discussion has bled over into comp.databases.pick from
> comp.databases.theory. I recommend CDPers check the full thread for
> context before posting.
>
> Kudos to Dawn for challenging the church of relational thinking.

The relational model is applied mathematics. Pick is applied religion. Your
thinking is as confused and idiotic as Dawn's.


> I
> see what she's talking about when I read books and articles. Look at
> any introduction/definition of databases or the history of databases:
> Everyone assumes nested values are invalid or don't exist (but they
> don't say why they're bad)

I can only conclude you either lack the ability to comprehend written
english or paid little attention to what you read. Few people want needless
complexity without benefit.


Bob Badour

unread,
Oct 14, 2003, 9:17:40 AM10/14/03
to
"Jonathan Leffler" <jlef...@earthlink.net> wrote in message
news:nRMib.566$7a4...@newsread4.news.pas.earthlink.net...

[responses to dawn's idiotic nonsense snipped]

> One of the things that vexes me in the context of databases
> (especially those where the DBMS is in a separate process from the
> application) is how an application can remain up to date with the
> validation that is performed by the DBMS. The DBMS *must* (IMO) check
> the data that it is asked to store for validity according to the rules
> it has been told to enforce. (Obviously, if the DBMS has no rules to
> enforce, any data is valid, but that is seldom going to be the case.)
> The application obtains information from the user and would like to
> be able to validate before presenting it to the DBMS for storage.
> Applying basic rules (like domain constraints) is not usually a
> problem; but more complex rules such as referential integrity etc are
> much harder to deal with if the rules change.

One need only write well-behaved applications that communicate database
errors to users. At worst, the user will experience a slight delay when the
user enters data that would corrupt the data according to some unanticipated
future requirement. One is left with the freedom to perform a simple
cost-benefit analysis: Does the benefit of removing the delay in these
exceptional circumstances outweigh the cost of updating the application?
Alphora addresses this problem by reducing the cost of updating the
application through automatic application generation.

Contrast the cost-benefit analysis when applications enforce constraints
instead: Does the benefit of trusting one's data exceed the cost of updating
all affected applications? Does the benefit of a new application exceed
either the cost of corrupt data or the cost of updating all existing
applications?


Bob Badour

unread,
Oct 14, 2003, 9:18:02 AM10/14/03
to
"Albert D. Kallal" <NOOSSPA...@msn.com> wrote in message
news:DxPib.92732$pl3.2925@pd7tw3no...

Enough said.

[superfluous and contradictory rationalizations snipped]


> Lets me give you an example of what I mean by constraints for free:

Nothing is free. We have already established that pick imposes large
unecessary costs just to express simple concepts.

[wordy elaboration predicated on false assumption snipped]


Bob Badour

unread,
Oct 14, 2003, 9:27:31 AM10/14/03
to
"Mecki Foerthmann" <mec...@gmx.net> wrote in message
news:bmgrl3$pcr$1...@newsreaderm1.core.theplanet.net...

Have you read Fred Brooks' _The Mythical Man-Month_ ? As the number of
applications grows linearly the communication problem grows quadratically.
However, there remains a single database.


Laura Hirsh

unread,
Oct 14, 2003, 9:43:44 AM10/14/03
to
In 1988 while I was a product manager for Ultimate, one of our missions was
to try to address this debate - not from a 'he said/she said' point of view,
but right from the source.

We had a meeting with the Ultimate folks (Chandru???), along with Dr. Codd,
C.J. Date and Dr. Nathan Goodman - Senior Vice President of R&D, Codd and
Date, Intl.

It was an interesting meeting. We agreed that the two organizations should
spend some time together and explore the Pick vs. Relational issue. So, I
spent the next couple of weeks with Dr. Goodman, and we went through the
"Total Package" that Ultimate offered at the time... including the OS/DBMS,
applications, utilities, cross-platform portability (Honeywell, DEC, Tandem,
and the PC) and price/performance.

At the conclusion, Dr. Goodman put together a marketing-type presentation
regarding Pick, which he was to give at the next Ultimate dealer meeting.
Dr. Goodman's conclusion was very positive regarding Pick, and although he
clearly states that the Pick model "is not relational", he states that "Pick
can be the poor man's relational"... and that "Pick accomplishes a lot of
what the relational model tries to accomplish".

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

Laura Hirsh

cmurthi

unread,
Oct 14, 2003, 11:45:07 AM10/14/03
to
Unfortunately I missed this meeting because it was postponed from the
original date (ha!) for which I flew in from SF to NJ. Never saw the
presentation either... do you have it, Laura?

Also, can someone tell me how to setup a filter to eliminate tiresome
posts such as BB's (and other's)? I use Netscape client and can do it
for regular mail (thankfully) but not on newgroups...

Chandru Murthi

kevin zollinger

unread,
Oct 14, 2003, 12:02:02 PM10/14/03
to
"Bob Badour" <bba...@golden.net> wrote in
news:57adnaV4RLk...@golden.net:

[snip]


> The relational model is applied mathematics. Pick is applied religion.
> Your thinking is as confused and idiotic as Dawn's.

[snip]


> I can only conclude you either lack the ability to comprehend written
> english or paid little attention to what you read. Few people want
> needless complexity without benefit.

Can I just take a minute here to express my heartfelt gratitude that Bob is
on the "other team?"

--
~ kevin zollinger
ke...@mailsoap.com

Mikito Harakiri

unread,
Oct 14, 2003, 12:25:50 PM10/14/03
to

"Albert D. Kallal" <NOOSSPA...@msn.com> wrote in message
news:DxPib.92732$pl3.2925@pd7tw3no...
> For example, many old systems only needed one phone number field. today,
we
> have cell phones, pagers etc. (the list is huge). In a mv system, these
> additional phone numbers can be added, BUT EXISTING REPORTS and even code
> can still function. In a sql relational system, all of the reports, code
and
> even the data entry screens will have to be EXTENSIVELY modified to add
> additional phone fields. I am assuming that those additional fields would
of
> course be moved into a child table and related back to the parent table.
> This large change in design that does not occur in a MV system. Thus,
again,
> this is why so many are pointing out the benefiting of long term
> maintenance, and why the MV system has stood the test of time.

Sorry, but you need to go to class and study what relational view is.

As for the practical examples, I know a big application vendor that changed
the whole customer database schema, and substituted old tables with views
for compatibility. The changes were much more significant than just adding a
column. And adding columns, in fact, doesn't imply any application changes.


Albert D. Kallal

unread,
Oct 14, 2003, 12:54:34 PM10/14/03
to
"Paul Vernon" <paul....@ukk.ibmm.comm> wrote in message

> Agreed. Although that is a SQL problem (e.g. lack of updatable views, lack
> of relation valued attributes etc) rather than a problem of the relational
> model.
>
> Good post though.
>
> Regards
> Paul Vernon
> Business Intelligence, IBM Global Services
>

Without question, one can easily point out that the main stream database
vendors do not have a perfect relational system. However, I did think it
worth while to point out that the MV model does get some RI as a result of
how the MV model is actually implemented in the marketplace today.

The same holds true of the issue of adding phone numbers. While updatable
views would help this, in most cases, the application would still extensive
modifications just to search for a phone number. The reports would also have
to be modified. This large amount of changes does NOT occur for MV
applications. Certainly an "ideal" relational system might reduce the amount
of changes required...but we don't have that ideal relational system in the
marketplace right now. We have to use what we got now.

Ed Sheehan

unread,
Oct 14, 2003, 1:15:52 PM10/14/03
to
Albert D. Kallal wrote:

<snip>

> Lets me give you an example of what I mean by constraints for free:
>
> Let assume we have the classic invoice. That means a bunch of fields
> like date, time, customer, method of shipping etc. (you know...the
> whole deal here). The other thing you need of course is the invoice
> details. (the classic related child table with stuff like product
> number, quantity, description, unit price etc). In MV land, that
> "set" of invoice details is defined in the dictionary.

The details CAN be defined in the dictionary for query purposes, but it's
not required, especially if all queries are written in BASIC.

The result of
> this MV set is a number of RI constraints for free:
>
> Some of them are:
> ** If the invoice record is deleted, then the invoice details are
> also deleted for you. This is simply the way the MV systems have
> worked for the last 30 years. You get this feature for free.

There are many instances where the child sets are stored externally and
links to the external data are stored in the "header" records. When there is
voluminous child data, you may want to segregate that data from the headers,
in order to avoid large memory requirements when updating/querying just the
header. Also, parsing/updating up to hundreds of values stored in more than
20 sets can take more time than is wanted, compared to updating/retrieving
them from a hashed file, and dealing only with item/id's stroed as links in
the main item.

>
>
> ** You can't add, or save invoice details without first creating a
> invoice id. Again, this RI feature comes for free in a MV system. The
> design of system is such that you can't even write code, nor save the
> record to disk without first creating the invoice id.

Not true when using segregated data.

>
> ** You don't have to create or have some index that connects the
> invoice, and the invoice details together. This also means that you
> do not need to read multiple child records here, since the invoice is
> in fact one record. This fact increases performance by a large
> amount, and eliminates the need for relational join.

Not true when using segregated data.

>
> ** For each line of invoice details you add, no foreign key is needed
> to relate back to the parent record (the invoice record).

Not true when using segregated data.


Again, this
> feature is free as result of the design. Virtually all modern sql
> based systems today STILL require some code to set this foreign key
> value. We have don't have to do this for MV data sets.

Not true when using segregated data.

It is amazing
> that modern systems sill require the developers to set this key
> value. Note that RI might prevent the developers from adding a
> foreign key that does not exist, but the developers and the code
> still has to set this foreign key value. In the case of a
> multi-valued set of data...we don't have to code this, or even have
> to use a foreign key!

Not true when using segregated data.

Thus, in some cases, I can argue that MV
> systems has less code required for RI.
>
> So, you actually do get a lot of RI for free in a MV system. In fact,
> that invoice may have several sets data related, and all the above
> free benefits applies. So, if I have a list of who edited, or viewed
> the invoice, and then we delete the invoice, those lists also get
> deleted just like the invoice details do. No special coding again is
> required.

Not true when using segregated data.

>
> As mentioned, not all RI is free in a MV system, but surprisingly
> amount is. In fact, the problem is that MOST of the MV community does
> not realize the above! It is only when you spend time in sql land do
> you realize the above points.
>
> Since the MV system does thus have a good deal of RI for free, then
> this is no doubt one reason why MV systems have stood the test of
> time.
>
> Further, even more important is that the addition of these child data
> sets were far more easier to implement in MV systems then most
> systems, and existing data AND CODE DID not have to be modified when
> a "child data set" is added.

Agreed.

>
> For example, many old systems only needed one phone number field.
> today, we have cell phones, pagers etc. (the list is huge). In a mv
> system, these additional phone numbers can be added, BUT EXISTING
> REPORTS and even code can still function. In a sql relational system,
> all of the reports, code and even the data entry screens will have to
> be EXTENSIVELY modified to add additional phone fields. I am assuming
> that those additional fields would of course be moved into a child
> table and related back to the parent table. This large change in
> design that does not occur in a MV system. Thus, again, this is why
> so many are pointing out the benefiting of long term maintenance, and
> why the MV system has stood the test of time.

When storing multivalued data as a child set, all the benefits above are
true, but not merely because mulitvalued storage is possible in Pick. Only
when people make actual use of embedded child sets are the benefits of
"local storage" realized. That may be obvious to many Pick seasoned
professionals, but I believe newbies/flat filers need to be aware of the
distinction.

Ed

P.S. My spell checker wanted to change sql to sol. Hmmm...


Albert D. Kallal

unread,
Oct 14, 2003, 1:23:34 PM10/14/03
to
"Mikito Harakiri" <mikha...@iahu.com> wrote in message
news:zAVib.30$It5...@news.oracle.com...

>
>
> As for the practical examples, I know a big application vendor that
changed
> the whole customer database schema, and substituted old tables with views
> for compatibility. The changes were much more significant than just adding
a
> column. And adding columns, in fact, doesn't imply any application
changes.

Where did I say that adding a column implies application changes?

Further, I did quite clearly state that one would *usually* add a new table
when going to add additional phone numbers (surely one would not suggest
adding a bunch of new columns for additional phone numbers...would they?)
That is certainly not the normalize way of doing things.

Look, fact is that if you need to add additional phone numbers you probably
will need to (and *should*) break out the phone numbers to another table in
most modern database systems today.

Given the above reality of adding another table, then most of the existing
reports and certainly most of the data entry screens will have to be
modified to take this fact into account. Simply making a relational view for
those existing reports will not allow you display those additional phone
numbers without some report modifications. The same goes for code that
searches for those phone numbers. Of course, the ideal situation would been
to have a proper design in the first place, and *already* had the phone
number in another table.

Of course if everything was a perfect relational model, and every
application was implement perfectly, then we would not be having this
discussion.

I am only stating that in today's marketplace, adding those additional phone
numbers generally takes WAY less modifications to the application side in a
MV system then what most modern sql systems require. This is assuming we do
add another table. If one simply adds a few new columns, then yes...usually
nothing needs to be changed in either type of system. (but in a MV system,
the existing code and applications will actually now search for the new
additional phone numbers without modification. You may get this with some
relational views...but it is not the norm).

When we get the perfect world..then this will not matter...until then...we
have to use what we got!

Anthony W. Youngman

unread,
Oct 14, 2003, 1:25:06 PM10/14/03
to
In article <ba87a3cf.03101...@posting.google.com>, Seun Osewa
<seun...@inaira.com> writes

>> Coming from a DBMS background, I was surprised to find that from my
>> experience, my developers who used PICK-based systems also had a more
>> agile environment for maintaining applications over time. That,
>> however, is anecdotal evidence and therefore requires some emperical
>> evidence or mathematical proof before I claimn that I KNOW it to be
>> the case that it is always better to persist data outside of the RDBMS
>> model.
>[.....]
>
>Ok, I think what we need to do is come up with an illustrative
>example. A particular simple application which Dawn can use to
>demonstrate the advantages of the MV model. And then our knowledgeable
>relational model advocates can use the same example to "debunk" her
>claims. And perhaps I can use it to show how some of my PlayDB
>concepts might prove useful.

Okay ... and I think this happened in BOTH Denmark, AND the UK.

A major computer magazine (in the UK it was Computer Weekly) ran a
competition annually for some five years. The brief was, you were given
a spec, and 24 hours later, you turned in your working application for
judging.

In both competitions, the prizes were won EVERY time by teams using MV
databases. I think it was OpenInsight was used by most of them.

Oh - several teams using relational databases failed even to get as far
as getting the basic data layout defined ...


And I can't give any details beyond "Witwatersrand Uni, South Africa",
but apparently they did a study of a load of (presumably successful)
companies, plotting database spend against turnover. There were actually
TWO peaks. Most of the companies in the lower (cheaper - 2% iirc) peak
were running MV databases. The ones in the more expensive peak (4%) were
running relational.


My favourite example is always to quote an invoice. How many tables do
you need in a relational database? One for the invoice itself, one for
the addresses (two at least, billing and shipping), one for the line
detail, a couple maybe for the relationships ...

In MV I would have just ONE "file" (as we call our equivalent to a
table) and I would need just ONE "record" (as we call our equivalent to
a row). Oh - and it's all properly normalised just as it would be in
relational - so I can present it to you as a SQL view no problem. Just
that whereas it costs you a hell of a lot of searching through tables
and indices to pull everything even if you know the invoice number,
presuming I've defined invoice number as the primary key I can retrieve
ALL that information with a single head movement on disk. Given that
disk io is the slowest thing on the system, if you can't store your
entire database in ram I've just kicked the shit out of you for speed
:-)

"How to win at poker - take your weaknesses and bluff that they're your
strengths" - I'm not saying that SQL's abstraction is a bad thing (it
does make ad-hoc queries easier), but by hiding the realities of
implementation from programmers you are basically handicapping them such
that they will NEVER be able to even compete successfully (let alone
win) if one of the requirements is to stretch the hardware to its
limits.

The reason MV is so powerful is that it's easy for us mimic relational -
it's a *subset* of what we have available to us. But in order for you to
match us, you have to implement (using all sorts of SLOW or EXPENSIVE
workarounds) what our model gives us for free - take my "one disk hit
and I can give you an entity view" :-) How expensive is a "many to many"
join in SQL? The chances are we don't need it, and if we do then we can
use an explicit index that costs us bugger all - it'll cost you a major
disk thrash :-)

Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
Witches are curious by definition and inquisitive by nature. She moved in. "Let
me through. I'm a nosey person.", she said, employing both elbows.
Maskerade : (c) 1995 Terry Pratchett

Laura Hirsh

unread,
Oct 14, 2003, 1:27:00 PM10/14/03
to
Yup I do... (and re-reading my message, it's clear that I didn't use a
spelling checker... sorry folks).

Anyway, I couldn't remember exactly who was at the meeting... maybe 10 or so
people... Codd, Date, Goodman... I'm sure Carl Margolis was there, and Al
Franco... it was interesting! And, although it doesn't come across in the
presentation, one of the features that really made a difference was
Ultimate's combination of Recall (now commonly called Access) and Update.
Not Dick Pick's Update, but Chandru's...

For those not familiar with Update (also called Forge), in the example of
LIST CUSTOMER NAME ADDRESS CITY STATE ZIP, where you'd get a report, you
could UPDATE CUSTOMER NAME ADDRESS CITY STATE ZIP, and you'd get a data
entry form. In this method, the same dictionary items used to display data
could be used to update the database. The dictionary definition contained
all the validations, defaults, conversions, etc. One dictionary, one
validation, one view... and although not used exclusively, (i.e., Basic was
also available), having UPDATE allowed us to "pass" a number of Codd and
Date's rules having to deal with security, integrity, and the treatment of
nulls.

My favorite part was Dr. Goodman's statement "Pick accomplishes a lot of
what the relational model *tries* to accomplish"... there it was... straight
from the horse's mouth... interesting that at the time, not even the so
called "relational databases" that were being so lauded met all the criteria
of the relational model. I wonder if they do now?

Laura


"cmurthi" <xyzcm...@quest.with.a.w.net> wrote in message
news:3F8C1A03...@quest.with.a.w.net...

Bob Badour

unread,
Oct 14, 2003, 1:50:30 PM10/14/03
to
"Albert D. Kallal" <NOOSSPA...@msn.com> wrote in message
news:eTVib.95508$6C4.76722@pd7tw1no...

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.


Bob Badour

unread,
Oct 14, 2003, 1:53:48 PM10/14/03
to
"Albert D. Kallal" <NOOSSPA...@msn.com> wrote in message
news:qiWib.95782$6C4.5417@pd7tw1no...

> "Mikito Harakiri" <mikha...@iahu.com> wrote in message
> news:zAVib.30$It5...@news.oracle.com...
> >
> >
> > As for the practical examples, I know a big application vendor that
> changed
> > the whole customer database schema, and substituted old tables with
views
> > for compatibility. The changes were much more significant than just
adding
> a
> > column. And adding columns, in fact, doesn't imply any application
> changes.
>
> Where did I say that adding a column implies application changes?
>
> Further, I did quite clearly state that one would *usually* add a new
table
> when going to add additional phone numbers (surely one would not suggest
> adding a bunch of new columns for additional phone numbers...would they?)
> That is certainly not the normalize way of doing things.

With all due respect, you do not yet understand normalization. A relation
with attributes for each of a main voice phone, a fax number, a cell number
and a modem might be in 5NF.


> Look, fact is that if you need to add additional phone numbers you
probably
> will need to (and *should*) break out the phone numbers to another table
in
> most modern database systems today.

Applying such a simplistic, thoughtless recipe is a recipe for disaster.


> Given the above reality of adding another table

Since it is not a reality, the remainder of your post is meaningless.


Paul Vernon

unread,
Oct 14, 2003, 1:47:30 PM10/14/03
to
"Albert D. Kallal" <NOOSSPA...@msn.com> wrote in message
news:eTVib.95508$6C4.76722@pd7tw1no...
[snip]

> Certainly an "ideal" relational system might reduce the amount
> of changes required...but we don't have that ideal relational system in
the
> marketplace right now.

> We have to use what we got now.

Not in comp.database.theory we don't. :-)

Here we can use whatever constructions we like - just as long as we can
explain sufficiently well how well they *would* work if anyone got round to
implementing them.

If you want to limit your discussions to what is "in the marketplace right
now", then I suggest one should avoid cross posting to comp.database.theory

Albert D. Kallal

unread,
Oct 14, 2003, 2:12:59 PM10/14/03
to
"Bob Badour" <bba...@golden.net> wrote in message news:bwednXYN6o7DpRGiU-


> With all due respect, you do not yet understand normalization. A relation
> with attributes for each of a main voice phone, a fax number, a cell
number
> and a modem might be in 5NF.

Yes, it *might* be. And then again, it might not be? Thus, I don't
understand your point here?

My point is that most existing systems out there are not 5nf. 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?

I am simply pointing out what the current situation is, and what we have to
deal with on a daily basis. It would be great if all systems were 5nf, but
they are not. It would be great if all major database vendors had a perfect
relational model..but they don't

I am just pointing out the reality that applies to the majority of the
current systems in the current marketplace. The changes I pointed out are
usually greater in a sql based system then they are in mv system.

The perfect ideal would be great..but we don't have that right now. I am
speaking of what developers have to deal with on a daily bases. What of are
you speaking about? That perfect system and implemtation is extremely rare
today. We cannot ignore the current situation and state of affairs that
exists in the average application today.

If your applications that you deal with are perfect, then so be it.
Unfortunately, some of us have to deal with existing systems.

Albert D. Kallal

unread,
Oct 14, 2003, 2:24:29 PM10/14/03
to
"Paul Vernon" <paul....@ukk.ibmm.comm> wrote in message
>
> If you want to limit your discussions to what is "in the marketplace right
> now", then I suggest one should avoid cross posting to
comp.database.theory
>
> Regards
> Paul Vernon
> Business Intelligence, IBM Global Services

A most fair point. I shall endeavour to keep that point in the sprit in of
that newsgroup.

Mikito Harakiri

unread,
Oct 14, 2003, 2:22:33 PM10/14/03
to

"Albert D. Kallal" <NOOSSPA...@msn.com> wrote in message
news:qiWib.95782$6C4.5417@pd7tw1no...

> Further, I did quite clearly state that one would *usually* add a new
table
> when going to add additional phone numbers (surely one would not suggest
> adding a bunch of new columns for additional phone numbers...would they?)
> That is certainly not the normalize way of doing things.

I'm certain that on practice you'll encounter database schema like this

table Customer (
...
phone_num String,
phone_num2 String,
fax_num String,
...
)

more often than normalized design. After seeng this
http://www.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=tGXM6.6343%246
j3.567845%40www.newsranger.com&rnum=1
there is little room for surprises.

> Look, fact is that if you need to add additional phone numbers you
probably
> will need to (and *should*) break out the phone numbers to another table
in
> most modern database systems today.
>
> Given the above reality of adding another table, then most of the existing
> reports and certainly most of the data entry screens will have to be
> modified to take this fact into account. Simply making a relational view
for
> those existing reports will not allow you display those additional phone
> numbers without some report modifications.

This is why it is called "backward compatible" view. A table renamed into a
backward compatible view would be showing one phone only as in the original
design, and none of the legacy applications would have to change. Then you
slowly start changing application code to leverage new schema and display
additional phone numbers.

> I am only stating that in today's marketplace, adding those additional
phone
> numbers generally takes WAY less modifications to the application side in
a
> MV system then what most modern sql systems require. This is assuming we
do
> add another table. If one simply adds a few new columns, then
yes...usually
> nothing needs to be changed in either type of system. (but in a MV system,
> the existing code and applications will actually now search for the new
> additional phone numbers without modification. You may get this with some
> relational views...but it is not the norm).

Sorry, but this is a fairy tale. You can add an attribute "home", "work",
the time period availability, etc so that changed business requirements
would force you to change the application logic.


Albert D. Kallal

unread,
Oct 14, 2003, 2:40:13 PM10/14/03
to
"Mikito Harakiri" <mikha...@iahu.com> wrote in message news:%hXib.37

> This is why it is called "backward compatible" view. A table renamed into
a
> backward compatible view would be showing one phone only as in the
original
> design, and none of the legacy applications would have to change. Then you
> slowly start changing application code to leverage new schema and display
> additional phone numbers.

Yes, my point exactly. Existing reports and screens will NOT show those
additional phone numbers. In a MV system, those additional phone numbers
will show in reports without modifications.

> > nothing needs to be changed in either type of system. (but in a MV
system,
> > the existing code and applications will actually now search for the new
> > additional phone numbers without modification. You may get this with
some
> > relational views...but it is not the norm).
>
> Sorry, but this is a fairy tale. You can add an attribute "home", "work",
> the time period availability, etc so that changed business requirements
> would force you to change the application logic.

Actually, in a MV system you will find that existing queries that search for
a phone number will now actually include the new numbers in the search.
Further, reports that display phone numbers will now display those
additional phone numbers. In a far greater number of cases no application
logic needs to be changed. However, as Paul has pointed out in this thread,
as we start to talk about specific vendors and implementations in the market
place, we are getting off topic for the .theory newsgroup.

You can read what I mean about the phone number example at:

http://www.attcanada.net/%7ekallal.msn/Articles/fog0000000006.html

--
Albert D. Kallal (MVP)

Anthony W. Youngman

unread,
Oct 14, 2003, 2:26:19 PM10/14/03
to
In article <DxPib.92732$pl3.2925@pd7tw3no>, Albert D. Kallal
<NOOSSPA...@msn.com> writes

>Let assume we have the classic invoice. That means a bunch of fields like
>date, time, customer, method of shipping etc. (you know...the whole deal
>here). The other thing you need of course is the invoice details. (the
>classic related child table with stuff like product number, quantity,
>description, unit price etc). In MV land, that "set" of invoice details is
>defined in the dictionary. The result of this MV set is a number of RI
>constraints for free:

Look at it this way - a single "entry" in a MV system is one ENTIRE
entity as seen in a relational "entity view".

So you can't muck about with part of an entity without making sure that
the entity exists first :-)

Cheers

Anthony W. Youngman

unread,
Oct 14, 2003, 2:41:14 PM10/14/03
to
In article <Xns9414660E34356...@206.127.4.25>, kevin
zollinger <ke...@mailsoap.com> writes
Applied Maths? Like Newton's - it breaks when you most need it to work
(and yes, I'm aware Mr Bad... is unlikely to read this as it's just cdp
:-)

Cheers,

SixFtWabbit

unread,
Oct 14, 2003, 3:08:09 PM10/14/03
to

> 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.


Mikito Harakiri

unread,
Oct 14, 2003, 3:32:34 PM10/14/03
to
"Albert D. Kallal" <NOOSSPA...@msn.com> wrote in message
news:hqXib.97458$pl3.65922@pd7tw3no...

> Actually, in a MV system you will find that existing queries that search
for
> a phone number will now actually include the new numbers in the search.
> Further, reports that display phone numbers will now display those
> additional phone numbers. In a far greater number of cases no application
> logic needs to be changed.

What if you don't want certain phone types to be displayed? Hint: security.


kevin zollinger

unread,
Oct 14, 2003, 3:50:40 PM10/14/03
to
"Anthony W. Youngman" <thew...@nospam.demon.co.uk> wrote in
news:ZvDBAlBKNEj$Ew...@thewolery.demon.co.uk:

[snip]

> Applied Maths? Like Newton's - it breaks when you most need it to work
> (and yes, I'm aware Mr Bad... is unlikely to read this as it's just
> cdp
>:-)

I cross post only when its appropriate, and its never appropriate! :)

Mikito Harakiri

unread,
Oct 14, 2003, 4:03:27 PM10/14/03
to

"SixFtWabbit" <dragoni...@cox.net> wrote in message
news:HQXib.34578$La.22247@fed1read02...

That is the most valuable post in the thread, but could you please be more
specific with references? Googling "arithmetic algorithm triad" and alike
leads nowhere.


SixFtWabbit

unread,
Oct 14, 2003, 4:43:06 PM10/14/03
to
Something that I can only reference by my conversations with many of the
"old timers" that have been in the mv model since it's inception. "Triad",
from what I understand, was invented by Don Nelson and the name was coined
by him. (look at the WITHIN modifier and the V correlative in the original
ENGLISH doc). Mr. Nelson's orignal notes are floating around but I have not
seen them. (Jon, have you? Frosty, have you? Chandru, have you?)

"Mikito Harakiri" <mikha...@iahu.com> wrote in message

news:BMYib.43$It5...@news.oracle.com...

cmurthi

unread,
Oct 14, 2003, 4:54:32 PM10/14/03
to
No, sorry. Maybe Henry has a copy of the original document. The triad
term was used iirc and the document was pretty formal though opaque. Chandru

Albert D. Kallal

unread,
Oct 14, 2003, 5:05:17 PM10/14/03
to
"Mikito Harakiri" <mikha...@iahu.com> wrote in message
news:DjYib.42$It5...@news.oracle.com...

Sure, no doubt that we would have to come up with a solution for the above.
However, you would have to deal with this problem in either system in some
way anyway. I mean, yea, sure lets add another column and place a yes/no
value in the field if it is to be displayed. This would mean that old code
would have to be modified to take into account this extra requirement.
However, once again implementing this extra requirement is going to be easer
in a MV environment in place of splitting out the data to another table. If
we already have this extra related table in the sql system, then I would
certainly say that there is probably no difference in the effort in either
system to implement the above feature.


--
Albert D. Kallal

Bob Badour

unread,
Oct 14, 2003, 6:07:34 PM10/14/03
to
"Albert D. Kallal" <NOOSSPA...@msn.com> wrote in message
news:L0Xib.97304$pl3.38040@pd7tw3no...

> "Bob Badour" <bba...@golden.net> wrote in message news:bwednXYN6o7DpRGiU-
>
> > With all due respect, you do not yet understand normalization. A
relation
> > with attributes for each of a main voice phone, a fax number, a cell
> number
> > and a modem might be in 5NF.
>
> Yes, it *might* be. And then again, it might not be? Thus, I don't
> understand your point here?

Without full knowledge of all the business requirements, it is impossible to
determine the level of normalization of a relation. Having two or more
attributes drawn on a phone number data type says nothing about the level of
normalization. As such, a relation might have attributes for each of the
numbers mentioned above and be fully normalized contrary to your earlier
assertion.


> 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.


Bob Badour

unread,
Oct 14, 2003, 6:11:40 PM10/14/03
to
"Albert D. Kallal" <NOOSSPA...@msn.com> wrote in message
news:hyZib.97745$6C4.7539@pd7tw1no...

I had hoped the books I sent you would improve your thinking. Sadly, it
appears your ignorance is incorrigible.


Bob Badour

unread,
Oct 14, 2003, 6:17:12 PM10/14/03
to
"SixFtWabbit" <dragoni...@cox.net> wrote in message
news:HQXib.34578$La.22247@fed1read02...
>

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?


Anthony W. Youngman

unread,
Oct 14, 2003, 6:18:40 PM10/14/03
to
In article <3F8C6288...@quest.with.a.w.net>, cmurthi <xyzcmurthi@qu
est.with.a.w.net> writes
iirc they've disappeared. When Dick was around they were in a filing
cabinet somewhere apparently. They don't seem to have been since (as
evidenced by past conversations on cdp)

Shame :-(

Mike Preece

unread,
Oct 14, 2003, 6:45:08 PM10/14/03
to
"Bob Badour" <bba...@golden.net> wrote in message news:<57adnaV4RLk...@golden.net>...
[snip]

> Few people want needless
> complexity without benefit.


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

Mike Preece

unread,
Oct 14, 2003, 6:57:36 PM10/14/03
to
Cool post Anthony!

"Anthony W. Youngman" <thew...@nospam.demon.co.uk> wrote in message news:<Ko91hKAyFDj$Ew...@thewolery.demon.co.uk>...

frostalicious

unread,
Oct 14, 2003, 7:15:35 PM10/14/03
to
>> "SixFtWabbit" wrote:
>>> 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.

> "Mikito Harakiri" replied:


>> That is the most valuable post in the thread, but could you please
>> be more specific with references? Googling "arithmetic algorithm
>> triad" and alike leads nowhere.

SixFtWabbit answered:


> Something that I can only reference by my conversations with many of
> the "old timers" that have been in the mv model since it's inception.
> "Triad", from what I understand, was invented by Don Nelson and the
> name was coined by him. (look at the WITHIN modifier and the V
> correlative in the original ENGLISH doc). Mr. Nelson's orignal notes
> are floating around but I have not seen them. (Jon, have you? Frosty,
> have you? Chandru, have you?)

I remember seeing the originals, a long, long time ago. In pencil, on that
green paper with the graph squares on the back, IIRC. Written as flow
charts, with little ovals with all the original mode names: MD10, etc.

I remember Dick looking for the orig's in the later years, but never recall
hearing that they were found. =`:^< Maybe John Bohner has an idea?

-- frosty


Mike Preece

unread,
Oct 14, 2003, 7:22:09 PM10/14/03
to
(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.

Ken North

unread,
Oct 14, 2003, 8:32:01 PM10/14/03
to
> 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.

Tony Gravagno

unread,
Oct 14, 2003, 8:37:35 PM10/14/03
to
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
T...@idratherbecodingNebula-RnD.com

Ken North

unread,
Oct 14, 2003, 8:51:03 PM10/14/03
to
> 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

Bob Badour

unread,
Oct 14, 2003, 9:07:21 PM10/14/03
to
"Mike Preece" <mic...@preece.net> wrote in message
news:1b0b566c.03101...@posting.google.com...

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


Jeffrey Kaufman

unread,
Oct 14, 2003, 9:16:38 PM10/14/03
to
Thank you, Tony, for your insight, clarity, and civility.

Your summation should pretty well conclude this thread.


"Tony Gravagno" <g6q3x9...@sneakemail.com.invalid> wrote in message
news:e62povc3e4i689717...@4ax.com...

(Patrick Latimer)

unread,
Oct 14, 2003, 10:59:23 PM10/14/03
to
Bob Badour wrote:

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

Ed Sheehan

unread,
Oct 15, 2003, 1:12:17 AM10/15/03
to
(Patrick Latimer)" <"(Patrick Latimer) wrote:
<snip>

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

What's left? :-)

Ed


Albert D. Kallal

unread,
Oct 15, 2003, 4:00:31 AM10/15/03
to
"Bob Badour" <bba...@golden.net> wrote in message news:oMGdnX_xJpsFqhGiU-
> 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.

Bob Badour

unread,
Oct 15, 2003, 8:26:24 AM10/15/03
to
"(Patrick Latimer)" <"(Patrick Latimer)"@comcast.net> wrote in message
news:DeSdnbCvC4x...@comcast.com...

> Bob Badour wrote:
>
> > "SixFtWabbit" <dragoni...@cox.net> wrote in message
> > news:HQXib.34578$La.22247@fed1read02...
> >
> >>>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.

Perhaps, you comprehend less of the catholic faith than you think if you
believe councils define no dogma.


Mike Wooding

unread,
Oct 15, 2003, 9:50:57 AM10/15/03
to
"Albert D. Kallal" <NOOSSPA...@msn.com> wrote in message
news:z87jb.101186$9l5.78520@pd7tw2no

<Some snippage>

> 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]


Mikito Harakiri

unread,
Oct 15, 2003, 12:11:50 PM10/15/03
to

"Ken North" <kno...@deletethis.yahoo.com> wrote in message
news:bmi5l2$kn4$1...@ngspool-d02.news.aol.com...

Excuse me, but this looks like yet another state transition theory. How does
it relates to databases?


delusion

unread,
Oct 15, 2003, 12:39:45 PM10/15/03
to
seun...@inaira.com (Seun Osewa) wrote in message news:<ba87a3cf.03101...@posting.google.com>...
> dw...@iserv.net (Dawn M. Wolthuis) wrote in message news:<6db906b2.03101...@posting.google.com>...
> > "Anith Sen" <an...@bizdatasolutions.com> wrote in message news:<b56ib.32551$mQ2....@newsread1.news.atl.earthlink.net>...
> > > BTW, it is hard to provide quick references to rectify every conceptual
> > > misunderstanding and counterpoint each fallacious MV arguments. Generally,
> > > it just warrants the invocation of the Principle of Incoherence.
> > >
> > > If the "XML doc specifiers" are proposing an alternative data model, yes,
> > > they are taking a path, which was proven wrong already, but they aren't
> > > aware of it yet.
> >
> > PROVEN? I would LOVE to see the proof -- I have begged to see a
> > proof. There IS NO PROOF OF WHICH I AM AWARE or can you point me to
> > one? In fact, persisting data with a model that is influenced by an
> > understanding of language (since the idea is that we not just store
> > it, but also retrieve it again) does employ a more complex structure
> > by some measures (mathematical relations, for example) but it does so
> > for a reason and, as I understand it, there is emperical evidence from
> > contests performed over a decade ago (so we need to do these again) to
> > show that systems that persist data with XML-like models (that what
> > PICK is) provide a more agile development environment.

> >
> > Coming from a DBMS background, I was surprised to find that from my
> > experience, my developers who used PICK-based systems also had a more
> > agile environment for maintaining applications over time. That,
> > however, is anecdotal evidence and therefore requires some emperical
> > evidence or mathematical proof before I claimn that I KNOW it to be
> > the case that it is always better to persist data outside of the RDBMS
> > model.
> [.....]
>
> Ok, I think what we need to do is come up with an illustrative
> example. A particular simple application which Dawn can use to
> demonstrate the advantages of the MV model. And then our knowledgeable
> relational model advocates can use the same example to "debunk" her
> claims. And perhaps I can use it to show how some of my PlayDB
> concepts might prove useful.
>
> Dawn is not thinking in terms of "Large Shared Data Banks" that must
> survive several generations of applications. She is thinking in terms
> of productivity of application developers, who are also responsible
> for the data model. The relational model is designed for flexibility
> and data that is used for a long time by a host of different
> applications.
>
> So, in summary, how about a sample application which we use to compare
> the models?
>
> Seun Osewa

only advantage of the multivalued model is it's multivaluedness
the fact that it's so explicit
i'ts part of the model
the model is multivaluedness
and the other thing
it's the sameness of information
there isn't any difference between information in the multivalued model
the other platforms they try to wrap up information in some way its like
packaged to look like something
the data is plain within the multivalued model what you see is what you get
the software driving it is secondary
the links are so much more important
within the multivalued model data has more meaning
data has value

(Patrick Latimer)

unread,
Oct 15, 2003, 5:09:26 PM10/15/03
to
Bob Badour wrote:

> "(Patrick Latimer)" <"(Patrick Latimer)"@comcast.net> wrote in message
> news:DeSdnbCvC4x...@comcast.com...
>
>>Bob Badour wrote:

<snip>


>>>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.
>
>
> Perhaps, you comprehend less of the catholic faith than you think if you
> believe councils define no dogma.

No Bob, councils can argue, discuss, agree or disagree. The big guy
declares the dogma, even if they all disagree with him. It's the way
it works. That was my point. You nshould to know how something works
before you argue about it.

Patrick, <;=)

P.S Hey Bob why don't we take this to alt.argue.anything

Tony Gravagno

unread,
Oct 15, 2003, 7:21:29 PM10/15/03
to
"Jeffrey Kaufman" <jeffrey...@sbcglobal.net> wrote:
>Thank you, Tony, for your insight, clarity, and civility.
>Your summation should pretty well conclude this thread.

I doubt it. I forgot to cross-post. Oh well. Great thread, it's
just a shame the academics get warped by religion. Well, the church
used to imprison or kill people who said the world wasn't flat, at
least they don't do that now when we tell them their databases
shouldn't be flat either.

Hey jeff, we miss your joke lists - prune those dupes though... :)
T

Bob Badour

unread,
Oct 15, 2003, 8:59:29 PM10/15/03