You spoke and we listened. Based on customer feedback, we are happy to announce that we have implemented some new changes here at Arcade. With an adjusted toolbar and the creation of a popup context menu, Arcade is more intuitive than ever. You can check us out at https://2018.datadriveninnovation.org/ on Friday and Saturday in Rome this weekend to learn more about these changes and what else Arcade has planned for the future.
Users can right click on a specific node or edge and view a pop up window that shows common functions, including: view selected node/edge properties, delete or hide selected node/edge, and traverse selected node.
To help make graph analysis with Arcade even simpler, we have added a feature that allows users to aggregate their data from their databases. To learn how all of this works, read about our aggregation feature below.
Aggregation – How it works
The Graph Model is more expressive than the ER Model. In the Graph Model, the N-N Relationship doesn’t need redundant structures like the join tables used in the SQL world, instead you just have edges. For this reason Arcade offers the capability to aggregate some redundant information in order to obtain a simpler and more efficient model.
This makes it possible to choose a specific mapping strategy that performs aggregation on join tables of dimension equals to 2, that is to say those tables which map two tables together by referencing the primary keys of each data table through a foreign key. The join tables of dimension greater than 2 are ignored by the aggregation algorithm. This process allows each candidate join table to be converted into an appropriate edge, and each field not involved in any relationship with other tables (hence not involved in any foreign key in the source DB schema) is aggregated in the properties of the new built edge.
Even if the new DB does not reflect the original DB schema, the aggregation leads to a great saving in terms of resources and avoids a substantial overhead. The OrientDB schema after the aggregation process comes out simpler, hence also the analysis is easier.
Below the join table is not translated into a Vertex Type, but rather into an Edge Type. The last_update column, the only one not involved in any relationship, becomes a field in the resulting “aggregator edge”.
By starting from the previous scenario, but this time using the aggregate function, we will get cleaner and simpler results.
This time we will obtain a less complex graph:
A simpler graph means better performance: to navigate the relationship between films and actors we will not need two jumps, but just one.
How to aggregate aggregate join tables of your source database
In order to aggregate all the join tables in your source database you simply have to flag the specific option in the Datasource options.
In this way all the widgets connected to this specific Datasource will come out with an aggregated model that will be reflected during the analysis.
Let’s focus on the N-N relationship between actors and movies: starting from a specific actor we will be able to expand all the related movies by traversing just one relationship, called with the same name of the original aggregated join table, in this case film_actor.
To check out Arcade’s newest updates and features for yourself, test out our free online demo.