Concept-oriented model

Concept-oriented model
Example of a concept-oriented model.

The concept-oriented model (COM) is a data model based on the following three principles:

  • Duality principle postulates that any element consists of two parts, called identity and entity. Accordingly, data modelling is divided into two orthogonal branches: identity modelling and entity modelling.
  • Inclusion principle postulates that elements exist within a hierarchy where each of them has a super-element specified via inclusion relation. All elements are identified via hierarchical domain-specific addresses.
  • Order principle postulates that elements exist within a partially ordered set where each of them has a number of greater and lesser elements. It is assumed that a reference stored in this element represents a greater element.

A data element in the concept-oriented model is defined as a couple consisting of one identity and one entity both having domain-specific structure. This model uses two orthogonal relations for data organization and manipulation: inclusion and partial order. Thus any element participates in two structures simultaneously: it is a member of a hierarchy (tree) and it is a member of a partially ordered set. The main purpose of the hierarchical structure consists in modelling hierarchical address spaces where each element has a unique domain-specific identity. The main purpose of the partial order consists in describing data semantics.

The name of this model originates from the main data modelling construct, concept, which generalizes conventional classes. This new approach to data modelling has been developed by Alexandr Savinov[1] since 2004 along with a novel approach to programming, called concept-oriented programming.




In COM, types of elements are described by a novel data modelling construct, called concept. Concept is defined as a couple of two classes: identity class and entity class. Concept fields are referred to as dimensions to emphasize their role in describing multi-dimensional structure. For example, a customer could be described by the following concept:

   CONCEPT Customer 
             CHAR(10) SSN 
             CHAR(64) name 
             DATE dob 

A concept instance consists of one identity and one entity. Identity is a domain-specific address or reference representing the entity. It is important that identities are not analogous to primary keys. Rather, they can be thought of as domain-specific surrogates.

Concepts generalize conventional classes and are used where classes are normally used to declare the type of elements. In particular, concepts are used to declare the type of elements of collections. For example, we could create a table for storing customers using the following SQL-like query:

   CREATE TABLE Customers CONCEPT Customer 

This table will contain only entity part of customers while identity part defines its address space. In terms of tables, entity class describes the horizontal structure (columns) and identity class describes the vertical structure (row addresses).

Concept Inclusion

Each concept has a super-concept which is declared via inclusion relation which generalizes inheritance. Concept instances are identified relative to their parent instance so that elements have unique hierarchical addresses which are analogous to the conventional postal addresses. For example, if streets are identified relative to cities then we use inclusion to describe this hierarchical relationship:

   CONCEPT City 
           CHAR(10) name 
           DOUBLE population 
   CONCEPT Street IN City 
           CHAR(10) name 
           DOUBLE length 

Parent and child elements are stored in different tables and one parent may have many children. After such declaration streets will be represented by two segments: the first segment is the city and the second segment is the street itself.

Concept Ordering

Each concept has a number of greater concepts specified via its dimension (field) types and this structure must be a partially ordered set. For example, assume that bank account concept has a dimension referencing its owner:

   CONCEPT Customer // It is a greater concept 
             CHAR(10) SSN 
             CHAR(64) name 
             DATE dob 
   CONCEPT Account // It is a lesser concept 
           CHAR(10) accNo 
           Customer owner // Dimension type is a greater concept 
           DOUBLE balance

Here the fact that an account stores a reference to a customer entails the fact that accounts are less than customers in the partially ordered set (in a diagram Account is positioned under Customer).

Projection and De-Projection

Operation of projection, denoted by right arrow, is applied to a set of elements and returns a set of their greater elements along the specified dimension. For example, given a set of accounts we can find their owners:

   AllOwners = Accounts -> owner -> Customers

Operation of de-projection, denoted by left arrow, is applied to a set of elements and returns a set of their lesser elements along the specified dimension. For example, given a set of customers we can find their accounts:

   AllAccounts = Customers <- owner <- Accounts

A sequence of projections and de-projections is referred to as an access path. Intermediate collections can involve constraints which can contain internal projections/de-projections with aggregation operations. For example, the following query returns accounts with small balance belonging to young customers who also have an account with big balance:

   ResultSet = (Accounts WHERE balance > 1000)
       -> owner -> (Customers WHERE age < 25)
       <- owner <- (Accounts WHERE balance < 100)

First, we select accounts with large balance (line 1). Then these accounts are projected to young customers by selecting their owners (line 2). Finally, these young rich customers (who may have also other accounts) are de-projected down to accounts with small balance (line 3).


Concept-oriented model.

The database schema shown in the diagram consists of 6 tables. Each table has two parts: identity and entity. (Note that identity part is not a primary key - it can be thought of as a domain-specific surrogate.) For example, banks are identified by their BLZ which acts as a domain-specific reference to the bank entity.

Each table is an element of the inclusion hierarchy, that is, each table has one super-table which is always positioned on the left. This relation is shown by dark blue leftward arrows. Tables which do not have an explicitly specified super-table are supposed to be included in the root which is the database. The basic idea behind inclusion is that any row of this table is always identified relative to some row of the super-table. For example, table Addresses is included in table Cities which means that any address is within some city and hence a fully qualified identifier of an address consists of two segments: a city id and the address itself. In the same way table Accounts is included in table Banks and hence any bank account is identifined by (i) the bank where it has been created, and (ii) account number. Such complex references are then stored as values in other tables by uniquely identifying the rows. For example, complex reference <11122233>:<111111111> represents account number 111111111 created in bank 11122233. If accounts could have internal savings accounts then a new sub-table SavingsAccounts had to be included in table Accounts. In this case one savings account would be identified by a complex reference consisting of three segments: bank, account, savings account number.

Each table in the database schema is an element of the partially ordered set where it has lesser and greater tables. Partial order relation among tables is shown by dark red upward arrows, that is, each upward arrow leads from the lesser table to a greater table. Here the main principle is that column types determine greater tables. For example, table Persons has a column which stores the person address and hence table Addresses is a greater table for Persons. Note that table Addresses is also greater than table Banks because banks also have an address. Tables Persons and Accounts have one common lesser table PersonsAccounts. It is used to implement a many-to-many relationship between them by storing account ownership information. It is also the most specific table in the model which is also called bottom table.

See also


  1. ^ Alexandr A. Savinov List of publications from the DBLP Bibliography Server. Retrieved 9 Oktober 2008.

Further reading

  • Alexandr Savinov (2005). "Hierarchical Multidimensional Modelling in the Concept-Oriented Data Model". In: Proceedings of the CLA 2005 International Workshop on Concept Lattices and their Applications Olomouc, Czech Republic, September 7-9, 2005. Edited by Radim Belohlavek and Vaclav Snasel. PDF

External links

Wikimedia Foundation. 2010.

Look at other dictionaries:

  • Concept-oriented design — (COD) is a theory of design and development based upon the language and diagrams of practitioners. It has been implemented in a tool Chasm to build 3D user interfaces (3DUIs). Its name is borrowed from the generic programming idea of a software… …   Wikipedia

  • Concept (disambiguation) — A concept is a cognitive unit of meaning an abstract idea or a mental symbol sometimes defined as a unit of knowledge . Concept may also refer to: Computing Concept (generic programming), a generic programming term In computational learning… …   Wikipedia

  • Model-driven security — (MDS) means applying model driven approaches (and especially the concepts behind model driven software development) [1] to security. Contents 1 Development of the concept 2 Opinions of industry analysts …   Wikipedia

  • Model-view-controller — (MVC) is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the …   Wikipedia

  • Oriented matroid — theory allows a combinatorial approach to the max flow min cut theorem. A network with the value of flow equal to the capacity of an s t cut An oriented matroid is a mathematical structure that abstracts the properties of directed graphs and of… …   Wikipedia

  • Model-based testing — is the application of Model based design for designing and optionally executing the necessary artifacts to perform software testing. Models can be used to represent the desired behavior of the System Under Test (SUT), or to represent the desired… …   Wikipedia

  • Model–view–controller — A general representation of the MVC design pattern. Model view controller concept. The solid line represents a direct as …   Wikipedia

  • Model car — For the term referring to delineation of (non model) car ranges, see car model. This Norev model car is a good miniature representation of a real Renault 4CV and would have been sold as a children s toy. A model car or toy car is a miniature… …   Wikipedia

  • Data model — Overview of data modeling context: A data model provides the details of information to be stored, and is of primary use when the final product is the generation of computer software code for an application or the preparation of a functional… …   Wikipedia

  • Database model — A database model is the theoretical foundation of a database and fundamentally determines in which manner data can be stored, organized, and manipulated in a database system. It thereby defines the infrastructure offered by a particular database… …   Wikipedia