MATBASE AUTO FUNCTION NON-RELATIONAL CONSTRAINTS ENFORCEMENT ALGORITHMS

International Journal of Computer Science & Information Technology (IJCSIT) Vol 11, No 5, October 2019
DOI: 10.5121/ijcsit.2019.11505 63
MATBASE AUTO FUNCTION NON-RELATIONAL
CONSTRAINTS ENFORCEMENT ALGORITHMS
Christian Mancas
Mathematics and Computer Science Department, Ovidius University, Constanta,
Romania
ABSTRACT
MatBase is an intelligent prototype data and knowledge base management system based on the Relational
(RDM), Entity-Relationship, and (Elementary) Mathematical ((E)MDM) Data Models, built upon Relation-
al Database Management Systems (RDBMS). ((E)MDM) has 61 constraint types, out of which21 apply to
autofunctions as well. All five relational (RDM) constraint types are passed by MatBase for enforcement to
the corresponding RDBMS host. All non-relational ones are enforced by MatBase through automatically
generated code. This paper presents and discusses both the strategy and the implementation of MatBase
autofunction non-relational constraints enforcement algorithms. These algorithms are taught to our M.Sc.
students within the Advanced Databases lectures and labs, both at the Ovidius University and at the De-
partment of Engineering in Foreign Languages, Computer Science Taught in English Stream of the Bucha-
rest Polytechnic University, as well as successfully used by two Romanian software companies.
KEYWORDS
intelligent systems, data modeling, database constraints theory, relational constraints, non-relational con-
straints, integrity checking, data structures and algorithms for data management, triggers and rules, busi-
ness rules, (Elementary) Mathematical Data Model, MatBase, automatic code generation
1. INTRODUCTION
MatBase is an intelligent prototype data and knowledge base management system based on the
Relational Data Model [1, 5, 13] (RDM), Entity-Relationship Data Model (E-RDM) [4, 13, 25],
and (Elementary) Mathematical Data Model ((E)MDM) [12, 13, 14, 15, 16], built upon Relational
Database Management Systems (RDBMS), and currently having two versions: one in VBA on
MS Access and one in C# on MS SQL Server[17].
Any universe of discourse that is interesting for data modeling is made of object sets, their prop-
erties, and the business rules that are governing it. Mathematically, object sets are abstracted as
sets (be them atomic or relations, i.e. subsets of Cartesian products), properties as functions, and
business rules as first order predicate calculus closed formulas. In relational databases (dbs), sets
are implemented as tables, functions as their columns, and constraints either as relational ones,
enforceable in pure SQL and/or in the Graphic User Interfaces (GUI) of RDBMSes, or as non-
relational, enforceable with either extended SQL (generally with triggers) or/and a high-level
programming language embedding SQL (generally with trigger-type event-driven procedures).
RDM introduced five types of (relational) constraints: domain (range; codomain – mathematical-
ly), not null (totally defined – mathematically), key (uniqueness; minimally one-to-oneness –
mathematically), typed inclusion (referential integrity, foreign key; function images inclusion –
mathematically), and tuple (check; closed first order predicate calculus formulas having only one
variable universally quantified and whose functions have same domain – mathematically).

64
RDBMSesalso generally provide a sixth one, which is also provided by MatBase, namely column
(function – mathematically) default value. Both existing MatBase versions are enforcing these by
simply passing them to their RDBMS hosts [18].
In RDBMS, autofunctions (i.e. functions of type f :AB, with BA or AB) are implemented as
foreign keys referencing their table (e.g. in table PERSONS, having primary key x, both Mother
and Father are referencing x). Consequently, only not-null, key, referential integrity, and tuple
constraints are applicable to autofunctions, from the RDM point of view (plus the default value,
from the RDBMS’ one).
From the (E)MDM’s one (which also considers compound functions, not only singleton ones), for
any function there are also non-primeness (i.e. the function may not be part of any key), ontoness,
and bijectivity. As autofunctions are particular cases of dyadic relations, both (null-)reflexivity,
(null-)irreflexivity, (null-)symmetry, asymmetry, (null-)idempotence, anti-idempotence, canonical
surjectivity (ontoness), and acyclicity are also applicable, while (in)Euclidianity and connectivity
are not, as they do not make sense for functions [14].Moreover, general object constraints [14, 16]
are also possible for autofunctions too. This paper focuses on the algorithms used by MatBase to
enforce these latter 16 (non-relational) constraint types.
For example, such a non-relational constraint exists even in an extremely simple db consisting
only of the tables STATES(x, Country, State, StateCapital) and CITIES(x, City, State): “any state
has as capital a city of its own” (or, dually, “no state may have as its capital a city of another
state”). Considering functions State : CITIESSTATES and StateCapital: STATESCITIES, this
constraint can be formalized as StateStateCapital = 1STATES(where  denotes function composition
and 1STATES is the unity mapping of STATES, 1STATES(x) = x, x STATES) or, equivalently, as
StateStateCapital reflexive. This constraint is associated to the E-RD cycle from Figure 1 (where
StateCapital has a double arrow because it is one-to-one).
Figure 1. An example of an E-RD cycle having an associated non-relational constraint.
Failing to enforce this constraint could result, for example, in letting users store in such a db in-
stance the fact that London is the capital of Romania’s state Teleorman and/or that the Romanian
city Caracal is the capital of the U.S.’ state California!
From MatBase users’ point of view, all above mentioned first 15 non-relational constraint types
may be added / removed from a db scheme by simply clicking the corresponding check-boxes of
its FUNCTIONS form (be it standalone or as a sub form of the SETS_DETAILED one), available
in its Math Scheme submenu.
Removing such a constraint is straightforward: if it is implied by the rest of the constraints (e.g. if
f is asymmetric, you cannot remove its irreflexivity), MatBase does not allow it, while otherwise
it does, which means that the corresponding code enforcing that constraint is deleted from the
class(es) associated to the form(s) that manage(s) corresponding data (i.e. built upon the table cor-
responding to the autofunction domain).

65
Detecting that a constraint is implied by the rest of the constraint set to which it belongs, as well
as whether adding it to a constraint set would make that set incoherent is done by using the
knowledge base and algorithm presented in [14].
Whenever adding a constraint is preserving corresponding constraint set’s coherence, MatBase
automatically injects the needed code for enforcing it into the class(es) associated to the form(s)
that manage(s) the corresponding data (that are automatically generated by MatBase when the
corresponding domain set is added to the db scheme).Composed functions (e.g.
StateStateCapital above) may be either explicitly specified by users or automatically generated
by MatBase whenever it is detecting cycles in a db E-RD [16, 19].
As another example, even for only one table, e.g. PERSONS(x, FirstName, LastName, Mother,
Father, Sex, BirthDate, PassedAwayDate), where Mother and Father are acyclic autofunctions,
non-relational general object-type constraints may exist as well: mothers should have sex ‘F’, fa-
thers ‘M’, no child may be born either after his/her mother’s death, or more than 9 months after
his/her father’s death, etc. Constraints of this general type are expressible in MatBase in its
OBJECT_CONSTRAINTS form, where users are expected to type the corresponding formula in a
user-friendly first-order predicate calculus structured language. For the time being, neither coher-
ence, nor minimality is automatically enforced by MatBase for this constraint type but left to its
users.
MatBase, just like most of the db applications, is presenting auto functions to users as combo-
boxes in the form(s) built over the table corresponding to their domain. Generally [15], whenever
possible, non-relational constraints should be enforced preventively, by eliminating from these
combo-boxes all implausible data. When this is not possible [15], they should be enforced cura-
tively through extended SQL triggers or/andSQL embedding trigger-type methods.
For example, the reflexivity constraint associated to Figure 1 above is preventively enforced par-
tially with only two VBA / C# statements of the Current event-driven method associated to cursor
entering on a line: the first one dynamically changes the WHERE clause of the StateCapital com-
bo-box of the form(s) based on the STATE table, such that only cities belonging to the current
state are selected, and the second one re-queries the combo-box to apply its changed definition.
However, this constraint might be also violated whenever users were moving capital cities to an-
other state: therefore, MatBase also automatically generates code in the BeforeUpdate (for its MS
Access version) and Validating (for its MS .NET version) event-driven methods attached to the
State combo-box of class CITIES form(s) to reject such requests.
1.1 Related Work
Generally, there are very few results on non-relational constraints, except for (E)MDM related
ones ([12, 14, 15, 16,19]). The most closely related approaches are based on business rules man-
agement (BRM) [8, 9, 20, 24, 27] and their corresponding implemented systems (BRMS) and
process managers (BPM), like IBM Operational Decision Manager[10], IBM Business Process
Manager [6], Red Hat Decision Manager [21], Agiloft Custom Workflow/BPM [2],etc., generally
based on XML (but also on the Z notation, Business Process Execution Language, Business Pro-
cess Modeling Notation, Decision Model and Notation, or the Semantics of Business Vocabulary
and Business Rules), which is the only other field of endeavor trying to systematically deal with
business rules, even if informally, not at the db design level, but at the software application one,
and without providing automatic code generation. From this perspective, MatBase is also a
BRMS, but a formal, automatically code generating one.

66
A somewhat related approach as well is the logical constraint programming [7, 11, 22, 23, 26],
which aims only at solving polynomial-complexity combinatoric problems (e.g. planning, sched-
uling, etc.) [3].
1.2 Paper Outline
Section 2 introduces MatBase architecture. Section 3 describes the relevant portions of its Graph-
ical User Interface (GUI). Section 4, the paper’s core, presents the algorithms for enforcing non-
relational constraints. Section 5 illustrates them with examples. Section 6 discusses their com-
plexity, optimality, implementation, and utility. The paper ends with conclusion, further work,
and references.
2. MATBASE ARCHITECTURE
MatBase has a standard 4-tier architecture, whose tiers are (in the top-down order) the following:
GUI, business logic (BL), ActiveX Data Objects (ADO), and db (DB) [17].
The MS Access version DB is composed of two shared dbs, namely MatBaseDB.accdb and Geog-
raphyDB.accdb (stored on a file server folder, identified through network mapping as virtual logic
drive V:), and each workstation storing eight other dbs, namely MatBaseTmp.accdb, Geogra-
phyTmp.accdb, StocksDB.accdb, StocksTmp.accdb, BookstoreDB.accdb, BookstoreTmp.accdb,
UserDB.accdb, and UserTmp.accdb (stored in a folder declared, through subst, as being virtual
logic drive U:).
MatBaseDB contains the Matbase’smetacatalog (storing metadata on the managed dbs, tables,
constraints, etc.) and knowledge base (storing data on coherence and minimality of constraint
sets, Datalog inference rules, object constraint types ones, etc.). As MatBase also provides four db
application examples (Geography, shareable, Stocks, Bookstore, and User) there are also db files
storing their data. All needed temporary tables are stored in corresponding Tmpdbs.
In its MS SQL Server versions, all these 5 fundamental dbs are stored on a server instance,
whereas all temporary ones in the corresponding system tempDB db.
ADO is the (de facto industry standard) middleware between BL and DB, completely transparent
to programmers in the .net and SQL Server MatBaseversion, carrying SQL statements as strings
from BL to DB and returning error codes and selected data. In the Access version, ADO is also
explicitly used, as, for example, there is no CHECK constraint in its SQL.
For its both versions, BL is made of object-oriented classes (most of them also event-driven, as-
sociated to forms and reports) and libraries grouping methods commonly used by at least two
classes. Every db application has its own library (e.g. Geography, Stocks, Bookstore, etc.). Mat-
Base’s core has several specialized ones: Constraints,Datalog, ERD, General, Mappings, Sets,
and Tools, with General including methods, variables, and constants commonly used by at least
two other libraries.
For example, the Constraints one includes parameterized Boolean functions for enforcing object
constraints (enforceObjConstraint), autofunction reflexivity (autoFunctReflex), irreflexivity (au-
toFunctIrreflex), etc. Whenever the current data passed as parameters satisfies the corresponding
constraint, these functions return False, otherwise they return True (following the event-driven
methods’ Cancel parameter conventions).
Whenever enforcing of a non-relational constraint is possible (i.e. it would not violate coherence
or minimality of the corresponding constraint set and the current db instance satisfies it), MatBase
injects in the corresponding BeforeUpdate / Validating event-driven method associated to the cor-

67
responding autofunction (in the object-oriented class(es) of the form(s) associated with the table
corresponding to the autofunction domain set) an assignment of type Cancel = call to the corre-
sponding Boolean function from Constraints; therefore, if the returned value is False, then the
corresponding data update is accepted and saved in the db; otherwise, it is rejected with a corre-
sponding context-dependent error message and users are invited to modify it or cancel the current
request.
Constraints also includes Boolean functions is Coherent (checking that adding / removing a con-
straint satisfies or violates coherence),isValid (checking whether the current db instance satisfies a
given constraint), injectConstraint (inserting code lines into an event-driven class), deleteMod-
uleLines(deleting all lines in a class containing exactly a string parameter value), as well as many
other useful functions for automatically enforcing constraints like findModuleLines (returning the
first line number in a class containing a string parameter value), etc.
GUI includes a tree-like menu, forms, and reports, all of them carefully designed, as user-friendly
as possible. Each fundamental db table has at least one standard associated form, automatically
generated, which manages corresponding data management (i.e. inserts / updates / deletes).
3. MATBASE GUI FOR AUTOFUNCTIONS AND OBJECT CONSTRAINTS
In the MatBase MetaCatalog / Scheme Updates / EMDM Scheme submenu the form
FUNCTIONS may be opened either standalone (with the Mapping Set button of the Mappings
submenu), for managing all functions known to the system, or as a subform of the
SETS_DETAILS form (opened with the button Update SETS set by set button of the Sets sub-
menu), for managing functions grouped by their domain set; the form OBJECT_CONSTRAINTS
may be opened with the homonym button from the submenu Constraints of the same menu path.
The form FUNCTIONS displays one row per function (be it fundamental or computed). For com-
posed ones, another instance of it may be opened as a subform, displaying a line for each member
function, in their composition order. All metadata on functions is displayed and may be updated
in its column controls, from its name, domain, codomain, description, and up to its constraints
(except for the object-type ones). For constraint types, check-boxes are used, except for the de-
fault value one, which needs a text-box.For example, for StateStateCapital from Figure 1 only
the reflexivecheck-box should be checked; for Mother and Father, only the acyclic should be
checked, which triggers MatBase to automatically check the implied constraints asymmet-
ric,irreflexive, and anti-idempotentas well.
The form OBJECT_CONSTRAINTS displays one row per object constraint. For example, there
should be a line reading “for any x in PERSONS Sex(Mother(x)) = ‘F’” (which formalizes
“mothers should have sex ‘F’”), another one reading “for any x in PERSONS Sex(Father(x)) =
‘M’” (which formalizes “fathers should have sex ‘M’”), one reading “for any x in PERSONS
BirthDate(x) <= PassedAwayDate(Mother(x)) and BirthDate(x) <= PassedAwayDate(Father(x))
+ 9 * 30.5” (which formalizes “no child may be born either after his/her mother’s death, or more
than 9 months after his/her father’s death”), etc.
4. MATBASE ALGORITHMS FOR ENFORCING AUTOFUNCTION
AND OBJECT-TYPE NON-RELATIONAL CONSTRAINTS
Figure2 and 3 show the pseudocode algorithms for enforcing autofunction non-relational
constraints, which summarizes all the above and that are implemented in both current
MatBase versions:

68
ALGORITHM A1. MatBase Algorithm for Enforcing Object Constraints
Input: - a db scheme S, its associated OBJECT_CONSTRAINTS form instance,
the user request (delete / insert / update), andthe corresponding object
constraints from its current rowc and c’, the former one updated to c;
- Cancel = False;
Output: ifCancelthenSelse if deletethenS = S {c} else if insert thenS = S {c}
elseS = S {c’}  {c};
Strategy:
select user request
casedelete:
if user does not confirm his/her delete request thenCancel = True;
else
loop for allobject setss mentioned in the current object constraint c
loop for all event-driven methods of the classes associated to s
delete line assigning to Cancel the value returned by objConstraint for c;
end loop;
end loop;
S = S {c};
if there is no other object constraint of the type t of cthen
if user agrees with it thendelete t from the knowledge base;
end if;
end if;
case insert or update:
Cancel = isValid(c);
ifCancelthen
display “Constraint cannot be enforced: current db instance violates it!”;
else
ifc type is not known to the knowledge base then
save its type; // which also generates and saves in Constraints a
// corresponding method for enforcing it;
end if;
end if;
case insert:
ifnotCancelthen
loop for allobject sets s mentioned in the current object constraint c
loop for all event-driven methods of the classes associated to s that are
stored in the knowledge base for the type of c (and generate
all those that might be missing)
inject line assigning to Cancel the value returned by objConstraint for c;
end loop;
end loop;
S = S {c};
end if;
case update:
ifnotCancelthen
loop for allobject sets s mentioned in the current former object constraint c’
loop for all event-driven methods of the classes associated to s

69
delete line assigning to Cancel the value returned by objConstraint for c’;
end loop;
end loop;
loop for allobject sets s mentioned in the current object constraint c
loop for all event-driven methods of the classes associated to s that are
stored in the knowledge base for the type of c (and generate
all those that might be missing)
inject line assigning to Cancel the value returned by objConstraint for c;
end loop;
end loop;
S = S {c’}  {c};
end if;
end select;
End ALGORITHM A1;
Figure1. Algorithm A1 (MatBase Algorithm for Enforcing Object Constraints)
ALGORITHM A2. MatBase Algorithm for Enforcing Non-Relational Autofunction
Constraints
Input: - a db scheme S, its associated FUNCTIONS form instance, the user request
(check / uncheck), the corresponding function f:DD, non-relational
constraint type c from its current row, and the implied by c set I, as well as
the set I’ of the constraints implied only by c and not desired anymore in S;
- Cancel = False;
Output: ifCancelthenSelse if uncheckthenS = S {c}I’ else S = S {c}I;
Strategy:
select user request
case uncheck:
if user does not confirm his/her delete request then
Cancel = True;
check c’s checkbox; // undo request
else
if c is implied by some subset of constraints C’ then
Cancel = True;
check c’s checkbox; // undo request
display “Constraint cannot be deleted as it is implied by C’!”;
else
loop for allobject sets s that are domainsof the functions g composing f
loop for all event-driven methods of the classes associated to g
delete line assigning to Cancel the value returned for cby
the corresponding constraint type enforcement Boolean function;
end loop;
end loop;
S = S {c};
loop for all constraintsc’ in S that were implied only by c
if user wishes to keep c’ in Sthen
generate code needed to enforce c’;
else
S = S {c’};

70
uncheck c’s checkbox; // remove unwanted implied constraint
end if;
end loop;
end if;
case check:
Cancel = isCoherent(c);
ifCancelthen
uncheck c’s checkbox; // undo request
display “Constraint rejected: constraint set would become incoherent!”;
else
Cancel = isValid(c);
ifCancelthen
uncheck c’s checkbox; // undo request
display “Constraint cannot be enforced: current db instance violates it!”;
else
loop for allobject sets s that are domains of the functions g composing f
loop for all event-driven methods of the classes associated to g
(and generateall those that might be missing)
inject line assigning to Cancelthe value returned for c by
the corresponding constraint type enforcement Boolean function;
end loop;
end loop;
S = S {c}I;
loop for all constraints c’ in I
check the checkbox corresponding to c’; // store that f also obeys c’
end loop;
end if;
end if;
end select;
End ALGORITHM A2;
Figure 3. Algorithm A2 (MatBase Algorithm for Enforcing Non-Relational Autofunction Constraints)
5. EXAMPLES
Consider the ER-D from the Geography db presented in Figure 1. Suppose that the db instance
data satisfies constraint StateStateCapital reflexive and that adding this constraint does not vio-
late either coherence or minimality of the db constraint set [14].
Then, when users check the Reflexive check box on the StateStateCapital row from the
FUNCTIONS form, MatBase automatically adds code to both CITIES and STATES classes of
their standard management forms (generally homonyms to their underlying table names), as well
as to any other classes associated to forms built upon tables CITIES and STATES(that have, just
like all other fundamental tables, primary keys named x) and allowing updates to columns State
and/or StateCapital, the following code:
 In class STATES, preventively, to the Current event-driven method (automatically
launched by the system whenever the cursor arrives on a line of the underlying table
STATES), a line reading Cancel = preventReflex(“State =”,me!x) (in the MS Access ver-
sion; in the .Net one, me!x is replaced by this.x) is added (and if this event-driven method
does not exist, MatBasefirst creates it).

71
The public preventReflex function from the Constraint library has only two lines: the first one
modifies the row (data) source definitionof the current combo-box control by adding to its
WHERE clause a filter State = me!x and the second one requeries the combo-box.
In this case, if the initial row source definition is SELECT x, City FROM CITIES ORDER BY-
City, the modified one becomes SELECT x, City FROM CITIES WHERE State = me!x ORDER
BY City. Without this filter, on any row, the combo-box displays all cities from table CITIES.
With this filter, whenever the cursor arrives on a row for which, e.g. x = 1, the row source is
changed to SELECT x, City FROM CITIES WHERE State = 1 ORDER BY City, so, after re-
querying it, the combo-box will display only the cities that belongs to the state having its x = 1.
 As this constraint may also be violated by moving a state capital to another state, this must
be rejected for such cities. This is why, in class CITIES, to the BeforeUpdate(Validating in
.Net) event-driven method associated to the column controlState(automatically launched
by the system whenever its value has changed and users want to save its new value), a line
reading Cancel = enforceReflex(“STATES”, “StateCapital”,me!x) is added (and if this
event-driven method does not exist, MatBasefirst creates it).
The public enforceReflex function from the Constraint library has the following strategy:
enforceReflex = False;
if not new record then
if current city is a state capital then
enforceReflex = True;
undo user update;
display “Current city is the state capital: request rejected!”
end if;
end if;
Dually, when users uncheck the Reflexive check box on the StateStateCapital row from the
FUNCTIONS form, if users confirm their request MatBase automatically deletes the code it in-
jected (i.e. both Cancel = preventReflex(“State =”,me!x) from STATES and Cancel = enforceRe-
flex(“STATES”, “StateCapital”, me!x) from CITIES).
As another example, suppose that a user adds in the OBJECT_CONSTRAINTS forms a row whose
Constrainttext-box reads “for any x in PERSONS BirthDate(x) <= PassedAwayDate(Mother(x))
and BirthDate(x) <= PassedAwayDate(Father(x)) + 9 * 30.5” and that the current db instance sat-
isfies it. Then, MatBase automatically adds in the classes attached to the forms based on the
PERSONS table that allow updates to the BirthDate, PassedAwayDate,Mother, and/orFather the
following code (supposing that this constraint gets the x identification value 1):
- In the event-driven method BeforeUpdate / Validating associated to the BirthDate control a line
reading Cancel = enforceObjConstraint(1, “PERSONS”, “BirthDate”);
- In the event-driven method BeforeUpdate / Validating associated to the PassedAwayDate con-
trol a line reading Cancel = enforceObjConstraint(1, “PERSONS”, “PassedAwayDate”);
- In the event-driven method BeforeUpdate / Validating associated to the Mother control a line
reading Cancel = enforceObjConstraint(1, “PERSONS”, “Mother”);
- In the event-driven method BeforeUpdate / Validating associated to the Father control a line
reading Cancel = enforceObjConstraint(1, “PERSONS”, “Father”);
- If any of these event-driven methods does not exist, MatBase first creates it.

72
The public Boolean enforceObjConstraint function from the Constraint library(one of the most
complex ones) enforces such constraints according to their corresponding formula type and given
parameters (object constraint id, set / table name, and function / column name).
Dually, when users delete this object constraint from the OBJECT_CONSTRAINTS form, Mat-
Base deletes all four lines injected as above.
6. RESULTS AND DISCUSSION
6.1 Algorithms Complexity, Optimality, and Implementation
It is very easy to check that these algorithms are very fast, as they do not ever infinitely loop and
their time complexitiesare linear:O(2 * k * (|F|)) = O(|F|) for A1 and O(k * (|F| + |I|)) = O(|F| + |I|)
for A2.For both, k is the average number of forms built over fundamental tables (which is general-
ly between 1 and 2).
For A1, |F| is the average number of functions used in an object constraint (multiplied by 2 in the
worst case, i.e. update, for which MatBase needs to both inject code for c and delete code for c’);
generally, this never approaches 100 (conjecture we are advancing after 40+ years of experience
in data modeling for lot of industries and services).
For A2, |F| is the average number of functions that are members of a composed function (general-
ly at most 8, as circular E-RD cycles having length greater than 16 are very hard to detect and
even harder to analyze for discovering associated autofunction constraints [19]) and |I| is the av-
erage number of implied constraints by a non-relational autofunction constraint (generally be-
tween 0 and 5 [16]).
Moreover, these algorithms are, in fact, also optimal, as they search in every object-oriented class
only within the event-driven methods and no such method is visited twice: their implementations
merge for updates in A1and deletions in A2 code injections and deletions in a same step, whereas
checking of implied constraints by a newly added one in A2 is done in internal memory (and are
saved in the db together with the one done by users in c’s checkbox, when the current row corre-
sponding to f from FUNCTIONS is saved).
In fact, A1 is not implemented as such in MatBase, but split into the event-driven methods
OnDelete (for delete requests) and BeforeUpdate / Validating for the control ObjectConstraint
(for insert and update requests) of the form OBJECT_CONSTRAINTS. A2 is implemented in the
BeforeUpdate / Validating for checkbox controls associated to the non-relational constraint types
of the form FUNCTIONS.
6.2 Algorithms Usefulness
First, analyzing non-relational constraints is interesting even per se, within the study of sets, func-
tions, and relations semi-naïve algebra, as well as the one of data modeling and db constraint the-
ory, as it helps getting a better understanding on both single and compound autofunctions. More-
over, the object-type constraints are excellent real-world examples of closed first order predicate
calculus with equality formulas.
The main utility of these algorithms is, of course, in the realms of data modeling, db constraints
theory, db and db software applications design and development. All constraints (business rules)
that are governing the sub-universes modeled by dbs, be them relational or not, should be de-

73
clared in the corresponding mathematical dbs’ schemas and then enforced in its implementations:
otherwise, their instances might be implausible.
Generally, almost all autofunctions have associated non-relational constraints [16].For example,
in the Geography db there are 7 compound autofunctions that are reflexive, 8asymmetric, 7 irre-
flexive, one acyclic, and 16 have associated object constraints [16].
7. CONCLUSION AND FURTHER WORK
In summary, we have designed, implemented, and successfully tested in both MatBase current
versions (for MS Access and C# and SQL Server, respectively) algorithms for automatic en-
forcement of the non-relational constraints associated to autofunctions, analyzed their complexity
and optimality, as well as outlined their usefulness for both sets, functions, and relations algebra,
and, especially, for data modelling, db constraints theory, db and db software application design
and development practices.
Unfortunately, except for MatBase and BRMS users, the state of the art in db and db software
application design and development related to non-relational constraints is exclusively using ad-
hoc approaches: very few db and/or software architects are aware of their types, optimal enforc-
ing ways per type, algorithmic approaches to discover all of them for any sub-universe of dis-
course, automatic enforcement, and even of their paramount importance; only from experience
and common sense (e.g. nobody may be simultaneously present in several places, no slot may be
simultaneously occupied by several objects, etc.) are they considering some such constraints and
enforce them in db software applications (through either RDBMS triggers in extended SQL
or/and high-level programming languages embedding SQL trigger-type methods).
Very many such constraints are only discovered in production, in time, generally by db software
application users, who report them as bugs. It would be highly preferable, of course, that db and
software architects discover all of them in the data modeling phase and then developers enforce
them from the beginning, up until MatBase (or/and other similar advanced DBMS products) will
become worldwide available, to provide automatic code generation for enforcing non-relational
constraints too, just like it is the case today with the relational ones.
The algorithms presented in this paper are successfully used both in our lectures and labs on Ad-
vanced Databases (for the postgraduate students of the Mathematics and Computer Science De-
partment of the Ovidius University, Constanta and the Computer Science Taught in English De-
partment of the Bucharest Polytechnic University), as well as by two Romanian IT companies
developing db software applications for many U.S. and European customers in the Fortune 100
ones, whose productivities have greatly increased ever since, as lot of software designing, devel-
oping, testing, and debugging efforts are spared by MatBase automatic code generation.
In fact, MatBase is automatically generating code for enforcing non-relational constraints not on-
ly for autofunctions, but also for the rest of the functions (including Cartesian product ones), as
well as for sets, which makes it also a formal BRMS and adds (E)MDM to the panoply of tools
expressing business rules.
Further work needs to be done for also assisting users in guaranteeing coherence and minimality
for object-type constraints. This is not at all an easy task, as even the problem for the subclass of
first order calculus predicate closed formulas is NP-complete.

74
REFERENCES
[1] Abiteboul, S., Hull, R., Vianu, V.:Foundations of Databases. Addison-Wesley, Reading, MA (1995).
[2] Agiloft Reference Manual,https://www.agiloft.com/documentation/agiloft-reference-manual.pdf, last
accessed 2019/03/28.
[3] Baptiste, P., Le Pape, C., Nuijten, W.: Constraint-Based Scheduling. Kluwer Academic Publishers,
Dordrecht, NL (2001).
[4] Chen, P. P.: The entity-relationship model: Toward a unified view of data. ACM Transactions on
Database Systems 1(1), 9–36 (1976).
[5] Codd, E. F.: A relational model for large shared data banks. CACM 13(6), 377–387 (1970).
[6] Dyer, L., et all.: Scaling BPM Adoption from Project to Program with IBM Business Process Man-
ager. ibm.com/redbooks,http://www.redbooks.ibm.com/redbooks/pdfs/sg247973.pdf, last accessed
2019/03/28.
[7] Fourer, R., Gay, D. M.: Extending an Algebraic Modeling Language to Support Constraint Pro-
gramming. INFORMS Journal on Computing, 14 (4), 322–344 (2002).
[8] von Halle, B.: Business Rules Applied: Building Better Systems Using the Business Rules Ap-
proach. John Wiley and sons, New-York, NY(2001).
[9] on Halle, B., Goldberg, L.: The Business Rule Revolution. Running Businesses the Right Way. Hap-
py About, Cupertino, CA (2006).
[10] Kolban, N.: Kolban’s Book on IBM Decision Server Insights.
ibm.com/redbooks,http://neilkolban.com/ibm/wp-content/uploads/2015/06/Kolbans-ODM-DSI-
Book-2015-06.pdf, last accessed 2019/03/28.
[11] Krzysztof, A.: Principles of Constraint Programming. Cambridge University Press, Cambridge, UK
(2003).
[12] Mancas, C.: On Modeling Closed E-R Diagrams Using an Elementary Mathematical Data Model. In:
Proc. 6th ADBIS Conference on Advances in DB and Inf. Syst., pp. 65-74. Slovak Technology Uni-
versity Press, Bratislava, Slovakia (2002).
[13] Mancas, C.: Conceptual Data Modeling and Database Design: A Completely Algorithmic Ap-
proach. Volume I: The Shortest Advisable Path. Apple Academic Press / CRC Press, Waretown, NJ
(2015).
[14] Mancas, C.: MatBase Constraint Sets Coherence and Minimality Enforcement Algorithms. In:
Benczur, A., Thalheim, B., Horvath, T. (eds.),Proc. 22nd ADBIS Conference on Advances in DB
and Inf. Syst., pp. 263-277. LNCS 11019, Springer (2018).
[15] Mancas, C.: Conceptual Data Modeling and Database Design: A Completely Algorithmic Approach.
Volume II: Refinements for an Expert Path. Apple Academic Press / CRC Press (Taylor & Francis
Group), Waretown, NJ (2019, in press).
[16] Mancas, C.: MatBase E-RD Cycles Associated Non-Relational Constraints Discovery Assistance
Algorithm. In: Intelligent Computing, Proc. 2019 Computing Conference, AISC Series 997, vol.1,
pp. 390 – 409, Springer Nature, Switzerland(2019).

75
[17] Mancas, C.: MatBase – a Tool for Transparent Programming while Modelling Data at Conceptual
Levels, In: Proc. 5th
Intl. Conf. on Computer Science, Information Technology (CSITEC 2019), pp.
15 – 27, AIRCC Pub. Corp., India (2019).
[18] Mancas, C., Dorobantu, V.: On Enforcing Relational Constraints in MatBase. London Journal of
Research in Comp. Sci. and Technology 17, 1 (Jan. 2017), 39-45 (2017).
[19] Mancas, C.,Mocanu, A.:MatBase DFS Detecting and Classifying E-RD Cycles Algorithm. Journal
of Computer Science Applications and Information Technology2 (4), 1–14(2017).
[20] Morgan, T.: Business Rules and Information Systems: Aligning IT with Business Goals. Addison-
Wesley Professional, Boston, MA (2002).
[21] Red Hat Customer Content Services: Getting Started with Red Hat Business Optimizer.
https://access.redhat.com/documentation/en-
us/red_hat_decision_manager/7.1/pdf/getting_started_with_red_hat_business_optimizer/Red_Hat_D
ecision_Manager-7.1-Getting_started_with_Red_Hat_Business_Optimizer-en-US.pdf, last accessed
2019/03/28.
[22] Richters, M.: A Precise Approach to Validating UML Models and OCL Constraints. Logos Verlag,
Berlin, Germany (2001).
[23] Rina, D.: Constraint processing. Morgan Kaufmann Publishers, Boston, MA (2003).
[24] Ross, R. G.: Principles of the Business Rule Approach. Addison-Wesley Professional, Boston, MA
(2003).
[25] Thalheim, B.:Fundamentals of Entity-Relationship Modeling. Springer-Verlag, Berlin, Germany
(2000).
[26] Thom, F., Abdennadher, S.: Essentials of Constraint Programming. Springer-Verlag, Berlin,
Germany (2003).
[27] Weiden, M., Hermans, L., Schreiber, G., van der Zee, S.: Classification and Representation of Busi-
ness Rules. In: Proc. 2002 European Business Rules Conference, http://www.omg.org/docs/ad/02-
12-18.pdf, last accessed 2010/07/02.
AUTHOR
Christian Mancas has graduated in 1977 the Computers Department of the
Politehnica University of Bucharest, Romania. He obtained his PhD degree in
1997 from the same as above Department. He first worked as a software engineer
and, since 1980, R&D manager of a Computer Centre in Bucharest. Since 1990,
he worked for several IT start-ups, including his owns, as data architect, software
infrastructure manager, etc. Since 1998, he is an Associate Professor with both the
Mathematics and Computer Science Department of the Ovidius University, Con-
stanta and Engineering Taught in Foreign Languages Department (Computer Sci-
ence and Telecommunications in English stream) of the Politehnica University, Bucharest, Romania (as an
invited Professor).

MATBASE AUTO FUNCTION NON-RELATIONAL CONSTRAINTS ENFORCEMENT ALGORITHMS

More Related Content

What's hot (20)

Similar to MATBASE AUTO FUNCTION NON-RELATIONAL CONSTRAINTS ENFORCEMENT ALGORITHMS (20)

Recently uploaded (20)

MATBASE AUTO FUNCTION NON-RELATIONAL CONSTRAINTS ENFORCEMENT ALGORITHMS