Transformation Of Knowledge, Information And Data: Theory And Applications

Hershey • London • Melbourne • Singapore

��

��

��

��

��

Patrick van BommelUniversity of Nijmegen, The Netherlands

Acquisition Editor: Mehdi Khosrow-PourSenior Managing Editor: Jan TraversManaging Editor: Amanda AppicelloDevelopment Editor: Michele RossiCopy Editor: Alana BubnisTypesetter: Jennifer WetzelCover Design: Mindy GrubbPrinted at: Yurchak Printing Inc.

Published in the United States of America byInformation Science Publishing (an imprint of Idea Group Inc.)701 E. Chocolate Avenue, Suite 200Hershey PA 17033Tel: 717-533-8845Fax: 717-533-8661E-mail: [email protected] site: http://www.idea-group.com

and in the United Kingdom byInformation Science Publishing (an imprint of Idea Group Inc.)3 Henrietta StreetCovent GardenLondon WC2E 8LUTel: 44 20 7240 0856Fax: 44 20 7379 3313Web site: http://www.eurospan.co.uk

Copyright © 2005 by Idea Group Inc. All rights reserved. No part of this book may bereproduced in any form or by any means, electronic or mechanical, including photocopying,without written permission from the publisher.

Library of Congress Cataloging-in-Publication Data

Transformation of knowledge, information and data : theory and applications / Patrick vanBommel, editor.

p. cm.

Includes bibliographical references and index.

ISBN 1-59140-527-0 (h/c) — ISBN 1-59140-528-9 (s/c) — ISBN 1-59140-529-7 (eisbn)

1. Database management. 2. Transformations (Mathematics) I. Bommel, Patrick van, 1964-

QA76.9.D3T693 2004

005.74—dc22 2004017926

British Cataloguing in Publication DataA Cataloguing in Publication record for this book is available from the British Library.

All work contributed to this book is new, previously-unpublished material. The views expressedin this book are those of the authors, but not necessarily of the publisher.

Preface ............................................................................................................. vi

Section I: Fundamentals of Transformations

Chapter ITransformation-Based Database Engineering ........................................... 1

Jean-Luc Hainaut, University of Namur, Belgium

Chapter IIRule-Based Transformation of Graphs and the Product Type ..............29

Renate Klempien-Hinrichs, University of Bremen, GermanyHans-Jörg Kreowski, University of Bremen, GermanySabine Kuske, University of Bremen, Germany

Chapter IIIFrom Conceptual Database Schemas to Logical Database Tuning ...... 52

Jean-Marc Petit, Université Clermont-Ferrand 2, FranceMohand-Saïd Hacid, Université Lyon 1, France

��

��

��

��

Chapter IVTransformation Based XML Query Optimization ...................................75

Dunren Che, Southern Illinois University, USA

Chapter VSpecifying Coherent Refactoring of Software Artefacts withDistributed Graph Transformations ...........................................................95

Paolo Bottoni, University of Rome “La Sapienza”, ItalyFrancesco Parisi-Presicce, University of Rome “La Sapienza”, Italy and George Mason University, USAGabriele Taentzer, Technical University of Berlin, Germany

Section II: Elaboration of Transformation Approaches

Chapter VIDeclarative Transformation for Object-Oriented Models .................. 127

Keith Duddy, CRC for Enterprise Distributed Systems Technology (DSTC), Queensland, AustraliaAnna Gerber, CRC for Enterprise Distributed Systems Technology (DSTC), Queensland, AustraliaMichael Lawley, CRC for Enterprise Distributed Systems Technology (DSTC), Queensland, AustraliaKerry Raymond, CRC for Enterprise Distributed Systems Technology (DSTC), Queensland, AustraliaJim Steel, CRC for Enterprise Distributed Systems Technology (DSTC), Queensland, Australia

Chapter VIIFrom Conceptual Models to Data Models ............................................ 148

Antonio Badia, University of Louisville, USA

Chapter VIIIAn Algorithm for Transforming XML Documents Schema intoRelational Database Schema .................................................................... 171

Abad Shah, University of Engineering & Technology (UET), PakistanJacob Adeniyi, King Saud University, Saudi ArabiaTariq Al Tuwairqi, King Saud University, Saudi Arabia

Chapter IXImprecise and Uncertain Engineering Information Modeling inDatabases: Models and Formal Transformations ................................ 190

Z. M. Ma, Université de Sherbrooke, Canada

Section III: Additional Topics

Chapter XAnalysing Transformations in Performance Management .................. 217

Bernd Wondergem, LogicaCMG Consulting, The NetherlandsNorbert Vincent, LogicaCMG Consulting, The Netherlands

Chapter XIMultimedia Conversion with the Focus on Continuous Media ......... 235

Maciej Suchomski, Friedrich-Alexander University of Erlangen-Nuremberg, GermanyAndreas Märcz, Dresden, GermanyKlaus Meyer-Wegener, Friedrich-Alexander University of Erlangen-Nuremberg, Germany

Chapter XIICoherence in Data Schema Transformations: The Notion of SemanticChange Patterns ........................................................................................ 257

Lex Wedemeijer, ABP Pensioenen, The Netherlands

Chapter XIIIModel Transformations in Designing the ASSO Methodology ......... 283

Elvira Locuratolo, ISTI, Italy

About the Authors ..................................................................................... 303

Index ............................................................................................................ 311

��

vi

Background

Data today is in motion, going from one location to another. It is more and moremoving between systems, system components, persons, departments, and orga-nizations. This is essential, as it indicates that data is actually used, rather thanjust stored. In order to emphasize the actual use of data, we may also speak ofinformation or knowledge.

When data is in motion, there is not only a change of place or position. Otheraspects are changing as well. Consider the following examples:

• The data format may change when it is transferred between systems.This includes changes in data structure, data model, data schema, datatypes, etc.

• Also, the interpretation of data may vary when it is passed on from oneperson to another. Changes in interpretation are part of data semanticsrather than data structure.

• The level of detail may change in the exchange of data between depart-ments or organizations, e.g., going from co-workers to managers or fromlocal authorities to the central government. In this context, we often seechanges in level of detail by the application of abstraction, aggregation,generalization, and specialization.

• Moreover, the systems development phase of data models may vary.This is particularly the case when implementation-independent data mod-els are mapped to implementation-oriented models (e.g., semantic datamodels are mapped to operational database specifications).

These examples illustrate just a few possibilities of changes in data. Numerousother applications exist and everybody uses them all the time. Most applicationsare of vital importance for the intelligent functioning of systems, persons, de-partments, and organizations.

vii

In this book, the fundamental treatment of moving knowledge, information, ordata, with changing format, interpretation, level of detail, development phase,etc., is based on the concept of transformation. The generally accepted termsconversion, mutation, modification, evolution, or revision may be used inspecific contexts, but the central concept is transformation.

Note that this definition covers well-known topics such as rewriting andversioning, and that it is relevant for collaborative information systems and datawarehouses. Although data transformation is typically applied in a networkedcontext (e.g., Internet or intranet), it is applied in other contexts as well.

Framework

Transformation techniques received a lot of attention in academic as well as inindustrial settings. Most of these techniques have one or more of the followingproblems:

• Loss of data: the result of the transformation does not adequately de-scribe the original data.

• Incomprehensibility: the effect of the transformation is not clear.

• Focus on instances: data instances are transformed, without incorpora-tion of data types.

• Focus on types: data types are transformed, without incorporation ofdata instances.

• Correctness: the transformation has no provable correctness.

We therefore aim at generic approaches for the treatment of data transforma-tions. Some of the questions we deal with are the following: What is an ad-equate data transformation technique? What are the requirements for the inputand output of those techniques? What are the problems in existing approaches?What are the possibilities of a generic approach in important areas such as thesemantic web, supply chain management, the global information community,and information security?

The theory and applications in this book are rooted in database schema trans-formation, as well as in database contents transformation. This allows for othertransformations, including transformation of document type definitions (DTDs)and of concrete documents. It is obvious that graph transformations are rel-evant here. Note that we do not particularly focus on specific kinds of data ordocuments (e.g., RDBMS, HTML or XML), although the models under consid-eration do not exclude such a focus.

viii

From Source to Target

Here we discuss general aspects of the move from source to target. They dealwith the basic assumptions underlying all transformation processes.

• Source. This is the structure to be transformed, or in other words, it is theinput to the transformation process. An important distinction is made be-tween formal and informal sources. If the source is informal, the transfor-mation process cannot be fully automated. We usually then have a partlyautomated transformation aiming at support, with sufficient possibilitiesfor interaction. As an example, a modeling process often is the mapping ofan informal view to a formal model. In this book, the input and output ofmost transformations are assumed to be available in some formal lan-guage.

• Target. This is the resulting structure, so it is the output of the transforma-tion process. A main question here is how the relation between the targetand the source is defined. Even when the transformation process hasbeen completed, it is important that the relation of the target with thesource remains clear. One way of establishing such a clear relation, is tohave the target defined in terms of the source. This is also helpful inproviding correctness proofs.

• Applicability. In some cases, transformations are not really general in thesense that the possible source and target are rather restricted. If, for ex-ample, a theoretical model of transformations only allows for exotic tar-gets, not being used in practical situations, the theoretical model suffersfrom applicability problems.

• Structure vs. access operations. Besides the transformation of struc-tures, we must provide mechanisms for the transformation of access op-erations. These operations may be modification operations as well as re-trieval operations. Consequently, we have a source structure with corre-sponding access operations, and a target structure with equivalent opera-tions. This situation is shown in Figure 1. The transformation kernel con-tains all metadata relevant for the transformation.

Correctness

Evidently, the correctness of transformations is of vital importance. What pur-pose would transformations have, if the nature of the result is uncertain? Ageneral setup for guaranteeing transformation correctness consists of threesteps.

ix

• Wellformedness conditions. First, we describe the required properties ofthe target explicitly. We prefer to have basic (independent) wellformednessconditions here, as this facilitates the systematic treatment in the nextsteps.

• Transformation algorithm. Next, we describe the construction of thetarget on the basis of the source at hand. This construction process isdefined in the transformation algorithm, which may be enhanced usingguidance parameters. Guidance is interpreted as the development towardstarget structures having certain desirable qualities.

• Correctness proof. Finally, we prove that the result of the algorithm sat-isfies the wellformedness conditions. As a consequence, the resulting struc-ture is correct in the sense that all wellformedness conditions are satis-fied. Moreover, when specific guidance parameters are used, we have toprove that the resulting structure not only satisfies all wellformedness con-ditions, but has the desirable qualities (indicated by guidance parameters)as well.

Sequences of Transformations

Transformations may be composed or applied in sequences. Such sequencessometimes consist of a relatively small number of steps. In more complex prob-lem areas, however, this is no longer possible. Then, transformation sequenceswill be longer and due to the various options in each transformation step, theoutcome of the overall sequence is not a priori known. This is particularly thecase when non-deterministic (e.g., random or probabilistic) transformation pro-cesses are considered.

Figure 1. Framework for transformation of structures and operations

transformation kernel

target structure source

structure

source operations

target operations

structure transformation

operation transformation

x

Although the outcome is not a priori known, it is often desirable to predict thenature of the result. One way of predicting the behavior of probabilistic trans-formation processes, is through the use of Markov theory. Here the probabili-ties of a single transformation step are summarized in a transition matrix, suchthat transformation sequences can be considered by matrix multiplication.

We will illustrate the definition of a single-step matrix for two basic cases. Inthe first case, consider a transformation in a solution space S where each inputx∈S has as possible output some y∈N(x), where N(x)⊆S and x∉N(x). So eachneighbor y∈N(x) can be produced from x by the application of some transfor-mation rule. Then the probability P(x,y) for the transformation of x into somey∈N(x) has the following property:

P(x,y) × |N(x)| = 1 (1)

Evidently for y∉N(x) we have P(x,y)=0. With this property it is guaranteed thatP(x,y) is a stochastic matrix, since 0 ≤ P(x,y) ≤ 1 and Σ

y∈S P(x,y) = 1. Note that

in the above transformation the production of all results is equally likely.

In the second case, we consider situations where the production of all results isnot equally likely. Consider a transformation in a solution space S where eachinput x∈S has as possible output some y∈B(x), where B(x)⊆N(x) contains allbetter neighbors of x. Then the probability P(x,y) for the transformation of xinto some y∈B(x) is given by the above mentioned formula (1). However, as aresult of accepting only improving transformations, this formula now does notguarantee P(x,y) to be a stochastic matrix. The consequence of rejecting allneighbours in N(x)-B(x) is, that a transformation may fail. So now we have toconsider P(x,x). This probability has the following property:

P(x,x) × |N(x)| = |N(x)| - |B(x)| (2)

In this case we have P(x,y)=0 for y ∉ {x}∪B(x). Now we have described ahill climbing transformation sequence. Note that the matrix underlying hillclimbing transformations is a stochastic matrix indeed.

We will now give an overview of the book. It consists of three parts: fundamen-tals of transformations, elaboration of transformation approaches, and addi-tional topics. These three sections contain 13 chapters. It is possible to start ina later chapter (e.g., in Section II or III), without reading all earlier chapters(e.g., more theoretical chapters in Section I).

xi

Fundamentals of Transformations

Section I is about fundamentals and consists of five chapters. The focus ofChapter I is databases: Transformation-Based Database Engineering. Herewe consider the basic theory of the transformation of data schemata, wherereversibility of transformations is also considered. We describe the use of basictransformations in the construction of more complex (higher-level) transforma-tions. Several possibilities are recognized here, including compound transfor-mations, and predicate-driven and model-driven transformations. Basic trans-formations and their higher-level derivations are embedded within database (for-ward) design processes as well as within database reverse design processes.

Most models to be transformed are defined in terms of graphs. In Chapter IIwe will therefore focus on graph transformations: Rule-Based Transforma-tion of Graphs and the Product Type. Graph transformations are based onrules. These rules yield new graphs, produced from a given graph. In this ap-proach, conditions are used to have more control over the transformation pro-cess. This allows us to indicate the order of rule application. Moreover, theresult (product) of the transformation is given special attention. In particular,the type of the product is important. This sets the context for defining the pre-cise relation between two or more graph transformations.

Having embedded our transformations within the graph transformation context,Chapter III proceeds with graphs for concrete cases: From Conceptual Data-base Schemas to Logical Database Tuning. Here we present several algo-rithms, aiming at the production of directed graphs. In databases we have sev-eral aims in transformations, including efficiency and freedom from null values.Note that wellformedness of the input (i.e., a conceptual model) as well aswellformedness of the output (i.e., the database) is addressed.

It is evident that graphs have to be transformed, but what about operations ongraphs? In systems design this corresponds with query transformation and op-timization. We apply this to markup languages in Chapter IV: TransformationBased XML Query Optimization. After representing document type defini-tions in terms of a graph, we consider paths in the graph and an algebra for textsearch. Equivalent algebraic expressions set the context for optimization, as weknow from database theory. Here we combine the concepts from previous chap-ters, using rule-based transformations. However, the aim of the transformationprocess now is optimization.

In Chapter V, the final chapter of Section I, we consider a highly specializedfundament in the theory behind applications: Specifying Coherent Refactoringof Software Artefacts with Distributed Graph Transformations. Modifica-tions in the structure of systems are recorded in terms of so-called “refactoring”.This means that a coordinated evolution of system components becomes pos-

xii

sible. Again, this graph transformation is rule-based. We use this approach toreason about the behavior of the system under consideration.

Elaboration ofTransformation Approaches

In Section II, we consider elaborated approaches to transformation. The focusof Chapter VI is object-oriented transformation: Declarative Transformationfor Object-Oriented Models. This is relevant not only for object-oriented datamodels, but for object-oriented programming languages as well. The transfor-mations under consideration are organized according to three styles of trans-formation: source-driven, target-driven, and aspect-driven transformations. Al-though source and target will be clear, the term “aspect” needs some clarifica-tion. In aspect-driven transformations, we use semantic concepts for setting upthe transformation rule. A concrete SQL-like syntax is used, based on rule —forall — where — make — linking statements. This also allows for the defini-tion of patterns.

It is generally recognized that in systems analysis we should use conceptualmodels, rather than implementation models. This creates the context for trans-formations of conceptual models. In Chapter VII we deal with this: From Con-ceptual Models to Data Models. Conceptual models are often expressed interms of the Entity-Relationship approach, whereas implementation models areoften expressed in terms of the relational model. Classical conceptual modeltransformations thus describe the mapping from ER to relational models. Hav-ing UML in the conceptual area and XML in the implementation area, we nowalso focus on UML to XML transformations.

We proceed with this in the next chapter: An Algorithm for TransformingXML Documents Schema into Relational Database Schema. A typical ap-proach to the generation of a relational schema from a document definition,starts with preprocessing the document definition and finding the root node ofthe document. After generating trees and a corresponding relational schema,we should determine functional dependencies and other integrity constraints.During postprocessing, the resulting schema may be normalized in case this isdesirable. Note that the performance (efficiency) of such algorithms is a criti-cal factor. The proposed approach is illustrated in a case study based on librarydocuments.

Transformations are often quite complex. If data is inaccurate, we have a fur-ther complication. In Chapter IX we deal with this: Imprecise and UncertainEngineering Information Modeling in Databases: Models and FormalTransformations. Uncertainty in information modeling is usually based on fuzzy

xiii

sets and probability theory. Here we focus on transformations in the context offuzzy Entity-Relationship models and fuzzy nested relations. In the models usedin this transformation, the known graphical representation is extended with fuzzyelements, such as fuzzy type symbols.

Additional Topics

In Section III, we consider additional topics. The focus of Chapter X is theapplication of transformations in a new area: Analysing Transformations inPerformance Management. The context of these transformations is an orga-nizational model, along with a goal model. This results in a view of organiza-tional management based on cycles of transformations. Typically, we have trans-formations of organizational models and goal models, as well as transforma-tions of the relationship between these models. Basic transformations are theaddition of items and detailing of components.

Next we proceed with the discussion of different media: Multimedia Conver-sion with the Focus on Continuous Media. It is evident that the major chal-lenge in multimedia research is the systematic treatment of continuous media.When focusing on transformations, we enter the area of streams and convert-ers. As in previous chapters, we again base ourselves on graphs here, for in-stance chains of converters, yielding a graph of converters. Several qualitiesare relevant here, such as quality of service, quality of data, and quality ofexperience. This chapter introduces specific transformations for media-typechangers, format changers, and content changers.

The focus of Chapter XII is patterns in schema changes: Coherence in DataSchema Transformations: The Notion of Semantic Change Patterns. Herewe consider updates of data schemata during system usage (operationalschema). When the schema is transformed into a new schema, we try to findcoherence. A catalogue of semantic changes is presented, consisting of a num-ber of basic transformations. Several important distinctions are made, for ex-ample, between appending an entity and superimposing an entity. Also, we havethe redirection of a reference to an owner entity, along with extension andrestriction of entity intent. The basic transformations were found during empiri-cal studies in real-life cases.

In Chapter XIII, we conclude with the advanced approach: Model Transfor-mations in Designing the ASSO Methodology. The context of this methodol-ogy is ease of specifying schemata and schema evolution during system usage.The transformations considered here particularly deal with subtyping (also calledis-a relationships). This is covered by the transformation of class hierarchies ormore general class graphs. It is evident that schema consistency is one of theproperties required. This is based on consistency of class definitions, with in-

ductive approaches by: (a) requiring that initialization adheres to applicationconstraints, and (b) all operations preserve all constraints.

Conclusions

This book contains theory and applications of transformations in the context ofinformation systems development. As data today is frequently moving betweensystems, system components, persons, departments, and organizations, the needfor such transformations is evident.

When data is in motion, there is not only a change of place or position. Otheraspects are changing as well. The data format may change when it is trans-ferred between systems, while the interpretation of data may vary when it ispassed on from one person to another. Moreover, the level of detail may changein the exchange of data between departments or organizations, and the systemsdevelopment phase of data models may vary, e.g., when implementation-inde-pendent data models are mapped to implementation-oriented models.

The theory presented in this book will help in the development of new innova-tive applications. Existing applications presented in this book prove the powerof current transformation approaches. We are confident that this book contrib-utes to the understanding, the systematic treatment and refinement, and theeducation of new and existing transformations.

Further Reading

Kovacs, Gy. & van Bommel, P. (1997). From conceptual model to OO data-base via intermediate specification. Acta Cybernetica, (13), 103-140.

Kovacs, Gy. & van Bommel, P. (1998). Conceptual modelling based design ofobject-oriented databases. Information and Software Technology, 40(1), 1-14.

van Bommel, P. (1993, May). A randomised schema mutator for evolutionarydatabase optimisation. The Australian Computer Journal, 25(2), 61-69.

van Bommel, P. (1994). Experiences with EDO: An evolutionary databaseoptimizer. Data & Knowledge Engineering, 13, 243-263.

van Bommel, P. (1995, July). Database design by computer aided schema trans-formations. Software Engineering Journal, 10(4), 125-132.

van Bommel, P., Kovacs, Gy. & Micsik, A. (1994). Transformation of databasepopulations and operations from the conceptual to the Internal level. In-formation Systems, 19(2), 175-191.

xiv

van Bommel, P., Lucasius, C.B. & Weide, Th.P. van der (1994). Genetic algo-rithms for optimal logical database design. Information and SoftwareTechnology, 36(12), 725-732.

van Bommel, P. & Weide, Th.P. van der (1992). Reducing the search space forconceptual schema transformation. Data & Knowledge Engineering, 8,269-292.

Acknowledgments

The editor gratefully acknowledges the help of all involved in the production ofthis book. Without their support, this project could not have been satisfactorilycompleted. A further special note of thanks goes also to all the staff at IdeaGroup Publishing, whose contributions throughout the whole process from in-ception of the initial idea to final publication have been invaluable.

Deep appreciation and gratitude is due to Theo van der Weide and other mem-bers of the Department of Information Systems at the University of Nijmegen,The Netherlands, for the discussions about transformations of information models.Most of the authors of chapters included in this book also served as reviewersfor chapters written by other authors. Thanks go to all those who providedconstructive and comprehensive reviews. Special thanks also go to the publish-ing team at Idea Group Publishing, in particular to Michele Rossi, CarrieSkovrinskie, Jan Travers, and Mehdi Khosrow-Pour.

In closing, I wish to thank all of the authors for their insights and excellentcontributions to this book.

Patrick van Bommel, PhDNijmegen, The NetherlandsFebruary [email protected]://www.cs.kun.nl/~pvb

xv

Section I

Fundamentals ofTransformations

Transformation-Based Database Engineering 1

Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without writtenpermission of Idea Group Inc. is prohibited.

Chapter I

Transformation-BasedDatabase Engineering

Jean-Luc Hainaut, University of Namur, Belgium

Abstract

In this chapter, we develop a transformational framework in which manydatabase engineering processes can be modeled in a precise way, and inwhich properties such as semantics preservation and propagation can bestudied rigorously. Indeed, the transformational paradigm is particularlysuited to database schema manipulation and translation, that are the basisof such processes as schema normalization and optimization, modeltranslation, reverse engineering, database integration and federation ordatabase migration. The presentation first develops a theoretical frameworkbased on a rich, wide spectrum specification model. Then, it describes howmore complex transformations can be built through predicate-based filteringand composition. Finally, it analyzes two major engineering activities,namely database design and reverse engineering, modeled as goal-orientedschema transformations.

2 Hainaut


Motivation and Introduction

Modeling software design as the systematic transformation of formal specifica-tions into efficient programs, and building CASE1 tools that support it, has longbeen considered one of the ultimate goals of software engineering. For instance,Balzer (1981) and Fikas (1985) consider that the process of developing aprogram [can be] formalized as a set of correctness-preserving transfor-mations [...] aimed to compilable and efficient program production. In thiscontext, according to Partsch (1983),

“a transformation is a relation between two program schemes Pand P’ (a program scheme is the [parameterized] representationof a class of related programs; a program of this class is obtainedby instantiating the scheme parameters). It is said to be correct ifa certain semantic relation holds between P and P’.”

These definitions still hold for database schemas, which are special kinds ofabstract program schemes. The concept of transformation is particularly attrac-tive in this realm, though it has not often been made explicit (for instance, as auser tool) in current CASE tools. A (schema) transformation is most generallyconsidered to be an operator by which a data structure S1 (possibly empty) isreplaced by another structure S2 (possibly empty) which may have some sort ofequivalence with S1. Some transformations change the information contents ofthe source schema, particularly in schema building (adding an entity type or anattribute) and in schema evolution (removing a constraint or extending arelationship type). Others preserve it and will be called semantics-preserving orreversible. Among them, we will find those which just change the nature of aschema object, such as transforming an entity type into a relationship type orextracting a set of attributes as an independent entity type.

Transformations that are proved to preserve the correctness of the originalspecifications have been proposed in practically all the activities related toschema engineering: schema normalization (Rauh, 1995), DBMS2 schematranslation (Hainaut, 1993b; Rosenthal, 1988), schema integration (Batini, 1992;McBrien, 2003), schema equivalence (D’Atri, 1984; Jajodia, 1983; Kobayashi,1986; Lien, 1982), data conversion (Navathe, 1980; Estiévenart, 2003), reverseengineering (Bolois, 1994; Casanova, 1984; Hainaut, 1993, 1993b), schemaoptimization (Hainaut, 1993b; Halpin, 1995) database interoperability (McBrien,2003; Thiran, 2001) and others. The reader will find in Hainaut (1995) anillustration of numerous application domains of schema transformations.

The goal of this chapter is to develop and illustrate a general framework fordatabase transformations in which all the processes mentioned above can be



formalized and analyzed in a uniform way. We present a wide spectrumformalism in which all the information/data models currently used can bespecified, and on which a set of basic transformational operators is defined. Wealso study the important property of semantics-preservation of these operators.Next, we explain how higher-level transformations can be built through threemechanisms, from mere composition to complex model-driven transformation.The database design process is revisited and given a transformational interpre-tation. The same exercise is carried out in the next section for database reverseengineering then we conclude the chapter.

Schema Transformation Basics

This section describes a general transformational theory that will be used as thebasis for modeling database engineering processes. First, we discuss somepreliminary issues concerning the way such theories can be developed. Then, wedefine a wide-spectrum model from which operational models (i.e., those whichare of interest for practitioners) can be derived. The next sections are dedicatedto the concept of transformation, to its semantics-preservation property, and tothe means to prove it. Finally, some important basic transformations aredescribed.

• Warning. In the database world, a general formalism in which databasespecifications can be built is called a model. The specification of a databaseexpressed in such a model is called a schema.

Developing Transformational Theories

Developing a general purpose transformational theory requires deciding on thespecification formalism, i.e., the model, in which the schemas are expressed andon the set of transformational operators. A schema can be defined as a set ofconstructs (entity types, attributes, keys, indexes, etc.) borrowed from a definitemodel whose role is to state which constructs can be used, according to whichassembly rules, in order to build valid schemas. For simplicity, the concept ofentity type is called a construct of the ERA3 model, while entity type CUS-TOMER is a construct of a specific schema. They are given the same name,though the latter is an instance of the former.

Though some dedicated theories rely on a couple of models, such as those whichare intended to produce relational schemas from ERA schemas, the mostinteresting theories are based on a single formalism. Such a formalism defines

4 Hainaut


the reference model on which the operators are built. According to its generalityand its abstraction level, this model defines the scope of the theory, that canaddress a more or less wide spectrum of processes. For instance, building atheory on the relational model will allow us to describe, and to reason on, thetransformation of relational schemas into other relational schemas. The 1NF4

normalization theory is a popular example. Another example would be atransformational theory based on the ORM (Object-Role model) that wouldprovide techniques for transforming (normalizing, optimizing) conceptual schemasinto other schemas of the same abstraction level (de Troyer, 1993; Proper, 1998).The hard challenge is to choose a unique model that can address not only intra-model transformations, but inter-model operators, such as ORM-to-relationalconversion.

To identify such models, let us consider a set of models Γ that includes, amongothers, all the operational formalisms that are of interest for a community ofpractitioners, whatever the underlying paradigm, the age and the abstractionlevel of these formalisms. For instance, in a large company whose informationsystem relies on many databases (be they based on legacy or modern technolo-gies) that have been designed and maintained by several teams, this set is likelyto include several variants of the ERA model, UML class diagrams, severalrelational models (e.g., Oracle 5 to 10 and DB2 UDB), the object-relationalmodel, the IDMS and IMS models and of course the standard file structure modelon which many legacy applications have been developed.

Let us also consider the transitive inclusion relation “≤” such that M ≤ M’, whereM≠M’ and M,M’ ∈ Γ, means that all the constructs of M also appear in M’.5 Forinstance, if M denotes the standard relational model and M’ the object-relational model, then M ≤ M’ holds, since each schema expressed in M is a validschema according to model M’.

Now, we consider a model M* in Γ, such that:

∀M∈Γ, M≠M*: M ≤ M*,

and a model M0 in Γ, for which the following property holds:

∀M∈Γ, M≠M0: M0 ≤ M.

(ΓxΓ, ≤) forms a lattice of models, in which M0 denotes the bottom node and M*the upper node.

M0, admittedly non-empty, is made up of a very small set of elementary abstractconstructs, typically nodes, edges and labels. An ERA schema S comprising anentity type E with two attributes A1 and A2 would be represented in M0 by the



nodes n1, n2, n3 which are given the labels “E”, “A1” and “A2”, and by the edges(n1,n2) and (n1,n3).

On the contrary, M* will include a greater variety of constructs, each of thembeing a natural abstraction of one or several constructs of lower-level models.This model should include, among others, the concepts of object type, attributeand inter-object association, so that the contents of schema S will be representedin M* by an object type with name “E” comprising two attributes with names “A1”and “A2”.

Due to their high level of abstraction, models M0 and M* are good candidates todevelop a transformational theory relying on a single model. Considering thecontext-dependent definition of Γ, M0 and M*, we cannot assert that theseconcepts are unique. Therefore, there is no guarantee that a universal theory canbe built.

Approaches based on M0 generally define data structures as semantics-freebinary graphs on which a small set of rewriting operators are defined. Therepresentation of an operational model M such as ERA, relational or XML, in M0requires some additional features such as typed nodes (object, attribute, associa-tion and roles for instance) and edges, as well as ad hoc assembly rules thatdefine patterns. A transformation specific to M is also defined by a pattern, a sortof macro-transformation, defined by a chain of M0 transformations. McBrien(1998) is a typical example of such theories. We can call this approachconstructive or bottom-up, since we build operational models and transforma-tions by assembling elementary building blocks.

The approaches based on M* naturally require a larger set of rewriting rules. Anoperational model M is defined by specializing M*, that is, by selecting a subsetof concepts and by defining restrictive assembly rules. For instance, a relationalschema can be defined as a set of object types (tables), a set of attributes(column), each associated with an object type (at least one attribute per objecttype) and a set of uniqueness (keys) and inclusion (foreign keys) constraints.This model does not include the concept of association. The transformations ofM are those of M* which remain meaningful. This approach can be qualified byspecialization or top-down, since an operational model and its transformationaloperators are defined by specializing (i.e., selecting, renaming, restricting) M*constructs and operators. DB-MAIN (Hainaut, 1996b) is an example of thisapproach. In the next section, we describe the main aspects of its model, named GER.6

Data Structure Specification Model

Database engineering is concerned with building, converting and transformingdatabase schemas at different levels of abstraction, and according to various

6 Hainaut


paradigms. Some processes, such as normalization, integration and optimizationoperate in a single model, and will require intra-model transformations. Otherprocesses, such as logical design, use two models, namely the source and targetmodels. Finally, some processes, among others, reverse engineering and feder-ated database development, can operate on an arbitrary number of models (oron a hybrid model made up of the union of these models) as we will see later on.The GER model is a wide-spectrum formalism that has been designed to:

• express conceptual, logical and physical schemas, as well as their manipu-lation,

• support all the data-centered engineering processes, and

• support all DMS7 models and the production and manipulation of theirschemas.

The GER is an extended entity-relationship model that includes, among others,the concepts of schema, entity type, entity collection, domain, attribute, relation-ship type, keys, as well as various constraints. In this model, a schema is adescription of data structures. It is made up of specification constructs whichcan be, for convenience, classified into the usual three abstraction levels, namelyconceptual, logical and physical. We will enumerate some of the main constructsthat can appear at each level:

• A conceptual schema comprises entity types (with/without attributes;with/without identifiers), super/subtype hierarchies (single/multiple, totaland disjoint properties), relationship types (binary/N-ary; cyclic/acyclic;with/without attributes; with/without identifiers), roles of relationship type(with min-max cardinalities; with/without explicit name; single/multi-entity-type), attributes (of entity or relationship types; multi/single-valued; atomic/compound; with cardinality), identifiers (of entity type, relationship type,multivalued attribute; comprising attributes and/or roles), constraints (in-clusion, exclusion, coexistence, at-least-one, etc.)

• A logical schema comprises record types, fields, arrays, foreign keys,redundancy, etc.

• A physical schema comprises files, record types, fields, access keys (ageneric term for index, calc key, etc.), physical data types, bag and listmultivalued attributes, and other implementation details.

It is important to note that these levels are not part of the model. The schema ofFigure 1 illustrates some major concepts borrowed to these three levels. Such ahybrid schema could appear in reverse engineering.



One remarkable characteristic of wide spectrum models is that all the transfor-mations, including inter-model ones, appear as intra-model operators. This hashighly interesting consequences. First, a transformation Σ designed for manipu-lating schemas in an operational model M1 can be used in a model M2 as well,provided that M2 includes the constructs on which Σ operates. For instance, mosttransformations dedicated to COBOL data structure reverse engineering appearto be valid for relational schemas as well. This strongly reduces the number ofoperators. Secondly, any new model can profit from the techniques andreasoning that have been developed for current models. For instance, designingmethods for translating conceptual schemas into object-relational structures orinto XML schemas (Estiévenart, 2003), or reverse engineering OO-databases(Hainaut, 1997) have proved particularly easy since these new methods can be,to a large extent, derived from standard ones.

The GER model has been given a formal semantics in terms of an extended NF2model (Hainaut, 1989, 1996). This semantics will allow us to analyze theproperties of transformations, and particularly to precisely describe how, andunder which conditions, they propagate and preserve the information contents ofschemas.

Figure 1. Typical hybrid schema made up of conceptual constructs (e.g.,entity types PERSON, CUSTOMER, EMPLOYEE and ACCOUNT,relationship type of, identifiers Customer ID of CUSTOMER), logicalconstructs (e.g., record type ORDER, with various kinds of fields includingan array, foreign keys ORIGIN and DETAIL.REFERENCE) and physicalobjects (e.g., table PRODUCT with primary key PRO_CODE and indexesPRO_CODE and CATEGORY, table space PRODUCT.DAT) (Note that theidentifier of ACCOUNT, stating that the accounts of a customer havedistinct Account numbers, makes it a dependent or weak entity type.)

1-1

0-N

of

T

PERSONNameAddress

EMPLOYEE

Employe NbrDate Hired

id: Employe Nbr

ACCOUNT

Account NBRAmountid: of.CUSTOMER

Account NBR

CUSTOMERCustomer ID

id: Customer ID

ORDERORD-IDDATE_RECEIVEDORIGINDETAIL[1-5] array

REFERENCEQTY-ORD

id: ORD-IDref: ORIGINref: DETAIL[*].REFERENCE

PRODUCTPRO_CODECATEGORYDESCRIPTIONUNIT_PRICEid: PRO_CODE

acc acc: CATEGORY

PRODUCT.DAT

PRODUCT

8 Hainaut


Let us note that we have discarded the UML class model as a candidate for M*due to its intrinsic weaknesses, including its lack of agreed-upon semantics, itsnon-regularity and the absence of essential concepts. On the contrary, acarefully defined subset of the UML model could be be a realistic basis forconstructive approaches.

Specifying Operational Models with the GER

In this section, we illustrate the specialization mechanism by describing apopular operational formalism, namely the standard 1NF relational model. All theother models, be they conceptual, logical or physical can be specified similarly.

A relational schema mainly includes tables, domains, columns, primary keys,unique constraints, not null constraints and foreign keys. The relational model cantherefore be defined as in Figure 2. A GER schema made up of constructs fromthe first columns only, that satisfy the assembly rules, can be called relational.As a consequence, a relational schema cannot comprise is-a relations, relation-ship types, multivalued attributes or compound attributes.

The physical aspects of the relational data structures can be addressed as well.Figure 3 gives additional specifications through which physical schemas for aspecific RDBMS can be specified. These rules generally include limitations suchas no more than 64 columns per index, or the total length of the componentsof any index cannot exceed 255 characters.

Figure 2. Defining standard relational model as a subset of the GER model

GER constructs relational constructs assembly rules

schema database schema

entity type table an entity type includes at least one attribute

simple domain domain

single-valued and atomic attribute with cardinality [0-1]

nullable column

single-valued and atomic attribute with cardinality [1-1]

not null column

primary identifier primary key a primary identifier comprises attributes with cardinality [1-1]

secondary identifier unique constraint

reference group foreign key the composition of the reference group must be the same as that of the target identifier

GER names SQL names the GER names must follow the SQL syntax



Transformation: Definition

The definitions that will be stated here are model-independent. In particular, theyare valid for the GER model, so that the examples will be given in the latter. Letus denote by M the model in which the source and target schemas are expressedby S the schema on which the transformation is to be applied and by S’ the schemaresulting from this application. Let us also consider sch(M), a function that returnsthe set of all the valid schemas that can be expressed in model M, and inst(S), afunction that returns the set of all the instances that comply with schema S.

A transformation ΣΣΣΣΣ consists of two mappings T and t (Figure 4):

• T is the structural mapping from sch(M) onto itself, that replaces sourceconstruct C in schema S with construct C’. C’ is the target of C through T,and is noted C’ = T(C). In fact, C and C’ are classes of constructs that canbe defined by structural predicates. T is therefore defined by the minimalprecondition P that any construct C must satisfy in order to be transformedby T, and the maximal postcondition Q that T(C) satisfies. T specifies therewriting rule of Σ.

• t is the instance mapping from inst(S) onto inst(S’), that states how toproduce the T(C) instance that corresponds to any instance of C. If c is aninstance of C, then c’ = t(c) is the corresponding instance of T(C). t can bespecified through any algebraic, logical or procedural expression.

Figure 3. Defining the main technical constructs of relational datastructures as they are implemented in a specific RDBMS

GER constructs relational constructs assembly rules for a specific DBMS

access key index comprises from 1 to 64 attributes of the parent entity type

collection table space a collection includes 1 to 255 entity types; an entity type belongs to at most 1 collection

Figure 4. Two mappings of schema transformation Σ ≡ <T,t> (The inst_ofarrow from x to X indicates that x is an instance of X.)

C' = T(C)

c' = t(c)c

C T

t

inst_ofinst_of

10 Hainaut


According to the context, Σ will be noted either <T,t> or <P,Q,t>.

Each transformation Σ is associated with an inverse transformation Σ' which canundo the result of the former under certain conditions that will be detailed in thenext section.

Reversibility of a Transformation

The extent to which a transformation preserves the information contents of aschema is an essential issue. Some transformations appear to augment thesemantics of the source schema (e.g., adding an attribute), some removesemantics (e.g., removing an entity type), while others leave the semanticsunchanged (e.g., replacing a relationship type with an equivalent entity type).The latter are called reversible or semantics-preserving. If a transformationis reversible, then the source and the target schemas have the same descriptivepower, and describe the same universe of discourse, although with a differentpresentation.

• A transformation Σ1 = <T1,t1> = <P1,Q1,t1> is reversible, iff there existsa transformation Σ2 = <T2,t2> = <P2,Q2,t2> such that, for any construct C,and any instance c of C: P1(C) ⇒ ([T2(T1(C))=C] and [ t2(t1(c)=c]). Σ2 is theinverse of Σ1, but the converse is not true8. For instance, an arbitraryinstance c’ of T(C) may not satisfy the property c’=t1(t2(c’)).

• If Σ2 is reversible as well, then Σ1 and Σ2 are called symmetricallyreversible. In this case, Σ2 = <Q1,P1,t2>. Σ1 and Σ2 are called SR-transformations for short.

Similarly, in the pure software engineering domain, Balzer (1981) introduces theconcept of correctness-preserving transformation aimed at compilable andefficient program production.

We have discussed the concept of reversibility in a context in which some kindof instance equivalence is preserved. However, the notion of inverse transfor-mation is more general. Any transformation, be it semantics-preserving or not,can be given an inverse. For instance, del-ET(et_name), which removes entitytype with name et_name from its schema, clearly is not a semantics-preservingoperation, since its mapping t has no inverse. However, it has an inversetransformation, namely create-ET(CUSTOMER). Since only the T part is defined,this partial inverse is called a structural inverse transformation.



Proving the Reversibility of a Transformation

Thanks to the formal semantics of the GER, a proof system has been developedto evaluate the reversibility of a transformation. More precisely, this systemrelies on a limited set of NF2 transformational operators whose reversibility hasbeen proven, and that can generate a large number of GER transformations.Basically, the system includes five families of transformations, that can becombined to form more complex operators:

• denotation, through which a new object set is defined by a derivation rulebased on existing structures,

• project-join which is a variant of the decomposition theorem,

• composition which replaces two relations by one of them and theircomposition,

• nest-unnest, the typical 1NF ↔ N1NF operators, and

• container, that states the equivalence between non-set containers (e.g.,bags, lists, arrays) and sets .

Thanks to a complete set of mapping rules between the GER model and the NF2model in which these basic transformations have been built, the latter can beapplied to operational schemas. Figure 5 shows how we have defined adecomposition operator for normalizing relationship types from the basic project-join transformation. It is based on a three-step process:

1. Source schema (Figure 5, top-left) is expressed in the NF2 formalism(bottom-left):

{entities:A,B,C; R(A,B,C); A → B}

2. Basic project-join transformation is applied and yields a normalized rela-tional schema (bottom-right):

{entities:A,B,C; R1(A,B); R2(A,C); R1[A]=R2[A]}

3. NF2 schema is expressed in the GER, leading to the target schema (Figure5, top-right).

12 Hainaut


Since the the GER ↔ NF2 mappings are symmetrically reversible and theproject-join is an SR-transformation, the ERA transformation is symmetricallyreversible as well. It can be defined as follows:

T1 = T11οT12οT13

T1' = T11'οT12'οT13'

We note the important constraint R1[A]=R2[A] that gives the project-join transfor-mation the SR property, while Fagin’s theorem merely defines a reversibleoperator. We observe how this constraint translates into a coexistence constraintin the GER model that states that if an A entity is connected to a B entity, it mustbe connected to at least one C entity as well, and conversely.

The reader interested in a more detailed description of this proof system isrefered to Hainaut (1996).

Six Mutation Transformations

A mutation is an SR-transformation that changes the nature of an object.Considering the three main natures of object, namely entity type, relationshiptype and attribute, six mutation transformations can be defined. In Figure 6, thecouples of operators Σ1 to Σ3, show them applied on typical schema fragments.The transformations Σ4 are not primitive since they can be defined by combiningother mutations. However, they have been added due to their usefulness. More

Figure 5. Proving the SR property of the decomposition of a relationshiptype according to a multivalued dependency (here an FD)

source schema target schema

GER 0-N

0-N0-N

R

C

BA

R: A → B

T1 ⇒ ⇐ T1'

0-1 0-NR1

0-N

0-NR2 C

BA

coex: R2.C[*]R1.B

T11 ⇓⇑ T11' T13 ⇑ ⇓ T13'

NF2

entities: A,B,C R(A,B,C)

A → B

T12 ⇒ ⇐ T12'

entities:A,B,C R1(A,B)

R2(A,C)

R1[A]=R2[A]



sophisticated mutation operators can be defined as illustrated in Hainaut (1991)in the range of entity-generating transformations.

Other Basic Transformations

The mutation transformations can solve many database engineering problems,but other operators are needed to model special situations. The CASE toolassociated with the DB-MAIN methodologies includes a kit of about 30 basicoperators that have proven sufficient for most engineering activities. Whennecessary, user-defined operators can be developed through the meta functionsof the tool (Hainaut, 1996b). We will describe some of the basic operators.

Expressing supertype/subtype hierarchies in DMS that do not support themexplicitly is a recurrent problem. The technique of Figure 7 is one of the mostcommonly used (Hainaut, 1996c). It consists in representing each source entitytype by an independent entity type, then to link each subtype to its supertypethrough a one-to-one relationship type. The latter can, if needed, be furthertransformed into foreign keys by application of Σ2-direct (T2).

Figure 6. Six mutation transformations Σ1 to Σ3 (Though not primitive,compound transformations Σ4 are shown as well.)

source schema target schema comment

Σ1

0-50-N r BA

T1 ⇒ ⇐ T1' 1-1

0-5

rB1-1

0-N

rAR

id: rA.ArB.B

BA

Transforming relationship type r into entity type R (T1) and conversely (T1'). Note that R entities are identified by any couple (a,b) ∈ AxB through relationship types rA and rB (id:ra.A,rB.B).

Σ2 0-N 0-5r B

AA1

id: A1

T2 ⇒ ⇐ T2'

BA1[0-5]

ref: A1[*]

AA1

id: A1

Transforming relationship type r into reference attribute B.A1 (T2) and conversely (T2').

Σ3 A

A1A2[0-5]A3

T3 ⇒ ⇐ T3'

1-N0-5 ra2A

A1A3

EA2A2

id: A2

Transforming attribute A2 into entity type EA2 (T3) and conversely (T3').

Σ4

AA1A2[0-5]A3

T4 ⇒ ⇐ T4'

0-5 1-1ra2

EA2A2id: ra2.A

A2

A

A1A3

Not a primitive operator. T4 can be defined by application of T3 to EA2.A2, then of T1' to EA2 in the schema above. Note that the EA2 entities depending on the same A entity have distinct A2 values (id:ra2.A,A2).

14 Hainaut


Transformations Σ3 and Σ4 show how to process standard multivalued at-tributes. When the collection of values is no longer a set but a bag, a list or anarray, operators to transform them into pure set-oriented constructs are mostuseful. Transformations Σ6 in Figure 8 are dedicated to arrays. Similar operatorshave been defined for the other types of containers.

Attributes defined on the same domain and the name of which suggests a spatialor temporal dimension (e.g., departments, countries, years or pure numbers) arecalled serial attributes. In many situations, they can be interpreted as the

Figure 7. Transforming an is-a hierarchy into one-to-one relationshiptypes and conversely

Figure 8. Converting an array into a set-multivalued attribute andconversely


Σ5 DC

C1C2

BB1B2

AA1A2

T5 ⇒ ⇐ T5'

1-1

0-1r

1-1

0-1 s

AA1A2excl: s.C

r.B

CC1C2

BB1B2

An is-a hierarchy is replaced by one-to-one relationship types. The exclusion constraint (excl:s.C,r.B) states that an A entity cannot be simultane-ously linked to a B entity and a C entity. It derives from the disjoint property (D) of the subtypes.


Σ6

AA1A2[0-5] arrayA3

T6 ⇒ ⇐ T6'

AA1A2[0-5]

IndexValue

A3id(A2):

Index

Array A2 (left) is transformed into a multivalued compound attribute A2 (right), whose values are distinct wrt component Index (id(A2):Index). The latter indicates the position of the value (Value). The domain of Index is the range [1..5].

Figure 9. Transforming serial attributes into a multivalued attribute andconversely


Σ7

A A1A2XA2YA2ZA3

T7 ⇒ ⇐ T7'

dom(A2.Dimension) = {'X','Y','Z'}

AA1A2[3-3]

DimensionValue

A3id(A2):

Dimension

The serial attributes {A2X, A2Y, A2Z} are transformed into the multivalued compound attribute A2 where the values (Value) are indexed with the distinctive suffix of the source attributes, interpreted as a dimension (sub-attribute Dimension, whose domain is the set of prefixes).



representation of an indexed multivalued attributes (Figure 9). The identificationof these attributes must be confirmed by the analyst.

Higher-Level Transformations

The transformations described in the section, Schema Transformation Basics,are intrinsically atomic: one elementary operator is applied to one object instance,and (Σ4 excluded) none can be defined by a combination of others (orthogonal-ity). This section develops three ways through which more powerful transfor-mations can be developed.

Compound Transformations

A compound transformation is made up of a chain of more elementary operatorsin which each transformation applies on the result of the previous one. Thetransformation Σ8 in Figure 10, illustrated by a concrete example, transforms acomplex relationship type R into a sort of bridge entity type comprising as manyforeign keys as there are roles in R. It is defined by the composition of Σ1-directand Σ2-direct. This operator is of frequent use in relational database design.

The transformation Σ9 is more complex (Figure 11). It is composed of a chainof four elementary operators. The first one transforms the serial attributesExpense-2000, ..., Expense-2004 into multivalued attribute Expense comprisingsub-attributes Year (the dimension) and Amount (transformation Σ7-direct). Thesecond one extracts this attribute into entity type EXPENSE, with attributes Yearand Amount (transformation Σ4-direct). Then, the same operator is applied to

Figure 10. Transformation of a complex relationship type into relationalstructures


Σ8

0-N

0-N

0-N

export

Volume

PRODUCT

Prod_IDid: Prod_ID

COUNTRYCtry_Name

id: Ctry_Name

COMPANYCy_Name

id: Cy_Name

T8 ⇒ ⇐ T8'

PRODUCT

Prod_ID

id: Prod_ID

EXPORTProd_IDCtry_NameCy_NameVolume

id: Ctry_NameProd_IDCy_Name

ref: Cy_Nameref: Prod_IDref: Ctry_Name COUNTRY

Ctry_Nameid: Ctry_Name

COMPANYCy_Name

id: Cy_Name

The relationship type export is first transformed into an entity type + three many-to-one relationship types. Then, the latter are converted into foreign keys.

16 Hainaut


attribute Year, yielding entity type YEAR, with attribute Year. Finally, the entitytype EXPENSE is transformed into relationship type expense (Σ1-inverse).

Predicate-Driven Transformations

A predicate-driven transformation Σp applies an operator Σ to all the schemaobjects that meet a definite predicate p. It will be specified by Σ(p). p is astructural predicate that states the properties through which a class of patternscan be identified. Interestingly, a predicate-based transformation can be inter-preted as a user-defined elementary operator. Indeed, considering the standarddefinition Σ = <P,Q,t>, we can rewrite Σp as Σ*(true) where Σ* = <P∧p,Q,t>. Ingeneral, the inverse of Σp cannot be derived from the expression of Σ and p.Indeed, there is no means to derive the predicate p’ that identifies the constructsresulting from the application of Σp, and only them.

We give in Figure 12 some useful transformations that are expressed in thespecific language of the DB-MAIN tool, which follows the Σ(p) notation. Mostpredicates are parametric; for instance, the predicate ROLE_per_RT(<n1> <n2>),where <n1> and <n2> are integers such that <n1> ≤ <n2> states that the number

Figure 11. Extracting a temporal dimension from serial attributes

Figure 12. Three examples of predicate-driven transformation


Σ9

ProjectDep#InitialBudgetExpense-2000Expense-2001Expense-2002Expense-2003Expense-2004

T9 ⇒ ⇐ T9'

dom(Year) = [2000..2004]

1-N

5-5

expense

Amount

YEARYearid: Year

ProjectDep#InitialBudget

The serial attributes are first transformed into a multivalued attribute, which in turn is extracted as external entity type EXPENSE. The dimension attribute (Year) is also extracted as entity type YEAR. Finally, EXPENSE is mutated into relationship type expense.

predicate-driven transformation interpretation

RT_into_ET(ROLE_per_RT(3 N))

transform each relationship type R into an entity type (RT_into_ET), if the number of roles of R (ROLE_per_RT) is in the range [3 N]; in short, convert all N-ary relationship types into entity types.

RT_into_REF(ROLE_per_RT(2 2) and

ONE_ROLE_per_RT(1 2))

transform each relationship type R into reference attributes (RT_into_ET), if the number of roles of R is 2 and if R has from 1 to 2 one role(s), i.e., R has at least one role with max cardinality 1; in short, convert all one-to-many relationship types into foreign keys.

INSTANTIATE(MAX_CARD_of_ATT(2 4))

transform each attribute A into a sequence of single-value instances, if the max cardinality of A is between 2 and 4; in short, convert multivalued attributes with no more than 4 values into serial attributes.



of roles of the relationship type falls in the range [<n1>..<n2>]. The symbol “N”stands for infinity.

Model-Driven Transformations

A model-driven transformation is a goal-oriented compound transformationmade up of predicate-driven operators. It is designed to transform any schemaexpressed in model M into an equivalent schema in model M’.

As illustrated in the discussion of the relational model expressed as a specializa-tion of the GER (Figure 2), identifying the components of a model also leads toidentifying the constructs that do not belong to it. Except when M ≤ M’, anarbitrary schema S expressed in M may include constructs which violate M’.Each construct that can appear in a schema can be specified by a structuralpredicate. Let P

M denote the set of predicates that defines model M and P

M’ that

of model M’. In the same way, each potentially invalid construct can be specifiedby a structural predicate. Let P

M/M’ denote the set of the predicates that identify

the constructs of M that are not valid in M’. In the DB-MAIN language used inFigure 12, ROLE_per_RT(3 N) is a predicate that identifies N-ary relationship typesthat are invalid in DBTG CODASYL databases, while MAX_CARD_of_ATT(2 N)defines the family of multivalued attributes that is invalid in the SQL2 databasemodel. Finally, we observe that each such set as P

M can be perceived as a single

predicate formed by anding its components.

Let us now consider predicate p ∈ PM/M’

, and let us choose a transformationΣ = <P,Q> such that:

(p ⇒ P) ∧ (PM’

⇒ Q)

Clearly, the predicate-driven transformation Σp solves the problem of invalidconstructs defined by p. Proceeding in the same way for each component of P

M/M’

provides us with a series of operators that can transform any schema in modelM into schemas in model M’. We call such a series a transformation plan, whichis the practical form of any model-driven transformation. In real situations, a plancan be more complex than a mere sequence of operations, and may compriseloops to process recursive constructs for instance.

In addition, transformations such as those specified above may themselves becompound, so that the set of required transformations can be quite large. In suchcases, it can be better to choose a transformation that produces constructs thatare not fully compliant with M’, but that can be followed by other operators whichcomplete the job. For instance, transforming a multivalued attribute can be

18 Hainaut


obtained by an ad hoc compound transformation. However, it can be thoughtmore convenient to first transform the attribute into an entity type + a one-to-many relationship type (Σ4-direct), which can then be transformed into a foreignkey (Σ2-direct). This approach produces transformation plans which are moredetailed and therefore less readable, but that rely on a smaller and more stableset of elementary operators.

The transformation toolset of DB-MAIN includes about 30 operators that haveproven sufficient to process schemas in a dozen operational models. If all thetransformations used to build the plan have the SR-property, then the model-driven transformation that the plan implements is symmetrically reversible.When applied to any source schema, it produces a target schema semanticallyequivalent to the former. This property is particularly important forconceptual→logical transformations. Figure 13 sketches, in the form of a script,a simple transformation plan intended to produce SQL2 logical schemas fromERA conceptual schemas. Actual plans are more complex, but follow theapproach developed in this section.

It must be noted that this mechanism is independent of the process we aremodeling, and that similar transformation plans can be built for processes suchas conceptual normalization or reverse engineering. Though model-driventransformations provide an elegant and powerful means of specification of manyaspects of most database engineering processes, some other aspects still requirehuman expertise that cannot be translated into formal rules.

Figure 13. Simple transformation plan to derive a relational schema fromany ERA conceptual schema (To make them more readable, thetransformations have been expressed in natural language instead of in theDB-MAIN language. The term rel-type stands for relationship type.)

step predicate-based transformation comment

1 transform IS-A relations into one-to-one rel-types operator Σ5-direct;

2 transform complex rel-types into entity types operator Σ1-direct; complex means N-ary or binary many-to-many or with attributes;

3 disaggregate level-1 compound attributes each compound attribute directly depending on an entity type is replaced by its components;

4 transform level-1 multivalued attributes into entity types

operator Σ4-direct; each multivalued attribute directly depending on an entity type is replaced by an entity type;

5 repeat steps 3 to 4 until the schema does not include complex attributes any more

to cope with multi-level attribute structures;

6 transform relationship types into reference groups at this point, only one-to-many and one-to-one rel-types subsist; they are transformed into foreign keys;

7 if the schema still includes rel-types, add a technical identifier to the relevant entity types and apply step 6

step 6 fails in case of missing identifier; a technical attribute is associated with the entity type that will be referenced by the future foreign key;



Transformation-Based Database Design

Most textbooks on database design of the eighties and early nineties propose afive-step approach that is sketched in Figure 14. Through the ConceptualDesign phase, users’ requirements are translated into a conceptual schema,which is the formal and abstract expression of these requirements. The LogicalDesign phase transforms the conceptual schema into data structures (the logicalschema) that comply with the data model of a family of DMS such as relational,OO or standard file data structures. Through the Physical Design phase, thelogical schema is refined and augmented with technical specifications that makeit implementable into the target DMS and that gives it acceptable performance.From the logical schema, users’ views are derived that meet the requirementsof classes of users (View Design). Finally, the physical schema and the usersviews are coded into the DDL9 of the DMS (Coding).

Database Design as a Transformation Process

Ignoring the view design process for simplification, database design can bemodeled by (the structural part of) transformation DB-design:

code = DB-design(UR)

where code denotes the operational code and UR the users requirements.

Figure 14. Standard strategy for database design

Dat

abas

e d

esig

n

Conceptual design

Logical design

Physical design

Coding View design

Logical schema

Physical schema

Users requirements

Conceptual schema

Users views

Operational code

20 Hainaut


Denoting the conceptual, logical and physical schemas respectively by CS, LSand PS and the conceptual design, logical design, physical design and codingphases by C-design, L-design, P-design and Coding, we can refine theprevious expression as follows:

CS = C-design(UR)

LS = L-design(CS)

PS = P-design(LS)

code = Coding(PS)

Clearly, these processes are model-driven transformations and can then bedescribed by transformation plans. The level of formality of these processesdepends on the methodology, on the existence of CASE support and of non-functional requirements such as performance and robustness, that generallyrequire human expertise. For instance, conceptual design (C-design) is a highlyinformal process based on human interpretation of complex information sources,while logical design can be an automated process completely described by atransformation plan. Anyway, these processes can be decomposed into sub-processes that, in turn, can be modeled by transformations and described bytransformation plans, and so forth, until the latter reduce to elementary opera-tors. Three of these processes are worth being examined a bit further.

Conceptual Design

This process includes, among others, two major sub-processes, namely BasicAnalysis, through which informal or semi-formal information sources areanalyzed and their semantic contents are translated into conceptual structures,and (Conceptual) Normalization, through which these raw structures are givensuch additional qualities as readability, normality, minimality, extensibility, com-pliance with representation standards, etc. (Batini, 1992; Blaha, 1998). Thissecond process is more formal than the former, and is a good candidate fortransformational modeling. The plan of Figure 15, though simplistic, can improvethe quality of many raw conceptual schemas.

Logical Design

As shown in the preceding sections, this process can be specified by a model-based transformation. In fact, we have to distinguish two different approaches,



namely ideal and empirical. The ideal design produces a logical schema thatmeets two requirements only: it complies with the target logical model M and itis semantically equivalent to the conceptual schema. According to the transfor-mational paradigm, the logical design process is a M-driven transformationcomprising SR-operators only. The plan of Figure 13 illustrates this principles forrelational databases. Similar plans have been designed for CODASYL DBTG,Object-relational and XML (Estievenart, 2003) databases, among others. Em-pirical design is closer to the semi-formal way developers actually work, relyingon experience and intuition, rather than on standardized procedures. Otherrequirements such as space and time optimization often are implicitly taken intoaccount, making formal modeling more difficult, if not impossible. Though nocomprehensive model-driven transformations can describe such approaches,essential fragments of empirical design based on systematic and reproduciblerules can be described by compound or predicate-driven transformations.

Coding

Quite often overlooked, this process can be less straightforward and morecomplex than generally described in the literature or carried out by CASE tools.Indeed, any DMS can cope with a limited range of structures and integrityconstraints for which its DDL provides an explicit syntax. For instance, plainSQL2 DBMSs know about constraints such as machine value domains, uniquekeys, foreign keys and mandatory columns only. If such constructs appear in aphysical schema, they can be explicitly declared in the SQL2 script. On the otherhand, all the other constraints must be either ignored or expressed in any other

Figure 15. Simple transformation plan to normalize ERA conceptualschemas

step predicate-based transformation comment

1 transform attribute entity types into attributes an attribute entity type has key attributes only, and is linked to one other entity type only through a mandatory rel-type; operator Σ3-inverse and Σ4-inverse;

2 transform relationship entity types into rel-types a relationship entity type has few attributes, is linked to at least 2 entity types through mandatory many-to-one rel-types and is identified by these entity types; operator Σ1-inverse;

3 decompose N-ary rel-types where a non full-key FD holds

transformation of Fig. 5;

4 remove transitive IS-A relations if A is-a B and B is-a C, then A is-a C cannot be explicitly asserted;

5 transform complex multivalued attributes into entity types

a complex attribute is compound, multivalued and has a local identifier; it is assumed to express an autonomous entity type; operator Σ4-inverse;

22 Hainaut


way, at best through check predicates or triggers, but more frequently throughprocedural sections scattered throughout the application programs. Distinguish-ing the DDL code from the external code, the operational code can be split intotwo distinct parts:

code = codeddl ∪ codeext

Despite this variety of translation means, the COD process typically is a two-model transformation (in our framework, GER to DMS-DDL) that can beautomated.

Transformation-Based Database ReverseEngineering

Database reverse engineering is the process through which one attempts torecover or to rebuild the technical and functional documentation of a legacydatabase. Intensive research in the past decade have shown that reverseengineering generally is much more complex than initially thought. We can putforward two major sources of difficulties. First, empirical design has been, andstill is, more popular than systematic design. Second, only the codeddl part of thecode provides a reliable description of the database physical constructs.

Empirical design itself accounts for two understanding problems. First, it oftenrelies on non-standard, unpublished, translation rules that may be difficult tointerpret. Second, actual logical schemas often are strongly optimized, so thatextracting a conceptual schema from the logical schema involves understandingnot only how the latter has been translated in the target model, but also how, andaccording to which criteria, it has been optimized.

The codeddl component expresses a part of the physical schema only. Therefore,the codeext part must be retrieved and interpreted, which leads to two indepen-dent problems. The first one requires parsing a huge volume of program code toidentify code sections that cope with implicit, i.e., undeclared, constructs such asdecomposed (flattened) fields or referential constraints. The second problemconcerns the correct interpretation of these code fragments, that translates intoconstructs to be added to the physical schema.

The whole process is described in Figure 16. It shows that database reverseengineering is decomposed into two main sub-processes, namely Extraction andConceptualization. The objective of the Extraction process is to recover the



complete logical schema of the legacy database. It includes three activities:Parsing the DDL code to extract the raw physical schema, schema Refinementthrough which implicit and hidden constructs are elicited from external code (aswell as from other sources, such as the data themselves, but we will ignore themin this discussion) and Cleaning, in which the technical constructs of the physicalschema are removed.

The second main sub-process, Conceptualization, is intended to derive aplausible conceptual schema from the logical schema. It consists in identifyingthe trace of the translation of conceptual constructs, then in replacing them withtheir source. For instance, a foreign key is interpreted as (i.e., replaced by) amany-to-one relationship type.

The transformational interpretation of the reverse engineering process isstraighforward:

CS = DBRE(code)

where code denotes operational code and CS the conceptual schema.

DBRE can be developed as follows:

LS = Extraction(code)

CS = Conceptualization(LS)

Figure 16. Main processes of database reverse engineering

Dat

abas

e re

vers

e en

gin

eeri

ng

Ext

ract

ion

Cleaning

Parsing Refinement

Logical schema

Physical schema

Conceptual schema

codeddl codeext

Conceptualization

Logical schema

24 Hainaut


Extraction itself includes three processes:

PS = Parsing(codeddl)

PS = Refinement(PS,codeext)

LS = Cleaning(PS)

By comparing the transformational expression of the database design anddatabase reverse engineering processes, we can state the following equivalencerules, in which, as usual, Σ’ denotes the inverse of transformation Σ:

Parsing + Refinement = Coding’

Cleaning = P-design’

Conceptualization = L-design’

Through this analysis, we have shown that, if database design and reverseengineering can be modeled by transformations, then database reverse engineer-ing is, to a large extent, the inverse of database design. This induces importantconsequences. In particular:

• database reverse engineering requires a deep understanding of empiricaldatabase design methodologies, and

• the Conceptualization process can be analyzed and specified by identify-ing the strategies and the transformations that are most popular in empiricallogical design, and by considering their inverse.

Among the operators that have been described, the transformations Σ1-inverse,Σ2-inverse, Σ3-direct and Σ3-inverse, Σ4-direct and Σ4-inverse, Σ5-inverse, Σ6-direct, Σ7-direct, form a sound (but unfortunately not complete) basis forconceptualizing logical schemas. This process can be supported by predicate-driven and model-driven transformations, but, even more than for forwardengineering, reverse engineering heavily relies on human expertise. An in-depthdescription of a wide-scope reverse engineering methodology can be found inHainaut (2002).



Conclusions and Perspectives

In this chapter, we have shown that schema transformation can be used as amajor paradigm in database engineering. In particular, being formally defined, itcan be used to precisely model complex processes and to reason on theirproperties such as semantics preservation. It has also been used to derive newprocesses from former ones, as illustrated by the formalization of databasereverse engineering as the inverse of database design.

Due to their formality, transformations can be implemented in CASE tools, eitheras implicit operators, or as tools that are explicitly made available to thedeveloper. Two implementations are worth being mentioned, namely Rosenthal(1994) and Hainaut (1996b). The latter reference describes the DB-MAINCASE environment which includes a transformation toolbox as well as specialengines for user-defined, predicate-driven and model-driven transformations.Further information can be found at http://www.info.fundp.ac.be/libd.

Transformations also have a great potential in other domains, such as databaseinteroperability, in which mediation between existing databases (McBrien, 2003)and data wrapping (Thiran, 2001) can be formalized and automated thanks to theuse of transformational operators. In this domain, data instance transformationsare modeled by the t part of the transformations. Specifying how the sourceschema is transformed into the target schema automatically provides a chain ofinstance transformations that are used to generate the data conversion code thatis at the core of data migrators (ETL processors), wrappers and mediators.

References

Balzer, R. (1981). Transformational implementation: An example. IEEE TSE,SE-7(1).

Batini, C., Ceri, S. & Navathe, S. B. (1992). Conceptual Database Design.Benjamin/Cummings.

Blaha, M. & Premerlani, W. (1998). Object-oriented Modeling and Designfor Database Applications. Prentice Hall.

Bolois, G. & Robillard, P. (1994). Transformations in reengineering techniques.Proceedings of the Fourth Reengineering Forum ‘Reengineering inPractice’. Victoria, Canada.

Casanova, M. & Amaral De Sa, A. (1984). Mapping uninterpreted schemes intoentity-relationship diagrams: Two applications to conceptual schema de-sign. IBM Journal of Research & Development, 28(1).

26 Hainaut


D’Atri, A. & Sacca, D. (1984). Equivalence and mapping of database schemes.Proceedings of the 10th VLDB Conference. Singapore.

De Troyer, O. (1993). On Data Schema Transformation. PhD thesis, Univer-sity of Tilburg, Tilburg, The Netherlands.

Estiévenart, F., François, A., Henrard, J. & Hainaut, J.L. (2003). Web siteengineering. Proceedings of the Fifth International Workshop on WebSite Evolution, Amsterdam, September 2003. IEEE CS Press.

Fagin, R. (1977). Multivalued dependencies and a new normal form for relationaldatabases. ACM TODS, 2(3).

Fikas, S. F. (1985). Automating the transformational development of software.IEEE TSE, SE-11.

Hainaut, J.L. (1989). A generic entity-relationship model. Proceedings of theIFIP WG 8.1 Conference on Information System Concepts: An In-depth Analysis, North-Holland.

Hainaut, J.L. (1991). Entity-generating schema transformations for entity-relationship models. Proceedings of the 10th Entity-Relationship Ap-proach, San Mateo (CA), North-Holland.

Hainaut, J.L. (1995). Transformation-based database engineering. Tutorialnotes, VLDB’95, Zürich, Switzerland, September 1995. Retrieved from theWWW: http://www.info.fundp.ac.be/libd

Hainaut, J.L. (1996). Specification preservation in schema transformations -Application to semantics and statistics. Data & Knowledge Engineering,11(1).

Hainaut, J.L. (2002). Introduction to Database Reverse Engineering, LIBDlecture notes. Retrieved from the WWW: http://www.info.fundp.ac.be/~dbm/publication/2002/DBRE-2002.pdf

Hainaut, J.L., Chandelon, M., Tonneau, C. & Joris, M. (1993). Contribution toa theory of database reverse engineering. Proceedings of the IEEEWorking Conference on Reverse Engineering, Baltimore, May 1993.IEEE Computer Society Press.

Hainaut, J.L., Chandelon, M., Tonneau, C. & Joris, M. (1993b). Transforma-tional techniques for database reverse engineering. Proceedings of the12th International Conference on ER Approach, Arlington-Dallas, ERInstitute.

Hainaut, J.L., Englebert, V., Henrard, J., Hick, J.M. & Roland, D. (1996b).Database reverse engineering: From requirements to CASE tools. Journalof Automated Software Engineering, 3(1).

Hainaut, J.L., Henrard, J., Hick, J.M., Roland, D. & Englebert, V. (1997).Contribution to the reverse engineering of OO applications - Methodology



and case study. Proceedings of the IFIP 2.6 WC on Database Semantics(DS-7), Leysin (CH), October 1997. Chapman-Hall.

Hainaut, J.L., Hick, J.M., Englebert, V., Henrard, J. & Roland, D. (1996c).Understanding implementations of IS-A relations. Proceedings of theConference on the ER Approach, Cottbus, October 1996, LNCS.Springer-Verlag.

Halpin, T. A. & Proper, H. A. (1995). Database schema transformation andoptimization. Proceedings of the 14th International Conference on ER/OO Modelling (ERA).

Jajodia, S., Ng, P. A. & Springsteel, F. N. (1983). The problem of equivalencefor entity-relationship diagrams. IEEE Trans. on Software Engineering,SE, 9(5).

Kobayashi, I. (1986). Losslessness and semantic correctness of databaseschema transformation: Another look of schema equivalence. InformationSystems, 11(1), 41-59.

Lien, Y. E. (1982). On the equivalence of database models. JACM, 29(2).

McBrien, P. & Poulovassilis, A. (1998). A general formal framework forschema transformation. Data & Knowledge Engineering, 28(1), 47-71.

McBrien, P. & Poulovassilis, A. (2003). Data integration by bi-directionalschema transformation rules. Proceedings of 19th International Con-ference on Data Engineering (ICDE’03). IEEE Computer SocietyPress.

Navathe, S. B. (1980, June). Schema analysis for database restructuring. ACMTODS, 5(2).

Partsch, H. & Steinbrüggen, R. (1983). Program transformation systems.Computing Surveys, 15(3).

Proper, H.A. & Halpin, T.A. (1998). Database schema transformation &optimization. Proceedings of the 14th International Conference onConceptual Modeling, LNCS, 1021, 191-203. Springer.

Rauh, O. & Stickel, E. (1995). Standard transformations for the normalization ofER schemata. Proceedings of the CAiSE’95 Conference, Jyväskylä,Finland, LNCS. Springer-Verlag.

Rosenthal, A. & Reiner, D. (1988). Theoretically sound transformations forpractical database design. Proceedings of Entity-Relationship Approach.

Rosenthal, A. & Reiner, D. (1994). Tools and transformations - Rigourous andotherwise - for practical database design. ACM TODS, 19(2).

Thiran, Ph. & Hainaut, J.L. (2001). Wrapper development for legacy data reuse.Proceedings of WCRE’01. IEEE Computer Society Press.

28 Hainaut


Endnotes

1 Computer-aided Software Engineering.2 Database Management System.3 Entity-relationship-attribute model. The UML class model is a variant of

the ERA model.4 1NF, or First Normal Form designates the class of relations defined on

simple domains (which are neither relations nor powersets). By contrast,a non 1NF relation is said to be in N1NF, or NF2 for short.

5 Defining more formally what the assertion this construct of M alsobelongs to M’ exactly means would require a development which would beuseless in this paper. Therefore, we will rely on an intuitive meaning of thisrelation only. For example, the concepts of field and of column will beconsidered the same though some slight differences exist between them.The same can be said for entity type (ERA), object class (UML), segmenttype (IMS), record type (standard files, CODASYL) and table (SQL2).

6 For Generic Entity-Relationship model.7 For Data Management System, a term that encompasses file managers and

DBMSs.8 The so-called decomposition theorem of the 1NF relational theory (Fagin,

1977) is an example of reversible transformation. Grossly sketched, itstates that the schema {R(A,B,C); A→→BC} can be losslessly replaced by{R1(A,B); R2(A,C)}, since, for any instance r of R, the relation r = r[A,B]*r[A,C]holds. However, there is no reason for any arbitrary instances r1 of R1 andr2 of R2 to enjoy the inverse property r1 = (r1*r2)[A,B]. Therefore, thistransformation is not symmetrically reversible. This example and some ofits variants are developed in (Hainaut, 1996).

9 Data Definition Language: that part of a database language intended todeclare the data structures of the database.

Rule-Based Transformation of Graphs and the Product Type 29


Chapter II

Rule-BasedTransformation of

Graphs and theProduct Type

Renate Klempien-Hinrichs, University of Bremen, Germany

Hans-Jörg Kreowski, University of Bremen, Germany

Sabine Kuske, University of Bremen, Germany

Abstract

This chapter presents rule-based graph transformation as a framework formodeling data-processing systems. It recalls the structuring concept ofgraph transformation units which allows for transforming graphs in a rule-based, modularized, and controlled way. In order to get a flexible typingmechanism and a high degree of parallelism, this structuring concept isextended to the product of transformation units. Moreover, it is demonstratedhow the product type can be used to transform graph transformation units.

30 Klempien-Hinrichs, Kreowski, and Kuske


The authors advocate rule-based graph transformation for all applicationswhere data, knowledge, and information can be modeled as graphs andtheir transformation can be specified by means of rules in an adequate way.

Introduction

The area of graph transformation brings together the concepts of rules andgraphs with various methods from the theory of formal languages and from thetheory of concurrency, and with a spectrum of applications (Figure 1).

Graphs are important structures in computer science and beyond to representcomplex system states, networks, and all kinds of diagrams. The application ofrules provides graphs with a dynamic dimension yielding a rich methodology ofrule-based graph transformation. The three volumes of the Handbook ofGraph Grammars and Computing by Graph Transformation give a goodoverview of the state of the art in theory and practice of graph transformation(Rozenberg, 1997; Ehrig, Engels, Kreowski & Rozenberg, 1999; Ehrig, Kreowski,Montanari & Rozenberg, 1999).

Although one encounters quite a large number of different approaches to graphtransformation in the literature, nearly all of them contain five basic features.

• Graphs to represent complex relations among items in an intuitive butmathematically well-understood way.

• Rules to describe possible changes and updates of graphs in a concise way.

• Rule applications to perform the possible changes and updates on graphsexplicitly as they are embodied in the rules.

• Graph class expressions to specify special classes of graphs to be usedas initial as well as terminal graphs.

• Control conditions to regulate the applications of rules such that theinherent non-determinism of rule application can be cut down.

Figure 1. Main ingredients of graph transformation

theory application

graphsrules



A particular choice of these five features establishes a graph transformationapproach. A selection of rules, initial and terminal graphs, and a control conditionis often called a graph transformation system or a graph grammar if there isa single initial graph as axiom (or a finite set of initial graphs likewise). FollowingKreowski and Kuske (1999a), we use the term graph transformation unit forsuch a selection where we also allow importing other graph transformation unitsfor structuring purposes.

In this chapter, we recall the elementary features of graph transformation and– based on it – discuss some new concepts that enhance the usefulness of graphtransformation. As graphs are derived from graphs by applying rules, the obvioussemantics is a binary relation on graphs or a binary relation between initial andterminal graphs if one provides a subtyping mechanism. To overcome this quiterestricted kind of typing, we introduce product types. The basic notion is aproduct of graph transformation units that comprises tuples of graphs to beprocessed component-wise, but where the transformations of the componentsrun in parallel. The product, together with typical operations on products likeembedding and projection, provides a very flexible kind of typing because onecan declare a sequence of input components and a sequence of output compo-nents independently. To transform input graphs into output graphs, all compo-nents are combined into a proper product of graph transformation units. If onecontrols the parallel transformations of the components suitably, one can get thedesired interrelations between input and output graphs. We then demonstratethat the product type is also quite useful if one wants to transform graphtransformation units.

Graph Transformation

In this section we introduce main concepts of graph transformation like graphs,rules, and transformation units. The concepts are illustrated with a simpleexample from the area of graph theory. In the literature one can find many moreapplications of graph transformation which underline the usefulness from apractical point of view. These are, for example, applications from the area offunctional languages (Sleep, Plasmeijer & van Eekelen, 1993), visual languages(Bardohl, Minas, Schürr & Taentzer, 1999), software engineering (Nagl, 1996),and UML (e.g., Bottoni, Koch, Parisi-Presicce & Taentzer, 2000; Engels,Hausmann, Heckel & Sauer, 2000; Fischer, Niere, Torunski & Zündorf, 2000;Petriu & Sun, 2000; Engels, Heckel & Küster, 2001; Kuske, 2001; Kuske,Gogolla, Kollmann & Kreowski, 2002).



Graph transformation comprises devices for the rule-based manipulation ofgraphs. Given a set of graph transformation rules and a set of graphs, one getsa graph transformation system in its simplest form. Such a system transforms astart graph by applying its graph transformation rules. The semantics can bedefined as a binary relation on graphs where the first component of every pairis a start graph G and the second component is a graph derived from G byapplying a sequence of graph transformation rules. In general, the application ofa graph transformation rule to a graph transforms it locally, i.e., it replaces a partof the graph with another graph part. Often one wishes to start a derivation onlyfrom certain initial graphs, and accepts as results only those derived graphs thatare terminal. Moreover, in some cases the derivation process is regulated in acertain way to cut down the nondeterminism of rule applications. For example,one may employ a parallel mode of transformation as in L systems, or one mayrestrict the order in which rules are applied. Altogether the basic elements of agraph transformation approach are graphs, rules, their application, graph classexpressions, and control conditions.

Graphs

First of all, there is a class of graphs G, that may be directed or undirected, typedor untyped, labelled or unlabeled, simple or multiple. Examples for graph classesare labeled directed graphs, hypergraphs, trees, forests, finite automata, Petrinets, etc. The choice of graphs depends on the kind of applications one has inmind and is a matter of taste.

In this chapter, we consider directed, edge-labeled graphs with individual,multiple edges. A graph is a construct G = (V, E, s, t, l) where V is a set ofvertices, E is a set of edges, s, t: E → V are two mappings assigning each edgee ∈ E a source s(e) and a target t(e), and l: E → C is a mapping labeling eachedge in a given label alphabet C. A graph may be represented in a graphical waywith circles as nodes and arrows as edges that connect source and target, withthe arrowhead pointing to the target. The labels are placed next to the arrows.In the case of a loop, i.e., an edge with the same node as source and target, wemay draw a flag that is posted on its node with the label inside the box. To coverunlabeled graphs as a special case, we assume a particular label * that is invisiblein the drawings. This means a graph G is unlabeled if l(e) = * for all e ∈ E. Forinstance the graph in Figure 2 consists of six nodes, one of them with a begin-flag, another with an end-flag, and a third one with an unlabeled flag. Moreover,it consists of seven directed edges where some of them are labeled with p. Thep-edges form a simple path (i.e., a path without cycles) from the begin-flaggednode to the end-flagged node. If one takes the subgraph induced by the edgesof the simple path and the begin- and end-flag and removes all occurrences of



the label p, one gets the string graph (i.e., a graph that is a simple path from abegin-flagged node to an end-flagged node) that is shown in Figure 3.

String graphs can be used to represent natural numbers. The string graph inFigure 3 represents the number four because it has four unlabeled edges betweenits begin-flagged and its end-flagged node. Whenever a string graph representsa natural number k in this way, we say that it is the k-string graph.

Rules and Rule Applications

To be able to transform graphs, rules are applied to graphs yielding graphs. Givensome class R of graph transformation rules, each rule r ∈ R defines a binaryrelation ⇒

r ⊆ G×G on graphs. If G ⇒

r H, one says that G directly derives H by

applying r.

There are many possibilities to choose rules and their applications. Rule classesmay vary from the more restrictive ones, like edge replacement (Drewes,Kreowski & Habel, 1997) or node replacement (Engelfriet & Rozenberg, 1997),to the more general ones, like double-pushout rules (Corradini et al., 1997),single-pushout rules (Ehrig et al., 1997), or PROGRES rules (Schürr, 1997).

In this chapter, we use rules of the form r = (L →K R) where L and R are graphs

(the left- and right-hand side of r, respectively) and K is a set of nodes sharedby L and R. In a graphical representation of r, L and R are drawn as usual, withnumbers uniquely identifying the nodes in K. Its application means to replace an

Figure 2.

Figure 3.



occurrence of L with R such that the common part K is kept. In particular, wewill use rules that add or delete flags, label edges, and add or delete a nodetogether with an edge.

The rule r = (L →K R) can be applied to some graph G directly deriving the graph

H if it can be constructed up to isomorphism (i.e., up to renaming of nodes andedges) in the following way.

1. Find an isomorphic copy of L in G, i.e., a subgraph that coincides with L upto the naming of nodes and edges.

2. Remove all nodes and edges of this copy except the nodes correspondingto K, provided that the remainder is a graph (which holds if the removal ofa node is accompanied by the removal of all its incident edges).

3. Add R by merging K with its corresponding copy.

For example (Figure 4), the rule move has as its left-hand side a graph consistingof an end-flagged node 1, a node 2 with unlabeled flag, and an unlabeled edgefrom node 1 to node 2. The right-hand side consists of the same two nodes wherenode 1 has no flag and node 2 has an end-flag. Moreover, there is a p-labelededge from node 1 to node 2. The common part of the rule move consists of thenodes 1 and 2.

The application of move labels an unlabeled edge with p if the edge connects anend-flagged node and a node with an unlabeled flag, moves the end-flag fromthe source of the edge to its target, and removes the unlabeled flag. For example,the application of move to the graph above yields the graph shown in Figure 5.

Figure 4.

Figure 5.



Note that this rule cannot be applied to the former graph in any other way; forinstance, its left-hand side requires the presence of an unlabeled flag.

Graph Class Expressions

The aim of graph class expressions is to restrict the class of graphs to whichcertain rules may be applied or to filter out a subclass of all the graphs that canbe derived by a set of rules. Typically, a graph class expression may be somelogic formula describing a graph property like connectivity, or acyclicity, or theoccurrence or absence of certain labels. In this sense, every graph classexpression e specifies a set SEM(e) of graphs in G. For instance, all refers to alldirected, edge-labeled graphs, whereas empty and bool designate a class ofexactly one graph each (the empty graph EMPTY for empty, and the graphTRUE consisting of one true-flagged node for bool). Moreover, graph specifiesall unlabeled graphs each node of which carries a unique flag (which is unlabeled,too). Also, a particular form of the graphs may be requested; e.g., the expressionnat defines all k-string graphs.

Control Conditions

A control condition is an expression that determines, for example, the order inwhich rules may be applied. Semantically, it relates start graphs with graphs thatresult from an admitted transformation process. In this sense, every controlcondition c specifies a binary relation SEM(c) on G. As control condition, we usein particular the expression true that allows all transformations (i.e., all pairs ofgraphs). Moreover, we use regular expressions as control conditions. Theydescribe in which order and how often the rules and imported units are to beapplied. In particular, the Kleene star states that an arbitrary number of iterationsmay be executed. The precise meaning of a regular expression is explainedwhere it is used. More about control conditions can be found in Kuske (2000).

All together, a class of graphs, a class of rules, a rule application operator, a classof graph class expressions, and a class of control conditions, form a graphtransformation approach based on which graph transformation units as a unifyingformalization of graph grammars and graph transformation systems can bedefined. To transform graphs, a unit has local rules, but may also import othergraph transformation units. Therefore, the semantic relation of a unit is given bythe interleaving of rule applications and calls of imported units.

Transformation units were presented in Andries et al. (1999) and Kreowski andKuske (1999b) as a modularization concept for graph transformation systems(cf. also Heckel, Engels, Ehrig & Taentzer, 1999). In the literature there are



case studies where transformation units are employed to model the semantics offunctional programming languages (Andries et al., 1999), UML state machines(Kuske, 2001), and logistic processes (Klempien-Hinrichs, Knirsch & Kuske,2002).

Transformation Units

In general, a graph transformation system may consist of a huge set of rules thatby its size alone is difficult to manage. Transformation units provide a means tostructure the transformation process. The main structuring principle of transfor-mation units relies on the import of other transformation units or — on thesemantic level — on binary relations on graphs. The input and the output of atransformation unit each consists of a class of graphs that is specified by a graphclass expression. The input graphs are called initial graphs and the output graphsare called terminal graphs. A transformation unit transforms initial graphs toterminal graphs by applying graph transformation rules and imported transforma-tion units in a successive and sequential way. Since rule application is non-deterministic in general, a transformation unit contains a control condition thatmay regulate the graph transformation process.

A graph transformation unit is a system tu = (I, U, R, C, T) where I and T aregraph class expressions, U is a (possibly empty) set of imported graph transfor-mation units, R is a set of rules, and C is a control condition.

To simplify technicalities, we assume that the import structure is acyclic (for astudy of cyclic imports see Kreowski, Kuske and Schürr (1997)). Initially, onebuilds units of level 0 with empty import. Then units of level 1 are those thatimport only units of level 0, and units of level n+1 import only units of level 0 tolevel n, but at least one from level n.

In graphical representations of transformation units we omit the import compo-nent if it is empty, the initial or terminal component if it is set to all, and the controlcondition if it is equal to true.

In the following, we present some examples of transformation units. We startwith very simple specifications of natural numbers and truth values because theyare auxiliary data types to be used later to model the more interesting examplesof simple paths, long simple paths, and Hamiltonian paths.

The first transformation unit nat0 (Figure 6, left side) constructs all string graphsthat represent natural numbers by starting from its initial graph, which represents0, and transforming the n-string graph into the n+1-string graph by applying therule succ.



The second transformation unit nat1 (Figure 6, right side) is a variant of nat0,but now with all n-string graphs as initial graphs. Consequently, it describesarbitrary additions to arbitrary n-string graphs by sequentially increasing therepresented numbers by 1.

The third transformation unit nat2 (Figure 7) also transforms string graphs intostring graphs. It has two rules pred and is-zero. The application of the rule predto the n-string graph (with n ≥ 1 since otherwise the rule cannot be applied)converts it into the n–1-string graph. The second rule is-zero can be applied onlyto the 0-string graph but does not transform it, which means that this rule can beused as a test for 0. Moreover, the transformation unit nat2 imports nat1 so thatarbitrary additions can be performed, too. The rules of nat2 and the imported unitnat1 can be applied in arbitrary order and arbitrarily often. Hence nat2 convertsn-string graphs into m-string graphs for natural numbers m, n. Therefore nat2can be considered as a data type representing natural numbers with a simple setof operations.

Figure 6.

Figure 7.

nat2

initial: nat

rules:

pred:

begin end

end

1

*

end

1

is-zero:

begin end

1 1

uses: nat1



The forth transformation unit, bool0 = (empty, ∅, set-true, true, bool), is shownin Figure 8. It has a single initial graph, the empty graph EMPTY. It does notimport other transformation units and it has one rule set-true which turns EMPTYto the graph TRUE. The control condition allows all transformations, meaningthat TRUE may be added arbitrarily often to EMPTY. However, the terminalgraph class expression specifies the set consisting of TRUE, which ensures thatthe rule set-true is applied exactly once to the initial graph.

One can consider bool0 as a unit that describes the type Boolean in its mostsimple form. At first sight, this may look a bit strange. But it is quite useful if onewants to specify predicates on graphs by nondeterministic graph transformation:If one succeeds to transform an input graph into the graph TRUE, the predicateholds, otherwise it fails. In other words, if the predicate does not hold for the inputgraph, none of its transformations yield TRUE.

The transformation unit simple-path given in Figure 9 constitutes an example ofanother kind. As an initial graph, it admits all unlabeled graphs with exactly oneflag on every node. It chooses an arbitrary simple path in an initial graph bylabeling the edges of the path with p and adding a begin-flag and an end-flag tothe beginning and the end of the path, respectively. This is done with the help oftwo rules start and move. The rule start turns an unlabeled flag of an arbitrarynode into two flags, respectively labeled with begin and end, and the rule moveis the same as above, i.e., it labels with p an edge from an end-flagged node toa node with an unlabeled flag, moves the end-flag to the other node, and removesthe unlabeled flag. The control condition is a regular expression which is satisfiedif first the rule start is applied, followed by move applied arbitrarily often. Theterminal graph class expression admits all graphs, which is why it is not explicitlyshown.

Figure 8.

bool0

initial:

rules:

set-true: empty

true

empty

terminal:true



Interleaving Semantics of Transformation Units

Transformation units transform initial graphs to terminal graphs by applyinggraph transformation rules and imported transformation units so that the controlcondition is satisfied. Hence, the semantics of a transformation unit can bedefined as a binary relation between initial and terminal graphs.

For example, the interleaving semantics of the transformation unit simple-pathconsists of all pairs (G,G’) such that G is an unlabeled graph with exactly one flagon every node and G’ is obtained from G by labeling the edges of a simple pathwith p, setting a begin-flag at the source of the path and an end-flag at the target ofthe path, and removing the flags from the intermediate nodes on the path.

In general, for a transformation unit tu without import, the semantics of tuconsists of all pairs (G,G’) of graphs such that:

1. G is an initial graph and G’ is a terminal graph;

2. G’ is obtained from G via a sequence of rule applications, i.e., (G,G’) is inthe reflexive and transitive closure of the binary relation obtained from theunion of all relations ⇒

r where r is some rule of tu; and

3. the pair (G,G’) is allowed by the control condition.

If the transformation unit tu has a non-empty import, the interleaving semanticsof tu consists of all pairs (G,G’) of graphs which satisfy the preceding items 1and 3, and where, in addition to rules, imported transformation units can beapplied in the transformation process of tu, i.e., the second item above isextended to:

Figure 9.

simple-path

rules:

cond: start ; move

start:

move:

begin end

end

1 2

endp

1 2

*

1 1

initial: graph

cond: start ; move *



2’. G’ is obtained from G via a sequence of rule applications and applicationsof imported units. This means that (G,G’) is in the reflexive and transitiveclosure of the binary relation obtained from the union of all relations ⇒

r and

SEM(u) where r is some rule of tu and u is some imported transformationunit of tu.

More formally, the interleaving semantics of tu is defined as follows: Let tu = (I,U, R, C, T) be a transformation unit. Then the interleaving semantics SEM(tu)is recursively defined as:

SEM(tu) = SEM(I) × SEM(T) ∩ (∪r ∈ R

⇒r ∪ ∪

u ∈ U SEM(u))* ∩

SEM(C).

If the transformation unit tu is of level 0, the semantic relation is well-definedbecause the union over U is the empty set. If tu is of level n+1, we can inductivelyassume that SEM(u) of each imported unit u is already well-defined, so thatSEM(tu) is also well-defined as a union and intersection of defined relations.

Product Type

As the iterated application of rules transforms graphs into graphs yielding aninput-output relation, the natural type declaration of a graph transformation unittu = (I, U, R, C, T) is tu: I→T where moreover the initial and terminal graphs aresubtypes of the type of graphs that are transformed by the unit. But in manyapplications one would like to have a typing that allows one to consider severalinputs and maybe even several outputs, or at least an output of a type differentfrom all inputs. For instance, a test whether a given graph has a simple path ofa certain length would be suitably declared by long-simple-path: graph × nat→ bool (or something like this) asking for a graph and a non-negative integer asinputs and a truth value as output.

Such an extra flexibility in the typing of graph transformations can be providedby products of graph transformation units, together with some concepts based onthe products. In more detail, we introduce the following new features:

1. The product of graph transformation units providing tuples of graphs to beprocessed and particularly tuples of initial and terminal graphs as well astuples of rules and calls of imported units, called action tuples, that can beexecuted on graph tuples in parallel.



2. The embedding and projection of a product into resp. onto another productthat allow one to choose some components of a product as inputs or outputsand to copy some components into others.

3. The semantics of a product of graph transformation units is the product ofthe component semantics such that — intuitively seen — all componentsrun independently from each other. If one wants to impose some iterationand interrelation between the components, one can use control conditionsfor action tuples like for rules and imported units.

The product type generalizes the notion of pair grammars and triple grammarsas introduced by Pratt (1971) and Schürr (1994), respectively.

Product of Graph Transformation Units

Let tu1, …, tu

m for m ≥ 1 be a sequence of graph transformation units with

tuj = (I

j , U

j , R

j , C

j , T

j) for j = 1, ..., m. Then the product:

prod = tu1 × … × tu

m =

1

m

ii

tu=

∏

transforms m-tuples of graphs (G1, …, G

m) by means of component-wise

transformation.

The global semantic relation of the product is just the product of the semanticrelations of the components, i.e., ((G

1, …, G

m), (H

1, …, H

m)) ∈ SEM(prod) if and

only if (Gi,H

i) ∈ SEM(tu

i) for i = 1, ..., m.

But there is also a notion of a single computation step that transforms graphtuples by applying action tuples. An action tuple (a

1, …, a

m) consists of rules,

imported units and an extra void action, i.e., ai ∈ R

i or a

i ∈ U

i or a

i = – for i =

1, ..., m. It transforms a graph tuple (G1, …, G

m) into a graph tuple (G

1’, …, G

m’)

if Gi →ai

Gi’ for a

i ∈ R

i and (G

i,G

i’) ∈ SEM(a

i) for a

i ∈ U

i and G

i = G

i’ for

ai = – .

In other words, a computation step simultaneously applies rules to somecomponents and performs calls of import units in other components while theremaining components of the graph tuple are kept unchanged.

Let a single computation step be denoted by (G1, …, G

m) → (G

1’, …, G

m’), and

let →∗ be the reflexive and transitive closure of →. Then one can say that (G1,

…, Gm) →∗ (H

1, …, H

m) satisfies the control condition tuple (C

1, …, C

m) if

(Gi,H

i) ∈ SEM(C

i) for i = 1, …, m. Similarly, (G

1, …, G

m) is an initial graph



tuple if Gi ∈ SEM(I

i), and (H

1, …, H

m) is a terminal graph tuple if H

i ∈

SEM(Ti), for i = 1, …, m. If all this holds, the pair of tuples belongs to the step

semantics of the product, which is denoted by STEPSEM(prod). It is easy to seethat the global semantics and the step semantics coincide, i.e., SEM(prod) =STEPSEM(prod).

For example, consider the product simple-path × nat2 of the transformationunits simple-path and nat2. Its semantics consists of all pairs ((G

1,G

2), (H

1,H

2))

where (G1,G

2) is in the semantics of simple-path and (H

1,H

2) is in the semantics

of nat2. This product combines two units in a free way like the well-knownCartesian product. In order to model interrelation between the components, e.g.,to test if a path in a graph is of a certain length, we would like to have controlconditions for the computation steps and a boolean value as output. This can beachieved with the concepts introduced in the following two sections.

Embedding and Projection

If not all initial graph class expressions of a product are meant as inputs, but someof them are just of an auxiliary nature for intermediate computations or to be usedas outputs, one may choose the input types and embed their product into theactual product that provides the graph tuples to be transformed. This is possiblewhenever the auxiliary components have unique initial graphs and if everychosen input type is a subtype of the corresponding initial graphs.

Let prod = tu1 × … × tu

m be a product of transformation units and let X be a set

of graph class expressions that is associated with the product components by aninjective mapping ass: X→{1,…,m} such that SEM(x) ⊆ SEM(I

ass(x)) for all x ∈ X.

Assume, moreover, for all j ∈ {1,…,m}\ ass(X) that either SEM(Ij) = {G

j} for

some graph Gj or SEM(x) ⊆ SEM(I

j) for some chosen x ∈ X, which will be

denoted by copy: x→j. Then we get an embedding of the product of the graphsin SEM(x) for x ∈ X into the product of initial graphs of the product prod:

embed: 1

( ) ( )jm

x X j

SEM x SEM I∈ =

→∏ ∏

defined by embed((Gx)

x∈X) = (G

1, …, G

m) with G

i = G

x for ass(x) = i and copy:

x → i, and Gi ∈ SEM(I

i) = {G

i} otherwise.

This means that each input component is embedded into its correspondingcomponent of the product of units with respect to ass and into all other



components given by the copy relation. All remaining components of the productof units are completed by the single initial graphs of these components.

As a simple example, let prod = simple-path × nat2 × bool0 and let X ={graph,nat}. Consider the initial graph class expressions graph, nat and emptyof the transformation units simple-path, nat2, and bool0, respectively. Everypair (G

1,G

2) ∈ SEM(graph) × SEM(nat) can be embedded into SEM(graph) ×

SEM(nat) × SEM(empty) by choosing ass(graph) = 1 and ass(nat) = 2, i.e., weget embed((G

1,G

2))=(G

1,G

2,EMPTY) for every pair (G

1,G

2)∈SEM(graph) ×

SEM(nat).

Conversely, if one wants to get rid of some component graphs, the well-knownprojection may be employed. The same mechanism can be used to multiplycomponents, which allows one, in particular, to copy a component graph intoanother component.

Let Y be a set which is associated with the product prod by ass: Y → {1, …, m}.Then one can consider the product of the terminal graphs in SEM(T

ass(y)) for all

y ∈ Y as the semantics of the association ass, i.e.:

SEM(ass) = ( )( )

ass y

y Y

SEM T∈

∏ .

The product of terminal graphs of the product prod can be projected toSEM(ass), i.e.:

proj: 1

( ) ( )i

m

i

SEM T SEM ass=

→∏

defined by proj(H1, …, H

m) = (H

ass(y))

y ∈ Y. For example, consider the terminal

graph class expressions all and bool of the transformation units simple-path,nat2, and bool0. Let Y = {3} and let ass(3) = 3. The semantics of ass is equalto the terminal graph TRUE of bool0 and every triple (H

1, H

2, H

3) ∈ SEM(all)

× SEM(all) × SEM(bool) is projected to H3, i.e., to TRUE.

In general, there are two cases of interest. Firstly, if Y ⊆ {1, …, m} and ass isthe corresponding inclusion, then proj is the ordinary projection of a product tosome of its components. (This is the case in the described example.) Secondly,if several elements of Y are mapped to the same index i, this results in themultiplication of the i-th component.

Embedding and projection may be used to realize transformations on graphs withtype declarations of the form trans: in

1 × … × in

k → out

1 × … × out

l where the



ini and the out

j are graph class expressions. The intention is that trans relates

the product of inputs SEM(in1) × … × SEM(in

k) with the product of outputs

SEM(out1) × … × SEM(out

l). This is obtained by using a product prod of graph

transformation units tu1,…,tu

k+l such that SEM(in

i) ⊆ SEM(I

i) for i = 1,…,k and

SEM(Tj) ⊆ SEM(out

j) for j = k+1,…,k+l. The first k inclusions allow one to

embed the inputs into the initial graph tuples of the product prod if, for j =k+1,…,k+l, we can choose some i with copy: i → j or SEM(I

j) = {G

j} for some

graph Gj. The last l inclusions allow one to project the terminal graph tuples of

prod onto outputs. Therefore, the semantic relation of trans has the properform, but the output tuples are totally independent of the input tuples due to theproduct semantics. To overcome this problem, we generalize the notion ofcontrol conditions in such a way that it applies not only to the control of ruleapplications and calls of imported units, but also to action tuples.

Control Conditions for Action Tuples

A control condition regulates the use of rules and imported units formally byintersecting the interleaving semantics with the semantic relation given by thecontrol condition. This is easily generalized to action tuples if one replaces theinterleaving semantics by the step semantics of the product of graph transforma-tion units.

In concrete cases, the control condition may refer to action tuples, just as it canrefer to rules and imported units. To make this more convenient, action tuplesmay get identifiers.

As an example how the features based on the product may be used, we specifythe test long-simple-path that transforms graphs and non-negative integers asinputs into truth values as output.

long-simple-path: graph × nat → bool

prod: simple-path × nat2 × bool0

actions: a0 = (start, –, – )

a1 = (move, pred, – )

a2 = (–, is-zero, set-true)

cond: a0 ; a

1* ; a

2

It is modeled on top of the product of the units simple-path, nat2 and bool0. Thetyping is appropriate as graph and nat specify the initial graphs of simple-pathand nat2 respectively, and bool refers to the terminal graph of bool0.



Hence, a computation in long-simple-path starts with an unlabeled graph anda non-negative integer completed to a triple by the initial graph of bool0. Thenthe control condition requires to perform a

0 that chooses a start node in the graph

without changing the other two components. This is followed by the iteration ofa

1 which in each step synchronously prolongs a simple path in the first component

by one edge and decreases the integer in the second component by 1. Hence weget a graph with a path of the input length if the second component becomes zero.This is tested by the second component of a

2. In the positive case, a

2 is performed

yielding TRUE as output in the third component. In other words, long-simple-path computes TRUE if and only if the input graph G has a simple path of the inputlength n.

Transformation of Graph Transformations

Two graph transformations may be related with each other in various significantways:

1. They may be semantically equivalent, meaning that their semantic relationscoincide or, seen from another perspective, that a semantic relation ismodeled in two different ways.

2. One graph transformation may be the refinement of the other one, meaningthat each computational step of the one can be accomplished by aninterleaving sequence of the other.

3. One graph transformation may be reduced to the other, meaning that thesemantic relation of the one can be translated into the semantic relation ofthe other.

Such situations are nicely modeled by transformations of graph transformations.In the case of two graph transformation units tu

i = (I

i, U

i, R

i, C

i, T

i) with SEM(tu

i)

⊆ SEM(Ii) × SEM(T

i) for i = 1,2, a transformation of the translational type (or

a translation for short) of tu1 into tu

2 is defined by two graph transformation

units tu1-2-tu

2(I) = (I

1, U

I, R

I, C

I, I

2) and tu

1-2-tu

2(T) = (T

1, U

T, R

T, C

T, T

2) where

the former transforms initial graphs of tu1 into initial graphs of tu

2 and the latter

does the same with respect to terminal graphs.

How a translation relates graph transformations units is depicted in Figure 10.

Clearly, such a translation is only meaningful if it preserves the semantics, whichis covered by the notion of correctness. A translation of tu

1 into tu

2 is correct

if the diagram in Figure 10 commutes, i.e., if the sequential compositions of the



semantic relations of SEM(tu1) with SEM(tu

1-2-tu

2(T)) on one hand and of

SEM(tu1-2-tu

2(I)) with SEM(tu

2) on the other hand coincide.

Correct translations can be very helpful because they carry over certainproperties from the source unit to the target unit and the other way round. Forexample, if some question is undecidable for the source unit, the correspondingquestion must be undecidable for the target unit, provided that the translatingunits have computable semantic relations (which holds in all reasonable cases).To demonstrate the usefulness of translations more explicitly, we restrict thenotion of translations to the notion of reductions as used in the study of thecomplexity class NP of all decision problems that can be computed non-deterministically in polynomial time. A reduction of tu

1 to tu

2 is a correct

translation of tu1 into tu

2 subject to the following further conditions:

1. tu1 and tu

2 model predicates, i.e., their output domain is bool,

2. tu1-2-tu

2(T) is the identity on bool, and

3. tu1-2-tu

2(I) has no import and runs in polynomial time, i.e., each derivation

starting in an initial graph of tu1 has a length polynomial in the size of its start

graph and can be prolonged such that it derives an initial graph of tu2.

If tu2 models an NP-problem, i.e., it has no import and each derivation starting

in an initial graph has a length that is polynomial in the size of the start graph, thenthe composition of the reduction and the semantic relation of tu

2 is in NP, too.

While the reduction yields an output for every input in a polynomial number ofsteps, the following computation in tu

2 runs also in polynomial time, but it is

nondeterministic because it may compute TRUE for some of its inputs whileother computations for the same input end in deadlocks. Hence, the sequentialcomposition, which is the semantic relation of tu

1 due to the correctness of the

translation, is nondeterministic, too, with polynomial runtime. By a similarreasoning, it turns out that tu

2 models an NP-complete problem if tu

1 does, i.e.,

Figure 10. Translation of graph transformation units



if each NP-problem can be reduced to the semantic relation of tu1. So the graph-

transformational variants of reductions may be used to investigate the class NPin the same way as ordinary reductions are useful. But, as many interestingproblems in NP are graph problems, graph-transformational reductions may bequite suitable.

As an illustrating example, we specify a reduction from the Hamiltonian-pathproblem HP into the unit long-simple-path. We assume that HP is a predicatewith the typing HP: graph → bool that yields TRUE for an input graph G if andonly if G has a simple path that visits all nodes. An explicit specification by graphtransformation is not needed, but it would look similar to simple-path, onlymaking sure that all nodes are involved. Due to the typing, the reduction mustconsist of a graph transformation unit of the type HP-2-lsp: graph → graph × natthat copies the input graph as output graph and computes the number of nodesminus one of the input graph as second output. For this purpose, the product ofunits mark-all-nodes, graph and nat0 will be used. The unit graph = (graph,∅, ∅, true, graph) takes unlabeled graphs as initial and terminal graphs and iswithout import and rules such that its semantics is the identity relation onSEM(graph), i.e., the input graph becomes the output graph. The unit mark-all-nodes consists of unlabeled graphs as initial graphs, of one rule mark thatreplaces the unlabeled flag by another flag (ok-labeled for example), and ofgraphs without unlabeled flags as terminal graphs. This is an auxiliary unit themeaning of which is that each derivation from an initial to a terminal graph hasthe number of nodes as length. Hence, an action tuple that applies the rule markin the first component allows one to count the number of nodes.

Summarizing, we get the following specification:

HP-2-lsp: graph → graph × nat0

prod: mark-all-nodes × graph × nat0

copy: 1 → 2

actions: b0 = (mark, –, –)

b1 = (mark ,–, succ)

cond: b0 ; b

1*

Note that the length of all computations is bounded by the number of nodes of theinput graph and that each computation can be prolonged until all nodes aremarked. As one always marks the first node without increasing the initialinteger 0 and as all other nodes are marked while the integer is increased by onein each step, one ends up with the number of nodes minus one as integer output.And the runtime of HP-2-lsp is linear. If one composes the semantic relation of



HP-2-lsp with that of long-simple-path, it returns TRUE if and only if theoriginal input graph has a simple path of a length that is the number of nodes minusone such that it visits all nodes. In other words, the translation is correct. As theHamilton-path problem is NP-complete, our reduction shows that long-simple-path is also NP-complete (which is already well known in this case).

Conclusions

In this chapter, we have given an introductory survey of graph transformationwith graphs, rules, rule application, graph class expressions, and control condi-tions as basic features. As all of the concepts are handled in a generic,parametric way, this covers nearly all of the graph transformation approachesone encounters in the literature (see, e.g., Rozenberg, 1997, for an overview).Readers who are interested in seeing the full spectrum of applications of graphtransformation and its relation to the theory of concurrency are referred to theHandbook of Graph Grammars and Computing by Graph Transformation,Vol. 2 and 3 (Ehrig, Engels, Kreowski & Rozenberg, 1999; Ehrig, Kreowski,Montanari & Rozenberg, 1999).

In addition, we have proposed the new concept of product types that allows oneto transform a tuple of graphs by the synchronous transformation of thecomponents. This is quite helpful to specify transformations with a flexibletyping, i.e., with an arbitrary sequence of input graphs and an arbitrary sequenceof output graphs. Moreover, the types of the input and output graphs need not besubtypes of the same type of graphs anymore. As a consequence, the producttype is particularly useful if one wants to transform graph transformations intoeach other. Further investigation of the product type may concern the followingaspects:

As we used graph-transformational versions of the truth values and the naturalnumbers in our illustrating examples, one may like to combine graph types witharbitrary abstract data types.

In the presented definition, we consider the product of graph transformationunits. But one may like to import products in units and to use components that areagain products. Whether such a composite use of products works must beinvestigated.

The transformation of graph transformation units is only tentatively sketched. Itmust be worked out how it helps to study refinement and semantic equivalenceand other interesting relationships between graph transformation systems.



Acknowledgments

The research presented here was partially supported by the EC ResearchTraining Network SegraVis (Syntactic and Semantic Integration of VisualModelling Techniques) and the Collaborative Research Centre 637 (Autono-mous Cooperating Logistic Processes: A Paradigm Shift and Its Limitations)funded by the German Research Foundation (DFG).

References

Andries et al. (1999). Graph transformation for specification and programming.Science of Computer Programming, 34(1), 1-54.

Bardohl, R., Minas, M., Schürr, A. & Taentzer, G. (1999). Application of GraphTransformation to Visual Languages. In H. Ehrig, G. Engels, H.-J. Kreowski& G. Rozenberg (Eds.), Handbook of Graph Grammars and Computingby Graph Transformation, Vol. 2: Applications, Languages and Tools(pp. 105-180). Singapore: World Scientific.

Bottoni, P., Koch, M., Parisi-Presicce, F., & Taentzer, G. (2000). ConsistencyChecking and Visualization of OCL Constraints. In A. Evans, S. Kent & B.Selic (Eds.), Proceedings of UML 2000 – The Unified ModelingLanguage. Advancing the Standard, Lecture Notes in Computer Sci-ence (Vol. 1939, pp. 294-308). Springer.

Corradini, A., Montanari, U., Rossi, F., Ehrig, H., Heckel, R. & Löwe, M. (1997).Algebraic Approaches to Graph Transformation – Part I : Basic Conceptsand Double Pushout Approach. In G. Rozenberg (Ed.), Handbook ofGraph Grammars and Computing by Graph Transformation, Vol. 1:Foundations (pp. 163-245). Singapore: World Scientific.

Drewes, F., Kreowski, H.-J. & Habel, A. (1997). Hyperedge ReplacementGraph Grammars. In G. Rozenberg (Ed.), Handbook of Graph Gram-mars and Computing by Graph Transformation, Vol. 1: Foundations(pp. 95-162). Singapore: World Scientific.

Ehrig et al. (1997). Algebraic Approaches to Graph Transformation – Part II:Single Pushout Approach and Comparison with Double Pushout Approach.In G. Rozenberg (Ed.), Handbook of Graph Grammars and Computingby Graph Transformation, Vol. 1: Foundations (pp. 247-312). Singapore:World Scientific.

Ehrig, H., Engels, G., Kreowski, H.-J. & Rozenberg, G. (Eds.) (1999). Hand-book of Graph Grammars and Computing by Graph Transformation,Vol. 2: Applications, Languages and Tools. Singapore: World Scientific.



Ehrig, H., Kreowski, H.-J., Montanari, U. & Rozenberg, G. (Eds.) (1999).Handbook of Graph Grammars and Computing by Graph Transfor-mation, Vol. 3: Concurrency, Parallelism, and Distribution. Singapore:World Scientific.

Engelfriet, J. & Rozenberg, G. (1997). Node Replacement Graph Grammars. InG. Rozenberg (Ed.), Handbook of Graph Grammars and Computing byGraph Transformation, Vol. 1: Foundations (pp. 1-94). Singapore:World Scientific.

Engels, G., Hausmann, J.H., Heckel, R. & Sauer, S. (2000). Dynamic MetaModeling: A Graphical Approach to the Operational Semantics of Behav-ioral Diagrams in UML. In A. Evans, S. Kent & B. Selic (Eds.), Proceed-ings of UML 2000 – The Unified Modeling Language. Advancingthe Standard, Lecture Notes in Computer Science (Vol. 1939, pp. 323-337). Springer.

Engels, G., Heckel, R. & Küster, J.M. (2001). Rule-Based Specification ofBehavioral Consistency Based on the UML Meta-model. In M. Gogolla &C. Kobryn (Eds.), UML 2001 – The Unified Modeling Language. ModelingLanguages, Concepts, and Tools, Lecture Notes in Computer Science,Vol. 2185 (pp. 272-286). Springer.

Fischer, T., Niere, J., Torunski, L. & Zündorf, A. (2000). Story Diagrams: A newGraph Transformation Language based on UML and Java. In H. Ehrig, G.Engels, H.-J. Kreowski & G. Rozenberg (Eds.), Proc. Theory andApplication of Graph Transformations, Lecture Notes in ComputerScience, Vol. 1764 (pp. 296-309). Springer.

Heckel, R., Engels, G., Ehrig, H. & Taentzer, G. (1999). Classification andComparison of Module Concepts for Graph Transformation Systems. In H.Ehrig, G. Engels, H.-J. Kreowski & G. Rozenberg (Eds.), Handbook ofGraph Grammars and Computing by Graph Transformation, Vol. 2:Applications, Languages and Tools (pp. 669-689). Singapore: WorldScientific.

Klempien-Hinrichs, R., Knirsch, P. & Kuske, S. (2002). Modeling the Pickup-and-Delivery Problem with Structured Graph Transformation. In H.-J.Kreowski & P. Knirsch (Eds.), Proc. APPLIGRAPH Workshop on AppliedGraph Transformation, Satellite Event of ETAPS 2002 (pp. 119-130).

Kreowski, H.-J. & Kuske, S. (1999a). Graph Transformation Units and Mod-ules. In H. Ehrig, G. Engels, H.-J. Kreowski & G. Rozenberg (Eds.),Handbook of Graph Grammars and Computing by Graph Transforma-tion, Vol. 2: Applications, Languages and Tools (pp. 607-638). Singapore:World Scientific.

Kreowski, H.-J. & Kuske, S. (1999b). Graph transformation units with interleav-ing semantics. Formal Aspects of Computing, 11(6), 690-723.



Kreowski, H.-J., Kuske, S. & Schürr, A. (1997). Nested graph transformationunits. International Journal on Software Engineering and KnowledgeEngineering, 7, 479-502.

Kuske, S. (2000). More about control conditions for transformation units. In H.Ehrig, G. Engels, H.-J. Kreowski & G. Rozenberg (Eds.), Proc. Theoryand Application of Graph Transformations, Lecture Notes in ComputerScience, Vol. 1764 (pp. 323-337). Springer.

Kuske, S. (2001). A Formal Semantics of UML State Machines Based onStructured Graph Transformation. In M. Gogolla & C. Kobryn (Eds.),UML 2001 – The Unified Modeling Language. Modeling Languages,Concepts, and Tools, Lecture Notes in Computer Science, Vol. 2185 (pp.241-256). Springer.

Kuske, S., Gogolla, M., Kollmann, R. & Kreowski, H.-J. (2002). An IntegratedSemantics for UML Class, Object, and State Diagrams based on GraphTransformation. In M. Butler & K. Sere (Eds.), Third Int. ConferenceIntegrated Formal Methods (IFM’02), Lecture Notes in ComputerScience, Vol. 2335 (pp. 11-28). Springer.

Nagl, M. (Ed.) (1996). Building Tightly Integrated SoftwareDevelopment Environments: The IPSEN Approach. Lecture Notes inComputer Science, Vol. 1170. Springer.

Petriu, D.C. & Sun, Y. (2000). Consistent Behaviour Representation in Activityand Sequence Diagrams. In A. Evans, S. Kent & B. Selic (Eds.), Proc.UML 2000 – The Unified Modeling Language. Advancing the Stan-dard, Lecture Notes in Computer Science, Vol. 1939 (pp. 359-368).Springer.

Pratt, T.W. (1971). Pair grammars, graph languages, and string-to-graphtranslations. Journal of Computer and System Sciences, 5(6), 560-595.

Rozenberg, G. (ed.) (1997). Handbook of Graph Grammars and Computing byGraph Transformation, Vol. 1: Foundations. Singapore: World Scientific.

Schürr, A. (1994). Specification of Graph Translators with Triple GraphGrammars. In G. Tinhofer (Ed.), Proceedings of WG’94 20th Int.Workshop on Graph-Theoretic Concepts in Computer Science, Lec-ture Notes in Computer Science, Vol. 903 (pp. 151-163). Springer.

Schürr, A. (1997). Programmed Graph Replacement Systems. In G. Rozenberg(Ed.), Handbook of Graph Grammars and Computing by GraphTransformation, Vol. 1: Foundations (pp. 479-546). Singapore: WorldScientific.

Sleep, R., Plasmeijer R. & van Eekelen, M. (eds.) (1993). Term GraphRewriting: Theory and Practice. New York: John Wiley.

52 Petit and Hacid


Chapter III

From ConceptualDatabase Schemas to

Logical DatabaseTuning

Jean-Marc Petit, Université Clermont-Ferrand 2, France

Mohand-Saïd Hacid, Université Lyon 1, France

Abstract

This chapter revisits conceptual database design and focuses on the so-called “logical database tuning”. We first recall fundamental differencesbetween constructor-oriented models (like extended Entity-Relationshipmodels) and attribute-oriented models (like the relational model). Then, weintroduce an integrated algorithm for translating ER-like conceptualdatabase schemas to relational database schemas. To consider the tuningof such logical databases, we highlight two extreme cases: null-freedatabases and efficient — though non redundant — databases. Finally, wepoint out how SQL workloads could be used a posteriori as a help for thedesigners and/or the database administrators to reach a compromise

From Conceptual Database Schemas to Logical Database Tuning 53


between these extreme cases. While a lot of papers and books have beendevoted for many years to database design, we hope that this chapter willclarify the understanding of database designers when implementing theirdatabases and database administrators when maintaining their databases.

Introduction

Semantic data modeling is the activity of specifying the structure and thesemantics of the data to be managed within an application. Since the 1970s,semantic data modeling has been the subject of a large body of work in severalareas, including databases, information systems, software engineering andknowledge representation. For database design, approaches to data modelingadvocate the use of abstract formalisms, such as the popular Entity Relationshipmodel (Chen, 1976), for describing data, mostly based on the notion of class orentities.

Two main families of semantic data models are addressed in the literature:

• Attribute-oriented models: Data structure is captured through the notionof attributes, i.e., objects and relationships between objects are modeledthanks to attributes. Most of data semantics is expressed by means ofadditional constraints. The relational data model or object-oriented datamodels fall into this family.

• Constructor-oriented models: Data semantics is captured through vari-ous constructors, including attributes but also a constructor for objects andanother one for relationships between objects. A key feature of suchmodels is that most of data semantics is already expressed by theconstructors. Entity-Relationship models (Chen, 1976) fall into this family.

Conceptual data models like ER models provide a high-level abstraction forinformation concerning an application domain. To do so, they rely on manyconstructors, such as relationship-type which is very powerful to capture datasemantics at a high level abstraction. Moreover, such models are widely used inpractice, as advocated by methods of information systems design like MERISE(Moulin, 1976; Tardieu, 1979) or R.U.P. (Rational Unified Process) based onUML (Jacobson, 1999). Most of them have conceptual data models derivedfrom ER models except that the interpretation of relationship cardinalitiessubstantially differs. As an example, a database schema created with oneinterpretation of relationship cardinalities is quite different from the samedatabase schema created with the other interpretation. This point is often left to

54 Petit and Hacid


the reader of many textbooks devoted to databases in general, and databasedesign in particular. However, these differences are often misunderstood bydatabase designers and may lead to practical errors at the implementation stage.Their use requires a thorough knowledge of the theory behind them, though suchknowledge is not required of the average designer.

For tasks like database design, some mappings are necessary to translateconceptual schemas into physical schemas, i.e., schemas which can be pro-cessed by some database management system (DBMS).

Mapping conceptual data models — like ER models (Chen, 1976) — to logicaldata models — like relational data model — has been widely investigated (e.g.,Theorey, 1986; Markowitz, 1992; Mannila, 1994; Fahrner, 1995; Rosenthal,1994). Despite the maturity of this field, we believe these approaches have acommon weakness, for example the lack of an integrated algorithm to performthe translation process whatever the convention used to represent the conceptualdata model, mainly around the interpretation of cardinality constraints onrelationship-types.

However, practitioners may use automated tools to carry out the mappings.Nevertheless, choices made by the tools could be far from the objectives of thedesigner and do not provide any insight into the key issues of such mappings.Furthermore, approaches are either too formal to be used by practitioners(Markowitz, 1992) or very informal so that a great deal of work is left to thepractitioners (Rosenthal, 1994; Fahrner, 1995).

In this chapter, we try to fill in the gap between these two approaches. We makea step toward a unified approach of translating conceptual data schemas torelational logical data schemas in which different kinds of interpretations can bedealt with without any overhead. Our work complements those done byMarkowitz (1992) and Mannila (1994). Due to space limitation, we do notattempt to define the whole process. Rather, we have tried to reach a compro-mise between a formal treatment, e.g., algorithms are given, and a clearunderstanding of the issues of such a mapping, e.g., through a running example.

We also study some classical choices database designers are faced with whenthey want to implement their databases from a logical database schema. Thisstage is a matter of compromises to be reached between getting a null-freedatabase and getting an efficient database. To end up, we argue that logicaldatabase tuning could also be defined a posteriori with respect to SQLworkloads representative of the database activity during some period of time. Itcan be thought of as a help to guide the designer when implementing (if she/hecan predict some SQL workloads) or maintaining her/his database.

The chapter is organized as follows: Notations and background materials aregiven first. Then the chapter gives a mapping from conceptual data models to



logical data models. Next, the chapter discusses strategies for logical databasetuning. The chapter then concludes.

Background

This section is intended to bring to the fore the abstracting power of constructor-oriented data models with respect to attribute-oriented data models as donepreviously by others (e.g., Hull, 1987; Navathe, 1992).

Numerous investigations have been conducted in the data modeling area in orderto seek more appropriate formalisms for accurately representing real-worldapplications. These investigations have resulted in a class of data models calledsemantic data models (Peckham, 1988).

Semantic data models provide constructors for explicitly representing thesemantics of the application. The constructs implement information modelingtools called data abstractions. These abstractions enable a complex world to beexamined in terms of a simplified world that incorporates the most significantpoints. Most importantly, data abstractions provide the basis for a step-wisedesign methodology for databases.

Each data model has its own structuring mechanism from which to buildapplication schemas. In semantic data models this mechanism is in terms ofsemantic structures expressed in some textual language or in graph-theoreticterms.

In such data models, most of the data semantics has to be captured by so-calledconstructors, which are high-level abstraction mechanisms. Two main familiesof semantic data models were addressed:

• With attribute-oriented data models, the main constructor is related to thenotion of attributes. Basically, an attribute associates a meaningful namein the application context with a type, the permitted values. They are usedto describe the characteristics (or properties) of objects of the real-world,but also to describe the relationships between objects.

• With constructor-oriented data models, many constructors are availableto produce a conceptual schema. Among the main constructors, we findagain the notion of attributes, but also an explicit constructor intended tocapture the relationships between objects.

The analysis of the above cited models makes it clear that, although they addressthe same issues, attribute-oriented models seem to be less expressive, or at leastless simple, than the constructor-oriented models.

56 Petit and Hacid


Therefore, when schemas based on constructor-oriented models have to betranslated into schemas based on attribute-oriented models, these later rely onexplicit constraints to accurately capture data semantics conveyed by theformer. For instance, the relational model requires constraints like functionaldependencies and inclusion dependencies to equivalently represent a relation-ship-type of an Entity-Relationship model. So, implicit constraints of construc-tor-oriented models should be encoded, if any, by explicit constraints ofattribute-oriented models.

Now, we introduce an instance of attribute-oriented models (namely therelational model) and an instance of constructor-oriented models based on anextension of the Entity-Relationship model (Chen, 1976).

Relational Data Model

Simplified notations of relational databases used in this chapter are given in thissection (for more details, see, e.g., Mannila, 1994; Levene, 1999; Ramakrishnan,2003).

An attribute A is associated with a domain, the set of its possible values. Arelation schema R is associated with a set of attributes, noted schema(R). Arelation r is defined over a relation schema R and corresponds to a set of tuples,an element of the cartesian product of attribute domains of R. A databaseschema R is a set of relation schemas. A relational database d (or database) overa database schema R corresponds to a set of relations, a relation of d being inone-to-one correspondence with a relation schema of R.

In this chapter, we are interested in two main types of constraints of the relationalmodel: functional dependencies and inclusion dependencies. The formerallows us to specify constraints within a relation schema and the latter allows usto specify constraints between two relation schemas (though possible within onerelation schema). The set of functional dependencies associated with a databaseschema is denoted by F, and the set of inclusion dependencies associated witha database schema is denoted by I. In the sequel, a relational database schemawill be denoted by a triple (R, F, I).

A set of attributes X of a relation schema R is a (minimal) key of R with respectto F if (1) F logically implies X�schema(R) and (2) no subset of X satisfies thisproperty.

Let X and Y be two sets. X+Y (respectively, X-Y) stands for X∪Y (respectively,X\Y) and we omit the brackets for sets reduced to singletons, i.e., the set {A}is denoted by A.



A Conceptual Data Model

An extension of the Entity-Relationship is quickly given in this section. For moredetails, see e.g., Chen (1976) and Ramakrishnan (2003). Recall that ourobjective is to be able to deal with different interpretations of relationshipcardinalities. However, in order to be able to run an example throughout thechapter, we have to select an interpretation. For that, we have chosen UML-likeinterpretation since it seems to be widely accepted at present as a standard. Themodel used in this chapter has the following basic and extended modelingconstructs1:

• Attributes: they are single-valued and are defined with respect to a type,omitted when clear from the context.

• Entity-type: it represents a set of entities (or objects) sharing commonproperties, described by means of attributes. Keys can be specified, i.e.,they are subsets of attributes identifying uniquely every entity.

• Relationship-type: it allows to associate together other entity-types. Wealso allow relationship-types to participate in other relationship-types,sometimes called generalized aggregation. In that case, an arrow is setto know “who associates who”. In the sequel, an object-type will denoteeither an entity-type or a relationship-type. Restrictions may be set tospecify the number of relationships that an object (or a group of objects) canparticipate in. Those restrictions are known as cardinality constraints.

• Generalization/specialization relationships: They define inheritancehierarchy (or is-a-hierarchy) over entity-types. We will say that A is-aB, A being an inherited entity-type. Note that these relationships are aspecial kind of binary relationship-types with a one-to-one constraint.

• We also allow is-a-hierarchy for relationship-types, which does not shareany element with is-a-hierarchy of entity-types. In the sequel, we shall useinherited object-types to denote either inherited entity-types or inheritedrelationship-types.

• Identifying relationships: They allow to define weak entity-types, i.e.,entity-types whose key is made up of both a local key and the key inheritedfrom the identifying relationship. Such relationships may form a hierarchy,called id-hierarchy. We will say that A id B, A being a weak-entity type.Note that this is a special kind of binary relationship-types with a one-to-many constraint.

As a consequence of our notation, an entity-type can be weak, inherited or justan entity-type. In the sequel, we denote by strong entity-types an entity-type

58 Petit and Hacid


which is neither weak nor inherited. We require the existence of a (minimal) keyfor each strong entity-type (It should be noted that we use this requirement hereto simplify the rest of this chapter. In practice, if such a key does not exist, asurrogate key can be defined at the logical level.)

Different Interpretations of Cardinalities

The difference between UML- and Merise-like relationships can be explainedas follows: Let A be a relationship-type defined on E

1, …, E

n and let us consider

that the domain of each Ei is a set of objects. Thus, A ⊆ E

1 x … x E

n. Let m

i be

the cardinality of the role between A and Ei. Let us consider two main cases:

mi =1 and m

i = N.

• mi = 1

• UML-like cardinality: It means that the functional dependencyE

1…E

i-1 E

i+1 … E

n � E

i must hold in every instance of A.

• Merise-like cardinality: It means that Ei � E

1 … E

i-1 E

i+1…E

n must

hold in every instance of A.

• mi = N: Neither UML- nor Merise-like interpretations can be used to define

constraints on E1 x … x E

n.

Graphical notations used to express a schema are not detailed here — they arejust given in our running example.

Example: For the sake of comparison, we borrow our running example from awidely disseminated textbook with only minor changes (Ramakrishnan, 2003).The application deals with the management of projects by employees in acompany organized in several departments. Figure 1 shows the diagram for theapplication example. More details can be found in Ramakrishnan (2003).

In this diagram, we have three strong entity-types (People, Projects,Departments), one inherited entity-type (Employees), one weak entity-type(Dependents) and two relationship-types (monitors, sponsors). Keys areunderlined in the diagram. The one-to-many relationship-type sponsors betweenProjects and Departments has to be read as follows: A department sponsorsone project only, whereas a project could be sponsored by several departments.Note that the relationship-type monitors associates an entity-type (Employees)with a relationship-type (sponsors). Dependents is a weak entity-type: itsidentification is defined by its local key pname and by the key of Employees,which is itself derivable from the key associated with People, i.e., ssn.



Formal approaches exist for describing and reasoning on an extended Entity-Relationship model. The interested reader may refer to Markowitz (1992), Hacid(2001) and Franconi (2000).

Well Formed Conceptual Data Schemas

The intuitive meaning of diagrams used to represent conceptual data schemas isboth a strength and a weakness of such a kind of modeling. Indeed, it should nothide the underlying semantics of each constructor, the risk being to produceschemas which could lead to inconsistencies at the implementation stage.

We identify two main restrictions on conceptual schemas:

• The hierarchy formed by the merging of is-a and id hierarchies isacyclic. This condition requires that each hierarchy (is-a-hierarchy onentity-types, is-a-hierarchy on relationship-types and id-hierarchy) has tobe acyclic, and once merged, the result is acyclic.

• At most one leaving id relationship is allowed from any weak entity-type. Indeed, many problems may arise when their identity can be derivedby at least two different paths with two different keys.

Note that our conditions differ from those given in Mannila (1994), where forexample a weak entity-type may be involved in different paths in the id-

Figure 1. A conceptual schema expressed with our extended ER model

60 Petit and Hacid


hierarchy. Some contributions (e.g., Mannila, 1994; Levene, 1999) consider alsoinherited entity-types as weak entity-types.

From Conceptual Data Schemas toLogical Data Schemas

We rigorously define a mapping which produces highly normalized schemas(stronger than the Boyce-Codd normal form (BCNF)), without null values butmaximizing the length of join paths. Normal forms have been defined to capturesuch kind of database schemas, such as entity-relationship normal form (ERNF)or inclusion dependency normal form (IDNF). Due to space limitation, we willnot develop such issues and we refer to Markowitz (1992), Mannila (1994) andLevene (1999) for more details.

A Classical Framework

From a formal point of view, the translation process involves four steps:

1. Verifying whether the conceptual schema is well formed.

2. Translating the conceptual schema into an oriented graph: doing so, someclassical misconceptions can be rectified and thus a formal treatment canbe carried out.

3. Dealing with attribute naming problems: indeed, assigning names to theattributes in a relational database schema turns out to be a challenging task.

4. Translating the conceptual schema to a logical database schema: often, thewhole process is reduced to this step according to a set of rules.

The first step is certainly the most easy to perform. Note that some toolssupporting both syntactic and semantic checking of a given conceptual schemaexist (e.g., Franconi, 2000). The second step is described in the next section andcould be coupled with the first step: if the graph is acyclic, then the first conditionof a well-formed conceptual schema is reached.

The third step is trickier to achieve. In fact, the intuition is that at the conceptuallevel, attribute names are local, i.e., their scope is delimited by the entity or therelationship-type in which they are defined. This is not true anymore with therelational model at least from a theoretical point of view: an attribute name hasa global scope within a relational database schema and its meaning is related to



the underlying assumption, such that for instance URSA for Universal Rela-tion Schema Assumption (many others do exist). In this setting, this apparentlysimple problem turns out to be technically difficult. In this chapter, we avoid suchproblems by considering that the scope of an attribute is local, i.e., valid onlywithin its relation schema. More details on this issue can be found in Rosenthal(1994) and Mannila (1994).

In the following, we will focus on steps two and four only since we believe theyare crucial for such a mapping.

Using a Graph-Based Representation

From a conceptual schema S, we produce a directed graph G = (V, E) as follows:

• Each entity-type or relationship-type of S becomes a node of V.

• Let A, B be nodes of V. An edge is created in E from A to B, noted(A→B), whenever:

• there exists A is-a B in S,

• there exists A id B in S,

• A is a relationship-type and B participates in A.

Formally speaking, we obtain a multi-graph since more than one edge can bedefined between two nodes. Nevertheless, we do not take advantage of themulti-graph structure. Therefore, we will speak about graph in the sequel.

Example: From our previous example, we derive the oriented graph depicted inFigure 2. We can easily verify that this oriented graph is acyclic.

With such graphs at hand, we shall use in the next subsection the notion ofsuccessor of a node x in V, denoted by successor(x), and defined as follows:

successor(x) = {y∈V∃x1, ..., x

n with x

1 = x, x

n = y and (x

i -> x

i+1)∈E, ∀ i ∈ {1,

n-1}}

Integrated Algorithm

The main algorithm takes advantage of the underlying existing pre-orderbetween object-types of the conceptual schema. We can therefore define apriority for performing the mapping: we first consider the elements of G without

62 Petit and Hacid


successor (except themselves) — they can be processed alone — then weremove those nodes and update the graph accordingly, until no more nodesremain in G. This is the main loop of the Algorithm 1 (line 3).

Figure 2. Directed graph of the conceptual schema of Figure 1

Algorithm MapERtoR Input: S, a well formed conceptual schema N, the notation to be used, i.e., UML or Merise Output: (R, F, I) a relational database schema Begin 1. (R, F, I) = ({},{},{})

Build the directed graph G = (V,E) from S 3. while (V not empty) do X := empty 5. for all x ∈ V such that successor(x)=x do X := X + x 7. case x do : x is an strong entity-type : (R, F, I) += Map_Entity (x) 9. x is an relationship-type : (R, F, I) += Map_Relationship (x) x is an inherited entity-type : (R, F, I) += Map_Inherited(x) 11. x is an weak entity-type : (R, F, I) += Map_Weak (x) end case 13. end for all V := V – X 15. E = E - {(x→y) ∈ Ε | x ∈ X or y ∈ X} end while return (R, F, I) End

Algorithm 1. Main algorithm



The complexity of this algorithm is clearly polynomial in the size of the input. Theterminating condition is ensured whenever the graph G is acyclic, a conditionwhich is met if the conceptual schema S is well-formed.

Example: Continuing our example, three iterations are necessary: The firstiteration gives three candidates {People, Projects, Departments}. Then,these nodes are removed and we get {Employees, sponsors} during thesecond iteration. Finally, it retains only one node {Dependents, monitors}.

At a given iteration, there is no particular order to be taken into account toconsider elements. For instance, the three elements of the first iteration can betreated in any order. Then the Algorithm 1 calls three main procedures, one foreach type of main constructors: Map_Entity, Map_Relationship,Map_Inherited and Map_Derived. They are described below.

Mapping Strong Entity-Types with Map_Entity

The procedure Map_Entity is straightforward since we do not deal with detailsof attribute names assignment. It is worth noting that Map_Entity is the uniqueprocedure which does not add any new attribute during the translation.

Example: Consider the strong entity-type People. A new relation schemaPeople is added to R with schema(People)={ssn,name,tel} and onefunctional dependency People: ssn → name,tel is added to F, since onlyone key is defined over People (see Figure 1).

Algorithm 2. Mapping an entity-type to a relation schema

Algorithm Map_Entity Input: E, a strong entity-type Output: (R, F, I) a relational database schema Begin Create a new relation schema R from E

schema(R) = attributes of E Let K be a key defined on E R = R + {R}; for each key K defined over E do

F = F + {R: K → schema(R)} end for Return (R, F, {}) End

64 Petit and Hacid


Mapping Relationship Types with Map_Relationship

The procedure Map_Relationship deals with relationship-types and handlesboth kind of cardinalities interpretation, referred to as, “US notation” and “EUnotation” in the sequel. To our knowledge, this is the first contribution dealingwith both kinds of constraints in a unified manner. We have seen that attribute-oriented models need additional attributes and constraints to overcome theirintrinsic limitations with respect to constructor oriented-models: this procedureimplements such a kind of mapping, i.e., new attributes and new constraints mustbe added to get a semantically equivalent database schema.

New attributes which are necessary to encode the relationship-type are exactlythose denoted by K (line 2), i.e., they are the keys of the participating object-types. If several keys exist, one is arbitrarily chosen, for instance, the smallestone in the number of attributes. The new attributes and descriptive attributes ofthe relationship-type are added to the relation schema (line 5). Implicit con-straints of the relationship-type are made explicit (lines 6, 8, 11 and 13): Afunctional dependency linking new attributes with descriptive attributes of therelationship-type is added (line 6). Then, each participating object-type leads tothe creation of an inclusion dependency (line 8). If the cardinality constraint isequal to 1 (line 9) for this participating object-type, let say the ith component ofthe relationship-type, a functional dependency is added to the relation schema(line 11 or 13). If one complies with U.S. notation, all components except the ith

Algorithm 3. Mapping a relationship-type to a relation schema

Algorithm Map_Relationship Input: A, a relationship type between O1, …, On Output: (R, F, I) a relational database schema Begin 1. Let R1, …, Rn be the relation schemas created from O1, …, On respectively.

Let Ki be a key of Ri, i ∈ {1, n} and K = K1 + … + Kn 3. Create a new relation schema R from A

R = R + {R} 5. schema(R) = attributes of A + K F = F + {K → schema(R) }; 7. for each Oi participating in relationship-type A do I = I + {R[Ki] ⊆ Ri[Ki] } 9. if cardinality between Oi and A is equal to 1 then if US notation then 11. F = F + {K- Ki → Ki } else 13. F = F + { Ki → K- Ki } end if 15. end if end for 17. return (R, F, I) End



determine the ith component (line 11). Otherwise, the ith component determinesall other components (line 13).

Note that in case of a reflexive relationship-type, there exists Oi and O

j referring

to the same entity-type (line 1). In that case, attribute(s) of one of thecorresponding key (K

i or K

j) must be renamed (line 2).

Example: First recall that the conceptual model used in this chapter complieswith U.S. notation. Now, consider the relationship-type sponsors: A newrelation schema sponsors is added to R with schema(sponsors)={did,pid,since}. Attributes did and pid are new attributes. The func-tional dependency sponsors: did,pid→since is added to F (line 6) andtwo leaving inclusion dependencies are created from sponsors: one toDepartements (sponsors[did] ⊆ Departments[did]) and the otherone to Projects (sponsors[pid] ⊆ Projects[pid]) (line 8). Thecardinality constraint equals to 1 between Projects and sponsors yields to thecreation of a functional dependency sponsors: did→pid (line 11). From thetwo functional dependencies defined over sponsors, did turns out to be a keyand sponsors is trivially in BCNF.

Mapping Inherited Object-Types with Map_Inherited

The procedure Map_Inherited deals with inherited object-types. Since multipleinheritance is allowed, we may have several generalizations for a given inheritedobject-type.

Algorithm 4. Mapping an inherited object-type to a relation schema

Algorithm Map_Inherited Input: E, an inherited object-type derived from O1, …, On i.e. E is-a O1, …, E is-a On Output: (R, F, I) a relational database schema Begin 1. Let R1, …, Rn be the relation schemas created from O1, …, On respectively.

Let Ki be a key of Ri, i ∈ {1, n} and K = K1 + … + Kn 3. Create a new relation schema R from E

R = R + {R} 5. schema(R) = attributes of E + K

for each key K defined over E do F = F + {R: K → schema(R)} end for for each E is-a Oi do 7. I = I + {R[Ki] ⊆ Ri[Ki] } F = F + {Ki → schema(R) } 9. end for

return (R, F, I) End

66 Petit and Hacid


Note that if we have E is-a A, E is-a B, E is-a C, A is-a D and B is-a D, then Ehas two different keys, derived from D and from C.

Example: Consider the inherited entity-type Employees. A new relationschema Employees is added to R with schema(Employees)={ssn,sal,lot}.Only one is-a relationship follows from Employees, so only one inclusiondependency Employees[ssn] ⊆ People[ssn]is created in I. No keys aredefined over Employees and only one key is available from People, so we getone functional dependency Employees: ssn → sal,lot in F.

Mapping Weak Entity-Types with Map_Weak

The procedure Map_Weak deals with weak entity-types. Basically, weakentity-types are a special case of relationship-types and due to restrictionsimposed by well-formed conceptual schemas, a weak entity-type may be derivedfrom only one object-type, which can be an entity-type or a relationship-type.

Example: Consider the weak entity-type Dependents. A new relation schemaDependents is added to R with schema(Dependents) ={ssn,pname,age,cost}, one inclusion dependency Dependents[ssn] ⊆Employees[ssn] and one functional dependency Dependents: ssn,pname→ age,cost are added to I and F, respectively. A unique compound key exists,i.e., {ssn,pname}.

Finally, applying MapERtoR yields the following relational database schema:R={Employees,Projects, Departments, Dependents, monitors,sponsors}. Details are shown in Table 1. Attributes in bold are exactly the

Algorithm 5. Mapping a weak entity-type to a relation schema

Algorithm Map_Derived Input: W, a weak entity-type derived from O Output: (R, F, I) a relational database schema Begin 1. Let S be the relation schema created from O

Let K be a key of S 3. Create a new relation schema R from W

R = R + {R} 5. schema(R) = attributes of W + K

Let LK be the local key of W 7. F = F + {LK + K → schema(R)}

I = I + {R[Ki] ⊆ S[Ki] } 9. return (R, F, I) End



attributes induced by the transformation of a constructor-oriented model to anattribute-oriented model.

Properties of the Translation

Some formal properties can be stated for such kinds of mappings (Markowitz,1992; Rosenthal, 1994; Mannila, 1994). Without going into many details, thedatabase schema obtained after applying the algorithm MapERtoR has thefollowing properties:

• Each relation schema is in BCNF.

• I is made up of key-based inclusion dependencies (their right-hand sidesare keys) and the oriented graph of I (a node corresponds to a relationschema and an edge between R and S corresponds to an elementR[X] ⊆ S[Y] of I) is acyclic.

Table 1. Relational database schema (logical schema)

Relation

schema

Attributes

(schema of)

FD specified within the

relation schema

Leaving IND

People ssn, name, tel ssn → name, tel

key of Employees: ssn

/

Departments did, dname,

budget

did → dname, budget;

key of Departments: did

/

Projects pid, started,

pbudget

pid → started, pbudget

key of Projects: pid

/

Employees ssn, sal, lot ssn → sal, lot

key of Employees: ssn

Employees[ssn] ⊆ People[ssn]

Sponsors did, pid, since did, pid → since

did → pid

key of sponsors : did

sponsors[did] ⊆ Departments[did],

sponsors[pid] ⊆ Projects[pid]

Dependents pname, ssn,

age, cost

ssn, pname → age, cost

key of Dependents:

{ssn,pname}

Dependents[ssn] ⊆ Employees[ssn]

Monitors did, ssn, until did, ssn → until

did → ssn;

key of monitors: did

monitors[did] ⊆ sponsors[did]

monitors[ssn] ⊆ Employees[ssn]

68 Petit and Hacid


• F and I do not interact, i.e., logical implication with F and I can berestricted to logical implication with F or with I.

Other properties can be given on such a mapping such as those related toinformation capacity (e.g., Miller, 1994; Hacid, 2001).

Logical Database Tuning

Once a logical database schema has been generated, a physical databaseschema has to be derived using some DBMS-dependent language. The imple-mentation of a physical database schema by itself is rather straightforward froma logical database schema. Physical database tuning such as definition of blocksize, indexes or clusters is out of the scope of this chapter. Therefore, we focuson de-normalization techniques usually performed at the logical level withrespect to three criteria:

• null values,

• length of join paths, and

• data redundancies, i.e., BCNF.

Then, we will show how SQL workloads can be used to tune the design ofdatabase schemas with respect to SQL accesses performed over the databaseduring some periods of time.

Getting a Null Free Database

Occurrence of null values is quite common in real life databases and is knownto be one of the major difficulties for database programmers when they have towrite SQL queries. In fact, problems raised by null values depend on which kindof attributes they occur:

• On duplicated attributes, i.e., attributes which enable attribute-orientedmodels to simulate constructor-oriented models: null values can be anightmare to compose queries involving joins, specific RDBMS functions,etc.

• On non-duplicated attributes: null values are not very challenging fordesigning SQL queries. Most of the time, null values were missing at theinsertion time of a tuple, but such values are not used anymore to navigate



through the database schema. These attributes are descriptive only: theyare defined within a relation schema and convey part of the information orsemantics of this relation schema.

To get a “null free” database on a duplicate attribute, the logical database schemaobtained from the conceptual schema with the MapERtoR algorithm has to beimplemented as it is, i.e., no transformation (or degradation) has to be performed.However, the price to pay is that the length of join paths is maximized.

Indeed each functional dependency turns out to be a key or a super-key and eachinclusion dependency turns out to be a foreign key, both of them being enforcedto be not null by the RDBMS.

Getting an Efficient Database

In that case, there are two main options:

• Reducing the length of join paths without sacrificing high normal form basedon functional dependencies such as BCNF or third normal form (3NF).

• Reducing the length of join paths by introducing data redundancy (2NF,1NF).

Denormalisation without Data Integrity Problems

To be compliant with the first option, a very well known transformation can bedone: instead of creating a new relation schema for each one-to-many or one-to-one binary relationship-type, it consists of migrating attributes of the relation-ship-type (if any) and a foreign key into the entity-type (or relationship-type) thatparticipates with the cardinality constraint equals to one.

Example: From our example, if we follow the previous transformation, we getthe logical database design given in Table 2. Note that the number of relationschemas and inclusion dependencies decreases at the price of null values on thethree duplicate attributes: pid and ssn into Departments and ssn intoDependents.

Consider the one-to-many relationship-type sponsors. It has been merged intothe relation schema Departments, its own attributes being now part of theschema of Departments. To show an example (not very realistic here) of theimpact of such a denormalization on the number of null values, let’s assume wehave 10,000 departments of which only 100 participate in the relationship-type

70 Petit and Hacid


sponsors. In that case, 99% of tuples of Departements get null values on theduplicated attribute pid, and less importantly, on attribute since. Such kind ofproblems never append with database schema produced by the algorithmMapERtoR.

To sum up, such kind of logical database schema is often chosen to producephysical database schemas, its main advantage being to minimize the length ofjoin paths, and thus to be rather efficient. The often misunderstood problem ofsuch schemas concerns the number of null values which can be generated oncethe database is operational. For database designers, it might not be an importantissue at database design time, but that could become a nightmare for databaseprogrammers who have to devise SQL queries in presence of null values onduplicated attributes.

Denormalisation with Data Integrity Problems

From Table 2, we may be tempted to go a step beyond in order to avoid costlyjoins. In that case, data integrity problems will inevitably occur.

Example: Consider the merging of Dependents and Employees intoEmployees. In that case, we have schema(Employees)={ssn, name,lot, tel, sal, pname, age, cost}, the inclusion dependencyDependents[ssn] ⊆ Employees[ssn] being removed. Two functionaldependencies need to be defined over Employees, namely ssn,pname →age,cost and ssn → name,lot,tel,sal.

Table 2. Another relational database schema (logical schema)

Relation

schema

Attributes

(schema of)

Keys

Leaving IND

Employees ssn, name,

lot, tel, sal

ssn

/

Projects pid, started,

pbudget

pid

/

Departments did, dname,

budget, pid,

since, ssn,

until

did Departments[pid] ⊆ Projects[pid]

Departments[ssn] ⊆ Employees[ssn]

Dependents pname, ssn,

age, cost

{ssn,pname} Dependents[ssn] ⊆ Employees[ssn]



The only key is made up of two attributes, i.e., ssn,pname. As a consequence,this schema is only in first normal form since the left-hand side of the secondfunctional dependency is strictly included in a key.

How to Reach a Compromise?

Clearly, a compromise has to be reached between the two opposite goals. In thespirit of (Ramakrishnan, 2003), we argue that a good design cannot be obtainedat database design time: too many parameters have to be taken into account atan early stage of the design, specifically those related to application programsaccessing the database.

Nevertheless, an optimal design could be defined and obtained with respect tothe database accesses as given by SQL workloads. We argue that SQLworkloads could be used to tune the database design of operational databasessince they offer a nice setting in which logical database tuning can be treatedobjectively — with respect to SQL workloads — instead of subjectively — withrespect to the database designer expertise.

Gathering SQL Workloads

SQL workloads represent a set of SQL accesses performed over the databaseduring some periods of time. They should be representative of the databaseactivity, either Select From Where SQL queries or update SQL queries (insert/delete/update). Recently, SQL workloads can be easily gathered from opera-tional databases by means of advanced functions available on top of majorRDBMS products: a representative workload can be generated by loggingactivity on the server and filtering the events we want to monitor (Agrawal,2001).

Using SQL Statements to Tune the Logical DatabaseDesign

The key idea is to tune the design with respect to three main goals: minimizingthe occurrence of null values, maximizing both the efficiency of cost-sensitiveSQL queries performed against the database and data integrity of the database.

Example: Assume that SQL workloads reveal that cost-sensitive SQL queriesoccur in a majority of cases between Departments and Projects. In that

72 Petit and Hacid


case, the logical database schema given in Table 1 could be transformed (ordenormalized) only with respect to the length of join paths implied by SQLworkloads, i.e., the relation schema sponsors could be merged into Depart-ments, the rest of the logical schema remaining unchanged, up to sometransformations of the set of inclusion dependencies.

The idea of tuning database parameters at the physical or logical level is not new.For instance, they are proven to be useful in many database applications such asphysical database tuning, e.g., automatic index definition (Agrawal, 2001),logical database tuning (Lopes, 2002) or materialized view selections in a datawarehouse (Agrawal, 2001).

Conclusions

Relational database technology and semantic data modeling have been two majorareas of database research in recent decades. Relational database technologyis based on solid theoretical foundations, and it is understood what constitutes awell-designed relational database schema. Semantic modeling, on the otherhand, provides a rich set of data abstraction primitives which can captureadditional semantics of the application in the database schema. Until recently,relational database technology and semantic modeling have evolved almostseparately. There is a need for establishing and understanding connectionsbetween semantic models and the relational model. This chapter is an attempt toinvestigate this connection. We tackled this problem by restricting the class ofdata dependencies to functional dependencies and inclusion dependencies. Theresults of our work are directed toward the understanding of the properties ofrelational translations of (extended) ER schemas.

We clarified two main steps in such a translation: (1) the order of the translationof entity and relationship-types and (2) the translation of cardinalities forrelationship-types, whatever the convention chosen to interpret these cardinali-ties (for example, UML class diagrams or conceptual data schemas of Merise).These considerations are simple though very important in practice. Between thedesire to get efficient databases for end-users and the desire to get null-freedatabases on duplicated attributes for database programmers, we have pointedout how SQL workloads could be used to reach a compromise among contradic-tory objectives.



References

Agrawal, S., Chaudhuri, S. & Narasayya, V.R. (2001). Materialized View andIndex Selection Tool for Microsoft SQL Server 2000, ACM SIGMOD2001, California, May 21-24.

Chen, P. (1976). The Entity-Relationship Model - Toward a Unified View ofData. ACM TODS, 1(1), 9-36.

Fahrner, C. & Vossen, G. (1995). A Survey of Database Design Transforma-tions Based on the Entity-Relationship Model. DKE, 15, 213-250.

Franconi, E. & Ng, G. (2000). The i.com tool for Intelligent ConceptualModeling. Proceedings of the Seventh International Workshop onKnowledge Representation Meets Databases (KRDB 2000), Berlin,Germany, 2000 (pp. 45-53).

Hacid, M.S., Petit, J.M. & Toumani, F. (2001). Representing and reasoning ondatabase conceptual schemas. Knowledge and Information Systems,3(1), 52-80.

Hull, R. & King, R. (1987). Semantic Database Modelling: Survey, Applications,and Research Issues. ACM Computing Surveys, 19(3), 201-260.

Jacobson, I., Booch, G. & Rumbaugh, J.E. (1999). Excerpt from “The UnifiedSoftware Development Process”: The Unified Process. IEEE Software,16(3), 82-90.

Levene, M. & Loizou, G. (1999). A Guided Tour of Relational Databases andBeyond. Springer.

Lopes, S., Petit, J.M. & Toumani, F. (2002). Discovering interesting inclusiondependencies: Application to logical database tuning. Information Sys-tems, 27(1), 1-19.

Mannila, H. & Räihä, K.J. (1994). The Design of Relational Databases (2nded.). Addison-Wesley.

Markowitz, V. & Shoshani, A. (1992). Representing Extended Entity-Relation-ship Structures in Relational Databases: A Modular Approach. ACMTODS, 17(3), 423-464.

Miller, R.J., Ioannidis, Y.E. & Ramakrishnan, R. (1994). Schema equivalencein heterogeneous systems: Bridging theory and practice. InformationSystems, 19(1), 3-31.

Moulin, P., Randon, J., Teboul, M., Savoysky, S., Spaccapietra, S. & Tardieu, H.(1976). Conceptual Model as a Data Base Design Tool. Proceeding of theIFIP Working Conference on Modelling in Data Base Management Sys-tems. In G. M. Nijssen (Ed.), Modelling in Data Base Management

74 Petit and Hacid


Systems, Freudenstadt, Germany, January 5-8, 1976 (pp. 221-238). North-Holland.

Navathe, S. (1992). Evolution of data modeling for databases. Communicationsof the ACM, 35(9), 112-123.

Peckham, J. & Maryanski, F. (1988). Semantic data models. ACM ComputingSurveys, 20(3), 153-189.

Ramakrishnan, R. & Gehrke, J. (2003). Database Management Systems (3rded.). McGraw-Hill.

Rosenthal, A. & Reiner, D.S. (1994). Tools and Transformations - Rigorous andOtherwise - for Practical Database Design. ACM TODS, 19(2), 167-211.

Tardieu, H., Pascot, D., Nanci, D. & Heckroth, H. (1979). A Method, aFormalism and Tools for Database Design - Three Years of Experi-mental Practice. ER 1979: 353-378.

Teorey, T., Dongqing, Y. & Fry, J. (1986). A Logical Design Methodology forRelational Databases Using the Extended Entity-Relationship Model. ACMComputing Surveys, 18(2), 197-222.

Endnote

1 Other extensions could have been integrated into our ER model such asmulti-valued attributes or composite attributes. In order to ease thepresentation of the mapping, they are not taken into account in this chapterbut could be integrated into our framework without any major difficulty.

Transformation Based XML Query Optimization 75


Chapter IV

Transformation BasedXML QueryOptimization

Dunren Che, Southern Illinois University, USA

Abstract

This chapter addresses the fundamental issues of XML query optimization– equivalences and transformation rules. Equivalences are typically usedas the basis to pursue transformation-based query optimization in traditionaldatabase systems. In this chapter, we develop the conception of equivalencesin the context of XML database and XML query optimization. We thenpropose to derive deterministic transformation rules by incorporatinggeneral and XML-specific optimization heuristics to achieve highoptimization efficiency for XML queries. We hope the work presented in thischapter will set a preliminary foundation or framework for further in-depthinvestigation for transformation-based XML query optimization.

76 Che


Introduction

With the advent of the Internet and World Wide Web (WWW), the repositoriesof SGML (Standard Generalized Markup Language) compliant structureddocuments have been fast mounting up. XML (Extensible Markup Language),as the new proposal of W3C (World Wide Web Consortium) for standard, ishurriedly getting the dominance of representing data in the Web and elsewhere.Therefore, commensurate management technology, including efficient queryprocessing and optimization for XML data is specially needed. It has beencommonly recognized that structured documents in general and SGML/XMLdocuments in particular should benefit from the same type of database manage-ment functionality as offered to traditional data. This requires the storage of thedocuments within a database (which we call a structured-document database)and management of these documents by a database management system(DBMS). Within the context of this chapter, structured documents refer todocuments according to the SGML/XML/HTML standards (Cover, 2002).Efficient processing and execution of declarative queries over structured-document databases are an essential issue for structured-document databasemanagement systems. This issue, however, has not been adequately studied.

Structured-document query optimization is fundamentally different from classi-cal query optimization in two aspects. First, because of the high complexity of theintrinsic data model behind XML data, the search space for query optimizationis much larger, which means the efficiency of traditional optimization approacheswill degrade unacceptably when applied to XML data. In other words, we haveto work out a much more progressive way of pruning the search space to achieveacceptable performance. Second, the structure of XML documents, which canbe interrogated in an XML query and is normally implied in the DTD or XMLschema of the documents, provides opportunities for efficient semantic queryoptimization, which shall be effectively exploited to achieve better optimizationefficiency for XML queries.

This chapter addresses the optimization issue of structured-document queries ina database environment. Considering the dominance that XML has alreadygained, our discussion is focused on XML-compliant documents, which are moregenerally referred to as XML data. The query optimization strategy we presenthere is transformation-based. The optimization of a query is accomplishedthrough a series of equivalent transformations applied to the query. Transforma-tion rules in our system are all derived from the equivalences that we identifiedin the specific context of XML document queries. The main theme of this chapteris XML-document specific equivalences and the transformation rules derived forXML query optimization.



The remainder of this chapter is organized as follows: the chapter first gives abrief review of related work. Next, it provides the preliminaries needed for thesubsequent discussion of this chapter. The chapter then addresses selectedequivalences that we have identified and used in our test bed. This is followedby a section that discusses the intended application of our equivalences, i.e.,deterministic transformations for XML query optimization, followed by anoptimization example. The chapter then concludes with a summary of thediscussion of this chapter and indicates future directions.

Related Work

Since SGML/XML entered the arena of database technology, a lot of work hasbeen done on the various aspects related to XML data management, e.g.,structured-document data modeling (Abiteboul, 1997; Özsu, 1997; Navarro,1997; Lee, 1997; Yan, 1994; Conse, 1994; Chaudhuri, 1996; Morishima, 1997;Gonnet, 1992; Fernadez, 2000; Florescu, 1999; Shanmugasundaram, 1999;Bohannon, 2002; Klettke, 2000), XML document indexing (Chan, 2002; Grust,2002; Li, 2001; Milo, 1999), and advanced algorithms for fast query processing(Fernandez, 1998; McHugh, 1997; Gottlob, 2002; Li, 2001; Guha, 2002; Chien,2002; Srivastava, 2002).

As structured-documents are essentially semistructured, the work done onsemistructured data management (e.g., Deutsch, 1999; McHugh, 1997) actuallyaddresses similar issues as structured-document management. Lore (McHugh,1997, 1999), a DBMS designed for semistructured data and later migrated toXML, has a fully-implemented cost-based query optimizer that transforms aquery into a logical query plan, and then explores the (exponential) space ofpossible physical plans looking for the one with the least estimated cost. Lore iswell known by its DataGuide path index that together with stored statisticsdescribing the “shape” of the database provides the structure knowledge aboutthe data to help Lore’s optimizer prune its search space for a better plan. In thissense, Lore is related to our work, but we capture the structure knowledge ofdocument data mainly from the DTDs and apply this knowledge on conductingexclusively deterministic transformations on query expressions.

In the work of Fernandez (1998), a comparable strategy for exploiting a grammarspecification for optimizing queries on semistructured data is discussed, whereeffort is made to make complete use of the available grammar for expanding agiven query. Our focus is different. We identify transformations that introduceimprovements on query expressions in a very goal-oriented manner.

78 Che


The work of Consens and Milo (1994) also exploits the document type definitionknowledge for query optimization. They replace a query algebra operator witha cheaper one whenever the DTD allows. However, the DTDs considered intheir study are simpler than the ones of SGML/XML, and the authors do notconsider different grammar constructors.

Our work is innovative in systematically addressing the query optimization issuefor structured documents through algebraic transformations. Our approachexploits the structure knowledge implied by the DTD and other heuristics toconduct strongly goal-driven, deterministic and thus highly efficient transforma-tions on query expressions for optimization.

Preliminaries

In this chapter, we are interested in structured documents that follow the SGML/XML standards (Cover, 2002). Our optimization techniques perform algebraictransformations on query expressions based on the PAT algebra (Salminen,1994). The main theme of this work is to exploit the structure knowledge aboutthe documents, which is usually characterized by the DTD or XML schema ofthe documents. The structure knowledge is used to conduct profitable transfor-mations on query expressions for optimization. In this section we first introducea few DTD-related notions that are important for the subsequent discussion ofthis chapter, followed by the PAT algebra, which forms the basis of querytransformations in our work.

DTD-Related Notions

XML, derived from SGML, is a markup language that identifies components ofstructured documents by means of “tags”. For a given class of documents, thelegal markup tags are defined in the DTD or the XML schema of the documents.XML schema was proposed to be an alternative to DTD for defining documentelement types and is currently used in parallel with DTD. Subsequent discussionin this chapter is based on the DTD notion, but the techniques we discuss applylikewise to documents using XML schemas.

A DTD is the grammar for a class of documents. The figurative representationof this grammar is a DTD graph, which is a useful concept and is formallydefined in the following text.



Definition 1 (DTD graph). The DTD graph of a specific DTD is a directedgraph G = (V,E). Its vertices in V are the names of the element types fromthe DTD, and each element type name occurs only once. An edge (ET

i,ET

j)

in E indicates that ETj occurs in the content model of ETi. RT ∈ V is the rootelement type of the DTD.

Figure 1 is an illustration of a fragment of the DTD graph for conferenceproceedings. By means of a DTD graph, we can visualize some importantrelationships induced by the DTD, such as the containment relationships amongdocument elements, which is defined next.

Definition 2 (Directly-contains/Directly-contained-in). Element type ETidirectly-contains element type ETj if there exists an edge (ET

i,ET

j) in the

DTD graph G. Conversely, ETj is directly-contained-in ETi. ETi is referredto as an external type, and ETj an internal type with regard to thecontainment relationship.

The transitive closure of directly-contains (or directly-contained-in) reflectsthe generalized situation, which is usually referred to as contains (or contained-in).

Definition 3 (Path in DTD graph). A path in a DTD graph G, is a sequenceof element types (ET

i, ... , ET

j) s.t. ET

k directly contains ET

k+1, i ≤ k < j.

Figure 1. Fragment of a sample DTD graph for conference proceedings

80 Che


It is obvious that the edge and path concepts in a DTD graph are the graphiccounterparts of directly-contains/contained-in and contains/contained-inrelationships among element types of the DTD. Literally, the term “a path fromET1 to ET2” is different from “a path between ET1 and ET2”. The latter doesnot concern the direction of the path. Path and edge are important concepts forthe identification of relevant structural properties of documents for semanticquery optimization, which we discuss in subsequent sections.

Notice that the above notions are defined at the type level of documentcomponents, but imply structural relationships at the instance level. As long asDTDs are available, we rely on DTDs to extract the structure knowledge ofdocuments, otherwise we need to obtain this useful structure knowledge forquery optimization by means of a document parser.

In addition to the above notions, further notions regarding the properties of thestructural relationships among document components are defined and used forderiving the core transformation equivalences for query optimization.

PAT Algebra

The PAT algebra (Salminen, 1994) was designed as algebra for searchingstructured documents. We adopted the PAT algebra and extended it accordingto the features of SGML/XML compliant documents. The PAT algebra is setoriented, in the sense that each PAT algebraic operator and each PATexpression evaluate to a set of elements. Herein, we present a restricted versionof it to serve the purpose of this chapter.

A PAT expression is generated according to the following grammar:

E ::= etn | E1∪E2 | E1∩E2 | E1 – E2 | σr(E) | σ

A,r(E) | E1⊂E2 | E1⊃E2 | (E)

“E” (as well “E1” and “E2”) generally stands for a PAT expression, etnintroduces a document element type’s name, “r” is a regular expressionrepresenting a matching condition on the textual content of the documentelements, and “A” designates an attribute of the elements.

∪, ∩ and – are the standard set operators, union, intersection and difference.The two operands of a set operator have to be type-compatible, i.e., returning thesame type of elements.

σr(E) takes a set of elements and returns those whose content matches the

regular expression r, whileσA,r

(E) takes a set of elements and returns thosewhose value of attribute A matches the regular expression r. Operator ⊂ returns



all elements of the first argument that are contained in an element of the secondargument, while ⊃ returns all elements of the first argument that contain anelement of the second argument.

In the subsequent discussion, we use ext(E) and τ(E) as shorthands to denote theelement extent determined by the expression E after evaluation and the resulttype of the elements in ext(E), respectively.

Following is a query example formulated according to the PAT algebra withregard to the DTD shown in Figure 1:

Query example. Find all the paragraphs containing both “xpath” and “xlink” inany article.

( (σr=“xpath”

(Paragraph) ⊂ Article) ∩ (σr=“xlink”

(Paragraph) ⊂ Article) )

Structured-Document Indices

We consider three types of index structures in the context of structured-document databases: element content indices, attribute value indices, andstructure indices.

Content indexing has been extensively exploited in information retrieval (IR)systems. Attribute indexing corresponds to the classical type of indexing pursuedin conventional DBMSs. Structure indexing is specific to structured-docu-ments. It is similar to path indexing (Bertino, 1994) studied in object-orienteddatabases. However, in our case the indexing mechanism needs to consider thecontainment relationship between the relating elements.

When the containment relationship between the elements of two differentelement types is expected to be frequently taken as a criterion for querying thedocument database, a structure index between the two element types isfavorably built. Structure indices may be defined either from an external typeto an internal type or vice versa, corresponding to the “contains” and “contained-in” relationships, respectively. To serve the purpose of this chapter, it sufficesto indicate that a structure index is simply defined as a map between the elementsof the two types related via the containment relationship. We introduce anadditional PAT operator, Iτ(E1)

(E2), to indicate the application of a structure indexwhich is defined between the two types, τ(E1) and τ(E2), with the subscript“τ(E1)” showing the return type of the index operation. This index operator willbe used in relevant equivalences and transformation rules.

82 Che


Equivalences for Document QueryOptimization

Our approach to XML query optimization is based on equivalent transformationsapplied to the queries represented as PAT algebraic expressions. Equivalencesare the laws in our approach, based on which we derive the transformation rulesto accomplish query optimization. In this section, we elaborate on the equiva-lence issue in the context of XML queries.

There are potentially four types of equivalences:

• Equivalences derived from general set-theoretic properties of the PAToperators.

• Equivalences derived from the constraints imposed by the DTD of thedocuments.

• Equivalences derived from particular structural properties of the docu-ment.

• Equivalences that explore opportunities of applying potential indices.

Considering that the number of the PAT algebraic operators and the complexityof their potential interactions are rather high, we also apply certain criteria in theselection of the equivalences to restrict their number. Otherwise, we wouldobtain an unmanageably large set of potential transformations. The criteria weobserve are as follows:

• Equivalence must have the potential to imply a profitable transformation.

• Equivalence must not imply transformations to further complicate orexpand the query expressions.

• Equivalences must not require complex conditions to be checked.

• Equivalences must not target at merely generating alternative expressions.

In our study, equivalences take the form “E1 →←c E2,” meaning E2 is equivalentto E1 under condition c; when the condition c is omitted, the correspondingequivalence holds unconditionally. Furthermore, we introduce the followingshorthand notations:

• “ ∩∪ ”: stands for the set operator ∪ and/or ∩.

• “σR”: acts for the selection operator σ

r and/or σ

A,r.

• “ ⊂⊃ ”: represents the containment operator ⊃ and/or ⊂.



Set-Oriented Equivalences

Set-oriented equivalences are based on the set-theoretic properties of the PAToperators. We identified 31 generic equivalences in Che (2003). Due to lack ofspace, we present only a few of them below:

Subset laws (� stands for any subset of ext(E))

ε1. � – E ←→ φ

ε2. � ⊂⊃ E ←→ �

‘–’ specific laws

ε3. ((E1 – E2) – E2) ←→ (E1 – E2)

ε4. ((E1 – E2)∪E2) ←→ (E1∪E2)

Commutativity

ε5. E1∪E2 ←→ E2∪E1

ε6. (E1 ⊂⊃ E2) ⊂

⊃ E3 ←→ (E1 ⊂⊃ E3) ⊂

⊃ E2

Distributivity

ε7. E1∩(E2∪E3) ←→ (E1∩E2)∪(E1∩E3)

ε8. E1 – (E2∪E3) ←→ (E1 – E2) – E3

Associativity

ε9. (E1 ⊂⊃ E2) ⊂

⊃ E3 →←c E1 ⊂⊃ (E2 ⊂

⊃ E3)

if τ(E2) contains/is contained in τ(E3)

The “subset laws” are useful for simplification of query expressions involving asubset relationship. The proof of the above equivalences is straightforwardexcept for the commutativity and associativity rules. In the following, as anexample, we give the proof of the commutativity law, ε 6, with regard to only the⊂ operator.

Proof. (the ⊂ commutativity)

(E1⊂E2)⊂E3

= {e1∈ext(E1⊂E2) | ∃e3∈ext(E3) s.t. e1 is contained in e3}

= {e1∈ext(E1) | ∃e2∈ext(E2) s.t. e1 is contained in e2 and ∃e3∈ext(E3)s.t. e1 is contained in e3}

= {e1∈ext(E1⊂E3) | ∃e2∈ext(E2) s.t. e1 is contained in e2}

= (E1⊂E3)⊂E2

84 Che


Equivalences Based on DTD Constraints

This type of equivalences is based on checking whether a single operator of thePAT algebra is consistent with the given DTD. A single operand can be eitheratomic, i.e., an element type name, or any of the operators, σ

A,r, σ

r(E), ⊂ or ⊃.

Following is an example of such equivalences:

ε10. σA,r

(E) ←→ φ if ‘A’ is not an attribute of τ(E)

Note that more complicated equivalences reducing expressions to an empty setexist, but need to take more than just one operator into account for deducing anempty result, thus are precluded from our consideration according to our ruleselection criteria mentioned before.

Equivalences Based on Properties of DTD Structure

Although we have ruled out in the previous section the situations wherecomplicated exploitation of the DTD knowledge is needed, there are particularlyinteresting situations that the DTD structure can be used most profitably toachieve query optimization. We show a few of such special cases and presentthe corresponding equivalences in this subsection.

First, we introduce the notions of exclusivity, obligation, and entrance loca-tions.

In a given DTD, some types may be shared among others. For example, theelement type Authors shown in Figure 1 is contained in element type Article andin ShortPaper. But the types that are not shared, i.e., exclusively contained-inanother type, bear potential for query optimization.

Definition 4 (Exclusivity). Element type ETj is exclusively contained in

element type ETi if each path (e

j,...,e

k) with e

j being an element of type ET

j

and ek being the document root contains an element of type ET

i.

We say an expression, E, is free of restriction on its extent, denoted as free(E),if the expression evaluates to the full extent of type τ(E). One typical case thatthe free(E) condition holds is when E is a plain element-type name etn. The freePAT expression notion often serves as a necessary condition to make anequivalence hold. The following equivalence comes from the exclusivity and thefree of restriction notions.



ε11. E1⊂E2 ←→ E1 if τ(E1) is exclusively contained in τ(E2) andfree(E2) holds

If τ(E1) is exclusively contained in τ(E2), an element e1 of the internal type τ(E1)

must be contained in an element e2 of type τ(E2). Furthermore, free(E2) renders

E2 to return the full extent of τ(E2). Therefore, the containment relationship inthe above equivalence imposes no condition on the elements of E1, and thus theequivalence holds.

It is easy to conclude from the operators’ definitions that the expression“E1⊂E2” and “E1⊃E2” are not equivalent, thus the exclusivity notion is notappropriate to transform queries involving subexpressions of the second form,and we need to introduce the counterpart of exclusivity, obligation, for thispurpose.

Definition 5 (Obligation). Element type ETi obligatorily contains element

type ETj if each element of type ET

i in any document complying with the DTD

has to contain an element of type ETj.

The concept of obligation gives rise to the following equivalence:

ε12. E1⊃E2 ←→ E1 if τ(E1) obligatorily contains τ(E2) and free(E2)

If two element types are not related by exclusivity and obligation, it may beworthwhile to check whether a third element type, called entrance location,exists that could render us opportunities for applying a potential structure indexor shortening the navigation path needed for evaluating an involved containmentoperation.

Definition 6 (Entrance location). Element type EL is an entrance locationfor τ(E1) and τ(E2) of a given DTD if in any document complying with theDTD, all paths from an element e1 of τ(E1) to an element e2 of τ(E2) passthrough an element el of τ(EL).

The notion of entrance location gives rise to the following equivalence:

ε13. E1⊂E2 ←→ E1⊂(E3⊂E2) if τ(E3) is an entrance location forτ(E1) and τ(E2), and free(E3) holds.

86 Che


The correctness of this equivalence trivially follows from the entrance locationdefinition. The equivalence corresponding to the ⊃ operation can be defined likewise.

In general, the adding of an additional element type, as introduced by an entrancelocation, to a PAT expression is detrimental to the evaluation efficiency of thequery. Therefore, the leftward application of these equivalences is obviouslyfavorable, while the left to right-side transformation will only be applied undercertain special conditions to ensure final, obvious improvements on the queryexpressions, e.g., to enable application of a structure index. We will show thisby the following transformation rule that combines exclusivity and entrancelocation:

ε14. E1⊂E2 ←→ E1⊂E3 if τ(E3) is an entrance location for τ(E1)and τ(E2), τ(E3) is exclusively contained in τ(E2), and free(E2) andfree(E3) holds.

The correctness of this equivalence becomes evident when the omitted interme-diate term, E1⊂(E3⊂E2), is added.

Analogously, the equivalence that combines obligation and entrance locationcan be defined, but omitted herein.

Equivalences Applying Structure Indices

Using the index operation introduced in Section 3, the equivalence exploitingstructure indexes is given below:

ε15. E1 ⊂⊃ E2 ←→ Iτ(E1)

(E2)∩E1 if a structure index between τ(E1)and τ(E2) is available.

When free(E1) additionally holds, Iτ(E1)(E2) is subset of ext(τ(E1)), and the

intersection is thus redundant and can be omitted.

Application of Equivalences

We envision two types of applications of our equivalences. One typical way isto directly apply the equivalences on query expressions for generating more



alternatives for each input query expression, and then according to a certaincriterion, e.g., cost comparison, choose the one with the cheapest cost. Thesecond way is to conduct only beneficial transformations on query expressionstoward the goal of optimization, which is usually achieved with resort toheuristics.

The strategy adopted in our work is strongly heuristics-based as it applies onlydeterministic transformations on query expressions for optimization. Here, thedeterminism consists in: (1) all transformation rules are unidirectional, ofwhich each obtains determinate improvement on its input queries, (2) once a newtransformation is performed, the previous candidate (i.e., the input expression tothe transformation rule) is immediately discarded. The whole optimizationprocess conducted according to this strategy is a linear, deterministic process,which step-wise improves on an input query and leads to the unique, final, optimalalternative of the input query. Query optimization thus accomplished is highlyefficient because of the determinism nature.

Control Strategy

In our system, all the performed transformations are required to lead to step-by-step improvements on an input query expression until a final expression isreached. Examples of significant improvements may be a potential structureindex being introduced or the input query expression being completely rewrittento be more evaluation-efficient. In both cases, equivalent transformations areperformed according to XML-specific semantics at the PAT algebra level. Sothe key transformations pursued in our system are heuristics-based semantictransformations, which are usually conducted more efficiently by starting froma carefully chosen standard format. In our system, this standard format isachieved via a normalization step, called normalization phase, which alsocarries out necessary simplification on input query expressions. The secondphase is, of course, the semantic optimization phase. During semantic transfor-mation, in order to introduce a major improvement into an expression, elementnames may be substituted and the newly introduced element names may haveredundancy with other parts of the expression. Therefore, a final cleaning-upor simplification phase is employed.

In the following, we present sample transformation rules (Che, 2003), and thenshow an optimization example using these rules.

Transformation rules are derived from the more general equivalences. Trans-formation rules are unidirectional and take the form “(E1)⇒(E2)”. An addi-tional precondition may be added to some rules to determine the applicability ofthe rule to a specific input expression.

88 Che


Transformation Rules

Transformation rules are organized into three consecutive phases: normaliza-tion, semantics optimization, and simplification.

Normalization Rules

Query normalization covers three aspects: DTD-constraint based simplification(like R1), operator reordering (like R2 - R5), and a bottom-up simplification (likeR6 - R7). Following are a few of such rules chosen from our rule set (Che, 2003):

R1. (E1⊂E2) ⇒ φ if τ(E2) doesn’t contain τ(E1)

R2. (σR(E1)∩E2) ⇒(σ

R(E1∩E2))

R3. (E1∩σR(E2))⇒(σ

R(E1∩E2))

R4. (E1 ⊂⊃ E2)∩E3⇒(E1∩E3) ⊂

⊃ E2

R5. E1∩(E2 ⊂⊃ E3)⇒(E1∩E2) ⊂

⊃ E3

R6. (E∩E)⇒(E)

R7. ((E1 ⊂⊃ E2) ⊂

⊃ E2)⇒(E1 ⊂⊃ E2)

Instead of giving a proof, we provide brief explanations of the above rules. R1

directly comes from the DTD constraint used. As ⊂⊃ operations restrict the first

argument’s extent by imposing a containment relationship with the elements of

the second argument, we may simply consider ⊂⊃ operations as a special kind

of selections. In this sense, R2 through R5 are communications of the intersectionwith a selection operation; their correctness is self-evident. R6 is yet anotherbasic law of the set theory. R7 is to delete redundant restriction imposed by thecontainment relationship with the same argument.

Semantic Rules

Semantic rules are developed with the predominant goal: to enable the exploita-tion of structure indices during optimization, which in most cases is not readilyachievable, rather, relies on deep exploration of DTD knowledge such asobligation, exclusivity, and entrance location.



Numerous cases have been identified for introducing structure indices into aquery (Che, 2003). The simplest case is to directly use an available structureindex between the two element types involved in a query:

R8. E1 ⊂⊃ E2⇒Iτ(E1)

(E2)∩E1 if a structure index between τ(E1) andτ(E2) is available

Iτ(E1)(E2) denotes a structure index operation defined between τ(E1) and τ(E2),

where the subscript τ(E1) indicates the result type of the operation.

This rule is based on the index substitution equivalence, ε15, to interpolate theindex operation into a query expression.

The second case is designed to reveal the applicability of a potential structureindex that is not directly available. The corresponding rule combines thecommutativity and associativity laws into a single transformation:

R9. (E1 ⊂⊃ (E2 ⊂

⊃ E3))⇒((Iτ(E1)(E3)∩E1) ⊂

⊃ E2) if a structure indexbetween τ(E1) and τ(E3) is available.

If applying indices into a query is not feasible, a less favorable opportunity —reducing the length of the traversal needed into the document’s structure — isexplored.

Simplification Rules

The third phase reapplies most of the simplification rules of Phase 1, andintroduces additional rules such as R10 to simplify new subexpressions pertain-ing to the index operator Iτ(E1)

.

R 10. (Iτ(E1)(E2)∩σ

R(E1))⇒σ

R(Iτ(E1)

(E2)) if free(E1) holds.

An Optimization Example

Now, we present the transformations performed on the example query given inthe earlier part of the chapter to show how our deterministic transformation ideaworks.

90 Che


Transformation Example

The query retrieves all the paragraphs containing both “xpath” and “xlink” fromany article.

( (σr=“xpath”

(Paragraph) ⊂ Article) ∩ (σr=“xlink”

(Paragraph) ⊂ Article) )

⇒ (∩ pushing down by R5)

( ( (σr=“xpath”

(Paragraph) ⊂ Article) ∩ σr=“xlink”

(Paragraph) ) ⊂ Article)


( ( (σr=“xpath”

(Paragraph) ∩ σr=“xlink”

(Paragraph) ) ⊂ Article) ⊂ Article)

⇒ (redundant ⊂ deletion by R7)

( (σr=“xpath”

(Paragraph) ∩ σr=“xlink”



(σr=“xpath”

(Paragraph ∩ σr=“xlink”



(σr=“xpath”

(σr=“xlink”

(Paragraph ∩ Paragraph) ) ⊂ Article)

⇒ (∩ deletion by R6)

(σr=“xpath”

(σr=“xlink”


⇒ (index introduction by R8)

(IParagraph

(Article) ∩ σr=“xpath”

(σr=“xlink”

(Paragraph) ) )

⇒ (preceding structure index by R10)

(σr=“xpath”

(σr=“xlink”

(IParagraph

(Article) ) ) )

In the optimized format, the structure index IParagraph

(Article) is applied,which is followed by two other selection operations.

Conclusions and Future Directions

Equivalences are the basis of transformation-based query optimization. Al-though a lot of work has been done on a broad spectrum of issues related to XMLdatabases, the work addressing equivalences for XML query optimization is rare.

In this chapter, we elaborated on the equivalences that we developed for XMLquery optimization. Our strategy differentiates transformations from equiva-



lences. Query transformation for optimization is accomplished in our implemen-tation by a rule system that consists of only deterministic transformation rules.Transformation rules are derived from equivalences. Alternatively, our equiva-lences may be directly used to enumerate alternative plans from which an optimalone is decided based on cost comparison.

Currently, a lot of work is continuing on various aspects related to XML datamanagement, e.g., structured-document modeling (Abiteboul, 1997; Özsu, 1997;Navarro, 1997; Lee, 1997; Yan, 1994; Conse, 1994; Chaudhuri, 1996; Morishima,1997; Gonnet, 1992; Fernadez, 2000; Florescu, 1999; Shanmugasundaram, 1999;Bohannon, 2002; Klettke, 2000), XML data indexing (Chan, 2002; Grust, 2002;Li, 2001; Milo, 1999), and advanced algorithms for fast query processing(Fernandez, 1998; McHugh, 1997; Gottlob, 2002; Li, 2001; Guha, 2002; Chien,2002; Srivastava, 2002). Transformation-based query optimization for XMLdatabases is a rarely explored but fascinating realm.

Our optimization is performed at the logical level — PAT expressions. Oneinteresting extension to our current work is to complement the logical (plan)optimization by introducing a compact physical (cost-based) optimizer to achievefurther better optimization result.

Acknowledgments

The author would like to show great appreciation to his former colleagues atFraunhofer-IPSI (formerly known as GMD-IPSI), Germany. This continuingresearch at the author’s current affiliation was originally initiated at GMD-IPSIin close collaboration with Prof. Karl Aberer, Dr. Klemens Böhm, and Prof. M.Tamer Özsu (during his visit to GMD-IPSI on his sabbatical leave).

References

Abiteboul, S., Cluet, S., Christophides, V., Milo, T., Moerkotte, G. & Simeon, J.(1997). Querying Documents in Object Databases. International Jour-nal on Digital Libraries, 1(1), 5-19.

Bertino, E. (1994). A Survey of Indexing Techniques for Object-OrientedDatabase Management Systems. In J.C. Freytag, D. Maier & G. Vossen(Eds.), Query Processing for Advanced Database Systems. MorganKaufmann Publishers, 383-418.

92 Che


Bohannon, P., Freire, J., Roy, P. & Simeon, J. (2002). From XML Schema toRelations: A Cost-Based Approach to XML Storage. Proceedings of the18th International Conference on Data Engineering (ICDE’02), (pp.64-73).

Böhm, K., Aberer, K., Özsu, T. & Gayer, K. (1998). Query Optimization forStructured Documents Based on Knowledge on the Document TypeDefinition. Proceedings of IEEE International Forum on Research andTechnology Advances in Digital Libraries (ADL’98), (pp. 196-205).

Chan, C. Y., Felber, P., Garofalakis, M. & Rastogi, R. (2002). Efficient Filteringof XML Documents with XPath Expressions. Proceedings of Interna-tional Conference on Data Engineering, (pp. 235-244).

Chan, C. Y., Garofalakis, M. N. & Rastogi, R. (2002). RE-Tree: An EfficientIndex Structure for Regular Expressions. Proceedings of VLDB 2002,(pp. 263-274).

Chaudhuri, S. & Gravano, L. (1996). Optimizing Queries over MultimediaRepositories. Proceedings of SIGMOD’96, (pp. 91-102).

Che, D. (2003). Implementation Issues of a Deterministic TransformationSystem for Structured Document Query Optimization. Proceedings of2003 International Database Engineering & Application Symposium.

Che et al. (2003). Query Processing and Optimization in Structured DocumentDatabase Systems. Manuscript in preparation for publication on the VLDBJournal.

Chien, S., Vagena, Z., Zhang, D., Tsotras, V.J. & Zaniolo, C. (2002). EfficientStructural Joins on Indexed XML Documents. Proceedings of VLDB2002, (pp. 263-274).

Consens, M. & Milo, T. (1994). Optimizing Queries on Files. Proceedings of the1994 ACM SIGMOD International Conference on Management ofData, (pp. 301-312).

Cover, R. (2002). Online Resource for Markup Language Technologies.Retrieved from the WWW: http://xml.coverpages.org

Deutsch, A., Fernandez, M. & Suciu, D. (1999). Storing Semistructured Datawith STORED. Proceedings of ACM SIGMOD 1999, (pp. 431-442).

Fernandez, M. F. & Suciu, D. (1998). Optimizing Regular Path ExpressionsUsing Graph Schemas. Proceedings of the 14th International Confer-ence on Data Engineering, (pp. 14-23).

Florescu, D. & Kossmann, D. (1999). Storing and Querying XML Data Usingan RDMBS. IEEE Data Engineering Bulletin, 22(3), 27-34.

Gonnet, G. H., Baeza-Yates, R. A. & Snider, T. (1992). Information Retrieval-Data Structures and Algorithms. New Indices for Text: PAT trees andPAT arrays. New York: Prentice Hall.



Gottlob, G., Koch, C. & Pichler, R. (2002). Efficient Algorithms for ProcessingXPath Queries. Proceedings of VLDB 2002, (pp. 95-106).

Grust, T. (2002). Accelerating XPath location steps. Proceedings of SIGMODConference 2002, (pp. 109-120).

Guha, S., Jagadish, H. V., Koudas, N., Srivastava, D. & Yu, T. (2002).Approximate XML joins. Proceedings of the ACM SIGMOD Confer-ence, (pp. 287-298).

Klettke, M. & Meyer, H. (2000). XML and Object-Relational Database Systems- Enhancing Structural Mappings Based on Statistics. Proceedings of theInternational Workshop on the Web and Databases (WebDB), (pp. 151-170).

Lee, K., Lee, Y. K. & Berra, P. B. (1997). Management of Multi-StructuredHypermedia Documents: A Data Model, Query Language, and IndexingScheme. Multimedia Tools and Applications, 4(2), 199-224.

Li, Q. & Moon, B. (2001). Indexing and Querying XML Data for Regular PathExpressions. Proceedings of the 27th International Conference on VeryLarge Databases, (pp. 361-370).

McHugh, J., Abiteboul, S., Goldman, R., Quass, D. & Widom, J. (1997). Lore:A Database Management System for Semistructured Data. SIGMODRecord, 26(3), 54-66.

McHugh, J. & Widom, J. (1999). Query Optimization for XML. Proceedings ofthe 25th International Conference on Very Large Databases, 315-326.

Milo, T. & Suciu, D. (1999). Index Structures for Path Expressions. Proceed-ings of ICDT 1999, (pp. 277-295).

Morishima, A. & Kitagawa, H. (1997). A Data Modeling and Query ProcessingScheme for Integration of Structured Document Repositories and Rela-tional Databases. Proceedings of the Fifth International Conference onDatabase Systems for Advanced Applications (DASFAA 1997), (pp.145-154).

Navarro, G. & Baeza-Yates, R. (1997). Proximal Nodes: A Model to QueryDocument Databases by Content and Structure. ACM Transaction onInformation Systems, 15(4), 400-435.

Özsu, M. T., Iglinski, P., Szafron, D. & El-Medani, S. (1997). An Object-Oriented SGML/HiTime Compliant Multimedia Database ManagementSystem. Proceedings of Fifth ACM International Multimedia Confer-ence (ACM Multimedia’97), (pp. 239-249).

Salminen, A. & Tompa, F. W. (1994). PAT Expressions: An Algebra for TextSearch. Acta Linguistica Hungarica, 41(1), 277-306.

94 Che


Shanmugasundaram, J., Tufte, K., Zhang, C., He, G., DeWitt, D.J. & NaughtonJ.F. (1999). Relational Databases for Querying XML Documents: Limita-tions and Opportunities. Proceedings of VLDB, (pp. 302-314).

Srivastava, D., Al-Khalifa, S., Jagadish, H. V., Koudas, N., Patel, J. M. & Wu,Y. (2002). Structural Joins: A Primitive for Efficient XML Query PatternMatching. Proceedings of ICDE’02, (pp. 141-150).

Yan, T. W. & Annevelink, J. (1994). Integrating a Structured-Text RetrievalSystem with an Object-Oriented Database System. Proceedings of the20th VLDB Conference, (pp. 740-749).

Specifying Coherent Refactoring of Software Artefacts 95


Chapter V

Specifying CoherentRefactoring of

Software Artefacts withDistributed GraphTransformations

Paolo Bottoni, University of Rome “La Sapienza”, Italy

Francesco Parisi-Presicce, University of Rome “La Sapienza”, Italyand George Mason University, USA

Gabriele Taentzer, Technical University of Berlin, Germany

Abstract

This chapter discusses the use of Graph Transformations for refactoring.Refactoring changes the internal structure of a software system, whilepreserving its behavior. Even though the input/output view of a system’sbehavior does not change, refactoring can have several consequences forthe computing process, as expressed for instance by the sequence of method

96 Bottoni, Parisi-Presicce, and Taentzer


calls or by state changes of an object or an activity. Such modificationsmust be reflected in the system model, generally expressed through UMLdiagrams. We propose a formal approach, based on distributed graphtransformation, to the coordinated evolution of code and model, as effectof refactorings. The approach can be integrated into existing refactoringtools. Due to its formal background, it makes it possible to reason about thebehavior preservation of each specified refactoring.

Introduction

Software is subject to changes and a piece of software may need changes forseveral reasons. One such reason is the introduction of new requirements thatcause the need for design changes. The introduction of a new requirement canbe a consequence of either the iterative development process chosen for theproject that constructs the system incrementally, or the fact that the requirementwas overlooked in the initial specification and design of the system. As a simpleexample, consider an application developed around a single specific algorithm.If a new algorithm to perform the same calculations (graph layout, for example)becomes available, it may be useful to modify the application to add the optionof using the new algorithm.

Object-oriented programming has made many changes easy to implement, oftenjust by adding new classes, as opposed to more traditional approaches requiringmany modifications. But adding classes may not be sufficient. Even in the simpleexample above, the application must evolve by means other than class addition.If the designer has not foreseen the possibility of alternatives for the algorithm,the class with the original algorithm would probably need to be “split” intoalgorithm-specific elements and general ones, the latter to be “moved” to a newclass that will then provide the means to choose between the two algorithms,placed in separate components.

Another reason for wanting to modify an object-oriented program is to be ableto reuse (part of) it. As an example, consider the case of two teams developingtwo class libraries independently. The two libraries may contain different classesimplementing the same basic objects (windows, lists) or the same operations tomanipulate them with different names. In order to integrate the libraries, it is bestto remove these inconsistencies, by changing one library to use the basic classesor the operation names of the other one. Simple modifications such as the changeof an operation name are not easy to implement, as they require searches for theprocedures that can invoke them or for the other operations that they wouldoverride with the new name.



The two modifications above are examples of what is called refactoring ofcode. Actually, software applications consist of code as well as specificationsand documentation, these being valuable company assets. The diffusion of UMLin large programming organizations is creating a wealth of documentation ascollections of UML diagrams, inspected by developers and designers, or used tocommunicate with the project shareholders. Documentation repositories facili-tate software reuse and design pattern identification. Ideally, refinements oradaptations should be traceable to the original material, and code transformationsreflected back to the documentation.

When refactoring software, the internal structure of a software system changes,while preserving its behavior, in terms of input/output relations. However, thiscan have consequences for the computing process, as expressed for instance bythe sequence of method calls or by state changes of an object or an activity.Several types of refactoring are now known and widely used (Fowler, 1999). Itis demonstrable that they preserve program behavior, and it is usually known inwhich way they modify static specifications, i.e., class diagrams. Refactoringcan also occur in design, involving modifications of interaction, state machine, oractivity diagrams.

However, not all transformations induced by refactoring are actually mappedback to the relevant documentation. Since refactoring is usually performed at thesource code level, it may be difficult to maintain consistency between the codeand its specification – expressed for example with UML diagrams – whichusually refers to the code original version. In particular, one has to identify therelevant diagrams when modifying a piece of software. Two strategies can beadopted to preserve consistency: either restoring the specification after a chosenset of changes, or coherently defining the effects of each refactoring on thedifferent artefacts of a software project. While changes in structural specifica-tions are notationally equivalent to lexical transformations on source code,transformations of behavioral specifications may be significantly moreintricated.

We discuss an approach to the problem of maintaining consistency betweensource code and diagrams, both structural and behavioral, using the formalframework of graph transformation. In particular, Abstract Syntax Treesdescribe the source code, while UML diagrams are represented as graphs,conforming to the abstract syntax presented in the UML metamodel. The UMLdiagrams and the code are hence seen as different views on a software system,so that consistency between the views and the code is preserved by modelingcoherent refactorings as graph transformations distributed on several graphs.Complex refactorings, as well as checking of complex preconditions, aredecomposed into collections of distributed transformations whose application ismanaged by control expressions in appropriate transformation units.



In the rest of this introduction, we set the background for our work, by introducingthe refactorings used in the motivating example and reviewing some approachesto refactoring and software evolution via graph rewriting, and illustratingmotivations for the coherent refactoring of code and models. Backgroundnotions on graph transformation are then given. Next, the problem of maintainingconsistency among specification and code is reformulated as the definition ofsuitable distributed graph transformations, and our approach is illustrated withtwo important refactorings. The next section discusses the principles underwhich one can establish correspondences between abstract representations ofthe code and of the model. Section 6 discusses forms of behavior preservationand sketches out how formal results for graph transformation help in reasoningabout it. Conclusions are then given.

Selected Refactorings

While a complete coverage of refactorings is beyond the scope of this chapter,we illustrate here the basic ones used in the example shown later in the chapter.A rich set of refactorings, both primitive and complex, is given in Fowler (1999).In general, all refactorings require that no name clashes be generated. Forinstance, if a new method is introduced or has its name changed, a check isneeded to ensure that no method with the same signature is already present inthe inheritance hierarchy. Here, we only mention additional checks other thanchecks for name clashes.

RenameVariable and RenameMethod change the name of a variable or method tohighlight structural or behavioral analogies in a set of classes: all references tothese features must be renamed. RenameMethod is one of the constituents of theChangeMethodSignature refactoring, with sub-refactorings such asChangeReturnType and ChangeParameterType, or addition and removal ofparameters. The EncapsulateVariable refactoring hides information by making avariable private and providing public getter and setter methods for accessing andupdating it. All direct references to the variable are replaced by dynamic callsto these methods. InsertClass expands the inheritance hierarchy by introducing anew class B between a class A and its original superclass C. B becomes thesuperclass for A and has C as its superclass. PullUpMethod allows replicatedmethods to be moved from subclasses into a common superclass. To apply thisrefactoring, the body of the pulled up method must not refer to any variable onlydefined in subclasses. ExtractMethod derives from the composition of severalprimitive refactorings, but it is so widespread that it can be considered as a singleone. It removes a block of code from a method and uses it to create a newmethod, substituting the code in the original method by a call to the new one.Beyond avoidance of name clashes, preconditions for it require that all variables



which are accessed by the extracted code and have a local scope be passed asparameters, and that the removed code form a block, i.e., it has a single entrypoint and a single exit point.

Related Work

Several tools have been developed to assist refactoring. Some are packaged asstand-alone executables, while others integrate refactorings into a developmentenvironment. Many tools refer directly and exclusively to a specific language, forexample C# Refactory (http://www.xtreme-simplicity.net/) for C#, orCoreGuide6.0 (http://www.omnicore.com) for Java. Xrefactory (http://www.xref-tech.com) assists in modifying code in C and Java. All of theseprovide a variety of refactorings, typically renamings and method extraction.However, none of them mentions diagrams and the effects on other views of thesystem, including documentation.

The class diagram, referred to as “the model,” is instead considered in objectiF(http: //www.microtool.de/objectiF), which, in addition to supporting a variety oflanguages, allows transformations of both the code and the class model, withchanges propagated automatically to both views. Other kinds of diagrams,especially those describing behavioral aspects of the system, are not refactored.Eclipse (http://www.eclipse.org) integrates system-wide changes of code withseveral refactoring actions (such as rename, move, push down, pull up,extract). Class diagrams are implicitly refactored, too. Finally, JRefactory(http://jrefactory.sourceforge.net) supports 15 refactorings including: pushingup/down, methods/fields, and extract method/interface. The only diagramsmentioned are class diagrams which are reverse engineered from the .javafiles.

Reverse engineering is present in Fujaba (Niere et al., 2001), where the user canreconstruct the model after a chosen set of changes of the code. A more efficientoption would be to define the effects of a refactoring on the different parts of themodel. This is more easily realized on structural models, where transformationson such diagrams are notationally equivalent to the lexical transformation on thesource code, than on behavioral specifications. Modern refactoring tools,however, work on abstract representations of the code, rather than on the codeitself, typically in the form of an Abstract Syntax Tree (AST), following Roberts’(1999) line.

Refactorings are also defined on model diagrams. Sunyé et al. (2001) illustraterefactoring of statecharts, typically to extract a set of states to be part of acomposite state. Transformations of concrete diagrams are specified by pre andpost-conditions, written as OCL constraints. Metz et al. (2002) consider theUML metamodel to propose extensions to use case models, which would allow



significant refactorings of such models and avoid improper current uses. Thesepapers, however, do not consider the integration with possible source coderelated to these models.

Current class diagram editors do not extend changes to all other relateddiagrams, limiting their “automation” to the source code, with the result thatdirect intervention is needed to restore consistency among possibly various UMLdiagrams representing the same subsystem. We adopt UML metamodel in-stances and draw a correspondence between these and abstract syntax treesrepresenting code. Hence, a common graph-based formalism can be used asbasis for an integrated management of refactoring both the code and the modelin an integrated way.

Graph rewriting has been introduced as a basis for formalising refactoring inwork by Mens, alone (2000, 2001) and with others (2002). In these papers, a non-standard graph representation of code is used, so that the availability of ASTrepresentations is not exploited. Moreover, integrated refactoring of model andcode by graph transformation has not been considered up to now.

Outline of the Approach

Our approach aims at precisely specifying integrated refactoring of model andcode, while maintaining the consistency between them achieved during thedevelopment of a software project.

Indeed, software development follows typical patterns. Authors can start somemodeling activity, update and refine their models, start writing code, and modifyit. If a CASE tool is available, code can be generated from models, e.g., skeletonsof classes or collaborations for some pattern. Moreover, developers can decideto compile the code, reverse-engineer, and update some parts of the model fromthe generated abstract syntax tree. As a result of this first phase of development,parts of the code and the model have had an independent evolution, so that theycan be consistent or not, while other parts have evolved in a coordinated way.The model and the code can then be checked to identify parts consistent with oneanother, either by circumstance or by construction. To this end, we assume thatat any time a pair of graphs exists providing abstract representations of the codeand of the model. The code representation is in the form of an AST, while themodel is given through UML diagrams, and constitutes an instance of the UMLmeta-model. The checking phase produces an interface graph IG and a pair ofgraph morphisms from IG to the AST and UML graphs respectively. Themorphisms establish the correspondence between code and models. The rela-tions between these graphs must be managed by the CASE tool. The subsequentphases of refactoring can then be triggered on the code or the model. For any



refactoring supported by the CASE tool in which the user acts on the code or onthe model, the corresponding modifications on the other graph must be enforced.After refactoring, the cycle can start again with new developments, and so on.

While refactoring tools work on both abstract and concrete representations ofcode, they are usually restricted to the manipulation of structural aspects of themodel, namely class diagrams. Although this is intuitively justifiable by the statedassumption that refactoring does not affect the behavior of systems, thecombination of refactoring with other forms of code evolution can lead toinconsistencies between the model and the code. This could be avoided by acareful consideration of what a refactoring involves, as shown in the followingtwo subsections.

Modification of Collaborations

In the refactoring ExtractMethod, a block of code blk is removed from a methodmorig in a class C, a new method mnew is created, block blk is inserted as thebody of mnew and a call to mnew replaces the original code in morig. If theexecution of morig is represented in a collaboration diagram (Figure 1a), but therefactoring tool cannot manipulate such a diagram, then the activation of mnewcannot be represented. Suppose that mnew is subsequently moved from C to acoupled class D, and finally modified so that it performs some new activities,involving a call to a method meth in a third class E. The designer can now assumethat the last addition of the call to meth is significant enough to show in thecollaboration. But, as we have lost the consistency between the model and thecode, a simple-minded addition of the call to meth as a descendant of the call tomorig would result in the inconsistent model of Figure 1b. This can be avoidedif all the steps in this process are reflected in the collaboration: the extraction ofblk to mnew would be reflected by a self-call stemming from the activation formorig, the movement of mnew to class D would transform the self-activation toa call to this new class and the consequent activation of mnew in it, so that thecall of meth would now be in the correct position, as in Figure 1c).

Modification of Activity Graphs

Activity graphs are special types of state machines used for describing complexprocesses, involving several classifiers, where the state evolution of the involvedelements is modeled. Suppose that an action is performed to the effect of settinga field variable to some value, say x = 15. Hence, a state s appears in the modelindicating that an assignment has to occur at that time. If the EncapsulateVariablerefactoring is subsequently applied to the variable x, the code x = 15 is replaced



by setX(15). The state in the activity diagram now becomes a CallState s’.(Compare similar modifications in activity diagrams in Figures 2c and 3c.)

Example of Refactoring

We illustrate the refactorings with a typical case in software development. Letus consider the design of an intelligent Audio player, able to dynamically identifya MusicSource, for example, on the basis of some preferences, and to obtain fromthis source a piece of Music. It then sets up an environment, in which it causesthe received piece to play itself.

A first version produces the following, strongly coupled, set of classes. More-over, the player must expose its preferences in a public variable for the musicsource to select some piece of music. This prevents reuse of the Audio class ina non-controlled environment. Figure 2 shows components of the UML model:class (2a), sequence (2b) and two activity diagrams (2c).

Figure 1. (a) Original sequence diagram; (b) inconsistent situation fromnot reflecting the extraction of mnew; (c) desired consistent situation

:C:C :E :C :D :E

morig morig

meth

morig

mnewmeth

a) b) c)

class Audio {

protected MusicSource ms; private Environment env;

public MusicDescription preferences;

protected findMusicSource() { // lookup for a music source }

protected void playMusic() {

ms = findMusicSource(); Music toPlay = ms.provideMusic(this);

// code to set the playing environment env

toPlay.play(env);

continued at top of page 103



With a view to the possibility of reuse, the programmer decides to protect thepreferences, by applying the EncapsulateVariable refactoring. After this firststep, the affected code looks as follows, where the parts in bold mark the changedelements. The new situation is reflected in the model diagrams of Figure 3.

The code above presents several possibilities for refactorings, allowing theintroduction of an abstract notion of player able to retrieve a content source,interrogate it to obtain some content and set an environment for it to play.Concrete players will differ for the type of source they have to retrieve and theway in which they define the environment. On the other hand, content sourcesmust have a generic ability to accept a player and sending the appropriate contentto it, while the different forms of content will have specific realizations of the play

}

}

class Music {

void play(Environment env) { // code to play in the environment env }

}

class MusicSource {

public Music provideMusic(Audio requester) {

MusicDescription desc = requester.preferences;

// code to retrieve music according to desc and sending it back as result

}

}

class Environment { // fields and methods to define a playing environment }

class Audio {

protected MusicSource ms; private Environment env;

private MusicDescription preferences;

protected findMusicSource() { // same implementation as before }

protected void playMusic() { // same implementation as before }

public MusicDescription getPreferences() { return preferences; }

public void setPreferences(MusicDescription desc) { preferences = desc; }

}

class MusicSource {

public Music provideMusic(Audio requester) {

MusicDescription desc = requester.getPreferences();

// same code using desc as before

}

}



method. To this end, a first step is to extract the code for playing in anenvironment from playMusic to a setEnvironment method. Method playMusic isthen renamed to playContent, while findMusicSource is renamed to findSourceand the variable musicSource to source, while in class Music, provideMusic isrenamed to provideContent. Refactorings are then performed to introduce newclasses and interfaces in an existing hierarchy, by creating and inserting theabstract class AbstractPlayer and the interfaces Content and ContentSource. Wecan now pull up methods and variables from Audio to AbstractPlayer. Finally, allreturn and parameter types referring to the concrete classes are now changedto the newly inserted types. The resulting code is reported below. Again, partsin bold show the modified parts with respect to the previous version. The readercan reconstruct the UML diagrams according to these modifications.

abstract class AbstractPlayer {

protected ContentSource source; private Description preferences;

private Environment env;

protected abstract ContentSource findSource();

protected abstract void setEnvironment();

protected void playContent() {

source = findSource(); Content toPlay = source.provideContent(this);

setEnvironment(); toPlay.play(env);

}

Description getPreferences() { return preferences; }

void setPreferences(Description desc) { preferences = desc; }

}

class Audio extends AbstractPlayer {

ContentSource findSource() { // code from findMusicSource }

void setEnvironment() { // previous code used to set env }

}

interface ContentSource { Content provideContent(AbstractPlayer requester); }

class MusicSource implements ContentSource {

Content provideContent(AbstractPlayer requester) {

Description desc = requester.getPreferences();

// previous code from provideMusic exploiting desc;

}

}

interface Content { void play(Environment env); }

class Music implements Content { // same implementation as before }

class Environment { // same implementation as before }



The Formal Background

The algebraic approach to graph transformation (Corradini et al., 1997) is theformal basis for our work, as graphs are natural means to represent code and

Figure 2. Components of the UML model for the first version of code – (a)class diagram; (b) sequence diagram; (c) activity diagrams

Audio+ MusicDescription preferences# MusicSource findMusicSource()# void playMusic()

MusicSource+ Music provideMusic(Audio requester)

# ms

Music# play(Environment env)

Environment

- env

Audio+ MusicDescription preferences# MusicSource findMusicSource()# void playMusic()


# ms

Music# play(Environment env)

Environment

- env

(a)

ms:MusicSourcea:Audio

playMusic()

findMusicSource()

ms

provideMusic(a)

toPlay

toPlay: Music

play(env)


playMusic()

findMusicSource()

ms

provideMusic(a)

toPlay

toPlay: Music

play(env)

(b)

findMusicSource()provideMusic(a)

a:Audio ms:MusicSource

ms:

toPlay: Music[found]

toPlay:Music

set environment

play(env)

Audio::playMusic()

findMusicSource()provideMusic(a)


ms:

toPlay: Music[found]

toPlay:Music

set environment

play(env)

Audio::playMusic()

start retrieval


a.preferences

Audio::provideMusic()

retrieve music

start retrieval


a.preferences


retrieve music

(c)



model structures. To handle model and code-related graphs in a separate butconsistent way, we apply concepts of distributed graph transformation. Finally,the concept of transformation units is used to obtain a global control on structuredgraph manipulations, useful to specify complex refactorings.

Graph Transformation

Graphs are often used as abstract representations of code and diagrams, e.g.,UML diagrams. Formally, a graph consists of a set of vertices V and a set ofedges E such that each edge e in E has a source and a target vertex s(e) and t(e)in V, respectively. Each vertex and edge may be attributed by some data valueor object, expressed by elements of an algebra on some algebraic signature Σ.Here, we consider typed attributed graphs. For graph manipulation, we adopt thedouble-pushout approach to graph transformation, DPO (Corradini et al., 1997),

Figure 3. UML diagrams after variable encapsulation – (a) class diagram;(b) sequence diagram; (c) activity diagram

Audio- MusicDescription preferences# MusicSource findMusicSource()# void playMusic()+ MusicDescription getPreferences()+ void setPreferences(MusicDescription desc)


# ms

Music# play(Environment env)Environment

- env

(a)


playMusic()

findMusicSource()

ms

provideMusic(a)

toPlay

toPlay: Music

play(env)

getPreferences()

desc


playMusic()

findMusicSource()

ms

provideMusic(a)

toPlay

toPlay: Music

play(env)

getPreferences()

desc

(b)

start retrieval


getPreferences()


retrieve music

start retrieval


getPreferences()


retrieve music

(c)



based on category theory. Using typed graphs, structural aspects appear at twolevels: the type level (modeled by a type graph T) and the instance level (modeledby an instance graph G). G is correctly typed if it can be mapped in a structure-preserving manner to T, formally expressed by a graph homomorphism.

A graph rule r: L → R is a pair of T-typed instance graphs L, R such that L ∪ R isdefined, i.e., graph objects occurring in both L and R have the same type andattributes and, if they have the same edges, will also have the same source andtarget vertices. The left-hand side L represents the modification pre-conditions,while the right-hand side R shows its effect. Vertex identity is expressed vianames, while edge identity is inferred from the identity of the connected vertices.Additionally, graph rules comprise attribute computations where left-hand sidesmay contain constants or variables of set X, while right-hand sides capture theproper computations, denoted as elements of an algebraic term TΣ (X)

.

A rule may also contain a set of negative application conditions (NAC),expressing graph parts that must not exist for the rule to be applicable. NACsare finite sets of graphs NAC={N

i| L ⊆ N

i, i ≥ 0 }, specifying a conjunction of

basic conditions, and can refer to values of attributes (Fischer et al., 1999). Fora rule to be applicable, none of the prohibited graph parts N

i – L present in a NAC

may occur in the host graph G in a way compatible with a rule match m. A matchis an injective graph homomorphism m: L ∪ R → G ∪ H, such that m(L) ⊆ G andm(R) ⊆ H, i.e., the left-hand side of the rule is embedded into G and the right-hand side into H. In this chapter we use dotted lines to denote NACs. Non-connected NACs denote different negative application conditions (see Figure 14for an example). A graph transformation from a graph G to a graph H, p(m):G ⇒ H, is given by a rule r and a match m with m(L – R) = G – H and m(R – L)= H – G, i.e., precisely that part of G is deleted which is matched by graph objectsof L not belonging to R and symmetrically, that part of H is added which ismatched by new graph objects in R. Operationally, the application of a graph ruleis performed as follows: First, find an occurrence of L in graph G. Second,remove all the vertices and edges from G matched by L – R. Make sure that theremaining structure D= G–m(L–R) is still a proper graph, i.e., no edge is leftwhich dangles because its source or target vertex has been deleted. In this case,the dangling condition is violated and the application of the rule at match m isnot possible. Third, glue D with R–L to obtain graph H. A typed graphtransformation system GTS=(T,I,R) consists of a type graph T and a finite setR of graph rules with all left and right-hand sides typed over T. GTS definesformally the set of all possible graphs by Graphs(GTS)={G|I ⇒*

R G} where

G ⇒*R

H ≡ G ⇒r1(m1)

H1

... ⇒rn(mn)

Hn = H with r1, ..., rn in R and n >= 0. It

follows from the theory that each graph G is correctly typed.



Distributed Graph Transformation

Distributed graph transformations (Fischer et al., 1999) are structured at twoabstraction levels: the network and the object level. The network level containsthe description of a system’s architecture by a network graph, and its dynamicreconfiguration by network rules. At the object level, graph transformationsmanipulate local object structures. To describe a synchronized manipulation ondistributed graphs, a combination of graph transformations on both levels isneeded. In a distributed graph each network vertex is refined by a local graph.Network edges are refined by graph homomorphisms on local graphs, whichdescribe how the local graphs are interconnected. Each local graph may be typeddifferently, only restricted by the fact that an interface type graph is fully mappedto all connected local type graphs. We use distributed graphs where the networkgraphs consist of three vertices: for the model, for the code and for theirinterface. Furthermore, two network edges are needed, starting from theinterface vertex and going to the model and code vertices, respectively. Thecorresponding refinement graphs are called model graph, code graph andinterface graph. The interface graph holds exactly that subgraph whichdescribes the correspondences between the other two local graphs.

A distributed graph rule r is a network rule n — a normal graph rule — togetherwith a set S of local rules — graph rules on local graphs — for all those networkvertices which are preserved. Each preserved network edge guarantees acompatibility between the corresponding local rules. The rules must also beconsistent with common attribute values. In this chapter, network rules arealways identities, as the network is not changing. Two local rules, on the modeland the code graph, are synchronized by applying a common subrule on theirinterface graph. We show here only local rules with grey levels indicating subruleparts. We introduce two operators to assemble a distributed rule from local ones:asOftenAsPossible means to apply a local rule as often as possible at differentmatches in parallel, while || just denotes the distributed application of rules.

Transformation Units

Transformation units (Kreowski et al., 1997) are a general concept to control ruleapplication, by control conditions specified by expressions over rules. We use itin the context of distributed graph transformation, in which a transformation unitconsists of a set of rules and a control condition over C describing how rules canbe applied. Typically, C contains expressions on sequential application ofrules, as well as conditions and loops, e.g., by applying a rule as long as possible.

We relate rule expressions to graph rules by giving names to rules and passingparameters to them, to be matched against specific attributes of some vertex. By



this mechanism, we can restrict the application of rules to those elements whichcarry an actual reference to the code to be refactored. To this end, the rulespresented in the transformation units are meant as rule schemes to be instantiated toactual rules, assigning the parameters as values of the indicated attributes.

Refactoring by Graph Transformation

We present the general setting of refactoring by graph transformation andanalyse a sample refactoring which involves transformation of the code andmore than one UML diagram. Furthermore, we show the use of transformationunits over distributed graph transformations to enforce synchronization andatomicity of the transformations in different diagrams.

Graph Representation of Diagrams and Code

The abstract representations of code and UML models are given in the form ofgraphs, obeying the constraints imposed by a type graph. For the code, we referto the JavaML definition of an abstract syntax for Java (Badros, 2000), and weconsider the type graph provided by its DTD. Indeed, any JavaML document isstructured as a tree, i.e., a special kind of graph where an XML element isrepresented by a typed vertex and its attributes by vertex attributes. The graphedges show the sub-element relation and are untyped and not attributed. We callthis graph the code graph. For UML (OMG, 2002), the abstract syntax of theUML metamodel provides the type graph to build an abstract representation ofthe diagram that we call the model graph.

As an example, Figure 4 shows the code graph for class Audio. For spacereasons, we omit the representation of fields ms and env and methodfindMusicSource. Figure 5 presents the model graph for the class diagram ofFigure 2a (without dependencies). Only the important fields of model elementsare shown. Details of model elements occurring in more than one figure areshown only in one. Vertices that would be directly connected to a class vertexin the code graph, appear in the model graph as feature elements for which theclass is an owner. Figures 6 and 7 present the components of the model graphfor the sequence and activity diagrams of Figure 2.

The model graphs, though presented separately, are different views of one largegraph representing the whole model. Indeed, behavioral diagrams are associatedwith model elements which own or contribute to the model’s behavior. As anexample, object m1:Method for playMusic appears in Figure 5 as a behavioral



Figure 4. A part of the code graph for the first version of the code of classAudio

c1‘: classname = „Audio“

: java-class-file

m1‘: methodname= „playMusic“id = „Audio:mth1“visibility = protected

: typename= „void“primitive = true

: assignment-exprop = „=„

c6‘: sendmessage= „findMusicSource“

: block

a1‘: fieldname= „preferences“visibility = public

: typename= „MusicDescription“

: lvalue a2‘: var-setname= „ms“

: local-variablename = „toPlay“id = „Audio:var1“

: typename= „Music“

c7‘: sendmessage= „provideMusic“

: target a2‘: var-refname= „ms“

: arguments o8‘: this

1

2

: java-source-program

c8‘: sendmessage= „play“ : target

o6‘: var-refname= „toPlay“idref=„Audio:var1“

i1‘: arguments

3

o5‘: var-refname= „env“


: java-class-file



: assignment-exprop = „=„

c6‘: sendmessage= „findMusicSource“

: block

a1‘: fieldname= „preferences“visibility = public


: lvalue a2‘: var-setname= „ms“

: local-variablename = „toPlay“id = „Audio:var1“

: typename= „Music“

c7‘: sendmessage= „provideMusic“

: target a2‘: var-refname= „ms“

: arguments o8‘: this

1

2


c8‘: sendmessage= „play“ : target

o6‘: var-refname= „toPlay“idref=„Audio:var1“

i1‘: arguments

3

o5‘: var-refname= „env“

Figure 5. Abstract graph for the class diagram of Figure 2a

m1:Methodname= „playMusic“visibility=#protected

c1:Classname= „Audio“

c2:Classname= „MusicDescription“

a1:Attributename= „preferences“visibility= #public

m2:Methodname= „findMusicSource“visibility=#protected

c4:Classname= „Environment“

c3:Classname= „MusicSource“

m3:Methodname= „provideMusic“visibility=#public

c5:Classname= „Music“

:Methodname= „play“visibility=#protected

:Parametername= „env“kind=#in

:Association

:AssociationEnd

a3:AssociationEndname= „env“visibility=#private

:AssociationEnd

:Association

a2:AssociationEndname= „ms“visibility=#protected

type type

type

p1:Parametername= „requester“kind=#in

type

o2:Operationo1:Operation

o3:Operation

o4:Operation

type

specification

specification

specification

specification

ownerownerowner

owner

owner

feature

feature

feature

feature

feature

:Parameterkind=#return

m1:Methodname= „playMusic“visibility=#protected

c1:Classname= „Audio“

c2:Classname= „MusicDescription“

a1:Attributename= „preferences“visibility= #public

m2:Methodname= „findMusicSource“visibility=#protected

c4:Classname= „Environment“

c3:Classname= „MusicSource“

m3:Methodname= „provideMusic“visibility=#public

c5:Classname= „Music“

:Methodname= „play“visibility=#protected

:Parametername= „env“kind=#in

:Association

:AssociationEnd

a3:AssociationEndname= „env“visibility=#private

:AssociationEnd

:Association

a2:AssociationEndname= „ms“visibility=#protected

type type

type

p1:Parametername= „requester“kind=#in

type

o2:Operationo1:Operation

o3:Operation

o4:Operation

type

specification

specification

specification

specification

ownerownerowner

owner

owner

feature

feature

feature

feature

feature

:Parameterkind=#return

feature of class Audio, and in Figure 7 as the element whose behavior is definedby the component of the model graph for activity diagrams.

Conversely, object o2:operation appears as the specification for playMusic inFigure 5, and as the operation for a CallOperationAction object in Figure 6. In thenext section, transformation units for distributed transformations are used to



Figure 6. Abstract graph for the sequence diagram of Figure 2b

Figure 7. Abstract graph for the activity diagram of Figure 2c for executingplayMusic

o8: Objectname= „a“

:CollaborationInstanceSet

:InteractionInstanceSet

o7: Objectname= „m“

o6: Objectname= „toPlay“

:Stimulus

:Stimulus

:Stimulus

:Stimulus

:Procedure

:Procedure

:Procedure

:Procedure

:CallOperationAction

o2:Operationname= „playMusic“

c6:CallOperationAction

o1:Operationname= „findMusicSource“


o3:Operationname= „provideMusic“


o4:Operationname= „play“

i1:InputPin

:DataFlow

o5: Objectname= „env“

c3: Classname= „MusicSource“ c5: Class

name= „Music“

c1: Classname= „Audio“

predecessor

predecessor

activator

activator

activator

sender

sender

sender

receiver

receiver receiver

receiver

destination

source

:OutputPin

:ReadLinkObjectEndAction

a3:AssociationEnd:LinkEnd

o8: Objectname= „a“

:CollaborationInstanceSet

:InteractionInstanceSet

o7: Objectname= „m“

o6: Objectname= „toPlay“

:Stimulus

:Stimulus

:Stimulus

:Stimulus

:Procedure

:Procedure

:Procedure

:Procedure

:CallOperationAction

o2:Operationname= „playMusic“







i1:InputPin

:DataFlow

o5: Objectname= „env“

c3: Classname= „MusicSource“ c5: Class

name= „Music“

c1: Classname= „Audio“

predecessor

predecessor

activator

activator

activator

sender

sender

sender

receiver

receiver receiver

receiver

destination

source

:OutputPin

:ReadLinkObjectEndAction

a3:AssociationEnd:LinkEnd

:Procedure



:ActivityGraph

:Partition :Partition :Partition

:CallState

:Procedure



:SubActivityState

:Procedure



:CallState

:Transition

:ActionState

:Procedure:Action

:Transition

contents

contents

contents

contents

source

target

source

m1: Methodname= „playMusic“

behavior

target:Transition

source

target

ag:ActivityGraph

:Procedure



:ActivityGraph

:Partition :Partition :Partition

:CallState

:Procedure



:SubActivityState

:Procedure



:CallState

:Transition

:ActionState

:Procedure:Action

:Transition

contents

contents

contents

contents

source

target

source

m1: Methodname= „playMusic“

behavior

target:Transition

source

target

ag:ActivityGraph

modify code and model graphs in a coordinated way, based on correspondences(further discussed in Section 5) between elements in the two graphs, indicatedby similar names (e.g., “c1’ ” in Figure 4 and “c1” in Figure 5).



Encapsulation of Variables

The preconditions for EncapsulateVariable require that no method exists in thehierarchy with the same signature as the setter and getter methods to be created.Therefore, we use NACs on rules transforming the code and model graphs.Neither graph expresses the hierarchy directly, so that the transitive closure ofinheritance must be evaluated by inserting edges of type gen from a class to itsancestors, before checking the precondition. This can be easily done by rules notshown here, but similar rules are presented in Bottoni et al. (2003).

a‘: fieldname= varnamevisibility = x

c‘: classname = cname

a‘: fieldname= varnamevisibility = private

m2‘: methodname= „get“+varnameid = cname + „:mth“ + cvisibility = x


: formal_arguments

m1‘: methodname= „set“+varnameid = cname + „:mth“ + dvisibility = x

p1‘: formal_argumentname = „arg“id = cname + „:frm“ + d

1: typename = t

1: typename = t

: typename = t

: typename = void

: typename = t

: return

: var-refname= „varname“

: asignment-exprop= „=“

: block

: lvalue

a1‘: var-setname= „varname“

: var-refname= „arg“id = cname + „:frm“ +d

a‘: fieldname= varnamevisibility = x


a‘: fieldname= varnamevisibility = private

m2‘: methodname= „get“+varnameid = cname + „:mth“ + cvisibility = x


: formal_arguments

m1‘: methodname= „set“+varnameid = cname + „:mth“ + dvisibility = x

p1‘: formal_argumentname = „arg“id = cname + „:frm“ + d

1: typename = t

1: typename = t

: typename = t

: typename = void

: typename = t

: return

: var-refname= „varname“


: block

: lvalue

a1‘: var-setname= „varname“

: var-refname= „arg“id = cname + „:frm“ +d

Figure 8. Rule for variable encapsulation in the code graph

encapsulate_variable_code(in String cname, in String varname):

Code graph transformation is now specified by rule encapsulate_variable_codein Figure 8, where cname identifies the class to be modified, and varname thevariable to be encapsulated. This rule is complemented by NACs, two of whichare shown in Figure 9, reporting also the nodes in the LHS of Figure 8. These twoNACs check the absence of methods with the same signature in the class, whilethe others check the absence in the whole hierarchy. All accesses to the variableare substituted by method calls. Hence, Figure 10 shows the rule replacing directaccess to the variable with a call of the getter, while Figure 11 shows the rule forvalue updates.



Rules operate locally on the components of the model graph for the diagramsabove. Figure 12 shows the encapsulate_variable_model rule acting on the classdiagram. Negative application conditions analogous to those for the code graphsare also used, guaranteeing a check of the overall consistency of the represen-tations. Consequently, we also need to compute the transitive closure of theinheritance relation for model graphs (not shown). Rulesencapsulate_variable_model and encapsulate_variable_code are applied in paral-lel along their common subrule shown in grey.

Figure 9. Two NACs for the rule in Figure 8, to check that no method existswith the same signature as the inserted setter and getter methods

a‘: fieldname= varname

: methodname= „get“+varname


1: type


: methodid= „set“+varname


1: typename= t

: formal_arguments

: formal_argumentname = „arg“

: typename = t

: typename= void


: methodname= „get“+varname


1: type


: methodid= „set“+varname


1: typename= t

: formal_arguments

: formal_argumentname = „arg“

: typename = t

: typename= void

Figure 10. Rule to replace accesses to varname in cname with calls to thegetter

ac: field-accessfield= varname

c2‘: sendname= „get“+varname

1: var-refid = i

: target

c‘: classname= cname


1: var-refid = i



m‘: method m‘: method

ac: field-accessfield= varname

c2‘: sendname= „get“+varname

1: var-refid = i

: target



1: var-refid = i



m‘: method m‘: method

field-access(in String cname, in String varname):



The effect on activity diagrams is shown by the rule getEncVarInActivity in Figure13, replacing variable access with a call of a getter. For simplicity, we omit allinput and output pins. We do not present the whole distributed rule, but only thelocal rule acting on the model graph. If the variable replacement in the modelgraph corresponds to some variable replacement in the code graph, all possiblerule applications of getEncVarInActivity have to be applied synchronously withcode rule field-access along their common subrule, which is shown in grey. Ananalogous rule exists for replacing variable updates with calls of the settermethod.

Figure 11. Rule to replace updates of varname in cname with calls to thesetter

ac: field-setfield= varname

c3‘: sendname= „set“+varname

1: lvalue 1: lvalue

2: expr-elems

: arguments

2: expr-elems





m‘: methodm‘: method

ac: field-setfield= varname

c3‘: sendname= „set“+varname

1: lvalue 1: lvalue

2: expr-elems

: arguments

2: expr-elems





m‘: methodm‘: method

Figure 12. LHS and RHS of the rule for variable encapsulation on the classdiagram component of the model graph

a: Attributename= varnamevisibility = x

c: Classname = cname

a: Attributename= varnamevisibility = private m1: Method

name= „get“+varnamevisibility = x


m2: Methodname= „set“+varnamevisibility = x

p1: Parametername = „arg“

1: Classifiername = t


type type

type

type

feature

feature

feature

feature

owner ownerowner

owner

op2: Operation

op1: Operation

: Parameterkind = #return

a: Attributename= varnamevisibility = x


a: Attributename= varnamevisibility = private m1: Method

name= „get“+varnamevisibility = x


m2: Methodname= „set“+varnamevisibility = x

p1: Parametername = „arg“



type type

type

type

feature

feature

feature

feature

owner ownerowner

owner

op2: Operation

op1: Operation

: Parameterkind = #return

field-set(in String cname, in String varname):

encapsulate_variable_model(in String cname, in String varname):



Finally, we consider the required modifications for sequence diagrams, for thecase of variable encapsulation. Since sequence diagrams do not show read andwrite actions on attributes, the encapsulation does not directly cause a refactoring.In order to maintain a consistent model, the user has to specify if and where therefactoring should be represented for this part of the model. In particular,whenever a method m is called, in which the encapsulated variable is used, it isnecessary to introduce a Stimulus s’ to call the relevant setter or getter method.From the ordering of subtrees in the code graph of m, one can identify thestimulus s for which s’ is the successor (or predecessor) in the new activationsequence, and pass it as a parameter to the rule. For space reasons, we omit therepresentation of the relative rule getEncVarInInteraction.

The rules in Figures 10, 11, and 13 must be applied at all possible instances of theirLHS in the distributed graphs. There may be several such instances, and we wantto apply a transformation in a transactional way, i.e., the overall application ispossible only if corresponding parts can be coherently transformed. Hence,transition units specify some form of control on the application. In particular, thecontrol construct asOftenAsPossible states that a local rule must be applied inparallel on all (non-conflicting) instances of the antecedent. Contextual elementscan be shared by different instances, but no overlapping is possible on elementsremoved or transformed by the rule. Moreover, the construct || indicates thedistributed application of two or more rules.

Figure 13. Rule for modifying variable access in activity diagrams

1:ActionState

2:Procedure

ac:ReadAttributeAction

2:Procedure


1:CallState

m1: Method

a: Attributename= varname




op: Operationname= „get“+varname


m1: Method

1:ActionState

2:Procedure

ac:ReadAttributeAction

2:Procedure


1:CallState

m1: Method







m1: Method

getEncVarInActivity(in String cname, in String varname):



The user can also decide to request a modification of interaction diagrams. In thiscase, he or she has to interactively provide a value for the stimulus after or beforewhich to place the new call, and the transformation unit is completed by thefollowing construct.

By applying the transformation unit, both code and model graphs are transformedto reflect the existence and usage of the new methods. As an example, the graphin Figure 14 is a subgraph of the resulting code graph (the body of playMusic isnot shown as it remained unchanged) obtained by applying the transformationunit EncapsulateVariable, i.e., the local rule encapsulate_variable_code has beenapplied once with arguments cname = “Audio” and varname = “preferences”.

Extract Method

In the words of Martin Fowler, “If you can do Extract Method, it probably meansyou can go on more refactorings. It’s the sign that says, ‘I’m serious about this’.”We present our approach to managing this refactoring, without figures due tolack of space. A more detailed version, but with a different code representation,is in Bottoni et al. (2003).

The pre-condition that the name for the new method does not exist in the classhierarchy is checked for variable encapsulation. In general, we can assume thatthe code and model graphs are complemented by all the needed gen edges. Thepre-condition that the code to be extracted be a block is easily checkable on the

EncapsulateVariable(in String cname, in String varname):=

encapsulate_variable_code(cname, varname) ||

encapsulate_variable_model(cname,varname);

asLongAsPossible field_access(cname,varname) ||

(asOftenAsPossible getEncVarInActivity(cname,varname) end) end;

asLongAsPossible field_set(cname,varname) ||

(asOftenAsPossible setEncVarInActivity(cname,varname) end) end;

asOftenAsPossible getEncVarInInteraction(cname,varname,stimulus) end

asOftenAsPossible setEncVarInInteraction(cname,varname,stimulus) end

To sum up, EncapsulateVariable is expressed by a transformation unit as follows:



code graph. Indeed, this code can be a whole subtree rooted in a block, if, switch,loop, do-loop vertex, or a collection of contiguous subtrees of a same methodvertex, composed of stmt-exprs not comprising any construct try, throw, return,continue, break, synchronized, and such that no label appears in them.

We then need to identify all the variables to be passed to the new method. Thecode graph is inspected to identify all the var-set and var-ref elements where thename of the variable is not the name of a formal-argument of the original methodor a name for a local-variable declaration present in the subtree to be moved.Additionally, if the subtree presents some local-variable vertex, we check thatthere are no var-set or var-ref elements for that variable in the subtrees remainingwith the original method. The creation of the call for the new method is achievedby substituting the removed subtrees with a send element with the name of thenew method as value of the attribute message, target this, and the list of formal-arguments as derived before. In the model, we modify the class diagram bysimply showing the presence of the new method in the class, as the effects onthe referred variables and the existence of a call for this method are not reflectedat the structural level. For the activity diagrams, we need to identify the Actionassociated with a given Operation. Such an Action can be further detailed through

Figure 14. Code graph for class Audio after the EncapsulateVariablerefactoring


: java-class-file



a1‘: fieldname= „preferences“visibility = private



a3‘: fieldname= „env“visibility = private

: typename= „Environment“

m3‘: methodname= „getpreferences“id = „Audio:mth2“visibility = public


m4‘: methodname= „setpreferences“id = „Audio:mth3“visibility = public


: formal_arguments p2‘: formal_argumentname= „arg“id = „Audio:frm1“


: return: var-refname= „preferences“


: block

: lvalue a2‘: var-setname= „preferences“

: var-refname= „arg“id = „Audio:frm1“


: java-class-file



a1‘: fieldname= „preferences“visibility = private



a3‘: fieldname= „env“visibility = private

: typename= „Environment“

m3‘: methodname= „getpreferences“id = „Audio:mth2“visibility = public


m4‘: methodname= „setpreferences“id = „Audio:mth3“visibility = public


: formal_arguments p2‘: formal_argumentname= „arg“id = „Audio:frm1“


: return: var-refname= „preferences“


: block

: lvalue a2‘: var-setname= „preferences“

: var-refname= „arg“id = „Audio:frm1“



a collection of Actions associated with it. So, we need to identify all those verticeswhich correspond to roots of the moved subtrees, detach them from thedescription of the Operation, and exploit them to create the description of theOperation associated with the new method.

For interaction diagrams, one must identify the existing instances of Stimulusoccurring before and/or after the extracted code, and insert the Stimulus to aCallOperationAction, for an Operation with the name of the new Method, withequal receiver and sender. Moreover, each instance of CallOperationAction,originating from the original Operation instances and related to a vertex in theextracted subtrees, must now be related to an instance of Stimulus, whoseactivator is the Stimulus for the new Operation. The existing predecessor andsuccessor associations for the first and last such instances of Stimulus aretransferred to the new Operation. These transformations must be applied as oftenas possible, so as to affect all the descriptions of the behavior of the refactoredmethod. Indeed, calls to such methods can occur in different scenarios, meaningthat the sequence diagrams for all such scenarios must be modified.

Building Correspondences between Codeand Model Graphs

In order to manage distributed transformations involving the Abstract SyntaxTree (AST) viewed as a graph and the graph representing the UML model, weneed to establish an interface graph IG and two morphisms µ

AST and µ

UML from

it to the two graphs. This requires the construction of a correspondence betweentypes of vertices in the two graphs. To this end, we adopt for AST the concreterepresentation given by JavaML, an XML-based specification, while the graphfor the UML model is constructed in accordance with the UML metamodel.

In this section, we sketch the principles directing the construction of thecorrespondences, as the complete construction is beyond the scope of thischapter. In particular, we consider the structural and behavioral aspects of thespecification separately.

From the structural point of view, we can proceed top-down and see thatJavaML class vertices correspond to UML class vertices, and a JavaML field toa UML Attribute. However, care must be taken in managing aspects of thestructural definition involving relations to other classes. For example, thesubclass relation is represented in UML by the presence of a pattern involvingtwo Class vertices, a Generalization vertex, and two associations relating the



latter vertex to the other two, one with the role of specialization, the other ageneralization. In JavaML, a superclass vertex, with a name attribute, constitutesa leaf of the tree rooted in the class vertex. In such a case, IG would contain onlya CLASS vertex, mapping to a class vertex in AST through µ

AST, and to a class

vertex in UML through µUML

. The definition of the morphisms requires checkingthat the superclass relation is consistently represented in the two graphs. Asimilar situation occurs for the implements construct.

As concerns behavioral aspects, the method vertex in JavaML contains all theinformation present in the code to characterize the method, in particular itssignature and its body. However, in the UML metamodel, this information isdistributed across an Operation vertex, maintaining information about the signa-ture, and a Method vertex which simply contains the code of the method body. Asregards the signature, similarly to before, we relate Method and Operationvertices and we check the agreement of the type information, without associatingthe type subvertices for method to the Classifier vertices describing those types inUML. This is due to the fact that a type vertex is present in JavaML every timeit is necessary, but, in a UML diagram, it needs to be present only once, andassociated with other vertices an arbitrary number of times.

To model not only the static declaration of a method, but also its behavior throughcollaboration, sequence, state, or activity diagrams, we recur to action seman-tics as defined in OMG (2003). Here, a Method is associated with a Procedure,which has a Composition relation with an Action vertex. We put such an Action incorrespondence with the stmt-elems vertex, usually a block, which is the root ofthe subtree for the description of the method vertex. In general, we want to putinto relation semantically equivalent elements, so we will consider the differenttypes of Action that can be associated with stmt-elems. A major difference exists,though. The JavaML file presents the stmt-elems of a block in an order whichcorresponds to the sequence of statements in the original code. The UML modelon the other hand, does not require an order to be specified for independentactions. Control flow actions indeed exist, such as ConditionalAction or LoopAction,and idioms such as Iteration can be expressed. However, actions not relatedthrough some chain of DataFlow objects, need not be realized in any given order.If desired, though, the modeler can prescribe the existence of ControlFlowobjects, defining predecessor and successor Actions.

The process of building such correspondences, i.e., of introducing elements in theinterface graph and establish the morphisms from this to the code and modelgraphs can be modeled by rewriting rules. Figure 15 shows two local rules whosedistributed application on the code and model graph, respectively, produces thefollowing effect: if there are, both in the code and model graph, elementsrepresenting a class s which is a superclass for a class c whose representations



in the two graphs have already been put in correspondence, as witnessed by theidentifiers c1 and c1’ for the two instances, then the two representations of classs are put in correspondence, as witnessed by the generation of the identifiers c2and c2’.

Behavior Preservation in Refactoring

The refactorings in Section 4 are historical ones, whose behavior preservationproperties are widely discussed. In general, it is important to have a methodologyto formally verify properties of new refactorings. The approach based on graphtransformations provides a formal basis to perform these checks and to generateconditions ensuring the desired preservation properties. We restrict our discus-sion to checks that can be carried out statically, not based on flow analysis.

Several kinds of behavior preservation are relevant to the refactorings studiedhere. Some of them are briefly described next (Mens et al., 2002):

• Type preservation: the refactoring does not change the type of any entitynot deleted.

• Access preservation: the refactoring maintains the access of a method toat least the same variables accessed before the refactoring, possiblythrough intermediate method calls.

Figure 15. Two rules to establish correspondences concerning classinheritance

c1‘: classname = c

: java-class-file

: superclassname = s


: java-class-file


: classname = s

c2‘: classname = s


: java-class-file



: java-class-file


: classname = s

c2‘: classname = s

c1:Classname= c

:Classname= s

c1:Classname= c

c2:Classname= s

:Generalization

generalizationspecialization

:Generalization


c1:Classname= c

:Classname= s

c1:Classname= c

c2:Classname= s

:Generalization


:Generalization




• Update preservation: each refactored method causes the same variablechanges as before.

• Call preservation: each method causes the execution of at least the samemethods called before the refactoring.

The refactorings presented here are based on typed graph transformations.Since these transformations always guarantee that all the resulting graphs arecorrectly typed over the same type graph, type preservation (according to thetype graph) is always exhibited by them.

Well-Formedness Constraints

This kind of behavior preservation is not sufficient to ensure that the resultinggraph is an acceptable code or model graph. Well-formedness constraints areneeded to rule out undesired configurations of the produced graph (instance ofthe type graph). For example, we have seen the requirement that no names,whether for variable or method, are in conflict in any class.

Refactoring-specific constraints addresses the problem of unwanted side ef-fects. These constraints can be expressed with pre and/or post-conditions. Withthe latter, if the post-condition is not met, the transformation must be “undone”and the previous model restored. With the former (more efficient) method,application conditions are checked to prevent the transformation by a refactoringif it produces unwanted effects. For example, a new method m defined in classC should not override an existing method m with the same signature in a subclassof C, or be overridden by an existing method with the same signature defined ina superclass of C. This constraint is needed, for example, in both samplerefactorings presented in the section, Refactoring by Graph Transformation.

Not all constraints can be expressed by simple “forbidden” graphs. More generalconstraints can be defined by using propositional logic (Matz, 2002) to compose“atomic” constraints, formed by simple forbidden graphs, and injective graphmorphisms describing the conditional existence of graph (sub)structures (Koch,Parisi Presicce, 2002).

For example, to express the fact that no method of arity one is allowed to havethe same name and a parameter of the same type as another method in the sameclass, we can write the formula NOT two_methods_with_same_signature wherethe constraint graph is presented in Figure 16. This formula is satisfied only if itthere are not two methods named mnew in a model graph having each exactly oneparameter of the same type.



Knowing the maximum number of arguments for a method, we can constructsimilar forbidden configurations for each number of arguments. Generalizing thisidea, we have to define graph constraint schemes, typically using set vertices(Bottoni et al., 2000), to be matched to any number of arguments.

Consistent Refactorings

In order to show that well-formedness constraints are satisfied after theapplication of refactoring rules, we can enlist the help of established results onconsistent graph transformations in Heckel et al. (1995). That approach consistsof first translating graph constraints into post-conditions of transformation rulesand then forming pre-conditions out of those post-conditions by applying the rulesbackwards. In the special case of a forbidden subgraph as constraint, thisconstruction would yield a number of NACs for the rule, preventing theapplication of the rule if it causes the construction of the forbidden subgraph.For example, the application of this construction to the constraint in Figure16 would yield NACs for the rule in Figure 13, in the case of method“get”+varname.

Figure 16. Constraint graph expressing the well-formedness of methodswith one parameter

: Classifier

: Parameterkind = #in

: Methodname=mnew

: Classname = target

owner

feature

typeparameter

: Methodname=mnew

typeparameter

owner

feature


: Classifier


: Methodname=mnew

: Classname = target

owner

feature

typeparameter

: Methodname=mnew

typeparameter

owner

feature


two_methods_with_same_signature:



Conclusions

We have presented a graph transformation-based approach to maintainingconsistency between code and model diagrams in the presence of refactorings.The approach allows the coordinated transformation of two graphs representingthe abstract syntax, as derived from the code by a parser, and the UML modelof the software system. A correspondence is established between these twographs, starting from the correspondence between types of vertices in theabstract syntax trees, as defined by the JavaML markup language, and types ofelements and associations in the UML diagrams, as defined by the UML meta-model.

Although the approach has been demonstrated using Java and the JavaMLcoding of its abstract syntax, it can be applied to any type of abstract syntax forobject-oriented languages, provided that a non-ambiguous correspondencebetween the abstract syntax and the UML model components can be estab-lished. As a consequence, an integrated tool which is able to perform refactoringon code and model diagrams while maintaining the original correspondencesbetween these components is imaginable. This would require integrating theability of modern refactoring tools to manipulate ASTs, with a more generalinterpreter for transformation units. Indeed, it is not needed that the tool exploitsgraph transformations in order to manipulate the tree. As all refactorings areindividually described by a transformation unit, and a tool has a finite number ofthem available, it is sufficient that the tree transformation is wrapped. In this way,the parameters can be communicated to the other parts of a distributedtransformation. If the transformation occurs on a part of the code for which thecorresponding parts of the model have been identified, the relevant modificationswould automatically be performed.

The opposite process could also be envisaged in which a refactoring of a modelwould reflect a modification of the corresponding code. This can be easilyperformed on structural diagrams, for which we have seen that there is a closecorrespondence between elements of JavaML and of the UML meta-model.Future work will have to identify refactorings in the behavioral diagrams forwhich it is possible to identify the needed transformations in the code.

Acknowledgments

Partially supported by the EC under Research and Training Network SeGraVis.



References

Badros, G. (2000). JavaML: A Markup Language for Java Source Code. 9th

Int. World Wide Web Conference. JavaML-Homepage. Retrieved fromthe WWW: http://www.cs.washington.edu/homes/gjb/JavaML

Bottoni, P., Parisi Presicce, F. & Taentzer, G. (2003). Specifying IntegratedRefactoring with Distributed Graph Transformations. In J. L. Pfaltz, M.Nagl, & B. Böhlen (Eds.), Applications of Graph Transformations withIndustrial Relevance. Second International Workshop, AGTIVE 2003,LNCS 3062, Springer, pp. 220-235.

Bottoni, P., Schuerr, A. & Taentzer, G. (2000). Efficient Parsing of VisualLanguages based on Critical Pair Analysis (and Contextual Layered GraphTransformation). Proc VL 2000, (pp. 59-61).

Corradini, A. Montanari, U. Rossi, F. Ehrig, H., Heckel, R. & Löwe, M. (1997).Algebraic approaches to graph transformation part {I}: Basic concepts anddouble pushout approach. In G. Rozenberg (Ed.), Handbook of GraphGrammars and Computing by Graph transformation, Vol. 1. WorldScientific, 163-246.

Fischer, I., Koch, M., Taentzer, G. & Volle, V. (1999). Visual Design ofDistributed Systems by Graph Transformation. In H. Ehrig, H.J. Kreowski,U. Montanari & G. Rozenberg (Eds.), Handbook of Graph Grammarsand Graph Transformation, (Vol. 3, pp. 269-340).

Fowler, M. (1999). Refactoring: Improving the Design of Existing Pro-grams. New York: Addison-Wesley.

Heckel, R. & Wagner, A. (1995). Ensuring Consistency in Conditional GraphGrammars: A Constructive Approach. Proceedings of SEGRAGRA’95,ENTCS, Vol.2. Retrieved from the WWW: http://www.elsevier.nl/locate/entcs/volume2.html

Koch, M. & Parisi Presicce, F. (2002). Describing policies with graph con-straints and rules. In A. Corradini, H. Ehrig, H.J. Kreowski & G. Rozenberg(Eds.), Proc. ICGT 2002, LNCS 2505, Springer, 223-238.

Kreowski, H.J., Kuske, S. & Schürr, A. (1997). Nested graph transformationunits. International Journal on Software Engineering and KnowledgeEngineering, 7(4), 479-502.

Matz, M. (2002). Design and Implementation of a Consistency CheckingAlgorithm for Attributed Graph Transformation. (In German.) DiplomaThesis, Technical University of Berlin.



Mens, T. (2000). Conditional Graph Rewriting as a Domain-Independent For-malism for Software Evolution. In Proceedings of AGTIVE’99, LNCS1779, (pp. 127-143). Springer-Verlag.

Mens, T. (2001). Transformational Software Evolution by Assertions. Proc.Wks. on Formal Foundations of Software Evolution (pp. 67-74).

Mens, T., Demeyer, S. & Janssens, D. (2002). Formalising Behaviour Preserv-ing Program Transformations. In Proceedings of IGCT2002, LNCS,2505 (pp. 286-301). Springer-Verlag.

Metz, P., O´Brien J. & Weber, W. (2002, July). Use Case Model Refactoring:Changes to UML’s Use Case Relationships. Internal Research Report,Department of Computer Science, Darmstadt University of Applied Sci-ences.

Niere, J., Wadsack, J.P. & Zündorf, A. (2001). Recovering UML Diagramsfrom Java Code using Patterns. Proceedings of the Second Workshop onSoft Computing Applied to Software Engineering.

OMG. (2003). UML Specification 1.5. Retrieved from the WWW: http://www.omg.org/uml

Opdyke, W.F. (1992). Refactoring Object-Oriented Frameworks. PhD The-sis. University of Illinois. Retrieved from the WWW: ftp://st.cs.uiuc.edu/pub/papers/refactoring/opdykethesis.ps.Z

Roberts, D. (1999). Practical Analysis for Refactoring. PhD Thesis. Univer-sity of Illinois at Urbana-Champaign.

Sunyé, G., Pollet, D., LeTraon, Y. & Jézéquel, J.M. (2001). Refactoring UMLmodels. Proceedings of UML 2001, LNCS, 2185 (pp. 134-138). Springer-Verlag.



Section II

Elaboration ofTransformation

Approaches

Declarative Transformation for Object-Oriented Models 127


Chapter VI

DeclarativeTransformation for

Object-OrientedModels

Keith Duddy, CRC for Enterprise Distributed Systems Technology(DSTC), Queensland, Australia

Anna Gerber, CRC for Enterprise Distributed Systems Technology(DSTC), Queensland, Australia

Michael Lawley, CRC for Enterprise Distributed Systems Technology(DSTC), Queensland, Australia

Kerry Raymond, CRC for Enterprise Distributed Systems Technology(DSTC), Queensland, Australia

Jim Steel*, CRC for Enterprise Distributed Systems Technology(DSTC), Queensland, Australia

Abstract

This chapter provides a context and motivation for a language to describetransformations of models within an object-oriented framework. Therequirements for such a language are given, and then an object-oriented

128 Duddy, Gerber, Lawley, Raymond, and Steel


model of the language’s abstract syntax is provided that meets theserequirements. A concrete syntax is introduced along with some exampletransformations. Finally, we discuss the tools required to use the languagewithin a model-driven software engineering paradigm. The authors aim todemonstrate the principles of model transformation within an object-oriented framework, and show how this can be applied to the developmentof software systems.

Introduction

In Model-Driven Architecture - A Technical Perspective (2001), the ObjectManagement Group (OMG) describes an approach to enterprise-distributedsystem development that separates the specification of system functionalityfrom the specification of the implementation of that functionality on a specifictechnology platform. The MDA approach envisions mappings from Plat-form Independent Models (PIMs) to one or more Platform Specific Models(PSMs).

The potential benefits of such an approach are obvious: support for systemevolution, high-level models that truly represent and document the implementedsystem, support for integration and interoperability, and the ability to migrate tonew platforms and technologies as they become available.

While technologies such as the Meta Object Facility (MOF v1.3.1, 2001) and theUnified Modelling Language (UML, 2001) are well-established foundations onwhich to build PIMs and PSMs, there is as yet no well-established foundationsuitable for describing how we take an instance of a PIM and transform it toproduce an instance of a PSM.

In addressing this gap, our focus is on model-to-model transformations and noton model-to-text transformations. The latter come into play when taking a finalPSM model and using it to produce, for example, Java code or SQL statements.We believe that there are sufficient particular requirements and properties of amodel-to-text transformation, such as templating and boilerplating, that aspecialised technology can be used. One such technology is Anti-Yacc (Hearnden& Raymond, 2002) and we deal briefly with such concrete syntax issues later inthe chapter.

This chapter focuses on a particular program transformation language, designedspecifically for use with object-oriented models and programming languages.We provide an overview of the general problem of software model transforma-tion and survey some technologies that address this space. The technology wethen describe is designed to satisfy a set of identified requirements and is



illustrated with a variety of example transformation specifications. We payparticular attention to how its features easily handle complex transformationsand enable modular, composable, and extendable transformation rules withoutimposing an undue burden on the writer of the rules.

Transformation for Enterprise-Distributed Systems Development

In order to build and maintain the IT systems supporting large-scale enterprise-distributed systems efficiently, descriptions of these systems at the domain levelneed to be automatically transformed into components, code, and configurations.The use of a transformation language designed to support the features of modernobject-oriented specification and implementation technologies leads to moreflexible, maintainable, and robust transformations than present ad-hoc ap-proaches.

The Meta Object Facility (MOF) is a technology specification standardised bythe OMG in 1997. It provides an object-oriented framework for the specificationof the abstract syntax of modeling languages. Space limitations do not permit adetailed description of MOF features, however, one can think of MOF modelsas corresponding to a slightly simplified UML Class Diagram.

The benefits of using this facility for the specification of languages such as theUnified Modelling Language (UML) are that there are standard mechanismsfor automatically deriving:

• a set of interfaces in CORBA IDL or Java for programmatic access toobject model repositories,

• a concrete syntax based on XML DTDs and/or schemas known as XMLModel Interchange (XMI), and

• a customisable human-usable textual notation or HUTN (Human-UsableTextual Notation, 2002) for representing model instances.

However, to date, the common MOF foundation of OMG languages such asUML, the Common Warehouse Metamodel (CWM) and the EnterpriseDistributed Object Computing (EDOC) model has not enabled the use of a modelin one language to be transformed into a model in another language, except bythe following limited means:

• An XML document representing one model in the standard XMI form maybe manipulated using XSLT to produce another model.



• A program may traverse the model using CORBA or Java interfaces, andpopulate another model in a different repository.

• Partial transformations of data may be described in the CWM.

All of these approaches have some usefulness. However, a language fordescribing the generic transformation of any well formed model in one MOFlanguage into a model in some other MOF language (or perhaps in the samelanguage) is not yet available in a standard form. The OMG has issued MOF 2.0Queries/Views/Transformations RFP (2003), known as QVT for short. Itrequires submissions to:

• define a language for querying MOF models,

• define a language for transformation definitions,

• allow for the creation of views of a model,

• ensure that the transformation language is declarative and expressescomplete transformations,

• ensure that incremental changes to source models can be immediatelypropagated to the target models, and

• express all new languages as MOF models.

In developing our response to the QVT RFP, the authors considered a numberof alternative approaches (Gerber, Lawley, Raymond, Steel & Wood, 2002). Theresults, along with a review of other submissions to the QVT RFP, aresummarised below.

Chapter 13 of the OMG’s Common Warehouse Metamodel Specification (2001)defines a model for describing transformations. It supports the concepts of bothblack-box and white-box transformations. Black-box transformations only asso-ciate source and target elements without describing how one is obtained from theother. White-box transformations, however, describe fine-grained links betweensource and target elements via the Transformation element’s association to aProcedureExpression. Unfortunately, because it is a generic model and re-uses concepts from UML, a ProcedureExpression can be expressed in anylanguage capable of taking the source element and producing the target element.Thus CWM offers no actual mechanism for implementing transformations,merely a model for describing the existence of specific mappings for specificmodel instances.

Varró and Gyapay (2000) and Varró, Varraó and Pataricza (2002) describe asystem for model transformation based on Graph Transformations (Andries etal., 1999). In their approach, a transformation consists of a set of rules combined



using a number of operators such as sequence, transitive closure, and repeatedapplication. Each rule identifies before and after sub-graphs, where each sub-graph may refer to source and target model elements and associations betweenthem (introduced by the transformation).

This style of approach to model transformation introduces non-determinism inthe rule selection, and in the sub-graph selection when applying a rule.

Additionally, since rules are applied in a sequence, thus resulting in a series ofstate changes, one needs to be very careful about the order of rule applicationand repeated rule application to ensure termination of the transformationprocess. A common technique is to delete elements from the source model asthey are transformed, but this requires that an element is transformed with asingle rule rather than allowing multiple rules to address different aspects of thetransformation.

Peltier, Ziserman and Bezevin (2000) and later, Peltier, Bezevin and Guillaume(2001) and Alcatel, Softeam, Thales and TNI-Valiosys (2003) in their QVT RFPresponse propose that transformation rules are best expressed at the model level,and that they should then be translated into a set of rules that operate on theconcrete representations of model instances. As such, they propose MOF as thecommon meta-model for representing models, XMI as the concrete expressionof model instances, and XSLT as the transformation tool to operate on theseconcrete instances.

Their rules have a mix of both procedural and declarative styles that is in part dueto the fact that a given rule may only define a single target element per sourceelement and that target element construction is explicit. They also require explicitordering of the execution of rules.

XSLT (W3C, 1999) is explicitly designed for the transformation of XMLdocuments and, through the XMI specification, all MOF models have an XML-based expression. However, being document-driven, XSLT is limited to source-driven transformations, and only provides for explicit object (or element)creation. Additionally, the XSLT syntax is both verbose and baroque, as it isbased on XML. These reasons make it wholly unsuitable as an expressive modeltransformation language.

The UML 1.4 specification introduces a new Action Semantics language (ASL),which has also been proposed by both Kennedy Carter (2003) and TataConsultancy Services (2003) as a model transformation language. The ASLprovides a number of low-level constructs that can be composed to providespecifications of actions. However, in order to be fully expressive for describingactions, ASL is defined at a very low level of abstraction, lower than appropriatefor model transformation. Furthermore, it is an imperative language, so it doesnot provide for implicit creation, or unordered rule evaluation.



Codagen Technologies (2003) propose an extension to XQuery and XPATH forselecting/querying MOF models, and a procedural templating language (MTDL)for constructing target model elements. In contrast, Interactive Objects Soft-ware GmbH & Project Technology (2003) propose the use of OCL 2.0 (2003)for querying/selecting source model elements and a declarative language forconstructing target model elements. Because there can only be a single creationrule that gives rise to a target model element, this proposal also effectively usesexplicit object creation, which we believe is an unfavourable approach to buildingscalable and re-usable transformation definitions.

Finally, Compuware & Sun Microsystems (2003) propose a language that isbased on OCL 2.0 for queries/selection, is declarative, uses implicit creation, andresults in links between target model elements and the source model elementsthat lead to their creation. However, the language is defined as a minimalsubtyping of the MOF meta-model and consequently provides little in the way ofstructuring mechanisms to guide the user in writing transformation definitions.

Design Requirements for OO-BasedTransformation

Consider the problem of representing data described by an object-oriented classdiagram in a relational database. Figure 1 shows possible models of the conceptsinvolved in these two domains.

This is an interesting transformation problem because the two models arefamiliar to many people, and they are not so similar that a transformation isessentially one-to-one. Additionally, there are simple alternative transformations

Figure 1. Simple source and target models

name : String

NamedElt

isAbstract : boolean

Classifier

ClassDataType

multivalued : boolean

Attribute

1

attr

*

*

type

1

super

*

sub *

-name : String

Named

Table Column

0..1 key *

1

col

*

Type

*

type

1



possible that result in different performance characteristics that we can alsoexplore.

Let us consider what such a transformation might involve. Firstly, we mightexpect each Class to have a corresponding Table, each DataType to have acorresponding Type, and each Attribute of each Class to have a correspondingColumn in the corresponding Table. Since our class model doesn’t contain anyinformation about the combination of attributes (if any) that constitute a key, wewill also need a Column per Table to represent an object-id.

However, note that an Attribute may be multi-valued, so it would be ratherinefficient to store all the other attributes multiple times in order to store the multi-valued attribute. Instead, we want a separate table for each Column correspond-ing to a multi-valued Attribute along with a Column for the object-id so we canperform the requisite joins.

If an Attribute’s type is a DataType, then the corresponding Column’s typewould be the Type corresponding to the DataType. But if the Attribute’s type isa Class, then the corresponding Column would need to be a foreign key, so itstype would be that of the (primary) key of the referenced table which is theobject-id Column.

So far, describing the transformation has been relatively straightforward. Thingsget more interesting once we consider that one Class can subtype another Class.As we have described the mapping so far, an instance of a subclass ends up withits attributes split between several tables. An alternative transformation involvescreating a Column for every Attribute owned by a Class and for every Attributeowned by a supertype of the Class.

Below we show, step by step, how one would express the transformationsdescribed above in our language. However, before we look at these details wereflect on the high-level natural-language description of the transformation wehave just outlined in order to motivate the design of our language.

The first thing to notice is that the description above is naturally declarative. Itdescribes the things we want to generate and the reasons why we want togenerate them, but it does not say how or when to create them, not does it involvea description of traversing either the source or the target models. Additionally,while there are natural dependencies between parts of the description, there isno explicit statement of “do this then do that”. Rule ordering is implicit, notexplicit. Since the declarative style is a natural way to communicate a transfor-mation description in a human language, we believe it is also suitable, indeedpreferable, for a formal language for specifying transformations to be declara-tive.

A set of functional and usability requirements for a transformation language hasbeen developed by Gerber, Lawley, Raymond, Steel and Wood (2002). A



detailed list of these is presented in our response (DSTC, IBM & CBOP, 2003)to the OMG’s QVT RFP.

The major functional requirements are as follows. A model-transformationlanguage must be able to:

• match elements, and ad-hoc tuples of elements, by type (include instancesof sub-types) and precise-type (exclude instances of sub-types);

• filter the set of matched elements or tuples based on associations, attributevalues, and other context;

• match both collections of elements not just individual elements. Forexample, we may need to count the number of Attributes a Class has;

• establish named relationships between source and target model elements.These relationships can then be used for maintaining traceability informa-tion;

• specify ordering constraints (of ordered multi-valued attributes or orderedassociation links), either when matching source elements or producingtarget elements;

• handle recursive structure with arbitrary levels of nesting. For example, todeal with the subclassing association in our example Class model;

• match and create elements at different meta-levels;

• support both multiple source extents and multiple target extents.

In addition, the following non-functional requirements, identified for readabilityand expressiveness concerns, require that:

• there is no requirement to explicitly specify the application order of therules, and all rules are matched against all relevant source elements;

• creation of target objects is implicit rather than explicit. This follows fromthe previous requirement; if there is no explicit rule application order, thenwe cannot know which rule creates an object and are relieved of the burdenof having to know;

• a single target element can be defined by multiple rules. That is, differentrules can provide values for different attributes of the same object;

• patterns can be defined and rules are able to be grouped naturally forreadability and modularity;

• embedding of conditions and expressions in the language is explicit andseamless;

• transformation rules are composable.



Our experiences have shown that there are three fairly common styles tostructuring a large or complex transformation, reflecting the nature of thetransformation. They are:

• Source-driven, in which each transformation rule is a simple pattern (oftenselecting a single instance of a class or association link). The matchedelement(s) are transformed to some larger set of target elements. This styleis often used in high-level to low-level transformations (e.g., compilations)and tends to favour a traversal style of transformation specification. Thisworks well when the source instance is tree-like, but is less suited to graph-like sources;

• Target-driven, in which each transformation rule is a complex pattern ofsource elements (involving some highly constrained selection of variousclasses and association links). The matched elements are transformed to asimple target pattern (often consisting of a single element). This style isoften used for reverse-engineering (low-level to high-level) or for perform-ing optimizations (e.g., replacing a large set of very similar elements witha common generic element);

• Aspect-driven, in which the transformation rule is not structured aroundobjects and links in either the source or target, but more typically aroundsemantic concepts, e.g., transforming all imperial measurements to metricones, replacing one naming system with another, or the various parts of theobject-relational transformation described above.

Indeed, aspect-driven transformations are a major reason why we favour implicit(rather than explicit) creation of target objects, since aspect-driven transforma-tion rules rarely address entire objects, and thus it is extremely difficult todetermine which of several transformation rules (that may or may not apply toany given object) should then have responsibility for creating the target object.Typically the target object is only required if any one of the transformation rulescan be applied, but no target object should be created if none of the rules can beapplied. This is extremely difficult to express if explicit creation is used.

A Declarative Object-OrientedTransformation Language

We describe a declarative object-oriented transformation environment thatsatisfies the requirements described in the previous section. We present both a



formal model for transformations and a concrete syntax and illustrate thetransformation language through a series of simple examples.

This section presents the transformation language that we have designed toaddress the problems faced when realising the MDA, by illustrating how thelanguage would be used to solve the object-relational mapping problem at hand.

A transformation in our language consists of the following major concepts:transformation rules, tracking relationships, and pattern definitions.

• Transformation rules are used to describe the things that should exist ina target extent based on the things that are matched in a source extent.Transformation rules can be extended, allowing for modular and incremen-tal description of transformations. More powerfully, a transformation rulemay also supersede another transformation rule. This allows for general-case rules to be written, and then special-cases dealt with via supersedingrules. For example, one might write a naive transformation rule initially,then supersede it with a more sophisticated rule that can only be appliedunder certain circumstances. Superseding is not only ideal for rule optimi-zation and rule parameterization, but also enhances reusability sincegeneral purpose rules can be tailored after-the-fact without having tomodify them directly.

• Tracking relationships are used to associate a target element with thesource elements that lead to its creation. Since a tracking relationship isgenerally established by several separate rules, other rules are able tomatch elements based on the tracking relationship independently of whichrules were applied or how the target elements were created. This allowsone set of rules to define what constitutes a particular relationship, whileanother set depends only on the existence of the relationship withoutneeding to know how it was defined. This kind of rule decoupling is essentialfor rule reuse via extending and superseding to be useful.

Establishing and maintaining Tracking relationships is also essential forsupporting round-trip development and the incremental propagation ofsource-model updates through the transformation to the target model(s).

• Pattern definitions are used to label common structures that may berepeated throughout a transformation. A pattern definition has a name, a setof parameter variables, a set of local variables, and a term. Parametervariables can also be thought of as formal by-reference parameters.Pattern definitions are used to name a query or pattern-match defined bythe term. The result of applying a pattern definition via a pattern use is acollection of bindings for the pattern definition’s parameter variables.



Figure 2. Transformation model

-nam

e-s

rcM

odel

-tgt

Mod

el

Tra

nsf

orm

atio

n

-nam

eTR

ule

-tra

nsfo

rmat

ion

1

-tru

le*

-sup

erce

dee

*

-sup

erce

der *

-ext

ende

e*

-ext

ende

r*

-ext

ende

e*

-ext

ende

r

*-n

ame

Pat

tern

Def

n

-tra

nsfo

rmat

ion1

-pat

tern

Def

n*

0..1 -bod

y

0..1

-dom

ain

Tra

ckin

g

Sco

pe

-nam

e-lo

calV

ar

-sco

pe

1

-va r *

-tru

le

1

-tra

ckin

g *

Ter

m

-ext

ende

e*

-ext

ende

r*

-sup

erce

dee

*

-sup

erce

der

*

Exp

r

Var

Use

-var

1

-use

*

-tra

ckin

g0.

.1

-tar

get 1

-tra

ckin

g*

-sou

rce *

Co

mp

ou

nd

Ter

m

An

dT

erm

OrT

erm

-ifT

erm

: T

erm

-the

nTer

m :

Ter

m-e

lseT

erm

: T

erm

IfT

erm

Mo

fTer

m

-ext

ract

ion

-fea

ture

Mo

fFea

ture

Pat

tern

Use

-def

n*

-use

*

-sim

pleT

erm

0..1

-arg *

-dom

ain

Tra

ckin

gU

se

Sim

ple

Ter

m

-rep

rese

ntat

ion

Sim

ple

Exp

r

Bo

ole

anC

on

stan

tE

nu

mC

on

stan

tIn

tCo

nst

ant

Str

ing

Co

nst

ant

-kin

d

Co

llect

ion

Exp

r

-exp

r

0..1

-arg

*

-nam

e

Nam

edE

xpr

-ope

rato

r

Fu

nct

ion

Exp

r

Co

mp

ou

nd

Exp

r

-com

poun

dTer

m

0..1

-ter

m*

-tru

le

0..1

-src

0..1

-tru

le

0..1

-tgt

*

-typ

e

Mo

fIn

stan

ce

-typ

eMo

fLin

k

-less

er :

Mof

Link

-gre

ater

: M

ofLi

nk

Mo

fLin

kOrd

er

-less

er :

Mof

Fea

ture

-gre

ater

: M

ofF

eatu

re

Mo

fFea

ture

Ord

er



The MOF model diagram in represents our current proposed Transformationmodel (DSTC, IBM & CBOP, 2002). The important classes are explained in thefollowing text.

The lower part of Figure 2 is an expression language metamodel constructedspecifically for identifying MOF model elements in patterns and rules. Its twomain abstract metaclasses are Term and Expression. Terms are evaluated to beeither true or false with respect to the models supplied for transformation. AnExpression represents some kind of value referenced by a Term. VarUse is aparticular kind of Expression that represents the binding of a value to a variable.Variables in the language are dynamically typed, and a Var slot may bind to any validMOF type.

The top left part of Figure 2 shows the main structuring parts of the model. TRulerepresents a transformation rule, which is a statement that for all model elementsthat can be bound to the Vars of the TRule’s src Term such that this Termevaluates to true the TRule’s tgt Terms must also evaluate to true. Generally, thisinvolves creating new MOF model elements in the target model(s) and settingtheir attributes. In order to know when and how many model elements to create,Trackings are used. A Tracking is a statement of a functional dependencybetween a set of source model elements and a target model element. This allowsseveral independent rules to require a target object to exist without needing toexplicitly coordinate which rule is responsible for actually creating the instance.

Transformation rules may be related to other transformation rules in either orboth of the following two ways:

• A rule that extends another rule augments its source matching term withthe source term of the extended rule.

• A rule that supersedes another rule restricts the source matching term ofthe superseded rule with the negation of its source term.

Rule extending and superseding allow for Transformations, which supply anamespace for rules and pattern definitions, to be reused and specialised. Inparticular, they allow rules to be written simply for the general case, and thensuperseded for some special or exceptional cases.

Concrete Syntax by Example

We now present the transformation described earlier using an SQL-like concretesyntax one rule at a time, based on one rule per concept-to-concept mapping. Wethen link these together and fill in details to provide the total transformation fromour OO model to our Relational model.



The first key element of our transformation is that a Class will be transformedinto a Table with an object-id Column, so this becomes our first rule. We alsowant to make sure that we preserve a tracking relationship between the table wecreate and the class from which we create it. The next major mapping, from anAttribute to a Column, is similar, as is the rule for DataTypes. As such, we startwith the following simple rules:

RULE class2table

FORALL Class Cls

MAKE Table Tbl, Column idCol,

idCol.name="id", Col.owner=Tbl

LINKING Cls to Tbl by c2t;

RULE attr2col

FORALL Attribute Att

MAKE Column Col

LINKING Att to Col by a2c;

Both Class and Attribute are subtypes of NamedElt, and we want their namesto be mapped to the names of their corresponding Tables and Columns. We canmake sure we have the right Class-Table or Attribute-Column pair by looking upthe tracking relationships we established earlier. We can then write a rule froman OO NamedElt to a Relational Named like this:

RULE named2named

FORALL NamedElt n1

WHERE c2t LINKS n1 to n2

OR a2c LINKS n1 to n2

MAKE Named n2,

n2.name = n1.name;

We see here that trackings can be used to tie rules together, thus giving us theability to express rules as fine-grained mappings rather than having to writecomplex, coarse-grained rules.

However, further inspection of our class diagram reveals that DataType namesmust also be mapped. Rather than adding another OR clause to our rule, weintroduce generalization to our tracking relationships. So, we make another



tracking relationship that stands as a superset of the two we have already used,and look up the parent tracking rather than alternating over the children, like so:

TRACKING c2t ISA named2named;

TRACKING a2c ISA named2named;

RULE named2named

FORALL NamedElt n1

WHERE named2named LINKS n1 to n2

MAKE Named n2, n2.name=n1.name;

Next, we need to make sure that the column resulting from the transformationof an attribute will be contained by the appropriate table, i.e., the table resultingfrom the transformation of the attribute’s containing class. We do this by againlooking up the tracking relationships established in our earlier rules. This givesus the following rule:

RULE clsAttr2tblCol

FORALL Attribute Att, Class Cls

WHERE Att.owner = Cls

AND c2t LINKS Cls to Tbl

AND a2c LINKS Att to Col

MAKE Table Tbl, Column Col,

Col.owner = Tbl;

We already have a rule for transforming Attributes. However, we now find thatwe wish to transform multi-valued attributes differently. The values of a multi-valued attribute will be stored in a separate table, with one column for the valuesand one column for the Class’s object-id.

This new rule for attributes will need to match a subset of the cases that weretrue for the previous rule, and we can reuse the earlier Attribute rule’s matchingpattern by using rule extension. However, we also want to indicate that theearlier Attribute rule should not run when this new Attribute rule runs, and wecan do this using rule supersession.

So now we have a rule for transforming Attributes to Columns, and another forlinking the Column to a Table. However, we find that we want to map multi-valued attributes differently. The Column for a multi-valued Attribute should



instead have its own Table, with another Column to link back to the key in themain Table for the Class. Therefore, we make a new rule that will supersede therule that puts Columns in Tables, and link the Attribute’s Column to a new Tablewith a new key Column.

RULE clsMultiAttr2tblCol extends

and supersedes clsAttr2tblCol

FORALL Attribute Att, Class Cls,

WHERE Att.multivalued = TRUE

MAKE Table AttTbl, Column KeyCol,

Column AttCol,

KeyCol.owner=Tbl, AttCol.owner=Tbl,

KeyCol.name = Cls.name

LINKING Att to AttTbl by mva2t;

Having created and placed these Columns, we need to give them an appropriatetype. So we need rules for mapping DataTypes to Types, and for assigning theappropriate Type to a Column. The latter case requires two rules, since anAttribute with a Class type is typed for a key value, but an Attribute with aDataType type is mapped for the corresponding Type.

TRACKING dt2t ISA named2named

RULE datatype2type

FORALL DataType Dt

MAKE Type T

LINKING Dt to T by dt2t;

RULE atype2ctype

FORALL Attribute Att, DataType Dt

WHERE a2c LINKS Att to Col

AND dt2t LINKS Dt to T

AND Att.type = Dt

MAKE Column Col, Type T,

Col.type = T;



RULE actype2ctype

FORALL Attribute Att, Class C

WHERE Att.type = C

AND a2c LINKS Att to Col

MAKE Column Col, Type T,

Col.type = T, T.name = "String";

The other approach to mapping attributes, as described above, is to includeinherited attributes as columns in the tables of subclasses. To do this, we needto define a recursive Pattern for finding the inherited attributes of a class.

PATTERN hasAttr(C, A)

FORALL Class C, Attribute A, Class C2

WHERE A.owner = C

OR (C.super = C2 AND hasAttr(C2, A));

Having defined this pattern, we can make a rule for creating a column for eachinherited attribute. To handle the linking of these columns to their tables, we needto change the Attribute to Column tracking to include Class as a source, bymodifying the earlier rules, attr2col and clsAttr2tblCol. The new rule,as well as these modified rules, is below:

RULE superattr2col


WHERE hasAttr(Cls, Att)

AND c2t LINKS Cls to Tbl

MAKE Table Tbl, Column Col

LINKING Att, Cls to Col by a2c;

RULE attr2col

FORALL Attribute Att, Class C

WHERE Att.owner = C

MAKE Column Col

LINKING Att, Cls to Col by a2c;



RULE clsAttr2tblCol


WHERE c2t LINKS Cls to Tbl

AND a2c LINKS Att, Cls to Col

MAKE Table Tbl, Column Col,

Col.owner = Tbl;

While some people may be daunted by the idea of specifying transformationsusing a declarative language, we believe that the use of an appropriate concretesyntax such as the SQL-like one introduced above will allay their fears and allowthem to reap the benefits of not needing to worry about rule order and explicitobject creation that a declarative language affords. Additionally, an equivalentgraphical syntax would be a useful addition for simple transformations, althoughour experiences indicate that more complicated transformations are betterhandled textually.

Advanced Transformations

As with expert systems, a substantial transformation embodies a significantinvestment in capturing domain knowledge and, therefore, the careful organisationand structuring of the transformation will aid its long-term maintenance andevolution.

Several features of the transformation language described in this chapter are keyto supporting both re-use and maintenance of transformation definitions. Thesefeatures are the supersedes and extends relationships, and dynamic typing ofvariables.

Duddy, Gerber, Lawley, Raymond & Steel (2003) describe in detail howsuperseding and extending can be used in the context of a transformation to anEntity Java Bean (EJB) model. Specifically, they show how a mapping thatresults in remote access to EntityBeans can be modified to instead employ theSession Façade pattern (Brown, 2001) using a SessionBean that delegatesmethods to local EntityBeans. One could also use an extra source model as aparameterisation, or marking model, to provide finer grain control over whichrules are applied to which source model elements.

Dynamic typing simplifies rule writing: if an object bound to a variable does nothave the attribute or reference mentioned in a term, then the term simplyevaluates to false rather than requiring explicit runtime-type introspection and



narrowing (down-casting). Dynamic typing also allows meta-transformationsand libraries of transformations matching common structural patterns to beeasily developed without the use of cumbersome reflective methods. Suchtransformations may, for example, deal with mapping names in nested namespacesto structured names in a single flat namespace.

Transformation Tool Set

The transformation language described previously is just one piece of theautomated development environment. Other tools that deal with the input andoutput of concrete textual representations of models, and the graphical visualisationof models and transformations are vital parts of an MDA tool set.

The OMG has developed the XML Metadata Interchange (XMI) Format (2002;XMI Production of XML Schema, 2001) which defines rules for producing bothan XML DTD and an XML Schema from a model, and a set of rules fortransferring data between conformant XMI documents and MOF-compliantrepositories. The main use of XMI is for interchange of models and modelinstances between tools, and for storage.

The result of the OMG’s RFP for a Human Usable Textual Notation standard(1999) was the adoption of a more generic approach for automatically creatinga human-friendly language for an arbitrary MOF model. By exploiting theinherent structure in a MOF model (containment, association cardinalities, etc.),and allowing for some on-the-fly customisation (e.g., for default values) it ispossible to fully automate the generation of both parsers and printers of theHUTN language for a given MOF model.

Most commonly, the ultimate goal of a transformation process is to generate codeor some other textual representation of a system. While it would be reasonableto realise this goal by transforming an abstract model to a model correspondingto the concrete syntax of the target language (Java, Cobol, HTML, etc.), this taskis particular enough to warrant and benefit from a specialised tool.

The motivation of the AntiYacc tool is to provide a simple means to render thecontent of a MOF-based repository in a textual form corresponding to somespecified syntax. It is capable of producing text that conforms to an arbitraryuser-supplied EBNF grammar. Just as a parser generator such as Yacc(Johnson, 1974) takes a set of grammar rules decorated with code fragments to,typically, construct a parse tree from a stream of lexical tokens, AntiYacc takesa set of grammar rules decorated with code fragments to construct a stream oflexical tokens from a traversal of a graph of MOF objects. An AntiYaccspecification also includes lexical rules that convert the token stream into text,



typically addressing issues such as horizontal and vertical white space, anddelimiters.

Finally, it would often be very useful to be able to visualise or edit a graphicalrepresentation of the models being transformed. However, since much of thetime their metamodels may be purpose-designed and therefore have no standardgraphical representation (let alone a tool to display/edit the model), it would beextremely useful to be able to generate such a tool in a manner analogous to theHUTN approach. That is, to employ a set of standard, simple visual concepts(box, line, label, containment, proximity, etc.) to render a given model. Such a toolis currently under development by the authors.

Conclusions

In this chapter we have introduced the problem of model-to-model transforma-tion for the purpose of building distributed systems from high-level modelsdescribing the system to be built in platform-independent terms then generatingthe system implementation for a particular, technology specific, platform. Thisis the vision embodied in the OMG’s Model Driven Architecture (MDA).

We have described the functional and non-functional design requirementsidentified for a language suitable for writing transformation definitions andpresented a language satisfying these requirements along with examples of ausable, familiar concrete syntax for the language. We have also briefly touchedon issues relating to advanced transformations and mentioned a number ofadditional technologies required for dealing with textual and graphical forms ofthe models.

It should be noted that the transformation language presented here is evolving aswe gain further experience and as a result of the OMG’s RFP process. Inparticular, influenced by the Compuware/Sun submission, we are extending theconcept of Trackings to more closely approximate a class model. Also, compo-sition of transformations is essential for the use and extension of existingtransformations. While there is no explicit mention of this in the languagepresented here, the ability to reference elements in one MOF model from anotherMOF model should be sufficient for simple composition of transformations.However, more sophisticated forms of composition, such as producing atransformation that maps A to C from one that maps A to B and one that mapsB to C or producing a transformation that merges A and B to produce C from theA to B and B to C transformations, is the subject of future research.

Additionally, the transformations discussed in this chapter have generally dealtwith transformation in a single direction, from model A to model B. Another use



of a declarative transformation language, and one in which the declarative natureoffers an advantage over imperative alternatives, is in the application of a singletransformation to perform transformations both from A to B, and back again.This is another aspect that is currently under investigation by both the authors andthe larger OMG community.

References

A Human-Usable Textual Notation for the UML Profile for EDOC: Requestfor Proposal. (1999). OMG Document ad/99-03-12.

Alcatel, Softeam, Thales & TNI-Valiosys. (2003). Response to the MOF 2.0Queries/Views/Transformations RFP. OMG document ad/03-03-35.

Andries et al. (1999). Graph transformation for specification and programming.Science of Computer Programming, 34(1), 1-54.

Boldsoft, Rational Software Corporation, IONA & Adaptive Ltd. (2003).Response to the UML 2.0 OCL RFP. OMG Document ad/2003-01-02.

Brown, K. (2001). Rules and Patterns for Session Facades. IBM’s WebSphereDeveloper Domain. Retrieved from the WWW: http://www.boulder.ibm.com/wsdd/library/techarticles/0106_brown/sessionfacades.html

Codagen Technologies Corporation. (2003). MOF 2.0 Query/Views/Transfor-mations. OMG Document ad/2003-03-23.

Common Warehouse Metamodel. (CWM) Specification (2001). OMG Docu-ments ad/01-02-01, ad/01-02-02, ad/01-02-03.

Compuware Corporation & Sun Microsystems. (2003). XMOF Queries Viewsand Transformations on Models using MOF, OCL and Patterns. OMGDocument ad/2003-03-24.

DSTC, IBM, & CBOP. (2003). MOF Query/Views/Transformations InitialSubmission. OMG Document ad/2003-02-03.

Gerber, A., Lawley, M., Raymond, K., Steel, J. & Wood, A. (2002). Transfor-mation: The Missing Link of MDA. Proceedings of the First Interna-tional Conference on Graph Transformation (ICGT’02), Barcelona,Spain (pp. 90-105). LNCS 2505.

Hearnden, D. & Raymond, K. (2002). Anti-Yacc: MOF-to-text. Proceedingsof the Sixth IEEE International Enterprise Distributed Object Comput-ing Conference, Lausanne, Switzerland. IEEE.

Human-Usable Textual Notation (HUTN) Specification. (2002). OMG Docu-ment ptc/02-12-01.



Johnson, S. (1974). YACC - Yet Another Compiler Compiler. CSTR 32, BellLaboratories.

Meta Object Facility (MOF) v1.3.1. (2001). OMG Document: formal/01-11-02.

Model Driven Architecture - A Technical Perspective. (2001). OMG Docu-ment ormsc/01-07-01.

MOF 2.0 Queries/Views/Transformations: Request for Proposal. (2002).OMG Document ad/02-04-10.

Peltier, M., Bezevin, J. & Guillaume, G. (2001). MTRANS: A general frame-work, based on XSLT, for model transformations. Proceedings of theWorkshop on Transformations in UML, Genova, Italy.

Peltier, M., Ziserman, F., & Bezevin, J. (2000). On levels of model transforma-tion. In XML Europe 2000, Paris.

Unified Modelling Language v1.4. (2001). OMG Document: formal/01-09-67.

Varró, D. & Gyapay, S. (2000). Automatic Algorithm Generation for VisualControl Structures. Retrieved February 8, 2001 from the WWW: http://www.inf.mit.bme.hu/FTSRG/Publications/TR-12-2000.pdf

Varró, D., Varraó, G. & Pataricza, A. (2002). Designing the AutomaticTransformation of Visual Languages. Science of Computer Program-ming, 44(2), 205-227.

XMI Production of XML Schema. (2001). OMG Document ptc/2001-12-03.

XML Metadata Interchange (XMI) Version 1.2. (2002). OMG Documentformal/2002-01-02.

XSL Transformations (XSLT) v1.0. (1999). W3C Recommendation. Retrievedfrom the WWW: http://www.w3.org/TR/xslt

Endnote

* Jim Steel is now at INRIA/Irisa, University of Rennes 1, France.

148 Badia


Chapter VII

From ConceptualModels to Data Models

Antonio Badia, University of Louisville, USA

Abstract

This chapter describes transformations between conceptual models (mainlyentity-relationship diagrams and also UML) and data models. It describesalgorithms to transform a given conceptual model into a data model for arelational, object-relational, object-oriented and XML database. Someexamples are used to illustrate the transformations. While sometransformations are well known, some (like the transformation into XML orinto object-relational schemas) have not been investigated in depth. Thechapter shows that most of these transformations offer options whichinvolve important trade-offs that database designers should be aware of.

Introduction

Conceptual models aim at capturing the structure of reality, are high-level andcomputer independent. Data models, on the other hand, aim at representingreality in the computer, and are therefore less abstract. It is assumed that, increating an Information System, a conceptual model will be developed as part ofthe Requirements Specification, from which a data model will be derived later on,

From Conceptual Models to Data Models 149


in the Design phase (Davis, 1993). Thus, mappings between conceptual modelsand data models are one of the most vital transformations in the development ofan Information System (Elmasri and Navathe, 2003). The purpose of this chapteris to present transformations between conceptual models and data models.Transformations between well known and used conceptual models (Entity-Relationship diagrams and UML Class Diagrams) and the most common andimportant data models (relational and object-oriented) have been developed andare well understood. However, new data models like XML and the Object-Relational data model are not included in these mappings. Translation into XMLis the focus of some research lately, but this is a relatively new area and not muchwork has been done yet. Translation into Object-Relational databases is avirtually unexplored topic, perhaps because it is felt that existing mappings intothe (pure) relational models are easy to extend to this case. However, Object-Relational databases provide options to the designer that are not available in therelational case. Therefore, some guidance is needed for the choices that appearin the mapping process.

In this chapter, we review existing mappings and extend them to include thesenew data models. We start with a review of the basic concepts, to establish somevocabulary and make the chapter self-contained, followed by a description ofrecent work in the area, including new and existing translations. One of thepurposes of the chapter is to put all of this research in a wider perspective andexamine the different approaches, something that is missing from the currentliterature.

Background

For lack of space, we do not discuss conceptual or data models in depth; weassume the reader is familiar with the basic ideas. However, we review somebasic concepts to establish a vocabulary.

Conceptual Models

We briefly review Entity-Relationship models and UML class diagrams. Thereare other conceptual models, like Object-Role-Modeling (ORM); we will notinclude them here.

An Entity-Relationship (E-R) (Chen, 1976; Thalheim, 2000) model is based onthree basic concepts: entity types, attributes and relationships. E-R modelsare usually depicted in E-R diagrams; an example is given in Figure 1. Entity

150 Badia


types are depicted as rectangles with a name inside, attributes as ovals, andrelationships as lines with a diamond shape on them.

Entity types represent things either real or conceptual. They denote sets ofobjects, not particular objects; in this respect they are close to classes in object-oriented models. The set of objects modeled by an entity type are called itsextension; particular objects are called entities.

Relationships are connections among entity types. Relationships may involve anynumber of entity types; those involving two entity types (called binary relation-ships) are the most common. However, n-ary relationships (involving n > 2 entitytypes) are also possible (in particular, relationships relating one entity type toitself are allowed). Relationships are fundamental in an E-R model in that theycarry very important information, in the form of constraints: participationconstraint tells us whether all objects in the extension of an entity type areinvolved in the relationship, or whether some may not be. For example,Department and Employee have a relationship Works-for between them. Ifall employees work for some department, then participation of Employee inWorks-for is total. However, if there can be employees which are not assignedto a particular department, then participation is partial. Cardinality constrainttells us how many times an object in the entity type’s extension may be involvedin a relationship, and allows us to classify binary relationship as one-to-one,one-to-many or many-to-many. There are several notations to state con-straints in an E-R diagram. The one chosen here associates with each entity typeE and relationship R a pair of numbers (min,max), where min represents theminimum number of times an entity in E appears in R (thus, min represents the

Figure 1. E-R diagram

Employee Department

Project

Hourly Salaried

employee

name dnamelocations

pname

hourly rate

address

ssn

salary

budget

street

zipcity

employee

reviews

manages

(1,1) (1,M)

(1,M)

(1,M)

(1,M)

started

(0,M)

(1,M)(1,M)

(0,M)

Date



participation constraint by being 0 for partial and 1 for total), and max representsthe maximum number of times an entity in E appears in R (thus, max representsthe cardinality constraint by being 1 for one-to relationships and greater than 1for many-to relationship; the latter case is traditionally represented by using theletters M or N). Thus, the (1,1) by Employee and Works-For indicates that allemployees work for exactly one department; the (0,M) by Department andManages indicates that not all departments manage projects, but those that domay manage more than one.

Entity types and relationships may have attributes, which are properties with avalue. Attributes convey characteristics or descriptive information about theentity type or relationship to which they belong. Attributes may be simple orcomposite (made up of simpler parts, like the attribute Address of entityDepartment in the example, which is made up of parts named street, cityand zip), single or multivalued (being capable of having one or several valuesfor a particular entity; multivalued attributes are displayed as dual ovals, likelocations in our example, meaning that some department may have multiplelocations), primitive or derived (a derived attribute value is computable fromother information in the model). A key attribute is an attribute whose value isguaranteed to exist and be different for each entity in the entity type. Therefore,this attribute (primary key) is enough to point out a particular entity. All entitytypes are assumed to have at least one key attribute.

A contentious issue is whether attributes are required (i.e., every entity of thetype must have a value for each attribute of the type) or optional (i.e., someentities of the type may or may not have values for some attributes). Differentauthors take different views on this issue, some even arguing that it is a mistaketo consider attributes optional (Bodart et al., 2001). Since this has an impactwhen transforming E-R models into different data models, we will point out howto deal with each view.

Some E-R models admit weak entities, entities with no key attributes; theseentities are connected by a one-to-many relationship to a regular entity, called thestrong entity. What characterizes a weak entity is its lack of clear identity(reflected in the lack of a key) and its dependence for existence on the strongentity. As a typical example, entity Employee has an associated weak entityDependent (shown as a double box). Clearly, an employee may be associatedwith several dependents (hence the one-to-many relationship), and if an em-ployee is deleted from the model (say the employee is fired), then the associateddependents also go away.

Many proposals for additional features have been made over the years. The mostsuccessful one is the addition of class hierarchies, by introducing IS-A (class/subclass) relations between entities. This addition, obviously motivated by thesuccess of object-oriented methods for analysis, allows the designer to recognizecommonalities among entities; usually this means shared attributes exist. Shared

152 Badia


attributes are removed and put together in a new entity (class) that is ageneralization of the others, and a class-subclass relationship is created. As inobject-oriented approaches, inheritance of attributes is assumed. In Figure 1,entity type Employee has two subtypes, Hourly-employee and Salaried-Employee. The IS-A relationship is indicated by a downward triangle in the linejoining the involved entity types. The IS-A relationship can be annotated todistinguish several situations: whether the subclasses are disjoint or not; andwhether the subclasses together cover the superclass (i.e., every entity of thesuperclass must also belong to one of the subclasses) or not. Note that bothdimensions are orthogonal to each other; hence, two annotations are needed todetermine the exact situation.

The Unified Modeling Language (UML) (Rumbaugh et al., 1999) is theconceptual model for object-oriented design. In its current incarnation, it is alarge, complex model made up of several different parts. Here we concentrateon static diagrams, which are the diagrams explaining the structure of informa-tion in the system and its interconnections. The previous E-R diagram is givenin Figure 2 as a UML diagram for illustration purposes.

A static or class diagram has many similarities to an E-R diagram. The worldis made up of classes, which are the equivalent of entity types. As in E-R models,classes are defined based on their attributes. Composite attributes can bemodeled by a structured domain, a domain with an internal structure (as anexample, see address in Department). In theory, a multivalued attributerequires its own separate class; however, modern versions of UML allowspecifying a cardinality constraint on the link between attribute and class. Thisseemingly minor point is very important since it gives the model the flexibility todeal with optional attributes (by setting minimum cardinality to 0) and multivaluedattributes in a uniform framework, similar to XML (however, this is far from anaccepted norm; see next subsection). It is usual in class diagrams to give a datatype for attributes, and it is possible to give them a default value. In UML,classes also have methods, procedural attributes which describe the behavior ofthe objects of the class. Methods, though, cannot be completely specified in theconceptual model because they are not declarative, but procedural (i.e., code).In a class diagram, classes are depicted as boxes divided into three parts: the topone contains the class name; the bottom one, methods; and the middle one,attributes.

Relationships are also present in UML, although there they are called associa-tions. Associations are displayed as lines connecting the involved classes.Associations can have attributes (displayed on a box related to the associationby a dashed line). However, unlike relationships, associations cannot involvemore than two classes. Therefore, if a relationship relates more than two classes,it must be reified into a class (which is then connected by binary associations tothe related classes; see Review in Figure 2); the resulting class is sometimes



called an association class. Associations can have roles and cardinality andparticipation constraints, though. Two special kinds of association are aggrega-tion and composition. Their semantics are somewhat vague; aggregation issupposed to represent a part-whole relationship, while composition is supposedto be somewhat stronger then aggregation, in that an object contains another oneas a part. The main difference seems to be that objects that stand in a compositionassociation have a lifetime dependence: when an object that contains another isdestroyed, the contained objects must be destroyed, too (in some versions,composition may involve an arbitrary number of objects). Thus, what we calledweak entities in the E-R model should be captured as a class associated bycomposition with another class. However, the semantics of UML are informaland fail to capture the special meaning that a part-whole relationship has(Moschnig-Pitrik et al., 1999). Aggregations are displayed with a hollowdiamond, and associations with a filled diamond. Another special association isthe one between class and subclass, called a generalization. This is displayedas an arrowhead.

Data Models

Here we briefly review the relational, object-oriented, object-relational andsemistructured (XML) data models.

The relational data model (Date, 2004) is well known; we simply overview itsmain concepts here. A domain is a non empty set; intuitively, it provides a poolof values. Every domain is assumed to come with a name (an infinite number ofnames, technically). Given a schema or list of domain names R = {A

1,…, A

n},

Figure 2. UML diagram

EmployeeDepartment

Hourly

Employee

Salaried

EmployeeProject

ssn

name

hourly rate salary

pname

budget

1..N

1..1

1..N city,zip}address:{street,

dname

locations

1..N

1..N

1..1

Manages

1..N1..N

0..N0..N

Date

Reviews

154 Badia


a relation on R is a subset of the Cartesian product A1 x …x A

n. The elements

of the relation are called tuples. A key K for relation r in schema R is a subsetof R (i.e., a set of attributes) such that, for any two tuples in r, they are the sameif they have the same value for K.

A relational database schema is a set of relation schemas plus a set of integrityconstraints. An integrity constraint is a predicate over relations expressing aconstraint; by far the most used integrity constraint is the referential integrityconstraint. A referential integrity constraint involves two sets of attributes S1and S2 in two relations, T1 and T2, such that one of the sets (say S1) is a key forone of the relations (called the primary key). The other set is called a foreignkey if T2[S2] is a subset of T1[S1]. Referential integrity constraints are the gluethat holds the relations in a database together. It is therefore necessary tospecify, when talking about a relational database, which are the primary keys andthe integrity constraints that are supposed to hold.

There are many variations of the Object-Oriented data model. In this chapter,we use the ODMG (Object Data Management Group) model (Catell et al., 2000),and its language ODL (Object Database Language), since it sets the standarddata model for Object-Oriented databases. In ODL, classes are declared bygiving them an interface (using the keyword interface); each class is a collectionof attributes that are either primitive (of a basic data type) or relationship, i.e.,their value is an object or set of objects of a given class. The interface includes:a name, a key (optional), an extent, and the properties and operations. A key isa set of properties (attributes or relationships) whose values are unique for eachobject in the extent (composite keys are called compound in ODMG). Theextent is the name of the set of objects under the declaration. Obviously,inheritance among classes is supported directly in the model, and declared usingthe keyword extends. Values of attributes are typically literals (atomic orcomplex) but can be oids. Values of relationships are always object names or acollection applied to object names. In the ODMG model, only binary relationshipsare explicitly represented, through a pair of inverse references (using theinverse keyword).

Literal’s value may be simple or complex. There are three types of literals:atomic, collection, structured. Atomic literals correspond to basic data types:integers (long, short, unsigned), float (float, double), Boolean, single character,string, and enumeration types. Structured literals have a tuple structure; theyinclude types like Date and Time. Also, the user can define structured literals asneeded (using the Struct constructs). Collection literals specify a collection ofobjects or literals. Types of collections are: Set, Bag, List (homogeneous), Arrayand Dictionary. Each collection has a group of built-in operators.

Finally, objects have object identifiers (oids) and a value (unlike literals, whichhave value but no oid). Objects may have a name, and can be of atomic or



collection type. Atomic objects are not objects without internal structure; theycorrespond to atomic or structured literals. For each object, properties (i.e.,attributes and relationships) and operations are specified.

The Object-Relational (also called extended-relational, or universal) datamodel is exemplified by the latest version of SQL, SQL-99 (Melton, 2003). It canbe seen as an attempt to capture as many as possible of the object-orientedconcepts introduced in the previous subsection and wrap them around arelational shell. A more modest view of it regards the model as extending the baseof the relational model (instead of the model itself) by making it easier to addmore complex data types to serve as domain definitions. Here we will describethe basics of the standard (Melton, 2003), since each commercial DBMS has itsown version of the model, with different names and different syntax.

The basic idea is to substitute domains by (possibly complex) types, called UserDefined Types (UDTs). The name comes from the fact that the model providesconstructors so that users can define their own types as needed by an application;the emphasis is in extendibility. UDTs come in two types, distinct types andstructured types. Distinct types are based on a single built-in data type. Distincttypes are not compatible with any other type (including the one they are basedon). The following is an example of an UDT called age based on the built-in typeinteger:

CREATE TYPE age AS INTEGER (CHECK age BETWEEN 0 and 100) FINAL;

FINAL refers to whether type can be extended with subtypes: distinct typescannot, structured ones can. Optionally, operations and comparisons can bedefined for types. Structured types can have internal structure, with parts calledattributes. Attributes do not have to be built-in; they may be complex (SQL99offers “built-in” structured types ARRAY and ROW), but cannot be of the typebeing defined (i.e., recursion is not allowed). Structured types do not haveidentity. One cannot specify constraints on the attributes of a structured type.

It is possible to define a hierarchy of types by defining a new type UNDERanother; (single) inheritance applies. Types may be NOT INSTANTIABLE(cannot have values of that type; this is used for abstract superclasses).Structured types can be used as columns of tables, and also as tuples of tables.A typed table is a table whose rows are of a structured type. The attributes ofthe type become attributes of the table. Typed tables also have inheritancehierarchies, corresponding to the hierarchies of the types. Subtables cannot haveprimary keys, but supertables can. They can also have UNIQUE, NOT NULL,CHECK and integrity constraints. There is also a self-reference value createdautomatically, unique for each row of the table. SQL99 provides REFERENCE

156 Badia


types, which give structured types an id. Maximal supertables must specify theself-referencing column (it is inherited by subtables, which cannot specify sucha column on their own). References can be generated by system, by using somebuilt-in type, or by using some attributes of the type.

Semistructured data is assumed not to have a strict type, but to possesirregular, partial organization (Abiteboul et al., 1999). Because, in addition, thedata may evolve rapidly, the schema for such data is usually large, dynamic, andis not strictly respected. Data models have been proposed that try to adapt tothose characteristics. Several of them have in common that they can be thoughtof as directed, labeled graphs (trees, in some cases) (Papakonstantinou et al.,1995). In this model, nodes are objects, and edges point to other objects whichare components of the given object. However, this model, while very general,gives very few constraints as to what the data looks like. In practice, someinformation about the components of objects is usually available. Thus, in mostcases the term semistructured data is reserved for data that does have some(loose) structure. XML (Bray et al., 1999) provides the tools to describe suchinformation, either through a DTD or an XML Schema (note, however, that XMLhas additional properties over semistructured data — order, attributes — whilesemistructured data does not assume the existence of any schema. Hence, bothterms are, strictly speaking, different).

Basically, in XML an object may have attributes and elements. Simple parts ofan object can be represented by attributes or elements, while complex parts arerepresented by elements, since they in turn are also objects. Elements aredefined by a pair of matching start and end tags. Elements may have embeddedsubelements, indicated by nested pairs of tags (empty elements are alsoallowed). A root element may be declared which is not a subelement of any otherelement. Subelements have associated information to indicate a cardinalityconstraint, in the form of a pair of attributes minOccurs and maxOccurs: noneor several occurrences (a Kleene star, indicated by ‘*’ in DTDs) is representedby setting minOccurs to 0 and maxOccurs to ‘’unbounded’’; none or oneoccurrences (indicated by ‘?’ in DTDs) is represented by setting minOccurs to0 and maxOccurs to 1; one or several occurrences (indicated by ‘+’ in DTDs)is represented by setting minOccurs to 1 and maxOccurs to ‘’un-bounded’’. Finally, exactly one occurrence (no mark in DTDs) is representedby setting minOccurs and maxOccurs to 1. There is also a “choice” construct(indicated by ‘|’ in DTDs) which represents union of types.

Attributes in XML are associated with types, not with elements, and areexpressed as an equation attribute name = value within the starting tag of thecorresponding element; the names must be unique within an element. Attributescan be mandatory (expressed with the keyword #REQUIRED) or optional(expressed with the keyword #IMPLIED). Keywords ID and IDREF are used toestablish links among elements, denoting the pointed at and pointing elements in



the link, respectively. Atomic elements and attributes are simply of #PCDATAor CDATA type (this is a string, but is used to represent any atomic type: integer,...). Attributes are only for complex types; for simple types, there are facets(restrictions on simple types).

Since in XML, unlike HTML, tags are not pre-defined, one must have an idea ofwhat tags one may find in a given documents. A Document Type Definition(DTD) or an XML schema can be used to give information about the componentsof an object. An XML document is well-formed when it respects the generalXML syntax (nested, balanced tags), and is valid (with respect to a given XMLschema or DTD) if it respects the tag definitions of that XML schema or DTD.

DTDs do not distinguish between entity types and relationships; relationships areimplicitly expressed through the element-subelement connection. Because rela-tionships are attached to objects, XML DTDs are much better at handlinghierarchical relations than many-to-many relations (or n-ary relationships (n > 2)or relationships with attributes), and indeed this is the way most DTDs are used(Sahuget, 2001).

XML schemas generalize DTDs. An XML schema has XML syntax (start/endtags), and enforces type checking and references. It classifies elements assimple type (integers, strings) or complex type (regular expressions, like inDTDs). For a complex type, it defines the structure. An XML schema alsointroduces the notion of Namespace, a collection of tags and their definitions.There is a notion of key and foreign key. In XML Schema, a key for a complextype T is declared by giving it a name, a path selector (that leads from the rootto T) and a field (to say which element(s) within T form the key). Note that a keycan be made up by several elements; also, several alternative keys can bespecified. Foreign keys are defined with a keyref keyword and a reference forthe key being denoted, using also a path and a field selector. Therefore, integrityconstraints can be specified in XML Schema.

One can specify mixed content, in which plain text and tags are intertwined.There is also an Any type that allows anything. Finally, inheritance can bemodeled with derived types. There are two ways to derive: by extension and byrestriction. In the second, types are derived by giving a base type and restrictingthe properties (cardinalities, choices) of the elements.

Translations

We divide the translations according to the target data model, as this creates themore salient differences. We first give an algorithm that uses the E-R model assource, and then point out the differences needed to handle UML.

158 Badia


From E-R and UML to Relational

There is a well-known procedure to transform an E-R diagram into a relationaldesign, given in Figure 3. Applied to the E-R model of Figure 1, the algorithmcreates the tables of Figure 4 (keys are underlined, foreign keys in italics).Intuitively, the algorithm maps every entity (including weak ones) to a table, andevery relationship to a separate table. This algorithm has one notable property:if all the functional dependencies that exist among the attributes in the E-R modelare those generated by the key, then all the relations generated by the algorithmare guaranteed to be in fourth normal form (Elmasri & Navathe, 2003). Evenwhen additional functional dependencies exist, they usually involve attributes ofa certain entity, and therefore normalization of the database can proceed on atable-by-table basis. There are a few tricky cases, though, in which the E-Rmodel does not have enough information to guarantee normal form, usuallyinvolving n-ary relationships (Camps-Pare, 2001).

If all attributes are considered required, then the above translation workscorrectly. If attributes are considered optional, the above translation is stillcorrect but allows for the introduction of nulls in the database. When using SQLto define the tables, required attributes should be considered non-nullable, andoptional attributes should be considered nullable. Unfortunately, without anyfurther information (for instance, dividing the attributes into required and

Figure 3. From E-R to Relational

For every entity E (including weak entities) do create table RE; if entity is weak, key of table is discriminator plus key of strong entity; else key of table is the key of entity;

For every n-ary relation R between entities E1, E2, ..., En do create a table RR; for all entities E1,...,En do

add as an attribute the primary key of Ei; declare it a foreign key for the table corresponding to Ei;

declare as a key for RR the set of all Ei such that R is many on Ei. For every attribute A of E (or R) that is not multivalued do

if A is atomic then add A as an attribute to RE (RR); else add one attribute to RE (RR) for every simple subpart of A; if attribute is (part of) a key, declare it as (part of) a key.

For every attribute A of E (or R) that is multivalued do create a new table RAE; add as attributes the key of RE (RR) and A; declare the key of E (R) as a foreign key for RE; declare the set of all attributes as the key of RAE.



optional), the only way to get rid of nulls is to break up every table into a set oftables, each one containing the key of the entity and one of its attributes. Thisway, entities with no value for a given attribute simply would have no entry in theappropriate table, but no nulls would be produced. However, this approachproduces a heavily partitioned database, with most queries requiring a largenumber of joins. Hence, the issue is usually ignored in the process.

The above algorithm admits some inlining, as follows: when a binary relationshipR exists between entities E1 and E2, and R is one-to-many or one-to-one, it ispossible to express R not by creating a new table, but by modifying the tablecorresponding to the entity on the one side (if R is one-to-one, either entity willdo). Say this entity is E1; then the key of E2 is added to the schema of E1, togetherwith any attributes R may have. Note that if participation of E1 in the relationshipis not total, this will result in some nulls; hence, this procedure must be used onlywhen participation of E1 is total or nulls can be dealt with adequately. In thedatabase of our example, we could create, instead of tables Employee andWorks-for, a single table Employee(ssn,name,dname,start-date).

The procedure must be extended to deal with IS-A links. If entity type E1 is asubtype of entity type E2, a table must be created for each. However, there aretwo options as to how to configure the relations:

1. Add to the table for the subtype (E1) all attributes of the supertype (E2).That is, repeat all attributes of the schema of E2 in the schema of E1. Thisimplies that objects that are in subclass E2 will be stored in its own table.Applied to the E-R model of Figure 1, this approach creates tablesEmployee(ssn,name), Hourly-Employee(ssn,name,hourly-rate),Salaried-Employee(ssn,name,salary). Note that if the two sub-classes are a cover of the superclass, the table for Employee would notbe necessary (would remain empty); but then, queries asking for allemployees would have no direct reference. Note also that if there wereoverlap (although obviously not the case in this example), informationabout employees could be duplicated.

Figure 4. Applying method to Figure 2

Employee(ssn, name) Dependant(ssn, lname, date-of-birth) Department(dname,address-street,address-city, address-zip) Dept-Loc(dname,location) Project(pname, budget) Works-for(ssn, dname, start-date) Manages(dname,pname) Started(dname,pname, date) Reviews(ssn,pname,dname).

160 Badia


2. Give as the schema of the superclass (E2) only those attributes that areproper of E2 and in the subclass (E1) only those attributes that are properof the superclass. This implies that objects which are in subclass E2 will bestored in two tables: in the table for E1, the inherited attributes will be takencare of; in the table for E2, we will put only those attributes that are properof E2. Applied to the E-R model of Figure 1, this approach creates tablesEmployee(ssn,name), Hourly-Employee(ssn,hourly-rate),Salaried-Employee(ssn,salary). Note that if the two subclassesare a cover, the table for the superclass is still needed. Note also that if thesubclasses overlap, there would be no redundancy on this schema.

Which option is better depends entirely on the intended use of the database, (i.e.,the applications it must support) and on the characteristics of the class/subclassrelationship (overlap, cover). Clearly, queries that refer to the whole superclassfrequently will be more efficient over the first option, while queries that referto specific classes more frequently will be more efficient over the secondoption.

As for the translation from UML, the basis is exactly the same: each class istranslated into a table, and each association is also translated into a table. Notethat all associations in UML are binary, and hence no rule is needed to handleother kinds of associations. Note also that when associations have attributes, orhave an arity greater than two, they get promoted to classes (the so-calledassociation classes); in this case, the class and the associated associations shouldbe translated as one since they represent a single relationship. As an example,the class Review in Figure 2 represents a ternary relationship, and is connectedby three binary associations to classes Employee, Department and Project. Asingle table should be created, containing the attributes of class Review andrepresenting the associations by adding the primary keys of Employee, Depart-ment and Project as foreign keys in the new class. Otherwise (if we treatedassociation classes like other classes), the resulting database would be techni-cally correct but would introduce artificial (vertical) partitioning of the database,which in turn would make querying more expensive by having additional joins tocompute. Finally, in those cases in which attributes have cardinality constraints,we still follow the same procedure as for the E-R model, simply identifyingattributes as multivalued if their max cardinality is greater than 1 (attributeswhose min cardinality is 0 are considered nullable in the database, but must stillbe present in the table).



From E-R and UML to Object-Oriented

Translations from UML to Object-Oriented databases are straightforward, sinceboth are based on the same underlying model. Thus, we start by explaining thetranslation from UML into ODL. Intuitively, each class in UML will become aclass in ODL, and each association will be captured as a relationship attributewith an inverse (recall that all associations in UML are binary). Complexattributes become structured attributes, and multivalued attributes can becaptured with a SET constructor. Weak entities, although not recognized inUML, should be identified to make them a complex attribute of the class theydepend upon. The reason is that, since composition is not recognized in ODL, thisis the best way to keep the semantics of weak entities (their life dependency andlack of key). Association classes can be treated as regular classes, since ODLcannot deal directly with relationships with attributes or with arities greater thantwo. Inheritance, of course, is modeled directly both in UML and ODL. Theprocedure can be described in Figure 5.

Note that this procedure does not involve object identifiers (oids) at all; it isexpected that any objects created in the database will get an oid because that ispart of the object-oriented model. Applied to the E-R model of Figure 1, thisapproach creates the classes shown in Figure 6. Note that some arbitrary datatypes were chosen to complete the declaration. Note also that key declarationsare optional in ODL, but that regardless of key declaration every object of theclass has an oid.

Figure 5. From UML to Object-Oriented

For each class C declare a class interface C’ in the database; if class C is a subclass of another class, use the “extend” declaration in C’; for each attribute A of C

add an attribute A of the appropriate data type to C’ (complex attributes are mapped to STRUCT attributes); For each association R between classes C1 and C2 if R has no attributes then declare a relational attribute R1 in C1 with value C2,

declare a relational attribute R2 in C2 with value C1, declare R1 as an inverse of R2, and R2 as an inverse of R1; make R1 be a <set> if R is many on C1; make R2 be a <set> if R is many on

C2; else declare a class interface R’ for R; add as attributes of R’ all attributes of R; create two binary relations, one between R’ and C1’, and another between R’ and C2’, as indicated above.

162 Badia


When starting with an E-R diagram, all of the above applies. The most importantdifference is that there will be n-ary relationships. To translate an n-aryrelationship R involving entities E1,…, En, one must do the following: R must bereified, just like a binary relationship with attributes. Thus, a class R’ must becreated, with attributes all attributes of R, and then n binary relations betweenR’ and each Ei’ must be established. The final result is the same as the procedureshown above, since the process of reification is basically the same transforma-tion that takes place in UML when an association class is created to representn-ary relations (n > 2).

Figure 6. Applying procedure to Figure 2

interface Employee (key ssn) { attribute string ssn;

attribute string name; attribute set<Struct>{string lname, Date date-of-birth} dependant; relationship Department works-for inverse Department::works-here; relationship Reviews reviewer inverse Reviews::reviews; }

interface Hourly-Employee extends Employee { attribute float hourly-rate; } interface Salaried-Employee extends Employee { attribute float salary; } interface Department (key dname) {

attribute string dname; attribute Struct {string street, string city, int zip} address; attribute set<string> locations; Relationship set<Employee> works-here inverse Employee::works-for; Relationship set<Project> Manages inverse Project::managed; Relationship set<Start> started inverse Start::started-by; Relationship Reviews reviewed-for inverse Reviews::reviews-for; }

interface Project (key pname) { attribute string pname; attribute float budget; Relationship set<Department> managed inverse Department::Manages; Relationship set<Start> inverse Start:project-started; Relationship Reviews under-review inverse Reviews::is-reviewed;}

interface Start { attribute date Date; Relationship set<Department> started-by inverse Department::started; Relationship set<Project> project-started inverse Project::start;}

Interface Reviews { Relationship Employee reviews inverse Employee::reviewer; Relationship Department reviews-for inverse Department::reviewed-for; Relationship Project is-reviewed inverse Project::under-review;}



To conclude, we point out that, contrary to popular belief, the object-orienteddata model does not handle optional attributes any better than the relationalmodel. Each class declaration specifies a series of attributes that every objectin the class must have; hence, optional attributes in the conceptual model createundefined attributes (the equivalent of relational nulls) in the objects.

From E-R and UML to Object-Relational

The object-relational data model offers several degrees of freedom with respectto the (purely) relational data model. These degrees of freedom, in turn, raisedifferent possibilities about the translation from conceptual models. Unfortu-nately, almost no research has been done on possible different translations, theirweaknesses and strengths, and their comparison. Here, we outline two differentapproaches to the translations and evaluate them.

The first translation is based on the intuition that the real goal of the object-relational data model is to allow for new data types in the relational model,without changing its structure. Under this view, a translation into object-relational databases would be the same as a translation into a purely relationaldatabase, with the following differences:

• subtypes of an entity type can be directly mapped into subtables of a table,since the object-relational approach supports inheritance directly.

• multivalued atomic attributes can be modeled as an attribute with internalROW or ARRAY constructor, at least if an upper bound in the number ofvalues is known1. This will help reduce table fragmentation and will allow,in many cases, to map one entity under an entity class into one tuple in onetable.

Because this is almost the same translation as the purely relational, we call thisapproach conservative. There is also another possible approach, which is moreextreme, in that it uses the full-blown potential of the object-relational model. Inthe extreme approach, we treat the data model as one of objects represented intables (i.e., in tabular form). Hence, we not only map subtypes into subtables andmultivalued attributes into complex attributes, we also map weak entities intocomplex subelements of the strong entity. That is, given weak entity E1 relatedby a 1-M relationship to strong entity E2, we create a type for E1, and include,as an attribute of E2, a collection attribute representing an ARRAY or SET ofthe type created for E1.

1-M relationships can also be mapped by embedding the entities in the M side intothe table for the entities in the 1 side. If the relationship has attributes, a table is

164 Badia


created that contains, on each tuple, the attributes of the relationship plus acomplex type corresponding to the entity. This table is then embedded as asubtable (complex) attribute of the table representing the entity on the 1 side.Note that there may be further references to the embedded entity, since it maybe involved in other relationships; these are handled by using REF types. Binaryrelationships without attributes can be implemented through REFs (or sets ofREFs), in a manner similar to the object-oriented model.

Note that this approach creates a series of choices as to how to represent many-relationships and complex types: directly by embedding or inlining, or indirectlythrough references. Since this creates differences in how the relations arephysically stored on disk, and therefore on access patterns, which option to usedepends on the expected workload (queries), size and performance requirementsof the database. As an example, consider the entity type Department, con-nected by a 1-M relationship to entity type Employee (i.e., a Department mayhave several Employees, each Employee belongs to a single Department). Oneoption is to create the complex type for Department using the complex type forEmployee as a (multivalued, complex) element. In this approach, there is onlyone table (Department), and queries asking about Department information(including Employees per Department) may run somewhat faster, sinceDepartments are explicitly joined to Employees. However, queries about Em-ployees may be somewhat slower (of course, the final performance depends onmany other factors, like clustering, indices, etc.). This approach is somewhatbiased towards Department (considered a “primary” type), in detriment ofEmployee (considered a “secondary” type). Moreover, if Employee is con-nected by another relationship to another entity, this second relationship has tobe handled by reference — unless it is also 1-M. In our example, Employee isinvolved in a 1-M relationship with Dependant. Then it is possible to inline thedependant type within the Employee type, which in turn is within the Depart-ment type. Direct access to dependants may be slow and complex in thisschema, though. However, Employee is also involved in a many-to-many-to-many relationship with Department and Project. Then it is not possible toinline this relationship since this would cause redundancy (a project would berepeated on each employee that reviewed it). In this case, using a separateReview table with references to Employees may be a better choice. Theproblem applies to any relationship that is many-to-many, which cannot beembedded without causing redundancy.

In contrast, the original option is to create a complex type for Department, onefor Employee, a table for each, and handle the relationship either with a separatetable (as in the relational model), or by using references (sets of references toEmployee on each Department, and a reference to Department on eachEmployee). This approach is more neutral, in that both Departments andEmployees are considered “top level” tables. Further relationships with other



tables, like Project, are easier this way. On the other hand, every join betweenDepartments and Employees needs support from separate indices and/oralgorithms. Note that both approaches would create subtables Hourly-Employee(hourly-rate) and Salaried-Employee(salary), under tableEmployee. A possible heuristic to decide between the conservative and extremeapproaches is this: the extreme approach works well for weak entity types, andfor entity types connected only by a 1-M relationship to other entity types.However, the presence of M-N relationships strongly suggests the use of theconservative approach.

Finally, we note that both approaches can handle required attributes but haveproblems with optional attributes. Since both approaches ultimately make objecttypes fit into table schemas, the absence of a value creates a null in any case.

From E-R and UML to XML

Mapping from E-R to XML is made complicated by the fact that XML isdecidedly a hierarchical model while E-R is more of a flat model (all entities areat the same level) (Mani et al., 2001; Lee et al., 2003; Conrad et al., 2000; DosSantos et al., 2001). This presents two options as to how to transform an E-Rmodel into XML: to somehow transform the E-R model to fit the hierarchicalnature of XML, or to create a flat model that can be expressed in XML Schema.The choice is similar to the conservative and extreme approaches outlined in theprevious subsection. In the case of XML, the first option may be taken to anextreme by choosing some entity type to become the root of the XML model, andembedding everything under it. M-N relationships, relationships with attributes,and n-ary relationships (n > 2) are difficult to represent in this manner;hierarchical relationships are, after all, 1-M. A less extreme approach would beto identify some entity types in the E-R model which are somehow “moreimportant” and use them as first elements under an artificial root; this is theapproach used in Bird et al. (2000). The second approach is basically to use theE-R to relational translation, and express the resulting (flat) database in XMLSchema. Thanks to its ability to represent foreign key-primary key relationships,XML Schema can faithfully represent the flat structure of a relational database.Here, we apply both approaches to our example and compare the results.

The first option requires us to choose a “root of the hierarchy” entity. Assumethat, when applied to the E-R model of Figure 1, this method chooses Employeeas the root; this results in the DTD of Figure 7.

Note that this approach is inherently biased. Also, many-to-many relationshipsare described as one-to-many, since this is the only type of relation compatiblewith the hierarchical organization. Moreover, attributes in relationships are lost,

166 Badia


too. Hence, this approach leaves much to be desired. The work of Bird et al.(2000) creates hierarchies when the structure is favorable (one-to-many rela-tionships), but breaks it up in favor of a flat approach in other cases.

The second approach takes the flat approach for all of the models, and it can beexpressed in the algorithm of Figure 8. To start the algorithm, we declare onecomplex element D to be the root element of the schema; D represents the wholedatabase. Then, one element is created per entity type and one per relationship;links are established through keys and foreign keys. Inheritance is modeled withderived types. Constraints on inheritance (exclusive or not, total covering or not),cannot be modeled in XML Schema at the moment. All attributes (optional,choice, and multivalued) are treated equally, since they can be handled in XMLSchema. If an attribute is optional but not multivalued, we use ‘?’; if an attributeis optional and multivalued, we use ‘*’. Hence, XML is the only data model thatcan adequately deal with optional attributes.

The decision to consider attributes as subelements instead of XML attributes isbased on two factors: it allows for more parallelism with the relational model, andhence facilitates integration of the two; and it allows saving the XML attributesfor metadata. However, clearly the option exists to treat E-R single-valued,simple attributes as XML attributes.

As for UML, the whole process is simplified by the fact that all relations(associations) are binary. Hence, if an association is 1-to-many, we can considera hierarchical organization, by making the entity on the many side a subelementof the entity on the 1 side. However, many-to-many associations still require twoseparate elements and the use of primary keys and foreign keys in XML Schemato be adequately modeled.

Figure 7.

<!ELEMENT Employee (ssn, name, dependants*,department*, Project*)> <!ELEMENT Dependant (lname,date-of-birth)> <!ELEMENT Department (dname, locations*, address)> <!ELEMENT Address (street, city,zip)> <!ELEMENT Project (pname,pbudget)>



Conclusions and Further Research

In this chapter, we have surveyed transformations between conceptual modelsand data models. These transformations are vital in the design and developmentof Information Systems. While some of them are well understood, new datamodels (like object-relational, and XML) create new challenges in developingsatisfactory transformations.

Clearly, the most important difference among transformations comes fromdifferences among data models, in particular the importance given to objects andrelationships: in the object-based paradigm objects (actually, classes) come first,and only binary relations (as special attributes of objects) are considered. Thesemodels have trouble handling n-ary relations (n > 2) and relations with attributes.XML, with its strong hierarchical view, also has problems at handling certaintypes of relationships. On the other hand, the relational data model transforms

Figure 8. From E-R to XML

For every non-weak entity E in the model, declare XE as a subelement of D; For each attribute A of E,

declare A as a subelement of XE, within a sequence type. Declare the primary key of XE. For each weak entity W in the model, declare XW as a subelement of the strong entity E;

For each attribute A of W, plus the key of E, declare A as a subelement of XW, within a sequence type.

Declare the primary key of XW as the discriminant of W plus the key of E. For each binary relation R between entities E and E’ with no attributes,

include a foreign key reference to E in the (complex) type description of E’, include a foreign key reference to E’ in the (complex) type description of E. If the relationship is 1-M, or M-N, the many side needs to define the refkey (foreign key reference) element as one occurring multiple times (’+’, if participation is total; ’*’, if participation is partial)

For each binary relationship R connecting entities E and E’, and attributes A1,…,An Create a new element ER. Add each attribute Ai to ER following the same rules used for entity types above1. Declare a primary key for ER Declare a binary relation between ER and E as above, using primary keys and foreign keys. Declare a binary relation between ER and E as above, using primary keys and foreign keys.

For each n-ary relation R connecting entities E1,…,En, and possibly attributes A1,…,An Create a new element ER. Add each attribute Ai to ER following the same rules used for entity types above1. For each Ei

Declare a binary relation between ER and Ei as above, using primary keys and foreign keys.

Declare a primary key for ER, by combining all foreign keys Ei such that R is many on Ei.

168 Badia


everything into relations, and hence objects are diluted in that the informationabout an object may be distributed in several tuples of several relations. Finally,the entity-relationship conceptual model treats them both as equally important;this has probably contributed to their popularity, since many applications may bebest described using both constructs. Another conclusion is that all data models,except XML, fail to accommodate irregular data. In particular, all models exceptXML cannot deal with optional attributes without resorting to nulls or otherspecial values.

The most important conclusion of this overview is that there is a severe lack ofresearch in transformations for the object-relational and semistructured datamodels, as can be seen from the fact that several translations, with differentadvantages and drawbacks, are possible, and none is considered the righttranslation. The object-relational data model offers several possibilities for all butthe most trivial conceptual models; the trade-offs among these options are notwell understood. Hopefully, new research will shed light into these issues in thenear future.

References

Abiteboul, S., Buneman, P. & Suciu, D. (1999). Data on the Web: FromRelations to Semistructured Data and XML. Morgan Kaufmann.

Bird, L., Goodchild, A. & Halpin, T. (2000). Object Role Modeling and XMLSchema. Proceedings of E-R 2000, Springer-Verlag (pp. 309-322).

Bodart, F., Patel, A., Sim, M. & Weber, R. (2001). Should Optional PropertiesBe Used in Conceptual Modeling? A Theory and Three Empirical Tests.Information Systems Research, 12(4), 384-405.

Bray, T., Paoli, J. & Sperberg-McQueen, C.M. (Eds.). Extensible MarkupLanguage (XML) 1.0.W3C Recommendation (2nd edition). Retrievedfrom the WWW: http://www.w3.org/TR/REC-xml-20001006

Camps-Pare, R. (2002). From Ternary Relationship to Relational Tables: ACase Against Common Beliefs. SIGMOD Record, 31(2), 46-49.

Cattell et al. (Eds.). (2000). The Object Data Standard: ODMG 3.0. MorganKauffman.

Chen, P. (1976). The Entity-Relationship Model-Toward a Unified View ofData. ACM Transactions on Database Systems, 1(1), 9-36.

Conrad, R., Scheffner, D. and Freytag, J. C. (2000). XML Conceptual ModelingUsing UML. Proceedings of ER 2000, Springer-Verlag, (pp. 558-571).



Date, C. (2004). An Introduction to Database Systems (8th ed.). New York:Adisson-Wesley.

Davis, F. (1993). Requirement Specification: Objects, Functions and States.New York: Prentice-Hall.

Elmasri, R. & Navathe, S. (2003). Fundamentals of Database Systems (4th

ed.). New York: Addison-Wesley.

Lee, D., Mani, M. & Chu, W. (2003). Schema Conversion Methods betweenXML and Relations Models (Invited Paper). In B. Omelayenko and M.Klein (Eds.), Knowledge Transformation for the Semantic Web. IOSPress.

Mani, M., Lee, D. & Muntz, R. (2001). Semantic Data Modeling Using XMLSchemas. Proceedings of ER 2001, Springer, (pp. 149-163).

Melton, J. (2003). Advanced SQL:1999. Morgan Kaufmann.

Mostchnig-Pitrik, R. & Kaasboll, J. (1999). Part-Whole Relationship Categoriesand Their Application in Object-Oriented Analysis. IEEE Transactions onKnowledge and Data Engineering, 11(5), 779-797.

Papakonstantinou, Y., Garcia-Molina, H. & Widom, J. (1995). Object ExchangeAcross Heterogeneous Information Sources. Proceedings of the 11th

International Conference on Data Engineering, IEEE Computer Soci-ety, (pp. 251-260).

Rumbaugh, J., Jacobson, I. & Booch, G. (1999). The Unified ModelingLanguage Reference Manual. New York: Addison-Wesley.

Sahuguet, A. (2001). Everything You Ever Wanted to Know About DTDs, ButWere Afraid to Ask. Extended Abstract. Third International WorkshopWebDB, LNCS, Springer, (pp. 171-183).

dos Santos Mello, R. & Heuser, C. A. (2001). Structure-Based Conversion ofa DTD to a Conceptual Schema. Proceedings of ER 2001, Springer, (pp.133-148).

Thalheim, B. (2000). Entity-Relationship Modeling. Springer-Verlag.

Endnote

1 Technically, the SQL-99 standard does not have a SET constructor, andhence does not have the ability to capture multivalued attributes (or many-relationships). Indeed, without such a constructor the standard does noteven have the ability to represent nested relations (Melton, 2003). How-

170 Badia


ever, it seems that SET is going to be added to the standard soon, so weconsider it available here.

An Algorithm for Transforming XML Documents Schema 171


Chapter VIII

An Algorithm forTransforming XMLDocuments Schema

into RelationalDatabase Schema

Abad Shah, University of Engineering & Technology (UET), Pakistan

Jacob Adeniyi, King Saud University, Saudi Arabia

Tariq Al Tuwairqi, King Saud University, Saudi Arabia

Abstract

The Web and XML have influenced all walks of lives of those who transactbusiness over the Internet. People like to do their transactions from theirhomes to save time and money. For example, customers like to pay theirutility bills and other banking transactions from their homes through theInternet. Most companies, including banks, maintain their records usingrelational database technology. But the traditional relational databasetechnology is unable to provide all these new facilities to the customers. Tomake the traditional relational database technology cope with the Web andXML technologies, we need a transformation between the XML technology

172 Shah, Adeniyi, and Al Tuwairqi


and the relational database technology as middleware. In this chapter, wepresent a new and simpler algorithm for this purpose. This algorithmtransforms a schema of a XML document into a relational database schema,taking into consideration the requirement of relational database technology.

Introduction

An electronic document on the Web contains regular and irregular structuresthat may not be understood by users (Suciu, 1999; Abiteboul & Vianu, 1997;Brayan, 1997). Such a document (or data) is referred to as semistructured data(Suciu, 1999; Abiteboul, 1997). Contrary to the data in relational databases(RDBs), the semistructured data is stored without any schema or with a vagueschema (Buneman, 1997; Suciu, 1999; Buneman, 1997). Beside the Web, thereare many other sources of semistructured data, such as heterogeneous network-ing of integrated systems, file systems, electronic mail systems, digital libraries,etc. (Abiteboul, 1997; Buneman, 1997).

The introduction of Extensible Markup Language (XML) as a standard data/information representation has facilitated the publication of electronic data onthe Web (W3C, 2003). This language also provides a hierarchical format for thedata exchange over the Web with structure (St. Laurent, 1999; Bray, Paoli,Sperberg-McQueen, & Maler, 2002). Information in an XML document isrepresented as nested element structures, which start with a root element. Anelement can have an attribute or a sub-element (for further details about XMLsee W3C (2003) and Bray et al. (2002)). An XML document has an optional part,which is called Document Type Declaration/Description (DTD). A DTD ofan XML document is considered as the schema of the XML document (W3C,2003; Bray et al., 2002; Men-Hin & Fu, 2001).

A relational database (RDB) has two main components, a schema and data files(or operational files) which are created according to the schema. As said earlier,a DTD is considered as a schema of an XML document, but there are noticeabledifferences between a RDB schema and an XML document schema (DTD). Wegive a complete comparison between them in Table 1. The basic differencebetween them is that a DTD represents a hierarchical structure whereas a RDBschema represents a relational (tabular) structure. We can consider XMLdocuments schema analogous to the classical hierarchical data model.

XML is considered as the best tool for representing and exchanging informationon the Web (St. Laurent, 1999; Bray, Paoli, Sperberg-McQueen & Maler, 2002).The language allows users to define and also display data on the Web. Thesefeatures make XML powerful and different from Hypertext Markup Language



(HTML) (Suciu, 1999; Comer, 2000). XML enables the user to define his ownstructures using the syntax of the elements in a DTD. A DTD describes thestructure of information in an XML document in a hierarchical way (Bray, Paoli,Sperberg-McQueen & Maler, 2002). The structure of a DTD consists ofelements which are further specified by attributes and/or sub-elements. Recur-sive and optional types of the sub-element can be defined using the operations* (zero or more times), + (one or more times),? (optional), and | (or). Many typesof data value can be assigned to attributes, i.e., string-type or entity. The datavalue ANY means that an arbitrary declaration can be made by the programmer.An element in an XML document is uniquely identified by a special attribute ID.This unique attribute of an element can be regarded as the primary key of theelement. As it has been mentioned in Table 1, a DTD does not support theconcept of the composite ID (or key). An attribute can be referenced in anotherelement through a field called IDREF, and it is a type-less attribute. The conceptof an IDREF is similar to the concept of a foreign key in relational databases.There is no concept of a root of a DTD (Bray et al., 2002).

Nowadays, financial organizations want to empower their customers so that theycan perform their transactions from their homes through the Internet. For thesefinancial organizations to provide their customers with this facility, it is necessaryand beneficial that the databases (which are mostly RDBs) should be presentedand processed in the XML format. We therefore need a technique that willprocess and transform an RDB and queries into an XML format and vice versa.This technique (or transformation) is essential because most of the commerciallyavailable database management systems (DBMSs) are relational DBMSs.

This transformation will integrate and handle heterogeneous RDBs in the samemanner. Researchers agree that the currently available RDB technology inde-pendently is not adequate to achieve this objective of using them on the Webwithout such transformation (Shanmugasundaram et al., 1999). Recently, someresearchers have proposed algorithms for this transformation (Shanmugasundaram

Table 1. Comparison between RDB schema and DTD

RDB (Schema) XML Schema (DTD) Tabular format Hierarchical format

It supports many data types. It supports only character data types. Schema and tuples of a relation are considered as two different entities, and they are stored in

two different files.

XML document and its DTD can be stored in the same file or in two different files.

It is mandatory for a database. It is optional for a XML document especially for

small XML documents. It is based on the rational data model. It is not based on any such data model.

It supports the concept of a composite key. The concept of composite key is not supported. It supports the concept of foreign key. Does not support any such concept.

A schema of a relation is defined before creating its instances (or tuples)

Since it is optional, it can, therefore, be defined after the creation of a XML document.



et al., 1999; Williams et al., 2000; Marni & Lee, 2002; Men-Hin, & Fu; 2001).In these transformation algorithms, most investigators have considered a DTDas a schema of the XML document, and they have used the tree data structureduring the transformation. We know that the processes of creating and maintain-ing tree data structures are costly and affect the performance of the transfor-mation process as pointed out by Shanmugasundaram et al. (1999). Also, thereare many syntax options that are available for writing DTDs. Most of the existingtransformation algorithms (from DTD into RDB schema) are unable to handleDTDs written in different ways (Shanmugasundaram et al., 1999; Men-Hin &Fu, 2001). In this chapter, we propose a different approach for transforming anyDTD of an XML document into relational database schema. This approach canhandle DTDs written in different ways and transform them into relationaldatabase schema in a simple and elegant way.

The remainder of this chapter is organized as follows. We describe and analyzethe existing approaches for transforming a DTD of an XML document into arelational database schema. We then present our proposed approach fortransforming a DTD into a relational database schema, and demonstrate theproposed approach in a case study. Finally, we give our concluding remarks andfuture direction of this work.

Background Related Work

Investigators have produced many different techniques for transforming DTDsinto relational database schemas (Eisenberg & Melton, 2002; Yan, 2001;Chidlovskii, 2001; Marni & Lee, 2002; Men-Hin & Fu, 2001; Shanmugasundaramet al., 1999). There are three main issues that need to be handled during thistransformation. These issues are: (i) the complexity of the DTD elementspecifications, (ii) the resolution of the conflict between arbitrary nesting in aDTD and relational schema, (iii) set-valued attributes and recursion(Shanmugasundaram et al., 1999). In the following paragraphs, we give a briefdescription of the works of these investigators and give, in Table 5 (at the endof this chapter), a comparison of these transformation approaches and ourproposed approach.

Shanmugasundaram et al. initially proposed an approach in the form of algo-rithms for transforming a DTD of an XML document into a RDB schema. Men-Hin and Fu later proposed an improvement to the algorithms (Shanmugasundaramet al., 1999; Men-Hin & Fu, 2001). Men-Hin and Fu proposed two algorithms,both of which work in the same way, except that they differ mainly in their Step2 and Step 5. In Step 2 of the improved algorithm they gave more rules for



determining the roots. The transformation algorithm by Men-Hin and Fu worksin six steps, and they are briefly given below:

• Step 1: Simplifying the DTD: This step simplifies DTDs of XMLdocuments using the rules similar to regular expression rules. The informa-tion that is useful in constructing schema prototype trees is preserved in theDTDs. The value types (e.g., #IMPLIED, #FIXED, etc.) for the characterdata (CDATA) are removed from the DTDs.

• Step 2: Determining the Root Node: In this step, roots of the prototypetrees are determined from the simplified DTDs using the set of rules thatare suggested for this purpose.

• Step 3: Constructing Schema Prototype Trees: The prototype trees areconstructed from the roots that are determined in the previous step usinga set of rules.

• Step 4: Generating a Relational Schema Prototype: This step realizesa prototype relational database schema from the prototype tree using thefollowing rules:

(i) Regard all the necessary attributes and elements in the simplified DTDas the attributes that are treated in the entity- relationship (ER) Model.

(ii) Inline all the necessary descendants of the schema prototype treestarting from the root. The necessary descendants refer to all the leafnodes in the schema prototype tree, and the nodes marked with a “#” ifthey exist.

• Step 5: Discovering Functional Dependencies (FDs) and CandidateKeys: In this step the traditional relational database design techniques areapplied in order to produce suitable relational schemas. These designtechniques reduce the redundancy and inconsistency in a relational data-base schema, and discover the functional dependencies and the candidatekeys by analyzing the newly constructed relational database schema.

• Step 6: Normalizing the Relational Schema Prototypes: This stepapplies the normalization rules on the relational database schema, afterdetermining the FDs and candidate keys of a relational database schema inthe previous step.

In the first algorithm of Men-Hin and Fu, functional dependencies are found inStep 5, first by analyzing the XML data, and then by applying the algorithm:Efficient discovery of functional and approximate dependencies using partition-ing. Step 6 of this algorithm is time-consuming, according to Men-Hin and Fu.They modified this step to make the first algorithm more efficient (Men-Hin &Fu, 2001). The modified algorithm decomposes a DTD into small prototypes in



Step 4: Tree Construction, and Step 5: Generating a Relational Schema Proto-type. The reason for the decomposition is to minimize the cost of findingfunctional dependencies.

Both of these algorithms-the first and the modified algorithms- use the tree datastructure in their transformation processes (or algorithms). The use of this datastructure affects the performance of the transformation process becausecreating and maintaining the tree structure are costly procedures. Also, thesetwo algorithms are unable to handle all types of DTDs as it has been mentioned(Shanmugasundaram et al., 1999; Men-Hin & Fu, 2001). Eisenberg and Melton(Eisenberg & Melton, 2001; Eisenberg & Melton, 2002) gave an informalproposal for a bi-directional transformation between an XML document and aRDB. This transformation can do a complete or a partial transformation atschema level as well as tuple level (or row level). The partial transformation mayhowever miss some semantics. This draft for the bi-directional transformationsalso suggests a transformation of the data types. The authors did not give anyproper formal algorithm for these transformations. It is, therefore, difficult tocomment about the real effectiveness of these transformations.

Williams et al. have proposed 18 steps for transforming DTD into a relationaldatabase schema and 11 steps for the reverse transformation (Williams et al.,2000). Both of these transformations do not use the tree data structure, but somesteps in both of these transformations are unclear. For example, in Step 9 andStep 13 of the transformation of a DTD into a relational database schema, datatypes are assigned to attributes of a DTD without any explanation and justifica-tion. This type of vagueness in the transformation processes makes them difficultto understand and to draw any conclusion about their correctness and accuracy.

Marni and Lee (2002) have proposed a process for transforming a DTD into arelational database schema using a regular tree grammar. The use of the regulartree grammar is helpful in maintaining semantics constraints in the transforma-tion process. The theory of regular tree grammars provides a useful formalframework for understanding various aspects of XML schema languages. Thetwo normal forms (NF1 and NF2) are used for the representation of regular treegrammars. NF1 is used in the XML document validation process, and to checkwhether a given XML schema satisfies the structural constraints imposed by theschema languages.

XML Schema (or DTD) provides several unique data modeling features such asunion type “+”, which does not exist in the traditional database models, such asthe relational database model. In Marni and Lee (2002), NF2 is used forrepresenting the basic of the conversion definition of the two schema languages,that is, a schema that supports union types (e.g., XML-Schema Language), anda schema language that does not support union types (e.g., SQL). This conver-



sion definition is used as the first step in this transformation process of XMLschema into relational database schema. The entities and relationships, whichform the basic items of data modeling, are represented as elements and attributesof a DTD.

The process of mapping XML schema (or DTD) into RDB schema has severalissues, and they have been pointed out (Marni & Lee, 2002). One of the mostimportant among them is the semantic constraint which exists in the XML model.Since relational database schema cannot express these constraints in the XMLschema languages, a useful and meaningful subset of those constraints shouldtherefore be found in the mapping process. This process of finding the subsetneeds simplification of an XML schema. The concept of inlining technique isused for generating an efficient relational schema (Marni & Lee, 2002).However, the inline technique that is presented in this work generates a hugenumber of relations. In addition, this work does not present any proposal forassigning data types to attributes of tables after or during the transformationprocess. The transformation process of an XML DTD to relational data schemais the mapping of each element in the DTD to a relation, and it maps the attributesof an element to the attributes of the relation. However, there is no correspon-dence between elements and attributes of DTDs and entities and attributes of ERmodel. The attributes in an ER model are often represented as elements in aDTD. The following DTD definition illustrates this issue of the transformation.

<!ELEMENT author (name, address)>

<!ATTLIST author id ID #REQUIRED>

<!ELEMENT name (firstname , lastname)>

<!ELEMENT firstname (#PCDATA)>

<!ELEMENT lastname (#PCDATA)>

<!ELEMENT address ANY>

In the ER model, author would be taken as an entity and firstname, lastnameand address would be taken as the attributes of the entity. But in defining a DTD,there is no incentive to consider author as an element and firstname, lastname,and address as attributes. In the syntax of a DTD, if firstname and lastnamewere defined as attributes, then they could not be nested under name becauseDTD attributes cannot have a nested structure. A direct mapping of elements torelations therefore leads to an excessive fragmentation.



Proposed Transformation Approach

Our proposed transformation approach (or process) works in two steps. The firststep takes a DTD written in any form using the syntax available for writing DTDsand transforms it into a standard form that is devised keeping in view the syntaxof a relational database schema. The second step of our proposed approachtakes a DTD in the standard form and transforms it into a relational databaseschema.

In our proposed approach, we do not include the processes of finding functionaldependencies (FDs), assigning data types to attributes of relations after thetransformation (note that DTD supports only one data type, i.e., PCDATA), andnormalization of the relation schema. The reason for this is that these threeprocesses are database design techniques and they depend on the perception ofa database designer about the database schema (Elmasri & Navathe, 2000).These processes need a direct or indirect expert’s intervention and decision.Therefore, we separate these three processes from the actual transformationprocess, i.e., DTD in relational schema. In other words, these three processesare difficult to automate. Consequently, we have separated the processes thatshould be done manually from the processes that can be automated. Thisseparation makes our algorithm simpler and has helped in our objective totransform any DTD into a relational schema. In this section, we propose onlythose processes of the transformation that can be automated.

The proposed approach consists of two algorithms (or steps): (i) Pre-ProcessingAlgorithm and (ii) Transformation Algorithm. Figure 1 shows a general view ofour proposed transformation process. The first algorithm (i.e., Pre-ProcessingAlgorithm) transforms any DTD that is written in any form (referred to asDTD

a), into the standard DTD that is referred to as DTD

s (Figure 1). The main

objective of Pre-Processing Algorithm is to transform a DTD into a simpleuniform and standard form. The second algorithm, (i.e., Transformation Algo-rithm), transforms a DTD in this standard form into an RDB schema (Figure 1).

Figure 1. General view of the algorithm

Pre-Processing Algorithm

Transforming Algorithm

DTDa

DTDs

RDB_Schema



Figure 2. Format of the standard DTD (DTDs)

1.<!DOCTYPE DTD_Name [

2.<!ELEMENT element_name ( sub_elementi *)* | EMPTY | (#PCDATA) >

3.<!ATTLIST element_name

4. attribute_name CDATA #FIXED | #IMPLIED | #REQUIRED

5. id? ID #REQUIRED | #IMPLIED

6. idref* IDREF #REQUIRED | #IMPLIED

7. idrefs* IDREFS #REQUIRED | #IMPLIED >

Pre-Processing Algorithm

As it has been mentioned earlier, there is no standard and fixed method forwriting a DTD of an XML document. In other words, different users can writeDTDs in different ways using the options provided by the syntax of DTD. Themain objective of the Pre-processing is to enable the overall transformationprocess to handle DTDs that are written in different ways. Hence, the mainfunction of this algorithm is to transform DTDs written in different forms into auniform and standard form. The output of this algorithm is the standard DTDdenoted as DTD

s, and it is used as the input to the Transformation Algorithm

(Figure 1).

Now we summarize the objectives of the standard DTD and give its format (orsyntax). The main objectives of the standard DTD are listed below:

(i) to provide input to Transformation Algorithm in a uniform and standardform; and

(ii) to enable the overall transformation process handle DTDs written indifferent ways.

The proposed syntax/format of the standard DTD is given in Figure 2. In thefigure, the operators ? and * mean zero or one, and zero or more, respectively.The structure given in Lines 2-7 in Figure 2 can be repeated until it produces astandard DTD and the number of repetitions depends on the corresponding XMLdocument structure. For example, in the standard Library DTD given in Figure3, this structure (i.e., Lines 2-7 in Figure 2) is repeated four times. In the figure,we have given a blank line after each repetition of the structure. The steps in the



Figure 3. Example of Library DTD in the standard DTD format

<!ELEMENT Library (Books+, Publishers+, Borrowers+, Loans+)>

<!ELEMENT Books (#PCDATA)>

<!ATTLIST Books LCNo ID #REQUIRED

PName IDREF #REQUIRED

title CDATA #FIXED

author CDATA #FIXED>

<!ELEMENT Publishers (#PCDATA)>

<!ATTLIST Publishers PName ID #REQUIRED

PAddr CDATA #FIXED

PCity CDATA #FIXED>

<!ELEMENT Borrowers (#PCDATA)>

<!ATTLIST Borrowers CardNo ID #REQUIRED

Name CDATA #FIXED

Addr CDATA #FIXED

City CDATA #FIXED>

<!ELEMENT Loans (#PCDATA)>

<!ATTLIST Loans CardNo ID #REQUIRED

LCNo IDREF #REQUIRED

Date CDATA #FIXED>

Pre-Processing Algorithm are given in Figure 4. The algorithm takes any DTD(DTD

a) and transforms it into the standard DTD (DTD

s).

In the Global Schema Extraction Algorithm (Men-Hin & Fu, 2001), elements andattributes are treated equally and represented as separate nodes in the prototypetree. The same approach is used in the DTD-splitting Schema ExtractionAlgorithm (Men-Hin & Fu, 2001) and Basic Inlining Algorithm(Shanmugasundaram et al., 1999). But our proposed Pre-Processing Algorithm



Figure 4. Pre-processing algorithm

Algorithm Pre-processing (DTDa):DTDs

(i)Scan DTD_Name in DTDa and make it DTDs_Name of DTDs

and add <!DOCTYPE DTDs_Name [ ;

/* DTDs is the standard DTD */

(ii) Find all the Root_elements of DTDa;

/* Root_element is the element that is not sub-element of

any other element in the DTD */

(iii)Scan Root_element of DTDa and make it Root_element of DTDs;

(iv) For each Root_element Find total number of main_elements, say that

they are n;

/* n is the total number of main_elements */

/* main_element has the following aspects:

(i) a sub-element of the Root_element,(ii)a sub-element of another

main_element, and/or (iii) has at least one sub-element, or (iv) has at

least one attribute */

(v) Transform the main_elements into DTDs as follows

<!ELEMENT Root_element (main_element1,..,main_elementn)> ;

(vi) FOR i= 1 to n

Find total number of sub-elements in main_elementi

say they are m;

/* Root_element could be main_element; for example if it has at

least one sub-element or at least one attribute */

/* the sub-element has one of the following features (i)it has no sub-

elements, (ii)neither sub-element of any other main_element nor sub-

element of the Root_element, and (iii)is not a main_element */

IF m > 0 THEN Add <!ELEMENT main_elementi (#PCDATA)> ; Add <!ATTLIST main_elementi ; FOR j=1 to m

Transform sub-elementj into DTDs as sub-elementj CDATA #FIXED



END FOR LOOP /*inner loop*/

attribute:

IF main_elementi has an attribute of type ID THEN Transform it in

DTDs as

attribute_name ID #REQUIRED

ELSEIF main_elementi has an attribute of type IDREF/IDREFS THEN

Transform it in DTDs as

attribute_name IDREF TYPE

/* TYPE is the type of the attribute originally exist in DTDa

it could be (#REQUIRED, #IMPLIED, #FIXED, or defaultvalue)

just transform it as it is in DTDa */

ELSE Transform any other attribute defined in DTDa, into DTDs

as it is defined in DTDa

add ‘>’

ELSE add main_elementi to DTDs as its;

/* it means m = 0; that is for the two cases: (i)<!ELEMENT main_elementi

(#PCDATA)> ,and (ii)<!ELEMENT main_elementi EMPTY> */

GOTO attribute;

END FOR LOOP /* outer loop */

(vii) add ‘]>’;

(viii) RETURN (DTDS);

(ix)END Algorithm;

Figure 4. Pre-processing algorithm (continued)

transforms all sub-elements of a main element into attributes of that mainelement.

Transformation Algorithm

The Transformation Algorithm takes the DTDs of an XML document as an input

and transforms it into a relational database schema (RDB_Schema). In Figure 5,we give the steps in the algorithm. In this algorithm, there are two nested loops.



The outer loop deals with elements of the DTDs and transforms them into

corresponding tables/relations. The inner loop transforms every attribute of theelement into the attributes of the corresponding relation. In Step (iii) of thealgorithm (Figure 5), it transforms ID and IDREF attributes of an element intothe primary key and foreign key of the relation, respectively. Note that since thesyntax of DTD does not support the concepts of composite key, our proposedtransformation process, therefore, does not support this concept.

Figure 5. Transformation algorithm

Algorithm Transforming (DTDs): RDB_Schema

(i) Scan Root_element of DTDs make it as Schema_name

of RDB_schema;

(ii) Find total number of main_elements in DTDs (say they are n);

(iii)IF n = 0 THEN EXIT();

ELSE

FOR i = 1 to n

Transform main_elementi into Tablei and give it the name of main_elementi;

Find total number of attributes in main_elementi (say they are m);

IF m = 0 THEN i++

ELSE

FOR j = 0 to m

Scan attribute_namej;

IF attribute_namej is of type ID THEN

make attribute_namej as primary key of Tablei ;

ELSEIF attribute_namej is of type IDREF THEN

make attribute_namej as a foreign key of Tablei ;

ELSE make attribute_namej a normal attributej of

Tablei;

END FOR LOOP; /* inner loop */

END FOR LOOP; /* outer loop */

(iv) RETURN (RDB_Schema);

(v) END Algorithm



Figure 6. DTDa of the Library XML document

1) <!DOCTYPE The_LIBRARY [

2) <!ELEMENT Library (Books+, Publishers+, Borrowers+, Loans+ )>

3) <!ELEMENT Books (title, author, PName, LCNo)>

4) <!ELEMENT title (#PCDATA) >

5) <!ELEMENT author (#PCDATA)>

6) <!ELEMENT PName (#PCDATA)>

7) <!ATTLIST PName idref IDREF #REQUIRED>

8) <!ELEMENT LCNo EMPTY>

9) <!ATTLIST LCNo id ID #REQUIRED>

10) <!ELEMENT Publisher (PName, PAddr, PCity)>

11) <!ELEMENT PName (#PCDATA)>

12) <!ATTLIST PName id ID #REQUIRED>

13) <!ELEMENT PAddr (#PCDATA)>

14) <!ELEMENT PCity (#PCDATA)>

15) <!ELEMENT Borrowers ( Name, Addr, city, CardNo)>

16) <!ELEMENT Name (#PCDATA)>

17) <!ELEMENT Addr (#PCDATA)>

18) <!ELEMENT city (#PCDATA)>

19) <!ELEMENT CardNo EMPTY>

20) <!ATTLIST CardNo id ID #REQUIRED>

21) <!ELEMENT Loans (CardNo, LCNo, Date)>

22) <!ELEMENT CardNo EMPTY>

23) <!ATTLIST CardNo id ID #REQUIRED>

24) <!ELEMENT LCNo EMPTY>

25) <!ATTLIST LCNo idref IDREF #REQUIRED>

26) <!ELEMENT Date (# PCDATA)> ] >

Case Study: Library DTD

In this section, we take a DTD that is written in a general form and demonstratethe workings of our proposed transformation process. For this purpose, we takea Library DTD

a of a Library XML document given in Figure 6. We first apply

Pre-Processing Algorithm that takes the DTD given in Figure 6 as input andproduces a DTD

s in the standard form as its output given in Figure 3. After

applying Pre-Processing Algorithm to the Library DTDa the complete trace and

step-wise working of the algorithm are given in Table 2 and Table 3 respectively.In Table 3 we give the transformation of the markup statements of the DTD

a, and

the output of the Pre-Processing Algorithm on Library DTDa is given in Figure 3.

After pre-processing of the Library DTDa and transforming it into the standard

DTDs, then Transformation Algorithm is applied to DTD

s. This algorithm

transforms the Library DTDs (Figure 3) into a Library RDB-Schema given in



Table 2. Trace of the pre-processing algorithm for Library DTDa

Root_element n i Main_element m j sub-elements ID IDREF Lno

Library 4 1 Books 4 1 title N N 1

2 author N N 2 3 PName N N 3 4 LCNo Y - 4

2 Publisher 3 1 PName Y - 5 2 PAddr N N 6

3 PCity N N 7

3 Borrowers 4 1 Name N N 8 2 Addr N N 9 3 City N N 10 4 CardNo Y - 11

4 Loans 3 1 CardNo Y - 12 2 LCNo N Y 13

3 Date N N 14

Table 3. Transformation of the markup statements

Lno The Markup Statement 1 title CDATA #FIXED 2 author CDATA #FIXED 3 PName IDREF #REQUIRED 4 LCNo ID #REQUIRED 5 Pname ID #REQUIRED 6 PAddr ID #REQUIRED 7 PCity CDATA #FIXED 8 Name CDATA #FIXED 9 Addr CDATA #FIXED 10 City CDATA #FIXED 11 CardNo ID #REQUIRED 12 CardNo ID #REQUIRED 13 LCNo IDREF #REQUIRED 14 Date CDATA #FIXED

Table 4. Trace of transformation algorithmSchema_name n i Main_element Table m j Attribute ID IDREF

Library 4 1 Books Table_Books 4 1 title N N

2 author N N

3 PName N Y

4 LCNo Y -

2 Publisher Table_Publisher 3 1 PName Y -

2 PAddr N N

3 PCity N N

3 Borrowers Table_Borrowers 4 1 Name N N

2 Addr N N

3 City N N

4 CardNo Y -

4 Loans Table_Loans 3 1 CardNo Y -

2 LCNo N Y

3 Date N N



Table 5. Comparative study of our approach with some existing approaches

Basic Inlining SI&HI * Global

Extracting DTD-splitting

Extracting Williams

et al.

Regular Tree

Grammars Our Approach

Data Structure

Used graph graph tree tree

relational structure

regular tree grammars

no such abstract data structure is

used

Operators Handling

creates a relation for

every element in the DTD

ensures that each

element is represented only once

in a relation

eliminates operators

from DTD

preserves some operators to

preserve some sub-elements occurrences

some rules are

specified to handle them

support XML-schema

(not DTD)

pre-pressing algorithm processes

them

Advantage handles

fragmentation Problem **

the common elements

are shared

actual data fields are

available in relational schema

number of attributes of the schema is less

than the algorithms

basic inlining

preserves entities and definitions

maintains semantics constrains

simple, direct mapping &

maintains the semantics of

RDB

Disadvs. ✦ large no. of relations it

creates

large number of

joins in mapping

for particular elements

number of possible minimal

dependencies is

exponential

works with limited number of elements and

attributes

some rules of the

mapping are vague such as

assigning of data types to

attributes

a complex mapping process

data types assigning is with human intervention

Prfce✦✦ low low low low didn’t

mention didn’t

mention high

(expected)

*. A direct mapping of elements to relations leads to excessive fragmentation of attributes (for more details see (Marni, M & Lee, D. 2002 )). ** Performance.

.Disadvantages. . Performance.

Figure 7. The trace of the algorithm is given in Table 4. In Figure 7, attributes,which are underlined, and those that are bold and underlined, denote primarykeys and foreign keys, respectively. Note that all attributes of the relationaldatabase schema given in Figure 7 are typeless attributes and they can be givendata types through user intervention. This issue and some other issues related tothis work are identified in the section on Future Direction.



A Few Words About Automation

We have automated the proposed transformation process by implementing bothits modules, i.e., Pre-Processing Algorithm and Transformation Algorithm. Wehave used the programming language Delphi Version 7 as the implementationlanguage. The first module parses the input DTD, checks its syntax and finds outsyntax errors (if any), and transforms the input DTD into the standard form. Thesecond module transforms the standard DTD in a relational schema.

Concluding Remarks and FutureDirections

In this chapter, we have given a new transformation algorithm (or an approach)to transform the DTDs (of an XML document) that are written in differentsyntax options, into a relational database schema. This transformation processconsists of two algorithms: (i) Pre-Processing Algorithms, and (ii) Transforma-tion Algorithm. We have defined: (a) the format of a standard DTD that is closerto a relational database schema, (b) Pre-Processing Algorithm that transformsany DTD (that is written in any form) of an XML document into this standardformat, and (c) the Transformation Algorithm that transforms the standard DTDof the original DTD into a relational database schema. We have demonstratedthe complete working of our proposed algorithm using a case study. Ourproposed approach is simpler, formal and different from the existing approachesthat have been suggested by Shanmugasundaram et al. (1999), and others (Men-Hin & Fu, 2001; Williams et al., 2000; Eisenberg & Melton, 2001; Eisenberg &

Figure 7. RDB schema for Library DTDs

Table_Books�

title author PName LCNo

Table_Publisher�

PName PAddr PCity

Table_Borrowers�

Name Addr City CardNo

Table_Loans

CardNo LCNo Date



Melton, 2002). Most of these approaches use the tree data structure, whichrequires costly operations in creating and maintaining it. Our approach does notuse a tree data structure and this makes it simpler and more efficient than thoseapproaches that use the tree data structure. We have also given a briefcomparative study of our proposed approach and some existing approaches inTable 5.

Future Directions

We are actively working on the complete and comprehensive implementation ofthe proposed transformation algorithm. We have briefly mentioned some of theresults of our initial implementation in this chapter. After a complete implemen-tation of our proposed algorithm, we will analyze the results of our transformationprocess, and compare them with the results of others. We are also working onmaking our proposed algorithm to be bi-directional so that our new algorithm willtransform relational databases schema into a DTD as well.

We also suggest that investigation should also focus on issues that are related tothe bi-directional transformation (i.e., XML documents schema into RDBSchema, and vice versa). These issues are:

(i) Handling of IDREFS: It can be an interesting study to translate the conceptof IDREFS into the relational paradigm.

(ii) Naming conflict between relations and attributes during the transforma-tions.

(iii) Assigning data types to attributes, because DTD supports only characterdata type and RDB schema supports multiple data types. Upon thecompletion of the transformation process, we get typeless RDB schema. Ittherefore needs further study on when and how data types should beassigned to attributes of tables.

References

Abiteboul, S. (1997). Querying semi-structured Data. Proceedings of Interna-tional Conference on Database Theory.

Abiteboul, S., Buneman, P. & Suciu, D. (2000). Data on the Web. CA: MorganKaufmann.

Abiteboul, S. & Vianu, V. (1997). Querying the Web. Proceedings of theICDT.



Bray, T., Paoli, J., Sperberg-McQueen, C. M. & Maler, E. (2002). ExtensibleMarkup Language (XML). Second Edition. Retrieved from the WWW:http://www.w3c.org/TR/REC-xml

Brayan, M. (1997). SGML and HTML Explained (2nd ed.). New York: AddisonWesley.

Buneman, P. (1997). Semi structured data. Proceedings ACM Symposium onPrinciples of Database Systems, (pp. 117-121).

Chidlovskii, B. (2001). Schema Extraction from XML Data: A GrammaticalInference Approach. Proceedings of the Eighth International Work-shop on Knowledge Representation meets Databases (KRDB2001),Italy.

Comer, D. (2000). The Internet Book (3rd ed.). NJ: Prentice Hall.

Eisenberg, A. & Melton, J. (2002). SQL/XML is Making Good Progress. ACMSIGMOD Record, 31(2),101-108.

Eisenberg, A. & Melton, J. (2001). SQL/XML and the SQL Information Groupof Companies. ACM SIGMOD Record, 30(3), 105-108.

Elmasri, R. & Navathe, S. (2000). Fundamental of Database Systems (3rd ed.).Benjamin/Cumming Publishing.

Marni, M. & Lee, D. (2002). XML to Relational Conversion using TheoryRegular Tree Grammars. Proceedings of the 28th VLDB Conference,Hong Kong.

Men-Hin, Y. & Fu, A. (2001). From XML to Relational Database. Proceedingsof the Eighth International Workshop on Knowledge Representationmeets Databases (KRDB2001), Italy.

Shanmugasundaram J., Tufte, K., Zhang, C., DeWit, D. & Naughton, J. (1999).Relational Database for Querying XML Documents: Limitations andOpportunities. Proceedings of the 25th VLDB Conference, Edinburgh,Scotland (pp. 302-314).

St.Laurent, S. (1999). XML A Primer (2nd ed.). CA: M&T Books.

Suciu, D. (1999). Semi Structured Data and XML. Proceedings of ACMSIGMOD (pp. 430-441).

Williams, K. et al. (2000). Professional XML Databases. UK: Wrox Press.

World Wide Web Consortium (W3C): Extensible Markup Language (XML),http://www.w3.org/XML.

Yan, M. (2001). From XML to Relational Database. M. Phil Thesis, ChineseUniversity of Hong Kong, Dept. of Computer Science.

190 Ma


Chapter IX

Imprecise andUncertain EngineeringInformation Modeling

in Databases:Models and

Formal Transformations

Z. M. Ma, Université de Sherbrooke, Canada

Abstract

Computer-based information systems have become the nerve center ofcurrent manufacturing systems. Engineering information modeling indatabases is thus essential. However, information imprecision anduncertainty extensively arise in engineering design and manufacturing. Socontemporary engineering applications have put a requirement on impreciseand uncertain information modeling. Viewed from database systems,engineering information modeling can be identified at two levels: conceptualdata modeling and logical database modeling and correspondingly wehave conceptual data models and logical database models, respectively. Inthis chapter, we firstly investigate information imprecision and uncertainty

Imprecise and Uncertain Engineering Information Modeling 191


in engineering applications. Then EXPRESS-G, which is a graphicalmodeling tool of EXPRESS for conceptual data modeling of engineeringinformation, and nested relational databases are extended based onpossibility distribution theory, respectively, in order to model impreciseand uncertain engineering information. The formal methods to mappingfuzzy EXPRESS-G schema to fuzzy nested relational schema are developed.

Introduction

Nowadays computer-based information systems have become the nerve centerof current manufacturing systems. Engineering information modeling in data-bases is thus essential. From the point of view of database systems, engineeringinformation modeling can be identified at two levels: conceptual data modelingand logical database modeling. Correspondingly, we have conceptual datamodels and logical database models for engineering information modeling,respectively. Product data models, for example, can be viewed as a class ofconceptual data models that take into account the needs of engineering data(Shaw, Bloor & Pennington, 1989). Much attention has been directed atconceptual data modeling of engineering information because conceptual datamodels can capture and represent rich and complex semantics in engineeringapplications at a high abstract level. Limited by the power of traditional ER/EER(Chen, 1976) in engineering modeling, the International Organization for Stan-dardization (ISO) has developed the Standard for the Exchange of Product Data(STEP, ISO 10303) in order to define a common data model and procedures forthe exchange of information. STEP provides a means to describe a productmodel throughout its life cycle and to exchange data between different units.STEP consists of four major categories: description methods, implementationmethods, conformance testing methodology and framework, and standard-ized application data models/schemata. EXPRESS (Schenck & Wilson,1994), being the description methods of STEP and a conceptual schemalanguage, can model product design, manufacturing, and production data andEXPRESS model hereby becomes a major one of the conceptual data models forengineering information modeling (Eastman & Fereshetian, 1994). Note that,however, not being the same as ER/EER and IDEF1X, EXPRESS is not agraphical schema language. In order to construct an EXPRESS data model at ahigher abstract level, EXPRESS-G is introduced as the graphical representationof EXPRESS. Here EXPRESS-G can only express a subset of the full languageof EXPRESS. In addition to EXPRESS-G, it is also suggested in STEP thatIDEF1X or ER/EER can be used as one of the optional languages for EXPRESSdata model design. Then EXPRESS-G, IDEF1X, ER/EER, or even UML data

192 Ma


model can be translated into EXPRESS data model. As to engineering informa-tion modeling in database systems, most of generic logical database models suchrelational databases, nested relational databases, and object-oriented databasescan be used. Also some hybrid logical database models (e.g., object-relationaldatabases) or some special databases based on these database models (activedatabases, deductive databases, and constraint databases) are very useful forthis purpose.

It should be noticed, however, that information is not always crisp in realapplications. Imperfect Information exists extensively in engineering applica-tions. Imprecision is most notable in the early phase of the design process andhas been defined as the choice between several design alternatives. In additionto product design, imprecise and uncertain information can be found in otheractivities related to engineering. Concerning the representation of imprecisionand uncertainty, attempts have been made to address the issue of imprecision andinconsistency in design by employing intervals (Kim et al., 1995). Otherapproaches to representing imprecision in design include using utility theory,implicit representations using optimization methods, matrix methods such asQuality Function Deployment, probability methods, and necessity methods. Anextensive review of these approaches was provided in Antonsoon and Otto(1995). All of these methods have had limited success in solving design problemswith imprecision. Currently, modeling fuzzy engineering information in concep-tual data models and logical database models is receiving increasing attention.

To model imprecise and uncertain information in database models, manytraditional database models have been extended. Being the most commondatabase model, the relational model has been extended to handle null values,fuzzy values, partial values, intervals, and probabilistic values. It should be notedthat it is very difficult for a relational data model based on a flat relational tableto model the complex structure and rich semantics of real-world objects.Therefore, the database models for modeling imprecise and uncertain informa-tion have increasingly been focused on the object-oriented database model(Bordogna, Pasi & Lucarella, 1999; George et al., 1996; Gyseghem & Caluwe,1998; Vila et al., 1996) and the nested (NF2) relational database model (Yaziciet al., 1999). Also some attention has been paid to information uncertainty andimprecision modeling in conceptual data models such as the entity-relationship(ER) model (Zvieli & Chen, 1986), extended entity-relationship (EER) model(Chen & Kerre, 1998), and IFO model (Vila et al., 1996; Yazici et al., 1999). ButEXPRESS has no the capacity of modeling imprecise and uncertain information,although imprecise and uncertain information exists extensively in engineeringapplications.

A classical database is generally created by first developing a high-levelconceptual data model and then mapping this conceptual model into an actual



implementation. The ER model, for example, is extensively used for theconceptual design of relational databases (Teorey, Yang & Fry, 1986). Similarly,engineering information modeling generally starts from conceptual data modelsand then the developed conceptual data models are mapped into logical databasemodels. But less research has been done in developing design methodologies forimplementing fuzzy databases, although some fuzzy conceptual data models andlogical database models have been developed. It is especially true for fuzzyengineering information modeling in databases. Extending EXPRESS-G tomodel fuzzy information in a product data model was initially presented by Maet al. (2000), where some main concepts and graphical representations weregiven. Modeling imprecise information, however, was not considered (Ma et al.,2000). In particular, the logical database model for product data with impreciseand uncertain information and its design methodology were not provided.

In this chapter, we concentrate on a fuzzy nested relational database model andfuzzy EXPRESS-G model. After introducing the basic knowledge on fuzzy setand possibility distribution theories, EXPRESS-G, and nested relational data-bases, we extend EXPRESS-G and nested relational databases using possibilitydistribution theory, respectively, so that fuzzy engineering information can bemodeled at two levels: conceptual data model and logical database model. Basedon the investigation that nested relational databases can support an EXPRESSmodel, we develop the formal methods to mapping from fuzzy EXPRESS-G tofuzzy nested relational databases.

The remainder of the chapter is organized as follows: The basic knowledge aboutpossibility distribution theory, EXPRESS-G, and nested relational databases aregiven. Based on possibility distribution theory, EXPRESS-G and nested relationaldatabases are extended. The formal methods to mapping fuzzy EXPRESS-Gschema to fuzzy nested relational schema are developed. The chapter thenconcludes.

Basic Knowledge

Information Imprecision, Uncertainty and PossibilityDistribution Theory

Inconsistency, imprecision, vagueness, uncertainty, and ambiguity are five basickinds of imperfect information in database systems (Bosc & Prade, 1993; Klir& Folger, 1988). Intuitively, imprecision and vagueness are relevant to thecontent of an attribute value, and it means that a choice must be made from a

194 Ma


given range (interval or set) of values, but we do not know exactly which one tochoose at present. For example, “between 20 and 30 years old” and “young”for the attribute Age are imprecise and vague values, respectively. In general,vague information is represented by linguistic values.

Imprecise values generally denote range-values with the form [ail, a

i2, ..., a

im] or

[ai1-a

i2] for the discrete and continuous universe of discourse, respectively,

meaning that exactly one of the values is the true value for the single-valuedattribute, or at least one of the values is the true value for the multivaluedattribute. Imprecise information hereby has two interpretations: disjunctiveinformation and conjunctive information. In addition to range values, there existsone special kind of imprecise information, namely, null values (Codd, 1987;Motor, 1990; Parsons, 1996; Zaniola, 1986).

Information uncertainty is related to the truth degree of its attribute value, andit means that we can apportion some, but not all, of our belief to a given value ora group of values. For example, the sentence, “I am 95 percent sure that Tomis married” represents information uncertainty. The random uncertainty, de-scribed using probability theory, is not considered in this chapter.

Generally speaking, several different kinds of imperfection can co-exist withrespect to the same piece of information. For example, that it is almost sure thatJohn is very young involves information uncertainty and vagueness simulta-neously. Imprecision, uncertainty, and vagueness are three major types ofimperfect information. Vagueness and uncertainty can be modeled with possi-bility theory (Zadeh, 1978). Therefore, we mainly concentrate on fuzzy extensionof EXPRESS-G model and fuzzy nested relational databases in this chapter.

Fuzzy data is originally described as fuzzy set by Zadeh (1965). Let U be auniverse of discourse, then a fuzzy value on U is characterized by a fuzzy set Fin U. A membership function µ

F: U → [0, 1] is defined for the fuzzy set F, where

µF

(u), for each u ∈ U, denotes the degree of membership of u in the fuzzy setF. Thus the fuzzy set F is described as follows:

F = {µ (u1)/u

1, µ (u

2)/u

2, ..., µ (u

n)/u

n}

When µF (u) is viewed to be a measure of the possibility that a variable, say X,

has the value u in this approach, where X takes values in U, a fuzzy value isdescribed by a possibility distribution π

X (Prade & Testemale, 1984; Zadeh,

1978).

πX = {π

X (u

1)/u

1, π

X (u

2)/u

2, ..., π

X (u

n)/u

n}



Here, for each ui ∈ U, π

X (u

i) denotes the possibility that X takes value u

i. Let

πX and F be the possibility distribution representation and the fuzzy set represen-

tation for a fuzzy value, respectively. Then X and F are usually regarded as the

same things, i.e., πX = F.

EXPRESS-G

EXPRESS-G is the graphical representation of EXPRESS, which uses graphicalsymbols to form a diagram (Eastman & Fereshetian, 1994; Shaw, Bloor &Pennington, 1989). Note that it can only represent a subset of the full languageof EXPRESS. EXPESS-G provides support for the notions of entity, type,relationship, cardinality, and schema. The functions, procedures, and rules inEXPRESS language are not supported by EXPRESS-G.

EXPRESS-G has three basic kinds of symbols for definition, relationship, andcomposition. Definition and relation symbols are used to define the contents andstructure of an information model. Composition symbols enable the diagrams tobe spread across many physical pages.

Definition symbols. A definition symbol is a rectangle enclosing the name ofthe thing being defined. The type of the definition is denoted by the style of thebox. Symbols are provided for simple type, defined type, entity type, and schema.

• Simple type symbols. A number of predefined simple types offered byEXPRESS language include Binary, Boolean, Integer, Logical, Number,Real, and String. The symbol for them is a solid rectangle with a doublevertical line at its right end. The name of the type is enclosed within the box.The symbols for these simple types are shown in Figure 1.

• Type symbols. The symbols for the select, enumeration and defined datatypes are dashed boxes as shown in Figure 2.

• Entity symbols. The symbol for an entity is shown in Figure 3.

• Schema symbols. The symbol for a schema is shown in Figure 4.

Relationship symbols. There are three different styles of lines, namely, adashed line, a thick solid line, and a thin solid line, which are employed to connectrelated definition symbols. The symbols for these three lines are shown inFigure 5.

A relationship for an optional valued attribute of an entity is displayed as a dashedline, as is a schema-schema reference. A supertype-subtype relationship isdisplayed as a thick solid line. All other relationships are displayed as thin lines.

196 Ma


Note that the lines with open circles denote relationship directions in EXPRESS-G.

Composition symbols. Graphical representation of models often spans manypages. Each page in a model must be numbered so that we can keep track ofwhere we are in the model and enable inter-page referencing. In addition, aschema may utilize definitions from another schema. Therefore, there are twokinds of composition symbols for page references and inter-schema references,which are shown in Figure 6 and Figure 7, respectively. EXPRESS-G providestwo levels of modeling, namely, schema level model and entity level model.Therefore, we discuss the fuzziness in the entity level model and in the schemalevel model in the following, respectively.

Nested Relational Databases

There is the restriction of first normal form (1NF) in traditional relationaldatabases, which assumes that each attribute value in a relational instance must

Figure 1. Simple type symbols

Figure 2. Type definition symbols

Binary Boolean Integer Logical Number Real String

Figure 3. Entity definition symbol

DefType Select Enumeration

Entity name

Figure 4. Schema definition symbol

Figure 5. Relationship line styles

Schema name

Dashed line Thick line Thin line



be atomic. It is clear that this assumption limits the expressive power of thetraditional relational database model in modeling complex objects with rich datatypes and semantic relationships in the real applications.

The first attempt to relax this limitation was made by Makinouchi (1977). In thisinitial work, attribute values in the relational instance may be atomic or set-valued. We call such relational databases non-first normal form (NF2) relationaldatabases. After Makinouchi’s proposal, NF2 database model is further ex-tended (Motor & Smets, 1997; Schek & Scholl, 1986; Yazici et al., 1999). TheNF2 database model in common sense now means that attribute values in therelational instances are either atomic or set-valued and even relations them-selves. So NF2 databases are called nested relational databases also. In thischapter, we do not differentiate between these two notions. It can be seen thatthe NF2 database model is a generalized relational data model, but it can modelcomplex objects and relationships. A formal definition of NF2 database model(Yazici et al., 1999) is given as follows.

Definition. Let a relation r have schema R = (A1, A2, ..., An) and let Dl, D2,..., Dn be corresponding domains from which values for attributes (A1, A2, ...,An) are selected. Attribute Aj is a higher order attribute if its schema appearson the left-hand side of a rule; otherwise, it is simple.

Definition. An NF2 schema may contain any combination of simple or higherorder attributes on the right-hand side of the rules. An instance of relation r,

Figure 6. Position symbols for page references

Figure 7. Position symbols for inter-schema references

Reference onto this page

Page #, Ref # (#, #, ... Page #, Ref # Name

alias

Schema.def

Definition referenced from another schema

alias

Schema.def

Definition used from another schema

198 Ma


denoted by r, consists of attributes (A1, A2, ..., An). A tuple of an NF2 relationis an element in r and denoted as <a1, a2, ..., an> consisting of n components.Each component aj (1 ≤ j ≤ n) may be an atomic or null value or another tuple.If Aj is a higher order attribute, then the value aj need not be a single value, butan element of the subset of the Cartesian product of associated domains D

jl, D

j2,

..., Djm

.

Let us look at the hierarchy structure of car products shown in Figure 8 (Erens,Mckay & Bloor, 1994; Li, Zhang & Tso, 2000; Zhang & Li, 1999). The Carstructure can be defined as a nested data model utilizing the following forms:

Car = (Car _Id, Interior, Chassis, Gearbox, Engine)

Interior = (Interior _Id, Dashboard, Seat)

Engine = (Engine_Id, Size, Turbo)

A NF2 relational instance for the Car product data model is illustrated inTable 1.

Based on NF2 database model, the ordinary relational algebra operations havebeen extended. In addition, two new restructuring operators, called the Nest and

Figure 8. Hierarchy structure of car product

Table 1. Nested relation for car product

Car

Gearbox Chassis Engine Interior

Dashboard Seat Interior_Id

Car_Id

Turbo Size Engine_Id

Interior Engine

Car_Id Interior_Id Dashboard Seat

Chassis

Gear-

box Engine_Id Size Turbo

VA11 IN01 SE89 DB24 CH01 GE5 E18 1.8 No

VA12 IN02 SE35 DB35 CH02 GE5 E20 2.0 Yes



Unnest (Ozsoyoglu et al., 1987; Roth, Korth & Batory, 1987; as well as Packand Unpack in Ozsoyoglu et al., 1987), have been introduced. The Nest operatorcan gain the nested relation including complex-valued attributes. The Unnestoperator is used to flatten the nested relation. That is, it takes a relation nestedon a set of attributes and desegregates it, creating a “flatter” structure. Theformal definitions and the properties of these two operators as well as theordinary relational algebra for the NF2 data model can be found in Colby (1990)and Venkatramen and Sen (1993).

The NF2 data model is useful in an engineering data modeling due to its capacityof modeling complex objects with hierarchical structure, which are very commonin engineering areas. Let’s look at the Instance-As-Type (IAT) problemproposed in Erens, Mckay and Bloor (1994) and Li, Zhang and Tso (2000). TheIAT means that an object appears as a type in one information base, but also asan instance in another information base at the same time. An IAT phenomenon,for example, occurs in the interior of car in the above example. The IATproblems can result in the more difficulty and cost in the maintenance ofinformation consistency. So we must resolve them in product data modeling, orupdate anomaly occur. It is shown in Table 2.1 that the NF2 data model can avoidthe IAT problems naturally.

Extended EXPRESS-G

Since entity and schema are keys of the EXPRESS-G information model, in thissection we extend EXPRESS-G for fuzzy information modeling in entity leveland schema level models, respectively. In an entity level model, we mainlyinvestigate the fuzziness in data types, attributes, entities, and relationships. Ina schema level, we mainly investigate the fuzziness between schemas. Thecorresponding notations are hereby introduced.

Fuzziness in Entity Level Model

An entity level model is an EXPRESS-G model that represents the definitions andrelationships that comprise a single schema. So the components of such a modelconsist of type, entity, relationship symbols, role, and cardinality information.

200 Ma


Imprecise and Uncertain Role Names

As we know, entities consist of attributes and an attribute corresponds to adomain of values with a certain type. In EXPRESS-G, the attributes of an entityare role named. The text string representing the role name is placed on therelationship line connecting an entity symbol to its attribute representation. Foran aggregation attribute, the role name on the relationship line is followed by thefirst letter of the aggregation, such as LIST [m: n], ARRAY [m: n], SET [m: n],or BAG [m: n].

It should be noted, however, that the attribute values of an entity may beimprecise or fuzzy. An entity Engine, for example, has an attribute Size, whichdata type is Real and values may be either fuzzy or imprecise in the preliminaryphase of its design. Such role names that may take imprecise and fuzzy valuesare different than ones that only take crisp values. In the EXPRESS, it is allowedthat attributes take null values by using the keyword “optional” in explicitattribute definition. In order to represent range values and fuzzy values inEXPRESS-G, we give the symbols for range-valued and fuzzy attributes thattake the values of simple data types as shown in Figure 9 and Figure 10,respectively.

Imprecise and Uncertain Type Modeling

Fuzziness can also be found in type modeling. First let’s have a look atenumeration type. As we know, an enumeration type is an ordered list of valuesrepresented by name, where the list has a perfect boundary. A value namedeither belongs to the enumeration type or does not belong to the enumerationtype. It is possible, however, that a value belongs to the enumeration type withdegree, namely, the value is fuzzy. For example, an enumeration type isHairType = ENUMERATION OF (Black, Red, Brown, Golden, Grey) and thehair type of a person is red and brown.

Figure 9. Simple range-valued type symbols

Figure 10. Simple fuzzy type symbols





A defined data type is created based on the underlying type. The defined datatype generally has the same domain of values as the underlying type unless aconstraint is put on it. The underlying type can be simple type, collection type,enumeration type, select type, and named type. We have shown that a value ofsimple type, collect type, or enumeration type may be fuzzy or imprecise. Theimprecision and fuzziness for the values of select type or entity type are shownin the following. Thus, the value of a defined data type may be imprecise or fuzzy.

A select type defines a named collection of other types called a select list. Avalue of a select type is a value of one of the types specified in the select listwhere each item is an entity type or a defined type. The imprecision or fuzzinessof a value of select type comes from the imprecision or fuzziness of itscomponent type, fuzzy or imprecise entity type and defined type.

The symbols for modeling imprecise and fuzzy type are shown in Figure 11 andFigure 12, respectively.

Fuzzy Entity Modeling

Fuzzy entity modeling can be classified into two levels. The first level is thefuzziness in the entity sets, namely, an entity has a degree of membership in the

Figure 11. Ranged-valued type definition symbols

Figure 12. Fuzzy type definition symbols

Enumeration DefType Select

Enumeration DefType Select

Figure 13. Entity with fuzzy instances

Figure 14. Entity with membership degree

E

(E)/E µ

202 Ma


model. For example, an entity Engine may be fuzzy in the product data model.The second level is related to the fuzzy occurrences of entities. For an entityResearch Student, for example, it is not uncertain if John is a Ph.D. student.Such an entity is represented using the definition symbol in Figure 13.

For the first level fuzziness, memberships can be placed inside the solid rectangleas well as the name of the entities. Let E be an entity and µ (E) be its grade ofmembership in the model, then “µ (E)/E” is enclosed in the solid rectangle.If µ (E) = 1.0, “1.0/E” is usually denoted “E” simply. The graphical represen-tation of such entity is shown in Figure 14.

In a classical situation, if there exist two entities E1 and E

2 such that for any entity

instance e, e ∈ E2 implies e ∈ E

1, then E

2 is called a subtype of E

1, and E

1 is called

a supertype of E2. As mentioned above, an instance of entity, say e, may be fuzzy

for an entity, say E. Therefore, there exists a fuzzy supertype/subtype inEXPRESS. Let E and S be two fuzzy entities with membership functions µ

E and

µS, respectively. Then S is a fuzzy subtype of E and E is a fuzzy supertype of

S if and only if the following is true:

(∀e) (e ∈ U ∧ µS (e) ≤ µ

E (e))

Considering a fuzzy supertype E and its fuzzy subtypes S1, S

2, …, S

n with

membership functions µE, µ

S1, µ

S2, ..., and µ

Sn, respectively, the following

relationship is true:

(∀e) (∀S) (e ∈ U ∧ S ∈ {S1, S

2, …, S

n} ∧ µ

S (e) ≤ µ

E (e))

For the fuzzy subtype with multiple fuzzy supertypes, let E be a fuzzy subtype andS

1, S

2, …, S

n be its fuzzy supertypes, which membership functions are respec-

tively µE, µ

S1, µ

S2, ..., and µ

Sn.

(∀e) (∀S) (e ∈ E ∧ S ∈ {S1, S

2, …, S

n} ∧ µ

E (e) > 0 ∧ µ

S (e) ≥ µ

E (e))

The fuzzy supertype/subtype in fuzzy EXPRESS-G can be represented with afuzzy relationship.

Fuzzy Relationship Modeling

As mentioned above, there are dashed lines, thick solid lines, and thin solid linesin EXPRESS-G. Dashed lines and thin solid lines connecting attributes represent



that attributes must belong to the corresponding entity. In fact, it is also possiblethat we do not know if an attribute belongs to the corresponding entity for sure.At this point, such an attribute should be associated with a membership degreeto indicate a fuzzy attribute-entity relationship. We can place membershipdegrees upon dashed lines and thin solid lines. In addition, we use thick dashedsolid lines to represent the fuzzy supertype/subtype above. The symbols for thesethree lines are shown in Figure 15, where A and µ denote the name of an attributeand its membership, respectively.

Fuzziness in Schema Level Model

A schema level model is one that displays the schemas, and the relationshipsbetween these schemas. Since fuzziness can occur in entities, the relationshipsamong these entities may hereby be fuzzy. Following two kinds of schemarelationships Use and Reference in EXPRESS-G, fuzzy Use and Referencerelationships in fuzzy EXPRESS-G are denoted by normal width relation linesand dashed relation lines with membership degrees as shown in Figure 16.

Through the discussion above, three levels of fuzziness can be found in fuzzyEXPRESS-G, namely, the fuzziness at the level of attribute value (the third level),the fuzziness at the level of instance/entity (the second level), and the fuzzinessat the level of entity and attribute (the first level). The fuzziness at the third levelmeans that attributes take fuzzy values. The second level of fuzziness means thateach instance of an entity belongs to the entity with a membership degree. Thefirst level of fuzziness means that attributes comprise an entity with membershipdegrees or entities comprise a schema with membership degrees.

Figure 15. Fuzzy relationship line styles

(A)/A (A)/A

Figure 16. Fuzzy schema definition symbol

Schema name

µ µ

204 Ma


Figure 17. Fuzzy EXPRESS-G data model

Len

gth

R

eal

Bod

y_Id

St

ring

0.5/

Thi

ckne

ss

N

umbe

r C

apac

ity

R

eal

Mat

eria

l T

ype

Vol

ume

Air

tank

Rea

l

Rad

ius

0.7/

Wat

er ta

nk

Lig

ht o

il ta

nk

Tan

k Tan

k_Id

Stri

ng

Rea

l

Rea

l O

ver

heig

ht



An Example Illustration

In Figure 17, we give a simple fuzzy EXPRESS-G data model utilizing somenotations introduced above. Entity Tank is a supertype, which has threesubtypes, namely, Air tank, Water tank, and Light oil tank. Among these threesubtypes, it is known for certain that entities Light oil tank and Air tank are thesubtypes of entity Tank. In other words, the membership degrees that Light oiltank and Air tank are the subtypes of Tank are 1.0, respectively. However, itis not known for certain if entity Water tank must be the subtype of entity Tank.It is only known that the membership degree that Water tank is the subtypes ofTank is 0.7. In addition, entity Light oil tank is a fuzzy entity with fuzzyinstances. The entity Air tank has eight attributes. The attribute Body_Id is aperfect one with string type. Attribute Thickness is an attribute associated witha membership degree 0.5, which means the possibility that entity Air tank hasattribute Thickness is not certainly 1.0 but is only 0.5. The attributes Volume,Capacity, and Over height are ones that can take fuzzy real values. Theattributes Length and Radius are imprecise ones that can take range values. Itshould be noted that attribute Material is one of enumeration type.

Fuzzy Nested Relational Databases

A fuzzy NF2 database schema is a set of attributes (A1, A2, ..., An, pM), wherepM is a special attribute and used to represent the membership degrees of thetuples, and their domains are Dl, D2, ..., Dn, D0, respectively, where Di (1 ≤ i ≤ n)might be one of the following:

1. The set of atomic values. For any an element ai ∈ Di, it is a typical simple

crisp value without imperfectness.

2. The set of atomic values as well as null values, where null values may beunk, inap, nin, and onul.

3. The power set of the set in (1). The corresponding attribute values aremultivalued ones with the form of {a

il, a

i2, ..., a

im}.

4. The power set of the set in (1). The corresponding attribute values areimprecise range-valued ones of the form [a

il, a

i2, ..., a

im] and [a

il-a

i2] for the

discrete and continuous universe of discourse, respectively.

5. The set of fuzzy subset. The corresponding attribute value, say ai, is a fuzzy

value represented by possibility distribution.

206 Ma


6. The set of relation values. The corresponding attribute value, say ai, is a

tuple of the form <ai1, a

i2, ..., a

im> which is an element of D

il × D

i2 × ... ×

Dim

(m > 1 and 1 ≤ i ≤ n), where each Dij (1 ≤ j ≤ m) may be a domain in

(1), (2), (3), (4), or (5) and even the set of relation values.

Domain D0 of attribute pM is a set of atomic values and each value is a crispone from the range [0, 1]. Let t be a tuple in a given NF2 relation. Then theattribute value of t on pM, denoted t [pM], represents the possibility that t belongsto the NF2 relation.

Let us look at the preliminary design of a pressured air tank presented by Ottoand Antonsson (1994). In this design, there are two design parameter values thatneed to be determined: length (l) and radius (r). In addition, there are fourperformance parameters in the design:

• Metal volume m: the preference ranks of m are set because it is proportionalto the cost;

• Tank capacity v: the desired level of this performance ranks the prefer-ence;

• Overall height restriction Lo: it is fuzzy; and

• Overall radius restriction Ro: it is also fuzzy.

Here, we focus on the modeling of these parameter values as well as its structureinformation in product data model using fuzzy NF2 database model. A possibledatabase schema and an instance are partially represented in Table 2 (for spacelimitation). Note that the attribute pM can be omitted from the fuzzy NF2 relationwhen all tuples have value 1.0 on pM. Here, “[25, 600],” “[10, 100],” “[30,650],”and “[15,110]” are imprecise value intervals, and “about 2.5e+03,” “about1.0e+06,” “about 2.5e+04,” “about 1.0e+07,” “less than 627.50,” “less than106.75,” “less than 630.00,” and “less than 112.50” are all fuzzy values. Assumethat these fuzzy values are represented by the possibility distributions as follows:

“about 2.5e+03”:

{1.0/2.5e+03, 0.96/5.0e+03, 0.88/7.5e+03, 0.75/1.0e+04, 0.57/1.25e+04, 0.32/1.5e+04, 0.08/1.75e+04};

“about 1.0e+06”:

{0.05/1.0e+05, 0.18/2.0e+05, 0.37/3.0e+05, 0.55/4.0e+05, 0.69/5.0e+05, 0.78/6.0e+05, 0.87/7.0e+05, 0.93/8.0e+05, 0.96/9.0e+05, 0.97/1.0e+06};



“less than 627.50”:

{1.0/600.0, 1.0/605.0, 1.0/610.0, 1.0/615.0, 1.0/620.0, 1.0/622.5, 1.0/623.0, 0.9/623.5, 0.7624.0/,0.5/625.0,0.3/625.75, 0.1/626.5}

“less than 106.75”:

{1.0/100.0, 1.0/101.25, 1.0/102.5, 1.0/103.0, 0.9/103.25, 0.81/103.75, 0.5/105.0,0.2/106.25, 0.1/106.5}

Mapping Fuzzy EXPRESS-G to FuzzyNested Relational Databases

In this section, we define the formal approaches to mapping EXPRESS-G datamodel with imprecise and uncertain information to fuzzy NF2 database schema.The issue is essentially concerned with the design of logical databases for aproduct data model from a conceptual data model for a product data model.

Nested Relational Databases Support to EXPRESSModel

The entity instances are identified by their unique identifiers in the EXPRESSinformation model. The entity identifiers are just like the keys in (nested)relational databases, but they are different. The keys are the component partsof information content whereas the entity identifiers are not. We can view anentity as a database relation and view the instances of the entity as the tuples ofthe database relation. When we would like to represent entity instances inrelational databases, we have to solve the problem of how to identify entityinstances in relational databases. In other words, we must indicate keys of thetuples originated from entity instances in the relational databases. As we know,in EXPRESS information, there are attributes with UNIQUE constraints. Whenan entity is mapped into a relation and each entity instance is mapped into a tuple,it is clear that such attributes can be viewed as the key of the tuples to identifyinstances. Therefore, an EXPRESS information model must at least contain suchan attribute with UNIQUE constraint when relational databases are used tomodel an EXPRESS information model.

In EXPRESS, there is the entity for which attributes are other entities, calledcomplex entities. Complex entities and subtype/supertype entities in an EX-

208 Ma


PRESS information model can be implemented in relational databases via thereference relationships between relations. It is clear that, based on suchorganization principles, the objects related in structural relationships with oneanother are represented in separate relational databases. In order to obtain someinformation, one may have to query multiple relational databases by using joinoperations. Besides, it is very hard to have a complete and clear picture aboutan information model from the query answers. Relational databases obviouslyare not suitable to support the EXPRESS information model because of therestriction of first normal form (1NF) in traditional relational databases. Nestedrelational databases can solve the problems above very well.

Formal Mapping

Generally speaking, an entity in EXPRESS-G can be mapped into a relationalschema and the role names in the entity mapped into the attributes of therelational schema. But the following problems must be solved when mapping:

(a) How to represent the subtype/supertype relationship in the fuzzy NF2

databases.

(b) How to model the fuzziness of the EXPRESS-G data model in the fuzzy NF2

databases.

(c) Data type transformation.

It has been claimed above that the fuzziness in EXPRESS-G can be classifiedinto three levels. The second level and the third level of fuzziness, namely, thefuzziness at the level of instance/entity and the fuzziness at the level of attributevalue, can be represented in fuzzy NF2 databases. Relational database modelsand nested relational database models only focus on instance modeling and theirmeta-structures are implicitly represented in the schemas. The fuzziness at thelevel of entity and attribute cannot be modeled in fuzzy NF2 databases due to thelimitation of NF2 databases in meta-data modeling.

The following three kinds of entities can be identified in an EXPRESS-G model:

1. Member entities. A member entity is the entity that comprises other entitiesas a component part or that is the underlying types of enumeration andselect types.

2. Subtype entities. A subtype entity is the entity that is in supertype/subtyperelationships and is the subtype entity of the supertype entity/entities.

3. Root entities. A root entity is neither a subtype entity nor a member entity.



For the entities mentioned above, we have different transformation strategies.First, let us look at case (3): root entities. Each root entity is mapped into a fuzzyNF2 relational schema and its role names become the simple attributes orstructured attributes of the relation, depending on their data types.

• A role name with simple data type is mapped to a simple attribute.

• A role name with entity type is mapped to a structured attribute.

• A role name with defined type can be mapped to a simple attribute or astructured attribute, depending on the structure of the defined type.

• A role name with enumeration type is mapped to a simple attribute. Here,assume that NF2 databases support such attribute domains that users definethemselves.

• A role name with select type is mapped to a structured attribute.

It is generally true that the transformations above should be processed recur-sively because an entity type, a defined type, or a select type may contain someof the above components by itself.

It should be noted that the fuzziness of values of simple attributes in EXPRESS-G information models is represented in the attribute values of NF2 databases. Forfuzziness of entity instances, the special attribute “pM” must be included in thestructured attributes or the relational schema to indicate the membership degreeof entity instances.

Second, let us look at case (2): subtype entities. Following similar methods asdescribed above, a subtype entity can be mapped into a fuzzy NF2 schema. Itshould be noted that, however, the key attributes of all the supertypes must bereplicated in the subtype.

Table 2. Air tank relation

Tank_body Tank

_Id Body_Id Material Length Radius Volume Capacity

Overall

height

TA1 BO01 Alloy [25, 600] [10, 100] about

2.5e+03

about

1.0e+06

less than

627.50

TA2 BO02 Steel [30, 650] [15, 110] about

2.5e+04

about

1.0e+07

less than

630.00

210 Ma


A member entity in case (1) is not mapped to a class, but to a complex attributeof another class that is composed of the member entities. But, the fuzziness inthe member entity can be handled according to the same principles as thecommon entity.

Following the formal rules given above, we map the fuzzy EXPRESS-G modelin Figure 17 into the fuzzy nested relational database in Table 2. Note thatattribute “0.5/Thickness” in Figure 17 cannot be mapped into the fuzzy nestedrelational database due to its first level of fuzziness.

It should be noted that we do not discuss the mapping of data types in fuzzyEXPRESS-G models. We assume that fuzzy nested relational databases supportthe data types in fuzzy EXPRESS-G models. In fact, the data types supportedby different database products vary. More and more data types are supportedby some latest release of database management systems. Our focus here is onmapping the entities and the attributes associated with entities in fuzzy EX-PRESS-G models. We have identified all three kinds of entities in fuzzyEXPRESS-G models and given the mapping methods that map fuzzy entities andattributes into fuzzy nested relational databases. So the mapping methods givenin the chapter can be used to solve the problem of fuzzy engineering data modeltransformations.

Conclusions

In this chapter, we have proposed a fuzzy extension to EXPRESS-G that cancapture the imprecise and uncertain engineering information. In addition, fuzzynested relational databases have been introduced. The formal approaches tomapping a fuzzy EXPRESS-G schema to a fuzzy nested relational databaseschema have been developed in this chapter.

It should be noted that EXPRESS-G is only a subset of the full language ofEXPRESS. Clearly, it is necessary to extend EXPRESS for imprecise anduncertain engineering information modeling and then map fuzzy EXPRESSmodels into databases. In addition, it is also very interesting to formally comparetransformation modeling among EXPRESS-G and other conceptual data models,such as ER/EER, UML, and IDEF1X. We will investigate these issues in ourfuture work.



References

Antonsoon, E. K. & Otto, K. N. (1995). Imprecision in Engineering Design.ASME Journal of Mechanical Design, 117(B), 25-32.

Bordogna, G., Pasi, G. & Lucarella, D. (1999). A Fuzzy Object-Oriented DataModel for Managing Vague and Uncertain Information. InternationalJournal of Intelligent Systems, 14, 623-651.

Bosc, P. & Prade, H. (1993). An Introduction to Fuzzy Set and Possibility TheoryBased Approaches to the Treatment of Uncertainty and Imprecision inDatabase Management systems. Proceedings of the Second Workshopon Uncertainty Management in Information Systems: From Needs toSolutions.

Buckles, B. P. & Petry, F. E. (1982). A Fuzzy Representation of Data forRelational Database. Fuzzy Sets and Systems, 7(3), 213-226.

Caputo, M. (1996). Uncertainty, Flexibility and Buffers in the Management ofthe Firm Operating System. Production Planning & Control, 7(5), 518-528.

Chaudhry, N., Moyne, J. & Rundensteiner, E. A. (1999). An Extended DatabaseDesign Methodology for Uncertain Data Management. Information Sci-ences, 121(1-2), 83-112.

Chen, G. Q. & Kerre, E. E. (1998). Extending ER/EER Concepts towards FuzzyConceptual Data Modeling. Proceedings of the 1998 IEEE InternationalConference on Fuzzy Systems, 2, 1320-1325.

Chen, P. P. (1976). The Entity-Relationship Model: Toward a Unified View ofData. ACM Transactions on Database Systems, 1(1), 9-36.

Codd, E. F. (1987). More Commentary on Missing Information in RelationalDatabases (Applicable and Inapplicable Information). ACM SIGMODRecord, 16(1), 42-50.

Colby, L. S. (1990). A Recursive Algebra for Nested Relations. InformationSystems, 15(5), 567-662.

Dubois, D. & Prade, H. (1986). Possibility Theory: An Approach to Comput-erized Processing. New York: Plenum Press.

Eastman, C. M. & Fereshetian, N. (1994). Information Models for Use inProduct Design: A Comparison. Computer-Aide Design, 26(7), 551-572.

Erens, F., Mckay, A. & Bloor, S. (1994). Product Modeling Using MultipleLevels of Abstraction Instance as Types. Computers in Industry, 24, 17-28.

212 Ma


Francois, F. & Bigeon, J. (1995). Integration of Fuzzy Techniques in a CAD/CAN System. IEEE Transactions on Magnetics, 31(3), 1996-1999.

George, R., Srikanth, R., Petry, F. E. & Buckles, B. P. (1996). UncertaintyManagement Issues in the Object-Oriented Data Model. IEEE Transac-tions on Fuzzy Systems, 4(2), 179-192.

Gottlob, G. & Zicari, R. (1988). Closed World Databases Opened through NullValues. Proceedings of the 1988 International Conference on VeryLarge Data Bases, 50-61.

Grabot, B. & Geneste, L. (1998). Management of Imprecision and Uncertaintyfor Production Activity Control. Journal of Intelligent Manufacturing, 9,431-446.

Guiffrida, A. & Nagi, R. (1998). Fuzzy Set Theory Applications in ProductionManagement Research: A Literature Survey. Journal of IntelligentManufacturing, 9, 39-56.

Gyseghem, N. V. & Caluwe, R. D. (1998). Imprecision and Uncertainty in UFODatabase Model. Journal of the American Society for InformationScience, 49(3), 236-252.

ISO IS 10303-1 TCI84/SC4. (1994a). Product Data Representation and Ex-change-Part 1: Overview and Fundamental Principles. International Standard.

ISO IS 10303-1 TCI84/SC4. (1994b). Product Data Representation and Ex-change-Part 11: The EXPRESS Language Reference Manual. Interna-tional Standard.

Karwowski, W. & Evans, G. W. (1986). Fuzzy Concepts in Production Manage-ment Research: A Review. International Journal of Production Re-search, 24(1), 129-147.

Kim, K., Cormier, D., Young, R. E. & O’Grady, P. (1995). A System for Designand Concurrent Engineering under Imprecision. Journal of IntelligentManufacturing, 6(1), 11-27.

Klir, G. J. & Folger, T. A. (1988). Fuzzy Sets, Uncertainty, and Information.Englewood Cliffs, NJ: Prentice Hall.

Li, Q., Ma, Z. M. & Zhang, W. J. (1998). Modeling of Incomplete and UncertainInformation in Relational Database for Engineering Design and ProductionManagement: Review and Future Work. Proceedings of the 1998 ASMEDesign Engineering Technical Conference.

Li, Q., Zhang, W. J. & Tso, S. K. (2000). Generalization of Strategies for ProductData Modeling with Special Reference to Instance-As-Type Problem.Computers in Industry, 41, 25-34.



Ma, Z. M., Zhang, W. J. & Li, Q. (1999). Extending Relational Data Model toResolve the Conflicts in Schema Integration of Multiple Databases inVirtual Enterprise. Proceedings of the 1999 ASME Design EngineeringTechnical Conference.

Ma, Z. M., Zhang, W. J. & Ma, W. Y. (1999). Incomplete Information in ProductConcept Design and Its Modeling in Relational Databases. Proceedings ofthe 1999 Lancaster International Workshop on Engineering Design,99-114.

Ma, Z. M., Zhang, W. J., Ma, W. Y. & Chen, G. Q. (2000). ExtendingEXPRESS-G to Model Fuzzy Information in Product Data Model. The2000 ASME Design Engineering Technical Conference.

Makinouchi, A. (1977). A Consideration on Normal Form of Not-NecessarilyNormalized Relations in the Relational Data Model. Proceedings of ThirdInternational Conference on Very Large Databases, 447-453.

McKay, A. (1988). The Structure Editor Approach to Product Description.Technical Report, University of Leeds, ISS-PDS-Report-4.

Motor, A. (1990). Accommodation Imprecision in Database Systems: Issuesand Solutions. ACM SIGMOD Record, 19(4), 69-74.

Motor, A. & Smets, P. (1997). Uncertainty Management in Information Sys-tems: From Needs to Solutions. Kluwer Academic Publishers.

Otto, K. N. & Antonsoon, E. K. (1994). Modeling Imprecision in ProductDesign. Proceedings of Fuzzy-IEEE 1994, 346-351.

Otto, K. N. & Antonsoon, E. K. (1994). Design Parameter Selection in thePresence of Noise. Research in Engineering Design, 6(4), 234-246.

Ozsoyoglu, G., Ozsoyoglu, Z. M. & Matos, V. (1987). Extending RelationalAlgebra and Relational Calculus with Set-Valued Attributes and AggregateFunctions. ACM Transactions on Database Systems, 12(4), 566-592.

Parsons, S. (1996). Current Approaches to Handling Imperfect Information inData and Knowledge Bases. IEEE Transactions on Knowledge DataEngineering, 8, 353-372.

Petrovic, D., Roy, R. & Petrovic, R. (1998). Modeling and Simulation of a SupplyChain in an Uncertain Environment. European Journal of OperationalResearch, 109, 299-309.

Petrovic, D., Roy, R. & Petrovic, R. (1999). Supply Chain Modeling Using FuzzySets. International Journal of Production Economics, 59, 443-453.

214 Ma


Prade, H. & Testemale, C. (1984). Generalizing Database Relational Algebrafor the Treatment of Incomplete or Uncertain Information. InformationSciences, 34, 115-143.

Roth, M. A., Korth, H. F. & Batory, D. S. (1987). SQL/NF: A Query Languagefor Non-1NF Relational Databases. Information Systems, 12, 99-114.

Schek, H. J. & Scholl, M. H. (1986). The Relational Model with Relational-Valued Attributes. Information Systems, 11(2), 137-147.

Schenck, D. A. & Wilson, P. R. (1994). Information Modeling: the EXPRESSWay. Oxford University Press.

Shaw, N. K., Bloor, M. S. & Pennington A. de, J. (1989). Product Data Models.Research in Engineering Design, 1, 43-50.

Teorey, T. J., Yang, D. Q. & Fry, J. P. (1986). A Logical Design Methodologyfor Relational Databases Using the Extended Entity-Relationship Model.ACM Computing Surveys, 18(2), 197-222.

Tsourveloudis, N. G. & Phillis, Y. A. (1998). Manufacturing Flexibility Measure-ment: A Fuzzy Logic Framework. IEEE Transactions on Robotics andAutomation, 14(4), 513-524.

Venkatramen, S. S. & Sen, A. (1993). Formalization of An IS-A BasedExtended Nested Relation Data Model. Information Systems, 20(1), 53-57.

Vila, M. A., Cubero, J. C., Medina, J. M. & Pons, O. (1996). A ConceptualApproach for Deal with Imprecision and Uncertainty in Object-Based DataModels. International Journal of Intelligent Systems, 11, 791-806.

Wood, K. L. & Antonsoon, E. K. (1992). Modeling Imprecision and Uncertaintyin Preliminary Engineering Design. Mechanism and Machine Theory,25(3), 305-324.

Yager, R. R. (2000). Targeted e-Commerce Marketing Using Fuzzy IntelligentAgents. IEEE Intelligent Systems, 15(6), 42-45.

Yager, R. R. & Pasi, G. (2001). Product Category Description for Web-Shopping in E-Commerce. International Journal of Intelligent Systems,16, 1009–1021.

Yazici, A., Soysa1, A., Buckles, B. P. & Petry, F. E. (1999). Uncertainty in aNested Relational Database Model. Data & Knowledge Engineering,30, 275-301.

Zadeh, L. A. (1965). Fuzzy Sets. Information and Control, 8(3), 338-353.

Zadeh, L. A. (1978). Fuzzy Sets as a Basis for a Theory of Possibility. FuzzySets and Systems, 1(1), 3-28.



Zaniola, C. (1986). Database Relations with Null Values. Journal of ComputerSystem Science, 28(2), 142-166.

Zhang, W. J. & Li, Q. (1999). Information Modeling for Made-to-order VirtualEnterprise Manufacturing Systems. Computer-Aided Design, 31, 611-619.

Zimmermann, H. J. (1999). Practical Applications of Fuzzy Technologies,Kluwer Academic Publishers.

Zvieli, A. & Chen, P. P. (1986). Entity-Relationship Modeling and FuzzyDatabases. Proceedings of the 1986 IEEE International Conference onData Engineering, 320-327.

216 Ma


Section III

Additional Topics

Analysing Transformations in Performance Management 217


Chapter X

AnalysingTransformations in

PerformanceManagement

Bernd Wondergem, LogicaCMG Consulting, The Netherlands

Norbert Vincent, LogicaCMG Consulting, The Netherlands

Abstract

Performance Management (PM) is a way of managing in which theorganisation’s goals and organisation model are made explicit. In thischapter, several forms of PM are investigated to meet these observations.The goals and organisation model together form the management model ofthe organisation. Steering the organisation towards its strategic goals thencomes down to repeatedly transforming this management model. In thischapter, these transformations are systematically analysed. In order to dothis, we first provide a framework in which several types of transformationcan be identified. Second, properties of the transformations are stated andrelated to different styles of management. In addition, we sketch futuretrends in a resource-based view on performance management.

218 Wondergem and Vincent


Introduction

Performance management (PM) is a way of managing in which the organisation’sstrategic goals and its organisation model are made explicit. In addition, theconnection between those two issues is made by stating how the organisationmodel produces the organisations output. The explicitly stated goals (the what)and organisation model (the how) form the core of the management model forsteering the organisation.

In PM, running a business is all about transformations. First, of course, a generalnotion of transformation applies: the organisation transforms some form of inputto some form of output. More specific to PM, steering the organisation towardsits strategic goals is done by repeatedly transforming the organisation and themanagement model. In this chapter, we focus on these latter forms of transfor-mation which describe the essence of performance management.

This chapter sets out to do two things. First, we describe a framework foranalysing transformations in performance management. Second, we use theframework to identify several types of transformations and describe whichproperties apply to them. The results of this chapter may enhance the under-standing of performance management and thus lead to more effective manage-ment.

This chapter has the following structure: it provides different views of, andapproaches to, PM and presents our vision on the subject. Next, the frameworkfor analysing transformations is presented: the performance management model.In the following section, we use this model for describing several types oftransformations. The chapter then deals with future trends. Finally, we provideconcluding remarks and an outlook on further research.

Background

In general, organisations try to find, reach and sustain a strategic position in theirenvironment. Mintzberg (1991) has classified the ways to do this into twocategories: emergent strategies and planned strategies. “Organisations developplans for the future and they evolve patterns out of their past” (Mintzberg, 1994).Performance management falls into the category of planned strategies.

Performance Management has a typical set-up. First, the organisation formu-lates a strategy. Formulating a mission, creating a vision and formulating goalsare often seen as preceding steps in strategy-formulation. However, these stepsare not always explicitly taken or repeated in formulating or revising the strategy.



Second, the strategy and the corresponding goals are translated into perfor-mance indicators (PI). PI’s form measurable indicators which give a quantitativeview on the organisation’s performance. The PI’s are often put on a scorecard,an instrument used for communicating and analysing the performance.

The scorecard is used for steering towards the strategic goals. Therefore, it isused in a cycle for continuous improvement. Deming’s cycle (Deming, 1982),consisting of the steps “plan,” “do,” “check” and “act,” probably is the most well-known variant. In this cycle, strategy formulation forms a part of the “plan” step.In addition, this step concerns setting up the organisation for the production ofvalue. Figure 1 sketches the place of the Deming’s cycle in the general set-upof performance management. In the “do” step, the organisation produces itsproducts or services and measures its performance through PI’s. This providesa fact-based insight into the current performance. The results are evaluated andactions to improve the future performance are defined in the “‘check” step.Finally, the “act” step consists of implementing the actions. After this, thestrategy may be revised and a new cycle starts. The information that is explicitlyused in the “check” and “act” steps constitutes the so-called performancemanagement model. This is elaborated upon later in this chapter.

In this chapter, we will consider three aspects of PM as its essence. We definePerformance Management as the management method and instrument that:

1. Translates the organisation’s strategy in measurable indicators. The “what”of the strategy is thus explicitly translated into quantitative performanceindicators.

Figure 1. General set-up of performance management



2. Links the strategic goals of the organisation to the operational organisation.In other words: how the strategy is to be realised is explicitly incorporatedin the management model.

3. Incorporates a mechanism for the continuous improvement of perfor-mance. For this aspect, we use Deming’s cycle as a point of reference.

Different approaches to PM can be distinguished. Without trying to offer acomplete overview, we provide a description of some approaches below.

The Balanced Scorecard (BSC) is both an instrument and management modelthat aims at providing a balanced view on the organisation’s performance(Kaplan & Norton, 1992, 2000). It was developed as a reaction to primarilyfinancial steering. Nowadays, it is a popular instrument in many businesses. TheBSC looks at the business from four perspectives: financial, customer, internaland innovation & learning. In practice, however, this set-up is sometimes alteredby changing the number and contents of the perspectives. In that way, the BSCis custom-made for the specific needs of organisations. The BSC is put to workby searching for key success factors (KSF) within the four perspectives. TheKSF’s are derived from the organisation’s strategy, thereby making its causaldependencies explicit. For each KSF, measurable indicators are formulated,resulting in a set of key performance indicators (KPI). The Balanced Scorecard,as an instrument, forms the tool for steering the organisation with these KPI’s.Often, the Deming cycle is used for working towards continuous improvements.Many software tools that implement the (Balanced) scorecard explicitly supportthe Deming cycle, for instance by providing functionality for data-analysis(check) and action management (act).

Value-based management (VBM) (an overview of this field is given in Scheiperset al., 2002) is an approach for performance management stemming from theareas of financial management and management accounting. VBM is a manage-ment control system that measures, encourages and supports maximizingshareholder value. It is based on the conviction that the interests of allstakeholder groups are best served by putting the shareholder first. The term“value” is more complete than earning-measures only, since it also takes thenotion of risk, the impact of inflation and opportunity costs into account. VBMrequires complete information to calculate “value” properly. In addition, a long-term strategic point of view is required to describe the expected outcomes. VBMis advocated to be used at the corporate and strategic business-unit level.Exploiting VBM requires substantial training, especially for non-experts infinance. In holistic approaches for VBM, continuous improvement of (financial)performance is mentioned. However, the link with operational processes ap-pears to be only indirect.



Six Sigma is an approach that aims at reducing variety in business processes(Harry, 1998). This can be done for processes that produce goods (products) aswell as for processes that deliver services. Six Sigma is a form of “managementby fact”: it uses statistical information and techniques to measure and analysebusiness performance. Six Sigma also exploits two variants of cycles forcontinuous improvements. First, the so-called DMAIC process, for Define,Measure, Analyse, Improve and Control, is an improvement system for existingprocesses. Second, the DMADV process, having Design and Verify as finalsteps, is a system for designing new processes.

Designing new processes can be done based on Quality Function Deployment(QFD) (Mazur, 1993). QFD can be seen as a method for high-quality design,which starts with solicitation of customer requirements. QFD distinguishes threetypes of requirements: (1) revealed requirements (what customers say theywant), (2) expected requirements (what customers demand as standard quality)and (3) exciting requirements (beyond the customer’s expectations). Theserequirements are analysed, prioritised and finally translated to design specifica-tions. This results in a set of measurable product specifications. QFD is anexplication of the “plan” phase of the Deming-cycle. The remaining three phasesof the Deming cycle are not explicitly covered by QFD. QFD thus provides astructured approach for the design of a quality product and service portfolio andthe processes that deliver them.

In addition to the mentioned approaches, several other methods can be distin-guished. A more elaborate overview of approaches to performance managementis given in Wondergem (2003). Also, other fields provide approaches to qualityand performance management that can be identified. As an example, we mentionthe approach to software quality, as described in Locuratolo (2002).

These approaches to PM all formulate performance indicators for measuringperformance and communicating strategic goals. How this is done differs fordifferent approaches. In general, though, all approaches use an intermediate stepbetween the goals (and strategy) on the one hand and the PI’s on the other hand.This step in between is formed by what we call “measured items” (MI). Themeasured items indicate which strategic subjects are important enough to bemeasured by PI’s. In the BSC, for instance, the MI’s are formed by the KSF’s.For Six Sigma, the MI’s are the measured characteristics of the processes andproducts, such as variability and quality.

In the next section, a model for PM is described. This model is used in latersections to describe and analyse different transformations in PM.



Performance Management Model

A Performance Management model (PMM) contains the information that isused for steering transformations in performance management (see also Figure1). The PMM fits in our notion of performance management by making the goalsand the organisation explicit. The cycle for continuous improvement is notincorporated in the model, since it does not constitute information for steering,but the process itself. Therefore, the cycle is described separately as a series oftransformations. The PMM is input for these transformations and, with alteredform and contents, forms its output as well.

PM explicitly models the desired performance in a goal model (GM) and thefactors that drive and produce output in an organisation model (OM). The GMand OM are parts of the performance management model (PMM). The PMMis completed by a connection between the GM and OM. This connectionindicates how the OM produces or influences the GM. In that sense, theconnection forms the handles (H) used to steer performance.

A performance management model is thus defined as a tuple (GM, OM, H).Details of GM, OM and H are provided in the remainder of this section.

Goal Model

The goal model explicitly states the desired results. It forms a strategic map,consisting of measured items, causal relations between them, and performanceindicators. The causal relations between the measured items describe dependen-cies between the strategic goals and subgoals. The PI’s operationalise themeasured items: they make the measurement of the performance considering themeasured items explicit.

Example: Customer Satisfaction: Contact centres are organisations for whichcustomer satisfaction is of major importance. The management of thefictive unit “The Contact Centre” (TCC) of a company that sells productsunderstands this. Therefore, they explicitly manage their organisation oncustomer satisfaction. To do this, they constructed the goal model asdepicted in Figure 2. The measured item “Customer Satisfaction” is brokendown into its constituents. Three other measured items appeared toinfluence customer satisfaction: satisfaction of the products, the quality ofthe contact with the customer and the image of the company.

The contact center is directly responsible for the quality of contact only.The other two aspects refer to the company as a whole. The quality of



contact is influenced by three other measured items: the quality of theprocesses of customer contact, the satisfaction of the front-office person-nel and the availability of the different channels for customer contact.Together, the measured items and causal relations (the arrows in Figure 2)form the strategic map of the company for steering towards customersatisfaction.

In Table 1, example performance indicators for some of the MI’s in the goalmodel are provided. The third column of the table provides examplenumerical values for the PI’s.

The goal model is defined as a tuple GM = (MI, CR, PI, O), where:

• MI is a set of measured items,

• CR is a relation on MI, the causal relations of GM,

Figure 2. Example goal model for customer satisfaction

Table 1. Example indicators

Measured item Performance indicator Example

values

Satisfaction of product % of customers rating the produt flexibility eight or higer

Number of complaints about the product per month

75%

35.6

Quality of process Helpfulness of the call center agents as grade

% of complaining customers that accepts offer

7.4

65%

Channel availability Waiting time in seconds before call is answered

Availability (uptime %) of the voice response system

13.1 sec

97%



• PI is a set of performance indicators, and

• O is a relation on MI x PI, the operationalisation of the measured items.

A number of properties of the goal model that are used in PM are describedbelow. The impact value of a causal relation (mi1 � mi2) denotes the part ofmi2 that is explained by mi1. The completeness of an MI, say mi1, is the sum ofall impact values of the causal relations (mi2 � mi1). The score of a PIexpresses the current performance with respect to the PI. The score of ameasured item is then given as the average of the scores of all PI’s thatoperationalise it. In order to compute the average of the PI’s, they first have tobe made comparable (Chang & Morgan, 2000).

Organisation Model

The organisation model provides the factors that drive and produce theorganisation’s output. Numerous ways of modeling organisations exist. For ourpurposes, it suffices to see the organisation model as a directed graph: OM = (N, L),where N is a set of organisational elements and L a set of links. The links modeldependencies on the organisational elements.

Example: Contact centre: The management of the contact centre of theprevious example has also constructed an organisation model. It has doneso based on the COPC model, which is a performance management modelfor contact centres (COPC, 2002). The organisation model distinguishesgoals, enablers and drivers (Figure 4). In short: the goals are produced bythe enablers, which, in turn, are directed by the drivers. The goals of thecontact centre consist of quality of contact (see the previous example) andcosts. The enablers describe how the contact centre is organised: whichprocesses are performed and how are employees and resources used inthat? The drivers of the contact centre describe the “way of organising”and contains aspects such as strategy, leadership and planning.

For PM, it is important that the OM is complete, i.e., that no relevant organisationalelements and links are missed. This would diminish the steering capabilities of theOM. Furthermore, it is important that the OM provides enough detail, enablingfocused steering.



Handles

Handles connect the goals (measured items) to elements from the organisationmodel. The handles can thus be formally described as a relation on GM.MI xOM.N. However, the handles are often not stated explicitly. Rather, they residein the heads of managers. In that sense, the handles are subjectively described:each manager may have his own opinion about which factors influence results.This is in line with the “idiosyncratic set of knowledge” managers are stated toform in Van den Bosch and Van Wijk (2001).

The scope of the handles is defined as the portion of all connections betweenorganisation model and goal model that are included in the handles. The scopedelimits the possible effectiveness of the management model. A large scope mayconsider many possibilities to influence a certain goal but may also be time-consuming in decision making. A small scope may quickly lead to a decision abouthow to steer, but may miss relevant options.

Transformations in PerformanceManagement

Performance management can be seen as a cyclic process of transformations.Based on evidence of the current performance, the goal model indicates which(sub)goals need to be improved. The organisation model states how this can bedone. Analysing the evidence in the light of the PMM thus leads to a series ofactions that can be taken to improve performance. The actions are implementedand the results are measured again. This starts a new cycle in the managementprocess.

Figure 3. Example organisation model for contact centers



This cyclic management process can be described as a series of transformations.Each transformation uses evidence of the current performance (E) and thecurrent status of the PMM as input. In Figure 4, this is schematically denoted asa model-theoretic statement. Implementing the actions leads to an altered PMM,denoted by PMM’.

Which actions are actually taken, depends on the view management has of theorganisation, its environment and their patterns of action-reaction. Together,these issues form the business model. In this sense, the business model (BM)forms the context in which the transformations take place. In Yilmaz andChatterjee (1999), the BM is called the “theory of knowledge”.

The remainder of this section focuses on actions that directly change the PMM:the transformations of the PMM. In general, three basic types of transformationof the PMM can be distinguished: transformation of the goal model, theorganisation model and the handles. These transformations are elaborated in thefollowing subsections. After that, the section, Future Trends in Transforma-tions in the Organisation, focuses on future trends for transformations in theorganisation itself.

Transformations of Goal Model

Transforming the goal model can be identified at two levels. First, measureditems and causal relations may be altered. Second, performance indicators andtheir connection to measured items can be changed.

On the level of MI’s and causal relations, the notion of completeness is important.If the GM is not complete enough, MI’s may be added. The precondition of sucha transformation can be stated as: the completeness of mi1 is too low, where mi1is a measured item out of the goal model. The action in the transformationconsists of adding a measured item mi2 and the causal relation (mi2 � mi1). Thepost-condition of the transformation then states that the completeness of mi1 ishigher. The proof of this claim hinges on the assumption that the impact value ofmi2 on mi1 is non-zero and positive.

Example: Adding measured items: Consider the goal model of the first example(Figure 2). Suppose that the MI “Satisfaction of product” is not completeenough. Therefore, this MI is augmented with the following underlying

Figure 4. Transformations in PMM



MI’s: “Satisfaction of product quality,” “Satisfaction of product price” and“Satisfaction of product flexibility.”

Changing MI’s and causal relations can also be required by a change of strategy.In contrast to the previous transformation, which is internally oriented throughthe notion of completeness, a change of strategy is an external factor to the goalmodel. Since organisations reside in dynamic environments, strategies need to befrequently adjusted and sometimes rigorously changed. As said before, the goalmodel forms a strategic map. Therefore, the goal model should properly reflectthe strategic goals and relations between them. Coherence between strategy andgoal model is, however, a subjective issue. This means that transformations thataim at adjusting the goal model to the strategy heavily rely on the business modelof the individual manager.

Changes in PI’s may stem from several reasons, as is shown in Wondergem andWulferink (2002). The corresponding transformations of the goal model there-fore aim at different improvements. A first reason to alter PI’s is the availabilityof source data. With these data, the contents of the PI’s are filled. PI’s forwhich the source data is not sufficiently (easily) available, may be deleted orreplaced by more suitable variants. Second, PI’s need to be recognisable, whichmeans that management needs to either be familiar or become familiar with thePI’s. If PI’s are not recognisable, this hinders effective steering. Insufficientlyrecognisable PI’s are therefore replaced by PI’s that better suit the manager’sexperience. As a third reason to change PI’s, we mention dysfunctionalbehaviour (Birnberg et al., 1983). PI’s measure specific aspects of theorganisation’s performance, leaving room for “gaming”: giving insufficientattention to other important issues. These issues can in turn be covered by PI’sas well, resulting in a balanced set of PI’s. In addition, the measurement of PI’sshould leave little room for “smoothing” the results. PI’s which are automaticallydelivered from a data warehouse may serve this purpose, since their computationfrom source data is strictly specified. Fourth, PI’s need to be consistent indefinitions, providing the possibility to compare PI’s. This is for instance requiredfor benchmarking. Finally, PI’s, or rather, the way in which performance ismeasured, should fit within the culture of the organisation. Measuring perfor-mance on individual levels, for instance, requires a culture that supports this.Otherwise, it may be seen as an intrusion on individual rights and as such mayharm effective steering.

Transformations of Organisation Model

The organisation model reflects the explicitly stated scope managers have forfinding actions for improvement. Transformations of the organisation model may



aim at providing a more complete (broad) model or at detailing certain compo-nents of the model.

If the OM, for instance, appears to be not complete enough, new organisationelements may be added. Adding an organisation element and linking it to theexisting OM, provides managers with a broader scope for steering the organisation.In certain quality models, such as the Dutch INK model (INK, 2001), severalidentified phases describe this growing complexity. Starting, for instance, withisolated actions, a proceeding phase considers series of actions and theirinterdependencies, i.e., processes. The final phase may describe a holistic viewon the organisation and its place within its environment.

Next to the completeness of the OM, its level of detail is also of importance. Inpractice, a first measurement of performance using a rather coarse grainedmodel pinpoints the organisation processes which require improvement. Onlythese processes are then described in more detail, thus focusing the energy forimprovement. Providing more detail for existing organisation elements may bedone by decomposing the element. A process, for instance, can be decomposedinto several sub-processes. This enlarges the insight in the problem areas andenables more specific decisions on improvement issues.

Example: Detailing the organisation model: Consider the example organisationmodel of The Contact Center as depicted in Figure 3. Suppose that theprocesses do not deliver the expected quality. In order to be able to select(only) under performing processes, this organisational element is brokendown into the following sub-elements: customer contact, instruction, train-ing, supervision, reporting and planning. Furthermore, customer contactprocesses may be divided into pre-sales, sales, after-sales and service.

Both types of transformation of the OM make it more complex. This coincideswith the growing professionalism with which performance management isexecuted: over time, management learns to stepwise increase its focus. Simpli-fying the OM by deleting elements may also take place. The need for this may,for instance, stem from a simplification in the actual organisation or from achange of focus in management instruments.

Transformations of Handles

Handles form the connection between the organisation model and the goalmodel. As such, they constitute the possibilities in the OM that a managerexplicitly considers for reaching a certain goal in the GM. In general, managers



start with a certain view on the handles. By experience, they learn that certainhandles do or do not work. This enhances or concentrates the set of options theyconsider in steering. In that way, the set of handles is personally defined andalters over time. In this respect, the professionalisation of management aims atproviding managers with the right set of handles.

Future Trends in Transformations in theOrganisation

In this chapter, we discuss future and emerging trends in performance manage-ment by focusing on organisational transformations. To this end, we vieworganisations as a set of activities, coordination-mechanisms and responsibilities,in line with the set-up of Mintzberg (1983). In this set-up, we distinguish threecategories of transformation, which will be elaborated on in the followingsubsections:

1. Transformation of the responsibilities: from effort-driven towards re-sult-driven management.

2. Transformation of coordination: from yearly to dynamic resourceallocation.

3. Transformation in activities: from competitive advantage to sustainedcompetitive advantage.

Toward Result-Driven Business Management

Performance Management can be used to transform the control style and thebudgeting process of the organisation. In addition, it makes the current way ofworking more explicit and thus transparent. This leads organisations toward aresult-driven style of management.

The control style and organisation’s budgeting process can have an impact on theway an organisation will set up its performance management model. Differentcontrol styles can be identified. Goold and Cambell, (as described in Strikwerda,2000), have defined three control styles: strategic planning, strategic control andfinancial control. An organisation should select a dominant style to make clearwhat the organisation expects from the PMM (De Waal, 2001). In addition, thissignals the dominant type of performance indicators which will be used. Financialcontrol will use primarily financial indicators, while strategic planning requiresinformation from non-financial sources as well.



The nature of the budgeting process influences the construction of the PMM. Inresult-based budgets, as opposed to cost-based budgets, the relationship be-tween performance and patterns of action-reaction is more complex. Thisrequires detailed insight into the causal relationship between the MI’s and thelinks with handles. The use of a balanced scorecard will thus coincide with theconstruction of more professional models of performance management.

Example: Results and indicators: The contact center from example two isdirectly responsible for the quality of contact only. The contact center hastwo goals: (1) quality of contact, and (2) costs. In the case of financialcontrol, the contact center mainly will be reviewed on the total costs.

In the strategic planning style not only the costs, but also the qualitybecomes more important. Then Table 1 gives a reflection of relevantperformance indicators. Organizations that change their control style fromfinancial to strategic or vice versa thus also transform their performancemanagement model.

Toward Dynamic Resource Allocation

The Deming circle, as stated before, is widely used to manage the process ofcontinuous performance improvement. The Deming circle is executed at strate-gic, tactical and operational levels. The integration between the managementlevels (vertical integration) and between the departments on the same level(horizontal integration) should ensure that the actions are coordinated and alldirected toward the strategic goals. The Deming circle can be seen as theoperationalisation of management control. Management control consists ofseveral control subsystems each with their own view on strategy (Simons, 1995).We mention two types: (1) the diagnostic control subsystem, where strategy isseen as a plan and performance indicators are used as control object and (2)interactive control, where strategy is viewed as a pattern of actions. In ourconsulting practice, we see that performance management often solely focuses

Examples of financial

control

Performance indicator Measured item

Costs per complaint Total costs divided by the total number of complaints Cost to service a product

Costs of personnel Total costs of all personal in the contact centers Personal costs to process the

complaints

Non-personal costs of the

channel

Costs of tools used in the contact centers The additional costs to process

the complaint



on the diagnostic control system (Wondergem & Eskens, 2003). The diagnosticcontrol system, however, is a single-loop learning process, while successfulimplementation of performance management requires at least a double-loop-learning process (Kaplan & Norton, 1992). In single-loop learning, the actionsare directed towards realising the target of the PI’s. Double-loop learningenables organisations to analyse and revise the assumptions underlying the PMMand uses the evidence to define new norms. With double-loop learning, theorganisation can plan the strategy and the necessary actions to realise thebusiness strategy. In that, the organisation uses the PMM to operationalise thebusiness strategy and can evaluate the strategic map and the causal relation-ships. Double-loop learning can make the connection between the diagnostic andinteractive control system. Finally, deutero learning can be distinguished (Argyris,1982). Deutero learning is about the speed and quality of the learning process andthus influences the flexibility and adaptability of the organisation. Considering theincreased dynamic nature of the business environment, we envision that deuterolearning will become a strategic necessity for many organisations.

In general, the business environment transforms from a make-and-sell environ-ment (industry era) into a sense-and-respond environment (information era).Changes in the environment make strategies obsolete. Therefore, the speed ofevaluating the chosen strategy increases and the speed and frequency ofwalking, through the Deming circle should keep the same pace. As an effect, thestrategic planning horizon shortens and budgets become obsolete sooner. As aconsequence, information should be available in real time and actions arefocused on short-term results. To make sure that the organisation develops theright product features and is able to adapt to the changes in a flexible manner,the performance results must be reviewed more frequently. We envision that,instead of making a yearly budget, organisations make quarterly rolling forecastsand align their resource allocation with the strategic requirements. This is in linewith the vision of the Working Council for CFO’s (WCC, 2001).

Example: The responsibility of the Contact Center for only the quality of thecontact is based on the assumption that the product (make and sell) and theservice of the product (sense and respond) can be separated and that theContact Center is only a service entrance and not a sales point. Nowadays,however, customers do not separate sales and service; customers callinga contact center also want information about products or even want to buyproducts (cross-selling). Fulfilling customer needs with additional productfeatures (extra games for a Nintendo) has a high impact on the satisfactionof the product.

When the satisfaction of the product is declining and the customer ContactCenter meets all of their goals (quality of contact, quality of process,



employee satisfaction, channel availability), it is not the current planningthat should be revised, but the assumptions that lie beneath it. Changingthese assumptions will transform the performance management model.

Toward Sustained Competitive Advantage

In the end, Performance Management should help an organisation to createsuperior performance and sustained competitive advantage. When taking aninside perspective on strategy, the actions should be focused on the enablers:processes, employees and resources. In this light, we mention several researchquestions that deserve renewed or ongoing attention. First, we mention the issueof process optimisation. A second question amounts to how the productivity ofthe employees can be increased. A third question centers around how to exploitsynergies out of the resources, both tangible and intangible. Given the complexityof the causal relations between MI’s and the organisation model, a resource-based view on performance management may well become more relevant. Wethus propose more attention be given towards an “enabler-oriented” vision onperformance management.

Conclusions

We have described a framework for analysing transformations in performancemanagement, including the performance management model. Using this frame-work, several types of transformation were described. The framework describeswhich elements of the organisation and its management model can be trans-formed by performance management, as well as the factors that play a role inthe transformations. In addition, an initial description of the properties of thetransformations was given and future consequences for the organisationwere sketched.

This chapter has focused strongly on the information that is used in transforma-tions in performance management, as formulated in the goal model and theorganisation model. As an additional aspect, the section about future directionssketched possible paths of evolution for organisations that use performancemanagement. Actually using the information in PM was only briefly touchedupon in this chapter. It is, however, an important issue since it heavily influencesthe success of the implementation of PM. The combination of insights into whichinformation is necessary for steering, how to organise performance management



and knowledge of effective ways of actually using the information, will providebetter means for successfully implementing performance management.

References

Argyris, C. (1982). Reasoning, Learning and Action: Individual andOrganisational. San Francisco, CA: Jossey-Bass.

Birnberg, J.G., Turpolec, L. & Young, S.M. (1983). The organisational contextof accounting. Accounting, Organizations and Society, 8, 111-130.

Chang, R.Y. & Morgan, M.W. (2000). Performance Scorecards. San Fran-cisco, CA: Jossey-Bass.

COPC. (2002). COPC Performance Management System – Release 3.2B.Customer Operations Performance Center, Inc.

Deming, W.E. (1982). Out of the crisis: Quality, productivity and competi-tive position. Cambridge: Cambridge University Press.

De Waal, A. (2001). Towards world-class performance management.Tijdschrift Financieel Management. In Dutch.

Harry, M.J. (1998). The Vision of Six Sigma, 8 volumes. Phoenix, AZ: Tri StarPublishing.

INK. (2001). Manual for assessing the position of businesses. Zaltbommel,The Netherlands: INK.

Kaplan, R. & Norton, D. (1992, January/February). The Balanced Scorecard– Measures that Drive Performance. Harvard Business Review.

Kaplan, R. & Norton, D. (2000). The Strategy Focused Organization.Harvard Business School Press.

Locuratolo, E. (2002). Designing Methods for Quality. Information Modellingand Knowledge Bases XIII. IOS Press.

Mazur, G.H. (1993). QFD for Service Industries. Proceedings of the FifthSymposium on Quality Function Deployment, Novi, Michigan.

Mintzberg, H. (1983). Structures in Five: Designing Effective Organiza-tions. Prentice Hall.

Mintzberg, H. (1991). Strategy and intuition – A conversation with HenryMintzberg. Long Range Planning, 24(2), 108-111.

Mintzberg, H. (1994). The rise and fall of strategic planning: Reconceivingroles for planning, plans, planners. New York: The Free Press.



Scheipers, G., Ameels, A. & Bruggeman, W. (2002). Value-based management:an integrated approach to value creation. A literature review. In L. Peeters,P. Matthyssens & L. Vereeck (Eds.), Stakeholder Synergie:Referatenboek 25e Vlaams Wetenschappelijk Economisch Congres,Hasselt, (pp. 77-128). Leuven-Apeldoorn: Garant.

Simons, R. (1995). Levers of Control – How Managers Use InnovativeControl Systems to Drive Strategic Renewal. Boston, MA: HarvardBusiness School Press.

Strikwerda, H. (2000). Het ontwerpen van een Organisatie: deConcernstructuur. Financial Times/Prentice Hall. In Dutch.

Van den Bosch, F.A.J. & Van Wijk, R. (2001). Creation of managerialcapabilities through managerial knowledge integration: A competence-based perspective. In R. Sanchez (Ed.), Knowledge Management andOrganizational Competence. New York: Oxford University Press, 159-176.

WCC. (2001). Beyond Measurement Alone. Report of the Working Councilfor Chief Financial Officers, London. Retrieved from the WWW:www.cfo.executiveboard.com

Wondergem, B.C.M. (2003). Het Selecteren van een Geschikte Methode Voorhet Formuleren van Indicatoren. Proceedings of the ConferentieInformatiewetenschap 2003, Eindhoven, The Netherlands, November2003. In Dutch.

Wondergem, B.C.M. & Wulferink, H. (2002). Prestatie-indicatoren. Informatie,48-52. In Dutch.

Wondergem, B.C.M. & Eskens, J. (2003). Bestuurlijke Begrenzingen van deBalanced Scorecard. Management & Informatie. In Dutch.

Yilmaz, M.R. & Chatterjee, S. (1999). Six-Sigma Quality in Small Businesses:A Genesis for Growth. Journal of Business and Management, 6(2), 100-115.

Multimedia Conversion with the Focus on Continuous Media 235


Chapter XI

Multimedia Conversionwith the Focus

on Continuous MediaMaciej Suchomski,

Friedrich-Alexander University of Erlangen-Nuremberg, Germany

Andreas Märcz, Dresden, Germany

Klaus Meyer-Wegener,

Friedrich-Alexander University of Erlangen-Nuremberg, Germany

Abstract

This chapter describes an approach to a very complex subject of multimediaconversion. The authors hope to familiarize readers with the idea ofmultimedia objects transformation, especially time-dependent data (likevideo and audio streams). After a short introduction, the chapter givesfundamentals with broad references to the discussed field. The presentedway of modeling conversions including an abstract model, categories oftransformation and a processing model, leads to an application of thegraph-based model in the deployment considering model-specific issues,

236 Suchomski, Märcz, and Meyer-Wegener


functional correctness, scheduling, management of resources and admissioncontrol. RETAVIC and memo.REAL are ongoing projects and the means ofevaluation of the models of conversion as well.

Introduction

Multimedia data are ubiquitous today. The formerly separated areas of musicrecordings, radio, and television are all moving to digital formats, which inessence means that all recordings are becoming data and can be stored andmanipulated as data. Standard data storage systems can be used for sound andvideo, and both can be transmitted over computer networks. The multimediacomputer as the endpoint is beginning to replace facilities such as telephone,radio, VCR, TV, and disk players.

While this looks like integration and simplification, the computers themselves areanything but homogeneous. They are equipped with many different kinds ofdisplays and audio/video boards, not to speak of software. Hence, the same pieceof media content must be available in a large variety of formats. User require-ments regarding platform and quality on one hand and resource limitations on theother even increase this variety. The simplest way is to create copies in all knownformats, but this has many deficiencies, in particular when updates are neces-sary. As an alternative, transformations are available. So it seems to be a usefulapproach to keep media assets in a single copy and in a neutral format, and totransform them on request into the format needed by a particular user. This iseven more useful in a large archive of media assets that is used by applicationson many different platforms, e.g., in an authoring or teaching scenario. Assumefor instance an archive of medical images and videos which must be kept withoutany loss of information and thus will potentially be rather large. In lectures andother presentations, however, a compressed version on a laptop computer will bemore appropriate. While some of the images and videos can be transformedoffline before the presentation, a discussion could create the need to access otherobjects online. Then a transformation at the time of the request is unavoidable.

In the following, the term “media object” (MO) will be used for any kind ofmedia data that belong to a single medium, i.e., text, image, audio, or video. Ofcourse, media objects can be combined into multimedia objects (MMO), but theirhandling must be clarified before. If a media object is available in one form andis then requested in another, it must be transformed. In this chapter, the term“conversion” will be used to denominate all forms of transformation onmultimedia data. Many conversion algorithms and programs are at hand, so theyshould be re-used in this context. In order to fulfill any kind of user request,



however, it may be required to combine more than one converter. So conversionsneed to be registered and classified.

Many conversions affect the quality of the media objects. In order to cope withthe resource limitations in the network and in the end-user devices, the qualitymust often be reduced. It is important to describe the quality in a number ofcharacteristics like resolution and number of different colours. This allows tofind a balance between resource requirements on the one hand and perceivedquality on the other.

A specific problem arises with media objects that have inherent time, i.e., audioand video. They are often referred to as streams. To create the requested formbefore beginning the playout would lead to a significant latency that many usersdo not accept. So the media object should be transformed during the playout,which requires real-time processing. This imposes tough requirements on thesystem that manages and delivers the media objects especially according to thesereal-time requirements. Such a system could support a large variety of quality-of-service requests for media objects, but it is of high complexity.

The goal of this chapter is to introduce the building blocks of such a system. Thedifferent forms of media objects — often defined by standards — must be wellunderstood to be handled properly. Next, after looking at other projects andsystems with similar goals, a model of conversion is defined. It allows forclassification and provides an abstract view of conversion tasks. These indi-vidual conversions are then combined into conversion graphs. To execute them,scheduling and admission control must be handled in cooperation with a real-timeoperating system.

Fundamentals

This section provides technical definitions in the discussed field. Obviously, themeaning of media data and multimedia data should be defined first. Media dataare text, image (natural pictures, 2D and 3D graphic, 3D pictures), audio (naturalsounds including human voice, synthetic) and video (natural video, 2D and 3Danimation, 3D video). These data have a special digital representation when usedin computers that is called media object (MO). Multimedia data combinesmore than one of mentioned media data and is represented by multimediaobjects (MMO’s).

While text and image are well known and reasonably simple to understand, theemphasis here is on audio and video — called audio stream and video streamrespectively from now on. An audio stream consists of discrete values (samples)



usually obtained during the process of sampling audio with a certain frequency.A video stream consists of images (frames) that have also been captured witha certain frequency. The characteristic distinguishing these streams from otherkind of data is the time constraint: The occurrence of the events (samples orframes) is ordered, and the periods between them are constant. These charac-teristics specify the continuous properties of a data stream (and justify why theyare called time-dependent data or timed data). Thus a media or multimedia objectwith this time constraint is usually referred to as a timed MO or a timed MMOrespectively. Because continuous properties are almost always present inMMO’s, the term timed is usually skipped (just as non-timed is skipped whenreferring to MO’s which are not time-dependent, e.g., images). By the way, theterms “timed” and “time-dependent” are often interchanged with the term“continuous”.

In reality audio-video streams (as well as non-timed objects) often containadditional information that describes the stream (object) itself. It is called metainformation, and it includes among others: stream properties (e.g., duration, bitrate) and quality properties (such as resolution, frame or sample rate, etc.). Metainformation heavily depends on the data it describes, and because each type ofmedia object differs from the other (e.g., stream properties are not present innon-timed objects), meta information contains different properties. Because anMMO consists of more than one MO, it must first identify the MO’s it includesand second it must store some arrangement information (additional properties inmeta information), e.g., temporal and spatial layout.

In available specifications like MPEG-4 (Battista et al., 1999) and H.263 (ITU,1996), the pictures (frames) of a video stream are grouped into groups of pictures(GOP’s) and further into video sequences. To generalize this, a term is adoptedhere from Gemmel et al. (1995): A quant is a portion of data that is treated asone logical unit occurring at a given time. Representatives of quanta are asample, a frame, a text, or a combination of them (e.g., a GOP), etc. So, anabstraction of the streams mentioned so far is a multimedia stream as a timeddata stream that consists of quanta.

In order to explain the transformation of MO’s and MMO’s in the followingsections, a logical description is needed. Some models of MO’s and MMO’s havealready been defined and discussed in the literature. It is common that each MOhas a type, a format and a content. They will be referred to as MO.type (e.g.,text, audio, etc.), MO.content and MO.format, respectively. Within MO.format,structure (e.g., frame rate, pixel depth, resolution) and coding scheme (e.g.,QuickTime, MPEG-1/-2, DivX, XviD, MP3, AAC) can be further distinguished.An MMO is structured similarly, but it adds to MMO.format data about relationsamong the included MO’s, i.e., data on temporal/spatial relations.



Based on this model of MO’s and MMO’s, all components of the conversionprocess will now be described. This process is depicted in Figure 1. A converterapplies a conversion function to an MMO. It may add, remove, or change contentas well as format and media type of any part. A chain of converters couplesa few converters in order to perform a conversion process with a more complexfunctionality. A chain is a directed, one-path, acyclic graph, i.e., a sequential lineof converters, which passes MMO’s from one node only to the next. A graphof converters consists of more than one connected converter chains. It is usedfor instance, if an MMO must be split into MO’s in order to use media-specificconverters, i.e., converters working only with a given type and/or format ofmedia object.

Regarding timed (M)MO’s, this general model of conversion graphs must beextended to reflect the timing. Instead of whole (M)MO’s, only quanta arepassed from one converter to the next in the chain, and that must be done at aparticular point in time, e.g., every 40 milliseconds for a video with 25 frames persecond. The main goal in modeling timed MO or MMO conversions is to definesuch an extended model independent of hardware, implementation, and environ-ment (Marder, 2002). In our opinion, a very promising model is that of jitter-constrained periodic event streams proposed by Hamann (1997). The author in2001 added jitter-constrained data streams which suit multimedia very well.These streams consist of a time stream and a volume stream. The former isdefined as t = ( T, D, τττττ, t0 ), where T is the average event distance (the period),D the minimum distance, τττττ the maximum jitter (lateness), and t0 the starting point.Analogously, the volume stream is defined as s = ( S, M, � , s0 ), where S is theaverage quant size, M the minimum quant size, � the maximum jitter (deviation),and s0 the initial value. Later, these models will be used in the deployment phaseto derive the important characteristics of the conversion process.

Another important issue regarding transformation of timed (M)MO’s is provid-ing and controlling the level of quality. Quality of Service (QoS) is defined bythe ITU-T as, “a set of qualities related to the collective behavior of one or more

Figure 1. Conversion process using multiple converters

converter graph

converter chain

converter converter converter

converter converter



objects” (ITU, 1997), i.e., as an assessment of a given service based oncharacteristics. Examples of these QoS characteristics (or parameters) are:latency (or delay), jitter in delay, delay bound, loss rate (lost data, delayed data),throughput, jitter in throughput, reliability (process failures, communicationbreaks), etc. (Vogel et al., 1995; Plagemann et al., 1995; Hafid and Bochmann,1998). A more elaborate description and classification of QoS characteristicscan be found in ITU (1997).

In addition to QoS, it is useful to also take Quality of Data (QoD) and Qualityof Experience (QoE) into account, as presented in Figure 2. Starting with thedata source, a stored object has a certain quality, e.g., resolution and frame rate,which is the QoD. The server provides the data with or without transformation,i.e., it serves the data with a quality level equal to the transformed QoD —indicated by T(QoD) — and with respect to its own services QoS

SRV. The

network delivers the data to the client with QoSNET

and influences as well theoverall quality. Additionally, the client side responsible for receiving and presen-tation to the end user has its own QoS

CLI. The end user finally perceives the

delivered data and feels some level of experience (QoE; also called subjectiveQoS) that is most important in the whole process of multimedia delivery.

However, discussing all those aspects in more detail goes beyond this work. Apossibility of mapping QoE to objective QoS is explained by Plagemann et al.(1995). Here, we focus on the server side and assume that the QoD is given andthat the T(QoD) requested by the user must be provided. Then it is necessaryto control the quality during serving (or processing). In other words, only theQoS

SRV is of interest at this point.

In order to guarantee a certain QoS during a conversion process at the serverside, the whole process with all involved components (mostly converters) mustbe scheduled in a real-time environment — with the possibility to control all partsof the process precisely.

Figure 2. Qualities involved in the process of delivering MMO’s to theclient

CLIENT SERVER

QoE <= QoSCLI

QoSNET

NETWORK

QoSSRV + T(QoD) QoD

End-Point of

Interest



Related Work

Media-data transformations have been well-known issues for quite some time.Many applications for converting or transforming audio and video can be found.Some built-in support for media files is available in many operating systems(OS’s). Because of that, they are sometimes called Multimedia OS’s, but usuallythe support can neither meet all requirements nor handle all possible kinds ofmedia data. In order to better solve the problems associated with the largediversity of formats, frameworks have been proposed, e.g., DirectShow, JavaMedia Framework (JMF), CORBA A/V Streams, and MME Toolkit. But to ourknowledge, no published work develops a theory of multimedia transformationsin a broad range, i.e., considering the other solutions. Of course, the use of filtersin multimedia networking and mobile communication has been covered exten-sively.

The pioneers, Pasquale et al. (1993) and Yeadon (1996), introduced somegeneralizations of video transformations. Pasquale defined a filter as a trans-former of one or more input streams of a multi-stream into an output stream,where the output stream replaces the input streams in the multi-stream (Pasqualeet al., 1993). He classified filters into three groups regarding their functionality:selective, transforming, and mixing. Yeadon (1996) presented five generic filtermechanisms: hierarchical, frame-dropping, codec, splitting/mixing, and parsing.He also proposed the QoS-Filtering Model which uses a few key objects toconstitute the overall architecture: sources, sinks, filtering entities, streams, andagents. There are many other papers, e.g., Margaritidis and Polyzos (2000) andWittmann and Zitterbart (1997), but they follow or somehow adopt the above-mentioned classifications of the pioneers. All of them consider only the commu-nication layer (networking) aspects, which is not sufficient when talking aboutmultimedia transformations.

The Microsoft DirectX platform is an ideal example of media transformations inan OS-specific environment. The most interesting part of DirectX is DirectShow(Microsoft, 2002b), which is responsible for dealing with multimedia files —especially audio/video. It uses a filter-graph manager and a set of componentsworking with different formats. These are specially designed “filters” (alsocalled media codecs). Filter graphs are built manually or automatically (Microsoft,2002a). Unfortunately, DirectX is only available under one OS family, and it doesnot support QoS or real-time, so use at the client side is limited.

The Java Media Framework (JMF) by Sun (Sun Microsystems, 1999) is acompetitor of MS DirectShow. JMF uses processors (similar to filter graphs)that are built from controls (filters) and are ordered in transformation chains.Processors can be configured with suitable controls by hand or on the basis ofprocessor models. In contrast to filter graphs, processors can be combined with



each other. JMF is not limited to just one OS, but it does not support QoS or real-time, either.

Posnak et al. (1997) proposed an adaptive framework for developing multimediasoftware components called the presentation processing engine (PPE) frame-work. PPE relies on a library of reusable modules implementing primitivetransformations (Posnak et al., 1996). They also proposed a mechanism forcomposing processing pipelines from these modules.

Another work of some importance is VirtualMedia (Marder, 2000). It defines atheory of multimedia metacomputing, i.e., a new approach to the managementand processing of multimedia data in web-based information systems. Marder(2001) offered a solution for application independence of multimedia data byintroducing an advanced abstraction concept (called transformation indepen-dence). It includes several ideas like device independence, location transpar-ency, execution transparency, and data independence. In Marder (2002), theauthor presented an approach to construct a set of connected filters, a descrip-tion of the conversion process, and an algorithm to set up the conversion graph.The transformation issues are solved by using individual signatures (mediasignatures as well as filter signatures). Unfortunately, an implementational proofof concept is still missing.

Other work in the field of audio/video transformation relates to the concept ofvideo transcoding (Kan & Fan, 1998; Keesm et al., 1996; Morrison, 1997), amethod allowing for interoperability in heterogeneous networks by changingformat, resolution, and/or transmission rate. So, they refer to a converter as atranscoder. Dogan (2002) talks about video transcoding (VT) in two aspects:homogeneous and heterogeneous. Homogeneous VT only changes bit rate,frame rate, or resolution, while heterogeneous VT allows for transformationsbetween different formats and networks topologies, i.e., different video stan-dards like H.263 and MPEG-4. Dogan (2002) gives a good overview andproposes a solution, but he covers only H.263 and MPEG-4, and he does notaddress the problem of transformation between different standards.

Last, but not least, related work that must not be omitted is an open-sourceprogram for audio/video transcoding (Östreich, 2003). It is called “transcode,”and it is still under heavy development, but a stable version is available. The goalis to produce a utility for video-stream processing that can be run from a Linuxtext console. The approach uses raw (uncompressed) data between input andoutput, i.e., transcoding is done by loading modules that are either responsible fordecoding and feeding transcode with raw video/audio streams (import modules),or for encoding the frames (export modules). Up to now, the tool supports manypopular formats (AVI, MOV, ES, PES, VOB, etc.) and compression methods(video: MPEG-1, MPEG-2, MPEG-4/DivX/XviD, DV, M-JPEG; sound: AC3,MP3, PCM, ADPCM), but it does not support real-time.



Summarizing, there are interesting solutions for media transformations that areready to be applied in certain fields, but still there is no solution that supports QoS,real-time, and format independence in a single framework.

Modeling Conversions

The new idea here is to build a framework for managing transformations ofMMO’s that work in real-time if necessary and guarantee QoS. An architecturebased on conversion graphs is defined that includes an abstract model ofconverters, categories of conversions, and a processing model for converters(Schmidt et al., 2003; Märcz & Meyer-Wegener, 2002).

Abstract Model for Converters

The first thing needed to transform MMO’s with QoS constraints is a basicconverter model. It must describe the conversion itself, the transport of dataduring the conversion process, and the QoS guarantees. Due to the high diversityand complexity of multimedia conversions, existing converters are used. In acase of timed MMO’s however, they must be adjusted to provide real-time andQoS.

In general a converter can be regarded as a black box. It converts incomingmedia objects mo

i, 1<=i<=n to outgoing media objects mo’

k, 1<=k<=m (Figure 3).

Neither input nor output is restricted to just one object, and the numbers need notmatch. In many cases, n and m are less than three.

The functionality of the conversion is described by a set of conversionfunctions CC

k : mo'

k = CC

k (mo

1, mo

2, ..., mo

n). Generally these functions consist

of three parts. First, each function maps the parameters of the incomingstream(s) to those of its outgoing stream. For timed MO’s, these parameters aredefined by the model of jitter-constrained periodic streams and include averagequanta size with jitter (for volume streams) or average event distance with jitter

Figure 3. Black-box view of a converter

converter

mo1mo2

mon

mo'1mo'2

mo'm



(for time streams). Second, the functions describe the format conversions FCk :

f 'k = FC

k (f

1, f

2, ..., f

n) which map the incoming media-object format description(s)

(fi = mo

i.format) to its outgoing media-object format description (f'

k =

mo'k.format). As a third part, the incoming media objects are themselves

converted to the outgoing media object. This is given by the converter code, incontrast with the others parts which must be defined during a converter analysisbased on a given converter.

Categories of Transformations

To organize the set of all converters, their conversion functions are grouped incategories with individual features (Figure 4). The first category is that ofmedia-type changers. Converters in this category transform the media type ofone of the incoming media objects (mo

i.type) into another media type for an

outgoing media object (mo’k.type), where ∃

i,k: mo

i.type ‘≠mo’

k.type and f

i ‘≠f’

k

and moi.content = mo’

k.content. Because two different media types do not have

common formats, the format of the media object must be changed, too. Thecontent, however, should remain the same — which is naive in many realapplications, but it is the goal of this operation. A typical example is that the mediatype must be changed due to hardware limitations (no audio device), or thatclients are handicapped people. Hence, speech recognition is used to turn audiointo text, and “readers” do it the other way around.

Converters of the second category do not change the media type, but the formatof the media object. They are called format changers, and are described by∃

i,k: mo

i.type = mo’

k.type and f

i ≠ f’

k. While not changing the content

(moi.content = mo’

k.content) is the goal, it may not be possible in reality, because

Figure 4. Categories of conversion functions

�

��

��

��

��

��

��

��

��

��



some formats require compression and thus a loss of information. The contentof mo

1 and mo

2 is considered to be the same, if mo

1 can be transformed into mo

2

and vice versa without using external knowledge or information. So formatchangers are split into two subcategories, namely, lossless and lossy. Losslesschangers have an inverse conversion function C’

hC with ∀

i∃

h : mo

i = C’

hC (C

1C (mo

1,

mo2, ..., mo

n), C

2C (...), ..., C

mC (...)). For lossy conversions, the format change implies

a content loss which must be known to the clients and must be acceptable forthem. More details can be found in Marder (2002). Examples of this category arethe typical encoders and decoders, many of which compress media objects (e.g.,DivX, MPEG, H.26x, RLE). A format change can be caused by hardwarelimitations (channel coding, colour reduction, down-sampling) or by user demand(resizing).

Finally, the third category of converters are those which explicitly change thecontent of a media object, while the format is not affected: ∃

i,k: mo

i.type =

mo’k.type and f

i = f’

k and mo

i.content ≠ mo’

k.content. They are called content

changers. Examples are editors, edge markers, high-pass or low-pass filters.

A very special case of content change is the dropping of quanta, which can occurbecause of resource limitations. In order to guarantee a certain QoS, uncon-trolled quanta loss must be avoided. However, a special converter can bescheduled as a lossy converter with a controlled (statistical) quanta loss. Thisoften means lower resource requirements for the whole converter graph,compared to the guarantee of no quanta loss. Normally these lower resourcerequirements are preferred, but the decision between lossless and lossy deliverymust be made by the user (accepting the quanta loss). This kind of contentchange in particular makes sense, if the quanta loss is not even noticed by theuser, that is, the same QoE is produced.

A Processing Model for Converters

As described above, timed MO’s are structured into quanta (frames, samples,GOP’s, etc.). Transfer is then done quant by quant, forming a streaming process.In this process, a converter reads a sequence of quanta (or just one quant) fromits input stream, processes these quanta and writes a sequence of quanta into itsoutput stream. Here it is no longer sufficient to treat a converter as a black box,a closer look is needed. Hence, a converter is broken down into an input, anoutput, and a conversion (or processing) part. The conversion part is treated asa black box again. These three parts are organized in the main loop, which is thecharacteristic structure of each streaming converter (Figure 5).

In general, the main loop starts after initialization with reading the first quant(beginning of stream), iterates over all other quanta, and ends with reading thelast quant (end of stream) and writing the associated output. For timed MO’s, the



main loop operates periodically, so there is a time limit for the processing of eachquant. Since size and contents of the quanta may differ significantly, theprocessing time varies. Some quanta are processed completely before the endof the period, while others need more time than available. It has been observedthat the maximum cumulative deviation from the end of the period is much moreuseful in calculating the effects than the distribution of processing times. This isdescribed by the jitter-constrained periodic time streams that have already beenintroduced.

While they model the time jitter and thus the maximum lateness, it is equallyimportant to handle the deviation of transferred data volumes, e.g., for thecalculation of buffer sizes. This is described as a jitter-constrained periodicvolume stream. The jitter in volume streams results from different quant typesand compression levels. In summary, each converter instance must have adescription of all incoming media objects mo

i and all outgoing media objects mo’

k

as jitter-constrained periodic time and volume streams. Please note that thesedescriptions are data-dependent, i.e., the streams are different for differentmedia objects. It is then necessary to find mappings from the description of theinput streams to the description of the output streams.

To achieve that, the use of resources by the converter must be taken intoaccount. All resources are managed by the underlying operating system.Resource usage can again be characterized by jitter-constrained periodic timeand volume streams. Processing the quanta is done in periods with jitter, hencethe use of resources is also periodical (in general with a shorter period), and thevolume of data handled varies around an average size (which may be smaller thatthe average quant size), so the same kind of model can be used.

Figure 5. Main processing loop of a converter

converter

input quanta fromstream(s)

process quanta

output processedquanta

main loop

begin

end



Deployment of the Graph-Based Model

Model-Specific Issues

The section Fundamentals has introduced the notion of conversion chains orgraphs, respectively, which allow for the construction of a large set of transfor-mations from a given set of converters. The descriptions of all the convertersinvolved in such a graph must be combined to handle the full complexity ofconversions, especially the calculation of the resource usage and the scheduling.To prevent the accumulation of jitter over the whole conversion process, theconverters are coupled by buffers. This means that converters write theiroutgoing quanta into dedicated buffers, from which they can be read bysubsequent converters (Figure 6).

Because some conversions can be performed in arbitrary order, usually morethan one conversion graph can be built for the same transformation task. Forexample, the order of “resizing” and “brightness change” is irrelevant.

The task now is to find functionally correct and schedulable conversion graphs.While the functional correctness is closely coupled with presentation demands(user or hardware requirements), the schedulability is essential to provide QoSguarantees during the streaming and conversion process.

Building Functionally Correct Conversion Graphs

Before the timing constraints of a conversion can be taken into account, it isimportant to decide about the logical structure. There are three ways of buildingfunctionally correct conversion graphs that perform the requested transforma-tion:

• based on interface,

• based on functionality,

• based on both functionality and interface.

Figure 6. Example of conversion graph with buffers

demux:mpeg-sys

network

mpeg-videoto DivX

mpeg-audioto wma

mux:asf

buffer

buffer buffer

buffer

bufferbuffer

disk



The first assumes that converters are coupled by interfaces. It means that theformat of the output data of one converter is accepted as input by the consecutiveconverter. In other words, the interfaces of output and input (metadata ofquanta) must be the same (or at least must allow for the creation of a connectionthat makes sense). This means that the input interface of the subsequentconverter includes or extends the output interface specification of the previousconverter. For instance, if the first converter produces quanta in YCrCb colourformat, the second converter must accept this format (it may accept otherformats as well).

The second method is based on the functions of the converters. Each converterperforms a specific task. The managing application stores information onfunctions of available converters and on functionally correct chains (e.g., colourconversion, resizing). Based on this, converters that have the requested function-ality are chosen to build a chain. For example, display on screen (RGB colourspace) with resolution and colour space different from the source is requested.So, converters doing resizing and converters doing colour conversion are chosenin order to build a conversion graph for this task.

These two methods both have their limitations. In particular, they might lead toa logically correct chain based on interfaces that does not provide the requestedfunctionality. Similarly, a logically correct chain based on functionalities mayresult in which the interfaces do not match each other (so no quant can be passedfrom one converter to the next, because that would require a compatible type ofquant). So the two methods can only be applied with some limitations. In orderto be on the safe side, a third and most reasonable method is defined. It combinesboth methods and builds a chain using the functions as well as the interfaces ofthe converters. The result is a logically correct chain in all respects, i.e., functionand data correctness are provided. The way to build up correct conversiongraphs respecting both functionality and interfaces is given by a couple ofoptimisation algorithms, e.g., Greedy, Simulated Annealing or EvolutionaryAlgorithms (Michalewicz & Fogel, 2000). In Marder (2002), which was alreadydescribed as related work, signatures for media objects and converters (aliasfilters) were introduced. Based on these signatures, a set of functionally correctconversion graphs can be found with the aid of optimisation algorithms. The workalso proposes information how to use these algorithms. Additionally, converter-graph transformations can be used for further optimisations.

Scheduling, Resource Management, and AdmissionControl

With a given conversion graph, the next step is to guarantee a certain QoS(Claypol & Tanner, 1999; Abdelzaher & Shin, 1999; Campbell, 1996). This for



example means that only a limited number of frames in a video stream aredropped, or that the jitter in frame presentation or recording must not exceed agiven maximum.

Here, a real-time environment with an efficient resource scheduling is neededthat can only be provided by a real-time operating system (RTOS) (QNX, 2001;Härtig et al., 1998; Yodaiken & Barabanov, 1996). The task of the multimediatransformation is to provide the scheduling parameters to the RTOS and to do anadmission control to evaluate a converter graph as schedulable or non-schedulable.This means that some system resources are scheduled at application level(Märcz & Meyer-Wegener, 2002).

Resource requirements can be divided into two parts, a static part which does notdepend on time (e.g., memory), and a dynamic part referring to active resourceswhich depends on time (e.g., CPU, DMA, busses). While the static part isdescribed by the volume required over the whole transformation process, thedynamic part is treated as a bandwidth (resource use per second). “Bandwidth”here means the number of operations or the amount of data that must beprocessed or transmitted in the time interval between quant arrival (beforeprocessing) and quant departure (after processing). Processing a quant must notaffect the resources needed for the next quant. Hence, the time interval betweenquant arrival and quant departure must be long enough to handle all possibleoperations on a quant. This can be determined by worst-case analysis or —considering the high jitter in execution times of quant processing — by meanvalues plus a bounded jitter. Both worst-case and mean-plus-jitter can bedescribed as jitter-constrained periodic streams.

Now, a significant part of the scheduling is the description of the convertersinvolved, including resource requirements as jitter-constrained periodic streams,which must be done separately for each converter. This description is easy tofind for converters without content dependencies, i.e., the resource require-ments can be derived directly from the parameters of the input formats f

i =

moi.format. Otherwise the resource requirements of a converter depend on the

media object itself, i.e., the format fi plus the content mo

i.content. At the moment,

these content-dependent resource requirements are merged into the jitter valueof the jitter-constrained periodic streams. The calculation of an accurate jittervalue from format f

i and some characteristic content-description parameters

(e.g., motion complexity) is yet to be developed.

For each input object moi, the function ( )

i

C

rr

C

rmoRs:R = yields the dynamic

resource requirements of a converter in the form of a jitter-constrained volume

stream( rs ) for each resource r. Additionally, rs =Sr describes the average

volume of the stream, and frate

is the mean quant rate, which is defined by userrequirement (e.g., quant playout rate at the end of the chain). Then the required



bandwidth on resource r is given by QCr dynamic

= RCr (mo

i)*f

rate. The static

resource requirements are unchanged over the lifetime, independent of quantrate, and are given directly by QC

rstatic = RC

r (mo

i).

The buffers needed to couple the converters also require resources, i.e., thebuffer size in the resource memory. They can be calculated with the aid of thejitter-constrained periodic streams (Hamann et al., 2001).

The sum of all requirements must not exceed the maximum system bandwidth oneach resource. If the maximum system capacity for a resource r is given by C

r,

then the following condition must always hold:

≤∑∀ r

C

Cr CQ:r

running

.

So, a converter graph is only schedulable, if:

≤∑+∑∀ r

C

Cr

C

Cr CQQ:r

chainnewrunning

,

which means that the additional requirements of the new converter chain mustbe less or equal to the available resources, or the sum of all chains, including thisone, must be less than or equal to the system capacity. In some situations (withdependencies between two dynamic resources) this describes only the neces-sary condition.

Evaluation

Many projects have been started by researchers all over the world, but they havefollowed different development directions such as multimedia transformationson gateways in heterogeneous networks, transformations on client-side soft-ware and hardware systems, end-to-end AV conversion solutions for telecom-munications, etc. Here, the work focuses on the multimedia database aspect.

The goal of obtaining format independence for stored multimedia data hasprovided the background for the investigation of conversion. Two ongoingprojects, memo.REAL (Märcz, 2003) and RETAVIC (Suchomski, 2003), are themeans to evaluate the models of conversion. An overview is given in Figure 7.



The tasks covered by each of the projects are marked in grey, and thesurrounding ellipses represent exterior factors.

The first step is analysis and benchmarking of existing converters with availablemedia data. The outcome is used in a modeling phase that covers three differentaspects: data, conversion, and resource models (by applying the theory of jitter-constrained periodic streams). The next step is to develop scheduling andadmission control methods that are strongly influenced by RTOS. In theseprojects, DROPS (Härtig et al., 1998) is used. The execution of a conversionprocess is also placed in an RTOS, which serves as a fully-controllable run-timeenvironment. To enable a converter to run in an RTOS, it has to be adapted tothis environment, i.e., it has to be extended to use the component streaminginterface (CSI), which is defined especially for controlling and real-time oper-ability (Schmidt et al., 2003). It can further be used by a control application. So,the process of developing real-time converters requires the following inputs: agiven non-real-time converter, the analysis of behaviour, and the description interms of the defined models. Moreover, it is very likely that in the implementation,the model and the adoption will influence each other.

Summarizing, the theses works of five students (master theses and studyprojects) have already been finished. They have contributed to RETAVIC andmemo.REAL by producing usable outcome that proves the theoretical ideas.Namely, a benchmark for AV compression, a bit-rate control algorithm for an

Figure 7. Overview of ongoing projects

�

��

��

��

��

��

��

��

��

��

��

��

��

!��"��

��

#$%��

�&#%'��

��



MPEG-4-based codec extending it with real-time capabilities (Militzer et al.,2003), a format description of media data (Feidler, 2003), bandwidth models ofconversion and resources for scheduling and buffer optimization, and a compo-nent streaming interface (Schmidt et al., 2003) have been developed. Currentlythe focus is on making the whole system complete in order to show a workingexample.

Conclusions

While the overall subject of multimedia conversion is very complex and thus stillincludes unsolved problems, some initial solutions are available. It is commonknowledge that converters should be organized in chains or graphs instead ofbuilding new converters for each task. In order to make such a conversion graphexecutable in a real-time environment, models are needed for the differentcomponents involved. This includes the data being processed. It consists ofquanta which are manipulated and transferred in periods. The converters usedmust be described by their functionality, i.e., the mapping of input to output, aswell as the resource requirements. The model of jitter-constrained periodicstreams turned out to be very useful here, for the timing and for the data volumeshandled. This model is rather simple in that it only needs four parameters perstream. Still it allows for a variety of derivations needed in this context. Basedon such a description, initial scheduling of conversion graphs in a real-timeenvironment becomes possible. A simple bandwidth model allows us to preventthe over-use of resources.

Much more work is required. The models need to be refined. In parallel, a systemis being built to evaluate the decisions made on their basis. This will significantlyinfluence the work on the models, because their simplicity is an advantage thatshould not be given up without reason.

References

Abdelzaher, T.F. & Shin, K.G. (1999). QoS Provisioning with qContracts in Weband Multimedia Servers. Proceedings of the 20th IEEE Real-TimeSystems Symposium, Phoenix, AZ, USA, December 1-3, (pp. 44–53). LosAlamitos, CA: IEEE Computer Society.

Battista, S., Casalino, F. & Lande, C. (1999). MPEG-4: A Multimedia Standardfor the Third Millennium, Part 1. IEEE Multimedia, 6(4), 74-83.



Campbell, A.T. (1996). A Quality of Service Architecture. Ph.D. thesis.Lancaster, UK: University.

Claypool, M. & Tanner, J. (1999). The Effects of Jitter on the Perceptual Qualityof Video [Poster]. Proceedings of ACM Multimedia ’99 (Part 2), Vol.2, Orlando, FL, USA, October 30-November 5, (pp. 115-118).

Dogan, S. (2001). Video Transcoding for Multimedia Communication Net-works. Ph.D. thesis. Guildford, UK: University of Surrey.

Fiedler, M. (2003). Entwurf einer Multimedia-Formatbeschreibung. M.Sc.thesis. Dresden, DE: Technical University.

Gemmel, D.J., Vin, H.M., Kandlur, D.D., Rangan, P.V. & Rowe, L.A. (1995).Multimedia Storage Servers: A Tutorial. IEEE Computer, 28(3), 40-49.

Hafid, A. & Bochmann, G.V. (1998). Quality of Service Adaptation in Distrib-uted Multimedia Applications. Multimedia Systems Journal, 5(5), 299-315.

Hamann, C.J. (1997). On the Quantitative Specification of Jitter ConstrainedPeriodic Streams. Proceedings of the Fifth International Symposium onModelling, Analysis and Simulation of Computer and Telecommunica-tion Systems, Haifa, Israel, January 12-15. Los Alamitos, CA: IEEEComputer Society.

Hamann, C.J., Märcz, A. & Meyer-Wegener, K. (2001). Buffer Optimizationin Realtime Media Servers Using Jitter-constrained Periodic Streams(Technical Report SFB 358 - G3 - 01/2001). Dresden, DE: TechnicalUniversity.

Härtig et al. (1998). DROPS - OS Support for Distributed Multimedia Applica-tions. In Proceedings of the Eighth ACM SIGOPS European Workshop,Sintra, Portugal, September 7-10.

ITU. (1996). Video Coding for Narrow Telecommunication Channels at <64 kbit/s. ITU-T Recommendation H.263.

ITU. (1997). Information technology – Quality of Service: Framework.ITU-T Recommendation X.641.

Kan, K.S. & Fan, K.C. (1998). Video Transcoding Architecture with MinimumBuffer Requirement for Compressed MPEG-2 Bitstream. Signal Pro-cessing, 67(2), 223-235.

Keesm, G., Hellinghuizen, R., Hoeksema, F. & Heideman, G. (1996). Transcodingof MPEG Bitstream. Signal Processing: Image Communication, 8(6),481-500.

Lu, G. (1999). Multimedia Database Management Systems. Norwood, MA:Artech House.



Manolescu, D.A. & Nahrstedt, K. (1998). A Scalable Approach to Continuous-Media Processing. Proceedings of the Eighth IEEE International Work-shop on Research Issues in Data Engineering, Orlando, FL, USA. LosAlamitos, CA: IEEE Computer Society.

Marder, U. (2000). VirtualMedia: Making Multimedia Database Systems Fit forWorld-wide Access [Extended Abstract]. In EDBT 2000 Ph.D. Work-shop. Konstanz, DE.

Marder, U. (2001). On Realizing Transformation Independence in Open, Dis-tributed Multimedia Information Systems. In A. Heuer, F. Leymann & D.Priebe (Eds.), Datenbanksysteme in Büro, Technik und Wissenschaft,(pp. 424-433). Berlin, DE: Springer.

Marder, U. (2002). Multimedia Metacomputing in Webbasierten multimedialenInformationssytemen. Ph.D. thesis. Kaiserslautern, DE: University.

Margaritidis, M. & Polyzos, G. (2000). On the Application of Continuous MediaFilters over Wireless Networks. Proceedings of IEEE InternationalConference on Multimedia and Expo, New York, NY, USA, July 30-August 2. Los Alamitos, CA: IEEE Computer Society.

Märcz, A. (2003). The memo.REAL Project. Retrieved July 25, 2003 from theWWW: http://wwwdb.inf.tu-dresden.de/research/memo.REAL/

Märcz, A. & Meyer-Wegener, K. (2002). Bandwidth-based converter descrip-tion for realtime scheduling at application level in media servers. Proceed-ings of Workshop of System Design Automation (SDA 2002). Dresden,DE: Technical University.

Michalewicz, Z. & Fogel, D.B. (2000). How to solve it: Modern Heuristics.Heidelberg, Berlin: Springer-Verlag.

Microsoft Corp. (2002a). The Filter Graph and Its Components. RetrievedFebruary 10, 2002, from the WWW: MSDN Library, DirectX 8.1 C++documentation.

Microsoft Corp. (2002b). Introducing DirectShow for Automotive. RetrievedFebruary 10, 2002 from the WWW: MSDN Library, Mobil and EmbeddedDevelopment documentation.

Militzer, M., Suchomski, M. & Meyer-Wegener, K. (2003). Improved p-domainRate Control and Perceived Quality Optimization for MPEG-4 Real-TimeVideo Applications. Proceedings of the ACM Multimedia, MM’03,Berkeley, CA, USA, November 2-8, (pp. 403-411).

Morrison, G. (1997). Video Transcoders with Low Delay. IEICE Transactionson Communications, E80-B(6), 963-969.

Östreich, T. (2003). Transcode – Linux Video Stream Processing Tool.Retrieved July 10, 2003, from the WWW: http://www.theorie.physik.uni-goettingen.de/~ostreich/transcode/



Pasquale, J., Polyzos, G., Anderson, E. & Kompella, V. (1993). Filter Propaga-tion in Dissemination Trees: Trading Off Bandwidth and Processing inContinuous Media Networks. In D. Shepherd, G.S. Blair, G. Coulson, N.Davies & F. Garcia (Eds.), Network and Operating System Support forDigital Audio and Video, Fourth International Workshop, NOSSDAV’93, (pp. 259-268).

Plagemann, T., Saethre, K.A. & Goebel, V. (1995). Application Requirementsand QoS Negotiation in Multimedia Systems. Proceedings of SecondWorkshop on Protocols for Multimedia Systems (PROMS’95), Octo-ber. Salzburg, Austria.

Posnak, E.J., Lavender, R.G. & Vin, H.M. (1997). An Adaptive Framework forDeveloping Multimedia Software Components. Communications of theACM, 40(10), 43-47.

Posnak, E.J., Vin, H.M. & Lavender, R.G. (1996). Presentation ProcessingSupport for Adaptive Multimedia Applications. In M. Freeman, P. Jardetzky& H.M. Vin (Eds.), Proceedings of SPIE Vol. 2667 [MultimediaComputing and Networking 1996, San Jose, CA, USA, January 29-31,1996, (pp. 234-245).

QNX. (2001). QNX Neutrino RTOS (version 6.1). QNX Software SystemsLtd.

Schmidt, S., Märcz, A., Lehner, W., Suchomski, M. & Meyer-Wegener, K.(2003). Quality-of-Service-based Delivery of Multimedia Database Ob-jects without Compromising Format Independence. Proceedings of theNinth International Conference on Distributed Multimedia Systems,Miami, FL, USA, September 24-26.

Suchomski, M. (2003). The RETAVIC Project. Retrieved July 25, 2003, fromthe WWW: http://www6.informatik.uni-erlangen.de/retavic/

Sun Microsystems, Inc. (1999). Java Media Framework API Guide (Nov. 19,1999). Retrieved January 10, 2003, from the WWW: http://java.sun.com/products/java-media/ jmf/2.1.1/guide/

Tsinaraki, Ch., Papadomanolakis, S. & Christodoulakis, S. (2001). A VideoMetadata Model supporting Personalization & Recommendation in Video-based Services. Proceedings of the First International Workshop onMultimedia Data and Document Engineering (MDDE 2001).

Wittmann, R. & Zitterbart, M. (1997). Towards Support for HeterogeneousMultimedia Communications. Proceedings of 6th IEEE Workshop onFuture Trends of Distributed Computing Systems, Bologna, IT, Octo-ber 31–November 2. Los Alamitos, CA: IEEE Computer Society.

Yeadon, N.J. (1996). Quality of Service Filtering for Multimedia Communi-cations. Ph.D. thesis. Lancaster, UK: Lancaster University.



Yodaiken, V. & Barabanov, M. (1996, March). A Real-Time Linux. LinuxJournal.

Vogel, A., Kerherve, B., Bochmann, G. & Gecsei, J. (1995). DistributedMultimedia and QoS: A Survey. Proceedings of IEEE Multimedia, 2(2),10-19.

Coherence in Data Schema Transformations 257


Chapter XII

Coherence inData Schema

Transformations:The Notion of Semantic

Change Patterns

Lex Wedemeijer, ABP Pensioenen, The Netherlands

Abstract

This chapter focuses on change in the information system’s ConceptualSchema in its operational life cycle phase, introducing Semantic ChangePatterns as a novel notion in Conceptual Schema evolution. Each patternoutlines a coherent way to accommodate new information needs, both onthe level of the existing data structure, and on the level of the data instances(data coercion). An initial catalogue of Semantic Change Patterns isproposed, based on actual schema changes observed in business cases. Thecatalogue exposes some of the schema evolution expertise that can be foundin maintenance practice.

258 Wedemeijer


Introduction

Evolving Conceptual Schemas

According to the classic 3-Schema Architecture (ANSI/X3/Sparc, 1975), theConceptual Schema captures and defines the semantics of, and the relationshipsbetween, all the data stored and transacted by an information system. It is a well-known finding by Lehman and Belady that every information system that is usedwill evolve in order to meet the ever-changing user requirements (Lehman &Belady, 1978). As the operational information system evolves, its ConceptualSchema will be subject to change. To paraphrase Lehman and Belady, it is ourexperience, and the motivation of this chapter, that any Conceptual Schema thatis used can and will evolve over time. In other words, a Conceptual Schema, oncedesigned, may claim to be stable in its operational life, but it cannot be assumedto remain rigid and fixed forever more.

This chapter focuses on change in the CS (Conceptual Schema) in the informa-tion system’s operational life cycle phase. We use the term “operational CS” todesignate the unique schema that captures and defines the semantics andrelationships of all the data handled by the operational information system.

It is remarkable that contemporary modeling theories and design practicesregarding Conceptual Schemas tend to overlook evolution of the operational CSin the operational life cycle phase of information systems. Most approachesseem to be restricted to the system development phase only, relying on a singledesign effort to deliver a once-and-for-all CS. However, this fails to recognizethe fact that every CS will be subjected to ongoing changes in its operational life.To remedy this lack, we introduce the notion of Semantic Change Patterns. Thisnotion regarding CS evolution has not been recognized before in the literature,but we have found it to be embraced by business practitioners engaged in thearea of schema maintenance.

Once the need for change in the data schema has emerged, an appropriatepattern can be selected and applied to the problem at hand. The pattern outlineshow new information needs can be accommodated on the level of existing datastructure and on the level of data instances (data coercion). As such, the patternscomprise some of the know-how experience from maintenance, and make thatknowledge available to data administrators and researchers.

Objectives of this chapter are to introduce the notion of Semantic ChangePatterns, to argue its relevance in Conceptual Schema evolution, and to proposean initial catalogue of patterns. We believe that the use of Semantic ChangePatterns can and will be instrumental in achieving the quality and consistency thatengineers look for in Conceptual Schema evolution.



Background

Conceptual Schema in the 3-Schema Architecture

According to the 3-schema architecture, a CS is conceived as the single abstractmodel that completely captures the relevant semantics of the “Universe ofDiscourse” (abbreviated UoD), being that part of the real world that theinformation system is about (Figure 1).

At the same time, the CS is the unique intermediary schema between on the onehand, schemas that expostulate how data is queried and transacted by userapplications, and, on the other hand, the data storage schema for files anddatabases. The former view of the data is usually referred to as ExternalSchemas; the view of data used in Database Management Systems is commonlycalled the Internal Schema. However, we will not discuss this aspect of the CS.In addition, the implications of our semantic change patterns for ExternalSchema or Internal Schema maintenance are beyond the scope of this chapter.

Figure 1. Conceptual Schema as an abstract model of the Universe ofDiscourse

Universe of Discourse"reality"perceived reality

engineeringabstractions

"Best" Model

ConceptualSchema

InternalSchemas

ExternalSchemas

data-realm:Dependent Models

Limited Models

ch3: 3SA (full)

conceptual realm:Symbolic Models

260 Wedemeijer


Semantic Change in the Operational CS

The CS is generally regarded to be a stable component in the architecture(Feldman & Miller, 1986; Wedemeijer, 1999). However, stability is not rigidity:no operational information system or CS can be impervious to change. A well-designed, high-quality CS may have a low number of changes, and small impacts,while many changes with large impacts may signify poor quality. Nevertheless,we feel that it is impossible to abolish changes from the CS altogether, as thatwould assume perfect anticipation: the CS design effort would suffice to copewith any future development whatsoever in the business environment. There-fore, in our opinion, we ought to study change in the CS in its operational lifetime.And it ought to be studied from the semantic perspective, i.e., from the viewpointof UoD and semantics as perceived by the user community. This notion ofsemantics is lacking in all of the above approaches.

We therefore need to introduce the notion of semantic change that we defineto be any change in the operational Conceptual Schema that validly reflectschange in the information structure of the Universe of Discourse.

This definition assumes a causal relationship between changes in UoD and CS,but does not demand that change in the CS be driven by UoD changesexclusively. Rather, the definition guides us to distinguish between semantic andnon-semantic changes, by looking for the corresponding change drivers in thereal world. The definition also allows for a semantic change to affect multipleconstructs of the CS at once or, the other way round, a single CS construct tobe affected by several semantic changes. Finally, notice how the definitionallows for delay (i.e., a CS change may be postponed) and anticipation (i.e., a CSchange may be made in preparation of an expected real world change).

Other Kinds of Change

By the above definition, a CS change is not semantic if no change of informationstructure occurred in the part of the real world modeled by the CS. In this sense,our notion of semantic change is in full agreement with the ANSI/SPARC 3-schema architecture. Even so, not every alteration in the specifications of anoperational information system’s CS constitutes a semantic change as weunderstand it.

For one, an abundance of data model theories exists for CS specification, suchas the relational data model, E-R and Extended E-R models, UML classdiagrams, and many variants and extensions thereof (Kim & March, 1995).



Consequently, two CSs may cover the same part of reality but their specifica-tions may be incompatible due to some fundamental differences in theirunderlying data model theories (McBrien & Poulovassilis, 1998). Such theoreticdifferences do not derive from the outside world and do not reflect evolution ofenvironment in any way (Bézevin, 2000). Even if the data model theory is firmlyfixed, two CSs modeling the same UoD may differ. This is because many datamodel theories are “rich”, i.e., they provide alternative ways to capture andmodel a particular real-world feature (Saiedian, 1997; Knapp, 1998). Hence, areal-world feature can be modeled first in one way and later in another, even ifthere is no change in the real world. Again, such differences, commonly referredto as semantic heterogeneity or discrepancy (Kent, 1991; Tseng, Chiang &Yang, 1998), do not derive from the outside world and do not reflect evolutionof environment in any way.

Regrettably, standard data model theories such as E-R and UML come in manyvariants and can permit a real-world feature to be modeled in several ways.Moreover, these data model theories may cover aspects that we consider non-semantic, such as primary key composition. Hence, to present our results, wecannot rely on standard data model theories. Instead, we have to employ asemantic data model theory that is “essential” as opposed to “rich” to avoid thekinds of theoretic differences and heterogeneities as explained above. Mainfeatures of this data model theory are outlined in the appendix.

Issues and Controversies

Change as the CS is Being Designed

We emphasize that we focus on the operational life, not on the design phase ofthe CS life cycle. Several authors have studied the notion of design primitives(Batini, Ceri & Navathe, 1992; Fernandez & Yuan, 2000; Hartmann, 2000). InCS design, an abstracted model is created and gradually adjusted and improvedto capture the semantics of the UoD. However, our interest lies with theoperational CS. We regard design adjustments to be part of the schemadevelopment phase, and do not consider it as true CS evolution. The amount andcharacteristics of adjustments in the design phase are a hallmark of thedesigner’s ability and experience in modeling, rather than an expression of realchanges in the UoD and corresponding evolution of the operational CS.

262 Wedemeijer


Change is a Mark of Bad Design

There is general agreement that: “The CS is invaluable as a stable descriptionof the database contents” (Elmasri & Navathe, 2000). Indeed, contemporarytheories and design practices for conceptual data modeling concentrate on asingle design effort to deliver a conceptual schema once and for all. However,the implication is not that a CS, once designed, should be perfect and the needfor any change whatsoever marks it as a bad design.

The issue therefore is not to judge a CS for its number of changes, and if manychanges are seen, denounce the CS as a low-quality design in hindsight. Indeed,a CS may well be justified to go through many changes if it models a turbulentenvironment. Hence, we should study the actual changes as they occur in theCSs of operational information systems, and use that understanding to improvefuture CS designs.

Change Driven from the Real World

First principles say that the CS ought to change only if the information structureof the UoD changes. Literature has it that major business events like mergers,acquisitions and diversifications are the change drivers that cause change in theCS (ANSI/X3/Sparc, 1975; Galliers, 1993; Orna, 1999). In theory, CS changescan only be justified by true structural changes in the UoD. However, we feelthat it is too limited a view to study only justified changes in the CS. Other events,such as downsizing to another database platform, or a general change inmodeling guidelines, may present engineers with legitimate opportunities tochange the CS. Such CS changes may be unjustified, but in practice, they arequite common. The same principles also suggest that the timing of a CS changemust coincide with the change driver. However, it is our experience that someCS changes may be postponed for quite some time, while other changes mayeven precede the change in the UoD. The currency conversion to Euro is anexample where CSs have been prepared well in advance of an upcoming changein the real world.

Change of a Single Construct at a Time

Formally, every CS is composed of elementary constructs that the data modeltheory provides. Hence, change in the CS can only be effected by changing thiscomposition. For example, one can add a single “entity” construct into a CS. Onemay surmise that a complete understanding of CS changes is achieved by



analyzing the possible changes of constructs in the data model theory, a researchapproach referred to as taxonomy (Roddick, Craske & Richards, 1993).However, Brèche (1996) already pointed out the gap between “schema changesby means of primitives closely related to the respective data model,” sometimesreferred to as syntactic changes, and what he calls “advanced primitives,” i.e.,changes of a more semantic nature.

Indeed, the example of adding a single “entity” construct into a CS is fictitious:it never happens in operational systems. An entity is added only if it has somesignificance in the CS, and therefore the new entity will always be related tosomething else in the schema. We feel that an understanding of syntacticchanges only is inadequate (Liu, Chryssanthis & Chang, 1994). The shortcom-ings are in both a lack of real-world semantics, and in ignoring the impact ofchange.

Change is Data-Preserving

Authors often assume that when a CS is changed, no data ought to be lost:“Schema evolution is the process of allowing changes to schema without loss ofdata” (Goralwalla, Szafron, Tamer, Öszu & Peters, 1998). Lossless schematransformations have been extensively studied (De Troyer, 1993; Bommel,1995). However, CS evolution in an operational business environment needgenerally not be lossless. Loss of data can even be intentional, for instance whenan obsolete data construct is eliminated from the CS.

Change is the Mere Application of a Pre-DefinedSchema-Evolution Operator

Some database management systems provide evolution operators that willperform data conversions when the Internal Schema is changed. However, suchconversions will adjust the stored data to comply with the new Internal Schema,but this is done without regard for the semantics of change. It remains theresponsibility of the maintenance engineer to select suitable operators, tailorthese to the problem at hand, and execute them in the appropriate order. Thedatabase evolution operators reduce the time required to accommodate the CSchange in all data and components of the information system, but they are notfounded on CS semantics or real-world understanding that still lies with theengineer.

264 Wedemeijer


Change is Due to Schema Merging

Corporations generally use more than one information system. If there is anoverlap in their respective Universes of Discourse, then an integrated CS iscalled for to ensure a valid, complete and consistent model of the combineduniverses (Cheung & Hsu, 1996; McBrien & Poulovassilis, 1998). Remarkably,schema integration is usually discussed as a single, massive design effort (Hars,1998; Lehmann & Schewe, 2000), not as an effort to be undertaken during CSoperation. Some authors even state that: “empirical research has found moreevidence of problems than of success” (Goodhue, Kirsch, Quillard & Wybo,1992).

Problem Statement

Shortcomings of Current Approaches

The majority of current approaches for schema change are targeted towards theCS design phase. However, schema changes in the “systems developmentphase” are fundamentally different from the kinds of changes that are necessaryin the operational phase. Therefore, it cannot be assumed that such designapproaches will suit the needs of maintenance engineers. Indeed, to accommo-date a change in a running information system and database calls for differenttechniques than to change a system being developed.

Design approaches fail to systematically incorporate the knowledge of actualchanges as observed in operational CSs. The customary design approach is tocreate a CS design early in the design phase, and not to alter it thereafter.However, semantic change can and will occur in later phases of the CS lifecycle.

Theoretic approaches to schema-evolution and change taxonomies are primarilyconcerned with the potential for change that the data model theory may bringabout in the CS. They do not yield insight into the types of actual changes inoperational CSs or their complications.

CS Change in Business

Changing an operational CS is no small matter. The desired change ought to bewell understood before it is committed. The consequences of changes must be



carefully considered, not only for the stored data but for other components of theinformation system as well: existing business procedures, applications and userinterfaces, user training, etc. It is no surprise that engineers try to keep the impactof change as small as possible. In effect, they aim for an adapted CS that is anadequate model of the new UoD, but at the same time as close to the old CS aspossible. Indeed, the major difference between CS change in the operationalphase versus design is the need for data coercion. In design, no operational datahas yet been stored and hence, data coercion is irrelevant.

Business Constraints on CS Change

The business need is to minimize the disruption of information system servicesand to avoid operational problems in data handling. Therefore, CS changerequests are carefully weighed against other pressing business needs (Orna,1999). Only if the change is unavoidable will valuable business resources beallocated, and even then reluctantly, i.e., compatibility is demanded in order toreduce the need for complex data conversions and application reprogramming.

A prearranged conversion strategy ought to be followed to achieve these goals.Although it is often assumed that CS change must precede changes in the data,engineers often come up with change strategies that permit data to be coercedin advance of an upcoming CS change, or that evade data conversionsaltogether.

System Constraints on CS Change

Although the 3-Schema Architecture makes a clear distinction between thestructural level of the CS and the level of data instances, it is impossible to changeone in complete isolation of the other. Any change in an operational CS must beconducted in such a way that the correlation between these two levels issafeguarded (Ewald & Orlowska, 1993; Peters, Tamer & Öszu, 1997). Inaddition, the engineer must determine what other components of the runninginformation system may be impacted by the change. Again, changes in the CSmust well be coordinated with changes in the other components to safeguard thecorrect operation of the system.

266 Wedemeijer


Solution: Semantic Change Pattern as aTool

Notion of Semantic Change Pattern

It is our experience that many CS modifications are not new and innovative, butappear to be modeled on some basic “model to be copied” whenever appropriate.A pattern, as commonly understood in information systems engineering, is anabstracted, generalized solution that solves a range of problems with sharedcharacteristics. Gamma, Helm, Johnson and Vlissides (1995) have it that: “eachpattern describes a problem (..), and then describes the core of the solution to thatproblem, in such a way that you can use this solution a million times over, withoutdoing it the same way twice.”

We understand the notion of semantic change pattern to be: any change in theoperational CS that is coherent, has unambiguous semantics, and is accommo-dated in a single maintenance effort.

The notion of patterns is not new to the database community, however, thepatterns described in current literature concern design only. The semanticchange patterns that we will describe consider the operational life cycle phase,and account for both the level of CS semantics and the stored data. We restrict,however, to the conceptual level of the stored data. We do not digress to eitherExternal Schemas or the implementation level of the Internal Schema.

Pattern Detection

To determine Semantic Change Patterns, we cannot resort to desk studies,laboratory examples, or theoretical analysis. Some examples of patterns can befound in the literature (McLeod, 1988; Brèche, 1996). Their examples howeverare contrived by theoretical arguments, and not by abstracting actual CS changesobserved in practice. Indeed, viable patterns can only be identified in their naturalhabitat, i.e., the running business. We therefore conducted a series of casestudies, tracking a number of operational CSs and studying their changes inentities and references over time. For the sake of feasibility, changes in attributesand constraints were ignored.



Catalogue of Semantic Change Patterns

In the case studies, we found 12 semantic change patterns to occur on at leastthree occasions. This constitutes a small catalogue of semantic change patternsthat we will now describe. To fully understand a semantic change pattern, weneed to address:

• the semantics of change, i.e., the typical user needs met by the pattern,

• the syntax of the pattern, i.e., how the change in the CS is composed fromelementary schema changes, and

• the impact of change on stored data and on other components of theinformation system.

A few patterns are outlined in some detail, but due to space limitations, we cannotdescribe all patterns in full detail. Instead, we simply show the patterns as a setof diagrams: before and after the change. We add a brief description to conveythe essence of the pattern, so that the reader will be able to apply the changepatterns in a practical situation by adjusting the appropriate pattern to meet theneeds at hand. We express the diagrams in a variant of the Entity-Relationshipdata model theory, but this does not limit the validity of the patterns. Thesemantics of the change patterns will still be valid in other data model theories,the only differences being in syntax.

Append an Entity

This semantic change pattern is perhaps the most familiar one. It clearlydemonstrates schema extensibility that is often alluded to.

• The pattern applies when the relevant real world extends, or equivalently,when users perceive it to be extended. A typical example is schemaintegration: the real world is unaffected, but user perception thereof isextended and users require that extra information be captured that extendson data captured about existing real-world objects.

• The pattern syntax is to insert a new entity, and add a reference to anexisting entity that now becomes an “owner” entity. A new specializationis induced in the existing entity, i.e., the set of instances that is beingreferred to by the new member entity. Data manipulation routines must beadjusted in order to ensure referential integrity when owner instances areupdated or deleted.

• The pattern comes with little or no complications, and no conversion ofstored data is needed.

268 Wedemeijer


Superimpose an Entity

This semantic change pattern resembles the previous one syntactically. It isanother demonstration of schema extensibility, but more rarely seen.

• The need to change emerges if a new way of grouping and organizingexisting objects is perceived. In other words, users regard an existing entityto be dependent on something new, something not yet captured in the CS.Whereas the previous “append” pattern adds details, the importance of thispattern is to add new structural elements. This pattern is likely to be usedwhen the UoD is expanded, and particularly in schema merging.

• Like the previous pattern, the syntax is to insert a new entity, and to add areference. Unlike the previous pattern however, the existing entity be-comes a “member” entity.

• Impact on the data level is kept limited by defining the reference as“optional” even if it is compulsory in a semantic sense. The impact wouldbe larger if the new reference is defined as compulsory: all stored instancesmust be updated to include correct references. It becomes even moreextensive if the new reference is incorporated into the primary key: this willset off a cascade of foreign-key changes in all dependent entities.

Figure 2. Append an entity

Figure 3. Superimpose an entity



Move Attributes Into a New Entity

In design, the creation of a new entity from a coherent set of attributes is acommon normalization procedure. The same change in maintenance may becalled “belated normalization”. While this semantic change pattern resemblesthe previous ones in syntax, the difference is that there is no extension of theUoD, but only a change in its information structure.

Connect by Reference

This semantic change pattern exactly matches an elementary change in anytaxonomy, i.e., to add a single construct to the CS. The amount of real-worldknowledge captured in the CS is extended, but only marginally so. The diagramshows the insertion of an optional reference, i.e., the connection is betweenspecializations. This is the common variant. If the new reference were compul-sory, then impact of change is larger as referential integrity must be ensured.

Although the pattern is attractively simple, it is not often applied. Apparently, thebenefit of having the reference explicitly represented in the CS is rarelyconsidered worthwhile.

Figure 4. Move attributes out into a new entity

Figure 5. Connect by reference

270 Wedemeijer


Impose a Reflexive Reference

This semantic change pattern resembles the connect-by-reference pattern, butit differs in semantics and applicability. Self-referring links between instancesare often known and noted by users even if the designers have not included thereflexive reference in their CS designs. Therefore, core entities should beexamined for the existence of a reflexive relationship.

Connect by Intersection

We borrow our terminology from the concept of “intersection-record” inclassical networked databases. Such records served a rather technical purposeof establishing a many-to-many link in the database. This pattern is named afterit because of the striking similarity in appearance. Notice how this pattern againresembles the Append-an-entity pattern syntactically, while differing in seman-tics. The diagram shows an interesting variant of the pattern where not one, buttwo “intersection entities” are inserted to constitute the reference.

Figure 6. Impose a reflexive reference

reflexive

Figure 7. Connect by intersection



Eliminate a Dependent Entity (Cluster)

On the CS level, elimination is the reversal of the Append pattern, however, noton the data level. There are numerous reasons why information in the CS mayturn obsolete, but obsolescence alone does not constitute a need to change theCS. Indeed, eliminations are rarely committed as soon as possible, but are oftenpostponed until maintenance is done for some other reason.

Redirect a Reference to Owner Entity

Although a reference may be redirected to any arbitrary entity, we only saw apattern where it is redirected towards an owner entity, i.e., it moves higher in theCS hierarchy. This probably has to do with implementation by weak entity-keys,where redirection is achieved simply by using only a part of the foreign-key. Itis remarkable that we could not clearly establish a change driver for this pattern.We believe that it has to do with a change of perception, if engineers and usersfeel that the current way of modeling a reference can be simplified.

Figure 8. Eliminate a dependent entity (cluster)

Figure 9. Redirect a reference to owner entity

272 Wedemeijer


Extend Entity Intent

Entity intent is its definition, i.e., the accurate description of relevant real worldobjects in the UoD that it is supposed to record. To extend the intent is to allowmore real world objects to be recorded by the entity. For example, a “car” entitymay be extended to also record motorcycles.

This pattern is a clear illustration of extensibility. The semantic change is not veryevident in the CS diagram. The extension is often left implicit, or it may even gounnoticed. Nonetheless, the CS is changed and the extended entity will structur-ally have more instances on record. Also, instances may be kept on record thatwere previously deleted, e.g., when a “partner” entity is extended to capture ex-partners as well.

Restrict Entity Intent

This pattern is the opposite of the previous pattern that extends entity intent.Fewer instances will be recorded, i.e., some particular specialization is dropped.Often one or more attributes, often the optional ones, can also be dropped. Thediagram shows an example where two entities are restricted at the same time.The reference between the entities is restricted accordingly.

Figure 10. Extend entity intent

Figure 11. Restrict entity intent



Promote a Specialization

A particular concept is perceived to be so much more important and differentfrom similar ones that users want to have it explicitly modeled in the CS. Theformer generalization does not become invalid, it just becomes less important inthe CS. However, the generalization may completely disappear from the CS ifthis pattern is applied repeatedly. Users perceive the new CS as a better modelbecause it is more explicit, easier to understand. In particular, access to the datais easier, as users no longer need to sieve out the irrelevant information of otherinstances.

Syntactically, the pattern resembles a “horizontal fragmentation” or “tabledivide” operator. It takes a generalized entity, divides it into two (or perhapsmore) independent entities, and relocates data instances to exactly one of thenew entities.

Relax a Reference

Relaxation comes in two flavors: either a 1:1 reference is relaxed to N:1cardinality, or an N:1 reference is relaxed to optional. The diagram shows the

Figure 12. Promote a specialization

Figure 13. Relax a reference

274 Wedemeijer


latter variant. This semantic change pattern is not very frequent. The fewexamples that we observed in our cases are all associated with minor CS designflaws that emerged in operation.

Discussion

Validity

Two arguments underpin the validity of the described patterns. First, thesepatterns are based on real changes in operational Conceptual Schemas seen toevolve in the business environment. We extracted the catalogue of 12 semanticchange patterns from a series of case studies, where we established that thisdozen patterns accounts for over 75% of the observed semantic changes.Evidently, these patterns embody proven practices that can be encountered in thebusiness environment.

Second, we have found that practitioners readily recognize these patterns, andwe take this as another mark that the notion of Semantic Change Pattern haspractical value and significance. In fact, we are convinced that the listed patternsare already known and used in practice, but have failed to be recognized as animportant tool for maintenance.

Absent Patterns

We remind the reader that we excluded attributes and constraints from ourinvestigations, so no change patterns involving attributes and constraints are tobe expected. For entities and references however, certain patterns may havebeen expected, such as:

• Eliminate a superimposed entity,

• Redirect a reference to an arbitrary entity,

• Restrict a reference; either from optional to compulsory, or from N:1 to 1:1cardinality,

• Generalize entities into one unified entity, in particular to enfold a hierarchicstack of entities into one entity with a reflexive reference (Veldwijk, 1995),

• Reify a reference into an entity.



One reason for their absence may be that we have not explored enough cases,and the semantic change patterns have not yet emerged. However, why did weexpect to see these patterns in the first place? Expectations are guided by whatis advocated as good design practices. Please bear in mind that most literaturefocuses on the design phase, and it cannot be assumed that patterns intended fordesign will meet the needs of maintenance engineers working in a turbulentbusiness environment. We already mentioned how the conservative tendency tosafeguard current investments in running information systems generally pre-vents extensive restructuring of the CS. We consider this call for compatibilityto be a major reason why theoretically attractive patterns like generalization andreification are unfit for maintenance. A good pattern for design is unacceptablein maintenance if it causes incompatibilities or a massive impact of change.

Apply a Semantic Change Pattern

Semantic change patterns as discussed above provide the maintenance engineerwith a proven way to resolve a need for change in the CS, whatever the reasonfor change, as we did not restrict our search for semantic change patterns tojustified changes only. Still, the patterns have yet to find their way into thecommon body of engineering knowledge. The notion of semantic changepatterns is novel and as yet we cannot show an example where a pattern wasselected and named explicitly before being applied. However, we believe thatengineers do employ the patterns, albeit implicitly, and without recognizing thepattern beforehand.

Real changes in user requirements are rarely straightforward and simple, and wedo not contend that every demand for change can be met by a single semanticchange pattern. However, the engineer, when faced with a general desire forimprovement, can use the patterns as partial solutions and combine them. Theengineer can select appropriate patterns, justify the choice to stakeholders, adaptthe pattern to the needs at hand, and proceed to make the desired CS change ina correct way. In this way, comprehensive solutions can be reached to meet newuser requirements in a best possible way.

We surmise that semantic change patterns can and will assist engineering effortsin all phases of the CS life cycle.

276 Wedemeijer


Future Trends

At the time of writing, the catalogue of Semantic Change Patterns outlined in thischapter is bound to be an incomplete set. However, completeness has not beenour aim. We want to outline realistic patterns of semantic change for the engineerto learn and copy from.

As the importance of schema maintenance will continue to increase, researchersand practitioners will detect more and more change patterns in operationalenvironments. Hence, the catalogue will continue to be extended. Moreover, wehope to see semantic change patterns of attributes and constraints added to thecatalogue.

Pro-active use of the patterns in the design phase of the CS life cycle allows adesigner to experiment with various kinds of alterations in the design proposal,and to get a feeling how the proposed CS will react to likely changes inrequirements. This may uncover flaws in the design that the designer can correctby applying the pattern.

The semantic change patterns can also be useful in the reverse-engineering ofa legacy CS. Knowing common patterns will help to understand the evolutionhistory and hence will ease the recovery of the schema.

Finally, the semantic change patterns offer an excellent opportunity to replacethe schema-evolution operations of today’s database management systems withdata conversion solutions that are semantically meaningful. This will providemaintenance engineers with easy to configure data conversion routines that arewell coordinated with the corresponding CS changes.

Conclusions

This chapter introduced the notion of Semantic Change Patterns and outlined acatalogue of a dozen patterns relevant in Conceptual Schema evolution. Seman-tic change patterns have their value in enabling the graceful evolution of databaseschemas. The patterns are targeted toward adjusting Conceptual Schemasemantics and database contents in accordance with changing user perceptionof the real world and information needs in the business environment.

Changing an operational CS is no small matter. Current business procedures,user interfaces, applications, etc., all have to be reviewed to determine the full



impact of change, and the possible consequences for the stored data must alsobe carefully weighed. As enterprises try to keep the impact of change as smallas possible, the adapted CS is required to be a good model of the new UoD, andat the same time to be “as close to the old CS as possible”. This usually translatesinto the demand for compatibility, thus reducing the need for complex dataconversions and application reprogramming.

The best argument for validity of the semantic change patterns is that these arebased on actual changes observed in operational Conceptual Schemas evolvingin the live business environment. The dozen patterns that we extracted from aseries of case studies, accounts for more than 75% of the observed semanticchanges. In other words, maintenance engineers apply the patterns, withoutthem having been recognized before.

Much has yet to be learned about the relation between organizational need forinformation and the systems -or indeed the Conceptual Schemas- that deliver it.The literature points out change drivers such as organizational change, mergersand diversifications, Business Process Reengineering projects, and ongoinginnovations in information system technology and databases. How such changedrivers are related to specific changes taking place in Conceptual Schemas at thecore of operational information systems is not yet well understood. We believethat the notion of semantic change pattern is a significant step towards thatunderstanding.

References

ANSI/X3/Sparc Special Interest Group on Management of Data. (1975). StudyGroup on Data Base Management Systems Interim Report. ACM-SIGMODNewsletter, 7(2).

Batini, C.W., Ceri, S. & Navathe, S.B. (1992). Conceptual Database Design:An Entity-Relationship Approach. CA: Benjamin/Cummings Publishing.

Bézevin, J. (2000). New Trends in Model Engineering. Proceedings of theIRMA2000 International Conference. Hershey, PA: Idea Group Publish-ing, 1185-1187.

Bommel, P. van. (1995). Database Optimization: An Evolutionary Ap-proach. Dissertation. Katholieke Universiteit Nijmegen, The Netherlands.

278 Wedemeijer


Brèche, P. (1996). Advanced Primitives for Changing Schemas of ObjectDatabases. CAiSE’96 Conference Advanced Information Systems Engi-neering. Springer Verlag, LNCS 1080, 476-495.

Cheung, W. & Hsu, C. (1996). Model-assisted Global Query System for MultipleDatabases in Distributed Environments. ACM Transactions on Informa-tion Systems, 14(4), 421-470.

De Troyer, O. (1993). On Data Schema transformations. Dissertation, TilburgUniversity, The Netherlands.

Elmasri, R. & Navathe, S.B. (2000). Fundamentals of Database Systems:Third edition. New York: Addison-Wesley.

Ewald, C.A. & Orlowska, M.E. (1993). A Procedural Approach to SchemaEvolution. CAiSE’93 Conference Advanced Information Systems Engi-neering. Springer Verlag, LNCS 685, 22-38.

Feldman, P. & Miller, D. (1986). Entity Model clustering: Structuring a datamodel by abstraction. The Computer Journal, 29(4), 348-360.

Fernandez, E.B. & Yuan, X. (2000). Semantic Analysis Patterns. ER’00Entity-Relationship Approach. Springer Verlag, LNCS 1920, 183-195.

Galliers, R.D. (1993). Towards a Flexible Information Architecture: IntegratingBusiness Strategies. Journal of Information Systems, 3(3), 199-213.

Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1995). Design Patterns:Elements of Reusable Object-Oriented Software. New York: Addison-Wesley.

Goodhue, D.L., Kirch, L.J., Quillard, J.A. & Wybo, M.D. (1992). Strategic Dataplanning: Lessons from the field. MIS Quarterly, 11-34.

Goralwalla, I.A., Szafron, D., Tamer Öszu, M. & Peters, R.J. (1998). Atemporal approach to managing schema evolution in object databasesystems. Data & Knowledge Engineering, 28(1), 73-105.

Hars, A. (1998). Natural Language-enabled Data Modeling: Improving Valida-tion and Integration. Journal of Database Management, 9(2), 17-25.

Hartmann, S. (2000). Decomposition by Pivoting and Path CardinalityConstraints. ER’00 Entity-Relationship Approach. Springer Verlag, LNCS1920, 126-139.

Kent, W. (1991). Solving domain mismatch and schema mismatch problemswith an object-oriented database programming language. VLDB’91,Morgan-Kaufmann, 147-160.

Kim, Y.G. & March, S.T. (1995). Comparing data modeling formalisms.Communications of the ACM, 38(6), 103-112.



Knapp, J. (1995). Uniqueness Conditions for ER Representations. ER’95Entity-Relationship Approach. Springer Verlag, LNCS 1021, 296-307.

Lehman, M.M. & Belady, L.A. (1978). Laws of Program Evolution, Rules andTools for Programming Management. Proceedings of the InformationTechnology Conference, “Why Software Projects Fail”. Reprinted in“Program Evolution” (1985). Academic Press.

Lehmann, T. & Schewe, K.D. (2000). A Pragmatic Method for the integra-tion of Higher-Order ER Schemata. ER’00 Entity-Relationship Ap-proach 2000, Springer Verlag, LNCS 1920, 37-51.

Liu, C.T., Chryssanthis, P.K. & Chang, S.K. (1994). Database SchemaEvolution through the Specification and Maintenance of Changes onEntities and Relationships. ER’94 Entity-Relationship Approach. SpringerVerlag, LNCS 881, 132-151.

McBrien, P. & Poulovassilis, A. (1998). Formalisation of semantic schemaintegration. Information Systems, 23(5), 307-334.

McLeod, D. (1988). A learning-based approach to metadata evolution inobject-oriented database systems. Advances in Object-Oriented Data-base Systems. Springer Verlag, LNCS 334, 219-224.

Orna, L. (1999). Using knowledge and information to manage and masterchange. Managing Information, 6(1), 42-45.

Peters, R.J. & Tamer Öszu, M. (1997). An axiomatic model of dynamic schemaevolution in objectbase systems. ACM Transactions on Database Sys-tems, 22(1), 75-114.

Roddick, J.F., Craske, N.G. & Richards, T.J. (1993). A Taxonomy for SchemaVersioning based on the Relational and Entity Relationship Models.ER’93 Entity-Relationship Approach. Springer Verlag, LNCS 823, 137-148.

Saiedian, H. (1997). An evaluation of extended entity-relationship model.Information & Software Technology, 39, 449-462.

Tseng, F.S.C., Chiang, J.J. & Yang, W.P. (1998). Integration of relations withconflicting schema structures in heterogeneous database systems. Data &Knowledge Engineering, 27(2), 231-248.

Veldwijk, R. (1995). Tien Geboden Voor Goed Database Ontwerp. DatabaseMagazine (in Dutch).

Wedemeijer, L. (1999). Design the flexibility, maintain the stability ofConceptual Schemas. CAiSE’99 Conference Advanced Information Sys-tems Engineering. Springer Verlag, LNCS 1626, 467-471.

280 Wedemeijer


Wedemeijer, L. (2002). Exploring Conceptual Schema Evolution. Disserta-tion. Delft University, The Netherlands.



Appendix: Data Model Theory

As a data model theory, we employ a variant of the Entity-Relationship datamodel theory that has been tailored to be both “semantic”, i.e., stripped of non-conceptual features, and “essential”, as opposed to “rich”. However, it is beyondthe scope of this chapter to discuss this variant in full detail. We refer toWedemeijer (2002). Main features of our data model theory are:

• By definition, an entity is an aggregate of attributes. The entity extent orpopulation is the current set of instances recorded in the database. Theentity intent is its definition, i.e., the accurate description of relevant realworld objects in the UoD that it is supposed to record.

• The structure of an entity is its references and specializations, as definedby the modeling primitives of entity aggregation and generalization.

• A relation of a real-world object is its property to be related to one otherreal-world object within the UoD. Relations in the real world are capturedas references in the CS. The entity modeling the object with that propertyis called the referring, or member entity. The entity modeling the relatedobject is called the referred, or owner entity.

For all clarity: objects and relations are encountered in the Universe ofDiscourse, whereas entities, instances and references are constructs that existin the Conceptual Schema.

Graphical Conventions

We use the following graphical conventions that make for compact and easy toread diagrams with a hierarchic, top-down structure:

• Rectangles depict entities. An enclosed rectangle depicts a specializa-tion, a diagramming technique borrowed from Venn diagrams in set theory.The is-a injective reference is evident from the inclusion.

• Arrows depict the references between entities. The arrow points from themember entity upwards to the owner, with N:1 cardinality. This notation isused to suggest some “pointer” attribute in the member entity.

• References may have 1:1 cardinality; i.e., each owner instance is referredto by at most one member instance. This is depicted by omitting the headof the arrow.

282 Wedemeijer


• A reference is compulsory if the arrow is drawn from the boundary of themember entity. The reference is optional if the arrow is drawn from theinterior, suggesting it to be coming from some specialization within themember entity, whether or not that specialization is drawn.

• To avoid cluttering the diagrams, we abstain from depicting attributes andconceptual constraints.

Model Transformations in Designing the ASSO Methodology 283


Chapter XIII

Model Transformationsin Designing the

ASSO MethodologyElvira Locuratolo, ISTI, Italy

Abstract

ASSO, an innovative conceptual methodology which combines features ofdatabase design with the formal method B, has been defined in order toensure the flexibility of semantic data models, the efficiency of objectmodels and design correctness. Starting from a directed acyclic graph ofclasses supported by semantic data models, a formal mapping generatesclasses supported by object models. The classes supported by semanticdata models are then extended with aspects of behavioural modelling: arelationship with the B model is established and the consistency proofs ofthe whole schema are reduced to small obligations of B. This chapterevidences how ASSO is based on model transformations. These have beenintroduced with various purposes: to map semantic data models to objectmodels, to integrate static and dynamic modelling, to link formal andinformal notations and to relate the conceptual schema and the logicalschema of the methodology.

284 Locuratolo


Introduction

Methodologies used in designing database applications can be based on informalmodels that, although easy to understand, are unable to cover both static anddynamic aspects of modelling in an integrate way and may cause inconsistencies.Further, they can be inadequate to guarantee that the schema supported by thedatabase system satisfies the requirements specified at conceptual level. Finally,they cannot ensure the coexistence of two quality requirements classicallyconflicting, i.e., flexibility in reflecting the changes occurring in real life on theschema and efficiency in accessing information.

B (Abrial, 1996), a formal method of software engineering, uses mathematicalnotations for modelling static and dynamics and for performing consistencyproofs. The refinement of B, supported again by proofs, allows the derivation ofcorrect implementations; however, the direct use of B for developing databaseapplications presents some shortcomings since B lacks the high level abstractionmechanisms used for modelling database schemas and its refinement has notbeen specifically designed for obtaining efficient database implementations.

ASSO (Castelli & Locuratolo, 1995; Locuratolo, 1997; Locuratolo & Matthews,1999) is an innovative methodology for the achievement of quality requirements,which combines features of database design with the B-Method in order toensure easiness in schema specifications, flexibility in reflecting the changesoccurring in real life on the schema, consistency between static and dynamicmodelling, correctness of implementations and efficiency in accessing informa-tion. Formality in ASSO is completely transparent to the designer until he decidesto make proofs.

Designing formal environments for the specification and the development ofdatabase applications is currently an interesting topic of research (Mammar &Laleau, 2003). This is because the growing use of databases in variousapplication domains where economical interests require a certain degree ofsafety, e.g., e-business or financial systems, favours the call for the integrationof databases and formal methods (Laleau, 2000, 2002).

ASSO results from the intuitions of researchers or students with backgroundscoming from different disciplinary areas. MetaASSO (Locuratolo, 2002), theapproach employed to design ASSO, highlights these intuitions while providinga high-level description of interacting components, called methodological tools.The following methodological tools have been designed to achieve quality inASSO:

the Revisited Partitioning, a formal method working on staticaspects of database conceptual schemas; the Structured DatabaseSchema, a formal conceptual model which integrates consistently



static and dynamic aspects of modelling whilst still allowing thePartitioning applicability; the Relationship between ASSO and B,link established between a formal methodology designed atconceptual level and a formal method designed at a lowerabstraction level.

The Revisited Partitioning (Locuratolo, 1998; Spagnolo, 2000) maps a graph ofclasses supported by semantic data models to a graph of classes supported byobject models (Cardenas & McLeod, 1990). This method achieves the flexibilityof semantic data models and the efficiency of object models while guaranteeingthe design correctness. The model on which the Revisited Partitioning works isextended with aspects of behavioural modelling; proof obligations for provingthe schema consistency are given. The model evolution defines the StructuredDatabase Schema (Locuratolo, 1997). This model has been designed from onehand with the intent to establish a relationship with the model supported by theB-Method and from the other with the intent to still allow the RevisitedPartitioning applicability. The Structured Database Schema integrates thespecification of both structural and behavioural information at a high abstractionlevel. A correct translation from the Structured Database Schema to the Bmodel (Locuratolo & Matthews, 1998) puts into evidence that many formaldetails explicated at the abstraction level of B are implicitly specified at theabstraction level of ASSO and that expensive proof obligations to proveconsistency at the B level are reduced to a set of cheap obligations at the ASSOlevel.

Support tools for B, such as the B-toolkit (B-Core), can be used to prove theASSO schema consistency; however, practical benefits (Locuratolo & Matthews,1999) can be achieved constructing an ASSO toolkit based on the B-toolkit.

This chapter aims at evidencing how the design of ASSO is all based on correctmodel transformations and how these have been introduced with variouspurposes: for mapping semantic data models to object models; for integratingstatic and dynamic modelling, for linking formal and informal notations, forrepresenting information at different levels of abstraction, and for linkingtogether the conceptual and the logical models of the methodology. The theoryis clarified by examples. The innovative aspects of ASSO are evidencedcomparing the methodology with related works.

The chapter is organised as follows: the following section gives a backgrounddescription and then illustrates the mapping from semantic to object models.Next, the chapter describes the model transformations resulting in ASSO. Thechapter then illustrates the relationship between the ASSO model and the Bmodel. Conclusions and future developments are covered in the final section.

286 Locuratolo


Background

This section highlights some aspects of database design and some aspects of theB-Method which can be usefully exploited for comparing ASSO with relatedworks.

Database Design

The database design process (Elmasri & Navathe, 1997) consists of two parallelactivities: the first involves the content and the structure of data, whereas thesecond relates to the design of database applications. Traditionally, databasedesign methodologies have primarily focused on the first of these activities,whereas software design has focused on the second. It is being recognised bydatabase designers and software engineers that the two activities should proceedin parallel and design tools are increasingly combining them. ASSO comprises aphase of conceptual database design and a phase of logical design. The goal ofthe former phase is to produce a conceptual schema, i.e., a high-level descriptionof the database structure and behaviour independent from the particular Data-base Management Systems (DBMS) which will be used. The goal of the latterphase is to map the conceptual schema from the high-level model into the lower-level model of a chosen type of DBMS.

The data-driven methodologies (Batini, Ceri & Navathe, 1992) focus mainly onthe definition of data and their properties. The applications, which access andmodify the database, are a complement of the static description. The data-drivenmethodologies generally consist of two steps: the conceptual schema construc-tion and the logical schema generation. In order to make the conceptual schemaeasy to be understood, high level abstraction models, such as Semantic Datamodels (Cardenas & McLeod, 1990) or Entity-Relationship Models (Chen,1976), are employed with a diagrammatic representation. The abstractionmechanisms of these models closely resemble those used in describing theirapplications. In order to represent the complementary dynamic aspects, state-based and data-flow models are employed; however, as the models employed torepresent statics and dynamics are either informal or have non-integratedformalisations, it is not possible to prove that the specified operations preservethe database consistency. The construction of the conceptual schema is followedby the generation of the logical schema. Within this step of design, informationspecified in the conceptual schema is represented in terms of relational models.The generation of the logical schema is a complex step since the mapping processis not isomorphic and there is the possibility of introducing errors. When the data-driven methodologies are used, the high-level description of the database given



in the conceptual schema is often used as documentation of the implementedschema; however, as the correctness is not guaranteed, the application user mustrefer to the low level logical schema in any case.

ASSO differs from the approach of Batini et al. since the Structured DatabaseSchema is a formal model, which integrates structure and behaviour guarantee-ing consistency. The conceptual schema of ASSO is correctly mapped into thelogical schema. The design correctness renders it possible to develop databasesystems that permit writing applications by referring to the conceptual schemarather than to the logical schema. The conceptual schema is supported by a datamodel, which ensures semantic expressiveness and flexibility, whereas an objectmodel supporting the logical schema ensures efficiency.

The object-oriented methodologies (Coad & Yordon, 1991; Bernard, 1993;Booch, 1994; Rumbaugh, Booch & Jacobson, 1999) proposed within the soft-ware engineering area are the more natural way to develop object systems,which nowadays are very popular because of the efficiency they provide. Thesemethodologies focus on the identification and organisations of the objects, whichcompose an application. The object-oriented methodologies employ the samemodel along the whole life cycle. This renders the mapping smoother, thusreducing the risk of introducing errors. Object-oriented methodologies, however,have always been very week when dealing with data design. They approach datadesign at a late stage of the software development process, after the consolida-tion of object-oriented specifications, by gathering data descriptions from varioussources and then assembling data definitions from them. An example ofmethodology which overcomes this problem is IDEA (Ceri & Fraternali, 1997).This methodology takes advantages from the object-oriented concepts, but it isdriven by the database technology: data design comes first and application designfollows. The generalisation hierarchies of IDEA do not require transformationsin the passage from analysis to design, because they are supported by a high-levelspecification language, called Chimera, and by the object model with exactly thesame meaning. Generally, the generalization hierarchies are total and exclusive,so that, differently from ASSO, the objects of a superclass are partitioned intothe objects of the subclasses.

B-Method

The B-Method (Abrial, 1996) is a formal method of consolidated industrialinterests. The approach consists of two phases: first a consistent and completeformal specification is constructed from informal requirements; then steps ofrefinement are applied until a target program is derived. B is based on a model,called B-Machine, which permits both the static and the dynamic aspects of the

288 Locuratolo


systems to be specified within the same formal framework. A B-Machinedefines a state as a mathematical data model, and a set of operations, whichmodify data and provide results as an animation of the data model. The staticaspects of the systems are specified by listing variables and by writing propertiesof the variables in the invariant. The invariant is formalised using first order logicand set theory notation, whereas the operations, including a special operation,called initialisation, specify the dynamic aspects of the system. These areformalised using the generalised substitution language. Dynamic modelling ispowerful enough to represent pre-conditioned operations, i.e., state transfor-mations which can be activated only when certain conditions are met; partialoperations, i.e., transformations which can be defined only on a subset of thestate space and non-deterministic operations, i.e., transformations from onestate to a state chosen among a set of possible ones. A specification is consistentif the initialisation establishes the invariant and if each operation preserves theinvariant. First order logic formulas, called proof obligations, are proved inorder to guarantee the model consistency. Analogously, refinement proofobligations are proved in order to ensure the design correctness.

Specifying a database application with the B notation is a tedious process sincemany properties implicitly declared using the database conceptual languages(Albano, Cardelli & Orsini, 1985; Jarke, Mylopulos, Schmidt & Vassiliou, 1992)must be explicated. Further, the consistency proofs are very expensive (Castelli& Locuratolo, 1994). Approaches to object-oriented design within B have beenproposed (Facon, Laleau & Nguyen, 1996; Shore, 1996). ASSO differs fromthese approaches, as a conceptual level and a logical level have been linkedtogether: specifications in ASSO are written using a formal notation whichexploits the concepts of class and is-a* relationship, i.e., the classic is-arelationship extended with a behavioural specialization constructor. The proofsof inherited transactions are avoided and only a restricted number of obligationsneed to be proved (Andolina & Locuratolo, 1997). The Revisited Partitioningtransformations are steps of correct refinements, which does not require proofs.Refinement in ASSO is very promising since conceptual schema specificationsare transformed into logical schema specifications supported by object models(Locuratolo & Matthews, 1999). This differs from the most recent proposals ofdatabase applications refinements, which are implemented using the relationaldatabase model (Mammar & Laleau, 2003).

A correct translation from the Structured Database Schema into modelssupported by B shows that B can model a whole conceptual schema (Locuratolo& Matthews, 1998). Support tools for B, such as the B-toolkit (B-Core), can beused to prove the ASSO schema consistency. When the designer wishes tocheck the consistency of his specification, he invokes the automatic translationand can use the B proof obligation generator to prove it. However, when anASSO toolkit based on the B-toolkit is constructed, the generation of nonessen-



tial obligations required to be proved in B can be avoided, as well as the reductionof the essential obligations to small obligations is obtained (Locuratolo &Matthews, 1999).

The innovative aspects of ASSO result from correct model transformations. Thenext section describes the differences between semantic and object models.

Semantic and Object Models

Semantic data models and object systems (Cardenas & McLeod, 1990) havesimilar mechanisms of abstraction; however, while semantic data models havenot been implemented efficiently (Nixon & Mylopoulos, 1990), object systemshave reached a remarkable level of efficiency; on the contrary, while semanticdata models are appropriate for conceptual design, object models can displayserious shortcomings in their ability to describe the dynamic nature of the realworld entities (Richardson, 1991). Semantic data models enhance flexibility,whereas object models enhance efficiency (Cardenas & McLeod, 1990). Thelink between semantic data models and object systems is a means to achieve bothof the conflicting requirements of flexibility and efficiency (Locuratolo &Rabitti, 1998).

In order to clarify the differences between semantic and object models, let usrefer to a graph (such as that of Figure 1a) which can be supported by bothsemantic data models and object systems. This graph, called conceptual classes(Locuratolo & Rabitti, 1998), is supported by a semantic data model, if thefollowing properties hold:

• Classification: each node of the graph is a class. A node coupled with anis-a link is a specialised class. In Figure 1a there are: the class person withattribute income, the class employee with attribute salary, the classstudent with attribute identifier, the specialised class employee and thespecialised class student;

• Inheritance: a specialised class (such as the specialised class employee)inherits all the attributes from the higher level classes and may haveadditional attributes. As an example, the specialised class employeeinherits the attribute income from the class person and has the additionalattribute salary;

• Object inclusion: the objects of a specialised class are object subsets ofhigher level classes. As an example, the employee objects are a subset ofthe person objects.

290 Locuratolo


The graph of Figure 1a, in the following called logical classes, is supported byan object system if, besides the above properties of classification, inheritanceand object inclusion, there is also the restriction that each object instancebelongs to one and only one class. As a consequence, in the logical classes,the object inclusion property can be only indirectly enjoined, i.e., as thespecialised class employee inherits all the attributes from the class person, theclass employee can be considered as enclosed in the class person, but the setsrepresenting the object instances of the two classes are really two disjoint sets.

The object intersection of the conceptual classes in Figure 1a is represented inFigure 1b, whereas the object intersection of the logical classes is representedin Figures 1c and 1d. In Figure 1b the intersection between the object instancesof the class student and of the class employee may be not empty, whereas inFigure 1c no object instance can belong simultaneously to both the class studentand class employee. This is allowed only in the case of multiple inheritances, i.e.,when the subclass student·employee belongs to the graph. Figure 1d representsthis last case evidencing that the object instances, which are simultaneouslystudent and employee, define a class, the class student·employee, which isenclosed indirectly in both the class student and the class employee.

Figure 1. Conceptual and logical classes

Person

Person

income

Student Employee

Employee

Is-aIs-a

salary

1.a

1.b

Studentidentifier

Person

Student Employee

Person

Student EmployeeStud_Empl

1.c

or

1.d



The following properties make the difference between semantic and objectmodels:

• Semantic data models: each object instance can belong to any class of thegraph. This enhances flexibility while limiting efficiency.

• Object models: each object instance belongs to one and only one class ofthe graph. This enhances efficiency while limiting flexibility.

In order to show how object models limit the flexibility in reflecting the changesoccurring in real life, let us suppose that the student John becomes an employee.In this case, the corresponding object instance must be removed from the classstudent and must be inserted into a class student•employee. If John completeshis studies later on, the corresponding object instance must be removed from theclass student•employee and must be inserted into the class employee. On thecontrary, in semantic data models, the object instance corresponding to John canbe inserted into the class employee when the student John becomes anemployee and can be removed from the class student when John completes hisstudies.

The Revisited Partitioning maps conceptual classes into logical classes linkingfeatures of formal and informal methods. This method is correct, i.e., theobjects of the obtained classes are all and only those of the original conceptualclasses and each of them has all and only the original declared attributes. Themethod is complete, i.e., it generates all the classes implicitly enclosed in theconceptual classes.

The Revisited Partitioning is composed of two phases, called representationand decomposition, respectively. The former permits describing the conceptualclasses, whereas the latter permits decomposing them while reconstructinghierarchies supported by object systems. The logical classes represented inFigure 1d encloses one class more than the original conceptual classes repre-sented in Figure 1b. The next section describes the model transformationsresulting in ASSO.

Structured Database Schema

The Structured Database Schema (Locuratolo, 1997, 2002) is a model thatextends the conceptual classes on which the Revisited Partitioning works. It hasbeen designed on the one hand with the intent to still permit the applicability ofthe Revisited Partitioning and on the other with the intent to establish arelationship between ASSO and B, a formal method of consolidated industrial

292 Locuratolo


interests. The Structured Database Schema is based on the concepts of classand is-a* relationship between classes. In the following their definitions aregiven:

• Definition (class): A class is a tuple (name, Att, Const, Op) where nameis a term connoting the class name and denoting the class objects. The termname, called class extension, represents a subset of a given set. Att is afinite set of terms called attributes; each of them is defined as a functionfrom the extension name to either a given set or the extension of anotherclass. Both extension and attributes define the class state variables,whereas the predicate, which formalises their definitions, is called classconstraints. Const is a predicate on the class state variables, whichformalises a set of properties, called class application constraints. Op isa finite set of operations defined as functions from predicates establishingthe class constraints to predicates establishing the class constraints. Aspecial operation, called initialisation, belongs to Op. This associatesinitial values establishing the class constraints with the state variables.

The concept of class extends that provided by the database conceptual lan-guages with application constraints and operations. The extension has beendesigned in order to reflect some features of the model supported by B: theoperations have first been designed as basic operations, i.e., operations that addobjects, remove objects, modify attributes or let the class unchanged, and havethen been enriched with constructors, recursively applied to the basic operations.The operations define pre-conditioned, partial and non-deterministic trans-formations.

• Definition (is-a* relationship): If class name is in is-a* relationship withclass root then the specialized class name is defined:

• the objects of the specialised class name are a subset of theobjects of class root.

• The specialised class name inherits both attributes and opera-tions from class root; it has specific operations and may havespecific attributes.

If a class name is in is-a* relationship with a class root, then an inheritedoperation is defined as an operation of the class root restricted to the class name.Similarly to attributes, the inherited operations are not specified on the concep-tual schema. The initialisation and the operations that insert objects are alsoinstantiated on the class name. These two last specific operations on the class



name are called specialisation. Other specific operations on the class name arepossible.

The two definitions of class and is-a* relationship allow introducing the followingdefinition of Structured Database Schema.

• Definition (Structured Database Schema): A Structured DatabaseSchema is a connected acyclic graph whose nodes are classes and whoselinks are is-a* relationships between classes.

The definition of Structured Database Schema as a graph has been given in orderto allow the applicability of the Revisited Partitioning, after steps of behaviouralrefinement, which abolish the non-determinism and weaken the pre-condition-ing. The next section presents an example of conceptual schema specification,a step of behavioural refinement and a step of Revisited Partitioning.

Example: The following syntactic forms are used to specify a schema supportedby the Structured Database Schema (Locuratolo, 2002):

• Class name1 of GIVEN-SET with (att-list; const; op-list)

• Class name2 is-a* name

1 with (att-list; const, op-list)

The former is the basic constructor used to specify the root class of a StructuredDatabase Schema. The latter is used to specify the remaining classes. Withinthese forms, name

1 and name

2 denote the class names; att-list, const and op-list

denote respectively the attributes, the application constraints and the operationlist of the class name

1 in the former specification and of the class name

2 in the

latter specification. The class and the is-a constraints are implicitly specified withthe class constructors.

Figure 2 presents the specification of the conceptual schema. This specificationdescribes information about:

• a set of persons and their income,

• a subset of working persons and their salary,

• a subset of students and their identifiers.

The income of each person is greater than or equal to 1,000; the salary of eachemployee is greater than or equal to 500; each student has a unique identifier.

Information is added when a new person is inserted in the database. This isspecialised both when the person is employed and when the person becomes astudent.

294 Locuratolo


Information is removed from the database when a person dies.

The employee class (resp. student class) includes the init.employee (resp.init.student) and the new.employee (resp. new.student) specialisation. No otherspecific operation has been specified.

The given Conceptual Schema shows that the specifications supported by theStructured Database Schema provide the advantages of both formal andinformal notations while exhibiting the quality features of the object-orientedstyle. Similar to the informal specifications written using the friendly databaseconceptual languages, ASSO allows the implicit specification of many detailsexplicitly specified by the formal notations. But, as opposed to the informalnotations, the ASSO specifications permit some properties of the model, such asits consistency, to be proved. Further, the ASSO notation is powerful enough torepresent pre-conditioned, partial and non-deterministic operations that aregiven at an abstraction level higher than the level provided by databaseconceptual languages.

As an example of behavioural refinement, let us consider the class student inFigure 2 with the non-deterministic operation new.student. This associates with

Figure 2. Conceptual schema specification

Structured Database Schema Database class person of PERSON with (income:Ν; person ∀p (p ∈ person ⇒ income(p) ≥ 1000) init.person() = person, income :=∅, ∅ ; new.person(pers, i) = PRE pers∈PERSON-person ∧ i ≥1000 THEN ADD person(pers,i) END del.person(pers) = PRE pers ∈person THEN REM person (pers) END ) class employee is-a* person with (salary: Ν; employee ∀e (e ∈ employee ⇒ salary(e) ≥ 500) init.employee() = employee, salary := ∅, ∅; new.employee( pers, sal) = PRE sal≥500 ADD employee( pers, sal) END ) class student is-a* person with (identifier: Ν; student ∀s1, s2 (s1 ∈ student ∧ s2 ∈ student ∧ s1 ≠ σ2 ⇒ identifier(s1) ≠ identifier(s2)) ; init.student() = student, identifier := ∅, ∅; new.student(pers) = ANY m WHERE m ∈ N ∧ m ∉ ran(identifier) THEN ADD student(pers,m) END END )



each new student one and only one identifier that has not been used before. Apossible step of behavioural refinement consists in associating with each newstudent the maximum of all existing identifiers incremented by one. A StructuredDatabase Schema behavioural refinement is a modular refinement of classes;i.e., if a class is refined, the entire Structured Database Schema is refined. Aftera step of behavioural refinement for the class student, the Conceptual Schema

Figure 3. Decomposition – First and second schemas

Structured Database Schema1 Database class person−employee of PERSON with (income:Ν; person ∀p (p ∈ person−employee ⇒ income(p) ≥ 1000) init.person−employee () = person, income :=∅, ∅ ; new.person−employee (pers, i) = PRE pers∈PERSON-(person−employee) ∧ i ≥1000 THEN ADD person−employee (pers,i) END del.person−employee (pers) = PRE pers ∈person−employee THEN REM person−employee (pers) END ) class student is-a* person−employee with (identifier: Ν; student ∀s1, s2 (s1 ∈ student ∧ s2 ∈ student ∧ s1 ≠ s2 ⇒ identifier(s1) ≠ identifier(s2)) ; init.student() = student, identifier := ∅, ∅; new.student(pers) = ADD student (s, max(ran(identifier))+1) END)

Structured Database Schema2 Database class person • employee of PERSON with (income:Ν, salary:N; person ∀p (p ∈ person • employee ⇒ income(p) ≥ 1000) , employee ∀e (e ∈ person • employee ⇒ salary(e) ≥ 500) ; init. person • employee () = person, income, employee, salary :=∅, ∅, ∅, ∅ ; new. person • employee (pers, i) = PRE pers∈PERSON-( person • employee) ∧ i ≥1000 ∧ sal ≥500 THEN ADD person • employee (pers,i, sal) END del. person • employee (pers) = PRE pers ∈ person • employee THEN REM person • employee (pers) END ) class student is-a* person • employee with (identifier: Ν; student ∀s1, s2 (s1 ∈ student ∧ s2 ∈ student ∧ s1 ≠ s2 ⇒ identifier(s1) ≠ identifier(s2)) ; init.student() = student, identifier := ∅, ∅; new.student(pers) = ADD student (s, max(ran(identifier))+1) END)

296 Locuratolo


in Figure 2 has been decomposed into two: the Structured Database Schema1

with root class person-employee and the Structured Database Schema2 with

root class person•employee. The former root class takes only attributes,application constraints and operations of the class person; whereas the latter rootclass person•employee takes attributes, initialisation, and constraints of both theclasses person and employee. The operations are parallel compositions of thecorresponding operations on the classes person and employee. Each structureddatabase schema also takes a copy of the class student implicitly splitting thisclass with the partition of the class person. With a further step of decomposition,four disjoint classes are obtained.

These are recomposed to define a class hierarchy in which each object instancebelongs to one and only one class.

The logical schema specifies more information with respect to the conceptualschema, since the person•employee•student class is explicitly specified.

The definition of Structured Database Schema based on graph has been givenin order to apply the Revisited Partitioning after some steps of behaviouralrefinement; however, before performing any model transformation, the concep-tual schema consistency needs to be proved. In order to prove the ConceptualSchema consistency, the relationship between ASSO and B is usefully exploited.The next section describes the ASSO-B relationships.

ASSO-B Relationship

In the following, the ASSO-B relationships (Locuratolo & Matthews, 1999) willbe captured through properties (Locuratolo, 2002) and will be used in order toprove the Structured Database Schema consistency:

• Property (B-Machine and Class): A B-Machine whose initialisationestablishes the class constraints and whose operations preserve the classconstraints can be associated with each class, and a class can be associatedwith each B-Machine whose initialisation establishes the class constraintsand whose operations preserve the class constraints.

If the initialisation establishes the class constraints and the operations preservethe class constraints, a class can be identified with a B-Machine whose statevariables are constrained to satisfy the class constraints. This means that inorder to prove consistency, no class constraint obligation needs to be proved, but



only the application constraints obligations. In the following, by the term class-machine, we will refer to a B-Machine that identifies a class.

• Definition (class-machine consistency): A class-machine is consistent ifthe initialisation establishes the application constraints and each of theremaining operations preserves the application constraints.

In order to prove the class-machine consistency, a process of translation fromASSO classes to B-machines able to generate the application constraintobligations while avoiding the generation of the class constraint obligations hasbeen proposed (Locuratolo & Matthews, 1999). The translation from an ASSOclass to a B-Machine has been performed by associating both a base machineand a class machine with each class. The base machine is the means to constrainthe state variables to satisfy the class constraints. The base machine contains theclass variables, base operations and initialisation, without the invariant, thusgenerating no proof obligations. The base machine is embedded within a classmachine that declares the class operations and asserts the application constraintson the form of invariant. The encapsulation principle of B (Abrial, 1996) ensuresthat only the base operations can modify the class variables. As the baseoperations preserve the class constraints, this principle ensures that operationson classes preserve the class constraints. Thus, only the obligations related to theapplication constraints are generated and proved.

• Definition (Structured Database Schema consistency): The StructuredDatabase Schema is consistent if each class-machine corresponding to aclass of the conceptual schema is consistent.

With regard to the specification given in section 4.1, the class-machine person,the class-machine employee and the class-machine student need to be consis-tent.

In this chapter, the Structured Database Schema has been designed as a modelin which operations and application constraints involve only variables of singleclasses. The model (Locuratolo, 2001) has been enriched in order to allowoperations and application constraints to involve variables of two or moreclasses. In order to prove consistency of the enriched Structured DatabaseSchema, the following concept of specialised class-machine, a concept in-duced from the is-a* relationship between classes, has been introduced:

298 Locuratolo


• Definition (specialised class-machine): If class-machine name is in is-a*relationship with class-machine root, then:

• the objects of the specialised class-machine name are those of class-machine name;

• the attributes of the specialised class-machine name are both theattributes of the class-machine root restricted to the class name and thespecific attributes of the class-machine name;

• the initialisation (resp. an operation which inserts objects) of thespecialised class-machine name is the parallel composition (Abrial,1996) of the inherited initialisation (resp. the inherited operation whichinserts objects) with the corresponding specialisation;

• for each remaining operation on the class-machine root, the inheritedoperation belongs to the specialised class-machine name;

• the specific operations of class name belong to the specialised class-machine name.

• Property (Specialised class-machine): A specialised class-machine is aclass-machine. However, the distinction between class-machines andspecialised class-machines will be retained for convenience.

• Definition (Structured Database Schema): A Structured DatabaseSchema is a set composed by a class-machine, called root class-machine,and by a finite number of specialised class-machines.

The above definition of Structured Database Schema is equivalent to theprevious one; however, this permits seeing the model supported by ASSO as aset of independent class-machines, i.e., root class-machine and specialisedclass-machines that allow the decomposition of large consistency obligations intoa set of small obligations.

• Definition (Structured Database Schema consistency): A StructuredDatabase Schema is consistent if the root class-machine is consistent andeach specialised class-machine is consistent.

The proof of the inherited operations can be avoided. Thus, in the case ofoperations and application constraints involving only single classes, the specialisedclass-machine consistency is reduced to the class-machine consistency, whereas,in the case of operations and application constraints involving variables ofspecialised class-machines, the consistency proof of the specialised machine canbe optimised.



Conclusions and Further Developments

The design of ASSO, an innovative database design methodology for quality, hasbeen based on correct model transformations: starting from a directed acyclicgraph of classes supported by semantic data models, classes supported byobjects models are generated exploiting the Revisited Partitioning. The classessupported by semantic data models have been extended with aspects ofbehavioural modelling; proof obligations have been given. The class evolutionhas been designed with the intent to establish a relationship with the modelsupported by B, a formal method of software engineering appropriate forcommercial use, while still applying the Revisited Partitioning. The resultingmodel is an innovative model called Structured Database Schema. Thespecifications, supported by the Structured Database Schema are only thosewhich satisfy the class and the specialisation constraints. This restriction is thekey to reduce the consistency proofs of the whole schema to the consistencyproofs of simple B-Machines.

In the following, two possible methods based on model transformations will beproposed. They allow using some of the results achieved in designing ASSO. Theformer permits deriving implicit knowledge contained in hierarchies of concepts;the latter permits raising the abstraction level of B.

• Partitioning of Concepts: The concept theory encloses the distinctionbetween concept intension and concept extension, where the former refersto the information content of the concepts, and whereas the latter to the setof objects which fall under the concepts. The revisited Partitioning can beapplied to the extensional side, whereas no similar approach has ever beendesigned for the intentional side. A method based on correct modeltransformations could be designed in order to derive knowledge implicitlycontained in hierarchies of concepts.

• Raising the Abstraction Level of B: The ASSO experience can beexploited for designing methods to be used in specific application areasstarting from widely accepted general purpose methods. An exampleconsists in raising the abstraction level of B. An approach composed by twophases could be designed: the former is a logical formalisation of classessupported by object systems in terms of B-Machines, the latter is a processof schema transformations, which provides a model where only specifica-tions of both the class and the specialised classes can be given and whereonly a minimal number of reduced obligations suffices to prove consistency.

300 Locuratolo


Acknowledgments

The author would like to thank her husband, Antonio Canonico, and her childrenPaola and Floriano for their help and advice.

Figures 2, 3 and 4 have been reprinted from “Designing Methods for Quality” byElvira Locuratolo in Information Modelling and Knowledge Bases XIII, editedby Hunnu Kangassalo, Hunnu Jaakkola, Eiji Kawaguchi and Tatjana Welzer, p. 287and p. 289, copyright 2002, with kind permission from IOS Press.

References

Abrial, J. R. (1996). The B-Book: Assigning Programs to Meanings. Cam-bridge University Press.

Albano, A., Cardelli, L., & Orsini, R. (1985). Galileo: A strongly-typed interac-tive conceptual language. ACM Transactions on Database Systems,10(2), 230-260.

Andolina, R., & Locuratolo, E. (1997). ASSO: Behavioural specialisationmodelling. In H. Kangassalo (Ed.), Information Modelling and Knowl-edge Bases VIII, (pp. 241-259). IOS Press.

B-Core. (n.d.). B-Toolkit (online manual). Oxford, UK. Available: http://www.b-core.com

Batini, C., Ceri, S., & Navathe, S.B. (1992). Conceptual Database Design: AnEntity-Relationship Approach. Redwood City, CA: Benjamin Cummings.

Booch, G. (1994). Object-Oriented Analysis and Design with Applications.Benjamin Cummings.

Cardenas, A. F., & McLeod (1990). Research Foundations in Object-Oriented and Semantic Database Systems. Englewood Cliffs, NJ: PrenticeHall.

Castelli, D., & Locuratolo, E. (1994). A Formal Notation for Database Concep-tual Schema Specifications. In H. Jaakkola (Ed.), Information Modellingand Knowledge Bases VI, IOS Press.

Castelli, D., & Locuratolo, E. (1995). ASSO: A formal database design meth-odology. In H. Jaakkola (Ed.), Information Modelling and KnowledgeBases VI, (pp. 145-158). IOS Press.

Castelli, D., & Locuratolo, E. (1995). Enhancing Database System Qualitythrough Formal Design. Fourth Software Quality Conference, Universityof Abertay Dundee & Napier University, pp. 359-366.



Ceri, S., & Fraternali, P. (1997). Database Applications with Objects andRules. Edinburgh Gate Harlow Essex, UK: Addison Wesley Longman.

Chen, P. P. (1976). The entity-relationship model: Towards a unified view ofdata. ACM Transaction on Database Systems, 1(1), 76-84.

Coad, P., & Yourdon, E. (1991). Object-Oriented Design. Yourdon Press.

Elmasri. R., & Navate, S. (1997). Fundamental of Database System. Addison-Wesley.

Facon, P., Laleau, R., & Nguyen, H. P. (1996). Mapping object diagrams intoB specifications. In A. Bryant & L.T. Semmens (Eds.), Proceedings ofthe Methods Integration Workshop, Electronics Workshops in Com-puting, BCS.

Jarke, J., Mylopoulos, J.W., Schmidt, J. W., & Vassiliou, Y. (1992). DAIDA: Anenvironment for evolving information systems. ACM Transactions onInformation Systems, 10(1), 1-50.

Laleau, R. (2000). On the interest of combining UML, with the B formal methodfor the specification of database applications. ICEIS2000, 2nd Interna-tional Conference on Enterprise International Systems. Stafford, UK.

Laleau, R. (2002). Conception et development formels d’applications basesde données. Habilitation Thesis, CEDRIC Laboratory, Évry, France.Available: http://cedric.cnam.fr/PUBLIS /RS424.ps.gz

Locuratolo, E. (1997). ASSO: Evolution of a formal database design methodol-ogy. Proceedings of Symposium on Software Technology, (SoST’97),Buenos Aires, August 12-13.

Locuratolo, E. (1998). ASSO: Portability as a Methodological Goal. TR IEIB4-05-02.

Locuratolo, E. (2002). Designing methods for quality. In H. Kangassalo, H.Jaakkoala, E. Kawaguchi & T. Welzer (Eds.), Information Modellingand Knowledge Bases XIII, (pp. 279-295). IOS Press.

Locuratolo, E., & Matthews, B.M. (1998). Translating structured databaseschemas into abstract machines. Proceedings of the 2nd Irish Workshopon Formal Methods, Cork, Ireland.

Locuratolo, E., & Matthews, B. M. (1999). ASSO: A formal methodology ofconceptual database design. In S. Gnesi & D. Latella (Eds.), Proceed-ings of the Federated Logic Conference, (pp. 205-224). Fourth Interna-tional ERCIM workshop on Formal Methods for Industrial Critical System.

Locuratolo, E., & Matthews, B. M. (1999). Formal development of Databasesin ASSO and B. In J. Wing, Woodcock, & J. Davies (Eds.), LNCS 1708,FM 99 – Formal Methods (pp. 388-410). Berlin Heidelberg: Springer-Verlag.

302 Locuratolo


Locuratolo, E., & Matthews, B. M. (1999). On the relationship between ASSOand B. In H. Jaakkoala, H. Kangassalo & E. Kawaguchi (Eds.), Informa-tion Modelling and Knowledge Bases X, (pp. 235-253). IOS Press.

Locuratolo, E., & Rabitti, F. (1998). Conceptual classes and system classes inobject databases. Acta Informatica, 35(3), 181-210.

Mammar, A., & Laleau, R. (2003). Design of an automatic prover dedicated tothe refinement of database applications. In K. Araki, S. Gnesi, & D.Mandrioli (Eds), CEDRIC-IIE (CNAM) (pp. 835-853). Evry, France,LNCS 2805, FME 2003, Formal Methods.

Nixon, B., & Mylopoulos, J. (1990). Integration issues in implementing semanticdata models: Advances in database programming languages. ACM Press,187-217.

Richardson, J., & Schwartz, P. (1991). Extending objects to support multiple,independent roles. Proceedings of the International Conference ofManagement of Data (vol. 20, pp. 298-307). SIGMOD Record.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W. (1991).Object-Oriented Modelling and Design. Englewood Cliffs: PrenticeHall.

Rumbaugh, J., Booch, G., & Jacobson, I. (1999). The Unified ModellingLanguage Reference Manual. Reading, MA: Addison-Wesley.

Shore, R. (1996). An object-oriented approach to B. In H. Habrias (Ed.),Proceedings of the 1st Conference on the B-Method, Nantes, France.

Spagnolo, A.M. (2000). Incrementare la qualità in ambito Basi di Dati. Tesi diLaurea. Università degli Studi di Pisa – Corso di Laurea in Scienzedell’Informazione. Relatore: Dott.ssa Locuratolo, E.

About the Authors 303


About the Authors

Patrick van Bommel received his master’s degree in Computer Science (1990)and PhD from the Faculty of Mathematics and Computer Science, University ofNijmegen, The Netherlands (1995). He is currently an assistant professor at theUniversity of Nijmegen. He gives courses in foundations of databases andinformation systems, information analysis and design, and he supervises a semi-commercial student software house. His main research interests include infor-mation modeling and information retrieval. In information modeling, he particu-larly deals with: modeling techniques for information systems; data models forhyperdocuments and Web sites; semi-structured data; equivalence and transfor-mation of data models; the transformation of conceptual data models intoimplementations; and the transformation of database populations, operations andconstraints. In information retrieval his main research interests include: docu-ment data modelling; WWW-based retrieval and filtering; document character-ization languages; and digital libraries.

* * *

Jacob O. Adeniyi is an associate professor with the Department of ComputerScience, King Saud University, Riyadh, Saudi Arabia. He received a BSc(Honors) in Mathematics from the University of Ibadan, Nigeria (1970) and aPostgraduate Diploma in Computer Science from the University of Lagos,Nigeria (1972). He earned an MSc and PhD in Computer Science (1973 and1976, respectively) from the University of Birmingham, UK. His research areasinclude modeling, systems design and implementation, and Web databases. Hehas more than 30 research articles to his credit including this chapter in the book,Transformation of Knowledge, Information, and Data (Idea Group Publishing,Hershey, Pennsylvania, USA).

304 About the Authors


Tariq Al Tuwairqi is a gradfiatgraduate student of the Department of ComputerScience at King Saud University in Riyadh, Saudi Arabia. He received a BSc inComputer Science from King AbdulAziz University, Jeddah, Saudi Arabia(1995). His research areas include Web databases, wireless computing, andInternet security.

Antonio Badia received a Licenciatura in Philosophy from the Universidad deBarcelona before studying Computer Science and Artificial Intelligence at theUniversitat Politecnica de Catalunya. He then joined the graduate program atIndiana University and received a PhD in Computer Science. He is currently anassistant professor in the Computer Science and Computer Engineering Depart-ment at the University of Louisville (USA) where he directs the Database Lab.His research has been funded by the National Science Foundation and the USNavy. His research interests include conceptual models, query languages, queryprocessing and optimization, active databases, knowledge management, andapplications of information systems to intelligence tasks.

Paolo Bottoni graduated in Physics in 1988 and obtained his doctoral degree inComputer Science (1995). Since 1994, he has been with the Department ofComputer Science of the University “La Sapienza” of Rome, first as a re-searcher, and, since 2000, as an associate professor. His research interests aremainly in the area of interactive computing, and include: definition of pictorial andvisual languages, visual simulation, formal models of visual interactive comput-ing, agent-based computing. On these topics, he has published 100 scientificpapers in international journals, contributed volumes and conference proceed-ings.

Dunren Che, an assistant professor with the Department of Computer Science,Southern Illinois University at Carbondale (USA), earned a PhD in ComputerScience from the Beijing University of Aeronautics and Astronautics, Beijing,China (1994). Afterwards, he gained several years of postdoctoral researchexperience in different institutes. His recent research interest covers two majorareas: advanced database technology (especially XML database management)and bioinformatics.

Keith Duddy is co-leader of the Pegamento Project within the EnterpriseAutomation Group at the DSTC. Since 1998, this project has been extending theObject Management Group’s core MOF and UML modeling technologies to dealwith enterprise modelling issues and mapping of those models to a range ofdistributed technology platforms. Keith was a contributor to the OMG Standards



for CORBA Trader and Notification services. He was co-author of ‘JavaProgramming with COBRA’ (Wiley, 1997), the first book on this subject. He hassince been editor for the OMG standards ‘UML Profile for CORBA’ and ‘UMLProfile for Enterprise Distributed Object Computing (EDOC)’. Keith has servedthree terms on the OMG architecture board.

Anna Gerber is currently a research scientist with the Distributed SystemsResearch Centre (DSTC) in Brisbane. Her present work involves research intoand prototyping of model-driven development techniques, and includes contribu-tions to DSTC’s work on the Object Management Group (OMG) EnterpriseDistributed Object Computing (EDOC) standard and OMG Meta Object Facility2.0 Query/View/Transformation (MOF QVT) proposals. Anna’s researchinterests include enterprise modelling, mapping workflow and business processmodels to middleware technologies facilitating automatic generation of imple-mentations, and generation of tools such as domain specific graphical editorsfrom models.

Mohand-Saïd Hacid is a professor at the University Claude Bernard Lyon,France. His research interests include knowledge representation and reasoning,data models and query languages for multimedia databases and the semanticWeb. Hacid graduated as an engineer in Computer Science from the Universityof Tizi-Ouzou, Algeria, and received his PhD in Computer Science from theNational Institute of Applied Sciences, Lyon, France.

Jean-Luc Hainaut is a full professor in Information System and DatabaseEngineering at the Institute of Informatics of the University of Namur, Belgium.He is heading LIBD (Laboratory of Database Applications Engineering), thepurpose of which is to develop general methodologies and CASE tools to assistpractitioners in solving such engineering problems as database design, databasereverse engineering, federated databases, database evolution, temporal data-bases, XML and Web engineering. He is the author of two books (in French) ondatabase modelling and database design, and of more than 50 recent journal andproceedings papers. Two of the major results of the research activities, namelythe DB-MAIN CASE environment and a wide spectrum database reverseengineering methodology, are being marketed by a young spin-off of the LIBD.

Renate Klempien-Hinrichs is a research assistant in theoretical computerscience at the University of Bremen in Germany. In 1992, she received a diplomain Computer Science from the University of Passau. Her doctoral thesis oncontext-free hypergraph grammars with node and hyperedge rewriting was



completed in 2000. In between, she was a fellow within the European ResearchNetwork GETGRATS at the University of Bordeaux in France. Her researchinterests are mainly directed towards formal methods and include computing bygraph transformation, context-free generation of graphs and graph-like objects,syntactic picture generation, and gender and teaching issues in computerscience.

Hans-Jörg Kreowski is a professor of Theoretical Computer Science at theUniversity of Bremen, Germany. He holds a diploma degree in Mathematics anda doctoral degree in Computer Science from the Technical University in Berlin.From 1992-1997, he served as chair of the IFIP Working Group 1.3 (Foundationsof Systems Specification), receiving the IFIP Outstanding Service Award in1996. He currently chairs the German Forum Informatikerinnen und Informatikerfür Frieden und gesellschaftliche Verantwortung [forum of computer scientistsfor peace and social responsibility]. His research is in the area of theoreticalcomputer science with emphasis on graph transformation, algebraic specifica-tion, rule-based systems, and syntactic picture processing, as well as oncomputers and society.

Sabine Kuske is a research assistant and lecturer in Theoretical ComputerScience at the University of Bremen, Germany. From 1982-1991, she studiedfirst business management with emphasis on tourism in Spain, and secondlycomputer science at the University of Bremen. From 1991-1993, she receiveda doctoral grant from the University of Bremen. In 2000, she obtained a doctoraldegree for her thesis on transformation units, a concept that offers a structuringprinciple for graph transformation systems. Her research interests concernprogramming and specifying with graph transformation, structuring principles forgraph transformation, and application of graph transformation to the UML.

Michael Lawley holds a PhD from Griffith University in Brisbane, Australia, inthe area of integrity constraint checking for object-oriented databases. Cur-rently, Dr. Lawley is the co-project leader for the Pegamento Project at theDSTC, also in Brisbane. He has published widely in the area of workflow designand verification, as well as the integration of workflow with other middlewaretechnologies. He is a contributor the OMG standard ‘UML Profile for EnterpriseDistributed Object Computing’. His current interests are in the area of modeltransformation for the development of software systems.

Elvira Locuratolo graduated in Mathematics from the University of Naples.Since 1982, she has been a researcher at Institute of Information Science and



Technologies (ISTI) of the Italian National Research Council in Pisa. Herresearch interests include quality modeling, database design methodologies,formal methods and re-engineering methods. She is the author of numerousarticles in books and journals. She has collaborated with the Rutherford AppletonLaboratory at Oxford and other foreign institutions. She also carries out teachingactivity in mathematics and computer science at the University of Pisa.

Z. M. Ma received his PhD from the City University of Hong Kong (2001). Hiscurrent research interests include intelligent database systems and design, Web-based data management, e-learning systems, engineering database modeling,enterprise information systems, knowledge management, intelligent planning andscheduling, decision making, and robot path/motion planning. He has publishedmany journal, conference, and book chapter papers in these areas. He iscurrently editing and authoring two upcoming books being published by IdeaGroup Inc. and Kluwer Academic Publishers, respectively.

Andreas Märcz was born in Großenhain near Dresden in the former GDR (eastpart of Germany). From 1983-1995, he attended elementary, grammar andsecondary school in Dresden and got a university-entrance diploma (GermanAbitur). Because of his interest in databases and software engineering hestudied Information Technology at the Dresden University of Technology (TU-Dresden) (1995-2000). In 2000, he graduated with an MSc in Computer Scienceand got a position as database chair at TU-Dresden with scientific, teaching andadministration activities. His current research scopes on format independencefor multimedia databases, especially for time dependent objects and thereforeresource management.

Klaus Meyer-Wegener studied computer science from 1975-1980 at DarmstadtInstitute of Technology, receiving the degree Diplom-Informatiker. From 1980–1986, he served as a research assistant with the Department of ComputerScience at University of Kaiserslautern. In 1986, he received a PhD (Doktor-Ingenieur). From 1986–1990, he served as assistant professor in the Departmentof Computer Science, University of Kaisers-lautern. From October 1987 throughDecember 1988, he served as adjunct research professor at the Naval Post-graduate School in Monterey, California. His other professions include: 1991,Habilitation, University of Kaiserslautern; 1990-1993, associate professor ofComputer Science (Database Systems), University of Erlangen and Nuremberg;1993-2001, full professor, Department of Computer Science, Dresden Univer-sity of Technology. Since October 2001, he has served as full professor ofComputer Science (Database Systems) at the University of Erlangen andNuremberg.



Francesco Parisi-Presicce is with the Department of Information and Soft-ware Engineering at George Mason University, on leave from the Università diRoma “La Sapienza,” where he has been professor of Computer Science in theDepartment of Information since 1993. He received his PhD and MS inMathematics from the University of Connecticut (1981 and 1977, respectively),and the degree of ‘Dottore in Matematica’ summa cum laude at the Universitàdi Roma La Sapienza (December 1975). He has been active in the graphtransformation community since its inception, and applies graph transformationsto information systems security, formal methods in secure system development,network security and visual modeling techniques. He is the author of more than100 papers appeared in international journals, books and conference proceed-ings.

Jean-Marc Petit is an associate professor at the University Blaise Pascal,Clermont-Ferrand, France. He graduated in computer science from the Univer-sity Claude Bernard and the Ecole Normale Superieure of Lyon. He received hisPhD in Computer Science from the University Claude Bernard (1996). His mainresearch interest concerns databases and data mining. In the past, he contributedto database reverse engineering.

Kerry Raymond is the distinguished research leader at DSTC, responsible forthe management of exploratory research projects. She has a PhD from theUniversity of Queensland in distributed systems. Her personal research interestsare in the Enterprise Automation research group which seeks to increase theextent of automatic generation of systems from high-level descriptions andenterprise models to provide rapid application development and evolution. Hercurrent research focuses on the development of a generic transformation engineto implement the automatic generation of systems, and the role of knowledgerepresentation and ontologies in automatic systems generations.

Abad Shah is an associate professor in the Department of Computer Science atKing Saud University in Riyadh, Saudi Arabia. He received his BSc in Math-ematics and Physics from Punjab University, Lahore, Pakistan (1967), an MScin Applied Mathematics from Quaid-I-Azam University, Islamabad, Pakistan(1981) with Quaid-I-Azam Award, an MS in Computer Science from RensselaerPolytechnic Institute, Troy, New York (1986), and a PhD in Computer Sciencefrom Wayne State University, Detroit, Michigan (1992). His research areasinclude modeling, object-oriented databases, temporal databases, Web data-bases, software engineering, information modeling. He has more than 40research articles to his credit including this chapter in the book, Transformation



of Knowledge, Information, and Data (Idea Group Inc., Hershey, Pennsylvania,USA).

Jim Steel has worked for the last four years as a research scientist at theDistributed Systems Technology Centre. He has extensive experience inmetamodeling and model-driven standards and techniques, including the meta-object facility (MOF), XML-based model interchange (XMI), enterprise distrib-uted object computing (EDOC) standards within the object management group(OMG). He also serves as the chairman of the Human-Usable Textual Notation(HUTN) Finalisation Task Force. He is currently working with the DSTC’sPegamento project on a language for describing model transformations. Hisresearch interests include metamodeling, generative and generic programming,automated systems development, and language design.

Maciej Suchomski was born in Zgorzelec in Poland in 1976. He earned adegree of Technician in Electro-Energy and an honored university-entrancediploma. Between 1996-2001, he studied at the Wroclaw University of Technol-ogy (PWR). In 2000, he was nominated to a one-year Socrates/ErasmusScholarship at the New University of Lisbon, Portugal. In 2001, he received theUSENIX Student Research Grant and later received his MSc in ComputerScience (Multimedia Information Systems). Since 2002, he has been a researchassistant at the Friedrich-Alexander University of Erlangen-Nuremberg inGermany. His current scientific work concerns a real-time audio-video conver-sion for MMDBs.

Gabriele Taentzer is an associate professor of Computer Science at theTechnical University of Berlin and member of the steering committee ofInternational Conferences on Graph Transformation (ICGT). Her researchinterests include the development of new graph transformation concepts andtheir application in different areas of software engineering, visual languages anddistributed systems. She leads the development of the graphtransformationenvironment AGG (http://tfs.cs.tu-berlin.de/agg) which offers a variety of toolsto work with graphs and graph transformation and supports the integration ofgraph transformation into Java applications.

Norbert Vincent received an MSc in Economics from the Vrije UniversiteitAmsterdam in 1994, specializing on the theme ‘Business Process Redesign’. Hecurrently is working on his PhD on Performance Management of the BusinessValue of IT at the Erasmus University Rotterdam. Professionally, NorbertVincent currently works as principal consultant for LogicaCMG. There, he



advises organisations on business and IT strategy, business transformation andcost and performance management. His current focus is on ERP and theperformance of organisations.

Lex Wedemeijer has been working in the areas of data administration and datamanagement in several Dutch companies for more than 20 years. His maininterests are in quality and evolution of data schemas, both its theoreticalfoundations and its practical implications encountered in the business environ-ment. In 2002, he received a PhD from Delft University, on a dissertation titled,Exploring Conceptual Schema Evolution. Currently, Lex Wedemeijer is dataarchitect at ABP Netherlands, Europe’s largest pension fund.

Bernd Wondergem received an MSc in Computer Science from UtrechtUniversity (1996), specializing on the theme ‘Organization & Information’. Hereceived a PhD in Information Retrieval from the University of Nijmegen (2000).His research centered around compact and tractable descriptors for informationdiscovery. In addition, he received an MSc in Management and Organisationfrom Tias Business School (2002). Currently, he is a guest lecturer on Perfor-mance Management at the University of Nijmegen. Professionally, BerndWondergem currently works as principal consultant for LogicaCMG Consulting,the advisory unit of LogicaCMG. There, he works with companies and otherorganisations on improving their performance. In particular, he focuses ontranslating the organisation’s strategy in the required management informationand on building performance-oriented organisations.

Index 311


Index

Symbols

1NF relational model 83-schema architecture 258

A

abstract syntax tree (AST) 99abstracting power 55abstraction level 285abstraction mechanism 286access preservation 120action management 220action semantics 119action semantics language (ASL) 131action tuples 44active database 192activity diagrams 97acyclicity 59admission control 237advanced transformations 143affected code 103aggregation 153aggregation attribute 200algebraic approach 105algebraic signature 106algebraic transformation 78

alias filters 248anti-Yacc 128application reprogramming 265approximate dependencies 175arbitrary entity 275arbitrary nesting 174aspect-driven transformation 135ASSO 284associations 152associativity 83atomic objects 155attribute value indices 81attribute-oriented data model 55attribute-oriented model 53attributed graph 106attributes 149audio 237audio stream 237availability of source data 227

B

B-machine 287B-method 287balanced scorecard (BSC) 220balanced tags 157behavior preservation 120

312 Index


behavioral analogies 98behavioral aspects 119behavioural modelling 285behavioural refinement 293, 294belated normalization 269binary graph 5binary relationship 150binary relationship-type 57bool 35bridge entity type 15business processes 221

C

call preservation 121candidate keys 175cardinality constraint 150cardinality information 199Cartesian product 198causal relationship 260chain of converters 239change pattern 266change taxonomies 264class application constraint 292class constructor 293class diagrams 97, 260class extension 292class hierarchy 151, 296class of patterns 16class state variables 292class-machine 296classification 289cleaning-up phase 87code evolution 101code representation 100coding scheme 238coexistence constraint 12collaboration diagram 101collection type 155common superclass 98common warehouse metamodel (CWM)

129commutativity 83compatibility 265complex entities 208complex objects 197compliant documents 80

component streaming interface (CSI)251

composite key 154composition 153composition symbol 196compound attributes 8compound transformation 15computer-based information systems

190conceptual classes 291conceptual data models 54conceptual models 148conceptual schema 6, 258concrete syntax 137conjunctive information 194constraint obligation 296constructor-oriented data model 55constructor-oriented model 53constructors 55containment relationship 79contextual elements 115contiguous subtrees 117continuous improvement 220control condition 30control flow actions 119conversion 236conversion algorithm 236conversion graph 239, 243conversion networks 237converter 239CORBA IDL 129correct translation 288correctness 287

D

dangling condition 107data coercion 265data model 53, 148data model theories 261data semantics 53data structure 53data type 133data-driven methodologies 286database design 52, 283database design process 286database interoperability 2

Index 313


database management systems(DBMS) 286

database platform 262declarative object-oriented transforma-

tion language 135decomposition 291, 296decomposition operator 11definition symbol 195Deming’s cycle 219dependent entities 268design correctness 283design primitives 261determinism 87deterministic transformation 77, 87directed graph 61, 224DirectX 241disjoint classes 296disjunctive information 194distributed application 115distributed graph 107distributed graph transformation 107distributivity 83document indexing 77document queries 76document schema (DTD) 172document type declaration/description

(DTD) 172domain 153, 205DROPS 251DTD graph 78dynamic aspect 287dynamic modelling 285dynamic resource allocation 229dysfunctional behaviour 227

E

edge concept 80element content indices 81element extent 81elementary operator 15embed 42end tags 156enterprise distributed object computing

(EDOC) 129enterprise-distributed system develop-

ment 128entity collection 6

entity identifier 207entity instances 207entity Java Bean (EJB) model 143entity types 149entity-relationship 149entity-relationship model 52EntityBeans 143enumeration type 200equivalence 82equivalent transformation 76estimated cost 77evaluation efficiency 86evolution operator 263excessive fragmentation 177exclusivity 84existing hierarchy 104expected requirements 221explicit constraints 56explicit constructor 55EXPRESS 191extend entity 272extensible markup language (XML) 172external schema 259extract method 116

F

facets 157families of transformations 11figurative representation 78filter 241filter graph 241foreign key 13, 154, 173, 184foreign-key change 268functional dependencies (FDs) 56, 178fuzzy conceptual data models 193fuzzy data 194fuzzy nested relational database model

193fuzzy occurrences 201fuzzy set 194fuzzy subtype 202fuzzy supertype 202

G

generalization 153generalization hierarchies 287

314 Index


generalized aggregation 57GER model 6global scope 60goal model (GM) 222graph 32graph class expression 30, 34graph homomorphism 106graph morphism 100graph of converters 239graph rule 106graph transformation 31, 97, 130graph transformation unit 36

H

hierarchical relation 157hierarchy structure 198horizontal fragmentation 273hybrid schema 6

I

impact value 224implicit constraints 56imprecision 193inclusion dependencies 56inconsistent model 101independent actions 119independent evolution 100index structures 81informal notation 285information retrieval (IR) 81inheritance 154, 289inheritance hierarchy 57inheritance of attribute 151inheritance relation 113initialisation 292inline technique 177inserted types 104instance graph 106instance mapping 9integrity constraints 154inter-model operators 4inter-schema references 196interface graph 100, 108internal schema 259interoperability 128intersection entities 270

intra-model transformations 4intuitive meaning 59inverse reference 154inverse transformation 9irregular structures 172is-a-hierarchy 57

J

Java media framework (JMF) 241

K

key attribute 150key performance indicators (KPI) 220key success factors (KSF) 220

L

labeled graphs 156lattice of models 4lexical transformations 97local graph 107logical data model 54logical database tuning 52logical schema 287

M

marking model 143markup language 78matrix method 192maximal postcondition 9MDA 128measurable indicator 219media codec 241media data 237media object (MO) 236“member” entity 268membership degrees 205membership function 194meta information 238meta object facility (MOF) 129method extraction 99min-max cardinalities 6minimal precondition 9MO.content 238MO.format 238MO.type 238

Index 315


model diagrams 99model driven architecture (MDA) 145model evolution 285model transformation 128model-driven architecture 128model-driven transformation 17MTDL 131multimedia computer 236multimedia conversion 235multimedia data 236, 237multimedia objects (MMO) 236multivalued attribute 14, 152mutation 12mutation transformations 12

N

name clashes 98negative application conditions 107nest operator 198nest-unnest 11nested element structure 172nested loops 184nested relational databases 196network graph 107network rule 107NF2 model 7nodes 156non-deterministic operation 288normalization 88, 178normalization phase 87normalization rules 175normalization theory 4normalized schemas 60

O

object identifiers 154object inclusion 289object instance 15, 290, 296object intersection 290object management group (OMG) 128object model 285object-id 133object-oriented methodologies 287object-oriented models 128object-oriented programming 96object-oriented specification 129

object-relational structure 7object-role modeling (ORM) 4, 149obligation generator 288OCL 2.0 131OCL constraint 99OO-databases 7operational models 3operational organisation 220operational phase 264optimisation algorithms 248optional attribute 152optional reference 269optional type 173ordering constraints 134organisation model (OM) 222owner entity 271

P

page references 196partial operation 288partial organization 156participation constraint 150PAT algebra 80PAT expression 80path concept 80path indexing 77, 81pattern definitions 136performance indicators (PI) 219, 224performance management (PM) 218,

225performance management model (PMM)

222permitted values 55physical schema 6platform independent models (PIMs)

128platform specific models (PSMs) 128possibility distribution theory 193potential indices 82potential transformations 82power set 205predicate-driven transformation 16presentation processing engine (PPE)

242primary key 8, 154, 173, 184, 261primitive refactoring 98

316 Index


product data mode 207product type 29profitable transformation 82project-join 11projection 42proof obligation 288prototype tree 175

Q

QoS-filtering model 241quality function deployment (QFD) 221quality of data (QoD) 240quality of experience (QoE) 240quality of service (QoS) 237, 239quantitative performance 219query algebra 78query expression 77query optimization 75query processing 76QVT 130

R

REAL 236real-time operating system (RTOS) 249real-time processing 237refactoring 97refactoring actions 99reference relationship 203referential integrity 154, 267regular expression 80, 175relation schema 56relation values 205relational algebra 198relational data model 153relational database (RDB) 172, 192,

196relational database technology 172relational model 52relational shell 155relationship cardinalities 53relationships 149relaxation 274removed subtrees 117resource usage 246restrict entity 272restructuring operators 198

result-driven business management229

RETAVIC 236, 250revealed requirements 221reverse engineering 6, 99revisited partitioning 285, 291rewriting operator 5root class 293root element 79root entities 209root node 175rule application 33rule-based transformation 29

S

schema equivalence 2schema evolution 263schema extensibility 268schema extraction algorithm 183schema integration 264schema merging 264self-activation 101self-call stemming 101self-referring links 270semantic change 260semantic checking 60semantic data model 55, 289semantic heterogeneity 261semantic optimization phase 87semantic relationships 197semantics constraints 176semantics preservation 10semistructured data 172semistructured data management 77separate nodes 183sequential application 108serial attributes 14set-oriented construct 14set-oriented equivalences 83significant refactoring 100simplification phase 87single schema 199software engineering 31source schema 10source-driven 135source-driven transformation 131

Index 317


specialised class 292stable description 262standard generalized markup language

(SGML) 76standard relational model 4state machine 97, 101statecharts 99static declaration 119static description 286static diagram 151STEP 191strategic goals 218strategic map 222structural changes 262structural inverse 10structural mapping 9structural predicate 16structural properties 82structure index 81structured database schema

285, 288, 291structured database schema consis-

tency 297structured document 76structured domain 152structured-document database 76sub-element 173subclass 151, 287subrule 113substitution language 288subtype 13subtype/supertype relationship 208subvertices 119superclass 287superimposed entity 275supertype 13surrogate key 58sustained competitive advantage 232symmetrically reversible 10, 12syntactic changes 263system evolution 128

T

table divide 273tags 78target-driven 135

terminal graph 39textual content 80time constraint 238timed MMO 238timed MO 238tracking relationships 136traditional optimization 76transcode 242transcoder 242transformation algorithm 173transformation database 9transformation plan 17transformation reversibility 9transformation rules 81, 136transformation tool set 144transformation unit 36, 109transformation-based database engi-

neering 1, 75, 127, 217, 257transformational theory 3transformations of data 129transitive closure 79transitive closure of inheritance 112transitive inclusion 4tree data 173tree grammar 176TRule 137tuples 154type modeling 200type preservation 120type transformation 208type-compatible 80

U

UML 31, 97, 149UML class diagram 129UML class model 8UML metamodel 99unidirectional 87unified entity 275unified modeling language (UML) 128,

151union types 176unique identifier 207, 293universal relation schema assumption

61universe of discourse 259

318 Index


update preservation 121user defined types (UDTs) 155user interface 265user training 265user-defined operator 13

V

validity 274value-based management (VBM) 220variable replacement 114vertex 105vertex identity 106video 237video stream 237VirtualMedia 242visual languages 31

W

weak entity 151, 271well-formedness constraints 121World Wide Web Consortium (W3C) 76

X

XML 149XML model interchange (XMI) 129XPATH 131XQuery 131

BO O K CH A P T E R S

JO U R N A L ART I C L E S

CO N F E R E N C E PR O C E E D I N G S

CA S E ST U D I E S

The InfoSci-Online database is the

most comprehensive collection of

full-text literature published by

Idea Group, Inc. in:

n Distance Learning

n Knowledge Management

n Global Information Technology

n Data Mining & Warehousing

n E-Commerce & E-Government

n IT Engineering & Modeling

n Human Side of IT

n Multimedia Networking

n IT Virtual Organizations

BENEFITS

n Instant Access

n Full-Text

n Affordable

n Continuously Updated

n Advanced Searching Capabilities

The Bottom Line: With easyto use access to solid, currentand in-demand information,InfoSci-Online, reasonablypriced, is recommended foracademic libraries.

- Excerpted with permission from Library Journal, July 2003 Issue, Page 140

“

”

Start exploring atwww.infosci-online.com

Recommend to your Library Today!

Complimentary 30-Day Trial Access Available!

InfoSci-Online

Instant access to the latest offerings of Idea Group, Inc. in the fields of

INFORMATION SCIENCE, TECHNOLOGY AND MANAGEMENT!

DatabaseInfoSci-OnlineDatabase

A product of:

Information Science Publishing*Enhancing knowledge through information science

*A company of Idea Group, Inc.www.idea-group.com

BROADEN YOUR IT COLLECTIONWITH IGP JOURNALS

[email protected] www.idea-group.com

A company of Idea Group Inc.

701 East Chocolate Avenue, Hershey, PA 17033-1240, USATel: 717-533-8845; 866-342-6657 • 717-533-8661 (fax)

Visit the IGI website for more information onthese journals at www.idea-group.com/journals/

Name:____________________________________ Affiliation: __________________________

Address: ______________________________________________________________________

_____________________________________________________________________________

E-mail:______________________________________ Fax: _____________________________

Upcoming IGP Journals

January 2005

� Int. Journal of Data Warehousing & Mining � Int. Journal of Enterprise Information Systems

� Int. Journal of Business Data Comm. & Networking � Int. Journal of Intelligent Information Technologies

� International Journal of Cases on E-Commerce � Int. Journal of Knowledge Management

� International Journal of E-Business Research � Int. Journal of Mobile Computing & Commerce

� International Journal of E-Collaboration � Int. Journal of Technology & Human Interaction

� Int. Journal of Electronic Government Research � Int. J. of Web-Based Learning & Teaching Tech.'s� Int. Journal of Info. & Comm. Technology Education

Established IGP Journals

� Annals of Cases on Information Technology � International Journal of Web Services Research

� Information Management � Journal of Database Management

� Information Resources Management Journal � Journal of Electronic Commerce in Organizations

� Information Technology Newsletter � Journal of Global Information Management

� Int. Journal of Distance Education Technologies � Journal of Organizational and End User Computing

� Int. Journal of IT Standards and Standardization Research

is an innovative international publishing company, founded in 1987, special-izing in information science, technology and management books, journalsand teaching cases. As a leading academic/scholarly publisher, IGP is pleasedto announce the introduction of 14 new technology-based research journals,in addition to its existing 11 journals published since 1987, which beganwith its renowned Information Resources Management Journal.

Free Sample Journal CopyShould you be interested in receiving a free sample copy of any of IGP'sexisting or upcoming journals please mark the list below and provide yourmailing information in the space provided, attach a business card, or emailIGP at [email protected].

IdeaGroup

Publishing

IDEA GROUP PUBLISHING

An excellent addition to your library

��

�� !�"

#��$��%�"��%""��& ��'��(�!�) �*��++�

ISBN 1-59140-180-1 (h/c) • US$79.95 • ISBN 1-59140-223-9 (s/c) • US$64.95• 280 pages • Copyright © 2004

Idea Group PublishingHershey • London • Melbourne • Singapore

, ��-��

#��

Brian Lehaney, PhD, University of Coventry, UKSteve Clarke, PhD, University of Luton, UK

Elayne Coakes, PhD, University of Westminster, UKGillian Jack, PhD, University of Glamorgan, UK

Beyond Knowledge Management provides abalance of conceptual and practical aspects ofknowledge management, offering the opportunity forstudents and practitioners to understand and effectivelyconsider knowledge management approaches in theirorganizations. Everyday examples are used to leadthe reader into the development of knowledgemanagement, then further into a conceptualperspective, and finally to the practical application ofknowledge management in organizations.

Beyond Knowledge Management provides a balance of conceptual and practicalaspects of Knowledge Management, offering the opportunity for students and practitionersto understand and effectively consider knowledge management approaches in theirorganizations.

- Gillian Jack, University of Galmorgan, UK

NEW RELEASE

An excellent addition to your library!

��

�� !�"

#��$��%�"��%""��& ��'��(�!�) �*��++�

ISBN 1-59140-126-7 (h/c) • US$79.95 • ISBN 1-59140-220-4 (s/c) • US$64.95eISBN 1-59140-127-5 • 296 pages • Copyright © 2004

,��-��

#�� .��

��/��

Maija Leena Huotari, Ph.D., University of Oulu, FinlandMirja Iivonen, Ph.D., University of Tampere, Finland

Trust in Knowledge Management and Systems inOrganizations aims at tying trust to knowledge management(KM). It highlights the complexity of the invisible phenomenonof trust challenged by the global economy. Fresh insights,novel theoretical frameworks, and empirical results and ideasfor future research are presented that differ from those sincethe 1950s. The eleven chapters (whose authors representinformation studies, economics, administrative scientists,mass communications, computer science and cognitivescience) explore the multidisciplinary nature of the conceptsof trust and KM. The concept of trust is analyzed by presentingits extensive description in relation to knowledge andinformation-intensive activities and systems for understandingthe dynamics of knowledge-based production at the levels of individuals, informationsystems, organizations, networks and society. Systems are considered from thesocial or the socio-technological perspective.

‘‘Trust has a crucial role to play when organizations aim at innovation and successful operation.Although trust has been studied for decades in various disciplines, the importance of trust hasprobably never before been more significant than it is today both in theory and practice.’’

- Maija Leena Huotari, University of Oulu, Finland &Mirja Iivonen, University of Tampere, Finland

NEW RELEASE

IDEA GROUP PUBLISHINGPublisher of IT books, journals and cases since 1988

Transformation Of Knowledge, Information And Data: Theory And Applications

Documents

Transcript of Transformation Of Knowledge, Information And Data: Theory And Applications