On enforcing dyadic relationship constraints in MatBase

Dyadic relationships are widely encountered in the sub-universes modeled by databases, from genealogical trees to sports, from education to healthcare, etc. Their properties must be discovered and enforced by the software applications managing such data, in order to guarantee their plausibility. The (Elementary) Mathematical Data Model provides 11 dyadic relationship constraint types. MatBase , an intelligent data and knowledge base management system prototype, allows database designers to simply declare them by only clicking corresponding checkboxes and automatically generates code for enforcing them. This paper describes the algorithms that MatBase uses for enforcing all these 11 dyadic relationship constraint types.


Introduction
Very many database (db) sub-universes include dyadic relationships (e.g., Lawvere and Rosebrugh2003; Mancas 2023). For example, let us consider soccer championships ones, where, besides a set of TEAMS and one of CITIES, in order to store the results a MATCHES set is needed as well. MATCHES is a dyadic relationship over TEAMS, i.e., a subset of the Cartesian product TEAMS  TEAMS, with, e.g., its first canonical projection denoted Host : MATCHES TEAMS and its second one denoted Visitor : MATCHES TEAMS.
On one hand, as with any other constraint (business rule), failing to enforce any of the above ones could lead to storing unplausible data in the corresponding db (e.g., matches <Chelsea, Chelsea> or missing matches).
On the other hand, as, except for the irreflexivity, all other above constraints on MATCHES are of type tuple generating, enforcing them is also saving time for end-users, as they only have to enter data for CITIES and TEAMS, while the system is automatically generating corresponding MATCHES <Host, Visitor> data pairs, with end-users then only having to enter calendar dates and scores for matches. Of course, the dyadic relationship constraints are not enough for guaranteeing data plausibility, not even for this simple db example: as usual, all other existing constraints in the corresponding sub-universe should also be enforced. For example, names of cities and teams should be unique (i.e., both Team : TEAMS  ASCII(32) and City : CITIES  ASCII(32) must be one-to-one), no team may play more than one match a day (i.e., both Host  MatchDate : MATCHES TEAMS  [13-Aug-2021, 22-May-2022 and Visitor  MatchDate : MATCHES TEAMS  [13-Aug-2021, 22-May-2022] must be minimally one-to-one), etc.
Unfortunately, while, for example, uniqueness may be enforced by almost any commercial Database Management System (DBMS), with unique indexes, no such DBMS may enforce dyadic relationship constraints. Consequently, developers must enforce them into the software applications that manage corresponding dbs (through either extended SQL triggers or event-driven methods of high-level programming languages embedding SQL).
Fortunately, our MatBase intelligent system provides, through its (E)MDM interface, both a very user-friendly experience to db architects (e.g., for MATCHES above, you only need to click its corresponding Connected, Irreflexive, Symmetric, Transitive, and Euclidean checkboxes) and its associated code-generating power, which is both constructing underlying db tables, standard MS Windows forms for them, as well as event-driven code in their classes for enforcing the corresponding constraints.
As such, MatBase is not only saving developing time, but also saves testing and debugging time, which promotes the 5 th programming generation -modelling as programming (Thalheim 2020; Mancas 2020a).
MatBase (Mancas 2018(Mancas , 2019a(Mancas , 2020b(Mancas , 2023 is an intelligent prototype data and knowledge base management system, Currently, MatBase has two versions -one developed in MS Access, for student and small db use and a professional one, developed in MS C# and SQL Server. This paper presents the pseudocode algorithms used by both MatBase versions to automatically generate code for enforcing dyadic relationship constraints.

Related work
This paper is a continuation of Mancas 2020b, which was mainly focused on assisting the process of detecting dyadic relationship constraints. It refines its AEDRC Algorithm (which is a very high level one, mainly dealing with the coherence and minimality of the sets of dyadic relationships constraints) for each type of dyadic relationship constraints. They are generally based on XML (but also on the Z notation, the Business Process Execution Language, the Business Process Modeling Notation, the Decision Model and Notation, or the Semantics of Business Vocabulary and Business Rules). This is the only other field of endeavor trying to systematically deal with business rules, even if informally. However, this is not done at the db design level, but at the software application one, and without providing automatic code generation.
From this perspective, (E)MDM also belongs to the panoply of tools expressing business rules, and MatBase is also a BRMS, but a formal, automatically code generating one.

Prerequisites
Let R = (fC, gC) be an arbitrary dyadic relationship. For enforcing dyadic relationship type constraints on R, both C and R must have Graphic User Interface (GUI) forms associated to their corresponding tables and event-driven methods:  Classes C and R must contain private AfterInsert(x) and AfterInsert(f, g) methods, respectively (see Figure 3);  Class R must contain: o Definition of two private numerical variables fOldValue and gOldValue (see Figure 1); o A private method Current(f, g)shown in Figure 1, to be called each time the cursor of the R's form enters a new element (line, row, record) of its underlying data; o A private method BeforeInsert(f, g)shown in Figure 2, to be called each time end-users ask for adding a new element to R; o A private BeforeUpdate(f, g) method shown in Figure 4, to be called each time a new or existing element of its underlying data whose values for columns <f, g> were < fOldValue, gOldValue > and that were then modified to <u, v> is about to be saved in the db; o A private AfterUpdate(f, g) method shown in Figure 5, to be called each time an existing element of its underlying data whose values for columns <f, g> were <fOldValue, gOldValue> were then modified to <u, v> and successfully saved to the db; o A private Delete(f, g) method shown in Figure 6, to be called each time end-users ask for the deletion of an existing element of its underlying data; o A private AfterDelSuccess(f, g) method shown in Figure 7, to be called each time an existing element of its underlying data whose values for columns <f, g> were <fOldValue, gOldValue> were successfully deleted from the db.

Enforcing connectivity constraints
According to the connectivity definition, enforcing such constraints for R requires that: 1. Each time a new element x is added to C, pairs <x, y> or <y, x>must be automatically added to R, for any other element y of C. Moreover, whenever R is also symmetric, both these pairs should be added. 2. Each time a pair <x, y> of R, yx, is modified in <u, v>, with either ux or vy, and there is no <y, x> in R, then either <x, y> or <y, x> must be automatically added to R. Moreover, whenever R is also symmetric, no such pair should ever be modified.

Enforcing reflexivity constraints
According to the reflexivity definition, enforcing such constraints for R requires that: 1. Each time a new element x is added to C, a pair <x, x> must automatically be added to R.
2. No pair <x, x> of R may be modified.
3. No pair <x, x> of R should ever be deleted, unless x is deleted from C.
Consequently, MatBase adds the pseudocode algorithm from Figure 11 to the method AfterInsert of class C from Figure  3 for case 1, the one from Figure 12 to method BeforeUpdate from Figure 4 for case 2, and the one from Figure 13 to method Delete from Figure 6 for case 3.

Enforcing irreflexivity constraints
According to the irreflexivity definition, enforcing such constraints for R requires that each time a pair <x, x> (be it new or obtained by modifying an existing <u, v>) is about to be saved in the db R's image, saving must be canceled.
Consequently, MatBase adds the pseudocode algorithm from Figure 14 to the method BeforeUpdate from Figure 4.

Figure 14
Code added in method BeforeUpdate from Figure 4

Enforcing symmetry constraints
According to the symmetry definition, enforcing such constraints for R not connected (the case R connected is dealt with in section 4) requires that: 1. Each time a pair <x, y>, xy, is added to R, a pair <y, x>must automatically be added to R as well. 2. Each time a pair <x, x> of R is modified in <u, v>, with uv and either ux or vx, then <v, u> must automatically be added to R; each time a pair <x, y> of R, yx, is modified in <u, v>, with uv and either ux or vy, then <y, x> must automatically be replaced in R by <v, u>, whenever R is not connected; and each time a pair <x, y> of R, yx, is modified in <u, u> and either ux, or uy, then <y, x> must automatically be deleted from R, whenever R is not connected. 3. Each time a pair <x, y> of R, yx, is deleted, then <y, x> must automatically be deleted from R as well, whenever R is not connected.
Consequently, whenever R is not connected, MatBase adds the pseudocode algorithm from Figure 15 to the method AfterInsert of class R from Figure 3 for case 1, the one from Figure 16 to method AfterUpdate from Figure 5 for case 2, and the one from Figure 17 to method AfterDelSuccess from Figure 7 for case 3.

Enforcing asymmetry constraints
According to the asymmetry definition, enforcing such constraints for R requires that: 1. Each time a pair <x, y>, xy, is about to be added to R, this must be rejected whenever a pair <y, x> exists in R.

2.
Each time a pair <x, y> of R is modified in <u, v>, with uv and either ux or vy, this must be rejected whenever a pair <v, u> exists in R.
Consequently, MatBase adds the pseudocode algorithm from Figure 18 to the method BeforeInsert of class R from Figure  2 for case 1 and the one from Figure 19 to the method BeforeUpdate from Figure 4 for case 2.

Enforcing transitivity constraints
According to the transitivity definition, enforcing such constraints for R requires that:

1.
Each time a pair <x, y>, xy, is added to R and R contains a pair <y, z>, zy, a pair <x, z>must automatically be added to R as well, if it does not exist already.

2.
Each time a pair <x, z> of R is modified in <u, v>, with either ux or vz, and there is at least a y in C such that both <x, y> and <y, z> belong to R, then modification of <x, z> must be rejected; each time a pair <x, x> of R is modified in <u, v>, with uv and either ux or vx, and there is at least a y in C such that either <u, y> or <y, v> are in R, then either <y, v> or <u, y> must automatically be added to R, if they do not exist already . 3. Each time a pair <x, z> of R is about to be deleted and there is at least a y in C such that both <x, y> and <y, z> belong to R, then deletion of <x, z> must be rejected.
Consequently, MatBase adds the pseudocode algorithm from Figure 20 to the method AfterInsert of class R from Figure  3 for case 1, the one from Figure 21 to method BeforeUpdate from Figure 4 for case 2, and the one from Figure 22 to method Delete from Figure 6 for case 3, but only when R is not connected and symmetric as well (case in which, according to the algorithms for the coherence and minimality of the constraint sets (Mancas 2018(Mancas , 2020b(Mancas , 2023, transitivity is redundant, being implied by connectivity and symmetry).

Enforcing intransitivity constraints
According to the intransitivity definition, enforcing such constraints for R requires that: 1. Each time a pair <x, z> is about to be added to R and there are at least two pairs <x, y> and <y, z> stored by R, then adding <x, z> to R must be rejected. 2. Each time a pair <u, v> of R is modified in <x, z>, with either ux or vz, and there is at least a y in C such that both <x, y> and <y, z> belong to R, with yx and yz, then modification of <u, v> must be rejected.
Consequently, MatBase adds the pseudocode algorithm from Figure 23 to the method BeforeInsert of class R from Figure  2 for case 1 and the one from Figure 24 to the method BeforeUpdate from Figure 4 for case 2.

Enforcing Euclideanity constraints
According to the Euclideanity definition, enforcing such constraints for R requires that: 1. Each time a pair <x, y>is added to R and R contains a pair <x, z>, a pair <y, z>must automatically be added to R as well, if it does not exist already. 2. Each time a pair <y, z> of R is modified in <u, v>, with either uy or vz, and there is at least a x in C such that both <x, y> and <x, z> belong to R, then modification of <y, z> must be rejected. 3. Each time a pair <y, z> of R is about to be deleted and there is at least a x in C such that both <x, y> and <x, z> belong to R, then deletion of <y, z> must be rejected.
Consequently, MatBase adds the pseudocode algorithm from Figure 25 to the method AfterInsert of class R from Figure  3 for case 1, the one from Figure 26 to method BeforeUpdate from Figure 4 for case 2, and the one from Figure 27 to method Delete from Figure 6 for case 3, but only when R is not connected and symmetric as well (case in which, according to the algorithms for the coherence and minimality of the constraint sets (Mancas 2018(Mancas , 2020b(Mancas , 2023, Eucideanity is redundant, being implied by connectivity and symmetry).

Enforcing inEuclideanity constraints
According to the inEuclideanity definition, enforcing such constraints for R requires that: 1. Each time a pair <y, z> is about to be added to R and there are at least two pairs <x, y> and <x, z> stored by R, then adding <y, z> to R must be rejected. 2. Each time a pair <u, v> of R is modified in <y, z>, with either uy or vz, and there is at least a x in C such that both <x, u> and <x, v> belong to R, with yx and yz, then modification of <u, v> must be rejected. Consequently, MatBase adds the pseudocode algorithm from Figure 28 to the method BeforeInsert of class R from Figure  2 for case 1 and the one from Figure 29 to the method BeforeUpdate from Figure 4 for case 2.

Enforcing equivalence constraints
According to a definition of relation equivalence, enforcing it for R requires that R be both reflexive and Euclidean. Consequently, equivalence is be enforced by merging the algorithms from sections 5 and 11.

Enforcing acyclicity constraints
According to the acyclicity definition, enforcing such constraints for R requires that: 1. Each time a pair <x, y> is about to be added to R and there is a path of pairs <y, x1>, …, <xn, x>, n>0, exists in R, then adding <x, y> to R must be rejected. 2. Each time a pair <u, v> of R is modified in <x, y>, with either ux or vy, this must be rejected whenever a path of pairs <y, x1>, …, <xn, x>, n>0, exists in R.
Consequently, MatBase adds the pseudocode algorithm from Figure 30 to the methods BeforeInsert of class R from

Concluding remarks and implications for future research
It is straightforward to check that applying the Algorithm A9DR from Figure  To conclude with, the above automatically generated code by MatBase is both guaranteeing data plausibility in this db and automatically generating the instance of the MATCHES table while end-users are entering data into the TEAMS one. Generally, the Algorithm A9DR from Figure 30 automatically generates code that is guaranteeing data plausibility for any dyadic relationship for which all its properties are declared to MatBase as corresponding constraints, while also automatically generating its core data values, thus saving most of the developing, testing, and data entering effort.
Moreover, please note that the (E)MDM also includes constraints on self-maps and binary homogeneous function products (Mancas 2018(Mancas , 2019b(Mancas , 2023, which are particular cases of dyadic relationships. For example, the self-map Mother : PERSONS  PERSONS is irreflexive (i.e., nobody may be his/her mother), asymmetric (i.e., no mother may be the child of his/her child), intransitive (i.e., anti-idempotent, because if y is the mother of x, then y may not be his/her own mother), and acyclic (i.e., nobody may be his/her either ancestor or descendant, on no generation level). For example, the binary homogeneous function product Mother  Father : PERSONS  PERSONS  PERSONS is irreflexive (i.e., nobody may be both your mother and father), asymmetric (i.e., if y is the mother of x and z his/her father, then there may not be any person p having y as mother and z as father), inEuclidean (i.e., if x is the mother of both u and v, y is the father of u and z the one of v, then there may not be a person p having u as mother and v as father, as u and v are siblings), and acyclic (i.e., no man may give birth and no woman may be a father of a child).
Consequently, future research will be devoted to describing what code is MatBase automatically generated for enforcing the constraints associated with both self-maps and homogeneous binary function products.

Conclusion
Not enforcing any existing business rule from the sub-universe managed by a db software application allows saving unplausible data in its db. This paper presents the algorithms needed to enforce the 11 possible dyadic relationship constraint types from the (E)MDM, which are implemented in MatBase, an intelligent DBMS prototype. Moreover, as MatBase automatically generates the corresponding code, it is a tool of the 5 th generation programming languagesmodelling as programming: db and software architects only need to assert the properties of the dyadic relationships (and not only, but of all other (E)MDM constraint types), while MatBase saves the corresponding developing, testing, and debugging time.