Here is the actual point of a true, native graph database: Real solutions require visualization. When you can see the problem, you can find the solution. And when you can project the problem to your database manager as something it can see, it can find the solution without you having to massively transform your data first.
Of course, what you really need to make this happen is the right graph.
The right graph
The right graph — and there truly is such a thing as “the right graph” — is never terrifically complex. For problems that incorporate any amount of data, there are circles representing objects and arrows representing relationships. We call this scheme “whiteboard friendly” — you could draw it with a dry-erase marker, and it’d be technically correct. Congratulations, you are now halfway to a complete comprehension of graph database principles.
Now, here’s the part you may never have been told: When you build a relationship model first using the right graph, solving for that graph solves the data problem the graph represents. Algorithms that were ostensibly engineered to find the shortest paths through mazes or the most optimum courses of action in chess games, with minimal or no alterations, can find solutions to real problems when graphs represent data.
Neo4j AuraDB: The right graph. Register now for free and start solving for real.
The real problems
What do we mean by “real problems?” Fraud detection is the one you’ve probably heard about. Another is money laundering detection, which typically requires a full-time risk management solution. Telecommunications network fault detection is another “real problem.”
Unifying cancer patient data under a single graph database model enables records from hundreds of separate sources requiring thousands of JOIN and UNION operations to yield behavior patterns that point the way towards cures – and that may save lives. The operational data produced today by essentially every automobile produced this decade, can be combined to yield correlations between maintenance patterns and safety records – again, yielding patterns of care that save lives.
The world’s supply chains have suffered unprecedented stresses, on account of the pandemic. Graph database models in manufacturing and warehousing systems can ameliorate the effects of stressed supply routes, ineffective logistics, and pesky geopolitical squabbles. Supply networks can be refashioned and rerouted to lower transport costs, re-establish direct routes, and resume reliable product delivery channels. Manufacturing process automation can be revolutionized, by adding literally dozens of layers of complexity — including accounting for exclusive vendor specializations — without adding exponential amounts of overhead and resources.
What you’re seeing above is not a screenshot or an embedded video. It’s Neo4j, it’s switched on, and it’s waiting for you to try manipulating its data and its graph. It’s pre-populated with data designed around a relatively vast, but structurally simple, graph data model: namely, the social relationships between users in Stack Overflow.
Try it right now. (Click the right arrow beside “Overview” to see more of the graph model.)
Now, imagine what you can know if your data actually told you something useful. You can’t make any “errors.” You can drag a node to a new place to see how relationships change. You can experiment with how a Cypher query works. For a full-screen, browser-based console version of this Neo4j Playground, click here.
Step 1: Solve
When you model a database with solutions in mind, solutions are easier to attain. Ordinary relational databases, by stark contrast, are not designed to be modeled. They do employ schemas to represent relationships between elements in tuples (tables), but these schemas are essentially leveraged to make it feasible to deconstruct relational data, and rebuild it into forms and formats whose relationships point to something resembling solutions.
So for fraud detection in a stream of financial transactions represented using traditional databases, all you’d need are the following:
- Data pipelines for transformation processes
- Separate streams representing something called the “source” and something else called the “sink”
- A multitude of filters
- An engine for iterating data through the various pipelines
- Something to synchronize the pipelines so there’s only one flow through the engine
- Something else called a “cross-join”
- A pointer extractor
- A “functional stream enricher”
- An output stream aggregator
Got all that?
Graph database should have been your first database
It’s as if you entered a skyscraper without elevators, escalators, or even a ladder, but you need to get to the 26th floor. Its architect did graciously provide you with the blueprints of the building, plus every tool you’d ever need, including a crane, to deconstruct the building floor-by-floor, and lay each floor on the ground next to the other. It’s never been easier, the skyscraper’s colorful, friendly marketing brochure would read, to bring the 26th floor down to your level in just under a year.
Graph database is your missing elevator. In the real world, relationships are at least as important as the things to which they relate. The conventional database world may as well reside in another solar system. There, you have to remove the relationships to put data into the system. Then in order to yield solutions, you use code to factor relationships back in.
Now that you think about it that way, how crazy is that?
Neo4j introduced graph databases to the world 15 years ago, and now research facilities, governments, every one of North America’s Top 20 banks, and over three-quarters of Fortune 100 companies are using Neo4j to model data in a way intended from the start to yield results. Why dilly-dally around with extract, transform, load, extract, transform, load, rinse, repeat, etc., when you can use a tool that already knows how to solve?
Neo4j solves the big problems. And because its graph data model is engineered from the outset to solve big problems, you don’t need to deconstruct anything or lower it to ground level first. You can rise to its level, and face your real-world business problem head-on.
You don’t need a supercomputer, a sea of data lakes, a runway for traffic control, a spare functional stream enricher, a multi-cloud paradigm, or any other sci-fi technobabble or pseudo-spiritual metaphor. The tools you need are actually here for you now, today, this very moment. And you’ll know them when you see them.
Neo4j AuraDB: The right graph. Register now for free and start solving for real.
Stop wasting time and effort
If your aim isn’t to maintain a ledger but to solve a real problem, you’re wasting time with anything other than a true graph database.
Now, here’s something that’s pretty obvious to us at Neo4j, especially after a decade and a half spent helping businesses build graph databases: We acknowledge that most of the world’s data — probably including yours — has not been assembled with graph models in mind.
Yes, that’s a problem for anyone who wants their database to solve problems by design. No, the complete solution is not some “enterprise knowledge” snap-on plug-in that gives your existing database the semblance — the soupçon — of a graph. Any well-architected product never has something bolted onto it to make it work the way it should have always worked.
Exporting and remodeling conventional data to become graph-ready data does take effort and cannot always be automated. But it’s effort you can comprehend, that’s sensible, and that yields results.
Here’s something else you should know: We’re here to help you. The whole point of graph is to help you simplify the problem, solve it, and then scale the model as your problem size grows. Sure, we have the tools, but we also have the skills. And with a bit of help from us, you can also have the skills.
Finding the solutions will metamorphose the way you work. Come aboard with AuraDB now. Start solving for real.