Jump to content

User:Hyeonjungko/GraphDatabases

From Wikipedia, the free encyclopedia
< User:Hyeonjungko
This is an old revision of this page, as edited by Hyeonjungko (talk | contribs) at 23:18, 21 October 2018 (minor change in overall description). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Copied text has been bolded.

Graph Database

In computing, a graph database (GDB) is a database that uses graph structures for semantic queries with nodes, edges and properties to represent and store data. A key concept of the system is the graph (or edge or relationship), which directly relates data items in the store representation of relationships between nodes of data. The relationships allow data in the store to be linked together directly, and in many cases retrieved with one operation.

This contrasts with relational databases that, with the aid of relational database management systems, permit managing the data without imposing implementation aspects like physical record chains; for example, links between data are stored in the database itself at the logical level, and relational algebra operations (e.g. join) can be used to manipulate and return related data in the relevant logical format. The execution of relational queries is possible with the aid of the database management systems at the physical level (e.g. using indexes), which permits boosting performance without modifying the logical structure of the database.

Graph databases are part of the NoSQL databases first created to address limitations of the existing relational databases. Since Edgar F. Codd's 1980 paper on the relational model[1], relational databases have been the de-facto industry standard for large-scale data storage systems. However, relational model's requirement of a strict schema and data normalization imposed limitations on how relationships can be queried[2]. The increasing amount of data needed to be processed became an additional problem posed by the relational model.

Graph databases, by design, allow simple and fast retrieval[citation needed] of complex hierarchical structures that are difficult to model[according to whom?] in relational systems. Graph databases are similar to 1970s network model databases in that both represent general graphs, but network-model databases operate at a lower level of abstraction and lack easy traversal over a chain of edges.

The underlying storage mechanism of graph databases can vary. Some depend on a relational engine and “store” the graph data in a table (although a table is a logical element, therefore this approach imposes another level of abstraction between the graph database, the graph database management system and the physical devices where the data is actually stored). Others use a key-value store or document-oriented database for storage, making them inherently NoSQL structures. Most[according to whom?] graph databases based on non-relational storage engines also add the concept of tags or properties, which are essentially relationships having a pointer to another document. This allows data elements to be categorized for easy retrieval en masse.

Retrieving data from a graph database requires a query language other than SQL, which was designed for the manipulation of data in a relational system and therefore cannot “elegantly” handle traversing a graph. As of 2017, no single graph query language has been universally adopted in the same way as SQL was for relational databases, and there are a wide variety of systems, most often tightly tied to one product. Some standardization efforts have occurred, leading to multi-vendor query languages like Gremlin, SPARQL, and Cypher. In addition to having query language interfaces, some graph databases are accessed through application programming interfaces (APIs).

Background

Usage

In Comparison: Relational Databases

Relational models enforce heavy data normalization in order to guarantee consistency. Problems arise with when there is a need to form complex relationships between the stored data. Although relationships can be analyzed with the relational model, complex queries performing many join operations on many different attributes over several tables are required.

References

  1. ^ Codd, E. F. (1970-06-01). "A relational model of data for large shared data banks". Communications of the ACM. 13 (6): 377–387. doi:10.1145/362384.362685. ISSN 0001-0782.
  2. ^ Jaiswal, Garima (2013-08). "Comparative analysis of Relational and Graph databases". IOSR Journal of Engineering. 03 (08): 25–27. doi:10.9790/3021-03822527. ISSN 2278-8719. {{cite journal}}: Check date values in: |date= (help)

Article Evaluation: Graph Database

The article contains decent information. However, the author(s) did not properly cite the sources for most of its work. There is no way for the readers to distinguish between the authors' opinions and facts from proper sources. There should also be more diagrams or images to help the reader understand the concepts of a graph database. The article is not categorized into subcategories to easily search through.

There are unnecessary comments that could be instead replaced with separate Wikipedia links. An example from the article is "that is, roughly relative to the logarithm of the size of the data." Many examples are written in good nature, but repetitive. The contrast between the relational databases and graph databases moves through the same differences with different examples.

Retrieved from "https://en.wikipedia.org/w/index.php?title=User:Hyeonjungko/GraphDatabases&oldid=865130947"