The relational model is based on set theory and set operations while the concept-oriented model is based on lattice theory and ordered set to describe its syntax and semantics.
The relational database manages records in tables while the concept-oriented model manages item connections because each item is defined via other items and an isolated item does not have its own non-primitive semantics. The concept-oriented semantics is intrinsically distributed over all items rather than encapsulated in one record.
The concept-oriented model is intrinsically multidimensional and hierarchical while the relational model in this sense has a flat structure because tables are not ordered. In the relational model table do not have a concrete position in the space of other tables. Even if we can imagine such a space the database does not take it into account. In contrast, for the concept-oriented model the position of concept among other concepts is a primary factor, which determines all other issues. Each concept is either higher than another concept (more abstract representation), or is lower then another concept (more detailed representation) or they are incomparable (orthogonal). Thus we can combine in one model both the properties of hierarchy and the properties of multidimensionality.
The concept-oriented data model emphasizes the global connectivity of data semantics, i.e., it is one complete model where parts cannot be separated without influence the model semantics. This means that each item is characterized by other items, which in turn are characterized by other items and so one. For example, what is an order? When it is created it is a reference but then it gets some semantics when we add the date of creation and associate it with some customer. So the customer here is not an object - it is a part of order description. After that we might add order parts and here again it influences the original order. Moreover, when we update the customer address the order also changes its semantics indirectly. Of course, the relational model also has such interconnections but in the concept-oriented approach such connections are of primary importance. In particular, they are well formalized and are in the basis of its semantics.
The relation model of data fails to solve the problem of logical navigation (it main advantages of the previous models consists in solving the problem of physical navigation). The concept-oriented model solves this problem in a principled manner. For example, such a simple data access operator as referencing a record is written as follows in COM: account.owner.address.street. In relational model the same operator is implemented by manually specify several intermediate join conditions because the database is almost unaware of the connections between records. However, COM goes further automates logical navigation by means of two operations: projection and de-projection.
The relational model fails to solve the problem of multi-valued attributes. In the concept-oriented model multi-valued attributes are modeled via inverse dimensions.

1.2 How references differ from primary keys?

Primary key is a normal column adapted to special purposes. Reference is an initially special mechanism, which has much less to do with object properties. In other words, reference is NOT a column or dimension. It is a separable part of an object, which is intended to represent the source object in another space. In fact, reference may have properties (both its own and object's) but the difference from primary key is in the role of the identifier.

1.3 Is it possible to model the concept-oriented model by means of secondary keys?

Yes, it is possible to some extent but it will require significant efforts and manual implementation and control of many features. In addition, it will require following a strict discipline in using this model. Although for restricted use such an simulation is possible, in general case this approach does not guarantee that all moments will be taken into account. This question is somewhat similar to object-oriented programming using only procedural programming language facilities where we need to manually implement some convenience techniques and follow the object-oriented discipline. The relational model and its implementations in the state of the art DBMSs is rich enough to simulate other data models. However, the main advantage of the concept-oriented approach is in its simplicity, reliability, flexibility and expressiveness in describing real problem domains.

1.4 Do normal forms exist in COM?

In relational model there is a problem of normalization, which consists in satisfying particular criteria by the data schema. In such a form this problem does not exist in COM because COM can be viewed as normalized by definition because COM enforces a concrete structure of concepts. However nothing prevents us from formulating the problem of normalization in some other modified form. In relational model the problem of normalization is especially actual because this model does not separate object representation functionality from semantic characterization and treats primary keys as normal columns. In other words, we define columns and then specify the role of some of them as representatives of the whole record. In COM we explicitly separate these functions in a principled manner by using the mechanism of references for object representation purposes and object characteristics or dimensions for semantic characterization. Although it is quite possible to use some semantic characteristics to represent an object, this is considered a kind of optimization or a trick, which is not encouraged. By postulating such a separation of functions we solve many serious problems, particularly, the problem of normalization. Actually, the normalization problem does not disappear at all but rather it takes another interpretation.

1.5 How primary keys can be modeled in COM?

In the two-level concept-oriented data model there exist only one root element, a number of concepts each having a number of items where items are identified via their references. Item references have system default format. In the case the default format is a restriction for developing a model, it is possible to define an arbitrary format of item references as a set of fields. This new format is analogous to primary keys. However, in contrast to primary keys in the relational model, the format of references is dual to the format of items themselves. In the concept oriented programming (COP) the format of references is defined by the reference class while the format of items is described by the object class. In the relational model primary key is defined by assigning special role to columns.

2 Object-Oriented Model

2.1 Is there inheritance in COM?

Strictly speaking no, there is no inheritance in COM. Each concept has a number of superconcepts, which are not considered base concepts as it is treated in object-oriented paradigm. In particular, a subconcept is not formally supposed to extend or specialize its superconcepts. The main role of the subconcept consists in defining the possible structure of its items as a combination of items taken from the superconcepts (and not from any other concept).

There exists the following interconnections between the conventional inheritance and the concept-oriented model:

A subconcept could be considered an extension of its superconcepts considered as base concepts.
An inheritance could be considered a special mechanism where subconcept is in one-to-one relationship to its superconcept. In this case each base concept is guaranteed to have only one extended concept.
An inheritance could be applied to concept definitions only. Such concept definitions could be considered types and the we might extend the types by adding additional properties. The types can be then used to create instances of concepts. For example, having a type Contacts each user could create its own list of contacts as one instance.

2.2 What are differences between inheritance and subconcept-superconcept relation?

Subconcept-superconcept relation allows for superitem (base object) sharing, i.e., one superitem is used in many subitems.
Both superitems (base object) and subitem (extension) have their identity (reference) in CO approach while in OO approach base and extension are represented by one reference.
In CO approach all superconcepts have equal rights and there are no other means to describe extensions while in OO approach there exist two types of elements for specialization: base classes and fields.
In CO approach there is normally many superconcepts for each subconcept while in OO approach there is typically one or a few base classes. In particular, a subconcept with a single superconcept does not add any specifiety to the superconcept and is semantically identical to it.
In CO approach subconcept-superconcept relation is not (primarily) interpreted as a means of specialization and reuse like in OO approach. It is more semantically rich because of its interpretation as item inclusion and item characterization. It is this interpretation what allows applying them to describe real data semantics from various problem domains.

2.3 What is the difference in object definition?

In the object-oriented approach object is a piece of information with its own identity, which distinguishes it from other objects. In COM it is also true because each data item has its identity represented by the reference. However, a subtle difference is that in COM an object does not have its own (private or internal) semantics and in this sense it is distributed all over the concept structure. In other words, the object semantics is expressed via other objects and generally we can find this object parts in very different concepts represented by other objects. This is a consequence of the principle that object is distributed in the space horizontally (multidimensionally) and vertically (hierarchically). In particular, we can produce an abstract view of an object and more specific and detailed view of this very object. So in the concept-oriented approach we essentially do not know what object is. For example, is an order item its reference, its date of issue or an address of its customer? We do not know. It depends on what do we need at this current moment. In the object-oriented approach we have arbitrary references between objects but we do not know how to interpret them. Thus each reference has its own interpretation, which is not an integral part of the model. The only thing we can do with reference is to follow it. In the CO approach the database knows precisely the meaning of references and this is why they cannot be used arbitrarily - creating one new reference adds concrete piece of semantics to the whole database and we have to understand what does it mean.

3 Formal Concept Analysis

3.1 What is formal concept analysis?

The goal of the Formal Concept Analysis (FCA) consists in developing methods for representation and analysis of data. Its specific feature is that the data is structured into units, which are formal abstractions of concepts of human thoughts allowing meaningful and comprehensive interpretation. FCA is heavily based on the lattice theory and essentially it can be viewed as an adaptation of lattice theory to the needs of data representation and analysis.

3.2 What is an FCA syntax?

FCA syntax is described by a set of attributes M.

FCA attributes are analogous to COM primitive concepts of binary type. Such an COM concept might have two items 0 and 1 or, alternatively (and better), it might have a single item 1 while the second value is denoted by null. Thus an object either takes the only concept value 1 or null.

3.3 What is FCA semantics?

FCA semantics is described by a set of object G where each object is characterized by a subset of attributes. This information is represented by a so called incidence relation I in G x M. A triple <G,M,I> is called an FCA formal context. An alternative (equivalent) approach is where each object is represented as a set of its binary characteristics corresponding to FCA attributes. If an object is characterized by an attribute then the attribute value is 1, otherwise the value is 0. All objects are characterized by a common set of attributes and live in one space G. This space is an COM concept (not FCA concept). FCA objects are analogous to COM items.

3.4 What is an FCA concept?

FCA concept is a subset of objects and a subset of attributes, where the subset of attributes precisely describes the set of objects (and dually, the subset of objects precisely covers the subset of attributes). A subset of objects is said to be concept extent while the subset of attributes is said to be the concept intent. This definition means that if an additional object is added to the concept extent then we have to add also attributes to cover this new set of objects (otherwise it is not an FCA concept). Dually, if we remove some attribute from the concept intent then we have also remove some objects (otherwise it is not an FCA concept).

3.5 How FCA concepts are specified?

FCA concepts cannot be directly specified because they are derived from FCA semantics and depend on this semantics, i.e., if FCA semantics changes then a set of FCA concepts also changes. For example, if objects change their attribute values or objects are deleted/added then a set of concepts may change. Thus the only way to change a set of FCA concepts consists in changing FCA semantics.

4 OLAP and Multidimensional Databases

4.1 What is an OLAP dimension?

An OLAP dimension is a concept hierarchy where superconcepts correspond to abstract representation with low details while subconcepts correspond to detailed representation. The items are values of this OLAP dimension representing objects with different levels of details.

4.2 What is an OLAP measure?

An OLAP measure is defined precisely like OLAP dimension, i.e., it is a concept hierarchy. Normally however, OLAP dimension has a numeric type so that its items can be arithmetically aggregated. In general case the measure could be non-numeric or even multidimensional where it is a product of several concepts (like dimensions).

4.3 What is drill down and roll up?

Drill down corresponds to choosing a subconcept of the current concept involved into the OLAP dimension. Thus we move to more detailed view because subconcepts have more detailed items. Roll up is an opposite operation of moving to a superconcept of the current concept. Thus changing the current concept we can the level of details. Generally there are more than one superconcept and subconcept defined for an OLAP dimension so the choice may be more complex.

4.4 What is an OLAP cube?

An OLAP cube is the product of the current concepts chosen for each dimension, which consists of a combination of all items from the current concepts. Each such combination of items is called a cell. By applying drill down and roll up we can change the current concepts and thus change the OLAP cube and its granularity.

4.5 What is an OLAP representation?

An OLAP representation is function, which assigns one measure value for each item from the OLAP cube. This means that for each combination of items from the concepts selected in the OLAP dimensions this function finds some item from the measure concept. In general case the measure is not necessarily numeric and then the function assigns any item to each cell in the OLAP cube.

5 Ontologies

5.1 How knowledge is shared in COM?

In the concept-oriented data model higher level concepts are supposed to be more stable because they describe common terms used in subconcepts. In other words, the syntax and semantics of superconcepts changes much less frequently then those of the subconcepts. The terms in the concept-oriented model are items (not concepts) from the common superconcepts. Having a common set of superconcepts with its term items allows us to position our own custom items in one and the same common space. In other words, such an approach allows sharing the space structure and its coordinate system. In order to define a new item we have to specify its position in this common space by specifying its coordinates from the superconcepts. Thus we can link our new custom terms to the system of common terms.

An example of such a common system of terms might be a product categorization schema, which consists of a set of concepts along with their semantics describing a list of products. Once such a schema has been fixed it can be shared among participating agents. This guarantees then that their own more specific databases will be linked against one system of product categorization. As a consequence the agents can exchange information and understand it because understanding means having a common system of terms or living in one space.

The most primitive knowledge sharing system is that of numbers. Nobody asks what number 10 means because everybody has the primitive concept of real numbers stored in its knowledge base. The concept-oriented approach allows sharing much more complex knowledge. This is equivalent to standardizing the space structure where we live.

6 Semantic Web and RDF

6.1 What are main differences between RDF and COM?

RDF syntax is represented by a set of resources identified by their references. These resources have three major types: subject, predicate and object. Subject is an item, i.e., a characterized entity. Predicate is a relation or characteristic. Object is a characterizing object or attribute value.
All syntactic elements have their references in RDF. In COM only items (semantic element) have their references while syntactic elements (concepts, dimensions) do not. (Syntactic elements may have reference on other levels of description, see COFS.) This reflects the principle of separation of space and objects in it.
RDF semantics is represented by triples subject-predicate-object. These triples themselves could be considered a resource and be involved in other triples.
The main indivisible unit of representation in RDF is a triple of subject-predicate-object while in COM it is an item. In COM it is very important that item characteristics (superitems) are not separable, i.e., all superitem references are stored alongside. Such a composition reflects the nature of objects, i.e., object is something integrated and inseparable in space. Object is one point, which cannot be distributed in space by definition. In RDF it is not so because an elementary semantic unit is the triple, which is a part of the whole description.
RDF is based on logic while COM is relies more on lattice theory and ordered sets.
Similar to RDF approach is used also in the associative database model and Entity-Attribute-Value (EAV) model.
RDF has classes as a separate mechanism for imposing constraint and reused. COM does not have classes in their traditional form. COM has types for describing concepts, which are however an additional mechanism.

7 Object-Role Modeling

7.1 What are main differences between ORM and COM?

At the fundamental level, ORM views the world in terms of objects playing roles while COM views the world in terms of objects living in structured space.
ORM does not enforce a special structure, which is then used for deriving semantic properties while COM has its intrinsic hierarchical and multidimensional structure of concepts as a basis for all other mechanisms.
In ORM (similar to ER model) there are two classes of elements: objects and relationships. Accordingly, there exist different types of objects and different types of relationships (logical predicates). In COM such a division does not exist and there are only concepts and their instances (data items). It is important that items in this case play a role of objects for subitems and relation instances for superitems. Thus at fundamental level COM implements relationships via objects while ORM implements then directly via special elements.
Information (semantics) in ORM is represented in terms of elementary facts, which is similar to RDF and other similar approaches while in COM an elementary piece of semantics is a conjunction, which is similar to object-oriented approach. In other words, in COM the minimal indivisible unit of representation is a combination (of items), which has a certain position in space. References in this case play a special role as special elements intended to represent objects in other contexts. In ORM an elementary fact asserts that a particular object has a property or some object participate in a relationship, which cannot be expressed in simpler terms by a number of simpler facts.
A fact in ORM is an assertion that an object plays a role. An n-ary fact has n roles. In typical applications predicates are binary and arities above 3, 4 are rare. A binary fact is analogous to references in COM. The mechanism of inverse predicates corresponds to inverse dimensions in COM. Thus ORM representation could be obtained from COM representation by replacing all references by binary facts where each fact has a type of its dimension name. ORM has a special mechanism for manipulating facts. In particular, there special fact tables as a part of the data semantics in addition to objects.
ORM allows for unary facts and facts with 3 and higher arity. Such things have no direct interpretation in COM and are rarely used in ORM.
ORM follows the conventional approach by distinguishing two types of objects: values (primitive objects like strings and numbers) and entities (non-primitive objects). In COM all items are equivalent and the only difference is in the way they are represented, which does not influence the semantics. In particular, we might to choose to represent items by reference, by value or by a custom reference.

8 Universal Relation Model (URM)

8.1 What are main assumptions of URM?

URM was started as an independent work of several researcher with the goal to study interrelational data dependencies. The relational model successully sovled the problem of physical navigation but it failed to solve the problem of logicl navigation where the user still has to specify concrete access paths in order to get a correct result set. The main goal of URM consists in achieving complete access path independence and free the user from specifying it for each query.

Here are the main assumptions of URM:

Access paths are embedded in attribute names which have to be unique and produce universal relation shcema.
For each set of attributes there is one basic relationship that the user has in mind which is referred to as the connection. The combinations of attributes then play a unique role.

8.2 What are main differences between URM and COM?

COM and URM are similar in their common goal to provide a mechanism for logical navigation where we specify only criteria of the query and the target while the system itself finds an appropriate intermediate steps and builds the final access path (in the case of altermative access paths we need to provide more information to avoid ambiguity).
In order to solve the problem of logical navigation and access path independence both approaches assume that the model is characterized by some final semantics. In URM it is called the universal relation while in COM it is called the primitive semantics. This assumption distinguishes these two approaches from other models including the relational model where the final semantics is not defined.
Instead of unique attributes names in URM we use dimensions of arbitrary rank as sequences of dimensions of rank 1. For example, an attribute EmployeesName is written in COM as Employees.Name.
COM relies on the mechanism of inverse dimensions which are dimensions with the opposite direction.
COM directly uses the syntactic structure of concepts for accessing data without the need to produce, manipulate or have in mind a kind of universal relation. At the same time we do not need to specify an access path for each query.

9 Functional Data Model (FDM)

9.1 What are main properties of FDM?

The basic constructs of FDM are entities and functions, which are intended to model conceptual objects and their properties.

9.2 What are main differences between FDM and COM?

For both COM and FDM the goal is to achieve a naturalness of data representation and manipulation.
Both models rely on the notion of derived properties.
Both models have rather similar query languages.
The mechanism of function inversion in FDM is analogous to the mechanism of inverse dimensions in COM.
FDM does not constraint a structure of functions and we can define them in a more or less free manner. In particular, there is no dependency on multiplicitly of functions (single-valued or multi-valued) and there can be cycles of functions. In COM all single-valued dimensions are upward directed while multi-valued inverse dimensions are downward directed.
FDM does not have a canonical semantics in the sense of COM and hence inference and complex manipulations are very limited.
The system of types in FDM is closer to the conventional OO approach.

10 Multi-Value Model (MV)

10.1 How multi-valued attributes are modeled in COM?

In the concept-oriented data model there is no dedicated mechanism for modeling multi-valued attributes. Instead, they are modeled by means of inverse dimensions. In other words, normal dimensions are always one-valued while inverse dimensions are always multi-valued. This property can be used to determine the direction of dimension and mutual position of concepts.

10.2 How multi-valued attributes are modeled in MV?

Records have multi-valued fields where values are separated by value marks. The values within these fields are dealt with a query language.

10.3 Links

http://www.pickwiki.com/cgi-bin/wiki.pl?MVDefinition - A formal mathematical critique of Relational Theory and its MultiValue opposition.
http://www.pickwiki.com/cgi-bin/wiki.pl?MultiValuedDatabases - Multi-Valued Databases.
http://www.cdbma.org/library/MultiValue_Review_White_Paper.pdf - A comparison of MV databases by MIS Modular Information Systems.
http://www.cdbma.org/presentations/nested_rdbms.pdf - IBM's white paper on comparing MV Architecture vs: "Normalized" DB structures.

Back to the Concept-Oriented Portal