Metadata for Data Warehousing Using Extended Relational Models

O. Mangisengi
A M. Tjoa
Institute of Software Technology
Technical University of Vienna, Austria
Resselgasse 3/188
A-1040 Wien, Austria
phone: (43)-1-58801-18800
fax: (43)-1-58801-18899
{oscar,tjoa}@ifs.tuwien.ac.at

R.R. Wagner
Institute of Applied Knowledge Processing
University of Linz
A-4040 Linz, Austria
phone: (43)-732-2468-791
wagner@ifs.uni-linz.ac.at

ABSTRACT

This paper introduces different extended relational concepts to model metadata for data warehousing. In the first approach we will use the concept of nested relations to model metadata for multi-dimensional OLAP data. We will discern between the use of the nested relation approach for creating user views which are deduced from a relational model – which omit the requirement of being in first normal form from the use of nested relations for the conceptual modeling of OLAP. In the second approach we will briefly introduce the use of quotient relations which also inherits the advantage of the original relational model as it was introduced by Codd paired with many advantages for the drill-down and roll-up operations. The powerful partitioning and de-partitioning operators on quotient relations can perform drill-down and roll-up operations in a very convenient way. In the third approach we propose the metadata for multidimensional data using an extended relational model which was introduced by Codd for use in OLAP-modeling. In this model Codd introduced important semantic concepts, such as unique object identifiers, different types of objects (kernel, characteristic and association) and also meta relations, e.g. association graph relation, characteristic graph relation, etc. The general requirements for all three extended relational data models, which could serve as a foundation for multidimensional database systems, are similar to those that made the relational model successful, namely the existence of an implementation independent formalism, the separation of structure and contents, and the existence of declarative query language. All three approaches are compared with the modeling based on the traditional flat relations, which is widely used in the OLAP community, i.e. the modeling of OLAP star and snow-flake schemas.

Keywords: data warehouse, OLAP, metadata, extended relational model.

1.0 INTRODUCTION

On-Line Analytical Processing (OLAP) is emerging as the most important approach in Data Warehousing. OLAP allows to model data in a multidimensional way as a cube and to query and analyze data from many different perspectives. Independent from the different implementation aspects, OLAP data are presented to the user in a multidimensional data model.

There are several ways to define multidimensional meta models. However until now there did not exist a commonly accepted multidimensional meta data model. Such a model is necessary as a basis for an accepted standardized logical data model for OLAP data. This would allow practitioners and researchers to specify their data warehouses in a unified way.

The aim of this paper is to propose an approach for a meta model of multidimensional data, which is entirely based on the relational data model. It seems to the authors that such a model would very much correspond with the original intuition of Codd when he introduced the concept of OLAP in his pioneering white paper.

Among the different ways to define a data cube the star schema approach could be regarded as the most dominant one. A data cube is defined as a collection of at least one fact table and a set of dimension tables.

In this paper we will introduce a meta model with the capability to describe these tables and the OLAP queries based on the extended relational model of Codd. The general requirements for such a formal data model that can serve as a foundation for multidimensional database systems, are similar to those that made the relational model successful, namely the existence of an implementation independent formalism, the separation of structure and contents, and the existence of declarative query language.

We will discern between the use of the nested-relation approach for creating user views which are deduced from a relational model – which omit the requirement of being in first normal form from the use of nested relations for the conceptual model of OLAP. In the second approach we will briefly introduce the use of quotient relation, which also inherits the advantage of the original relational model as it was introduced by Codd paired with many advantages for the drill-down and roll-up operations. The powerful partitioning and de-partitioning operators on quotient relations can perform drill-down and roll-up operations in a very convenient way. In a third approach we will model OLAP by using the extended relational model which was introduced by Codd for use in OLAP-modeling. Most of the paper will focus on the extended relational model RM/T of Codd.

All three approaches will be compared with the modeling based on the traditional flat relations, which is widely used in the OLAP-community, i.e. the modeling of OLAP star and snow-flake schemas as it is proposed by the Meta Data Coalition in the Meta Data Interchange Specification (MDIS-Appendix B6 „Representing Multi-Dimensional Databases) [19].

In the last section we will show that the extended relational model of Codd is well suited as a basis for an object oriented meta model of OLAP-data since it inherently uses the concept of object identifiers, a typology of different object types (associations, characteristics, and kernel object types) and a meta model description on the relationships between the different object types.

The remainder of this paper is organized as follows: In the next section we briefly present the theoretical issues of metadata. Section 3 present the meta model of OLAP-data based on the nested relation, quotient relation, and the extended relational and its design. In section 4 we compare all three modeling approaches with the modeling based on the traditional flat relations. Our conclusion is given in section 5.

2.0 METADATA

Metadata management is a critical issue in archiving a fully integrated data warehouse. In a data warehouse environment metadata has a variety of purposes including [5]:

• Metadata associated with data loading and transformation. It describes the source data and any change that were made to the data. For example, for each source field there should be a unique identifier, original field name, source data type, and original location including the system and object name, along with the destination data type and destination table name.
• Metadata associated with data management. It defines the data stored in the data warehouse. Every object in the database needs to be described including the data in each table, index, and view, and any associated constraints. This information is held in the DBMS system catalog, however, there are additional requirements for the purposes of the warehouse. For example, metadata should also describe any fields associated with aggregations, including a description of the aggregation that was performed. In addition, table partitions should be described including information on the partition key, and the data range associated with that partition.
• Metadata used by the query manager to generate an appropriate query. The query manager generates additional metadata about the queries that are run, which can be used to generate a history on all the queries and a query profile for each user, group of users, or the data warehouse. There is also metadata associated with the users of queries that includes, for example, information describing what the terms ‘price’ or ‘customer’ means in a particular database and has the meaning changed over time.

There are several kinds of metadata for data warehouse, such as technical metadata, business metadata, and information navigator metadata [23].

• Technical metadata primarily supports technical staff that must implement and deploy the data warehouse. The information contained within the technical directory is compatible with this kind of audience and contains the term and definition of metadata, exactly as they appear in operational databases.
• The business metadata primarily supports business end users who do not have a technical background, and can not use the technical metadata to determine what information is stored inside the data warehouse.
• The information navigator metadata is a facility that allows users to browse through both the business metadata and the data inside the data warehouse.

3.0 THE META MODEL OF OLAP-DATA BASED ON NESTED RELATION, QUOTIENT RELATION, AND EXTENDED RELATIONAL

In this section we discuss the metadata for data warehouse based on the extended relational model of Codd. The quotient relation model approach for Data Warehousing has been published in [17]. The multidimensional modeling approach based on the nested relation concept is given in [18]. Therefore, in this section we focus on the meta model using the extended relational approach.

3.1 THE META MODEL OF OLAP-DATA BASED ON NESTED RELATION AND QUOTIENT RELATION MODELS

We discern between the use of the nested-relation approach for creating user views which are deduced from a relational model – which omit the requirement of being in first normal form from the use of nested relations for the conceptual model of OLAP.

The use of quotient relation inherits the advantage of the original relational model as it was introduced by Codd paired with many advantages for the drill-down and roll-up operations. The powerful partition and de-partition operators on quotient relations can perform drill-down and roll-up operations in a very convenient way.

In section 4 we give a comparison of the different approaches.

3.2 THE META MODEL OF OLAP-DATA BASED ON THE EXTENDED RELATIONAL MODEL

3.2.1 THE DIFFERENT RELATIONS OF THE EXTENDED RELATIONAL MODEL

The extended relational model has been proposed by Codd in [7]. It is suitable as a concept of an object oriented meta model for OLAP-data, since it inherently uses the concept of object identifiers, a typology of different object types, such as: associations, characteristics, and kernel object types; and a meta model description on the relationships between the different types. In this model, different kind of relations, namely the object relation, property relation, association relation, characteristic relation, association-graph relation, and characteristic-graph relation, are defined. We use these constructions to design the metadata for a data warehouse. The extended relation concept requires the following relations that are used to design a metadata.

• The Object Relation

• The Property Relation

The Association Relation

• Characteristic Relation

• Association-Graph Relation

• Characteristic-Graph Relation

3.2.2 IMPLEMENTING THE RELATION REQUIREMENTS IN A DATA WAREHOUSE

The extended relational model of Codd can be applied to model metadata for data warehousing. To model metadata based on the extended relation, we use a small data warehouse schema example. In this example, the Data Warehouse based on the star schema has a sales fact relation and three dimension relations. The dimension relations are given by the relation Store, Product, and Time represented in Figure 1. Figure 1 applies the multidimensional graphical notation as it is developed by Bulos [4] using the ADAPT modeling tool developed at the Technical University of Braunschweig by Andreas Totok and Ramo Jaworski [25].

The following steps describe the approach to design metadata for data warehouses based on the extended relation model.

• The data warehouse in figure 1 based on the star schema consists of a fact table and a set of dimension tables. In the extended relational approach we first create an object-relation for each dimension table and fact table. Each object has the Object-Relation-Name and an object identifier name (attribute name). Therefore, four Object-Relations, namely Object-Relation-Sales, Object-Relation-Store, Object-Relation-Product, and Object-Relation-Time, need to be created. Each object of the "Sales Data Warehouse" is shown in the following figure 2.

• In a star schema, a fact table consists of the attribute keys of each dimension table and fact attributes. In the extended relational model, a fact table and a set of dimension tables are identified by their object-relations. However, the object-relation of the "sales fact" has to be associated with the set of dimension object relations. To associate these objects, a relation is defined, called the Association Relation Sales. This relation contains the object identifier of each object relations, e.g. Sales_Oid, Store_Oid, Product_Oid, and Time_Oid. The Association-Relation-Sales is shown in figure 3.

• To support the specification which object types participates in which associative object type, the Association-Graph-Relation is defined. This relation contains two attributes, namely the superordinate role (SUP) and subordinate role (SUB) attributes. The (SUP:SUB) attributes pair defines a pair of the Object-Relation-Sales and Object Relation of each dimension. The Association-Graph-Relation and the relationship between Object-Relation-Sales and the object relations of its dimension can be shown in the figure 4.

• The correspondence between an object and its property is defined in a relation, called Property-Relation. This Property-Relation contains an object-identifier (Oid) and its property attribute names. In the data warehouse environment, this correspondence is provided by a relation between either an object-relation of a fact and its attributes table or between an object-relation of each dimension and its attributes. The following relation shows the Property-Relation-Sales, specifically the correspondence Sales_Oid and its attribute Sales. The Property-Relation-Sales is shown by figure 5

• To support the full capability in a data warehouse, each attribute of the dimension hierarchies has to be created as an object relation. Each object has an object relation name and an object identifier. Each Object Relation of dimension "Store" is shown in the figure 9.

• To form a strict hierarchy (characteristic tree) between two object relations in a dimension, a relation, called characteristic-relation, is created. In this characteristic-relation, an object type p is the parent of object type q, if q is an immediate characteristic of p. A characteristic-relation contains an object identifier of each object relation. For example, Characteristic-Relation-City-Store contains attributes, such as City_Oid and Store_Oid. The characteristic relation of dimension "Store" is given by figure 12. This information can be used for drill-down and roll-up operations.

• To represent the collection of characteristic trees, we introduce a relation, called Characteristic-Graph-Relation, which is used to store characteristic trees for all object-relation type. This relation contains a pair of superordinate (SUP) and of subordinate (SUB) attributes. The SUP attribute contains the parent name of object-relation and the SUB attribute contains the immediate characteristic of SUP. The Characteristic-Graph-Relation is given by figure 15.

The full description of the metadata of the example is given in the Appendix.

4.0 THE COMPARISON OF THREE OLAP MODELING APPROACHES WITH THE MODELING BASED ON THE TRADITIONAL FLAT RELATIONS

In this section we give a comparison of the most important features of OLAP for the three extended relational models. All three approaches are compared with the modeling based on the traditional flat relations, which is used in the OLAP-community, i.e. the modeling of OLAP star and snow-flake schemas proposed by the Meta Data Coalition in the Meta Data Interchange Specification (MDIS-Appendix B6 "Representing Multi-Dimensional Databases).

As a conclusion we can see that the difference between quotient relation and nested relation are marginal.

The nested relations are defined on the schema level, which have some advantages in the presentation of data. The quotient relation is value-oriented with advantages in the use of data-filters. However we can also use "historical knowledge" of partitions to have the same effect as nested relations on the schema level.

The nested relations are much better investigated, so that we can use functional dependencies in these relations to represent granulation hierarchies.

The extended relational model has the greatest semantic richness and is therefore most suitable to be used for a metadata specification.

5.0 CONCLUSION

The extended relational proposed by Codd has the required semantic granularity for representing OLAP data. It is the only relational model which discern between properties (attribute values transparent to the user), the definition of object classes which just contain object-identifiers, a typology of relationships between object types (especially the introduction of characteristic object types with the possibility to define "characteristics of characteristics" and the introduction of an association-type for facts). Another strength of this model is the proper introduction of meta-graph-relations reflecting the roles of participating object types within characteristic object types and association object types.

Summarizing the differences of the three models we can conclude a huge advantage of the extended relational model because of its very positive semantic rigorism. Our task is it to find an implementation approach with an acceptable performance for this model. For some highly structured application this model could build a real alternative to conventional solutions.

The use of quotient and nested relations in object oriented databases is relatively easy possible by defining the appropriate class-hierarchies for these relations together with their well defined operators. Especially for MOLAP databases the complex objects of quotient relations and nested relations are highly suitable for performing roll-up and drill-down on the fly.

In the MDIS-Appendix B6 Representing Multi-Dimensional Databases, drill-down and roll-up operation is represented by the hierarchy relationship description. The description defines the attribute of each dimension hierarchy. In the extended relational model, the drill-down and roll-up operation is represented in a relation, called characteristic-relation. The characteristic-relation contains the objects, which participate for that operation. The participated objects are stored in the Characteristic-Graph-Relation (meta-graph-relation).

REFERENCES

[1] S. Abiteboul, and N. Bidoit. Non First Normal Form Relations to Represent Hierarchically Organized Data. In Proceedings of the 3^rd. ACM SIGMOD Symposium on Principles of Database Systems, Waterloo, Ontario, Canada, 1984.

[2] R. Agrawal, A. Gupta, and S. Sarawagi. Modelling Multidimensional Databases. In Proceedings of the Int’l Conference on Data Engineering, 1997.

[3] M. Blaschka, C. Sapia, G. Höfling, and D. Dinter. An overview of multidimensional data models for OLAP. In Proceedings of Database and Expert Systems Applications, IEEE Press, 1998.

[4] D. Bulos. A New Dimension, in Database Programming & Design, 1996.

[5] T. Connolly, C. Begg, and A. Strachan. Database Systems, A practical Approach to Design, Implementation, and Management. 2^nd edition, Addison-Wesley, 1999.

[6] E.F. Codd, S.B. Codd, and C.T. Salley. Providing OLAP (On-line Analytical Processing) to User-Analysts: An IT Mandate. E.F. Codd & Associates, White paper, 1993.

[7] E.F. Codd. Extending the Database Relational Model to Capture More Meaning. ACM Transaction on Database Systems, Vol. 4, December 1979.

[8] L. Cabbibo, and R. Torlone. A systematic Approach to Multidimensional Databases. In Proceedings of SEBD 1997.

[9] L. Cabbibo, and R. Torlone. Querying Multidimensional Databases. In Proceedings of the 6^th DBPL, 1997.

[10] A.L. Furtado, and L. Kerschberg. An Algebra of Quotient Relations. In Proceedings of ACM SIGMOD, 1977.

[11] M. Gyssens, and L.V.S. Lakshmanan. A Foundation for Multi-Dimensional Databases. In Proceedings of Int’l Conference on Very Large Databases, 1997, Athens, Greece.

[12] ESPRIT-Project 7091; GOAL (Geographic On-Line Analysis: GIS-Data Warehouse Integration), Technical Report, 1998.

[13] R. Kirkgöze, M. Katic, M. Stolba, and A.M. Tjoa. A Security concept for OLAP. In Proceeding 8^th. Int’l. Workshop on Database and Expert System Applications, IEEE Computer Society, 1997.

[14] A. Kurz and A.M. Tjoa. Web Warehousing. Thomson Publishing, 1998 (to appear).

[15] V. Linnemann. Non First Normal Form Relations and Recursive Queries: An SQL-Based Approach. In Proceedings of 3^rd. International Conference on DataEngineering, Los Angeles, California, USA, 1987.

[16] C. Li and X.S. Wang. A data model for supporting on-line analytical processing. In Proceedings of Conference On Information and Knowledge Management, November 1996.

[17] O. Mangisengi, and A.M. Tjoa. A Multidimensional Modeling Approach for OLAP within the Framework of the Relational Model based on Quotient Relations, ACM First International Workshop on Data Warehousing and OLAP (DOLAP), 1998.

[18] O. Mangisengi, A M. Tjoa, and R.R. Wagner. Multidimensional Modeling Approaches for OLAP Based on Extended Relational Concepts, Accepted Paper on the International Database Conference 1999, Hong Kong, 1999.

[19] Metadata Coalition, Metadata Interchange Specification (MDIS Version 1.1), URL http://www.he.net/~metadata/standards/toc.html, August 1, 1997.

[20] Z.M. Ozsozoglu, and L.Y. Yuan. A Design Method for Nested Relational Databases. In Proceedings of 3^rd. International Conference on Data Engineering, Los Angeles, California, USA, 1987.

[21] M.A. Roth, H.F. Korth, and A. Silberschatz. Extended Algebra and Calculus for Nested Relational Databases. ACM Transaction on Database Systems, Vol. 13, No. 4, December 1988.

[22] M.H. Scholl, H.B. Paul, and H.J. Schek. Supporting Flat Relations by a Nested Relational Kernel. In Prooceedings of the 13^th. International Conference on Very Large Data Bases, Brighton, England, 1987.

[23] Que. The Official Client/Server Computing Guide to Data Warehousing. Que Books, 1997.

[24] H.J. Schek, and M.Scholl. An Algebra for the Relational Model with Relation-Valued Attributes. TR DSVI 1984-T1, Techn. Univ. Darmstadt, 1984 (in German).

[25] A. Totok, and R. Jaworski. Modeling of Multidimensional Data Structures with ADAPT. Technical Report, Technical University of Braunschweig, ISBN 3-930166-92-5, 1998 (in German).

ACKNOWLEDGEMENTS

The authors are very indebted to Andreas Kurz and Josef Schiefer for many creative remarks. This work is supported by the Austrian Federal Bank, Project No. 6681. For the object-oriented implementation we thank Informix for their "Innovative Software Grant".

Copyright 1999 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

APPENDIX

EXAMPLE

METADATA FOR DATA WAREHOUSING USING EXTENDED RELATIONAL APPROACH

BEGIN DATABASE

Identifier = "CHARACTER"

DatabaseName = "SALES DATA WAREHOUSE"

/* Description of Object Relation */

BEGIN

Identifier = "Object-Relation-Sales"

Description = "Object Relation Sales"

AttributeName = "Sales_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Object-Relation-Product"

Description = "Object Relation Product"

AttributeName = "Product_ Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Object-Relation-Item"

Description = "Object Relation Item"

AttributeName = "Item_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Object-Relation-Category"

Description = "Object Relation Category"

AttributeName = "Category_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Object-Relation-Store"

Description = "Object Relation Store"

AttributeName = "Store_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Object-Relation-City"

Description = "Object Relation City"

AttributeName = "City_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Object-Relation-State"

Description = "Object Relation State"

AttributeName = "State_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Object-Relation-Time"

Description = "Object Relation Time"

AttributeName = "Time_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Object-Relation-Month"

Description = "Object Relation Month"

AttributeName = "Month_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Object-Relation-Year"

Description = "Object Relation Year"

AttributeName = "Year_Oid"

AttributeDataType = "OID"

END /* End of Object Relation Description */

/* Description of Property Relation */

BEGIN

Identifier = "Property-Relation-Sales"

Description = "Property Relation Sales"

BEGIN

BEGIN /* Description of attributes * /

Identifier = "Sales_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Sales"

AttributeDataType = "NUMERIC"

END

END

END

BEGIN

Identifier = "Property-Relation-Store"

Description = "Property Relation Store"

BEGIN

BEGIN

Identifier = "Store_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "StoreName"

AttributeDataType = "CHARACTER"

END

END

END

BEGIN

Identifier = "Property-Relation-City"

Description = "Property Relation City"

BEGIN

BEGIN

Identifier = "City_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "City"

AttributeDataType = "CHARACTER"

END

END

END

BEGIN

Identifier = "Property-Relation-State"

Description = "Property Relation State"

BEGIN

BEGIN

Identifier = "State_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "State"

AttributeDataType = "CHARACTER"

END

END

END

BEGIN

Identifier = "Property-Relation-Product"

Description = "Property Relation Product"

BEGIN

BEGIN

Identifier = "Product_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "ProductName"

AttributeDataType = "CHARACTER"

END

END

END

BEGIN

Identifier = "Property-Relation-Item"

Description = "Property Relation Item"

BEGIN

BEGIN

Identifier = "Item_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Item"

AttributeDataType = "CHARACTER"

END

END

END

BEGIN

Identifier = "Property-Relation-Category"

Description = "Property Relation Category"

BEGIN

BEGIN

Identifier = "Category_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Category"

AttributeDataType = "CHARACTER"

END

END

END

BEGIN

Identifier = "Property-Relation-Time"

Description = "Property Relation Time"

BEGIN

BEGIN

Identifier = "Time_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Day"

AttributeDataType = "CHARACTER"

END

END

END

BEGIN

Identifier = "Property-Relation-Month"

Description = "Property Relation Month"

BEGIN

BEGIN

Identifier = "Month_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Month"

AttributeDataType = "CHARACTER"

END

END

END

BEGIN

Identifier = "Property-Relation-Year"

Description = "Property Relation Year"

BEGIN

BEGIN

Identifier = "Year_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Year"

AttributeDataType = "CHARACTER"

END

END

END /*End of Property Relation Description */

/* Description of Association Relation */

BEGIN

Identifier = "Association-Relation-Id"

Description = "Association Relation Definition "

BEGIN

BEGIN

Identifier = "Sales_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Store_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Time_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Product_Oid"

AttributeDataType = "OID"

END

END

END /* End of Association Relation Description */

/* Description of Characteristic Relation */

BEGIN

Identifier = "Characteristic-Relation-City-Store"

Description = "Characteristic Relation City-Store"

BEGIN

BEGIN

Identifier = "City_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Store_Oid"

AttributeDataType = "OID"

END

END

END

BEGIN

Identifier = "Characteristic-Relation-State-City"

Description = "Characteristic Relation State-City"

BEGIN

BEGIN

Identifier = "State_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "City_Oid"

AttributeDataType = "OID"

END

END

END

BEGIN

Identifier = "Characteristic-Relation-Item-Product"

Description = "Characteristic Relation Item-Product"

BEGIN

BEGIN

Identifier = "Item_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Product_Oid"

AttributeDataType = "OID"

END

END

END

BEGIN

Identifier = "Characteristic-Relation-Category-Item"

Description = "Characteristic Relation Category-Item"

BEGIN

BEGIN

Identifier = "Category_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Item_Oid"

AttributeDataType = "OID"

END

END

END

BEGIN

Identifier = "Characteristic-Relation-Month-Day"

Description = "Characteristic Relation Month-Day"

BEGIN

BEGIN

Identifier = "Month_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Day_Oid"

AttributeDataType = "OID"

END

END

END

BEGIN

Identifier = " Characteristic-Relation-Year-Month"

Description = "Characteristic Relation Year-Month"

BEGIN

BEGIN

Identifier = "Year_Oid"

AttributeDataType = "OID"

END

BEGIN

Identifier = "Month_Oid"

AttributeDataType = "OID"

END

END

END /* End of Characteristic Relation Description */

/* Description of Association-Graph Relation */ 

BEGIN

Identifier = "Association-Graph-Rel"

Description = "Association Graph Relation"

BEGIN

SUP = "Object-Relation-Sales"

SUB = "Object-Relation-Time"

END

BEGIN

SUP = "Object-Relation-Sales"

SUB = "Object-Relation-Store"

END

BEGIN

SUP = "Object-Relation-Sales"

SUB = "Object-Relation-Product"

END

END /* End of Association-Relation Description */

/* Description of Characteristic-Graph Relation */ 

BEGIN

Identifier = "Characteristic-Graph-Relation"

Description = "Characteristic Graph Relation Definition"

BEGIN

Identifier = "Year-Month"

SUP = "Object-Relation-Year"

SUB = "Object-Relation-Month"

END

BEGIN

Identifier = "Month-Day"

SUP = "Object-Relation-Month"

SUB = "Object-Relation-Time"

END

BEGIN

Identifier = "State-City"

SUP = "Object-Relation-State"

SUB = "Object-Relation-City"

END

BEGIN

Identifier = "City-Store"

SUP = "Object-Relation-City"

SUB = "Object-Relation-Store"

END

BEGIN

Identifier = "Category-Item"

SUP = "Object-Relation-Category"

SUB = "Object-Relation-Item"

END

BEGIN

Identifier = "Item-Product"

SUP = "Object-Relation-Item"

SUB = "Object-Relation-Product"

END

END /* End of Characteristic-Graph-Relation Description */

END DATABASE