Binary Relational Modeling

Introduction

The version of BRM presented here is a concept for defining and visually representing sets and relations between elements of those sets. With the addition of implementation of uniqueness constraints, BRM could play the role of SQL in a (programming language + SQL) platform. BRM can also give some groundings for universal knowledge base representation. Moreover, with the addition of supporting dynamics of sets' elements, BRM can be used as a base for a complete programming paradigm. For the sake of simplicity, there are only two different building components: sets and named binary relations. These two components are just about enough to construct complex data definitions that reflect bindings between elements in different sets. The real value of BRM graphs is in their simplicity while allowing enough expressiveness for complex data definition. Just to get an impression of how a BRM graphs look like, an example of a graph describing an organization with its personnel is shown in figure 1:

If you are familiar with relational databases

Relations used in a BRM are actually many-to-one relationships. Besides their regular use, they can be used to express definitions of tables and their columns. It also turns out that many-to-many and one-to-one relationships can be represented using BRM relations. Many-to-many relationships can be expressed by using an intermediate set with a complementary pair of BRM relations (experienced database users will be familiar with this technique). One-to-one relationships can also be expressed in a similar way like many-to-many relationships, but with some unique constraints.

Basics

Before we dive into a deeper discussion, let's take a look at another example of a BRM graph. Figure 2 defines a simplified database for publishing articles:

As we can see, there are only two different building components: named rounded rectangles and named arrows. Those named rounded rectangles represent sets and those named arrows represent named binary relations (binary relations from now on). These sets are named collections of some elements. BRM graphs show only notions of sets and their binary relations, but not individual elements of sets.

A binary relation over two sets is a notion that state the presence of bindings between elements of two engaged sets. Binary relations are identified by their name. Each binary relation also has its direction which is shown by an arrow, pointing from one set to the other. We shall say that every binary relation "relates sets' elements from its source set to its destination set" where the source and destination sets are assumed by the arrow direction.

Looking at the direction of the arrow, a relation allows bindings of any element of its source set to any, but only one element of its destination set. In figure 1, set Person is a source set of binary relations name and surname. That means that each person can have exactly one name and one surname, both represented by some text. Analogously, each Article can be related to one instance of author, title, description, and content.

Looking backwards on the direction of arrow, another light is being put on the source and destination sets. We already know that each source set's element can point to one destination set's element. But it is also possible that any number of source set elements point to the same destination set element. This is a very important point where many-to-one binding is made between source and destination sets, respectively. If we take a look at the binary relation author, we'll see that the relation has its source in set Article and destined to set Person. It means that any number of articles can have the same author (one person).

Relation issues

Binary relations between sets in a BRM graph really represent the classic many-to-one relationships between elements, as simple as that. So we may conclude that many-to-one relations are supported.

In the real world, there also exist many-to-many types of binding. When analyzing figure 2, we can see that each article can have one author. But in reality, each article can be contributed by several authors while each author can be involved in writing several articles. That would require a many-to-many binding between relevant sets, instead of the current many-to-one binding. BRM essence has only one type of relation, standing for many-to-one binding. But these relations can be combined into a composition equivalent to a many-to-many binding. This binding can be expressed by introducing a new set and two new binary relations. The new set will be a source for new binary relations which will be destined to the original sets involved in binding. In figure 3, to upgrade the binary relation author to a many-to-many binding, these new components are introduced: set "Author" and relations "represented by" and "wrote". The new set Author is a source of its new binary relations that is destined to sets Person and Article, forming a many-to-many binding between these sets.

When defining many-to-many bindings, sometimes we need to attach extra information for each binding. The example is classic teacher-class lecturing database where each teacher can be lecturing in many classes, while each class can be lectured by many teachers. Extra information we might need is, for example, the number of lessons that a teacher has to carry out with each class. BRM is capable of managing this requirement at the essence level, as is shown in figure 4:

One-to-one relationships can be stored like many-to-many relationships in an intermediate set with the restriction of uniqueness of both of its binary relations. We'll talk about uniqueness constraints later.

What about n-ary relationships? Yes, they are also supported in a way that every n-ary relationship can be turned into an equivalent composition of binary relationships. How this is done is shown in figure 5:

Sometimes it's required to define recursive binary relations. These are merely ordinary binary relations having the same set for the source and destination. An example is given in figure 6:

Just to test the completeness of the BRM concept, we can take a look at the very BRM definition in itself. An assumption is made that there must exist a starting primitive set Text that will contain data end points. As we can see from figure 7, BRM is capable of holding such a definition:

Sets as elements

If we consider sets as elements of other sets, a very important point can be reached in defining a knowledge pyramid. This point gives us the possibility to choose different forms of data contained in the same set. For example, one person could be a host or a guest, having different additional descriptions according to the person's role. This is shown in figure 8:

Figure 8 shows some sets as elements of destination sets for the binary relations species and tourism role. For some person, if we choose Female as species, we get access to two additional binary relations: orientation and radiation. On the contrary, if we choose Male as species, we get access to has beard as an additional binary relation. Analogically, the sets Guest and Host define their own additional specifications. Here we have made an effort of bringing a set's elements in the BRM graph.

Interface for querying elements

A set can have any number of elements that can be enumerated by some query expression. Expressions for querying sets' elements should include some syntax for selecting a range of elements. A query could be implemented as a boolean expression that could be tested for each element of a given set, filtering only the elements that pass the rules. Queries could form destination sets of binary relations, allowing automatic sets' content that depends on the required rules. For example, a query for getting a list of guests from some country could look like this:

SELECT Person WHERE (tourism role == Guest) AND 
   (tourism role.country == "some country")

With these kinds of queries, it should also be possible to get results of functions stored in the form of semantic tables in sets' contents. These queries can be seen as expressions that automatically compute their values as queries' parameters change through time. So queries give us a possibility of describing mutually dependent expressions.

About uniqueness constraints

Visual representation of uniqueness of specific binary relations regarding some source set could complicate BRM graphs whose main advantage is in its simplicity. However, uniqueness of elements might be a very important thing in defining sets. A specific implementation of uniqueness can be made in many different ways, embracing different rules of when different uniqueness constraints take place. Even the quantity of relation elements or conditional uniqueness might be specified. Because the extreme complexity of uniqueness matter, it will not be standardized here, in BRM graphs. Programmers are called to implement uniqueness in a way they find most convenient.

About elements of sets

Elements can be considered as notions that hold relation bindings to other elements. Each element can specify each binary relation that sources from its set. Binary relations that source from some set actually define the form of elements contained in that set.

Sets can also have an interface for modifying its content. This interface can have commands for inserting, modifying, and deleting elements.

Sets can be used in three different ways:

• If a set represents input from some outer system (i.e., keyboard), then its elements can be updated directly from the outer system. Those changes can be queried and used to update other sets. Events for detecting data changes can be generated when the input set is modified.
• A set can also represent output to some outer system (i.e., screen). The outer system could constantly watch for changes of the output set's elements and could act according to changes of contents of the output set.
• And finally, as bound from the input system to the output system, some internal sets can be defined. These internal sets can be modified and queried to adjust the output system according to the input system.

We can say that definitions of sets' binary relations are the static side of dynamic data represented by sets' elements. Sets can also be elements of other sets. In that case, sets as elements can be altered in their structure, providing dynamics of set's definitions.

Interface for modification of elements

Expressions for modifying contents of sets should have the notions for adding, modifying, and deleting sets' elements. Those expressions should have the possibility of reflecting the dynamic nature of data. Let's call expressions that modify elements as actions. Each action that is related to some set should have defined an event that triggers that action. The event should be in the form of a boolean expression, so when that expression turns from false into true, an event can be generated. Actions triggered by events give us the possibility of expressing and memorizing the side effects and provide data dynamics.

Conclusion

With the addition of some syntax for querying data, BRM could play the role of SQL in a (programming language + SQL) platform. The concept could also be the inspiration for automatic derivation of an end-user interface dealing with records. On a more enthusiastic view, with the addition of some syntax for altering elements of sets, BRM could represent a base for a completely new programming paradigm. BRM leaves a good impression, but it’s impossible to predict how things will work out in practice. Will the concept be implemented in real world applications? It’s probably up to some individual programmer who might or might not be subjective enough to give it a try.