Creating Triggers with Trigger-By-Example in Graph Databases Kornelije Rabuzin a and Martina Sestakˇ b Faculty of Organization and Informatics, University of Zagreb, Pavlinska 2, 42000 Varazdin,ˇ Croatia Keywords: Trigger-By-Example, Graph Databases, Triggers, Active Databases. Abstract: In recent years, NoSQL graph databases have received an increased interest in the research community. Vari- ous query languages have been developed to enable users to interact with a graph database (e.g. Neo4j), such as Cypher or Gremlin. Although the syntax of graph query languages can be learned, inexperienced users may encounter learning difficulties regardless of their domain knowledge or level of expertise. For this reason, the Query-By-Example approach has been used in relational databases over the years. In this paper, we demon- strate how a variation of this approach, the Trigger-By-Example approach, can be used to define triggers in graph databases, specifically Neo4j, as database mechanisms activated upon a given event. The proposed ap- proach follows the Event-Condition-Action model of active databases, which represents the basis of a trigger. To demonstrate the proposed approach, a special graphical interface has been developed, which enables users to create triggers in a short series of steps. The proposed approach is tested on several sample scenarios. 1 INTRODUCTION Example approach has been introduced to simplify the process of designing database triggers. The The idea of active mechanisms able to react to a spec- approach uses the Query-By-Example (QBE) as a ified event implemented in database systems dates graphical interface for creating triggers (Lee et al., from 1975, when it was first implemented in IBM’s 2000b), and makes the entire trigger design process System R. The idea was quite simple; it was important more user-friendly. to implement a mechanism that could be able to react Nowadays, modern database systems need to han- to different types of events that occur primarily within dle important challenges, such as large data volume, the database or in its surroundings. In database theory, data integrity, scalability, variety of data sources, un- such behaviour was described by the concept of active structured data, etc. Hence, in some application do- (Event-Condition-Action, ECA) rules. ECA rules are mains, traditional relational databases have been ”re- interpreted in the following way: if some event oc- placed” by their NoSQL counterparts designed to bet- curs in the system, and some conditions are fulfilled, ter adapt to these challenges. Graph databases are then a given action (or set of actions) is automatically a category of database solutions within the NoSQL executed as a system’s reaction to the event. The ecosystem designed to efficiently store and manage events defined in ECA rules can vary in their com- highly interconnected data (for instance, social net- plexity, ranging from simple (e.g. basic data manip- work data). ulation statements such as INSERT, UPDATE and/or Triggers as database objects have only been re- DELETE) to complex events, which can be defined cently introduced in a very few Graph Database Man- by means of simple events, or events such as a se- agement Systems (GDBMSs) (e.g. Neo4j and Janus- quence of events, negation, etc. In database systems, Graph), and they still require users of different levels ECA rules are most often implemented through the of expertise to have a certain level of query language trigger mechanism. A trigger represents a database syntax knowledge. This research is motivated by this object written in a given procedural language, which issue, and the aim of this paper is to make the trigger executes automatically when a given event occurs. design process in graph databases easier, faster and To avoid manually writing the trigger func- more understandable for different users. tion code for inexperienced users, the Trigger-By- The main contribution of this paper is an ap- a https://orcid.org/0000-0002-0247-669X proach, which describes how to easily design and im- b https://orcid.org/0000-0001-7054-4925 plement triggers in graph databases. To implement 137 Rabuzin, K. and Šestak, M. Creating Triggers with Trigger-By-Example in Graph Databases. DOI: 10.5220/0007829601370144 In Proceedings of the 8th International Conference on Data Science, Technology and Applications (DATA 2019), pages 137-144 ISBN: 978-989-758-377-3 Copyright c 2019 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved DATA 2019 - 8th International Conference on Data Science, Technology and Applications the proposed Trigger-By-Example approach in graph sibility of using rule-based systems for industrial au- databases, we implemented a graphical user interface tomation (Gruner¨ et al., 2014). Specifically, the au- (GUI), which enables users to define triggers stored as thors used Neo4j GDBMS and Cypher to build a rule- ECA rules, i.e., Cypher query language statements, in based system, which will demonstrate the benefits of a graph database (specifically, Neo4j). using graph concepts to specify rules. In their ap- The rest of the paper is organized as follows: Sec- proach, a rule consists of a premise (Cypher query) tion 2 contains an overview of existing research pa- and a conclusion (series of operations executed based pers related to active databases, Trigger-By-Example on results of the query evaluation), and it is stored in approach and developed graph-based rule specifica- XML format as a statement written in a descriptive tion engines. In Section 3, a theoretical background is syntax similar to RuleML. However, in this approach, given to help readers understand the concept of active the rules are created either manually on demand or and graph databases and the TBE approach. In Sec- by the system, which lowers the need for users’ en- tion 4 the proposed TBE approach in graph databases gagement in the rule specification process. On the is presented and demonstrated on simple Neo4j use other hand, our graphical interface for rule specifica- cases. Finally, we conclude this paper by describing tion provides more flexibility for the users, and it fur- future research directions. ther engages the user in the process by making it more simple. Furthermore, an interesting rule-based engine has 2 RELATED WORK been introduced in (Rapsevicius and Juska, 2014). The authors developed an expert system for the Com- Over the years, there has been a number of research pact Muon Solenoid (CMS) Cathode Strip Chambers papers, which introduced graph-based rule specifica- detector at the Large Hadron Collider (LHC). One tion engines and visual interfaces. During the 90s, of the system’s components is the rule-based com- Dayal, Widom and Ceri published several relevant plex event processing (CEP) engine, which consists of research papers and books related to active database rules written in SQL syntax forming a decision tree. systems. In these publications, the authors discussed In the context relevant for this paper, a rule presents a active database systems in general and their possible named computational expression that results in a con- application domains (Widom and Ceri, 1996), using clusion if expression conditions are met (Rapsevicius declarative approach to specify the model for active and Juska, 2014). The CEP engine ensures that, for rules execution (Ceri, 1992), rule execution semantics each incoming data stream, a relevant rule is fired, and implementation (Dayal et al., 1994), etc. which evaluates the conditions, and returns a conclu- Nowak, Bak and Jedrzejek developed a graph- sion based on that evaluation. The conclusion can based prototype implementation of a graphical inter- then be configured to perform a certain action, such face for specifying rules (Nowak et al., 2012). Apart as sending notifications, execute commands, etc. The from rule creation, the interface is able to perform rule rules definitions are stored within tables in a relational reasoning in order to obtain results. The rule cre- databases, and the authors developed a GUI interface ation process is carried out by specifying the body for rules specification. Nevertheless, the interface re- (left hand side, LHS) and the head (right hand side, quires users to specify rules by using specific opera- RHS) of the rule in a form of two separate graphs, tors with no explicit syntax guidelines. Compared to which are then used to build ”if LHS then RHS” state- our proposed approach, the GUI requires users to still ments. Created rules are able to check if there is a have a level of syntax knowledge, whereas our ap- given fact with specific attribute values in the knowl- proach enables users to specify rules in a completely edge base, or if there exists a relationship between two visual manner regardless of their level of knowledge existing facts. The first condition type is supported and experience. in the current state of our implementation, while the The idea of active graph databases is still in its relationship existence check will be part of our fu- early years of development. The most significant con- ture work. The authors used Jess rule engine for rule tribution in this field has been made by Kankanamge creation and reasoning, which requires users to spec- et al., who developed Graphflow, an active graph ify rule conditions by following Jess language syntax database (Kankanamge et al., 2017). The system similar to RDF. In the proposed approach, the users is built on Neo4j, and uses Cypher++, a declara- can specify rules by simply following ”natural” se- tive Cypher extension, which supports triggers as mantics, i.e., they do not need to be familiar with any subgraph-condition-action rules. Cypher++ support kind of syntax. the specification of rules, which are triggered on ex- Next, Gruner,¨ Weber and Epple explored the pos- ecuting MATCH, CREATE, DELETE, UPDATE and 138 Creating Triggers with Trigger-By-Example in Graph Databases SHORTEST PATH queries, and such rules can result • Method events (in object-oriented databases), etc.