Kingsley Uyi Idehen
4 min readMay 19, 2017

--

Illustration by John O Gorman shared via comment thread

Here’s why:

  • Data is how we represent observation (a collection of Entity Relationships) in reusable form — using natural language as an example, a sentence is an example of a Datum while a paragraph is an example of Data
  • A Database is a document (not an application) that contains a collection of Entity Relationships grouped by Relationship Type (or Relations).
  • Relationship Types (Relations) can be represented in a variety of ways i.e., as Records in a Table (re. SQL world view) or Statement/Sentences grouped by Sentence Predicate (which can be visually represented as a Graph, Network, or Web pictorial)
  • A Database Management System is an Application that provides Data Definition and Manipulation service (this includes Query Languages like SQL, SPARQL, GraphQL, DataLog, Quel, and many others)

It sounds nice to speak of Graph Databases, but in reality this is marketing buzz-phrasing at its worst i.e., it doesn’t bring light to the important issue of understanding data or the real distinctions that exist in the database technology application realm. For instance, a Relational Database Management doesn’t imply SQL Relational Database Management system, that’s just another example of marketing overreach.

Headline perpetuating SQL and Codd’s Abstract Relational Model Conflation

Likewise, the emerging notion of an RDBMS equipped with AI is just contemporary babble for a Deductive Database Management system.

Conclusion 1

Graph Data is like saying “Data Data”. Thus, a Graph Database is like saying “Data Data Document”. That phrase sounds nice to the ear, and the visualization are temporarily appealing, but ultimately it will be revealed as a predictable path to confusion and poor wheel reinvention.

Initial Conclusion Rebuttal

That said, I revisited Wikipedia and related literature about the Relational Model and Codd’s 12 Rules (based on a zero-index meaning 13) that are contradictory, thereby providing actual basis for the emerging Relational Database and Graph Database (NoSQL) dichotomy.

Relational Model

The relational model (RM) for database management is an approach to managing data using a structure and language consistent with first-order predicate logic, first described in 1969 by English computer scientist Edgar F. Codd,[1][2] where all data is represented in terms of tuples, grouped into relations. A database organized in terms of the relational model is a relational database. — Wikipedia Entry

Codd’s 12 Rules (by Rule 3 contradiction and basis for Graph Database moniker manifests)

Rule 0: The foundation rule:

For any system that is advertised as, or claimed to be, a relational data base management system, that system must be able to manage data bases entirely through its relational capabilities.

Rule 1: The information rule:

All information in a relational data base is represented explicitly at the logical level and in exactly one way — by values in tables.

Rule 2: The guaranteed access rule:

Each and every datum (atomic value) in a relational data base is guaranteed to be logically accessible by resorting to a combination of table name, primary key value and column name.

Directly excerpted from Wikipedia entry, these 3 rules basically confine the notion of a Relational Database Management System to a Database Management Systems genre where Tuples are in the form of Tables (N-Tuple Relations) comprising Primary Keys. That’s incompatible with the nature of a NoSQL DBMS genre associated with the Graph Database moniker!

Revised Conclusion

To avert confusion introduced by Codd’s 12 Rules a new Graph Database Management genre is indeed justified based on the simple fact that a Database Management System operates on Data represented as Tuples rather than then specific notions outlined in the versions of Codd’s 12 Rules that I’ve found so far in my quest for clarity.

Here’s a simple Database Management Systems (DBMS) breakdown aided by illustrating the nature of Relations — what these systems manipulate via declarative query languages (e.g., SQL or SPARQL).

Generic DBMS
SQL RDBMS “Customer” Relation (Table) Definition — includes a Primary Key Column
RDF Graph Database Relations describing “Customer” Schema — using terms from RDFS Schema and OWL Ontologies

Representing what’s happening with an RDF Database, especially when Linked Data principles are incorporated such that each hyperlink functions as a Super Key, you end up with what’s depicted below.

Original Image Location: https://www.openlinksw.com/data/turtle/general/knowledge-graph-manifestation.png

Related

  1. Relational Model
  2. Relational Database Technology
  3. Understanding Data
  4. About Deductive Databases
  5. About QUEL Query Language
  6. About SPARQL Query Language
  7. About the Structured Query Language (SQL)
  8. About Datalog
  9. About Prolog
  10. Conceptual Graphs for a Data Base Interface
  11. About Conceptual Graphs
  12. Semantics for Interoperable Systems
  13. What is a Knowledge Graph? CORRECTION
  14. What is the difference between a Graph and a Network?
  15. Interactive HTML Document Illustrating Knowledge Graph Components
  16. Faceted Classification in support of Interoperable Ontologies

--

--

Kingsley Uyi Idehen

CEO, OpenLink Software —High-Performance Data Centric Technology Providers.