Network Database

A type of database that was fairly common in the 1960's, but was eventually replaced by RelationalDatabases without much of a fight.

It is alleged that ObjectOrientedDatabases resemble NetworkDatabases in a way that is too close for comfort. The downfall of ObjectOrientedDatabases with regard to stalling market share in the late 1990's is sometimes attributed to drawbacks of NetworkDatabases . In other words OODBMS have not overcome the flaws of NetworkDatabases, according to this view.

One way to define a NetworkDatabase is a network of DictionaryDataStructures. IOW, a pool of dictionaries that may point to one another. This differs from a RelationalDatabase partly in that the highest and primary object is the dictionary instead of a "table" (relational). Of course vendors had their own variations on this theme, some with quasi-relational features and perhaps some HierarchicalDatabase influenced features. Another common feature is "exposed indices". One could select an index and "surf" on it (next, previous, first, last) to retrieve dictionaries (records) in the order of the index. (I have not found any "formal" theory description. This definition/description is just based on specimen observation.)

Not to be confused with a "LAN-Database" or "WAN-Database". "Network" is a data structure, not a matrix of physical wires in this context.

Using database cursors is sometimes seen as a throwback to NetworkDatabases because one is "surfing the index(es)". Relational theory is suppose to hide the existence of indexes (or the lack of) from queries and DB users. For some operations, such as open-ended browsing of tables, I *like* cursors though. Bummer.

There is a difference between capturing and maintaining data on the one hand and presenting and manipulating it on the other. The former is without a question the responsibility a DBMS, and the latter part of the 'application' of that information. A RDBMS doesn't require cursors as part of the data model, rather provides them to clients who don't want to program in Prolog. A cursor doesn't have to run across an index. It can be as arbitrary as the select statement that generated it. A network database requires some sort of index surfing as part of the data model.

My understanding of the big disadvantage of NetworkDatabases was that the navigation paths between entities were determined at database design time; you as a programmer then just followed those paths ("the programmer as navigator"). If the particular navigation path you application turns out to need was missing, you either had to change the database or implement the logic for such a query in your application. Whereas in relational databases, you can use any columns of any tables for a join, whether the database designer thought of the need for such a query or not.

(Can anyone of those who have been around that long correct or confirm the above?)

See CalculatedRelations

The same goes for objects. For example, let's say you are given two components to work with, Person and City, and you can't change their source code. The pre-determined "navigation paths" are person.getCity() and city.getPersons(). Now marketing comes up with a great new promotion idea, where they award prices to persons who are named like a city (I know, it's strange, but that's marketing for you). Problem is, there is no person.getPersonsNamedLikeACity(), so you have to go and implement the logic for such a search outside of the Person and City objects. Contrast with relational DBs, where you just say "select * from person, city where person.name = city.name", without touching the database or implementing searching logic in your application.

Note that when you "just say 'select...'" you _are_ "implementing searching logic." -- DanielBarclay?

{WRT to the SQL example, you may want to consider using a LIKE clause of some sort for near matches. Some DB's even have SoundEx() operations.}

You seem to be confused about how objects and classes are used. In the example you give (supposing that indeed I can't change the code of the components of the application I'm maintaining) then one solution could be to introduce a new class, say Promotion, that has the responsibility for find instances of class Person with the same name as an instance of class City. That's perfectly respectable, more respectable that taking Person and bolting on some arbitrary new responsibility in fact. Why would you think otherwise?

If there was a good reason to roll the responsibility into an existing class then we might expect to be able to extend Person using inheritance without changing Person itself.

Several responses:

"You seem to be confused about how objects and classes are used." - Gee, thanks. I'm pretty much of an OO-head myself, so where's that coming from? Was it something I said or did you see an argument against OO, immediately assumed it must be coming from a certain person, and projected what you knew about said person's OO knowledge onto me?

It was something you said. Specifically, the suggestion that instances of person might have a method to do the required search. That would bee a goofy thing to do, and is the sort of thing I see done a lot by OO neophites [Removed personal digs]. If that isn't what you meant, you might want to revise your words to make them clearer. Actually, with your permission, I think we should try to refactor the whole page.

"one solution could be to introduce a new class..." ...outside of the city and person objects. Yes, that's what I said, wasn't it?

I don't know, you didn't mention classes. Where else than in classes would I put that functionality in an OO solution?!?

My point was that in OO, you either have to touch the "database" (change or extend Person with getPersonsNamedLikeACity(), which, as you say, looks quite bolted-on), or you have to implement query/searching logic in the "client" of the database (Promotion), which is also smelly. With a relational model, you have to do neiter.

You do have to write the new query though. With a smart choice of OO language and OO persistance technology the code to do the search might not be any more complicated than the query (might in fact look almost identical to it), so...what's you point again? That in order to be able to use the query, you'd have to ad it as a meethod on one of the databases' classes, hence change the database design.

When the persistance technology offers such relational-like querying, there is no disadvantage that I can see. In that way, many OO persistance solutions "embraced and extended" relational technology - after all, matching up the attributes of two sets of entities to establish an relationship is pretty relational (and practical) thing to do. If such features are missing (think serialized object graphs, think XML), though, the designer has to watch out for said "predefined navigation path trap", and plan for change.

Relational databases had superior query abilities by most accounts. Nobody appeared to challenge the downfall of NetworkDatabases at the time (that I know of), until OO revived interest in similar techniques in the late 80's. You also imply that a OODBMS is being used. If that is the case, then why do you still need Person classes in your application code? Shouldn't the schema be defined and managed in only one place if we obey OnceAndOnlyOnce? Just a question. I am a believer in DatabasesAreMoreThanJustPersistence?, I would note. I don't necessarily question that a NetworkDatabase can have relational queries done on it, but I suspect that it's implementation and tools must be optimized for either one model or the other, and not both at the same time.

By the way, objects may be a step back to network databases, but XML goes even further, back to hierarchical... (XmlSucks)

And JQuery is NetworkDatabase reborn? Odd. At this pace, COBOL will be the next big thing. Maybe security concerns will drive the market back into mainframe techniques and languages, eh? Buy stock in COBOL and JCL.

{Wow. How do you get from JQuery to NetworkDatabase? JQuery is a library of Web browser Javascript goodies, with -- among all sorts of other stuff -- mechanisms for retrieving parts of an HTML document in a vaguely query-like fashion -- hence the name. There's nothing remotely NetworkDatabase-like about it, unless you consider an HTML document to be a NetworkDatabase.}

Let me rephrase it to be the "query part of JQuery".

{It's a "query part" to the same extent that a fully-qualified domain name is a "domain query", or a file path is a "file query", or a regular expression is a "text query". I don't think the RelationalModel would be appropriate for those, and none of them involve a NetworkDatabase.}

It has query abilities beyond just basic tree-oriented queries; network-like.