Re: The Nelson-Pick Data Model

From: Steve Lancour <stevel_at_lancour.com>
Date: Sat, 06 Nov 2004 16:18:24 -0500
Message-ID: <cNednba9VuB_ohDcRVn-jA_at_comcast.com>


Steve Lancour wrote:

> Laconic2 wrote:
> 

>> In the MySQL/PHP thread there was a dialogue in which Dawn responded to
>> erk's precis about what the issues were.
>>
>> I'd like to focus in on the Nelson-Pick model for a little while. I
>> did a
>> quick google search and the first five sites were companies that were
>> selling their expertise for big bucks. That's the sort of thing that
>> Dawn
>> has claimed is less necessary with Nelson-Pick than with Relational.
>> So I'm
>> not interested in the bucks. I'm interested in the bang.
>>
>> What is the Nelson-Pick Model?
>> Is it a subset of the graph (or di-graph) group of data models? Is it
>> essentially a variant on the hierarchical model, or is it inherently
>> different? I'll point out that in the "Database Hall of Fame", it gets a
>> separate entry from "Hierarchical".
>>
>> What is the Nelson-Pick model for?
>> I note that the discussion seems to center on "Pick files". Does this
>> mean
>> that it's a data model for "files" only? Or is it also a data model that
>> serves as a foundation for building a class of DBMS products? In other
>> words, what is it's mission?
>>
>> How does the Nelson-Pick model work?
>> The only discussion in here, about a year ago, seemed to suggest that
>> the
>> implementation was based on the following: inside a pick file is a whole
>> pile of records. Every record has two record pointers in it,
>> followed by
>> data. The first pointer points to the eldest child (or nil). The second
>> pointer points to the next younger sibling (or nil).
>>
>> The above sounds, to me, to be only trivially different from the
>> hierarchical model. But there was a lot of discussion in here about a
>> year
>> ago, and elsewhere on the web, that strongly opines that this is not so.
>>
>> Is the Nelson-Pick model easy to learn and use?
>> Is there less to learn? Are there fewer ways to misuse the power of the
>> model than there are in, for instance, the Relational model? Are there
>> obvious pitfalls? Are there well known ways to avoid them?
>>
>> Is the data model intentional or accidental?
>> At the time the Relational model was first proposed, the idea of a data
>> model was itself something of a novelty. And the idea of proposing a
>> model
>> first, and then building an implementation was a radical departure
>> from the
>> history of the hierarchical model, which was built first, and only then
>> modeled. That's what I mean by an "accidental model".The CODASYL
>> model was
>> proposed, debated and published before ever being implemented. So how
>> central was the Nelson-Pick model of data to the product known as "Pick"?
>>
>> What kind of interfaces are offered?
>> In addition to a query/programming language, is there a data
>> sublanguage?
>> is there an ODBC like connection mechanism?
>>
>> Why do it's proponents like the Nelson-Pick model?
>>
>> Why aren't there more proponents of the Nelson-Pick model?
>>
>>
>>
>>
>>
> 
> Some dated but still useful information can be found at 
> http://www.jes.com/cdp/ .  Particularly interesting (to me, anyway), is 
> the thread at http://www.jes.com/cdp/#117
> 
> Universe and Unidata are two products from IBM based on Nelson-Pick. IBM 
> offers a fair amount of information at 
> http://www-306.ibm.com/software/data/u2/ and a decent overview at 
> ftp://ftp.software.ibm.com/software/data/u2/pubs/whitepapers/nested_rdbms.pdf 
> 
> 
> jBASE, one of the newer players in the Nelson-Pick arena, gives an 
> overview of their system at http://www.jbase.com/products/jbase.html
> 
> Raining Data (the successor to Pick Systems), offers this overview of 
> the model:  http://www.rainingdata.com/products/dbms/d3/d3datamodel.html
> 
> Hope this helps.
> 
> Steve Lancour
> 

Sorry to follow up my own post but the second link I gave above should have been http://www.jes.com/cdp/cdp_t2.html Received on Sat Nov 06 2004 - 22:18:24 CET

Original text of this message