Re: Network databases

Mark D Powell wrote:
> If my memory is correct a networked database could only follow
> predefined paths to the data. Nodes (chunk of data) were chained to
> other nodes using pointers and these prebuilt pointer chains were the
> only paths through the data.
>
> A relational database on the other hand supports accessing data in a
> more flexible manner and does not use predefined pointers to the data
> elements. In theory any column can be used to join to any other
column
> in another table. Obviously you would only do this when the data in
> question was actually the same data values and for performance
reasons
> you would probably add indexes on these columns. But the point being
a
> user can declare any relation that makes business sense at run time
> rather than at object definition time.
>
> I hope this is clean enough. I believe that CA still supports a
legacy
> network database product. The methods being discussed in the OO
world
> may include "fixes" for some of the problems on network db designs of
> the past. For certain types of applications a network design would
be
> very fast as only one IO would be required for each node.
> HTH -- Mark D Powell --

as i've mentioned before ... the hierarchical/network side (bldg. 90) during the 70s against the relational (bldg.28) original relational http://www.garlic.com/~lynn/subtopic.html#systemr

wasn't so much about the information organization ... but about the physical implementation. the hierarchical/network implementations from the 50/60s used direct physical pointers ... while relational used indexes. The direct physical pointers increased human administrative workload ... but was faster for the standard case ... being able to go directly to the desired data. relational reduced the human administrative effort but increased the overhead to get to the desired data and typically doubled the physical storage requirements (both space and processing overhead introduced by the indexes).

the physical pointer implementation vis-a-vis indexes can be independent of the information organization (aka it is possible to do physical implementation using indexes for both hierarchical and network information organizations).

so for NLM at the NIH ... they did card catelogue using BDAM. The "card" was identified by its BDAM pointer (implementation from the 60s). They built indexes of cards by listing the BDAM pointer. So for a specific author .... there was a list of all BDAM pointers (that corresponded to papers/books/etc they had authored). a specific keyword had a list of all the corresponding BDAM pointers. They have 80-some categories that entries were indexed by (author name, keyword, address, subject, etc) ... aka categories of things for which lists of BDAM pointers are built for.

The claim was that sometime in the early '80s they hit the query problem .... a query response involving 5-8 qualifiers could be quite bi-model ... trivial change making the difference between 100,000 responses or zero responses.

Query strategy became returning the number of responses .... rather than the actual responses ... and experimentally trying queries until responses were reasonable number (greater than zero ... but less than thousand)

Basically the various BDAM pointer lists were treated as sets of pointers ... and queries with ANDs, ORs, NOT, ... became and'ing, or'ing, etc the BDAM pointer sets, and then counting the members of the resulting set.

Arriving at a set-size of reasonable number ... then could retrieve the list of set members (and eventually the corresponding "card").

In this case, the BDAM pointers are both the physical pointer as well as analogous to globally unique primary key in relational. So the information organization might be considered relational? Are the various lists of BDAM pointers correspond to normalization? It would appear that the implementation would also work were the globally unique identifier was something other than a direct physical pointer. Received on Tue Jan 11 2005 - 17:14:14 CET