On Using a Semiotic Quality Framework to

On Using a Semiotic Quality Framework to Evaluate the Quality of Conceptual Database Schemas Erki Eessaar Department of Informatics, Tallinn University of Technology, Raja 15, 12618 Tallinn, Estonia [email protected] Abstract-In this paper, we introduce a semiotics-based framework for evaluating the quality of conceptual schemas of databases. We created it based on an existing semiotics-based framework that has been used to evaluate other types of software entities. We propose two measures for evaluating the perceived semantic quality of conceptual schemas. The measures consider correspondence between conceptual data models and conceptual schemas that are created based on the models. In addition, we describe how to use one of the measures to evaluate computeraided software engineering systems in terms of transforming conceptual data models into conceptual database schemas.

I.

INTRODUCTION

One of the first steps of database development is the creation of a conceptual data model [1]. Integrity constraints are integral and important part of conceptual models. They specify the semantics of problem domain [2]. Moody [3] identifies over 50 proposals about the quality of conceptual models. According to the transformational and model-driven approach [4], database developers create logical data models, physical data models, and statements of data definition language (DDL) by using a sequence of transformations. The resulting schema of each transformation should have the same descriptive power as the source schema, though with a different representation. One has to execute the DDL statements in a database management system (DBMS) to create database schemas. According to the ANSI-SPARC architecture, a database has one or more external views, one conceptual view, and one internal view. The conceptual view “is a representation of the entire information content of a database” [5, p. 39]. Each such view is defined by means of a schema. In this paper, we propose a novel framework for investigating the quality of conceptual schemas. We do not consider external and internal schemas. The development of views (that belong to the external schemas) and objects that help developers to improve the performance of database operations (that belong to the internal schema) is too DBMS-specific. Some authors use the concept “conceptual schema” to denote a conceptual data model but in this paper it denotes a part of implementation of a database. For relational databases there exist a number of formal principles like the normalization theory and the principle of orthogonal design [5] that guide the development and evaluation of relational database schemas. Baroni et al. [6] present a set of measures for evaluating object-relational

databases. The measures do not take into account how well a database schema corresponds to the requirements, based on which the database is created. The transformation rules for creating the conceptual schema of a SQL-database based on a conceptual data model, which is created by using UML, are presented for instance in [7]. In addition, Marcos et al. [8] present a set of rules for transforming generalization and whole-part relationships to an object-relational database schema. If the transformation rules are violated, then a high quality conceptual data model may result in a poor conceptual database schema. Blaha [9] and Cleve et al. [10] describe deficiencies in the existing database schemas. For instance, many integrity constraints are not enforced at the database level. It may decrease data quality [10] and productivity of application developers [11]. A possible reason of such state of affairs is that existing computer-aided software engineering (CASE) systems provide limited support for generating code that implements different integrity constraints [12]. In addition, SQL and SQL DBMSs limit the use of declarative integrity constraints [13] and hence one has to use complex trigger procedures to implement many constraints. However, such difficulties should not prevent us from trying to improve the quality of database implementations. The first goal of the paper is to propose a semiotics-based framework for evaluating the quality of conceptual schemas of databases. It is based on the semiotic quality framework of conceptual modeling SEQUAL that was proposed by Lindland et al. [14] and has been revised and extended since then. We concentrate our attention to the perceived semantic quality. Our examples are based on SQL. However, the framework is usable in case of any database language, the abstract syntax of which can be specified by using a metamodel. The framework can be used to compare model transformation facilities of different CASE systems. The second goal of the paper is to present a method for evaluating CASE systems in terms of transforming conceptual data models into conceptual database schemas and the results of a small experiment. The rest of the paper is organized as follows. Firstly, we specify a semiotic quality framework for evaluating conceptual schemas of databases. We apply it to evaluate the quality of a database schema. In addition, we propose a method for evaluating CASE systems in terms of their model transformation facilities. Finally, we draw conclusions and point to the future work with the current topic.

II. A QUALITY FRAMEWORK OF CONCEPTUAL DATABASE SCHEMAS Some researchers have used semiotics as the basis of evaluation frameworks of different kinds of software entities. For instance, Lindland et al. [14] and Krogstie et al. [15] use semiotics to evaluate conceptual models and process models, respectively. Merriam-Webster dictionary [16] defines semiotics as “a general philosophical theory of signs and symbols that deals especially with their function in both artificially constructed and natural languages and comprises syntactics, semantics, and pragmatics”. Each database language provides a concrete syntax for creating data types, data structures, constraints, and operators. Each conceptual schema is created by using a set of statements in a data definition language (DDL). This language is a subset of a database language. Hence, it is interesting to evaluate such schemas in semiotic/linguistic terms. In this paper, we explain how to use semiotics as a basis to evaluate the quality of conceptual schemas and how some of the existing approaches fit to this framework. The proposal should extend existing evaluation approaches, but not replace them. Krogstie et al. [15] use a set-theoretic approach to present a semiotics-based framework of evaluating model quality. They define model quality at different semiotic levels as the correspondence between statements that belong to different sets. We describe some of the sets in terms of our problem domain – evaluation of conceptual schemas. G – the goals that a database must help its users to achieve. L – the set of all the statements that one can make by using a database language. The language is usable in a DBMS, based on which the database will be implemented. For example, it can be a dialect of SQL that corresponds to the SQL:2006 standard [17]. Each database language has the underlying data model – an abstract programming language – that determines the abstract syntax of L. D – “the domain, that is, the set of all the statements that can be stated about the situation at hand” [15]. Ks – the pertinent explicit knowledge of the set of stakeholders who are involved in modeling. This knowledge about the domain is specified by using a conceptual data model that represents stakeholders’ perception of reality. It is created during system analysis. M – the externalized model, which is the conceptual schema of a database in our case. We assume that the externalized model consists of statements that belong to L. I – the social actor interpretation. It is the set of all the statements that the audience (database developers and users) thinks that M consists of. A. Semantic Quality and Perceived Semantic Quality Semantic quality is in our case the correspondence between a conceptual schema M and a domain D [15]. The goals of semantic quality are feasible validity and feasible completeness. In our case validity means that all the statements, which are made by a schema, are correct and relevant in terms of its domain [14]. Completeness means that a schema contains all the statements about its domain that are

correct and relevant [14]. Feasible means that there is no improvement of the semantic quality such that its additional benefit to a schema exceeds the drawbacks of using it. We classify the use of normalization theory and the principle of orthogonal design as the means to improve the validity of conceptual schemas. They consider dependencies between data elements that are themselves integrity constraints and as such specify the semantics of the problem domain. It is hard to measure the semantic quality because “both the problem domain and the minds of the stakeholders are unavailable for formal inspection” [15, p. 94]. Next, we propose how to measure perceived semantic quality of conceptual schemas. It covers correspondence between Ks (stakeholders’ knowledge of D) and I (interpretation of M). Its goals are perceived validity and perceived completeness. A candidate measure EV(M) can be used for evaluating the perceived validity of a conceptual schema M. A candidate measure is a measure that experts have not yet accepted or rejected. EV(M): Let X be the set of all the elements in a conceptual data model Ks. Let Y be the set of all the elements in a conceptual schema M. Let y be the cardinality of Y. Let W be the set of all the elements in Y that have a corresponding element in X. There exists an ordered pair (correspondence) of elements (a, b) if element b in Y is created based on an element a in X by using a sequence of transformations and without the loss of semantics. Hence, it must be possible to trace the origin of b to a. Let w be the cardinality of W. In this case EV(M) = w/y. The possible value of EV(M) is between 0 and 1 (endpoints included). 0 and 1 denote minimal (total lack of) and maximal perceived semantic validity, respectively. Ideally, there must be a total surjective function f: X→Y. Next, we present a candidate measure EC(M) for evaluating the perceived completeness of a conceptual schema M. EC(M): Let X be the set of all the elements in a conceptual data model Ks. Let x be the cardinality of X. Let Y be the set of all the elements in a conceptual schema M. Let Z be the set of all the elements in X that have a corresponding element in Y. There exists an ordered pair (correspondence) of elements (a, b) if element b in Y is created based on an element a in X by using a sequence of transformations and without the loss of semantics. Hence, it must be possible to trace the origin of b to a. Let z be the cardinality of Z. Then EC(M) = z/x. The possible value of EC(M) is between 0 and 1 (endpoints included). 0 and 1 denote minimal (total lack of) and maximal semantic completeness, respectively. Ideally, there must be a total surjective function f: Y→X. How to find the elements of a conceptual data model and a conceptual schema? Both of them are created by using a language. For instance, one could create a conceptual data model by using UML and implement a conceptual schema by using SQL. It is possible to specify the abstract syntax of a language by using a metamodel. If we use UML class models for creating metamodels, then classes specify language elements and properties/ relationships specify relationships

between the language elements [18]. One could perform the analysis of perceived semantic quality based on the language elements that correspond to the classes in the metamodels. Meta Object Facility (MOF) Specification [19] describes four-layer metadata architecture. Metamodels and models, which are created according to the metamodels, belong to M2 and M1 layer, respectively. Fig. 1 presents a fragment of a metamodel of a language that can be used to create conceptual data models (on the left) as well as a fragment of a metamodel of a database language that can be used to implement conceptual schemas (on the right). A class c1 from a metamodel m1 can have more than one corresponding class in a metamodel m2 and vice versa. For instance, in case of SQL:2006, one could implement a constraint in a conceptual data model by using assertions or trigger procedures. Next, we calculate the values of EV(M) and EC(M) based on the information at M1 layer in Fig. 1. In the analysis, we use elements that correspond to the classes at M2 layer. X={Person, Person.last_name String, String, {The number of persons cannot be bigger than 30}} and Y={Person, Person.first_name VARCHAR, Person.last_name INTEGER, VARCHAR, INTEGER}. W={Person, VARCHAR}, y=5, and w=2. EV(M)=w/y=2/5=0.4. Column last_name is not in W because it has lost semantics during the transformation – it has a wrong type. In addition, the schema specifies column first_name that has no corresponding element in the conceptual data model. Z={Person, String}, x=4, and z=2. In this case EC(M)=z/x=2/4=0.5. A reason of quite low semantic completeness is that the conceptual data model specifies an integrity constraint that has no corresponding elements in the conceptual schema. B. Other Quality Levels Syntactic quality is in our case the correspondence between a conceptual schema M and the set of all the possible database language statements L [15]. Constraint 0..* Class

1..* Attribute 0..* 0..* 1 Type 1

0..* Assertion Table 1..* 1 Column 1..* 0..* 1 Type

String

Varchar

Integer

Integer

M2 layer – metamodel Person -last_name : String

{The number of persons cannot be bigger than 30}

CREATE TABLE Person (first_name VARCHAR, last_name INTEGER);

Mapping

M1 layer – model Fig. 1: Identification of elements for the evaluation of perceived semantic quality of conceptual schemas.

Syntactic correctness is the only syntactic goal [15]. In case of conceptual schemas the syntactic correctness is checked by a DBMS before the DDL statements for creating/altering the schema are executed. One can improve the syntactic quality by using code generators. In this case developers have to write less code and hence have fewer possibilities to make syntax errors. Unfortunately, existing CASE systems provide limited support for generating code that implements integrity constraints [12]. Hence, one could instead use specific code generators for that purpose. For example, Vasilecas et al. [20] propose template-based generation of SQL triggers based on business rules. Pragmatic quality is in our case the correspondence between a conceptual schema M and actor interpretation I [15]. Krogstie et al. [15] write that comprehension is the only pragmatic quality goal. Conceptual schemas must be understandable to their audience. Baroni et al. [6] present a set of measures for evaluating conceptual schemas of object-relational databases. The measures help us to evaluate the complexity of schemas and as such can be used to evaluate the pragmatic quality of schemas. Next, we list some means that DBMSs or separate database management applications can provide to improve the pragmatic quality of the conceptual schema of a database DB. Possibility to register comments about schema elements in the system catalogue of DB. For instance, PostgreSQL™ [21] allows developers to use COMMENT statement. Possibility to search data about schema elements from the system catalogue of DB. It must be possible to use the same query language as in case of other parts of DB. Views, like the ones defined in INFORMATION_SCHEMA [17], simplify the creation of such queries. Visualization of schema elements and dependencies between the elements. Information about the elements and their interdependencies is in the system catalogue of DB. A problem with the current SQL DBMSs is that the meaning of procedural code (for instance, in trigger procedures) becomes apparent only after careful inspection of the code. Hence, to improve the pragmatic quality of schema, one should comment the code and follow other guidelines to improve the readability of code. These means also increase the empirical quality of a database schema. Pragmatic means also include ensuring the continuous availability of models that have been used to create a schema because they help users to understand the schema. Krogstie et al. [15] write that externalisation and internalisability are the goals of physical quality. Externalisation means that each conceptual schema must be available as a physical artifact that consists of statements of database language. Some DBMSs provide means to generate data definition language statements based on information in the system catalogue of a database. Internalisability means that each conceptual schema must be accessible so that interested parties (database users as well as database developers) can make sense of it. Hence, each schema should be accessible as a part of a database. The

means that increase internalisability are the same as the means to achieve high availability of databases. C. Discussion The proposed candidate measures EV(M) and EC(M) depend on the existence of conceptual data models that are rich in detail and have high quality. They are the most useful in the context of Model Driven Development, according to which one can create a database implementation from a conceptual data model by using a sequence of transformations. Simsion [22] investigates the state of the art of data modeling and concludes that many practitioners do not create conceptual data models or create them as high-level preliminary artifacts without much detail. For instance, Simsion [22] notes that most of practitioners exclude identification of attributes from the activities of conceptual data modeling stage (see Fig 2). It is possible that creators of a conceptual data model choose to present very few/basic integrity constraints. It may be caused by the existing work practices, lack of education, limitation of modeling languages, limitations of CASE systems that are used to create models, or frustration about difficulties of enforcing the constraints in a database. Hainaut [4] also notes that coping with constraint propagation during transformation-based database development is still a problem that needs to be addressed. If a conceptual data model is a high-level preliminary artifact, then the value of EC(M) may be high although the conceptual schema does not sufficiently reflect the real world. A semiotic framework that is specified in [14] can be used to improve the quality of conceptual models. It is also possible that database developers have not created the conceptual data model at all. In this case it is not possible to use the proposed measures. On the other hand, the proposed framework could encourage the creation of a conceptual data model during database development because it helps interested parties to measure the results of database development. The use of EV(M) and EC(M) requires the existence of metamodels of conceptual modeling languages and database languages. If these metamodels do not exist, then the use of the proposed measures will be time consuming because developers firstly have to create the metamodels. The values of semantic quality measures depend on the quality of metamodels that are used for the analysis. For each language there can be more than one metamodel. They are used for different purposes like code generation, teaching, etc. For instance, let us assume that a metamodel of a conceptual modeling language (see Fig. 1) does not contain classes Constraint, Attribute, and Type. In this case X={Person}, Z={Person}, x=1, z=1, and EC(M)=z/x=1/1=1. The results of evaluation depend on the language that is used to create conceptual data models. Different languages have different levels of expressiveness. For instance, it is possible that in a language L1 one can represent a constraint by using a specific model element but in case of language L2, one has to use a separate language like OCL to represent the constraint. Therefore, in case of calculating EV(M) and

EC(M) it is necessary to document the language that is used to create the conceptual data model and versions of metamodels that are used as the basis of analysis as well as the stakeholders who performed the analysis. This information is needed to decide whether two different measurement results are comparable or not. It is possible that different stakeholders have different opinions about whether the semantics of a conceptual data model element is preserved in the corresponding conceptual schema. Therefore, the evaluation results are somewhat subjective in nature. To repeat, EV(M) and EC(M) allow us to calculate perceived semantic quality because the results depend on the users perception of M and D. One has to improve the pragmatic quality of conceptual data models and conceptual schemas so that interested parties can better understand them during the analysis of perceived semantic quality. It is also necessary to educate interested parties about conceptual modeling and database design to enhance the quality of their observations. D. An Example In this section, we present an example based on a database that is created by using database language that conforms to the SQL:2006 standard [17]. The proposed framework and measures can be used in case of other database languages as well. TPC BENCHMARK™ C [23] specifies a database for the wholesale supplier company that has a number of geographically distributed sale districts and warehouses. The document presents entity types, relationship types, and additional requirements to the data in the database. These requirements help us to determine the multiplicity of relationships. Based on this information it is possible to create an entity-relationship diagram (see Fig. 2) that is a part of a conceptual data model. One should implement the database as a SQL database according to the benchmark document. The document presents table layouts: column names, column types, primary key constraints, and foreign key constraints. The description of table layouts specifies the conceptual schema of the database. In this paper, we calculate the values of EV(M) and EC(M) based on the specifications in TPC BENCHMARK™ C document. There is a non-conformance between the conceptual data model and the conceptual schema in the document. The conceptual data model does not include specifications of properties (attributes) and unique identifiers. 1

1..*

1

1 Warehouse 100000 Stock Item

10 District New_order 0..1 1 3..* Order_line 5..15

History 1

1..* 3000 Customer 1 1 1..* 1 Order 1

Fig. 2: An entity-relationship diagram.

In addition, the conceptual data model specifies multiplicity constraints, some of which are not explicitly implemented in the conceptual schema. We assume that UML is used to create entity-relationship diagrams. In this case classes and associations are used to represent entity types and relationship types, respectively. Therefore, we use a UML metamodel [24] as a basis of our analysis. In addition, we use a metamodel of SQL that is specified as a part of Common Warehouse Metamodel (CWM) Specification [25]. Firstly, we have to determine the correspondence (mapping) between the classes of metamodels (see Table 1). In some cases, one has to create multiple different SQL elements based on one UML element (AND operation). In some cases, one could choose, which set of elements to create based on an UML element (OR operation). Next, we calculate the value of EV(M). The number of elements in the conceptual schema (y) is 125: 9 tables, 92 columns, 8 primary key constraints, 10 foreign key constraints, and 6 different types. The types, which are used in the conceptual schema, are unique ID, variable text, fixed text, signed numeric, unsigned numeric, and date and time. Each table has a corresponding entity type. There is one foreign key constraint that does not have a corresponding relationship type (a foreign key constraint of table History). Hence, the number of elements of the conceptual schema, which do have the corresponding elements in the conceptual data model, is 18. EV(M)=18/125=0.14. The validity of the conceptual schema is quite low. The main reason of such result is that the conceptual data model does not contain the specification of attributes. Therefore, the results are mainly indication of the problems of the conceptual data model. Next, we calculate the value of EC(M). The number of elements in the conceptual data model (x) is 36: 9 entity types, 9 relationship types, and 18 multiplicity elements. Each entity type has a corresponding table in the conceptual schema. Each relationship type has a set of corresponding foreign key columns and a foreign key constraint in the conceptual schema. In addition, multiplicity elements 1 and 0..1 have been explicitly implemented in the conceptual schema. On the other hand, multiplicity elements 10, 3000, 100000, 1..*, 3...*, and 5..15 have not been explicitly implemented in the conceptual schema. They are used as implicit constraints that one has to take into account during the generation of test data. TABLE I CORRESPONDENCE BETWEEN CLASSES OF METAMODELS UML metamodel [24] Class Property Association

Multiplicity Element Constraint

SQL metamodel [25] Table (Table AND Column AND UniqueConstraint AND ForeignKey) OR Column (Column AND ForeignKey) OR (Table AND Columns AND UniqueConstraint AND ForeignKeys) Column OR CheckConstraint OR Trigger OR UniqueConstraint PrimaryKey OR UniqueConstraint OR CheckConstraint OR Trigger

Therefore, the number of elements of the conceptual data model that do have the corresponding elements in the conceptual schema is 28. EC(M)=28/36=0.78. As you can see, the conceptual schema does not have the highest possible completeness (1). One could argue that it is not feasible to increase the completeness any more due to difficulties in enforcing the multiplicity constraints. However, it also points to the problems with SQL and its implementations in various DBMSs. The next example illustrates difficulties in enforcing some integrity constraints in SQL databases and at the same time points to the need of good code generators. We implemented a multiplicity constraint [Parent]-----m..-[Child] (m>0) in a PostgreSQL™ 8.3 database. In PostgreSQL™ 8.3 it was not possible to implement the integrity constraint by using declarative means. We had to implement the constraint by using unstandardized constraint triggers, the execution of which can be deferred to the end of the containing transaction. The number of physical lines of the implementation was 44 and the number of necessary statements was 3. The count of physical lines is influenced by the length of identifiers and the style of writing. We used the names Parent, and Child as the identifiers of base tables. We followed the rule that lines of the code cannot be longer than 60 symbols. E. A Comparison of CASE Systems in Terms of Model Transformation Functionality EC(M) values can be used to compare model transformation functionality of different CASE systems. Let us assume that there is a conceptual data model Ks. In addition, there is a set of CASE systems C that we want to compare. Let us also assume that we want to implement a database by using a DBMS s. In case of each CASE system from C, one has to perform the task: create DDL statements for creating the conceptual schema M of a database in s by using a series of transformations from Ks. Ks must have the same details in case of all the systems from C. In case of each resulting conceptual schema definition, one should calculate the value of EC(M). It would provide concrete numerical values for comparing CASE systems in terms how much information, which is specified in a conceptual data model, is taken into account while generating the specification of a conceptual schema. Ks should be rich in detail (to contain as much as possible different types of elements) in this investigation. Next, we describe the results of a small experiment for comparing CASE systems in terms of their transformation functionality. Firstly, we selected two CASE systems that allow their users to create a conceptual data model and to generate a set of SQL statements from the conceptual data model by using a sequence of transformations. We selected IBM Rational Rose Enterprise Edition 7 [26] and DB-MAIN 9.1 [4]. We created a conceptual data model (see Fig 2) with the same precision by using both CASE systems. The model specifies entity types (without attributes), relationship types, and multiplicity constraints. We stress the importance of multiplicity constraints because they are widely used in

various conceptual data models [27] and are also presented in the taxonomy of integrity constraints [2]. In case of both CASE systems, we automatically generated SQL statements (in standard SQL) for implementing the conceptual schema. We did not manually specify the code for implementing the integrity constraints during the transformation. The information about integrity constraints was specified in the conceptual data models and we assumed that the system should take this information into account during transformations. Next, we calculated EC(M) values based on the conceptual data model and generated SQL statements based on the metamodels specified in [24, 25]. In case of Rational Rose 7 EC(M)=0.79 (x=33 – 8 entity types; 8 relationship types, 16 multiplicity elements; z=26). In case of DB-MAIN 9.1 EC(M)=0.88 (x=33; z=29). The reason why EC(M) is not 1 is that Rational Rose did not generate any code for enforcing the multiplicity constraints 10, 3000, 100000, 1..*, 3...*, and 5..15. DB-MAIN generated code for enforcing the constraint 1..* in case of all these multiplicity constraints. One could claim that the proposed measures for evaluating validity and completeness are not very interesting because high validity and completeness can be ensured by rigorously following transformation rules. However, the results of the experiment demonstrate that some current CASE systems have still problems in transforming even the very common integrity constraints and hence the proposed measures are useful and necessary.

REFERENCES [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13]

III. CONCLUSIONS In this paper, we proposed a framework for evaluating the quality of a part of the implementation of a database – a conceptual schema. The framework is based on semiotics – the theory of signs. We developed the framework by adapting an existing semiotic framework that is used to investigate the quality of different kinds of software entities. Existing means to evaluate the quality of conceptual schemas (like the use of normalization theory) fit with the proposed framework. We evaluated a SQL database schema as an example. We extended the set of software entities that can be studied by using the semiotic framework and it is also one of the results of our study. We proposed two candidate measures for evaluating the perceived semantic quality of conceptual schemas. We also explained how one could use the measure of perceived completeness to compare different CASE systems in terms of their model transformation functionality. The advantage of using the measure in this context is that it gives us concrete numerical results. We performed a small experiment, the results of which demonstrate that some existing CASE systems should be improved to facilitate the generation of code that implements integrity constraints. The future work must include further empirical evaluation of proposed measures in case of different conceptual data models and conceptual schemas. The future work should also include extending the framework to take into account the quality of the process of creating conceptual schemas.

[14] [15] [16] [17] [18] [19] [20]

[21] [22] [23] [24] [25] [26] [27]

T.J. Teorey, D. Yang, and J.P. Fry, “A logical design methodology for relational databases using the extended entity-relationship model,” ACM Computing Surveys, vol. 18, issue 2, pp. 197-222, 1986. E. Miliauskaité and L. Nemuraité, “Representation of integrity constraints in conceptual models,” Information Technology and Control, vol. 34, issue 4, pp. 355-365, 2005. D.L. Moody, “Theoretical and practical issues in evaluating the quality of conceptual models: current state and future directions,” Data & Knowledge Engineering, vol. 55, issue 3, pp. 243-276, 2005. J.-L. Hainaut, “The Transformational Approach to Database Engineering,” in GTTSE 2005, 2006, LNCS 4143, pp. 95-143. C.J. Date, An Introduction to Database Systems, 8th ed.. Boston: Pearson/Addison Wesley, 2003. A.L. Baroni, C. Calero, M. Piattini, and F.B. Abreu, “A Formal Definition for Object-Relational Database Metrics,” in 7th International Conference on Enterprise Information Systems, 2005. T. Connolly and C. Begg, Database Systems. A Practical Approach to Design, Implementation, and Management, 3rd ed.. Pearson/Addison Wesley, 2002. E. Marcos, B. Vela, J.M. Cavero, “A Methodological Approach for Object-Relational Database Design using UML,” Software and Systems Modeling, vol. 2, no. 1, pp. 59-72, 2003. M. Blaha, “A retrospective on industrial database reverse engineering projects – part 2,” in Eighth Working Conference on Reverse Engineering, 2001, pp. 147-153. A. Cleve, J. Lemaitre, J.-L. Hainaut, C. Mouchet, and J. Henrard, “The Role of Implicit Schema Constructs in Data Quality,” in QDB/MUD, 2008, pp. 33-40. P. Bellström and L. Jakobsson, “Analyzing and Defining Active Database Rules on a Conceptual Level,” in Eighth International Baltic Conference on Databases and Information Systems, 2008, pp. 361-372. J. Cabot and E. Teniente, “Constraint Support in MDA Tools: A Survey,” In ECMDA-FA 2006, 2006, LNCS 4066, pp. 256-267. C. Türker and M. Gertz, “Semantic integrity support in SQL:1999 and commercial (object-) relational database management systems,” The VLDB Journal, Dec. 2001, vol. 10, issue 4, pp. 241-269, 2001. O.I. Lindland, G. Sindre, and A. Solvberg, “Understanding quality in conceptual modeling,” IEEE Software, vol. 11, no. 2, pp. 42-49, March/April 1994. J. Krogstie, G. Sindre, and H. Jorgensen, “Process models representing knowledge for action: a revised quality framework,” European Journal of Information Systems, vol. 15, no. 1, pp. 91-102, 2006. Merriam-Webster, Inc., “Merriam-webster’s online dictionary,” [Online document] [2009 September 04], Available at http://www.m-w.com/ J. Melton, IWD 9075-1:200x(E) Information technology — Database languages — SQL — Part 1: Framework (SQL/Framework). February, 2006. J. Greenfield, K. Short, S. Cook, and S. Kent, Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley Publishing, 2004. MetaObjectFacility(MOF) Specification. Version 1.4.1. formal/05-0505. O. Vasilecas, D. Bugaite, and S. Sosunovas, “Templates-Based Approach for Rules Transformations into SQL Triggers,” in Eighth International Baltic Conference on Databases and Information Systems, 2008, pp. 253-263. “PostgreSQL 8.3 Documentation,” [Online document] [2009 August 09], Available at http://www.postgresql.org/docs/ G. Simsion, Data Modeling. Theory and Practice. Technics Publication, LLC, 2007. TPC BENCHMARK™ C Standard Specification Revision 5.10.1, 2009. Object Management Group, Unified Modeling Language: Superstructure, version 2.1.1, formal/2007-02-03. February 2007. Object Management Group, Common Warehouse Metamodel Specification, version 1.1, formal/03-03-02. March 2003. “Rational Rose Data Modeler,” [Online document] [2010 August 08], Available at http://www-01.ibm.com/software/awdtools/developer/ datamodeler/ L. Silverston, A Library of Universal Data Models for All Enterprises, Vol.1. Wiley Computer Publishing, 2001.