<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="en">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">Hierarchical Multidimensional Modelling in the Concept-Oriented Data Model</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author role="corresp">
							<persName><forename type="first">Alexandr</forename><surname>Savinov</surname></persName>
							<email>savinov@ais.fraunhofer.de</email>
							<affiliation key="aff0">
								<orgName type="institution">Fraunhofer Institute for Autonomous Intelligent Systems Schloss Birlinghoven</orgName>
								<address>
									<postCode>D-53754</postCode>
									<settlement>Sankt Augustin</settlement>
									<country key="DE">Germany</country>
								</address>
							</affiliation>
							<affiliation key="aff1">
								<orgName type="institution">Fraunhofer Institute for Autonomous Intelligent Systems Schloss Birlinghoven</orgName>
								<address>
									<postCode>D-53754</postCode>
									<settlement>Sankt Augustin</settlement>
									<country key="DE">Germany</country>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">Hierarchical Multidimensional Modelling in the Concept-Oriented Data Model</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">B365D50E2924522F1F776F9F29201923</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-23T20:17+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>In the paper the concept-oriented data model (COM) is described from the point of view of its hierarchical and multidimensional properties. The model consists of two levels: syntactic and semantic. Concepts are combinations of superconcepts while items are combinations of superitems. It is described how this model can be interpreted as a hierarchical coordinate system. Two operations of projection and de-projection are used in the mechanism of access path. Grouping and aggregation with roll up and drill down are implemented via multidimensional de-projection. The described approach can be applied to very different problems for multidimensional modelling including database systems, online analytical processing, knowledge based systems, ontologies, complex categorizations, knowledge sharing and semantics web.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="en">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Introduction</head><p>Currently there exist several general approaches to data modelling based on different principles and main notions such as relations in the RM <ref type="bibr" target="#b4">[5,</ref><ref type="bibr" target="#b8">9]</ref>, entity and relationships in the ERM <ref type="bibr" target="#b3">[4]</ref>, facts and object roles in the ORM <ref type="bibr" target="#b12">[13]</ref>, subject-predicate-object triples in the RDF <ref type="bibr" target="#b1">[2]</ref> and many others. One of the most interesting approaches is based on using dimension as the main notion and construct of the model and dimensionality (degrees of freedom) as one of its main characteristics. This direction has been developed in the area of multidimensional databases <ref type="bibr" target="#b0">[1,</ref><ref type="bibr" target="#b11">12,</ref><ref type="bibr" target="#b14">15,</ref><ref type="bibr" target="#b16">17,</ref><ref type="bibr" target="#b21">22]</ref> and online analytical processing (OLAP) <ref type="bibr" target="#b2">[3,</ref><ref type="bibr" target="#b16">17]</ref>. In this paper we describe an approach to dimensionality modelling based on the concept-oriented data model (COM).</p><p>The described model has been proposed in <ref type="bibr" target="#b18">[19,</ref><ref type="bibr" target="#b19">20]</ref> and it takes its origin from the idea of multidimensional hierarchical space (analytical space) <ref type="bibr" target="#b17">[18]</ref>. There are several general assumptions about the nature of data in the COM. One of them is that the whole model is viewed as one global construct with canonical syntax and semantics. Analogous assumption is used in the universal relation model (URM) <ref type="bibr" target="#b5">[6,</ref><ref type="bibr" target="#b13">14,</ref><ref type="bibr" target="#b15">16]</ref>. Using this assumption we can derive properties of elements as properties of the whole model as well as automate many operations such logical navigation and query construction. Another important assumption is that the model is based on ordering its elements which is analogous to concept-lattices, formal concept analysis (FCA) <ref type="bibr" target="#b7">[8]</ref> and ontologies <ref type="bibr" target="#b6">[7]</ref>. This means that the order of elements is of crucial importance for the model and element position with respect to other elements determines most of its properties. In great extent everything in the COM is about order of elements. In contrast to FCA where objects are grouped into concepts depending on their properties (represented in incidence relation), items in the COM belong to concepts in advance and then their properties depend on the relative position to other items. The third assumption is that the hierarchical multidimensional structure of the model can be used for automating data access and logical navigation. The mechanism of access paths and queries in the COM is very close to that used in the functional data model (FDM) <ref type="bibr" target="#b9">[10,</ref><ref type="bibr" target="#b10">11,</ref><ref type="bibr" target="#b20">21]</ref>.</p><p>In section 2 we formally define the COM including its physical and logical structure (section 2.1), syntactic dimensionality structure (section 2.2) and semantics (section 2.3). In section 3 we describe how this model can be interpreted as a hierarchical multidimensional coordinate system. In section 4 we introduce two operations of projection and de-projection and the mechanism of access path based on them. Section 4 describes multidimensional grouping and aggregation. We will follow a convention that concept names are capitalized and written in plural while dimension names are in singular and start from lower case letter, for example, Products is a concept while product is a dimension with the domain in Products. Formulas will be written as usual in italics while queries and examples in monotype font (Courier).</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">Model Definition</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.1">Physical and Logical Structure</head><p>In the concept-oriented model each element E is defined via other elements and this definition consists of two parts:</p><formula xml:id="formula_0">(i) a collection of other elements } , , { K b a E = , K , , E b E a ∈ ∈</formula><p>, and (ii) a combination of other elements:</p><formula xml:id="formula_1">〉 〈 = K , ,V U E , K &lt; &lt; , , E V E U</formula><p>. Here ∈ denotes membership in collection and &lt; denotes membership in combination. This means that each element stores and knows directly two groups of elements which have different purpose and interpretation. Elements within a collection are identified by reference while elements within a combination are identified by position. Collectional parts of elements describe physical structure of the model which is assumed to be strictly hierarchical so that each element is a member of one parent collection (Fig. <ref type="figure">1a</ref>). It is important that this structure is fixed in the sense that elements can be added or deleted but they cannot change their parent collection. For example, element b cannot be moved from C to U (Fig. <ref type="figure">1a</ref>). Physical structure is used to implement references which are a mechanism of physical representation and access. In other words, each element in the model has a reference according to its position in the physical hierarchy of elements starting from the root.</p><p>Combinational parts of elements are intended to describe logical structure of the model. Logical structure defines how elements are characterized by other elements. It is important that an element may be a member of several combinations and itself combines several other elements (Fig. <ref type="figure">1b</ref>). Another important property of logical structure is that it is not fixed and we can always change how any element is logically defined. <ref type="figure">1</ref>. a) Physical structure is defined by a hierarchical collection where each element has only one parent. In two-level model the root consists of concepts (syntax) and concepts consists of items or concept instances (semantics). b) Logical structure is defined by combinations with dual interpretation as a logical collection of elements. In two-level model each concept is a combination of superconcepts and each item is a combination of superitems. Here element g can be a concept (and then a, b,…,c are superconcepts and d,e,…,f are subconcepts) or an item (and then a, b,…,c are superitems and d,e,…,f are subitems).</p><formula xml:id="formula_2">〉 〈 = c b a g , , , K , g c g b g a &lt; K &lt; &lt; , , , a b c d e f R C U V a b c d e f concepts items model root a) b) } , , , { f e d g K = , g f g e g d &gt; K &gt; &gt; , , , &gt; -membership in logical collection ∈ -membership in physical collection g Fig.</formula><p>Elements in combination are interpreted as object properties, i.e., an element is a combination of its properties. The dual interpretation is that an element is a logical collection consisting of all the elements which include it into their combinational part. Thus any element is a combination of other elements and, dually, a (logical) collection of other elements. Formally, if</p><formula xml:id="formula_3">〉 〈 = K K , ,U E ( E U &lt; ) then } , , { K K E U = ( U E &gt; )</formula><p>where &gt; denotes membership in logical collection. In contrast to physical collections which are fixed and intended to implement references, logical collections (dual combinations) are intended to represent data itself. We will follow a convention that combination</p><formula xml:id="formula_4">〉 〈 = K , ,V U E is drawn below its elements K , ,V U</formula><p>. In this case an upward arrow connects combination with its constituents and denotes membership in logical collection. Then each element can be represented as a combination of all elements above it and, dually, a (logical) collection of all elements below it (Fig. <ref type="figure">1b</ref>). In conventional terms this means that an object/record is a combination of its properties but at the same time it is a collection/group of all objects/records where it is used as a property. (A property is a group/category for all objects that have it.)</p><p>From the point of view of physical structure we distinguish three types of the model: (i) one-level model has one root and a number of data items in it, (ii) two-level model has one root, a number of concepts in it, each of them having a number of data items, (iii) multi-level model has an arbitrary number of levels in the physical hierarchy. In this paper we consider only two-level model defined as consisting of the following elements:</p><formula xml:id="formula_5">[Root] One root element R is a physical collection of concepts, } , , , { 2 1 N C C C R K = , [Syntax] Each concept is (i) a combination of other concepts called superconcepts (while this concept is a subconcept), R C C C C n ∈ 〉 〈 = , , ,<label>2 1 K</label></formula><p>, and (ii) a physical collection of data items (or concept instances),</p><formula xml:id="formula_6">R i i C ∈ = } , , { 2 1 K</formula><p>,</p><p>[Semantics] Each data item is (i) a combination of other data items called superitems (while this item is a subitem),</p><formula xml:id="formula_7">C i i i i n ∈ 〉 〈 = , , ,<label>2 1 K</label></formula><p>, and (ii) empty physical collection, {} = i , [Special elements] If a concept does not have a superconcept then it is referred to as primitive and its superconcept is one common top concept; and if a concept does not have a subconcept then it is assumed to be one common bottom concept, and an absence of superitem is denoted by one special null item.</p><p>[Cycles] Cycles in subconcept-superconcept relation and subitem-superitem relation are not allowed, [Syntactic constraints] Each data item from a concept may combine only items from its superconcepts.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.2">Dimensions and Inverse Dimensions</head><p>Each superconcept has a uniquely identified position within a concept definition,</p><formula xml:id="formula_8">〉 〈 = n n C x C x C x C : , , : , : 2 2 1 1</formula></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>K</head><p>, which is called dimension (of rank 1 or local dimension). Here superconcepts</p><formula xml:id="formula_9">n C C C , , ,<label>2 1</label></formula></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>K</head><p>are called domains or ranges for di-</p><formula xml:id="formula_10">mensions n x x x , , , 2 1 K , ) Dom( j j x C =</formula><p>. Normally dimensions (concept positions within a combination) are identified by names or integer values. The syntactic structure of concepts can be represented by a graph where nodes are concepts and edges are dimensions connecting subconcepts with their superconcepts. Cycles are not allowed in this graph so that concepts cannot be defined via themselves. Loops can be permitted for simplicity and performance reasons. If one of two concepts is direct or indirect parent of another then they are called syntactically dependent or parallel concepts, otherwise the two concepts are referred to as independent or orthogonal. In particular, all primitive concepts are orthogonal. A dimension x of rank k is a sequence of k dimensions of rank 1 (separated by dots) where each next dimension in the sequence belongs to the domain of the previous one:</p><formula xml:id="formula_11">k x x x x . . . 2 1 L = , where ) Dom( ) ( Dom 1 − j j x x &lt; , k j , , 3 , 2 K =</formula><p>Dimensions will be frequently prefixed by the very first concept:</p><formula xml:id="formula_12">k x x x C . . . . 2 1</formula><p>L . Also we frequently will use the terms dimension and its domain interchangeably. Each dimension is represented by one path in the concept graph and the number of edges in the path is its rank. A dimension with the primitive domain (direct superconcept of the top concept) is referred to as primitive dimension. For example, Auc- tions.product.category in Fig. <ref type="figure">2</ref> is a primitive dimension of rank 2 from the source concept Auctions to its superconcept Categories of rank 2. Note that there may be several different paths (dimensions) between a concept and its superconcept.</p><p>The number of different primitive dimensions (paths) of a concept is referred to as the concept primitive dimensionality. The model dimensionality is equal to that of the bottom concept, that is, the number of dimension paths from the bottom concept to primitive concepts (or, equivalently, to the top concept) is the model primitive dimensionality. The length of the longest dimension (path) of a concept is referred to as concept rank. The length of the longest dimension of the bottom concept is the model rank. Thus each concept-oriented model is characterized by two properties: (i) model rank describing its hierarchy (depth), and (ii) model dimensionality describing its multidimensionality (width). Model structure can vary from the flat space with many dimensions to one-dimensional hierarchal space. The task of the model syntactic design consists in defining what concrete structure of dimensions is appropriate for one or another problem domain.</p><p>Dually, each concept is a logical collection of its subconcepts: } , , , {</p><formula xml:id="formula_13">2 1 n S S S C K = , j S C &lt; .</formula><p>Inverse dimension is a dimension with opposite direc- tion, i.e., where the dimension starts the inverse dimension has its domain, and where the dimension ends the inverse dimension has its start. In concept graph inverse dimension is a path from superconcept to some its subconcept. Inverse dimension of rank 1 is an edge in concept graph with the opposite direction (from superconcept to a subconcept). Inverse dimensions do not have their own identifiers because they can be produced from the corresponding dimensions by inverting their direction. We will denote inverse dimensions by enclosing the corresponding dimension into curly brackets. If</p><formula xml:id="formula_14">k x x x C . . . . 2 1 L is a dimension of concept C with rank k then } . . . . { 2 1 k x x x C L is inverse dimension of concept ) Dom( k</formula><p>x with the domain in C and the same rank k. Thus any concept is characterized by (i) a set of dimensions leading to superconcepts and (ii) a set of inverse dimensions leading to subconcepts. For example, {Auctions.product.category} is an inverse dimension of rank 2 from superconcept Categories to its subconcept Auctions (Fig. <ref type="figure">1</ref>). An example of logical structure of concepts (syntax). Each concept is a combination of its superconcepts and a logical collection of its subconcepts. The model syntax can be represented as a concept graph where one path is one named dimension. Dimensionality and inverse dimensionality of this model is 6.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Prices Users</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Auctions</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.3">Semantics</head><p>Semantically each concept is a physical collection of its items, } , , { 2 1</p><formula xml:id="formula_15">K i i C =</formula><p>, where each item is a combination of items from its superconcepts:</p><formula xml:id="formula_16">〉 〈 = n i i i i , , ,<label>2 1</label></formula></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>K</head><p>, where</p><formula xml:id="formula_17">〉 〈 = ∈ n C C C C i , , , 2 1 K and n j C i j j , , 2 , 1 , K = ∈</formula><p>Just like for the concept graph cycles are not permitted so that the items constitute an acyclic graph. In such a definition two levels of logical description (syntactic and semantic) are isolated, i.e., we can represent things either by means of concepts or by means of items within their own acyclic graphs. A bridge between them is established via the physical structure where each item is physically a member of one concept. The logical structure of concepts is used to describe model dimensionality and impose syntactic constraints on possible items. In other words, without syntactic constraints an item can combine any items from any other concepts. In the presence of syntactic constraints an item can combine only items from its superconcepts.</p><p>An important property of the concept-oriented semantics is its globality which means that each item has its semantics distributed all over the model. Indeed, each individual item taken in isolation as an instance of its concept has no its own intrinsic properties or characteristics and the only thing that can be used to distinguish it from other items is its (physical) reference (location in the physical hierarchy). Items in the concept-oriented model can be only characterized by other items which in turn are characterized by other items and so on. If we want to get some property then we need to specify what other items we want to retrieve. However, an item representing a property may well be also semantically empty (if it is not a primitive item) so we need to retrieve some other item and so on. Thus any individual item semantics is distributed all over the model and finding item properties is reduced to specifying what part of the whole model semantics (associated with this item) we want to get.</p><p>Another property of this approach is that it does not have a dedicated mechanism of multi-valued properties. In order to model single-valued and multi-valued attributes the COM uses dimensions and inverse dimensions, respectively. In other words, dimensions are always single-valued and return one superitem as a value while inverse dimensions are always multi-valued and return a collection of subitems as its values. Single-valued attributes are upward directed while multi-valued attributes are downward directed in the concept graph. Such a mechanism has significant consequences. We cannot now simply change the multiplicity of an attribute because it entails changing the relative position of the domain. For single-valued attributes the domain is positioned above the source concept while for multi-valued attributes the domain is positioned below the source concept. Thus changing the multiplicity results in significant changes in the model semantics and syntax.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3">Hierarchical Coordinate System</head><p>Universe of discourse of a concept is the Cartesian product of its superconcepts:</p><formula xml:id="formula_18">} , , 2 , 1 , | , , , { 2 1 2 1 n j C i i i i C C C j j n n K K K = ∈ 〉 〈 = = × × × = Ω ω Each syntactically possible combination Ω ∈ ω of superitems is referred to as point.</formula><p>Only a subset of all points from Ω really exists and this subset is precisely the con- cept semantics (a set of its items). The superconcepts in the definition of a concept are treated as axes of the multidimensional space while items in these superconcepts are coordinates on these axes. The model can be then interpreted as a hierarchical multidimensional coordinate system where each item is characterized by its position along superconcepts as axes and, at the same time, is a coordinate taken by its subitems.</p><p>For example, in Fig. <ref type="figure" target="#fig_1">3</ref> the problem domain consists of 2-dimensional plane XY 4 points of which are combinations of 2 coordinates along two axes X and Y. From the concept-oriented point of view both axes X and Y are superconcepts each with 2 superitems (black circles). Their common subconcept XY potentially can consist of 4 subitems because there exist only 4 combinations of superitems. However, subconcept XY has only 3 subitems in its semantics while the fourth potentially possible subitem does not exist (dashed circles). Each item from concept XY corresponds to one point in the 2-dimensional plane while its constituents are interpreted as coordinates taken along the superconcepts as axes. Such a coordinate system is flexible because we can change the available coordinates for positioning objects by adding or removing items. This means that the coordinate system is an integral part of and is described by the model itself. New axes are introduced by defining new concepts and new possible coordinates can be added by defining new data items within existing concepts. For example, in Fig. <ref type="figure" target="#fig_1">3</ref> we might add a new coordinate Z and then data points from their subconcept XYZ could be positioned by assigning three coordinates rather than two. Another advantage is that it allows the modeller to create hierarchical coordinate systems. The thing is that all concepts have equal rights and can be treated as an axis with coordinates for its subconcepts and as a space with objects for its superconcepts. Thus any new subconcept defined via its superconcepts can be treated as a separate individual axis for future subconcepts. The coordinates in such a complex axis are complex multidimensional objects having many their own coordinates. For example, in Fig. <ref type="figure" target="#fig_1">3</ref> each point in XY is a combination of two coordinates from X and Y but in the hierarchical system each coordinate from X and Y can be itself a point with its own coordinates taken from their superconcepts. On the other hand, each item from XY can be used as a possible coordinate for new subconcepts added later. For example, we might add a new subconcept A which has two dimensions in XY and Z. The primitive dimensionality of A is 3 but we specify only two coordinates for each its item.</p><p>The problem of modelling in such a setting is formulated as designing a hierarchical coordinate system (syntax) and positioning objects in it via other objects treated as coordinates (semantics). After defining the model syntactic structure items are added in superconcepts and serve as coordinates for adding items in subconcepts. For example, in Fig. <ref type="figure">2</ref> each auction bid from concept AuctionBids has four coordinates along axes Prices, Users, Dates and Auctions. However, the last coordinate has its own three coordinates, i.e., each auction along axes Users, Dates and Products. Finally each auction bid has 6 primitive coordinates because there are 6 different paths from the concept AuctionBids to the top concept. We might equivalently describe this model as the flat multidimensional space consisting of 6 primitive concepts and one 6-dimensional concept AuctionBids. Obviously, such a model would have very low level and too inflexible. Having a hierarchical coordinate system allows us to introduce intermediate levels, which impose syntactic constraints. The concept AuctionBids in this case has only 4 its own dimensions and describing its items in this case is much more convenient.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4">Projection and De-projection</head><p>Let us assume that I is a subset of items from concept C, C I ⊆ . In order to get related items from some target domain concept we need to specify a path by means of either dimension (with the domain in a superconcept of C) or inverse dimension (with the domain in a subconcept of C). This path (dimension or inverse dimension) is applied to the source subset of items and returns a subset of related items from the domain concept. If</p><formula xml:id="formula_19">k d d d d . . . 2 1 L = is a dimension of C with domain in ) Dom(d U = then operation d I → is</formula><p>referred to as projection of I to U and returns a set of superitems referenced by items from I:</p><formula xml:id="formula_20">} , . | { C I i u d i U u d I ⊆ ∈ = ∈ = →</formula><p>It is important that each item from U can be included into the result collection (projection) only one time. If we want to include superitems as many times as they are referenced then we can use dot instead of arrow, i.e., x I. includes all referenced superitems of U even if they occur more than once. For example, if A is a collection of today's auctions then A-&gt;product.category will return all today's categories (each category only once) while A.product.category will return categories for each auction in A (as many categories as we have auctions).</p><p>Dual operation to projection returns a set of related items from a subconcept. If</p><formula xml:id="formula_21">} . . . { } { 2 1 k d d d d L = is an inverse dimension of C with domain in }) Dom({d S = then de-projection of I to S is defined as follows: } , . | { } { C I i i d s S s d I ⊆ ∈ = ∈ = →</formula><p>The result collection of de-projection } {d I → consists of all items from subconcept S which reference items from I via dimension d. For example, if C is a set of categories then C-&gt;{Auctions.product.category} returns a set of all auctions with the products having these categories. Dimension d specifying path between the source concept and the target concept is referred to as bounding dimension.</p><p>Access path is sequence of dimensions or inverse dimensions separated either by dot or by arrow where each next operation is applied to the result collection returned by the previous operation. Each access path has a zigzag form in the concept graph where dimensions move up to a superconcept while inverse dimensions move down to a subconcept in the concept graph.</p><p>It is possible to restrict items that are included into de-projection by providing a condition that all items from the domain subconcept have to satisfy:</p><formula xml:id="formula_22">} , true ) ( . | { )} ( | . : { C I i s f i d s S s s f d S s I ⊆ ∈ = ∧ = ∈ = →</formula><p>Here d S. is bounding dimension from subconcept S to the source collection I, s is instance variable that takes all values from set S and the predicate f (separated by bar) must be true for all items s included into the result collection (de-projection). After the query in angle brackets we can specify a list of values returned with each item of the new result collection. For example, access path C-&gt;{a : Auction.product.category | a.date==today}&lt;user,date&gt; will return user and date for all today's auctions for a subset of categories from C.</p><p>Frequently we need to have aggregated characteristics of items computed from related items. This can be done by defining a derived property of concept which is a named definition of a query returning one item or a collection for each item from this concept. For example, we could define a derived property allBids of concept Auctions returning a collection of all bids for one auction:</p><p>Auctions.allBids = this-&gt;{ AuctionBids.auction } (Keyword this is an instance variable referencing the current item.) Derived properties can use other properties. For example, the maximum bid for an auction could be defined as the following derived property:</p><p>Auctions.maxBid = max( this.allBids.price )</p><p>Here we get a set of all bids by applying existing property allBids to the current item, then get their prices via dot operation and then find the maximum price. In the same way we might compute the mean price for ten days for one category:</p><p>Category.meanPriceForTenDays = avg( {ab in AuctionBids.auction.product.category | ab.auction.date &gt; today-10 }.price );</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5">Multidimensional Grouping and Aggregation</head><p>In the previous section we assumed that there is only one path between the source concept and the target concept with related items, which is specified by means of one bounding dimension. However, in multidimensional case there can be more than one path which is specified by means of several bounding dimensions. If I is a subset of items from the source concept C, C I ⊆ , S is some subconcept of C, and</p><formula xml:id="formula_23">n d d d , , , 2 1 K are different dimensions of S with the domain in C, C d j = ) ( Dom , n j , , 2 , 1 K =</formula><p>, then multidimensional de-projection of I to S is defined as a set of subitems S s ∈ that reference source items</p><formula xml:id="formula_24">I i ∈ along all dimensions: } , . . . | { } , , , { 2 1 2 1 C I i i d s i d s i d s S s d d d I n n ⊆ ∈ = ∧ ∧ = ∧ = ∈ = → K K</formula><p>If we use only one dimension then we get 1-dimensional de-projection defined in the previous section. The idea of multidimensional de-projection is that we want to get subitems s belonging to one group item i along all specified dimensions. For example, if we select a set of points interpreted as groups/categories then multidimensional deprojection will return a set of all objects with coordinates in these points (projected to these points).</p><p>The mechanism of multidimensional de-projection can be used for online analytical processing (OLAP) where the task consists in finding aggregated characteristics of objects with the possibility to vary level of details. Let us assume that S is some concept with items to be aggregated. <ref type="bibr">In</ref>  For each level we can define its universe of discourse or multidimensional cube as a set of all possible points produced from the corresponding domains:</p><formula xml:id="formula_25">} | , , , { 2 1 2 1 j j n n L D D D D ∈ 〉 〈 = = × × × = Ω ω ω ω ω ω K K , ) Dom( j j d D = Projection of a set of items S I ⊆ to level L is a set of points from L Ω referenced by items from I via dimensions n d d d , , , 2 1 K of level L: } , . . . | { 2 1 S I i d i d i d i L I n L ⊆ ∈ = ∧ ∧ = ∧ = Ω ∈ = → ω ω ω ω K Multidimensional de-projection of a subset of items L I Ω ⊆ (where L Ω is deter- mined by level L) is a set of items from S with projection in I: } , . . . | { } { 2 1 L n I d s d s d s S s L I Ω ⊆ ∈ = ∧ ∧ = ∧ = ∈ = → ω ω ω ω K</formula><p>Multidimensional de-projection allows us to find items from a subconcept that are related to each point from one level. Thus items from the subconcept are broken into groups depending on the point from the level they are projected to. For each such group we can then find some aggregated property.</p><p>For example, let us suppose that S=Auctions is the concept we want to analyse. The first dimension path is p 1 =Auctions.date has only one level of details. The second dimension path p 2 =Auctions.products.categories has two levels of details so that we can consider either Products (more details) or Categories (less details) as domains for our analysis. The goal is to understand how properties of auctions are distributed over these two dimensions. The universe of discourse is defined as follows: {Dates, Categories | having(this)}. Here we enumerate domains from the level D 1 =Dates, D 2 =Categories and provide also restriction on the points we are interested in the predicate having(this) (analogous to HAVING clause in SQL). Then each point from this space has to be de-projected to the target concept S=Auctions and this group of items can be used to find some aggregated property. The following query will find average maximum bid for last week: Here in angle brackets after the source collection we specify values computed and returned for each point from the universe of discourse. In this example, we select only points for last week by imposing constraint on the source 2-dimensional space is-LastWeek(d). Each point from this space is de-projected to concept Auctions using query this-&gt;{Auctions.date, Auctions.product.category} with two bounding dimensions. Then we add property maxBid (defined in the previous section) to this access path because we want to find average value for all items of this de-projection. And finally this group of auction prices is passed as a parameter to the aggregation function which returns one value as a computed characteristic of one source point with the new name averagePrice. The result is that we have a twodimensional space with one aggregated property (called measure in OLAP).</p><p>It is important that we can vary the level of details. For example, to get more details we can drill down along the second dimension path and consider Products instead of Categories. Additionally, we might want to consider only auctions with price higher than some threshold: This query will produce all combinations of dates and products for last week and for each of them find a group of auctions with price higher than 10. Then this group of prices is averaged and returned as a new aggregated property. Note that grouping is carried out independent of any measure because we simply de-project a point and find a set of related subitems. Measure in this case is any property of items in deprojection (concept S). In particular, it is possible to define several measures in one or more different subconcepts with their own bounding dimensions. It is important also that dimension paths, measure and cubes are roles which are assigned only for certain type of analysis while the model itself is defined only by its concept graph.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="6">Conclusion</head><p>In the paper we described an approach to hierarchical multidimensional modelling based on the concept-oriented data model. This approach separates physical structure and logical structure by defining each element as a collection of other elements and as a combination of other elements. The logical structure is then used to represent data. For modelling (syntactic) dimensionality structure we use concepts which are combinations of their superconcepts. A distinguishing feature is that we define the model structure as an acyclic graph with edges as dimensions and after that this graph is used for analysis by assigning roles to its elements such as levels, cubes, dimensions and measures. In contrast, the conventional approaches are based on defining dimensions, cubes and other elements needed for analysis as initial elements of the model. Two important operations used for analysis are projection and de-projection which use the mechanism of dimensions and inverse dimensions, respectively. Taking into account simplicity and rich set of features and mechanisms this model can be applied not only to dimensionality modelling but used in many other application areas for modelling a wide range of practical situations and use cases.</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head></head><label></label><figDesc>Fig.2. An example of logical structure of concepts (syntax). Each concept is a combination of its superconcepts and a logical collection of its subconcepts. The model syntax can be represented as a concept graph where one path is one named dimension. Dimensionality and inverse dimensionality of this model is 6.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_1"><head>Fig. 3 .</head><label>3</label><figDesc>Fig. 3. Interpretation the model as a coordinate system. Plane with two axes is a subconcept with two superconcepts.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_2"><head></head><label></label><figDesc>{d : Dates, c : Categories | isLastWeek(d) }&lt; avg(this-&gt;{Auctions.date,Auctions.product.category}.maxBid) as averagePrice &gt;</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_3"><head></head><label></label><figDesc>{d : Dates, c : Products | isLastWeek(d) }&lt; avg(this-&gt;{Auctions.date, Auctions.product | this.maxBid &gt; 10 }.maxBid) as averagePrice &gt;</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_0"><head></head><label></label><figDesc>concept S we select a number of dimension paths If all level constituents are 0s then we get concept S which contains the most detailed information used for analysis. If all level constituents are 1s then we get a set of dimensions with rank 1 and their corresponding direct superconcepts of S as domains.</figDesc><table><row><cell>p 1</cell><cell cols="2">p , 2</cell><cell>,</cell><cell>K</cell><cell>,</cell><cell>p</cell><cell>n</cell><cell>which will be used for analysis. A level</cell><cell>L</cell><cell>=</cell><cell>〈</cell><cell>l 1</cell><cell>l , 2</cell><cell>,</cell><cell>K</cell><cell>,</cell><cell>l</cell><cell>n</cell><cell>〉</cell><cell>is a set of</cell></row><row><cell cols="21">numbers specifying a set of positions along dimension paths, a set of dimensions</cell></row><row><cell cols="2">d , 2 j D = d 1</cell><cell cols="19">n ( d Dom j , , K of concept S with ranks ) d , n j , , 2 , 1 K = . One constituent of level j n l l l , , , 2 1 K with their domains l is a rank of dimension n D D D , , , 2 1 , K</cell></row><row><cell cols="21">j d taken along path j p . Operation of increasing rank j l (one constituent of level)</cell></row><row><cell cols="21">of one dimension j d is referred to as roll up. Operation of decreasing rank j l of one</cell></row><row><cell cols="9">dimension j d is referred to as drill down.</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row></table></figure>
		</body>
		<back>
			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<analytic>
		<title level="a" type="main">Modeling multidimensional databases</title>
		<author>
			<persName><forename type="first">R</forename><surname>Agrawal</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Gupta</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Sarawagi</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proc. 13th International Conference on Data Engineering (ICDE&apos;97)</title>
				<meeting>13th International Conference on Data Engineering (ICDE&apos;97)</meeting>
		<imprint>
			<date type="published" when="1997">1997</date>
			<biblScope unit="page" from="232" to="243" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<monogr>
		<title level="m" type="main">The Semantic Web</title>
		<author>
			<persName><forename type="first">T</forename><surname>Berners-Lee</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Hendler</surname></persName>
		</author>
		<author>
			<persName><forename type="first">O</forename><surname>Lassila</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2001-05">May 2001</date>
			<publisher>Scientific American</publisher>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<monogr>
		<author>
			<persName><forename type="first">A</forename><surname>Berson</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><forename type="middle">J</forename><surname>Smith</surname></persName>
		</author>
		<title level="m">Data warehousing, data mining, and OLAP</title>
				<meeting><address><addrLine>New York</addrLine></address></meeting>
		<imprint>
			<publisher>McGraw-Hill</publisher>
			<date type="published" when="1997">1997</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<analytic>
		<title level="a" type="main">The Entity-Relationship Model. Toward a Unified View of Data</title>
		<author>
			<persName><forename type="first">Peter</forename><surname>Pi-Shan Chen</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">ACM Transactions on Database Systems</title>
		<idno type="ISSN">0362-5915</idno>
		<imprint>
			<biblScope unit="volume">1</biblScope>
			<biblScope unit="page" from="9" to="36" />
			<date type="published" when="1976">/1/1976</date>
			<publisher>ACM-Press</publisher>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b4">
	<analytic>
		<title level="a" type="main">A relational model of data for large shared data banks</title>
		<author>
			<persName><forename type="first">E</forename><forename type="middle">F</forename><surname>Codd</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Communications of the ACM</title>
		<imprint>
			<biblScope unit="volume">13</biblScope>
			<biblScope unit="issue">6</biblScope>
			<biblScope unit="page" from="377" to="387" />
			<date type="published" when="1970">1970</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b5">
	<analytic>
		<title level="a" type="main">A Simplified Universal Relation Assumption and Its Properties</title>
		<author>
			<persName><forename type="first">R</forename><surname>Fagin</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><forename type="middle">O</forename><surname>Mendelzon</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><forename type="middle">D</forename><surname>Ullman</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">ACM Trans. Database Syst</title>
		<imprint>
			<biblScope unit="volume">7</biblScope>
			<biblScope unit="issue">3</biblScope>
			<biblScope unit="page" from="343" to="360" />
			<date type="published" when="1982">1982</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b6">
	<monogr>
		<author>
			<persName><forename type="first">D</forename><surname>Fensel</surname></persName>
		</author>
		<title level="m">Ontologies: a silver bullet for knowledge management and electronic commerce</title>
				<imprint>
			<publisher>Springer</publisher>
			<date type="published" when="2004">2004</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b7">
	<monogr>
		<title level="m" type="main">Formal Concept Analysis: Mathematical Foundations</title>
		<author>
			<persName><forename type="first">B</forename><surname>Ganter</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><surname>Wille</surname></persName>
		</author>
		<imprint>
			<date type="published" when="1999">1999</date>
			<publisher>Springer</publisher>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b8">
	<monogr>
		<title level="m" type="main">Database Systems: the Complete Book</title>
		<author>
			<persName><forename type="first">H</forename><surname>Garcia-Molina</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Ullman</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Widom</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2003">2003</date>
			<publisher>Prentice Hall</publisher>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b9">
	<analytic>
		<title level="a" type="main">Functional Approach to Intelligent Information Systems (Special issue)</title>
	</analytic>
	<monogr>
		<title level="j">Journal of Intelligent Information Systems</title>
		<editor>P.M.D. Gray, P.J.H. King and L. Kerschberg</editor>
		<imprint>
			<biblScope unit="volume">12</biblScope>
			<biblScope unit="page" from="107" to="111" />
			<date type="published" when="1999">1999</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b10">
	<monogr>
		<title level="m">The Functional Approach to Data Management: Modeling, Analyzing, and Integrating Heterogeneous Data</title>
				<editor>
			<persName><forename type="first">P</forename><forename type="middle">M D</forename><surname>Gray</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">L</forename><surname>Kerschberg</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">P</forename><surname>King</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">A</forename><surname>Poulovassilis</surname></persName>
		</editor>
		<meeting><address><addrLine>Germany</addrLine></address></meeting>
		<imprint>
			<publisher>Springer</publisher>
			<date type="published" when="2004">2004</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b11">
	<analytic>
		<title level="a" type="main">A foundation for multi-dimensional databases</title>
		<author>
			<persName><forename type="first">M</forename><surname>Gyssens</surname></persName>
		</author>
		<author>
			<persName><forename type="first">L</forename><forename type="middle">V S</forename><surname>Lakshmanan</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proc. 23th VLDB &apos;97</title>
				<meeting>23th VLDB &apos;97<address><addrLine>Athens, Creece</addrLine></address></meeting>
		<imprint>
			<date type="published" when="1997">1997</date>
			<biblScope unit="page" from="106" to="115" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b12">
	<analytic>
		<title level="a" type="main">Entity Relationship modeling from ORM perspective</title>
		<author>
			<persName><forename type="first">T</forename><forename type="middle">A</forename><surname>Halpin</surname></persName>
		</author>
		<ptr target="www.inconcept.com/jcm" />
	</analytic>
	<monogr>
		<title level="j">Journal of Conceptual Modeling</title>
		<imprint>
			<biblScope unit="volume">11</biblScope>
			<date type="published" when="1999">1999</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b13">
	<analytic>
		<title level="a" type="main">Consequences of assuming a universal relation</title>
		<author>
			<persName><forename type="first">W</forename><surname>Kent</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">ACM Trans. Database Syst</title>
		<imprint>
			<biblScope unit="volume">6</biblScope>
			<biblScope unit="issue">4</biblScope>
			<biblScope unit="page" from="539" to="556" />
			<date type="published" when="1981">1981</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b14">
	<analytic>
		<title level="a" type="main">A data model for supporting on-line analytical processing</title>
		<author>
			<persName><forename type="first">C</forename><surname>Li</surname></persName>
		</author>
		<author>
			<persName><forename type="first">X</forename><forename type="middle">S</forename><surname>Wang</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proc. Conference on Information and Knowledge Management</title>
				<meeting>Conference on Information and Knowledge Management<address><addrLine>Baltimore, MD</addrLine></address></meeting>
		<imprint>
			<date type="published" when="1996">1996</date>
			<biblScope unit="page" from="81" to="88" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b15">
	<analytic>
		<title level="a" type="main">On the foundation of the universal relation model</title>
		<author>
			<persName><forename type="first">D</forename><surname>Maier</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><forename type="middle">D</forename><surname>Ullman</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><forename type="middle">Y</forename><surname>Vardi</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">ACM Trans. on Database System (TODS)</title>
		<imprint>
			<biblScope unit="volume">9</biblScope>
			<biblScope unit="issue">2</biblScope>
			<biblScope unit="page" from="283" to="308" />
			<date type="published" when="1984">1984</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b16">
	<analytic>
		<title level="a" type="main">An Object Oriented Multidimensional Data Model for OLAP</title>
		<author>
			<persName><forename type="first">T</forename><forename type="middle">B</forename><surname>Nguyen</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><forename type="middle">M</forename><surname>Tjoa</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><forename type="middle">R</forename><surname>Wagner</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proc. 1st International Conference on Web-Age Information Management (WAIM&apos;00)</title>
				<meeting>1st International Conference on Web-Age Information Management (WAIM&apos;00)<address><addrLine>Shanghai, China</addrLine></address></meeting>
		<imprint>
			<publisher>Springer</publisher>
			<date type="published" when="2000-06">June 2000. 2000</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b17">
	<analytic>
		<title level="a" type="main">Analytical space for data representation and interactive analysis</title>
		<author>
			<persName><forename type="first">A</forename><surname>Savinov</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Computer Science Journal of Moldova</title>
		<imprint>
			<biblScope unit="volume">10</biblScope>
			<biblScope unit="issue">1</biblScope>
			<biblScope unit="page" from="59" to="80" />
			<date type="published" when="2002">2002</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b18">
	<monogr>
		<title level="m" type="main">Principles of the Concept-Oriented Data Model</title>
		<author>
			<persName><forename type="first">A</forename><surname>Savinov</surname></persName>
		</author>
		<ptr target="http://conceptoriented.com/savinov/publicat/imi-report&apos;04.pdf2004" />
		<imprint/>
		<respStmt>
			<orgName>Institute of Mathematics and Informatics</orgName>
		</respStmt>
	</monogr>
	<note type="report_type">Technical Report</note>
</biblStruct>

<biblStruct xml:id="b19">
	<analytic>
		<title level="a" type="main">Logical Navigation in the Concept-Oriented Data Model</title>
		<author>
			<persName><forename type="first">A</forename><surname>Savinov</surname></persName>
		</author>
		<ptr target="http://www.inconcept.com/jcm" />
	</analytic>
	<monogr>
		<title level="j">Journal of Conceptual Modeling</title>
		<imprint>
			<date type="published" when="2005">2005</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b20">
	<analytic>
		<title level="a" type="main">The Functional Data Model and the Data Language DAPLEX</title>
		<author>
			<persName><forename type="first">D</forename><forename type="middle">W</forename><surname>Shipman</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">ACM Transactions on Database Systems</title>
		<imprint>
			<biblScope unit="volume">6</biblScope>
			<biblScope unit="issue">1</biblScope>
			<biblScope unit="page" from="140" to="173" />
			<date type="published" when="1981">1981</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b21">
	<analytic>
		<title level="a" type="main">Conceptual multidimensional models</title>
		<author>
			<persName><forename type="first">R</forename><surname>Torlone</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Multidimensional Databases: Problems and Solutions, Idea Group</title>
				<imprint>
			<date type="published" when="2003">2003</date>
			<biblScope unit="page" from="69" to="90" />
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
