Re: The Nelson-Pick Data Model

"Laconic2" <laconic2_at_comcast.net> wrote in message news:DPCdnYImRJutcRHcRVn-2A_at_comcast.com...
> 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".

If you look at the data as seen through the eyes of a software developer is is eerily like XML in that it is tagged-delimited strings of data. Unlike XML, the tags on not on either side of the data, but on one side only and they are single characters, such as ^253, rather than metadata tags. Also, unlike XML, there is no provision in the products to go down many levels deep in the stuructures, only about 3-4 (depending on how and what you count). Like XML, you can put a document (such as ascii or binary) as a value for an attribute. This is done for documents such as source and object code (which is really byte-code, p-code, for the p-machine virtual machine). Also unlike XML, it is blazingly fast to retrieve data and people other than me can explain why that is, but one reason is that the "relations" are actually functions -- they each have a primary key that is stored in attribute 0 of the relation. The attributes are ordered, more because the metadata describe data and can do so in many different ways, each of which points to the position of the attribute(s) to which is referring. There is no strong typing. You can describe a single attribute with different types (a number or a string) and it will interpret the same string as a number when you ask about the first and a string with the second (for comparisons, etc). Derived data looks to someone in the query language exactly the same as stored data, while to the developer, the data are identified by position and there is no position to be used for updating derived data (since, afterall, they are derived).

> What is the Nelson-Pick model for?

The original purpose was to permit people who were not IT professionals (DP back then), particularly those in the US Army, to be able to query the data. For example, the first use of which I am aware was in Viet Nam for tracking Cheyenne helicopter parts. The people in the field had to be able to ask the database questions and get answers without much training.

> I note that the discussion seems to center on "Pick files". Does this
mean
> that it's a data model for "files" only?

Pick was originally an operating system combined with a "database". UNIX and DOS beat it out for a top spot, with many stories on what happened in the politics of OS's as well as stories about Dick Pick's personality.

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

I looked at definitions of "data model" and they are too varied to say with certainty that many on this list would consider it a data model. But is does provide an alternative way of modeling data to the relational model, so call it whatever. Additionally, when I first saw it after working with IMS for years, I told my (new) staff that it didn't look like a database to me. It looked much more like a series of VSAM files. It predates RDBMS's, but it does have additions to the framework that permit SQL transactions, triggers, logging, and other features found in database management systems. It's mission originally was related to data retrieval and the storage was a means to an end.

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

I don't think of it that way. I think the closest thing to it in some respects is to take an XML document and replace each pair of tags with a single tag that identifies at what level the next value is (is it a new file (relation.function), a new record (like a row, but with nested structures) , a new attribute (aka field), a new value within the current attribute, or a sub-value within the current value, for example). Now persist this all as a string and maintain it similarly. You can view each portion of this string in whatever ways you want -- work with dates as being of type date, or if you are really skewed, work with them as numbers or strings.

> The above sounds, to me, to be only trivially different from the
> hierarchical model.

Having worked with IMS and PICK there are significant differenences, but perhaps not fundamentally in the model. If you are working with one "function" (no one in the pick world calls them that -- that is simply their mathematical shape) and you want data from another function, you have a foreign key and you declare within this function that there is a new name of an attribute. You then "code" that declaration as finding the data in another function, using your foreign key and the location of the data in the other function. So, instead of views, you have derived data which appear to a function as if it were stored. That is similar to views appearing to the user as if they were base relations, however, it is done at an attribute level rather than set level.

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

IMS still thinks in terms of schema that combine various tables -- more of a view-like approach. It is also more of a strongly-typed database and more of a database management system than is Pick. IMS feels more like Oracle than it feels like Pick -- yet another of my non-mathematical statements, but this is a non-mathematical thread, so please forgive.

> Is the Nelson-Pick model easy to learn and use?

Yes. However, it is old and feels old.

> Is there less to learn?

Yes.

> Are there fewer ways to misuse the power of the
> model than there are in, for instance, the Relational model?

No, many, many more. Bad Pick implementations are likely worse than bad RDBMS implementations, but good ones sing.

> Are there
> obvious pitfalls? Are there well known ways to avoid them?

Yes and yes ;-)

> Is the data model intentional or accidental?

Intentional for being able to retrieve data -- for queries, accedental in that there were likely no discussions about how the data ought to be modeled. It was about how it needed to be stored in order to be retrieved handily.

> 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"?

Not at all -- only the querying capability and speed/performance were important as best I can tell.

> What kind of interfaces are offered?

I gotta run, but hopefully others will also reply, else more to follow. Cheers! --dawn

> 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?
Received on Sat Nov 06 2004 - 17:02:06 CET