Talk:Network model

untitled

I think Network model can be represented by one big table.

Think of a big table. Every record is being placed in the same Table. Not depending on what they are: customers, letters, computers, cars, needles, needle or atom - put them as records to the one Table. Imagine that whenever you enter a new record,

a new field with the same value created automatically.

Thus any and every record can be compared another record.

Not every record can be described in terms of all fields.
 A computer cannot be described by cars,
  so the cell where the record "computer" and the field "car" intersects, is empty or having a value of incomparability.

Depending on what fields what records can describe, data can be sorted. Such Table is maximum flexible, because every new information always can be put to it without losing any information.

Such table can always be broken down to many tables by sorting the records to "customers", "computers" etc.

Various possible hierarchies could also be generated according to the relations of the records.

This kind of table would have unlimited comparation capability, because every element of it would be possible to compare to any other element or any group of elements could always be possible to compare to another group of elements with respect to one or more criteria. Criterium itself would be a record.

---

This page is very confusing.

For example, it says, "A network model database management system has a more flexible structure than the hierarchical model or relational model, but pays for it in processing time and specialization of types."

However, nowhere in the text does it say how it is structured, or why it is more flexible.

Then, it jumps into talk about neural networks. This seems pre-mature to me. We should understand what a network model database is, before we hear about neural networks.

Neural networks are not a database

The discussion on neural networks is ok, I suppose, but it's not to do with databases. A database is not composed of processing units, although a database might describe the connection between them.

A network database has to do with the method of structuring and locating data. Hierarchical databases are a special case of network database in which all the navigation directions are tree-shaped, starting from a single root. Generally network data models have data entities that are connected to other data entities systematically, much like Wikipedia (and, much like browsing through Wikipedia via links, similar data could be located "near" each other but not be connected, and therefore not be found in a network search). When a network model is used the data management system must have some understanding of the data (or a way to decode it) so that it can understand which data are meant to be connected and how to search through the connections.

The relational model came about in part because it seemed to some that you should be able to define what you want rather than how to find it, and let a general database management system figure out where it is rather than write a specific program that understands the meaning of the data to manage it. This arose both from a concern that a lot of the navigational data storage was redundant to the purpose, and from the feeling that navigational databases were too prone error and "mapping out" some of the data from the network. A relational system aggregates data of similar type into larger collections and follows its own strategies for sifting those collections for items that match the declared search criteria. This is analogous to using the Wikipedia search command - a single process might find any page but doesn't understand the context of the data, so pages that are not linked to each other may be returned.

An advantage of a network database that is purpose-built for an application is that the connections between data are explicitly part of the system. It can be designed to make complex relationships very quick to resolve, however searches about relationships that were not designed into the network can be extremely difficult to perform, and changes to the network have to be performed very carefully to preserve its integrity.

Removal of Irrelevant Text and Improvements

This article contains a fair bit of text irrelevant to the topic, namely the neural network text and related discussion. It is not related to network databases in a technical sense.

Things that need to be added:

• a broad description of the network data model (started)
• relationship between the network data model and relational and heirarchical (started)
• some data examples
• some references to products that use the model
• some historical information (started)

Darkov 06:19, 28 Mar 2005 (UTC) Bold textwhy you didn't discuss the model

the demise of the network model

"Secondly, it was eventually displaced by the relational model, which offered a higher-level, more declarative interface. Until the early 1980s the performance benefits of the low-level navigational interfaces offered by hierarchical and network databases were persuasive for many large-scale applications, but as hardware became faster, the extra productivity and flexibility of the relational model led to the gradual obsolescence of the network model in corporate enterprise usage."

The demise of the network model offers some speculative opinions. Initially, productivity and flexibility were offered as reasons to switch to DB2 and other relational models available on the personal computer, but the learning curve for programmers and students limited productivity in most enterprises. Relational databases have not displaced the hierarchical model nor the network model in many enterprises. Relational model databases coexist with transaction-processing databases like IMS, IDMS and DL/1, and these are typically used as informational repositories to assist business intelligence and analysis. Because relational model is the predominant offering for network servers running Unix and Windows, web presentation layers typical cache data via relational database models which forward data (in mainframe environments) to traditional database structures like IDMS, IMS and ADABAS.

In fact, for large volumes of data, the network and hierarchical models remain very efficient and effective modes of transaction processing in real time, real fast. And, there are now a number of tools to take these inverted-file, network and hierarchical databases to the presentation layer via Java API and .Net API calls. —Preceding unsigned comment added by 99.206.95.130 (talk) 01:21, 7 February 2008 (UTC)

"In fact, for large volumes of data, the network and hierarchical models remain very efficient ". While that is undoubtedly true, it's also true that very few new applications are built using these models, and I think that the article fairly represents the broad consensus about the reasons why this happened. It's very hard to find hard evidence for this kind of analysis - it's based much more on the accumulated evidence of lots of small events reported in the press over a long period - but I think the analysis is fair. Mhkay (talk) 14:13, 9 February 2008 (UTC)

I agree with 99.206.95.130. I use hierarchical databases with MDSPlus, software which is apparently prevalent and which recent projects implement. The article gives readers the impression that the network model replaced the hierarchical model, and the relational model replaced the network model. I've never used a network database but know this is false because I (and many others) use hierarchical databases. The article strikes me as largely unsupported, so unless citations are provided for these claims, I propose to remove them. Also, filesystems are hierarchical databases and are still very common.  dmyersturnbull  ⇒ talk 00:47, 27 June 2009 (UTC)

A filesystem is a hierarchical database? If you think that, then you have seriously misunderstood what a hierarchic database is. It's a database in which the graph of relationships between types of records forms a hierarchy. A filesystem has no types and no relationships, so it's not a hierarchic database. For that matter, it's not even a database. Mhkay (talk) 23:51, 28 June 2009 (UTC)

A filesystem is a database by every definition of the word. If you seriously contest that, then I suggest you propose that on the Filesystem page:

"a file system is a special-purpose database for the storage, organization, manipulation, and retrieval of data."

and on the Database page:

"A database is a structured collection of records or data that is stored in a computer system."

and then block Princeton WordNet:

"an organized body of related information"

Filesystems are flat and have no physical understanding or representation of hierarchy, but operating systems artificially present one to their users.

I'm sorry, but most would find it clear that you're mistaken. Anyways. My original point was that hierarchical databases are not dead and that the article conveys that false impression.  dmyersturnbull  ⇒ talk 00:50, 30 June 2009 (UTC)

It's true that the definition of database has become very diluted over time. I've even heard people refer to a simple spreadsheet as a "database". But nearly all definitions say that to qualify as a database, the data has to be structured and/or managed. A filesystem is not structured (it imposes no structure on the data and has no knowledge of the structure), and it offers no assistance in managing the data. In terms of layers of added value, it's one level above raw disk, but well below what people expect of a database (in the computer science sense and in industry, I'm not talking here about popular or journalistic misuse of the term). Mhkay (talk) 11:56, 30 June 2009 (UTC)

I suppose that's reasonable. When I use the term with regard to computer science, I don't intend to include filesystems. I wish determining the proper definition was easy, but prescription seems relevant—and prevalent.

A filesystem format is merely a standard for organizing data. If a filesystem follows that standard, I think it should be considered organized and structured.

Anyways, that the article portrays a false notion was my sole intended point. Perhaps we can manipulate this sentence:

Until the early 1980s the performance benefits of the low-level navigational interfaces offered by hierarchical and network databases were persuasive for many large-scale applications, but as hardware became faster, the extra productivity and flexibility of the relational model led to the gradual obsolescence of the network model in corporate enterprise usage.

to convey the prevalence of usage in science; corporate enterprises are not the only database users. My other concern is the lack of citation.  dmyersturnbull  ⇒ talk 20:00, 30 June 2009 (UTC)

The diagram

I think the diagram (preventive maintenance, sealants etc) is very unhelpful. Is it a diagram of types or instances? It's hard to tell. There's no explanation, no reference to it in the text, no indication as to what it's trying to say. A picture is not always worth a thousand words.

Mhkay (talk) 15:15, 28 March 2009 (UTC)

I agree. In fact, it's nearly a pure hierarchical diagram, and doesn't show the features of a network model. Eight40 (talk) 15:16, 15 November 2012 (UTC)

Confusing

In particular, how is this different than the navigational database model? It seems the same Turing lecture by Bachman is cited in both, with no mention in the body of either? Are they the same (so articles should be merged) or different? Or is one just a model and the other a database that implements it? Probably then again should be merged into one article that is coherent and better sourced. W Nowicki (talk) 00:11, 4 September 2013 (UTC)

The Codasyl database standards were in two parts: a data model (the Codasyl or network data model) consisting of records and "sets" (1 to many relationships); and navigational data manipulation language. The "programmer as navigator" paper is primarily about data manipulation, and describes modes of access in databases in terms of two primary patterns: finding records by key, and following relationships (this must all be seen in the context of the sequential tape-based processing that was dominant at the time). Network databases of course support both these access patterns, but they are not unique to network databases.

Really, there is no such thing as a navigational database, there is only a navigational DML (or API). Although declarative access languages like SQL and XQuery are much more fashionable, navigational APIs live on in libraries like JQuery. Mhkay (talk) 22:42, 4 September 2013 (UTC)