This is the talk page for discussing improvements to the Network model article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||
|
![]() | Daily pageviews of this article
A graph should have been displayed here but graphs are temporarily disabled. Until they are enabled again, visit the interactive graph at pageviews.wmcloud.org |
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.
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.
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:
Darkov 06:19, 28 Mar 2005 (UTC) Bold textwhy you didn't discuss the 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)
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)
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)
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)