Cloud backup is more important than ever, and it needs to be respected and understood.

Released back in 2012, Neo4j 1.8.M03 introduced the RELATE clause, a two-step dance of MATCH or CREATE. Also, new Transaction support in the shell lets you call for a do-over in case you misstep. RELATE, a Subgraph Match-Maker A RELATE clause looks a lot like a MATCH clause — the ASCII-art of graph traversals — but behaves differently when there isn't a satisfying subgraph. When there is no match, RELATE will create the needed Relationships and even intervening Nodes. RELATE ensures that the subgraph exists. So, I just fetched myself a coffee. Let's say I want to keep track of how often I visit 3 Bees Coffee. I could carve notches on my desk, but I've already ruined one Ikea desk that way. Being graph-minded, I immediately realize that I'll be curious about deeper questions regarding all the places I visit. I will, of course, evolve a graph mini-app. Neo4j 1.8.M01 introduced the CREATE clause, so I'll create me and the coffee shop: CREATE me = {name:"Andreas"}, `3bees` = {name: "3 Bees Coffee"} (Note the back ticks around 3bees because the term starts with a number) To record that I have visited 3 Bees Coffee, I could add a relationship at the same time: CREATE me = {name:"Andreas"}, `3bees` = {name: "3 Bees Coffee"}, me-[:VISITS]->`3bees` Of course, I will be re-visiting coffee shops more often than going to newly opened shops. I already know about me, and will usually know about the coffee shop, so what I really want to do is just create the Relationship. START me=node(1), coffee=node(2) CREATE me-[:VISITS]-coffee Easy as pie. Mmm pie. Create a record for me, create a record for a shop, and whenever I visit a shop, create a Relationship. Because I want to keep track of the frequency of my visits, I suddenly have a problem: I don't want to create a Relationship every time, but get one if it exists and just update a property on it. Cypher is declarative. There is no spoon, I mean 'IF'. So we turn to our friendly match-making RELATE clause: START me=node(1), coffee=node(2) RELATE me-[v:VISITS]-coffee return v That'll match the VISITS if it exists, or create one if it doesn't. To update the visits, I can convert the RETURN into a WITH to tack on a SET clause like so: START me=node(1), coffee=node(2) RELATE me-[v:VISITS]-coffee WITH v SET v.visits=(v.visits +1) RETURN v OK, one last detail to adjust: the classic initial condition problem. If RELATE happened to create a new Relationship, it won't yet have a visits Property. We'll use COALESCE to ignore v.visits if it is null, then add 1: START me=node(1), coffee=node(3) RELATE me-[v:VISITS]-coffee WITH v SET v.visits=(coalesce(v.visits?,0)+1) return v Ah, now I have even more motivation to take coffee breaks. The RELATE clause is powerful fun. Get yourself a cup of coffee, then sit down to peruse the Neo4j Manual section on Cypher RELATE to learn more. And, check on my coffee consumption in the Neo4j Live console, where you can play around with RELATE. Transactional Shell Prior to this release, every query issued in the Neo4j shell (whether command-line or in Webadmin) created a transaction when needed. Now, you have control over transactions with some new shell commands: begin transaction, commit, and rollback. These let you practice your new Cypher dance moves without worrying about falling on your face and taking your database down with you. As usual, look to the Neo4j Manual for the details. Now that we’ve looked back in time, let’s see what Neo4j can do better than SQL. SQL is an impressive query language but there are things that Cypher handles so much better. Whereas SQL started as a single table query language, support was added later for geospatial data and for XML and JSON as well. XML is primarily used for displaying documents on web pages. It uses customized markup languages that are user-defined. JSON reads data from web servers in order to display it online. When dealing with relational databases which are built on tables, JOINs make the connections. So how does this relate to Neo4j? Well, Neo4j is designed to handle product recommendation engines as well as supply management and personalizing customer experience. And Cypher’s graph query language allows you to extract data from graphs. It’s essentially SQL for graphs. Cypher is easy to use and understand. It’s designed for graphs. It borrows from other languages such as Python and is a powerful, full-featured modern language perfect for data analysts and subject matter experts who need to extract meaningful data by reading and writing queries themselves if need be. You don’t need to be a developer to get the benefits from Cypher. A feature of graph databases is that their searches are schema-free. Or at least optional. By not having a fixed schema you can develop the relationships, add attribute types and develop your data as you go. This provides extreme levels of flexibility when developing applications. SQL Path Patterns Query Using path patterns which is an advanced feature, you can have a product that points to a list of categories. With a deep hierarchy, one which you don’t know the depth of yet, you can insert a “*” to find arbitrary linked relationships right to the root directory. But you can limit it to a set number of relationships as well as categories. This is all easily achieved in Cypher but requires linking together a chain of queries in SQL. Each level must be spelled out in the query to the limit that is needed. A cumbersome and time-intensive process, especially when you don’t necessarily know how many categories you’re going to end up with anyway. Find All Cycles in a Directed Graph If you wish to find loops, where a loop leads back to the same person or thing over again, path patterns will determine the outcome. Using MATCH path = (p:Person)-[*3..10]-(p), one can look for 5 hops ending with the person you started with. Not only is the data available in a table but it can be generated visually. And that in essence is what you get with Cypher; a powerful much more user-friendly tool that is purpose-built to provide graph queries in a format that the user can manipulate to show relationships without being bogged down in endless hours of programming and validation. Combine Reads and Writes If you’re familiar with SQL, you need to support Reads and Writes by using insert statements or insert from select. Unfortunately, that’s where it ends. Cypher does the heavy lifting and combines reads and writes in a single query. So, you can update the database while simultaneously fetching data. The benefits of Cypher over SQL don’t end there but I’m sure you get the point. Relate Yourself Neo4j 1.8.M03 is available for immediate download in the usual places. Get it now: Download from neo4j.org Bump the versions in your maven pom.xml Provision on heroku with: heroku addons:add neo4j --neo4j-version 1.8.M03 Want to practice Cypher with fellow Graphistas? Join us at a meetup somewhere in the world, or propose a new location and we'll look into visiting your area to buy you a cup of coffee. The content of this article was originally written by Andreas Kolleger over at the Neo4j blog.

While a lot of databases have been created listing information in a table format, the web isn't set up in a tabular style. Neither is plenty of data in a variety of formats that the web uses. However, many databases are still using tables, because many web developers feel that tables handle plenty of data better than any other structure. Others feel that the data tables known as RDB should be converted to RDF, a format used to gather an even wider array of metadata across the worldwide web. The ability to convert to RDF will be extremely beneficial as technology advances to Artificial Intelligence AI and beyond. What is an RDB? RDB stands for a Relational Database. An RDB is a collective set of multiple data sets organized by tables, columns, or records. An RDB establishes a well-defined relationship between database tables. The tables communicate to share information that makes it possible to search for data, organize, and report. RDB is derived from the mathematical function concept of mapping data sets as developed by Edgar R. Codd. RDBs use Structured Query Language, SQL.SQL is a standard user application that provides an easy programming interface for database interaction. RDBs organize data with each table known as a relation which contains columns. Each table row, or record, contains a unique data instance defined for a corresponding column category. The data and record characteristics relate to at least one record to form functional dependencies. RDB performs "select", "project" and "join" database operations, where select is used for data retrieval, identifying data attributes, and combining relations. Those who prefer to use RDBs do so because of the advantages, including easy extensibility or scalability, new technology performance, and data security. What is RDF? RDF is primarily used to provide information or metadata for data available on the Internet. RDF provides the methodology for specifying, structuring, and transferring metadata, and provides the basic XML syntax for software applications to exchange or use that information. The URI/URL provides the location of that data. RDF stands for Resource Description Framework and is a standard for describing web resources and data interchange, developed and standardized by the World Wide Web Consortium, W3C with Xtensible Markup Language (XML) and Uniform Resource Identifier (URI) serving as its distribution standards. Typically, RDF provides basic information and attributes about an Internet-based object, such as the name of the author, Web page keywords, object creation or editing data, or the sitemap. While there are many conventional tools for dealing with data and more specifically for dealing with the relationships between data, RDF is the easiest, most expressive, and most powerful standard to date. The overall informational value is much greater because context or intent can be inferred. RDF presents small chunks of information in a form that infers meaning. This can include rules about how the data should be interpreted. Resource Description Framework, RDF, is the standard for encoding metadata and other structured information on the Semantic Web. Semanticization Data With all the semantic standards and database-centered HTML5 APIs and a W3C standard that calls for implementations, this is an exciting time for data on the web. It's time to embrace RDF with the capacity to start pulling relational data into the semantic web! The Purpose of RDBMS The software used to store, manage, query, and retrieve data stored in a relational database is called a Relational Database Management System, or RDBMS. The RDBMS provides an interface between users and applications with the database. It also provides administrative functions for managing data storage, performance, and access. Semanticization, or giving meaning to, all data can be done in two stages. First, construct a web of meanings, not documents -- as Sir Tim Berners-Lee has always wanted, and as the RDF, Resource Description Framework seeks to do. Second, fit all tabular data into the web whether legitimately or not. This second step is less exciting than the first because plenty of tabular data is not ideally tabular. In these cases, the second step is rather backward-looking. However, it is no less necessary than the first for two reasons: Converting everything RDBMS to RDF is not even close to worth it Much data ought not to be converted to RDF All of this data still needs to talk to the web, which means it needs to be translated into a webby structure, ideally RDF. The easiest way to translate without conversion is, of course, just plain mapping. But mapping two rather different structures to one another is no small undertaking or trivial task. That's why there's a whole W3C Working Group devoted to devising a mapping language and actual mapping of relational data to RDF. Sir Tim offers this insight into the RDF-RDBMS relation, cutting through questions that might otherwise be couched in domain-inappropriate terms (like 'is the RDF model an entity-relationship model'): Relational database systems manage RDF data, but in a specialized way. In a table, there are many records with the same set of properties. An individual cell (which corresponds to an RDF property) is not often thought of on its own. SQL queries can join tables and extract data from tables, and the result is generally a table. So, the practical use for which RDB software is used is typically optimized for doing operations with a small number of tables, some of which may have a large number of elements. Because relational databases are species of the genus described by RDF, the basic mapping model is as follows: a record is an RDF node; the field (column) name is RDF propertyType; and the record field (table cell) is a value. So far, so straightforward. Of course, the implementations usually wander pretty far from the original concept. That's why mapping actual RDBMS to RDF takes a bit of dirty work. RDB2RDF Enter RDB2RDF. The RDB2RDF WG is doing the dirty work. Back in 2005, when the Group was still an Incubator, they published a detailed survey of then-current approaches to mapping relational databases to RDF. This survey served as the starting point for typically extensive discussion and debate, which culminated in two Candidate Recommendations: The RDB to RDF mapping language: R2RML The Relational-to-RDF mapping itself Many techniques and tools have been proposed to enable the publication of relational data on the web in RDF. RDB-to-RDF methods are one of the keys to populating the web of data by unlocking the huge amount of data stored in relational databases. Since producing RDF data with sufficiently rich semantics is often important in order to make the data usable, interoperable and linkable, there are various strategies developed to enrich data semantics. Turning RDB to RDF has proven to be of value when dealing with SQL databases. It offers a straightforward and practical system for relational database conversion into RDF. RDB2RDF and the Future Moving forward beyond RDB-to-RDF methods, it will become necessary to find a compromise between the expressiveness of RDB to RDF mapping languages and the need for updating relational data using protocols of the semantic web. Creating, updating, and deleting RDF data should only be made possible in a secure, reliable, trustworthy, and scalable way.

Let's explore distributed tracing for microservices on the ELK stack.

In this article, you will learn when you should consider adding JSON data types to your tables and when you should avoid them.

From benchmark schema migration tools to new products embracing the idea of "database as code," let's break down the current landscape and explore the trends.

There's value in aggregating data from multiple systems into a single, holistic, real-time representation of a business entity. See why.

Follow a brief explanation of CI/CD and how to implement caching of Maven dependencies in the pipelines while deploying your Mule application to CloudHub.

Discover benefits of a DevSecOps approach to API security, API vulnerabilities at F5, trends in API integration, bot attacks on APIs on the rise, and more.

Learn how to improve the performance of a Spring application and diagnose problems in production: lessons from our live workshop covering JPA.

This blog post will help you get quickly started with DynamoDB Streams and AWS Lambda using Go. It will cover how to deploy the entire solution using AWS CDK.

Custom Resources in AWS CDK are powerful and give you much flexibility. You can leverage the Provider framework when you need more than a single API call.

Deploy a website on AWS using S3, CloudFront and Route 53 as the main services and Terraform as the infrastructure as code deployment tool.

Microservice applications can run in many ways, with different tradeoffs and cost structures. Let’s go over the 5 main ways we can deploy microservices.

There has been a surge of recent interest in a data infrastructure that is designed to take maximum advantage of the benefits that cloud computing provides.

This article looks at three best-practice database designs to store data in multiple languages and easily scale to new markets.

Worried about threats to your Open API ecosystem? Prepare yourself with this list of noteworthy tips and best practices.

Most organizations that utilize DevOps principles and tools require a logging system to cover the shortcomings of Prometheus.

In this blog, we will go over how developers and DBAs should use ALTER TABLE in a proper fashion to avoid problems this query can create.

In this update, learn more about an insecure API in WordPress plugin and a Tesla 3rd party vulnerability, as well as become introduced to vAPI.