How Neo4j Co-exists with Oracle RDBMS: An Introduction to Graphs

Let’s be honest. No one can argue about the value of the Oracle RDBMS database. Oracle
is and continues to be the mainstay for enterprise applications. However, another – but not
contradictory – truth remains: IT organizations need capabilities beyond what Oracle and
other relational databases provide.

While organizations don’t want to rip and replace Oracle, they do want more: They want
more features in their applications, more data variety, more agility, more speed and, perhaps
most importantly, more ways to rapidly uncover and innovate based on the rich connections
inherent in their data.

opens in new tabConnected data enables advanced capabilities that put companies ahead of the competition, including reduced time to market in many development contexts. With connected data, companies can better unify data across many disparate systems with opens in new tabbetter master data management (MDM) approaches, and increase positive behaviors and possibly revenue with contextual and opens in new tabrelevant real-time product recommendations across ever-growing and evolving datasets. They can also save millions of dollars by analyzing complex connections to opens in new tabfight financial fraud in real time.

Every business needs to leverage these data relationships and leverage them faster. A graph
database, like opens in new tabNeo4j, delivers those capabilities – at no risk to your Oracle investments.

In this Neo4j and Oracle blog series, we’ll explore how these two database technologies work together in tandem to deliver the best bottom-line results for both enterprise architects and business teams alike.

This week, we’ll start with definitions and introductions of both Oracle RDBMS and the Neo4j graph database.

A Closer Look at Relational Databases

In order to understand how a graph database works and the value it brings, it’s helpful to
understand how relational databases, like Oracle, work. opens in new tabRelational databases store highly structured data in tables with predetermined columns and many rows of the same type of information. Because developers must structure the data used in their applications in this tabular format, the fixed schema works best for problems that are well-defined at the outset.

Relational databases are the perfect tool for highly structured, predetermined schemas.
However, these databases don’t adapt well to change nor do they provide an efficient
approach for traversing relationships between data elements. It’s ironic, but relational
databases are not good at navigating multi-layered, complex relationships in real time.

You might be using a “relational database,” but the truth is it’s not really optimized for dealing with relationships. Sure, it’s possible to use JOINs to navigate relationships, but relational databases take a opens in new tabperformance hit as queries get deeper and add more JOINs. In fact, the term “relational database” has nothing to do with describing relationships between data, but is a reference to the highly specific mathematical notion of a “relation” – a.k.a. a table – as part of E.F. Codd’s opens in new tabrelational algebra.

What is Neo4j?

A opens in new tabgraph database, like Neo4j, puts data relationships first. Neo4j is an opens in new tabACID-compliant, transactional database management system with Create, Read, Update and Delete (CRUD) operations working on a graph data model. The graph data model is easy to understand, as it reflects how data naturally exists – as objects and the relationships between those objects.

You can think of a graph data model as composed of two elements: nodes and relationships.
Each node represents an entity, and each relationship represents how two nodes are
associated. By assembling the simple abstractions of nodes and relationships into
connected structures, Neo4j enables you to build sophisticated models that map closely to a
problem domain.

A simple graph data model: Books, authors and owners

Neo4j enables developers to be more agile and to deliver applications faster due to one
simple fact: It’s a schema-optional database. This means there’s no need to set up elaborate
data models based on what you think the business requirements are.

Instead, this flexibility abstracts your data model and validation to the application tier, but
still inherently provides you with the right level of control to define the data coming in. A data
model in Neo4j mirrors whiteboard drawings, closing the gap between business and IT, and
enabling you to make changes on the fly as business requirements change.

Because Neo4j uses an intuitive data model that anyone in the organization can understand,
querying the data is just as easy to grasp, even for team members without a database
background.

Conclusion

It’s time to get real about databases. Relational databases can’t do everything you need them
to do. But more importantly, you don’t have to sacrifice the capabilities of a graph database to
preserve your investment in Oracle RDBMS – or vice versa.

Next week, we’ll take a closer look at the specific advantages of using Neo4j alongside Oracle RDBMS and in the weeks to come, we’ll look at each deployment paradigm for using the two technologies together.