Supporting functional aspects in relational databases

Transcription

1 Supporting functional aspects in relational databases Matthias Liebisch Database and Information Systems Group Friedrich-Schiller-University Jena Jena, Germany Abstract Fundamental concepts of information technology involve modularisation and encapsulation to handle inherent complexity and achieve some worthwhile system qualities, for example extensibility. This also applies to relational database systems, which have been playing a central role for the storage of application data for thirty years. However, some cross-cutting concerns, for example the need to support internationalisation, interfere the process of modelling business objects and requirements as encapsulated logical units. This paper presents an approach to support cross-cutting concerns, also designated as functional aspects, in relational database systems. Thereby the concept pursues the intention to ensure important characteristics derived from the paradigm of aspect-oriented data management, particularly orthogonality and locality for functional aspects. Besides a relational data model, which is illustrated with a practical example, a XML structure for description of functional aspects is shown. Index Terms functional aspects, aspect-oriented data management, relational reference model, meta-data definition for functional aspects, integration of functional aspects I. INTRODUCTION In many scopes of information technology a fundamental strategy involve modularisation and encapsulation of both functionality and data resulting in logical units to handle inherent complexity and ensure maintainability, extensibility as well as reusability. Some well known examples can be found in the definition of system architectures and layer models such as the ANSI/SPARC database model[6]. Another evidence for this proposition appears in the history of programming languages. Starting with assembler languages followed by procedural programming languages, the paradigm of objectoriented programming (OOP) became the most important programming model during the last 20 years. In all these evolution steps more and more potential was created to qualify software engineers for developing reusable and maintainable code, which modularises logically related functions and data. However, pure OOP doesn t have the ability to solve all problems. Even in the case of an optimal encapsulation of the business logic, cross-cutting concerns can t be modularised similarly because their functionality is spread across a lot of modules and logical units[3]. Examples for cross-cutting concerns are exception handling, logging and transaction management. Therefore the maintenance of the code becomes more time-consuming and complex, reusability is not ensured. To overcome these difficulties the aspect-oriented programming (AOP) paradigm has been established during the last decade[7]. AOP languages like AspectJ[2] define syntactical constructs as join points, pointcuts and advices to implement such aspects in a unitised manner and to combine them later with the application code in the weaving process. Due to the fact that database management systems (DBMS) perform a central part for saving data in most modern applications, the existence of cross-cutting concerns in the latter also has implications for underlying databases. One approach to deal with this effects is described by RASHID, who postulates aspect-oriented database systems (AODB) as advancement of object relational/oriented database systems. This includes AOP techniques to provide resources for storing and retrieving aspects of a programming language like AspectJ as well as using AOP methods for the database system implementation itself[10]. By contrast this paper specifies a model to support cross-cutting concerns, referred to as functional aspects, in relational database management systems (RDBMS), because since the relational model[4] was developed and published it became the most important and prevalent database model over the last 40 years. Therefore a wide acceptance and a high suitability for daily use can be achieved. The rest of the paper is structured in the following way. At first a closer look at functional aspects is given in section II, which includes a definition and some essential properties. In section III a reference model for the relational implementation of functional aspects is presented. Finally the paper is completed by a summary and an outlook in section IV. II. FUNCTIONAL ASPECTS As shown in section I, cross-cutting concerns also have an impact on databases. You need to distinguish the following term for further discussion: Definition. A functional aspect refers to a specific crosscutting property in the context of a database, which neither is primary subject of modelling the business logic requirements nor can be attached to an individual business object (logical unit). Instead such a property is related to a multitude of all modelled objects. Internationalisation, versioning or tenant support[1] are well-known examples for functional aspects of data models.

2 Generally they can be imagined as a hypercube or a k- dimensional matrix spanned for each table cell in the relational model. Thereby k is determined by the number of functional aspects A 1,..., A k defined for a specific table column and each dimension for aspect A i (1 i k) is rasterized according to the inherent distinct key values, e.g. the continuing growing set of revision numbers for the functional aspect versioning. A. Characteristics Based on the definition given above, the fundamental strategy described at the beginning, namely encapsulation of function and data, runs the risk of being violated within a straightforward storage process of functional aspects. Therefore it is necessary to introduce a new modelling approach to deal with these challenges. Such an approach is represented by the paradigm of aspect-oriented data management, which is described through five characteristics: modularity, orthogonality, locality, universality and usability[8]. Particularly orthogonality and locality represent truly important requirements for developing a reference model (see section III) to integrate more than one functional aspect in a database, hence they are described in detail. The orthogonality property includes two dimensions. On the one hand a set of n different aspects results in n! possible sequences for integrating them in a database model. Otherwise it should be expected, that a specific attribute is relevant for arbitrary [0,..., n] aspects. Thereby the following formular is valid for two aspects A i and A k regarding their influenced attribute sets M: M(A i ) M(A k ) = c (0 c m), with m = max( M(A i ), M(A k ) ) Orthogonality requires for an aspect integration, that all potential sequences transform a given database model into a semantic equivalent state as well as no interdependency exists between aspects concerning their swayed attribute sets. By locality the mapping of functional aspects should be designed in such a manner, that in case of an aspect integration the whole database model doesn t need to be transformed. Instead, changes - as minimal as possible - have to be sufficient only at indispensable logical units. B. Integration As denoted by the usability requirement in the last paragraph, some kind of support is needed to make an aspect applicable in a database. This includes not only a dialoguebased integration tool as described in[8], but also a descriptive medium for specifying the functional aspect. This medium, concretely a XML document whose structure is presented in section III, can be independently maintained and is finally evaluated by the integration tool. III. REFERENCE MODEL This section demonstrates, how functional aspects and relational databases can be brought together under the paradigm of aspect-oriented data management. The delineated approach ensures the associating five characteristics, especially the desired property of modularity. Beside a concrete relational implementation a descriptive structure for functional aspects is introduced, both illustrated with a simplified example. A. Relational implementation Basic principles for the relational model shown in Fig. 1 arise from the EAV concept[9], which defines the tables ENTITY, ATTRIBUTE and VALUE combined with a rotated storage. That means, object attributes will not be mapped into classical table columns but rather result in table rows. Thereby it s possible to store additional information of objects without performing a schema evolution only by inserting data. In the context of this paper consequences of functional aspects represent such supplementary data, for example translated attributes of business objects in the case of internationalisation. The relational representation of functional aspects incorporates eight tables (see Fig. 1), which can be divided into three groups. Generally each table has an artificial primary key, other attributes will be described in the following. Aspect meta data: The associated tables build a simplified database catalogue, which is needed to administrate all tables respectively columns affected by functional aspects. ASPECTTABLE only stores schema and name for a table, which is referenced by ASPECTCOLUMN.TABLE in conjunction with name and data type for a column. The latter attribute points to a record in ASPECTDATATYPE, where name, length and scale (only reasonable for numeric types) specify a data type. During the execution of the integration tool for applying a functional aspect, the user has to decide in the third step which tables and columns are relevant for the current aspect[8]. These information should be initially stored in ASPECTTABLE and ASPECTCOLUMN. Aspect master data: As the group name suggests with these three tables master data of functional aspects is being specified in an adequate way. At first a name, key attribute and its data type are maintained for an aspect in ASPECTDEFINITION. All permitted values for an aspect key will be stored in ASPECTKEYVALUE, consisting of a reference to the particular aspect, the key value in itself plus a comment. Because different functional aspects can have different data types for their key, the attribute ASPECTKEYVALUE.KEYVALUE has to use a generic built-in data type, for example VARCHAR. Finally, additional information for a specific aspect held in further tables can be stored in ASPECTADDITIONAL, the evaluation of these tables remains at the application s responsibility. Aspect weaving data: This is the most interesting group where the connection between functional aspects and business objects is realised. In the first step a specific attribute value (business object property) defined by a table, a column and the row identifier (primary key value) is extended by a new value in ASPECTVALUE. The data

3 Fig. 1. Relational model for functional aspects (without data types) type for VALUE has to be generic again, the accordingly loss of semantic information can be partly intercepted by the indirect related table ASPECTDATATYPE. Afterwards the actual catenation with a functional aspect is done in table ASPECTASSIGN by referencing a specific aspect (ASPECT) and one of its feasible key values (KEYVALUE) for an aspect-related attribute assignment as described before (ASPECTVALUE). It s imaginable, that one record in ASPECTVALUE is referenced more than once in ASPECTASSIGN, for example by varying aspect key values or even by different functional aspects. The latter case is necessary to manage the dependencies for table columns which are influenced by more than one functional aspect. This procedure of isolation corresponds to the requirement of orthogonality discussed in section II. As described above, in ASPECTVALUE.ROWID the primary key value of an arbitrary table row has to be stored. Therefore the assumption must apply, that each relevant table exhibits a primary key based on a single attribute which has a uniform data type. This can easily be ensured by an additional artificial attribute with option auto increment declared as primary key. Furthermore some integrity constraints must be enforced: Uniqueness over (TABLE, COLUMN, ROWID, VALUE) in table ASPECTVALUE Uniqueness over (KEYVALUE, ASPECT, ASPECTVALUE) in table ASPECTASSIGN B. Description of functional aspects After the relational data model for functional aspects has been explained in the last section, a structure for their description, more precisely the group aspect master data in Fig. 1, is now presented as announced in section II. A capable approach is to map all necessary information into a XML document, because on the one hand such a document can both easily modified by humans and processed by applications, otherwise the intrinsic semi-structured characteristic[5] provides the flexibility which is just needed for functional aspects. As shown in Fig. 2 the XML layout will be illustrated based on the exemplary functional aspect internationalisation. Starting with the tag <aspect> a unique name for the functional aspect must be declared, which is mapped to ASPECTDEFINITION.NAME, whereas the subsidiary elements build up a precise definition: <desc>: optional description of the functional aspect <key>: specifies the aspect key by mapping name to ASPECTDEFINITION.KEY and all other attributes to a record in ASPECTDATATYPE <value>: contains a permitted value for the aspect key including a comment and will be mapped accordingly to ASPECTKEYVALUE <additional>: optional element for additional data relevant for a functional aspect, which is described in tables, e.g. branching information for the versioning aspect or locale hierarchies for the internationalisation aspect

4 <?xml version="1.0" encoding="utf-8"?> <definitions> <aspect name="i18n"> <desc>internationalisation</desc> <key name="locale" typename="string" length="5" scale=""> <value comment="germany"> de_de</value> de_ch</value> fr_ch</value> it_ch</value> </key> <additional> <table name="localedep" comment="locale hierarchie info"> <sql> CREATE TABLE LocaleDep ( Locale INT NOT NULL, ParentLocale INT, Comment VARCHAR(250), PRIMARY KEY (Locale), FOREIGN KEY (Locale) AspectKeyValue(AspKeyID), FOREIGN KEY (ParentLocale) AspectKeyValue(AspKeyID) ); </sql> </table> </additional> </aspect> </definitions> Fig. 2. XML structure for description of functional aspects <table>: defines an additional aspect table and will be mapped correlatively to ASPECTADDITIONAL <sql>: contains the SQL code for the table definition and will be executed by the integration tool C. Example This section illustrates the consequences of internationalisation (I18N) for a module table DEMO.MODULE as a realistic example. A module consists of an item number (primary key), a name, a price with its currency and some system flags, which shouldn t be affected by any functional aspect. The aspect key for I18N is a so-called locale, which corresponds to the Java standard class java.util.locale[11]. The complete description of the aspect internationalisation is given by the XML structure in Fig. 2, which yields to the tables shown in Fig. 3 after processing by the integration tool. Now let s have look at some specific data, for example the first row in ASPECTASSIGN. This record concatenates an aspect-related attribute assignment (ASPECTVALUE = 3000) with the functional aspect I18N (ASPECT = 2000) linked with the aspect key value de DE (KEYVALUE = 2100). Therefore, following the reference to the first row in ASPECTVALUE, DEMO.MODULE ITEMNR NAME PRICE CURRENCY FLAGS screw 0.75 e cable 0.10 e Aspect meta data ASPECTTABLE ASPTABID SCHEMA TABLENAME 1000 Demo Module ASPECTCOLUMN ASPCOLID TABLE COLUMNNAME DATATYPE Name Price Currency 1202 ASPECTDATATYPE ASPTYPEID TYPENAME LENGTH SCALE 1200 STRING NUMERIC STRING Aspect master data ASPECTDEFINITION ASPDEFID NAME KEY DATATYPE 2000 I18N Locale 1202 ASPECTKEYVALUE ASPKEYID ASPECT KEYVALUE COMMENT de DE Germany de CH Switzerland fr CH Switzerland it CH Switzerland ASPECTADDITIONAL ASPADDID ASPECT TABLENAME COMMENT LocaleDep Locale hierarchie info LOCALEDEP LOCALE PARENTLOCALE COMMENT Aspect weaving data ASPECTVALUE ASPVALID TABLE COLUMN ROWID VALUE Schraube cavo ASPECTASSIGN ASPASSID KEYVALUE ASPECT ASPECTVALUE Fig. 3. Example for the relational reference model

5 one can see that in table Demo.Module (TABLE = 1000) the value for attribute Name (COLUMN = 1100) in the first record (ROWID = 19780) is translated with Schraube (VALUE). Other aspect-related attribute assignments can be maintained analogously, whether for the same functional aspect or any other one. IV. SUMMARY The on hand paper presented a reference model to apply functional aspects to relational database systems with respect to orthogonality and locality as truly important requirements. For this purpose a relational data model was introduced as well as a descriptive XML structure processable by an integration tool. Based on this, functional aspects as occurrence of crosscutting concerns can be modularised in a given data model respective to their functionality and data, whereby valuable properties like extensibility, maintainability and reusability can be ensured. The feasibility of the approach was demonstrated with a practice-oriented example. Future work will concentrate on strategies to handle the application side access to functional aspects in a database. Particularly, this includes the EAV based tables ASPECTVALUE and ASPECTASSIGN. Furthermore a prototypical implementation of the delineated concept is intended, this regards the relational modelling in an existing database management product as well as the development of the mentioned integration tool for functional aspects. [1] S. Aulbach, T. Grust, D. Jacobs, A. Kemper, and J. Rittinger. Multitenant databases for software as a service: schema-mapping techniques. In SIGMOD Conference, pages , [2] O. Böhm. Aspektorientierte Programmierung mit AspectJ 5: Einsteigen in AspectJ und AOP. dpunkt.verlag, [3] R. Chitchyan, I. Sommerville, and A. Rashid. An Analysis of Design Approaches for Crosscutting Concerns. In Workshop on Aspect-Oriented Design (held in conjunction with the 1st Aspect Oriented Software Development Conference AOSD), [4] E. F. Codd. A relational model of data for large shared data banks. CACM, 13(6): , [5] E. R. Harold and W. S. Means. XML in a Nutshell: A Desktop Quick Reference. O Reilly Media, [6] D. A. Jardine. ANSI/SPARC DBMS Model. Elsevier Science Publishing Co Inc., [7] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. V. Lopes, J. Irwin, and J.-M. Loingtier. Aspect-Oriented Programming. In ECOOP, pages , [8] M. Liebisch. Aspektorientierte Datenhaltung - ein Modellierungsparadigma. In Grundlagen von Datenbanken Workshop 2010, Bad Helmstedt, Germany, May [9] P. Nadkarni, L. Marenco, R. Chen, E. Skoufos, G. Shepherd, and P. Miller. Organization of Heterogeneous Scientific Data Using the EAV/CR Representation. In JAMIA, 6, pages , [10] A. Rashid. Aspect-Oriented Database Systems. Springer, [11] H. Schildt. Java J2SE. The Complete Reference. Mcgraw-Hill Professional, 2005.