Maija-Leena Huotari, Mirja Iivonen, Mirja Iivonen - Transformation of Knowledge, Information and Data - Theory and Applications-IGI Global (2003)

Transformation of
Knowledge,
Information and Data:
Theory and Applications
Patrick van Bommel

University of Nijmegen, The Netherlands
Information Science Publishing

Hershey • London • Melbourne • Singapore
Acquisition Editor: Mehdi Khosrow-Pour
Senior Managing Editor: Jan Travers
Managing Editor: Amanda Appicello
Development Editor: Michele Rossi
Copy Editor: Alana Bubnis
Typesetter: Jennifer Wetzel
Cover Design: Mindy Grubb
Printed at: Yurchak Printing Inc.
Published in the United States of America by

Information Science Publishing (an imprint of Idea Group Inc.)
701 E. Chocolate Avenue, Suite 200
Hershey PA 17033
Tel: 717-533-8845
Fax: 717-533-8661
E-mail: cust@idea-group.com
Web site: http://www.idea-group.com
and in the United Kingdom by

Information Science Publishing (an imprint of Idea Group Inc.)
3 Henrietta Street
Covent Garden
London WC2E 8LU
Tel: 44 20 7240 0856
Fax: 44 20 7379 3313
Web site: http://www.eurospan.co.uk
Copyright © 2005 by Idea Group Inc. All rights reserved. No part of this book may be
reproduced 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 van
Bommel, 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 Data
A 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 expressed
in this book are those of the authors, but not necessarily of the publisher.
Transformation of
Knowledge, Information
and Data:
Theory and Applications
Table of Contents
Preface ............................................................................................................. vi
Section I: Fundamentals of Transformations
Chapter I
Transformation-Based Database Engineering ........................................... 1
Jean-Luc Hainaut, University of Namur, Belgium
Chapter II
Rule-Based Transformation of Graphs and the Product Type .............. 29
Renate Klempien-Hinrichs, University of Bremen, Germany
Hans-Jörg Kreowski, University of Bremen, Germany
Sabine Kuske, University of Bremen, Germany
Chapter III
From Conceptual Database Schemas to Logical Database Tuning ...... 52
Jean-Marc Petit, Université Clermont-Ferrand 2, France
Mohand-Saïd Hacid, Université Lyon 1, France
Chapter IV
Transformation Based XML Query Optimization ................................... 75
Dunren Che, Southern Illinois University, USA
Chapter V
Specifying Coherent Refactoring of Software Artefacts with
Distributed Graph Transformations ........................................................... 95
Paolo Bottoni, University of Rome “La Sapienza”, Italy
Francesco Parisi-Presicce, University of Rome “La Sapienza”, Italy
and George Mason University, USA
Gabriele Taentzer, Technical University of Berlin, Germany
Section II: Elaboration of Transformation Approaches
Chapter VI
Declarative Transformation for Object-Oriented Models .................. 127
Keith Duddy, CRC for Enterprise Distributed Systems Technology
(DSTC), Queensland, Australia
Anna Gerber, CRC for Enterprise Distributed Systems Technology
Michael Lawley, CRC for Enterprise Distributed Systems Technology
Kerry Raymond, CRC for Enterprise Distributed Systems Technology
Jim Steel, CRC for Enterprise Distributed Systems Technology
Chapter VII
From Conceptual Models to Data Models ............................................ 148
Antonio Badia, University of Louisville, USA
Chapter VIII
An Algorithm for Transforming XML Documents Schema into
Relational Database Schema .................................................................... 171
Abad Shah, University of Engineering & Technology (UET),
Pakistan
Jacob Adeniyi, King Saud University, Saudi Arabia
Tariq Al Tuwairqi, King Saud University, Saudi Arabia
Chapter IX
Imprecise and Uncertain Engineering Information Modeling in
Databases: Models and Formal Transformations ................................ 190
Z. M. Ma, Université de Sherbrooke, Canada
Section III: Additional Topics
Chapter X
Analysing Transformations in Performance Management .................. 217
Bernd Wondergem, LogicaCMG Consulting, The Netherlands
Norbert Vincent, LogicaCMG Consulting, The Netherlands
Chapter XI
Multimedia Conversion with the Focus on Continuous Media ......... 235
Maciej Suchomski, Friedrich-Alexander University of
Erlangen-Nuremberg, Germany
Andreas Märcz, Dresden, Germany
Klaus Meyer-Wegener, Friedrich-Alexander University of
Erlangen-Nuremberg, Germany
Chapter XII
Coherence in Data Schema Transformations: The Notion of Semantic
Change Patterns ........................................................................................ 257
Lex Wedemeijer, ABP Pensioenen, The Netherlands
Chapter XIII
Model Transformations in Designing the ASSO Methodology ......... 283
Elvira Locuratolo, ISTI, Italy
About the Authors ..................................................................................... 303
Index ............................................................................................................ 311

vi
Preface
Background
Data today is in motion, going from one location to another. It is more and more
moving between systems, system components, persons, departments, and orga-
nizations. This is essential, as it indicates that data is actually used, rather than
just stored. In order to emphasize the actual use of data, we may also speak of
information or knowledge.
When data is in motion, there is not only a change of place or position. Other
aspects 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, data
types, etc.
• Also, the interpretation of data may vary when it is passed on from one
person to another. Changes in interpretation are part of data semantics
rather 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 from
local authorities to the central government. In this context, we often see
changes 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 data
models are mapped to operational database specifications).
These examples illustrate just a few possibilities of changes in data. Numerous

other applications exist and everybody uses them all the time. Most applications
are 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, or

data, with changing format, interpretation, level of detail, development phase,
etc., is based on the concept of transformation. The generally accepted terms
conversion, mutation, modification, evolution, or revision may be used in
specific contexts, but the central concept is transformation.
Note that this definition covers well-known topics such as rewriting and
versioning, and that it is relevant for collaborative information systems and data
warehouses. Although data transformation is typically applied in a networked
context (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 in
industrial settings. Most of these techniques have one or more of the following
problems:
• 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 of
data 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 input
and output of those techniques? What are the problems in existing approaches?
What are the possibilities of a generic approach in important areas such as the
semantic 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 other
transformations, 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 or
documents (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 deal
with the basic assumptions underlying all transformation processes.
• Source. This is the structure to be transformed, or in other words, it is the
input 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 partly
automated transformation aiming at support, with sufficient possibilities
for interaction. As an example, a modeling process often is the mapping of
an informal view to a formal model. In this book, the input and output of
most 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 target
and the source is defined. Even when the transformation process has
been completed, it is important that the relation of the target with the
source remains clear. One way of establishing such a clear relation, is to
have the target defined in terms of the source. This is also helpful in
providing correctness proofs.
• Applicability. In some cases, transformations are not really general in the
sense 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 suffers
from 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? A
general setup for guaranteeing transformation correctness consists of three
steps.
ix
Figure 1. Framework for transformation of structures and operations
structure transformation target

source
structure structure
transformation kernel
source target
operations operations
operation transformation
• Wellformedness conditions. First, we describe the required properties of

the target explicitly. We prefer to have basic (independent) wellformedness
conditions here, as this facilitates the systematic treatment in the next
steps.
• Transformation algorithm. Next, we describe the construction of the
target on the basis of the source at hand. This construction process is
defined in the transformation algorithm, which may be enhanced using
guidance parameters. Guidance is interpreted as the development towards
target 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 to
prove 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 sequences
sometimes consist of a relatively small number of steps. In more complex prob-
lem areas, however, this is no longer possible. Then, transformation sequences
will be longer and due to the various options in each transformation step, the
outcome of the overall sequence is not a priori known. This is particularly the
case when non-deterministic (e.g., random or probabilistic) transformation pro-
cesses are considered.
x
Although the outcome is not a priori known, it is often desirable to predict the
nature 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, such
that transformation sequences can be considered by matrix multiplication.
We will illustrate the definition of a single-step matrix for two basic cases. In
the first case, consider a transformation in a solution space S where each input
x∈S has as possible output some y∈N(x), where N(x)⊆S and x∉N(x). So each
neighbor 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 some
y∈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 that
P(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 is
not equally likely. Consider a transformation in a solution space S where each
input x∈S has as possible output some y∈B(x), where B(x)⊆N(x) contains all
better neighbors of x. Then the probability P(x,y) for the transformation of x
into some y∈B(x) is given by the above mentioned formula (1). However, as a
result of accepting only improving transformations, this formula now does not
guarantee P(x,y) to be a stochastic matrix. The consequence of rejecting all
neighbours in N(x)-B(x) is, that a transformation may fail. So now we have to
consider 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 a

hill climbing transformation sequence. Note that the matrix underlying hill
climbing 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 in
a 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 of
Chapter I is databases: Transformation-Based Database Engineering. Here
we consider the basic theory of the transformation of data schemata, where
reversibility of transformations is also considered. We describe the use of basic
transformations 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 II
we will therefore focus on graph transformations: Rule-Based Transforma-
tion of Graphs and the Product Type. Graph transformations are based on
rules. 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, the
result (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 as
wellformedness of the output (i.e., the database) is addressed.
It is evident that graphs have to be transformed, but what about operations on
graphs? In systems design this corresponds with query transformation and op-
timization. We apply this to markup languages in Chapter IV: Transformation
Based XML Query Optimization. After representing document type defini-
tions in terms of a graph, we consider paths in the graph and an algebra for text
search. Equivalent algebraic expressions set the context for optimization, as we
know from database theory. Here we combine the concepts from previous chap-
ters, using rule-based transformations. However, the aim of the transformation
process now is optimization.
In Chapter V, the final chapter of Section I, we consider a highly specialized
fundament in the theory behind applications: Specifying Coherent Refactoring
of 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 to

reason about the behavior of the system under consideration.
Elaboration of
Transformation Approaches
In Section II, we consider elaborated approaches to transformation. The focus
of Chapter VI is object-oriented transformation: Declarative Transformation
for Object-Oriented Models. This is relevant not only for object-oriented data
models, 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 up
the 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 conceptual
models, 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 in
terms of the Entity-Relationship approach, whereas implementation models are
often expressed in terms of the relational model. Classical conceptual model
transformations thus describe the mapping from ER to relational models. Hav-
ing UML in the conceptual area and XML in the implementation area, we now
also focus on UML to XML transformations.
We proceed with this in the next chapter: An Algorithm for Transforming
XML 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 of
the 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 is
desirable. Note that the performance (efficiency) of such algorithms is a criti-
cal factor. The proposed approach is illustrated in a case study based on library
documents.
Transformations are often quite complex. If data is inaccurate, we have a fur-
ther complication. In Chapter IX we deal with this: Imprecise and Uncertain
Engineering Information Modeling in Databases: Models and Formal
Transformations. Uncertainty in information modeling is usually based on fuzzy
xiii
sets and probability theory. Here we focus on transformations in the context of

fuzzy Entity-Relationship models and fuzzy nested relations. In the models used
in this transformation, the known graphical representation is extended with fuzzy
elements, such as fuzzy type symbols.
Additional Topics
In Section III, we consider additional topics. The focus of Chapter X is the
application of transformations in a new area: Analysing Transformations in
Performance 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 the
addition 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 qualities
are relevant here, such as quality of service, quality of data, and quality of
experience. This chapter introduces specific transformations for media-type
changers, format changers, and content changers.
The focus of Chapter XII is patterns in schema changes: Coherence in Data
Schema Transformations: The Notion of Semantic Change Patterns. Here
we consider updates of data schemata during system usage (operational
schema). When the schema is transformed into a new schema, we try to find
coherence. 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 have
the redirection of a reference to an owner entity, along with extension and
restriction 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 called
is-a relationships). This is covered by the transformation of class hierarchies or
more general class graphs. It is evident that schema consistency is one of the
properties required. This is based on consistency of class definitions, with in-
xiv
ductive approaches by: (a) requiring that initialization adheres to application

constraints, and (b) all operations preserve all constraints.
Conclusions
This book contains theory and applications of transformations in the context of
information systems development. As data today is frequently moving between
systems, system components, persons, departments, and organizations, the need
for such transformations is evident.
When data is in motion, there is not only a change of place or position. Other
aspects 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 is
passed on from one person to another. Moreover, the level of detail may change
in the exchange of data between departments or organizations, and the systems
development 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 power
of current transformation approaches. We are confident that this book contrib-
utes to the understanding, the systematic treatment and refinement, and the
education 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 of
object-oriented databases. Information and Software Technology, 40(1), 1-14.
van Bommel, P. (1993, May). A randomised schema mutator for evolutionary
database optimisation. The Australian Computer Journal, 25(2), 61-69.
van Bommel, P. (1994). Experiences with EDO: An evolutionary database
optimizer. 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 database
populations and operations from the conceptual to the Internal level. In-
formation Systems, 19(2), 175-191.
xv
van Bommel, P., Lucasius, C.B. & Weide, Th.P. van der (1994). Genetic algo-
rithms for optimal logical database design. Information and Software
Technology, 36(12), 725-732.
van Bommel, P. & Weide, Th.P. van der (1992). Reducing the search space for
conceptual schema transformation. Data & Knowledge Engineering, 8,
269-292.
Acknowledgments
The editor gratefully acknowledges the help of all involved in the production of
this book. Without their support, this project could not have been satisfactorily
completed. A further special note of thanks goes also to all the staff at Idea
Group 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 reviewers
for chapters written by other authors. Thanks go to all those who provided
constructive and comprehensive reviews. Special thanks also go to the publish-
ing team at Idea Group Publishing, in particular to Michele Rossi, Carrie
Skovrinskie, Jan Travers, and Mehdi Khosrow-Pour.
In closing, I wish to thank all of the authors for their insights and excellent
contributions to this book.
Patrick van Bommel, PhD

Nijmegen, The Netherlands
February 2004
pvb@cs.kun.nl
http://www.cs.kun.nl/~pvb
Section I
Fundamentals of
Transformations
Transformation-Based Database Engineering 1
Chapter I
Transformation-Based
Database Engineering
Jean-Luc Hainaut, University of Namur, Belgium
Abstract
In this chapter, we develop a transformational framework in which many

database engineering processes can be modeled in a precise way, and in
which properties such as semantics preservation and propagation can be
studied rigorously. Indeed, the transformational paradigm is particularly
suited to database schema manipulation and translation, that are the basis
of such processes as schema normalization and optimization, model
translation, reverse engineering, database integration and federation or
database migration. The presentation first develops a theoretical framework
based on a rich, wide spectrum specification model. Then, it describes how
more complex transformations can be built through predicate-based filtering
and composition. Finally, it analyzes two major engineering activities,
namely database design and reverse engineering, modeled as goal-oriented
schema transformations.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
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 long
been considered one of the ultimate goals of software engineering. For instance,
Balzer (1981) and Fikas (1985) consider that the process of developing a
program [can be] formalized as a set of correctness-preserving transfor-
mations [...] aimed to compilable and efficient program production. In this
context, according to Partsch (1983),
“a transformation is a relation between two program schemes P
and P’ (a program scheme is the [parameterized] representation
of a class of related programs; a program of this class is obtained
by instantiating the scheme parameters). It is said to be correct if
a certain semantic relation holds between P and P’.”
These definitions still hold for database schemas, which are special kinds of
abstract program schemes. The concept of transformation is particularly attrac-
tive in this realm, though it has not often been made explicit (for instance, as a
user tool) in current CASE tools. A (schema) transformation is most generally
considered to be an operator by which a data structure S1 (possibly empty) is
replaced by another structure S2 (possibly empty) which may have some sort of
equivalence with S1. Some transformations change the information contents of
the source schema, particularly in schema building (adding an entity type or an
attribute) and in schema evolution (removing a constraint or extending a
relationship type). Others preserve it and will be called semantics-preserving or
reversible. Among them, we will find those which just change the nature of a
schema object, such as transforming an entity type into a relationship type or
extracting a set of attributes as an independent entity type.
Transformations that are proved to preserve the correctness of the original
specifications have been proposed in practically all the activities related to
schema engineering: schema normalization (Rauh, 1995), DBMS2 schema
translation (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), reverse
engineering (Bolois, 1994; Casanova, 1984; Hainaut, 1993, 1993b), schema
optimization (Hainaut, 1993b; Halpin, 1995) database interoperability (McBrien,
2003; Thiran, 2001) and others. The reader will find in Hainaut (1995) an
illustration of numerous application domains of schema transformations.
The goal of this chapter is to develop and illustrate a general framework for
database transformations in which all the processes mentioned above can be
formalized and analyzed in a uniform way. We present a wide spectrum

formalism in which all the information/data models currently used can be
specified, and on which a set of basic transformational operators is defined. We
also study the important property of semantics-preservation of these operators.
Next, we explain how higher-level transformations can be built through three
mechanisms, 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 reverse
engineering then we conclude the chapter.
Schema Transformation Basics

This section describes a general transformational theory that will be used as the
basis for modeling database engineering processes. First, we discuss some
preliminary issues concerning the way such theories can be developed. Then, we
define a wide-spectrum model from which operational models (i.e., those which
are of interest for practitioners) can be derived. The next sections are dedicated
to the concept of transformation, to its semantics-preservation property, and to
the means to prove it. Finally, some important basic transformations are
described.
• Warning. In the database world, a general formalism in which database
specifications can be built is called a model. The specification of a database
expressed in such a model is called a schema.
Developing Transformational Theories
Developing a general purpose transformational theory requires deciding on the

specification formalism, i.e., the model, in which the schemas are expressed and
on the set of transformational operators. A schema can be defined as a set of
constructs (entity types, attributes, keys, indexes, etc.) borrowed from a definite
model whose role is to state which constructs can be used, according to which
assembly rules, in order to build valid schemas. For simplicity, the concept of
entity 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 which
are intended to produce relational schemas from ERA schemas, the most
interesting 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 generality
and its abstraction level, this model defines the scope of the theory, that can
address a more or less wide spectrum of processes. For instance, building a
theory on the relational model will allow us to describe, and to reason on, the
transformation of relational schemas into other relational schemas. The 1NF4
normalization theory is a popular example. Another example would be a
transformational theory based on the ORM (Object-Role model) that would
provide techniques for transforming (normalizing, optimizing) conceptual schemas
into 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-relational
conversion.
To identify such models, let us consider a set of models Γ that includes, among
others, all the operational formalisms that are of interest for a community of
practitioners, whatever the underlying paradigm, the age and the abstraction
level of these formalisms. For instance, in a large company whose information
system 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 likely
to include several variants of the ERA model, UML class diagrams, several
relational models (e.g., Oracle 5 to 10 and DB2 UDB), the object-relational
model, the IDMS and IMS models and of course the standard file structure model
on which many legacy applications have been developed.
Let us also consider the transitive inclusion relation “≤” such that M ≤ M’, where
M≠M’ and M,M’ ∈ Γ, means that all the constructs of M also appear in M’.5 For
instance, 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 valid
schema 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 abstract
constructs, typically nodes, edges and labels. An ERA schema S comprising an
entity 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 them
being a natural abstraction of one or several constructs of lower-level models.
This model should include, among others, the concepts of object type, attribute
and inter-object association, so that the contents of schema S will be represented
in 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 to
develop a transformational theory relying on a single model. Considering the
context-dependent definition of Γ, M0 and M*, we cannot assert that these
concepts are unique. Therefore, there is no guarantee that a universal theory can
be built.
Approaches based on M0 generally define data structures as semantics-free
binary graphs on which a small set of rewriting operators are defined. The
representation of an operational model M such as ERA, relational or XML, in M0
requires some additional features such as typed nodes (object, attribute, associa-
tion and roles for instance) and edges, as well as ad hoc assembly rules that
define patterns. A transformation specific to M is also defined by a pattern, a sort
of macro-transformation, defined by a chain of M0 transformations. McBrien
(1998) is a typical example of such theories. We can call this approach
constructive 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. An
operational model M is defined by specializing M*, that is, by selecting a subset
of concepts and by defining restrictive assembly rules. For instance, a relational
schema 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 object
type) and a set of uniqueness (keys) and inclusion (foreign keys) constraints.
This model does not include the concept of association. The transformations of
M are those of M* which remain meaningful. This approach can be qualified by
specialization or top-down, since an operational model and its transformational
operators are defined by specializing (i.e., selecting, renaming, restricting) M*
constructs and operators. DB-MAIN (Hainaut, 1996b) is an example of this
approach. 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 transforming

database schemas at different levels of abstraction, and according to various
6 Hainaut
paradigms. Some processes, such as normalization, integration and optimization

operate in a single model, and will require intra-model transformations. Other
processes, such as logical design, use two models, namely the source and target
models. Finally, some processes, among others, reverse engineering and feder-
ated database development, can operate on an arbitrary number of models (or
on 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 their
schemas.
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 a
description of data structures. It is made up of specification constructs which
can be, for convenience, classified into the usual three abstraction levels, namely
conceptual, logical and physical. We will enumerate some of the main constructs
that can appear at each level:
• A conceptual schema comprises entity types (with/without attributes;
with/without identifiers), super/subtype hierarchies (single/multiple, total
and 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 (a
generic term for index, calc key, etc.), physical data types, bag and list
multivalued attributes, and other implementation details.
It is important to note that these levels are not part of the model. The schema of
Figure 1 illustrates some major concepts borrowed to these three levels. Such a
hybrid schema could appear in reverse engineering.
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), logical
constructs (e.g., record type ORDER, with various kinds of fields including
an array, foreign keys ORIGIN and DETAIL.REFERENCE) and physical
objects (e.g., table PRODUCT with primary key PRO_CODE and indexes
PRO_CODE and CATEGORY, table space PRODUCT.DAT) (Note that the
identifier of ACCOUNT, stating that the accounts of a customer have
distinct Account numbers, makes it a dependent or weak entity type.)
PERSON
Name
Address
T
PRODUCT ORDER
EMPLOYEE
PRO_CODE ORD-ID CUSTOMER
Employe Nbr
CATEGORY DATE_RECEIVED Customer ID
Date Hired
DESCRIPTION ORIGIN id: Customer ID
UNIT_PRICE DETAIL[1-5] array id: Employe Nbr
id: PRO_CODE REFERENCE 0-N
acc QTY-ORD
acc: CATEGORY id: ORD-ID of
ref: ORIGIN
ref: DETAIL[*].REFERENCE 1-1
ACCOUNT
PRODUCT.DAT
Account NBR
PRODUCT Amount
id: of.CUSTOMER
Account NBR
One remarkable characteristic of wide spectrum models is that all the transfor-
mations, including inter-model ones, appear as intra-model operators. This has
highly 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, most
transformations dedicated to COBOL data structure reverse engineering appear
to be valid for relational schemas as well. This strongly reduces the number of
operators. Secondly, any new model can profit from the techniques and
reasoning that have been developed for current models. For instance, designing
methods for translating conceptual schemas into object-relational structures or
into 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 NF2
model (Hainaut, 1989, 1996). This semantics will allow us to analyze the
properties of transformations, and particularly to precisely describe how, and
under which conditions, they propagate and preserve the information contents of
schemas.
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, its
non-regularity and the absence of essential concepts. On the contrary, a
carefully defined subset of the UML model could be be a realistic basis for
constructive approaches.
Specifying Operational Models with the GER
In this section, we illustrate the specialization mechanism by describing a

popular operational formalism, namely the standard 1NF relational model. All the
other 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 can
therefore be defined as in Figure 2. A GER schema made up of constructs from
the 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 a
specific RDBMS can be specified. These rules generally include limitations such
as no more than 64 columns per index, or the total length of the components
of 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 nullable column
with cardinality [0-1]
single-valued and atomic attribute not null column
with cardinality [1-1]
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
Figure 3. Defining the main technical constructs of relational data

structures 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
Transformation: Definition
The definitions that will be stated here are model-independent. In particular, they
are valid for the GER model, so that the examples will be given in the latter. Let
us denote by M the model in which the source and target schemas are expressed
by S the schema on which the transformation is to be applied and by S’ the schema
resulting from this application. Let us also consider sch(M), a function that returns
the set of all the valid schemas that can be expressed in model M, and inst(S), a
function 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 source
construct 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 can
be defined by structural predicates. T is therefore defined by the minimal
precondition P that any construct C must satisfy in order to be transformed
by T, and the maximal postcondition Q that T(C) satisfies. T specifies the
rewriting rule of Σ.
• t is the instance mapping from inst(S) onto inst(S’), that states how to
produce the T(C) instance that corresponds to any instance of C. If c is an
instance of C, then c’ = t(c) is the corresponding instance of T(C). t can be
specified through any algebraic, logical or procedural expression.
Figure 4. Two mappings of schema transformation Σ ≡ <T,t> (The inst_of

arrow from x to X indicates that x is an instance of X.)
T
C C' = T(C)
inst_of inst_of
t
c c' = t(c)
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 can
undo the result of the former under certain conditions that will be detailed in the
next section.
Reversibility of a Transformation
The extent to which a transformation preserves the information contents of a

schema is an essential issue. Some transformations appear to augment the
semantics of the source schema (e.g., adding an attribute), some remove
semantics (e.g., removing an entity type), while others leave the semantics
unchanged (e.g., replacing a relationship type with an equivalent entity type).
The latter are called reversible or semantics-preserving. If a transformation
is reversible, then the source and the target schemas have the same descriptive
power, and describe the same universe of discourse, although with a different
presentation.
• A transformation Σ1 = <T1,t1> = <P1,Q1,t1> is reversible, iff there exists
a 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 the
inverse of Σ1, but the converse is not true8. For instance, an arbitrary
instance 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 symmetrically
reversible. 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 the
concept of correctness-preserving transformation aimed at compilable and
efficient program production.
We have discussed the concept of reversibility in a context in which some kind
of 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 entity
type with name et_name from its schema, clearly is not a semantics-preserving
operation, since its mapping t has no inverse. However, it has an inverse
transformation, 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 developed
to evaluate the reversibility of a transformation. More precisely, this system
relies on a limited set of NF2 transformational operators whose reversibility has
been proven, and that can generate a large number of GER transformations.
Basically, the system includes five families of transformations, that can be
combined to form more complex operators:
• denotation, through which a new object set is defined by a derivation rule
based on existing structures,
• project-join which is a variant of the decomposition theorem,
• composition which replaces two relations by one of them and their
composition,
• 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 NF2
model in which these basic transformations have been built, the latter can be
applied to operational schemas. Figure 5 shows how we have defined a
decomposition 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 (Figure
5, top-right).
12 Hainaut
Figure 5. Proving the SR property of the decomposition of a relationship

type according to a multivalued dependency (here an FD)
source schema target schema

A B A
0-N 0-N T1 coex: R2.C[*] 0-1 R1 0-N B
R ⇒ R1.B
⇐
GER 0-N T1'
0-N
R2 0-N C
C
R: A → B
T11 ⇓⇑ T11' T13 ⇑ ⇓ T13'

entities: A,B,C T12 entities:A,B,C
R(A,B,C) ⇒ R1(A,B)
NF2 ⇐
A →B T12'
R2(A,C)
R1[A]=R2[A]
Since the the GER ↔ NF2 mappings are symmetrically reversible and the
project-join is an SR-transformation, the ERA transformation is symmetrically
reversible 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 reversible
operator. We observe how this constraint translates into a coexistence constraint
in the GER model that states that if an A entity is connected to a B entity, it must
be connected to at least one C entity as well, and conversely.
The reader interested in a more detailed description of this proof system is
refered 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, relationship
type and attribute, six mutation transformations can be defined. In Figure 6, the
couples of operators Σ1 to Σ3, show them applied on typical schema fragments.
The transformations Σ4 are not primitive since they can be defined by combining
other mutations. However, they have been added due to their usefulness. More
Figure 6. Six mutation transformations Σ1 to Σ3 (Though not primitive,

compound transformations Σ4 are shown as well.)
source schema target schema comment

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

A A B
Σ2
A1 0-N r 0-5 B ⇒ A1 A1[0-5]
r into reference attribute B.A1
(T2) and conversely (T2').
id: A1
⇐ id: A1 ref: A1[*]
T2'
T3 Transforming attribute A2 into

A A EA2
Σ3
A1 ⇒ A1 0-5 ra2 1-N A2
entity type EA2 (T3) and
conversely (T3').
⇐
A2[0-5] A3 id: A2
A3
T3'
T4 Not a primitive operator. T4

A EA2
A1 ⇒ A
A1 0-5 ra2 1-1
A2
can be defined by application
of T3 to EA2.A2, then of T1' to
Σ4 ⇐
A2[0-5] id: ra2.A
A3 EA2 in the schema above.
A3 A2
T4' Note that the EA2 entities
depending on the same A
entity have distinct A2 values
(id:ra2.A,A2).
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 tool
associated with the DB-MAIN methodologies includes a kit of about 30 basic
operators that have proven sufficient for most engineering activities. When
necessary, user-defined operators can be developed through the meta functions
of the tool (Hainaut, 1996b). We will describe some of the basic operators.
Expressing supertype/subtype hierarchies in DMS that do not support them
explicitly is a recurrent problem. The technique of Figure 7 is one of the most
commonly used (Hainaut, 1996c). It consists in representing each source entity
type by an independent entity type, then to link each subtype to its supertype
through a one-to-one relationship type. The latter can, if needed, be further
transformed into foreign keys by application of Σ2-direct (T2).
14 Hainaut
Figure 7. Transforming an is-a hierarchy into one-to-one relationship

types and conversely

An is-a hierarchy is replaced
A A
by one-to-one relationship
A1 T5 A1
types. The exclusion constraint
A2
⇒ r 0-1 A2
excl: s.C
0-1 s
(excl:s.C,r.B) states that an A
Σ5 D ⇐ 1-1 r.B 1-1 entity cannot be simultane-
ously linked to a B entity and a
B C T5' B C
C1
C entity. It derives from the
B1 B1 C1
B2 C2 disjoint property (D) of the
B2 C2
subtypes.
Figure 8. Converting an array into a set-multivalued attribute and

conversely
T6 Array A2 (left) is transformed
A A
A1 ⇒ A1
into a multivalued compound
attribute A2 (right), whose
A2[0-5] array
A3 ⇐ A2[0-5]
Index values are distinct wrt
Σ6 T6' Value component Index
A3 (id(A2):Index). The latter
id(A2): indicates the position of the
Index value (Value). The domain of
Index is the range [1..5].
Figure 9. Transforming serial attributes into a multivalued attribute and

conversely
T7 The serial attributes {A2X,
A A
A1 ⇒ A1
A2Y, A2Z} are transformed into
the multivalued compound
⇐
A2X A2[3-3]
A2Y Dimension attribute A2 where the values
A2Z T7' Value (Value) are indexed with the
Σ7 A3 A3 distinctive suffix of the source
id(A2): attributes, interpreted as a
Dimension dimension (sub-attribute
Dimension, whose domain is
dom(A2.Dimension) = {'X','Y','Z'} the set of prefixes).
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 an
array, operators to transform them into pure set-oriented constructs are most
useful. Transformations Σ6 in Figure 8 are dedicated to arrays. Similar operators
have been defined for the other types of containers.
Attributes defined on the same domain and the name of which suggests a spatial
or temporal dimension (e.g., departments, countries, years or pure numbers) are
called serial attributes. In many situations, they can be interpreted as the
representation of an indexed multivalued attributes (Figure 9). The identification

of 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 operators

in which each transformation applies on the result of the previous one. The
transformation Σ8 in Figure 10, illustrated by a concrete example, transforms a
complex relationship type R into a sort of bridge entity type comprising as many
foreign keys as there are roles in R. It is defined by the composition of Σ1-direct
and Σ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 chain
of four elementary operators. The first one transforms the serial attributes
Expense-2000, ..., Expense-2004 into multivalued attribute Expense comprising
sub-attributes Year (the dimension) and Amount (transformation Σ7-direct). The
second one extracts this attribute into entity type EXPENSE, with attributes Year
and Amount (transformation Σ4-direct). Then, the same operator is applied to
Figure 10. Transformation of a complex relationship type into relational

structures

COMPANY COUNTRY
The relationship type
EXPORT COMPANY
Cy_Name Ctry_Name
export is first transformed
Prod_ID Cy_Name
id: Cy_Name id: Ctry_Name Ctry_Name
into an entity type + three
id: Cy_Name
T8 Cy_Name many-to-one relationship
0-N 0-N ⇒ Volume types. Then, the latter are
converted into foreign keys.
Σ8
export
Volume
⇐ id: Ctry_Name
Prod_ID
PRODUCT
Prod_ID
T8' Cy_Name id: Prod_ID
ref: Cy_Name
0-N
ref: Prod_ID
PRODUCT ref: Ctry_Name COUNTRY
Prod_ID Ctry_Name
id: Prod_ID id: Ctry_Name
16 Hainaut
Figure 11. Extracting a temporal dimension from serial attributes

The serial attributes are
Project Project
first transformed into a
Dep# T9 Dep#
multivalued attribute, which
InitialBudget
Expense-2000
⇒ InitialBudget
in turn is extracted as
Expense-2001
Expense-2002
⇐ 5-5 external entity type
EXPENSE. The dimension
T9' expense
Expense-2003 attribute (Year) is also
Σ9 Expense-2004 Amount
extracted as entity type
1-N YEAR. Finally, EXPENSE
is mutated into relationship
YEAR type expense.
Year
id: Year
dom(Year) = [2000..2004]
Figure 12. Three examples of predicate-driven transformation

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 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_per_RT(1 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.
attribute Year, yielding entity type YEAR, with attribute Year. Finally, the entity
type EXPENSE is transformed into relationship type expense (Σ1-inverse).
Predicate-Driven Transformations
A predicate-driven transformation Σp applies an operator Σ to all the schema

objects that meet a definite predicate p. It will be specified by Σ(p). p is a
structural predicate that states the properties through which a class of patterns
can be identified. Interestingly, a predicate-based transformation can be inter-
preted as a user-defined elementary operator. Indeed, considering the standard
definition Σ = <P,Q,t>, we can rewrite Σp as Σ*(true) where Σ* = <P∧p,Q,t>. In
general, 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 constructs
resulting from the application of Σp, and only them.
We give in Figure 12 some useful transformations that are expressed in the
specific language of the DB-MAIN tool, which follows the Σ(p) notation. Most
predicates 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
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 transformation

made up of predicate-driven operators. It is designed to transform any schema
expressed 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 to
identifying the constructs that do not belong to it. Except when M ≤ M’, an
arbitrary schema S expressed in M may include constructs which violate M’.
Each construct that can appear in a schema can be specified by a structural
predicate. Let PM 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 specified
by a structural predicate. Let PM/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 in
Figure 12, ROLE_per_RT(3 N) is a predicate that identifies N-ary relationship types
that 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 database
model. Finally, we observe that each such set as PM can be perceived as a single
predicate formed by anding its components.
Let us now consider predicate p ∈ P M/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 invalid

constructs defined by p. Proceeding in the same way for each component of PM/M’
provides us with a series of operators that can transform any schema in model
M into schemas in model M’. We call such a series a transformation plan, which
is the practical form of any model-driven transformation. In real situations, a plan
can be more complex than a mere sequence of operations, and may comprise
loops to process recursive constructs for instance.
In addition, transformations such as those specified above may themselves be
compound, so that the set of required transformations can be quite large. In such
cases, it can be better to choose a transformation that produces constructs that
are not fully compliant with M’, but that can be followed by other operators which
complete the job. For instance, transforming a multivalued attribute can be
18 Hainaut
obtained by an ad hoc compound transformation. However, it can be thought

more 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 foreign
key (Σ2-direct). This approach produces transformation plans which are more
detailed and therefore less readable, but that rely on a smaller and more stable
set of elementary operators.
The transformation toolset of DB-MAIN includes about 30 operators that have
proven sufficient to process schemas in a dozen operational models. If all the
transformations 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 semantically
equivalent to the former. This property is particularly important for
conceptual→logical transformations. Figure 13 sketches, in the form of a script,
a simple transformation plan intended to produce SQL2 logical schemas from
ERA conceptual schemas. Actual plans are more complex, but follow the
approach developed in this section.
It must be noted that this mechanism is independent of the process we are
modeling, and that similar transformation plans can be built for processes such
as conceptual normalization or reverse engineering. Though model-driven
transformations provide an elegant and powerful means of specification of many
aspects of most database engineering processes, some other aspects still require
human expertise that cannot be translated into formal rules.
Figure 13. Simple transformation plan to derive a relational schema from

any ERA conceptual schema (To make them more readable, the
transformations have been expressed in natural language instead of in the
DB-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 operator Σ4-direct; each multivalued attribute directly
types depending on an entity type is replaced by an entity
type;
5 repeat steps 3 to 4 until the schema does not to cope with multi-level attribute structures;
include complex attributes any more
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 step 6 fails in case of missing identifier; a technical
technical identifier to the relevant entity types and attribute is associated with the entity type that will be
apply step 6 referenced by the future foreign key;
Figure 14. Standard strategy for database design
Users requirements
Conceptual design Conceptual schema
Database design
Logical design Logical schema
Physical design Physical schema
Coding View design
Users views
Operational code
Transformation-Based Database Design

Most textbooks on database design of the eighties and early nineties propose a
five-step approach that is sketched in Figure 14. Through the Conceptual
Design phase, users’ requirements are translated into a conceptual schema,
which is the formal and abstract expression of these requirements. The Logical
Design phase transforms the conceptual schema into data structures (the logical
schema) 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, the
logical schema is refined and augmented with technical specifications that make
it implementable into the target DMS and that gives it acceptable performance.
From the logical schema, users’ views are derived that meet the requirements
of classes of users (View Design). Finally, the physical schema and the users
views 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 be
modeled by (the structural part of) transformation DB-design:
code = DB-design(UR)
where code denotes the operational code and UR the users requirements.
20 Hainaut
Denoting the conceptual, logical and physical schemas respectively by CS, LS

and PS and the conceptual design, logical design, physical design and coding
phases by C-design, L-design, P-design and Coding, we can refine the
previous 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 be

described by transformation plans. The level of formality of these processes
depends on the methodology, on the existence of CASE support and of non-
functional requirements such as performance and robustness, that generally
require human expertise. For instance, conceptual design (C-design) is a highly
informal process based on human interpretation of complex information sources,
while logical design can be an automated process completely described by a
transformation plan. Anyway, these processes can be decomposed into sub-
processes that, in turn, can be modeled by transformations and described by
transformation 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 Basic
Analysis, through which informal or semi-formal information sources are
analyzed and their semantic contents are translated into conceptual structures,
and (Conceptual) Normalization, through which these raw structures are given
such additional qualities as readability, normality, minimality, extensibility, com-
pliance with representation standards, etc. (Batini, 1992; Blaha, 1998). This
second process is more formal than the former, and is a good candidate for
transformational modeling. The plan of Figure 15, though simplistic, can improve
the 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,
Figure 15. Simple transformation plan to normalize ERA conceptual

schemas
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 transformation of Fig. 5;
FD holds
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 a complex attribute is compound, multivalued and has a
entity types local identifier; it is assumed to express an autonomous
entity type; operator Σ4-inverse;
namely ideal and empirical. The ideal design produces a logical schema that
meets two requirements only: it complies with the target logical model M and it
is semantically equivalent to the conceptual schema. According to the transfor-
mational paradigm, the logical design process is a M-driven transformation
comprising SR-operators only. The plan of Figure 13 illustrates this principles for
relational 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, relying
on experience and intuition, rather than on standardized procedures. Other
requirements such as space and time optimization often are implicitly taken into
account, making formal modeling more difficult, if not impossible. Though no
comprehensive model-driven transformations can describe such approaches,
essential fragments of empirical design based on systematic and reproducible
rules can be described by compound or predicate-driven transformations.
Coding
Quite often overlooked, this process can be less straightforward and more
complex than generally described in the literature or carried out by CASE tools.
Indeed, any DMS can cope with a limited range of structures and integrity
constraints for which its DDL provides an explicit syntax. For instance, plain
SQL2 DBMSs know about constraints such as machine value domains, unique
keys, foreign keys and mandatory columns only. If such constructs appear in a
physical schema, they can be explicitly declared in the SQL2 script. On the other
hand, all the other constraints must be either ignored or expressed in any other
22 Hainaut
way, at best through check predicates or triggers, but more frequently through
procedural sections scattered throughout the application programs. Distinguish-
ing the DDL code from the external code, the operational code can be split into
two 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 be
automated.
Transformation-Based Database Reverse

Engineering
Database reverse engineering is the process through which one attempts to
recover or to rebuild the technical and functional documentation of a legacy
database. Intensive research in the past decade have shown that reverse
engineering generally is much more complex than initially thought. We can put
forward two major sources of difficulties. First, empirical design has been, and
still is, more popular than systematic design. Second, only the codeddl part of the
code provides a reliable description of the database physical constructs.
Empirical design itself accounts for two understanding problems. First, it often
relies on non-standard, unpublished, translation rules that may be difficult to
interpret. Second, actual logical schemas often are strongly optimized, so that
extracting a conceptual schema from the logical schema involves understanding
not only how the latter has been translated in the target model, but also how, and
according 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 to
identify code sections that cope with implicit, i.e., undeclared, constructs such as
decomposed (flattened) fields or referential constraints. The second problem
concerns the correct interpretation of these code fragments, that translates into
constructs to be added to the physical schema.
The whole process is described in Figure 16. It shows that database reverse
engineering is decomposed into two main sub-processes, namely Extraction and
Conceptualization. The objective of the Extraction process is to recover the
Figure 16. Main processes of database reverse engineering
Logical schema Conceptual schema
Conceptualization
Database reverse engineering Logical schema
Cleaning
Extraction
Physical schema
Parsing Refinement
codeddl codeext
complete logical schema of the legacy database. It includes three activities:

Parsing the DDL code to extract the raw physical schema, schema Refinement
through which implicit and hidden constructs are elicited from external code (as
well as from other sources, such as the data themselves, but we will ignore them
in this discussion) and Cleaning, in which the technical constructs of the physical
schema are removed.
The second main sub-process, Conceptualization, is intended to derive a
plausible conceptual schema from the logical schema. It consists in identifying
the trace of the translation of conceptual constructs, then in replacing them with
their source. For instance, a foreign key is interpreted as (i.e., replaced by) a
many-to-one relationship type.
The transformational interpretation of the reverse engineering process is
straighforward:
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)
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 and

database reverse engineering processes, we can state the following equivalence
rules, 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 reverse
engineering can be modeled by transformations, then database reverse engineer-
ing is, to a large extent, the inverse of database design. This induces important
consequences. In particular:
• database reverse engineering requires a deep understanding of empirical
database design methodologies, and
• the Conceptualization process can be analyzed and specified by identify-
ing the strategies and the transformations that are most popular in empirical
logical 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 for
conceptualizing logical schemas. This process can be supported by predicate-
driven and model-driven transformations, but, even more than for forward
engineering, reverse engineering heavily relies on human expertise. An in-depth
description of a wide-scope reverse engineering methodology can be found in
Hainaut (2002).
Conclusions and Perspectives

In this chapter, we have shown that schema transformation can be used as a
major paradigm in database engineering. In particular, being formally defined, it
can be used to precisely model complex processes and to reason on their
properties such as semantics preservation. It has also been used to derive new
processes from former ones, as illustrated by the formalization of database
reverse engineering as the inverse of database design.
Due to their formality, transformations can be implemented in CASE tools, either
as implicit operators, or as tools that are explicitly made available to the
developer. Two implementations are worth being mentioned, namely Rosenthal
(1994) and Hainaut (1996b). The latter reference describes the DB-MAIN
CASE environment which includes a transformation toolbox as well as special
engines 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 database
interoperability, in which mediation between existing databases (McBrien, 2003)
and data wrapping (Thiran, 2001) can be formalized and automated thanks to the
use of transformational operators. In this domain, data instance transformations
are modeled by the t part of the transformations. Specifying how the source
schema is transformed into the target schema automatically provides a chain of
instance transformations that are used to generate the data conversion code that
is 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 Design
for Database Applications. Prentice Hall.
Bolois, G. & Robillard, P. (1994). Transformations in reengineering techniques.
Proceedings of the Fourth Reengineering Forum ‘Reengineering in
Practice’. Victoria, Canada.
Casanova, M. & Amaral De Sa, A. (1984). Mapping uninterpreted schemes into
entity-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 site
engineering. Proceedings of the Fifth International Workshop on Web
Site Evolution, Amsterdam, September 2003. IEEE CS Press.
Fagin, R. (1977). Multivalued dependencies and a new normal form for relational
databases. 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 the
IFIP 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. Tutorial
notes, VLDB’95, Zürich, Switzerland, September 1995. Retrieved from the
WWW: 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, LIBD
lecture 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 to
a theory of database reverse engineering. Proceedings of the IEEE
Working 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 the
12th International Conference on ER Approach, Arlington-Dallas, ER
Institute.
Hainaut, J.L., Englebert, V., Henrard, J., Hick, J.M. & Roland, D. (1996b).
Database reverse engineering: From requirements to CASE tools. Journal
of 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 the
Conference on the ER Approach, Cottbus, October 1996, LNCS.
Springer-Verlag.
Halpin, T. A. & Proper, H. A. (1995). Database schema transformation and
optimization. Proceedings of the 14th International Conference on ER/
OO Modelling (ERA).
Jajodia, S., Ng, P. A. & Springsteel, F. N. (1983). The problem of equivalence
for entity-relationship diagrams. IEEE Trans. on Software Engineering,
SE, 9(5).
Kobayashi, I. (1986). Losslessness and semantic correctness of database
schema transformation: Another look of schema equivalence. Information
Systems, 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 for
schema transformation. Data & Knowledge Engineering, 28(1), 47-71.
McBrien, P. & Poulovassilis, A. (2003). Data integration by bi-directional
schema transformation rules. Proceedings of 19th International Con-
ference on Data Engineering (ICDE’03). IEEE Computer Society
Press.
Navathe, S. B. (1980, June). Schema analysis for database restructuring. ACM
TODS, 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 on
Conceptual Modeling, LNCS, 1021, 191-203. Springer.
Rauh, O. & Stickel, E. (1995). Standard transformations for the normalization of
ER schemata. Proceedings of the CAiSE’95 Conference, Jyväskylä,
Finland, LNCS. Springer-Verlag.
Rosenthal, A. & Reiner, D. (1988). Theoretically sound transformations for
practical database design. Proceedings of Entity-Relationship Approach.
Rosenthal, A. & Reiner, D. (1994). Tools and transformations - Rigourous and
otherwise - 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 also
belongs to M’ exactly means would require a development which would be
useless in this paper. Therefore, we will rely on an intuitive meaning of this
relation only. For example, the concepts of field and of column will be
considered the same though some slight differences exist between them.
The same can be said for entity type (ERA), object class (UML), segment
type (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, it
states that the schema {R(A,B,C); A→→BC} 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 and
r2 of R2 to enjoy the inverse property r1 = (r1*r2)[A,B]. Therefore, this
transformation is not symmetrically reversible. This example and some of
its variants are developed in (Hainaut, 1996).
9
Data Definition Language: that part of a database language intended to
declare the data structures of the database.
Rule-Based Transformation of Graphs and the Product Type 29
Chapter II
Rule-Based
Transformation of
Graphs and the
Product 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 for

modeling data-processing systems. It recalls the structuring concept of
graph transformation units which allows for transforming graphs in a rule-
based, modularized, and controlled way. In order to get a flexible typing
mechanism and a high degree of parallelism, this structuring concept is
extended to the product of transformation units. Moreover, it is demonstrated
how 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 applications

where data, knowledge, and information can be modeled as graphs and
their transformation can be specified by means of rules in an adequate way.
Introduction
The area of graph transformation brings together the concepts of rules and
graphs with various methods from the theory of formal languages and from the
theory of concurrency, and with a spectrum of applications (Figure 1).
Graphs are important structures in computer science and beyond to represent
complex system states, networks, and all kinds of diagrams. The application of
rules provides graphs with a dynamic dimension yielding a rich methodology of
rule-based graph transformation. The three volumes of the Handbook of
Graph Grammars and Computing by Graph Transformation give a good
overview 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 graph
transformation in the literature, nearly all of them contain five basic features.
• Graphs to represent complex relations among items in an intuitive but
mathematically 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 graphs
explicitly as they are embodied in the rules.
• Graph class expressions to specify special classes of graphs to be used
as initial as well as terminal graphs.
• Control conditions to regulate the applications of rules such that the
inherent non-determinism of rule application can be cut down.
Figure 1. Main ingredients of graph transformation
rules graphs
theory application
A particular choice of these five features establishes a graph transformation

approach. A selection of rules, initial and terminal graphs, and a control condition
is often called a graph transformation system or a graph grammar if there is
a single initial graph as axiom (or a finite set of initial graphs likewise). Following
Kreowski and Kuske (1999a), we use the term graph transformation unit for
such a selection where we also allow importing other graph transformation units
for 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 graph
transformation. As graphs are derived from graphs by applying rules, the obvious
semantics is a binary relation on graphs or a binary relation between initial and
terminal graphs if one provides a subtyping mechanism. To overcome this quite
restricted kind of typing, we introduce product types. The basic notion is a
product of graph transformation units that comprises tuples of graphs to be
processed component-wise, but where the transformations of the components
run in parallel. The product, together with typical operations on products like
embedding and projection, provides a very flexible kind of typing because one
can 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 one
controls the parallel transformations of the components suitably, one can get the
desired interrelations between input and output graphs. We then demonstrate
that the product type is also quite useful if one wants to transform graph
transformation 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 simple
example from the area of graph theory. In the literature one can find many more
applications of graph transformation which underline the usefulness from a
practical point of view. These are, for example, applications from the area of
functional 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 of

graphs. Given a set of graph transformation rules and a set of graphs, one gets
a graph transformation system in its simplest form. Such a system transforms a
start graph by applying its graph transformation rules. The semantics can be
defined as a binary relation on graphs where the first component of every pair
is a start graph G and the second component is a graph derived from G by
applying a sequence of graph transformation rules. In general, the application of
a graph transformation rule to a graph transforms it locally, i.e., it replaces a part
of the graph with another graph part. Often one wishes to start a derivation only
from certain initial graphs, and accepts as results only those derived graphs that
are terminal. Moreover, in some cases the derivation process is regulated in a
certain 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 may
restrict the order in which rules are applied. Altogether the basic elements of a
graph transformation approach are graphs, rules, their application, graph class
expressions, and control conditions.
Graphs
First of all, there is a class of graphs G, that may be directed or undirected, typed
or untyped, labelled or unlabeled, simple or multiple. Examples for graph classes
are labeled directed graphs, hypergraphs, trees, forests, finite automata, Petri
nets, etc. The choice of graphs depends on the kind of applications one has in
mind 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 of
vertices, E is a set of edges, s, t: E → V are two mappings assigning each edge
e ∈ E a source s(e) and a target t(e), and l: E → C is a mapping labeling each
edge in a given label alphabet C. A graph may be represented in a graphical way
with circles as nodes and arrows as edges that connect source and target, with
the 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, we
may draw a flag that is posted on its node with the label inside the box. To cover
unlabeled graphs as a special case, we assume a particular label * that is invisible
in the drawings. This means a graph G is unlabeled if l(e) = * for all e ∈ E. For
instance 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. The
p-edges form a simple path (i.e., a path without cycles) from the begin-flagged
node to the end-flagged node. If one takes the subgraph induced by the edges
of the simple path and the begin- and end-flag and removes all occurrences of
Figure 2.
Figure 3.
the label p, one gets the string graph (i.e., a graph that is a simple path from a
begin-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 in
Figure 3 represents the number four because it has four unlabeled edges between
its begin-flagged and its end-flagged node. Whenever a string graph represents
a 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. Given
some class R of graph transformation rules, each rule r ∈ R defines a binary
relation ⇒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 classes
may 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 shared
by L and R. In a graphical representation of r, L and R are drawn as usual, with
numbers uniquely identifying the nodes in K. Its application means to replace an
occurrence of L with R such that the common part K is kept. In particular, we

will use rules that add or delete flags, label edges, and add or delete a node
together 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 and
edges) in the following way.
1. Find an isomorphic copy of L in G, i.e., a subgraph that coincides with L up
to the naming of nodes and edges.
2. Remove all nodes and edges of this copy except the nodes corresponding
to K, provided that the remainder is a graph (which holds if the removal of
a 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 consisting
of an end-flagged node 1, a node 2 with unlabeled flag, and an unlabeled edge
from node 1 to node 2. The right-hand side consists of the same two nodes where
node 1 has no flag and node 2 has an end-flag. Moreover, there is a p-labeled
edge from node 1 to node 2. The common part of the rule move consists of the
nodes 1 and 2.
The application of move labels an unlabeled edge with p if the edge connects an
end-flagged node and a node with an unlabeled flag, moves the end-flag from
the 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; for
instance, 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 which
certain rules may be applied or to filter out a subclass of all the graphs that can
be derived by a set of rules. Typically, a graph class expression may be some
logic formula describing a graph property like connectivity, or acyclicity, or the
occurrence or absence of certain labels. In this sense, every graph class
expression e specifies a set SEM(e) of graphs in G. For instance, all refers to all
directed, edge-labeled graphs, whereas empty and bool designate a class of
exactly one graph each (the empty graph EMPTY for empty, and the graph
TRUE consisting of one true-flagged node for bool). Moreover, graph specifies
all 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 expression
nat defines all k-string graphs.
Control Conditions
A control condition is an expression that determines, for example, the order in

which rules may be applied. Semantically, it relates start graphs with graphs that
result from an admitted transformation process. In this sense, every control
condition c specifies a binary relation SEM(c) on G. As control condition, we use
in particular the expression true that allows all transformations (i.e., all pairs of
graphs). Moreover, we use regular expressions as control conditions. They
describe in which order and how often the rules and imported units are to be
applied. In particular, the Kleene star states that an arbitrary number of iterations
may be executed. The precise meaning of a regular expression is explained
where 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 class
of graph class expressions, and a class of control conditions, form a graph
transformation approach based on which graph transformation units as a unifying
formalization of graph grammars and graph transformation systems can be
defined. To transform graphs, a unit has local rules, but may also import other
graph transformation units. Therefore, the semantic relation of a unit is given by
the interleaving of rule applications and calls of imported units.
Transformation units were presented in Andries et al. (1999) and Kreowski and
Kuske (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 of
functional 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 that
by its size alone is difficult to manage. Transformation units provide a means to
structure the transformation process. The main structuring principle of transfor-
mation units relies on the import of other transformation units or — on the
semantic level — on binary relations on graphs. The input and the output of a
transformation unit each consists of a class of graphs that is specified by a graph
class expression. The input graphs are called initial graphs and the output graphs
are called terminal graphs. A transformation unit transforms initial graphs to
terminal 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 that
may regulate the graph transformation process.
A graph transformation unit is a system tu = (I, U, R, C, T) where I and T are
graph 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 a
study of cyclic imports see Kreowski, Kuske and Schürr (1997)). Initially, one
builds units of level 0 with empty import. Then units of level 1 are those that
import only units of level 0, and units of level n+1 import only units of level 0 to
level 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 control
condition if it is equal to true.
In the following, we present some examples of transformation units. We start
with very simple specifications of natural numbers and truth values because they
are auxiliary data types to be used later to model the more interesting examples
of simple paths, long simple paths, and Hamiltonian paths.
The first transformation unit nat0 (Figure 6, left side) constructs all string graphs
that represent natural numbers by starting from its initial graph, which represents
0, and transforming the n-string graph into the n+1-string graph by applying the
rule succ.
Figure 6.
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 describes
arbitrary additions to arbitrary n-string graphs by sequentially increasing the
represented numbers by 1.
The third transformation unit nat2 (Figure 7) also transforms string graphs into
string graphs. It has two rules pred and is-zero. The application of the rule pred
to 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 only
to the 0-string graph but does not transform it, which means that this rule can be
used as a test for 0. Moreover, the transformation unit nat2 imports nat1 so that
arbitrary additions can be performed, too. The rules of nat2 and the imported unit
nat1 can be applied in arbitrary order and arbitrarily often. Hence nat2 converts
n-string graphs into m-string graphs for natural numbers m, n. Therefore nat2
can be considered as a data type representing natural numbers with a simple set
of operations.
Figure 7.
nat2
initial: nat
uses: nat1
rules:
end end
pred:
1 1
begin end * begin end
is-zero:
1 1
Figure 8.
bool0
initial:empty
rules:
true
set-true: empty
true
terminal:
The forth transformation unit, bool0 = (empty, ∅, set-true, true, bool), is shown
in Figure 8. It has a single initial graph, the empty graph EMPTY. It does not
import other transformation units and it has one rule set-true which turns EMPTY
to the graph TRUE. The control condition allows all transformations, meaning
that TRUE may be added arbitrarily often to EMPTY. However, the terminal
graph class expression specifies the set consisting of TRUE, which ensures that
the 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 most
simple form. At first sight, this may look a bit strange. But it is quite useful if one
wants to specify predicates on graphs by nondeterministic graph transformation:
If one succeeds to transform an input graph into the graph TRUE, the predicate
holds, otherwise it fails. In other words, if the predicate does not hold for the input
graph, none of its transformations yield TRUE.
The transformation unit simple-path given in Figure 9 constitutes an example of
another kind. As an initial graph, it admits all unlabeled graphs with exactly one
flag on every node. It chooses an arbitrary simple path in an initial graph by
labeling the edges of the path with p and adding a begin-flag and an end-flag to
the beginning and the end of the path, respectively. This is done with the help of
two rules start and move. The rule start turns an unlabeled flag of an arbitrary
node into two flags, respectively labeled with begin and end, and the rule move
is the same as above, i.e., it labels with p an edge from an end-flagged node to
a node with an unlabeled flag, moves the end-flag to the other node, and removes
the unlabeled flag. The control condition is a regular expression which is satisfied
if first the rule start is applied, followed by move applied arbitrarily often. The
terminal graph class expression admits all graphs, which is why it is not explicitly
shown.
Figure 9.
simple-path
initial: graph
rules:
begin end
start:
1 1
end end
p
move:
1 2 1 2
cond:
cond:start ; move
start ; *move
*
Interleaving Semantics of Transformation Units
Transformation units transform initial graphs to terminal graphs by applying

graph transformation rules and imported transformation units so that the control
condition is satisfied. Hence, the semantics of a transformation unit can be
defined as a binary relation between initial and terminal graphs.
For example, the interleaving semantics of the transformation unit simple-path
consists of all pairs (G,G’) such that G is an unlabeled graph with exactly one flag
on every node and G’ is obtained from G by labeling the edges of a simple path
with p, setting a begin-flag at the source of the path and an end-flag at the target of
the path, and removing the flags from the intermediate nodes on the path.
In general, for a transformation unit tu without import, the semantics of tu
consists 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 in
the reflexive and transitive closure of the binary relation obtained from the
union 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 semantics

of tu consists of all pairs (G,G’) of graphs which satisfy the preceding items 1
and 3, and where, in addition to rules, imported transformation units can be
applied in the transformation process of tu, i.e., the second item above is
extended to:
2’. G’ is obtained from G via a sequence of rule applications and applications

of imported units. This means that (G,G’) is in the reflexive and transitive
closure 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 transformation
unit 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-defined

because the union over U is the empty set. If tu is of level n+1, we can inductively
assume that SEM(u) of each imported unit u is already well-defined, so that
SEM(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 an
input-output relation, the natural type declaration of a graph transformation unit
tu = (I, U, R, C, T) is tu: I→T where moreover the initial and terminal graphs are
subtypes of the type of graphs that are transformed by the unit. But in many
applications one would like to have a typing that allows one to consider several
inputs and maybe even several outputs, or at least an output of a type different
from all inputs. For instance, a test whether a given graph has a simple path of
a 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 as
inputs and a truth value as output.
Such an extra flexibility in the typing of graph transformations can be provided
by products of graph transformation units, together with some concepts based on
the products. In more detail, we introduce the following new features:
1. The product of graph transformation units providing tuples of graphs to be
processed and particularly tuples of initial and terminal graphs as well as
tuples of rules and calls of imported units, called action tuples, that can be
executed on graph tuples in parallel.
2. The embedding and projection of a product into resp. onto another product
that allow one to choose some components of a product as inputs or outputs
and to copy some components into others.
3. The semantics of a product of graph transformation units is the product of
the component semantics such that — intuitively seen — all components
run independently from each other. If one wants to impose some iteration
and interrelation between the components, one can use control conditions
for action tuples like for rules and imported units.
The product type generalizes the notion of pair grammars and triple grammars
as introduced by Pratt (1971) and Schürr (1994), respectively.
Product of Graph Transformation Units
Let tu 1, …, tu m for m ≥ 1 be a sequence of graph transformation units with

tu j = (Ij , Uj , Rj , Cj , Tj) for j = 1, ..., m. Then the product:
m
prod = tu1 × … × tum = ∏ tu
i =1
i
transforms m-tuples of graphs (G1, …, Gm) by means of component-wise

transformation.
The global semantic relation of the product is just the product of the semantic
relations of the components, i.e., ((G 1, …, Gm), (H1, …, Hm)) ∈ SEM(prod) if and
only if (G i,Hi) ∈ SEM(tui) for i = 1, ..., m.
But there is also a notion of a single computation step that transforms graph
tuples by applying action tuples. An action tuple (a1, …, am) consists of rules,
imported units and an extra void action, i.e., ai ∈ Ri or ai ∈ Ui or ai = – for i =
1, ..., m. It transforms a graph tuple (G 1, …, Gm) into a graph tuple (G 1’, …, Gm’)
if Gi →ai Gi’ for ai ∈ Ri and (G i,Gi’) ∈ SEM(ai) for ai ∈ Ui and Gi = Gi’ for
ai = – .
In other words, a computation step simultaneously applies rules to some
components and performs calls of import units in other components while the
remaining components of the graph tuple are kept unchanged.
Let a single computation step be denoted by (G 1, …, G m) → (G1’, …, Gm’), and
let →∗ be the reflexive and transitive closure of →. Then one can say that (G1,
…, Gm) →∗ (H1, …, Hm) satisfies the control condition tuple (C1, …, Cm) if
(G i,Hi) ∈ SEM(Ci) for i = 1, …, m. Similarly, (G 1, …, G m) is an initial graph
tuple if Gi ∈ SEM(Ii), and (H1, …, Hm) is a terminal graph tuple if H i ∈

SEM(T i), 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 see
that the global semantics and the step semantics coincide, i.e., SEM(prod) =
STEPSEM(prod).
For example, consider the product simple-path × nat2 of the transformation
units simple-path and nat2. Its semantics consists of all pairs ((G1,G 2), (H1,H2))
where (G 1,G2) is in the semantics of simple-path and (H 1,H2) is in the semantics
of nat2. This product combines two units in a free way like the well-known
Cartesian 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 control
conditions for the computation steps and a boolean value as output. This can be
achieved 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 some
of them are just of an auxiliary nature for intermediate computations or to be used
as outputs, one may choose the input types and embed their product into the
actual product that provides the graph tuples to be transformed. This is possible
whenever the auxiliary components have unique initial graphs and if every
chosen input type is a subtype of the corresponding initial graphs.
Let prod = tu 1 × … × tum be a product of transformation units and let X be a set
of graph class expressions that is associated with the product components by an
injective mapping ass: X→{1,…,m} such that SEM(x) ⊆ SEM(Iass(x)) for all x ∈ X.
Assume, moreover, for all j ∈ {1,…,m}\ ass(X) that either SEM(Ij) = {Gj} for
some graph Gj or SEM(x) ⊆ SEM(Ij) for some chosen x ∈ X, which will be
denoted by copy: x→j. Then we get an embedding of the product of the graphs
in SEM(x) for x ∈ X into the product of initial graphs of the product prod:
m
embed: ∏
x∈X
SEM ( x) → ∏ SEM ( I )
j =1
j
defined by embed((Gx)x∈X) = (G1, …, Gm) with Gi = G x for ass(x) = i and copy:

x → i, and G i ∈ SEM(Ii) = {Gi} otherwise.
This means that each input component is embedded into its corresponding
component of the product of units with respect to ass and into all other
components given by the copy relation. All remaining components of the product
of 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 empty
of the transformation units simple-path, nat2, and bool0, respectively. Every
pair (G1,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., we
get embed((G 1,G2))=(G 1,G 2,EMPTY) for every pair (G1,G2)∈SEM(graph) ×
SEM(nat).
Conversely, if one wants to get rid of some component graphs, the well-known
projection may be employed. The same mechanism can be used to multiply
components, which allows one, in particular, to copy a component graph into
another 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(Tass(y)) for all
y ∈ Y as the semantics of the association ass, i.e.:
SEM(ass) = ∏ SEM (T
y∈Y
ass ( y )
).
The product of terminal graphs of the product prod can be projected to

SEM(ass), i.e.:
m
proj: ∏ SEM (T ) → SEM (ass )
i
i =1
defined by proj(H 1, …, Hm) = (Hass(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 equal
to the terminal graph TRUE of bool0 and every triple (H1, H 2, H3) ∈ SEM(all)
× SEM(all) × SEM(bool) is projected to H 3, i.e., to TRUE.
In general, there are two cases of interest. Firstly, if Y ⊆ {1, …, m} and ass is
the corresponding inclusion, then proj is the ordinary projection of a product to
some 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 the
multiplication of the i-th component.
Embedding and projection may be used to realize transformations on graphs with
type declarations of the form trans: in 1 × … × in k → out 1 × … × outl where the
in i and the outj are graph class expressions. The intention is that trans relates
the product of inputs SEM(in 1) × … × SEM(in k) with the product of outputs
SEM(out1) × … × SEM(outl). This is obtained by using a product prod of graph
transformation units tu1,…,tu k+l such that SEM(ini) ⊆ SEM(Ii) for i = 1,…,k and
SEM(Tj) ⊆ SEM(outj) 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(Ij) = {Gj} for some
graph G j. The last l inclusions allow one to project the terminal graph tuples of
prod onto outputs. Therefore, the semantic relation of trans has the proper
form, but the output tuples are totally independent of the input tuples due to the
product semantics. To overcome this problem, we generalize the notion of
control conditions in such a way that it applies not only to the control of rule
applications 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 by
intersecting the interleaving semantics with the semantic relation given by the
control condition. This is easily generalized to action tuples if one replaces the
interleaving 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 can
refer to rules and imported units. To make this more convenient, action tuples
may get identifiers.
As an example how the features based on the product may be used, we specify
the test long-simple-path that transforms graphs and non-negative integers as
inputs 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: a 0 ; a1* ; a2
It is modeled on top of the product of the units simple-path, nat2 and bool0. The
typing is appropriate as graph and nat specify the initial graphs of simple-path
and nat2 respectively, and bool refers to the terminal graph of bool0.
Hence, a computation in long-simple-path starts with an unlabeled graph and

a non-negative integer completed to a triple by the initial graph of bool0. Then
the control condition requires to perform a0 that chooses a start node in the graph
without changing the other two components. This is followed by the iteration of
a1 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 we
get a graph with a path of the input length if the second component becomes zero.
This is tested by the second component of a2. In the positive case, a2 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 input
length n.
Transformation of Graph Transformations

Two graph transformations may be related with each other in various significant
ways:
1. They may be semantically equivalent, meaning that their semantic relations
coincide or, seen from another perspective, that a semantic relation is
modeled in two different ways.
2. One graph transformation may be the refinement of the other one, meaning
that each computational step of the one can be accomplished by an
interleaving sequence of the other.
3. One graph transformation may be reduced to the other, meaning that the
semantic relation of the one can be translated into the semantic relation of
the other.
Such situations are nicely modeled by transformations of graph transformations.

In the case of two graph transformation units tu i = (Ii, U i, Ri, Ci, Ti) with SEM(tui)
⊆ SEM(Ii) × SEM(Ti) 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) = (I1, UI, RI, C I, I2) and tu 1-2-tu2(T) = (T1, U T, RT, C T, T2) where
the former transforms initial graphs of tu 1 into initial graphs of tu2 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, which
is covered by the notion of correctness. A translation of tu1 into tu2 is correct
if the diagram in Figure 10 commutes, i.e., if the sequential compositions of the
Figure 10. Translation of graph transformation units
semantic relations of SEM(tu1) with SEM(tu1-2-tu 2(T)) on one hand and of

SEM(tu1-2-tu2(I)) with SEM(tu2) on the other hand coincide.
Correct translations can be very helpful because they carry over certain
properties from the source unit to the target unit and the other way round. For
example, if some question is undecidable for the source unit, the corresponding
question must be undecidable for the target unit, provided that the translating
units have computable semantic relations (which holds in all reasonable cases).
To demonstrate the usefulness of translations more explicitly, we restrict the
notion of translations to the notion of reductions as used in the study of the
complexity class NP of all decision problems that can be computed non-
deterministically in polynomial time. A reduction of tu1 to tu2 is a correct
translation of tu1 into tu2 subject to the following further conditions:
1. tu1 and tu2 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 tu 2.
If tu 2 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, then
the composition of the reduction and the semantic relation of tu2 is in NP, too.
While the reduction yields an output for every input in a polynomial number of
steps, the following computation in tu2 runs also in polynomial time, but it is
nondeterministic because it may compute TRUE for some of its inputs while
other computations for the same input end in deadlocks. Hence, the sequential
composition, which is the semantic relation of tu 1 due to the correctness of the
translation, is nondeterministic, too, with polynomial runtime. By a similar
reasoning, it turns out that tu 2 models an NP-complete problem if tu1 does, i.e.,
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 NP
in the same way as ordinary reductions are useful. But, as many interesting
problems in NP are graph problems, graph-transformational reductions may be
quite suitable.
As an illustrating example, we specify a reduction from the Hamiltonian-path
problem HP into the unit long-simple-path. We assume that HP is a predicate
with the typing HP: graph → bool that yields TRUE for an input graph G if and
only if G has a simple path that visits all nodes. An explicit specification by graph
transformation is not needed, but it would look similar to simple-path, only
making sure that all nodes are involved. Due to the typing, the reduction must
consist of a graph transformation unit of the type HP-2-lsp: graph → graph × nat
that copies the input graph as output graph and computes the number of nodes
minus one of the input graph as second output. For this purpose, the product of
units mark-all-nodes, graph and nat0 will be used. The unit graph = (graph,
∅, ∅, true, graph) takes unlabeled graphs as initial and terminal graphs and is
without import and rules such that its semantics is the identity relation on
SEM(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 that
replaces the unlabeled flag by another flag (ok-labeled for example), and of
graphs without unlabeled flags as terminal graphs. This is an auxiliary unit the
meaning of which is that each derivation from an initial to a terminal graph has
the number of nodes as length. Hence, an action tuple that applies the rule mark
in 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: b 0 = (mark, –, –)
b1 = (mark ,–, succ)
cond: b 0 ; b1*
Note that the length of all computations is bounded by the number of nodes of the
input graph and that each computation can be prolonged until all nodes are
marked. As one always marks the first node without increasing the initial
integer 0 and as all other nodes are marked while the integer is increased by one
in 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 the

original input graph has a simple path of a length that is the number of nodes minus
one such that it visits all nodes. In other words, the translation is correct. As the
Hamilton-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 transformation
with 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 approaches
one encounters in the literature (see, e.g., Rozenberg, 1997, for an overview).
Readers who are interested in seeing the full spectrum of applications of graph
transformation and its relation to the theory of concurrency are referred to the
Handbook 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 one
to transform a tuple of graphs by the synchronous transformation of the
components. This is quite helpful to specify transformations with a flexible
typing, i.e., with an arbitrary sequence of input graphs and an arbitrary sequence
of output graphs. Moreover, the types of the input and output graphs need not be
subtypes of the same type of graphs anymore. As a consequence, the product
type is particularly useful if one wants to transform graph transformations into
each other. Further investigation of the product type may concern the following
aspects:
As we used graph-transformational versions of the truth values and the natural
numbers in our illustrating examples, one may like to combine graph types with
arbitrary abstract data types.
In the presented definition, we consider the product of graph transformation
units. But one may like to import products in units and to use components that are
again products. Whether such a composite use of products works must be
investigated.
The transformation of graph transformation units is only tentatively sketched. It
must be worked out how it helps to study refinement and semantic equivalence
and other interesting relationships between graph transformation systems.
Acknowledgments
The research presented here was partially supported by the EC Research
Training Network SegraVis (Syntactic and Semantic Integration of Visual
Modelling 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 Graph
Transformation to Visual Languages. In H. Ehrig, G. Engels, H.-J. Kreowski
& G. Rozenberg (Eds.), Handbook of Graph Grammars and Computing
by Graph Transformation, Vol. 2: Applications, Languages and Tools
(pp. 105-180). Singapore: World Scientific.
Bottoni, P., Koch, M., Parisi-Presicce, F., & Taentzer, G. (2000). Consistency
Checking and Visualization of OCL Constraints. In A. Evans, S. Kent & B.
Selic (Eds.), Proceedings of UML 2000 – The Unified Modeling
Language. 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 Concepts
and Double Pushout Approach. In G. Rozenberg (Ed.), Handbook of
Graph Grammars and Computing by Graph Transformation, Vol. 1:
Foundations (pp. 163-245). Singapore: World Scientific.
Drewes, F., Kreowski, H.-J. & Habel, A. (1997). Hyperedge Replacement
Graph 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 Computing
by 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. In
G. Rozenberg (Ed.), Handbook of Graph Grammars and Computing by
Graph Transformation, Vol. 1: Foundations (pp. 1-94). Singapore:
World Scientific.
Engels, G., Hausmann, J.H., Heckel, R. & Sauer, S. (2000). Dynamic Meta
Modeling: 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. Advancing
the Standard, Lecture Notes in Computer Science (Vol. 1939, pp. 323-
337). Springer.
Engels, G., Heckel, R. & Küster, J.M. (2001). Rule-Based Specification of
Behavioral Consistency Based on the UML Meta-model. 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. 272-286). Springer.
Fischer, T., Niere, J., Torunski, L. & Zündorf, A. (2000). Story Diagrams: A new
Graph Transformation Language based on UML and Java. In H. Ehrig, G.
Engels, H.-J. Kreowski & G. Rozenberg (Eds.), Proc. Theory and
Application of Graph Transformations, Lecture Notes in Computer
Science, Vol. 1764 (pp. 296-309). Springer.
Heckel, R., Engels, G., Ehrig, H. & Taentzer, G. (1999). Classification and
Comparison of Module Concepts for Graph Transformation Systems. In H.
Ehrig, G. Engels, H.-J. Kreowski & G. Rozenberg (Eds.), Handbook of
Graph Grammars and Computing by Graph Transformation, Vol. 2:
Applications, Languages and Tools (pp. 669-689). Singapore: World
Scientific.
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 Applied
Graph 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 transformation

units. International Journal on Software Engineering and Knowledge
Engineering, 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. Theory
and Application of Graph Transformations, Lecture Notes in Computer
Kuske, S. (2001). A Formal Semantics of UML State Machines Based on
Structured 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 Integrated
Semantics for UML Class, Object, and State Diagrams based on Graph
Transformation. In M. Butler & K. Sere (Eds.), Third Int. Conference
Integrated Formal Methods (IFM’02), Lecture Notes in Computer
Nagl, M. (Ed.) (1996). Building Tightly Integrated Software
Development Environments: The IPSEN Approach. Lecture Notes in
Computer Science, Vol. 1170. Springer.
Petriu, D.C. & Sun, Y. (2000). Consistent Behaviour Representation in Activity
and 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-graph
translations. Journal of Computer and System Sciences, 5(6), 560-595.
Rozenberg, G. (ed.) (1997). Handbook of Graph Grammars and Computing by
Graph Transformation, Vol. 1: Foundations. Singapore: World Scientific.
Schürr, A. (1994). Specification of Graph Translators with Triple Graph
Grammars. 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 Graph
Transformation, Vol. 1: Foundations (pp. 479-546). Singapore: World
Scientific.
Sleep, R., Plasmeijer R. & van Eekelen, M. (eds.) (1993). Term Graph
Rewriting: Theory and Practice. New York: John Wiley.
52 Petit and Hacid
Chapter III
From Conceptual
Database Schemas to
Logical Database
Tuning
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 differences
between constructor-oriented models (like extended Entity-Relationship
models) and attribute-oriented models (like the relational model). Then, we
introduce an integrated algorithm for translating ER-like conceptual
database schemas to relational database schemas. To consider the tuning
of such logical databases, we highlight two extreme cases: null-free
databases and efficient — though non redundant — databases. Finally, we
point out how SQL workloads could be used a posteriori as a help for the
designers 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 been
devoted for many years to database design, we hope that this chapter will
clarify the understanding of database designers when implementing their
databases and database administrators when maintaining their databases.
Introduction
Semantic data modeling is the activity of specifying the structure and the
semantics 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 several
areas, including databases, information systems, software engineering and
knowledge representation. For database design, approaches to data modeling
advocate the use of abstract formalisms, such as the popular Entity Relationship
model (Chen, 1976), for describing data, mostly based on the notion of class or
entities.
Two main families of semantic data models are addressed in the literature:
• Attribute-oriented models: Data structure is captured through the notion
of attributes, i.e., objects and relationships between objects are modeled
thanks to attributes. Most of data semantics is expressed by means of
additional constraints. The relational data model or object-oriented data
models fall into this family.
• Constructor-oriented models: Data semantics is captured through vari-
ous constructors, including attributes but also a constructor for objects and
another one for relationships between objects. A key feature of such
models is that most of data semantics is already expressed by the
constructors. Entity-Relationship models (Chen, 1976) fall into this family.
Conceptual data models like ER models provide a high-level abstraction for

information concerning an application domain. To do so, they rely on many
constructors, such as relationship-type which is very powerful to capture data
semantics at a high level abstraction. Moreover, such models are widely used in
practice, as advocated by methods of information systems design like MERISE
(Moulin, 1976; Tardieu, 1979) or R.U.P. (Rational Unified Process) based on
UML (Jacobson, 1999). Most of them have conceptual data models derived
from ER models except that the interpretation of relationship cardinalities
substantially differs. As an example, a database schema created with one
interpretation of relationship cardinalities is quite different from the same
database 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 database

design in particular. However, these differences are often misunderstood by
database designers and may lead to practical errors at the implementation stage.
Their use requires a thorough knowledge of the theory behind them, though such
knowledge is not required of the average designer.
For tasks like database design, some mappings are necessary to translate
conceptual 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 logical
data 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 a
common weakness, for example the lack of an integrated algorithm to perform
the translation process whatever the convention used to represent the conceptual
data model, mainly around the interpretation of cardinality constraints on
relationship-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 the
designer 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 the
practitioners (Rosenthal, 1994; Fahrner, 1995).
In this chapter, we try to fill in the gap between these two approaches. We make
a step toward a unified approach of translating conceptual data schemas to
relational logical data schemas in which different kinds of interpretations can be
dealt with without any overhead. Our work complements those done by
Markowitz (1992) and Mannila (1994). Due to space limitation, we do not
attempt 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 clear
understanding of the issues of such a mapping, e.g., through a running example.
We also study some classical choices database designers are faced with when
they want to implement their databases from a logical database schema. This
stage is a matter of compromises to be reached between getting a null-free
database and getting an efficient database. To end up, we argue that logical
database tuning could also be defined a posteriori with respect to SQL
workloads representative of the database activity during some period of time. It
can be thought of as a help to guide the designer when implementing (if she/he
can predict some SQL workloads) or maintaining her/his database.
The chapter is organized as follows: Notations and background materials are
given first. Then the chapter gives a mapping from conceptual data models to
logical data models. Next, the chapter discusses strategies for logical database
tuning. 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 done
previously by others (e.g., Hull, 1987; Navathe, 1992).
Numerous investigations have been conducted in the data modeling area in order
to seek more appropriate formalisms for accurately representing real-world
applications. These investigations have resulted in a class of data models called
semantic data models (Peckham, 1988).
Semantic data models provide constructors for explicitly representing the
semantics of the application. The constructs implement information modeling
tools called data abstractions. These abstractions enable a complex world to be
examined in terms of a simplified world that incorporates the most significant
points. Most importantly, data abstractions provide the basis for a step-wise
design methodology for databases.
Each data model has its own structuring mechanism from which to build
application schemas. In semantic data models this mechanism is in terms of
semantic structures expressed in some textual language or in graph-theoretic
terms.
In such data models, most of the data semantics has to be captured by so-called
constructors, which are high-level abstraction mechanisms. Two main families
of semantic data models were addressed:
• With attribute-oriented data models, the main constructor is related to the
notion of attributes. Basically, an attribute associates a meaningful name
in the application context with a type, the permitted values. They are used
to 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 available
to produce a conceptual schema. Among the main constructors, we find
again the notion of attributes, but also an explicit constructor intended to
capture the relationships between objects.
The analysis of the above cited models makes it clear that, although they address
the same issues, attribute-oriented models seem to be less expressive, or at least
less simple, than the constructor-oriented models.
56 Petit and Hacid
Therefore, when schemas based on constructor-oriented models have to be

translated into schemas based on attribute-oriented models, these later rely on
explicit constraints to accurately capture data semantics conveyed by the
former. For instance, the relational model requires constraints like functional
dependencies 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 of
attribute-oriented models.
Now, we introduce an instance of attribute-oriented models (namely the
relational model) and an instance of constructor-oriented models based on an
extension of the Entity-Relationship model (Chen, 1976).
Relational Data Model
Simplified notations of relational databases used in this chapter are given in this
section (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. A
relation schema R is associated with a set of attributes, noted schema(R). A
relation 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 database
schema R is a set of relation schemas. A relational database d (or database) over
a database schema R corresponds to a set of relations, a relation of d being in
one-to-one correspondence with a relation schema of R.
In this chapter, we are interested in two main types of constraints of the relational
model: functional dependencies and inclusion dependencies. The former
allows us to specify constraints within a relation schema and the latter allows us
to specify constraints between two relation schemas (though possible within one
relation schema). The set of functional dependencies associated with a database
schema is denoted by F, and the set of inclusion dependencies associated with
a database schema is denoted by I. In the sequel, a relational database schema
will 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 respect
to F if (1) F logically implies Xàschema(R) and (2) no subset of X satisfies this
property.
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 more

details, see e.g., Chen (1976) and Ramakrishnan (2003). Recall that our
objective is to be able to deal with different interpretations of relationship
cardinalities. However, in order to be able to run an example throughout the
chapter, we have to select an interpretation. For that, we have chosen UML-like
interpretation since it seems to be widely accepted at present as a standard. The
model used in this chapter has the following basic and extended modeling
constructs1:
• 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 common
properties, 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. We
also allow relationship-types to participate in other relationship-types,
sometimes called generalized aggregation. In that case, an arrow is set
to know “who associates who”. In the sequel, an object-type will denote
either an entity-type or a relationship-type. Restrictions may be set to
specify the number of relationships that an object (or a group of objects) can
participate in. Those restrictions are known as cardinality constraints.
• Generalization/specialization relationships: They define inheritance
hierarchy (or is-a-hierarchy) over entity-types. We will say that A is-a
B, A being an inherited entity-type. Note that these relationships are a
special kind of binary relationship-types with a one-to-one constraint.
• We also allow is-a-hierarchy for relationship-types, which does not share
any element with is-a-hierarchy of entity-types. In the sequel, we shall use
inherited object-types to denote either inherited entity-types or inherited
relationship-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 inherited
from 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 just

an 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) key
for each strong entity-type (It should be noted that we use this requirement here
to simplify the rest of this chapter. In practice, if such a key does not exist, a
surrogate key can be defined at the logical level.)
Different Interpretations of Cardinalities
The difference between UML- and Merise-like relationships can be explained

as follows: Let A be a relationship-type defined on E1, …, En and let us consider
that the domain of each Ei is a set of objects. Thus, A ⊆ E 1 x … x E n. Let mi be
the cardinality of the role between A and E i . Let us consider two main cases:
m i =1 and m i = N.
• mi = 1
• UML-like cardinality: It means that the functional dependency
E1…Ei-1 Ei+1 … En à Ei must hold in every instance of A.
• Merise-like cardinality: It means that Ei à E1 … Ei-1 Ei+1…En 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 En.
Graphical notations used to express a schema are not detailed here — they are
just given in our running example.
Example: For the sake of comparison, we borrow our running example from a
widely disseminated textbook with only minor changes (Ramakrishnan, 2003).
The application deals with the management of projects by employees in a
company organized in several departments. Figure 1 shows the diagram for the
application 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 are
underlined in the diagram. The one-to-many relationship-type sponsors between
Projects and Departments has to be read as follows: A department sponsors
one 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: its
identification 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.
Figure 1. A conceptual schema expressed with our extended ER model
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 is

both a strength and a weakness of such a kind of modeling. Indeed, it should not
hide the underlying semantics of each constructor, the risk being to produce
schemas 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 is
acyclic. This condition requires that each hierarchy (is-a-hierarchy on
entity-types, is-a-hierarchy on relationship-types and id-hierarchy) has to
be 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 derived
by at least two different paths with two different keys.
Note that our conditions differ from those given in Mannila (1994), where for
example a weak entity-type may be involved in different paths in the id-
60 Petit and Hacid
hierarchy. Some contributions (e.g., Mannila, 1994; Levene, 1999) consider also
inherited entity-types as weak entity-types.
From Conceptual Data Schemas to

Logical Data Schemas
We rigorously define a mapping which produces highly normalized schemas
(stronger than the Boyce-Codd normal form (BCNF)), without null values but
maximizing the length of join paths. Normal forms have been defined to capture
such kind of database schemas, such as entity-relationship normal form (ERNF)
or inclusion dependency normal form (IDNF). Due to space limitation, we will
not develop such issues and we refer to Markowitz (1992), Mannila (1994) and
Levene (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, some
classical misconceptions can be rectified and thus a formal treatment can
be carried out.
3. Dealing with attribute naming problems: indeed, assigning names to the
attributes in a relational database schema turns out to be a challenging task.
4. Translating the conceptual schema to a logical database schema: often, the
whole 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 tools
supporting both syntactic and semantic checking of a given conceptual schema
exist (e.g., Franconi, 2000). The second step is described in the next section and
could be coupled with the first step: if the graph is acyclic, then the first condition
of a well-formed conceptual schema is reached.
The third step is trickier to achieve. In fact, the intuition is that at the conceptual
level, attribute names are local, i.e., their scope is delimited by the entity or the
relationship-type in which they are defined. This is not true anymore with the
relational model at least from a theoretical point of view: an attribute name has
a 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 apparently
simple problem turns out to be technically difficult. In this chapter, we avoid such
problems by considering that the scope of an attribute is local, i.e., valid only
within 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 they
are 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 be
defined between two nodes. Nevertheless, we do not take advantage of the
multi-graph structure. Therefore, we will speak about graph in the sequel.
Example: From our previous example, we derive the oriented graph depicted in
Figure 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 of
successor of a node x in V, denoted by successor(x), and defined as follows:
successor(x) = {y∈V∃x1, ..., x n with x1 = x, xn = y and (x i -> xi+1)∈E, ∀ i ∈ {1,

n-1}}
Integrated Algorithm
The main algorithm takes advantage of the underlying existing pre-order

between object-types of the conceptual schema. We can therefore define a
priority for performing the mapping: we first consider the elements of G without
62 Petit and Hacid
Figure 2. Directed graph of the conceptual schema of Figure 1
successor (except themselves) — they can be processed alone — then we

remove those nodes and update the graph accordingly, until no more nodes
remain in G. This is the main loop of the Algorithm 1 (line 3).
Algorithm 1. Main algorithm
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
The complexity of this algorithm is clearly polynomial in the size of the input. The
terminating condition is ensured whenever the graph G is acyclic, a condition
which is met if the conceptual schema S is well-formed.
Example: Continuing our example, three iterations are necessary: The first
iteration gives three candidates {People, Projects, Departments}. Then,
these nodes are removed and we get {Employees, sponsors} during the
second iteration. Finally, it retains only one node {Dependents, monitors}.
At a given iteration, there is no particular order to be taken into account to
consider elements. For instance, the three elements of the first iteration can be
treated in any order. Then the Algorithm 1 calls three main procedures, one for
each 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 details

of attribute names assignment. It is worth noting that Map_Entity is the unique
procedure which does not add any new attribute during the translation.
Example: Consider the strong entity-type People. A new relation schema

People is added to R with schema(People)={ssn,name,tel} and one
functional dependency People: ssn → name,tel is added to F, since only
one 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
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
Algorithm 3. Mapping a relationship-type to a relation schema
Algorithm Map_Relationship
Input: A, a relationship type between O1, …, On
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
Mapping Relationship Types with Map_Relationship
The procedure Map_Relationship deals with relationship-types and handles

both kind of cardinalities interpretation, referred to as, “US notation” and “EU
notation” in the sequel. To our knowledge, this is the first contribution dealing
with both kinds of constraints in a unified manner. We have seen that attribute-
oriented models need additional attributes and constraints to overcome their
intrinsic limitations with respect to constructor oriented-models: this procedure
implements such a kind of mapping, i.e., new attributes and new constraints must
be added to get a semantically equivalent database schema.
New attributes which are necessary to encode the relationship-type are exactly
those 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 smallest
one in the number of attributes. The new attributes and descriptive attributes of
the 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): A
functional dependency linking new attributes with descriptive attributes of the
relationship-type is added (line 6). Then, each participating object-type leads to
the creation of an inclusion dependency (line 8). If the cardinality constraint is
equal to 1 (line 9) for this participating object-type, let say the ith component of
the 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
determine the ith component (line 11). Otherwise, the ith component determines
all other components (line 13).
Note that in case of a reflexive relationship-type, there exists O i and O j referring
to the same entity-type (line 1). In that case, attribute(s) of one of the
corresponding key (Ki or Kj) must be renamed (line 2).
Example: First recall that the conceptual model used in this chapter complies
with U.S. notation. Now, consider the relationship-type sponsors: A new
relation 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) and
two leaving inclusion dependencies are created from sponsors: one to
Departements (sponsors[did] ⊆ Departments[did]) and the other
one to Projects (sponsors[pid] ⊆ Projects[pid]) (line 8). The
cardinality constraint equals to 1 between Projects and sponsors yields to the
creation of a functional dependency sponsors: did→pid (line 11). From the
two functional dependencies defined over sponsors, did turns out to be a key
and sponsors is trivially in BCNF.
Mapping Inherited Object-Types with Map_Inherited
The procedure Map_Inherited deals with inherited object-types. Since multiple

inheritance is allowed, we may have several generalizations for a given inherited
object-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
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 E
has two different keys, derived from D and from C.
Example: Consider the inherited entity-type Employees. A new relation

schema Employees is added to R with schema(Employees)={ssn,sal,lot}.
Only one is-a relationship follows from Employees, so only one inclusion
dependency Employees[ssn] ⊆ People[ssn]is created in I. No keys are
defined over Employees and only one key is available from People, so we get
one 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, weak

entity-types are a special case of relationship-types and due to restrictions
imposed by well-formed conceptual schemas, a weak entity-type may be derived
from only one object-type, which can be an entity-type or a relationship-type.
Example: Consider the weak entity-type Dependents. A new relation schema

D e p e n d e n t s is added to R with sc h e m a ( D e p e n d e n t s ) =
{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
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
Table 1. Relational database schema (logical schema)
Relation Attributes FD specified within the Leaving IND

schema (schema of) relation schema
People ssn, name, tel ssn → name, tel /
key of Employees: ssn
Departments did, dname, did → dname, budget; /
budget key of Departments: did
Projects pid, started, pid → started, pbudget /
pbudget key of Projects: pid
Employees ssn, sal, lot ssn → sal, lot Employees[ssn] ⊆
key of Employees: ssn People[ssn]
Sponsors did, pid, since did, pid → since sponsors[did] ⊆
did → pid Departments[did],
key of sponsors : did sponsors[pid] ⊆
Projects[pid]
Dependents pname, ssn, ssn, pname → age, cost Dependents[ssn] ⊆
age, cost key of Dependents: Employees[ssn]
{ssn,pname}
Monitors did, ssn, until did, ssn → until monitors[did] ⊆
did → ssn; sponsors[did]
monitors[ssn] ⊆
key of monitors: did Employees[ssn]
attributes induced by the transformation of a constructor-oriented model to an

attribute-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, the
database schema obtained after applying the algorithm MapERtoR has the
following properties:
• Each relation schema is in BCNF.
• I is made up of key-based inclusion dependencies (their right-hand sides
are keys) and the oriented graph of I (a node corresponds to a relation
schema and an edge between R and S corresponds to an element
R[X] ⊆ S[Y] of I) is acyclic.
68 Petit and Hacid
• F and I do not interact, i.e., logical implication with F and I can be

restricted to logical implication with F or with I.
Other properties can be given on such a mapping such as those related to

information capacity (e.g., Miller, 1994; Hacid, 2001).
Logical Database Tuning

Once a logical database schema has been generated, a physical database
schema has to be derived using some DBMS-dependent language. The imple-
mentation of a physical database schema by itself is rather straightforward from
a logical database schema. Physical database tuning such as definition of block
size, indexes or clusters is out of the scope of this chapter. Therefore, we focus
on de-normalization techniques usually performed at the logical level with
respect 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 of
database schemas with respect to SQL accesses performed over the database
during some periods of time.
Getting a Null Free Database
Occurrence of null values is quite common in real life databases and is known
to be one of the major difficulties for database programmers when they have to
write SQL queries. In fact, problems raised by null values depend on which kind
of attributes they occur:
• On duplicated attributes, i.e., attributes which enable attribute-oriented
models to simulate constructor-oriented models: null values can be a
nightmare to compose queries involving joins, specific RDBMS functions,
etc.
• On non-duplicated attributes: null values are not very challenging for
designing SQL queries. Most of the time, null values were missing at the
insertion time of a tuple, but such values are not used anymore to navigate
through the database schema. These attributes are descriptive only: they
are defined within a relation schema and convey part of the information or
semantics of this relation schema.
To get a “null free” database on a duplicate attribute, the logical database schema
obtained from the conceptual schema with the MapERtoR algorithm has to be
implemented 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 each
inclusion dependency turns out to be a foreign key, both of them being enforced
to 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 based
on 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 be
done: 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) that
participates with the cardinality constraint equals to one.
Example: From our example, if we follow the previous transformation, we get

the logical database design given in Table 2. Note that the number of relation
schemas and inclusion dependencies decreases at the price of null values on the
three duplicate attributes: pid and ssn into Departments and ssn into
Dependents.
Consider the one-to-many relationship-type sponsors. It has been merged into
the relation schema Departments, its own attributes being now part of the
schema of Departments. To show an example (not very realistic here) of the
impact of such a denormalization on the number of null values, let’s assume we
have 10,000 departments of which only 100 participate in the relationship-type
70 Petit and Hacid
Table 2. Another relational database schema (logical schema)
Relation Attributes Keys Leaving IND

schema (schema of)
Employees ssn, name, /
lot, tel, sal ssn
Projects pid, started, /
pbudget pid
Departments did, dname, Departments[pid] ⊆ Projects[pid]
budget, pid, did
Departments[ssn] ⊆ Employees[ssn]
since, ssn,
until
Dependents pname, ssn, Dependents[ssn] ⊆ Employees[ssn]
age, cost {ssn,pname}
sponsors. In that case, 99% of tuples of Departements get null values on the
duplicated attribute pid, and less importantly, on attribute since. Such kind of
problems never append with database schema produced by the algorithm
MapERtoR.
To sum up, such kind of logical database schema is often chosen to produce
physical database schemas, its main advantage being to minimize the length of
join paths, and thus to be rather efficient. The often misunderstood problem of
such schemas concerns the number of null values which can be generated once
the database is operational. For database designers, it might not be an important
issue at database design time, but that could become a nightmare for database
programmers who have to devise SQL queries in presence of null values on
duplicated attributes.
Denormalisation with Data Integrity Problems
From Table 2, we may be tempted to go a step beyond in order to avoid costly

joins. In that case, data integrity problems will inevitably occur.
Example: Consider the merging of Dependents and Employees into

Employees. In that case, we have schema(Employees)={ssn, name,
lot, tel, sal, pname, age, cost}, the inclusion dependency
Dependents[ssn] ⊆ Employees[ssn] being removed. Two functional
dependencies need to be defined over Employees, namely ssn,pname →
age,cost and ssn → name,lot,tel,sal.
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 second
functional 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 the
spirit of (Ramakrishnan, 2003), we argue that a good design cannot be obtained
at database design time: too many parameters have to be taken into account at
an early stage of the design, specifically those related to application programs
accessing the database.
Nevertheless, an optimal design could be defined and obtained with respect to
the database accesses as given by SQL workloads. We argue that SQL
workloads could be used to tune the database design of operational databases
since they offer a nice setting in which logical database tuning can be treated
objectively — with respect to SQL workloads — instead of subjectively — with
respect to the database designer expertise.
Gathering SQL Workloads
SQL workloads represent a set of SQL accesses performed over the database
during some periods of time. They should be representative of the database
activity, 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 major
RDBMS products: a representative workload can be generated by logging
activity on the server and filtering the events we want to monitor (Agrawal,
2001).
Using SQL Statements to Tune the Logical Database

Design
The key idea is to tune the design with respect to three main goals: minimizing
the occurrence of null values, maximizing both the efficiency of cost-sensitive
SQL queries performed against the database and data integrity of the database.
Example: Assume that SQL workloads reveal that cost-sensitive SQL queries
occur 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 (or
denormalized) only with respect to the length of join paths implied by SQL
workloads, i.e., the relation schema sponsors could be merged into Depart-
ments, the rest of the logical schema remaining unchanged, up to some
transformations 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 as
physical database tuning, e.g., automatic index definition (Agrawal, 2001),
logical database tuning (Lopes, 2002) or materialized view selections in a data
warehouse (Agrawal, 2001).
Conclusions
Relational database technology and semantic data modeling have been two major
areas of database research in recent decades. Relational database technology
is based on solid theoretical foundations, and it is understood what constitutes a
well-designed relational database schema. Semantic modeling, on the other
hand, provides a rich set of data abstraction primitives which can capture
additional semantics of the application in the database schema. Until recently,
relational database technology and semantic modeling have evolved almost
separately. There is a need for establishing and understanding connections
between semantic models and the relational model. This chapter is an attempt to
investigate this connection. We tackled this problem by restricting the class of
data dependencies to functional dependencies and inclusion dependencies. The
results of our work are directed toward the understanding of the properties of
relational translations of (extended) ER schemas.
We clarified two main steps in such a translation: (1) the order of the translation
of entity and relationship-types and (2) the translation of cardinalities for
relationship-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 the
desire to get efficient databases for end-users and the desire to get null-free
databases on duplicated attributes for database programmers, we have pointed
out 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 and
Index Selection Tool for Microsoft SQL Server 2000, ACM SIGMOD
2001, California, May 21-24.
Chen, P. (1976). The Entity-Relationship Model - Toward a Unified View of
Data. 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 Conceptual
Modeling. Proceedings of the Seventh International Workshop on
Knowledge Representation Meets Databases (KRDB 2000), Berlin,
Germany, 2000 (pp. 45-53).
Hacid, M.S., Petit, J.M. & Toumani, F. (2001). Representing and reasoning on
database 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 Unified
Software Development Process”: The Unified Process. IEEE Software,
16(3), 82-90.
Levene, M. & Loizou, G. (1999). A Guided Tour of Relational Databases and
Beyond. Springer.
Lopes, S., Petit, J.M. & Toumani, F. (2002). Discovering interesting inclusion
dependencies: Application to logical database tuning. Information Sys-
tems, 27(1), 1-19.
Mannila, H. & Räihä, K.J. (1994). The Design of Relational Databases (2nd
ed.). Addison-Wesley.
Markowitz, V. & Shoshani, A. (1992). Representing Extended Entity-Relation-
ship Structures in Relational Databases: A Modular Approach. ACM
TODS, 17(3), 423-464.
Miller, R.J., Ioannidis, Y.E. & Ramakrishnan, R. (1994). Schema equivalence
in heterogeneous systems: Bridging theory and practice. Information
Systems, 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 the
IFIP 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. Communications
of the ACM, 35(9), 112-123.
Peckham, J. & Maryanski, F. (1988). Semantic data models. ACM Computing
Surveys, 20(3), 153-189.
Ramakrishnan, R. & Gehrke, J. (2003). Database Management Systems (3rd
ed.). McGraw-Hill.
Rosenthal, A. & Reiner, D.S. (1994). Tools and Transformations - Rigorous and
Otherwise - for Practical Database Design. ACM TODS, 19(2), 167-211.
Tardieu, H., Pascot, D., Nanci, D. & Heckroth, H. (1979). A Method, a
Formalism 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 for
Relational Databases Using the Extended Entity-Relationship Model. ACM
Computing Surveys, 18(2), 197-222.
Endnote
1
Other extensions could have been integrated into our ER model such as
multi-valued attributes or composite attributes. In order to ease the
presentation of the mapping, they are not taken into account in this chapter
but could be integrated into our framework without any major difficulty.
Transformation Based XML Query Optimization 75
Chapter IV
Transformation Based
XML Query
Optimization
Dunren Che, Southern Illinois University, USA
Abstract
This chapter addresses the fundamental issues of XML query optimization

– equivalences and transformation rules. Equivalences are typically used
as the basis to pursue transformation-based query optimization in traditional
database systems. In this chapter, we develop the conception of equivalences
in the context of XML database and XML query optimization. We then
propose to derive deterministic transformation rules by incorporating
general and XML-specific optimization heuristics to achieve high
optimization efficiency for XML queries. We hope the work presented in this
chapter will set a preliminary foundation or framework for further in-depth
investigation for transformation-based XML query optimization.
76 Che
Introduction
With the advent of the Internet and World Wide Web (WWW), the repositories
of SGML (Standard Generalized Markup Language) compliant structured
documents have been fast mounting up. XML (Extensible Markup Language),
as the new proposal of W3C (World Wide Web Consortium) for standard, is
hurriedly getting the dominance of representing data in the Web and elsewhere.
Therefore, commensurate management technology, including efficient query
processing and optimization for XML data is specially needed. It has been
commonly recognized that structured documents in general and SGML/XML
documents in particular should benefit from the same type of database manage-
ment functionality as offered to traditional data. This requires the storage of the
documents 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 to
documents 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 database
management 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 the
intrinsic data model behind XML data, the search space for query optimization
is much larger, which means the efficiency of traditional optimization approaches
will degrade unacceptably when applied to XML data. In other words, we have
to work out a much more progressive way of pruning the search space to achieve
acceptable performance. Second, the structure of XML documents, which can
be interrogated in an XML query and is normally implied in the DTD or XML
schema of the documents, provides opportunities for efficient semantic query
optimization, which shall be effectively exploited to achieve better optimization
efficiency for XML queries.
This chapter addresses the optimization issue of structured-document queries in
a database environment. Considering the dominance that XML has already
gained, our discussion is focused on XML-compliant documents, which are more
generally referred to as XML data. The query optimization strategy we present
here is transformation-based. The optimization of a query is accomplished
through a series of equivalent transformations applied to the query. Transforma-
tion rules in our system are all derived from the equivalences that we identified
in the specific context of XML document queries. The main theme of this chapter
is XML-document specific equivalences and the transformation rules derived for
XML query optimization.
The remainder of this chapter is organized as follows: the chapter first gives a
brief review of related work. Next, it provides the preliminaries needed for the
subsequent discussion of this chapter. The chapter then addresses selected
equivalences that we have identified and used in our test bed. This is followed
by a section that discusses the intended application of our equivalences, i.e.,
deterministic transformations for XML query optimization, followed by an
optimization example. The chapter then concludes with a summary of the
discussion of this chapter and indicates future directions.
Related Work
Since SGML/XML entered the arena of database technology, a lot of work has
been 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 on
semistructured data management (e.g., Deutsch, 1999; McHugh, 1997) actually
addresses similar issues as structured-document management. Lore (McHugh,
1997, 1999), a DBMS designed for semistructured data and later migrated to
XML, has a fully-implemented cost-based query optimizer that transforms a
query into a logical query plan, and then explores the (exponential) space of
possible physical plans looking for the one with the least estimated cost. Lore is
well known by its DataGuide path index that together with stored statistics
describing the “shape” of the database provides the structure knowledge about
the data to help Lore’s optimizer prune its search space for a better plan. In this
sense, Lore is related to our work, but we capture the structure knowledge of
document data mainly from the DTDs and apply this knowledge on conducting
exclusively deterministic transformations on query expressions.
In the work of Fernandez (1998), a comparable strategy for exploiting a grammar
specification for optimizing queries on semistructured data is discussed, where
effort is made to make complete use of the available grammar for expanding a
given query. Our focus is different. We identify transformations that introduce
improvements on query expressions in a very goal-oriented manner.
78 Che
The work of Consens and Milo (1994) also exploits the document type definition
knowledge for query optimization. They replace a query algebra operator with
a cheaper one whenever the DTD allows. However, the DTDs considered in
their study are simpler than the ones of SGML/XML, and the authors do not
consider different grammar constructors.
Our work is innovative in systematically addressing the query optimization issue
for structured documents through algebraic transformations. Our approach
exploits the structure knowledge implied by the DTD and other heuristics to
conduct 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 algebraic
transformations on query expressions based on the PAT algebra (Salminen,
1994). The main theme of this work is to exploit the structure knowledge about
the documents, which is usually characterized by the DTD or XML schema of
the documents. The structure knowledge is used to conduct profitable transfor-
mations on query expressions for optimization. In this section we first introduce
a few DTD-related notions that are important for the subsequent discussion of
this chapter, followed by the PAT algebra, which forms the basis of query
transformations in our work.
DTD-Related Notions
XML, derived from SGML, is a markup language that identifies components of

structured documents by means of “tags”. For a given class of documents, the
legal 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 document
element types and is currently used in parallel with DTD. Subsequent discussion
in this chapter is based on the DTD notion, but the techniques we discuss apply
likewise to documents using XML schemas.
A DTD is the grammar for a class of documents. The figurative representation
of this grammar is a DTD graph, which is a useful concept and is formally
defined in the following text.
Definition 1 (DTD graph). The DTD graph of a specific DTD is a directed

graph G = (V,E). Its vertices in V are the names of the element types from
the DTD, and each element type name occurs only once. An edge (ETi,ETj)
in E indicates that ETj occurs in the content model of ETi. RT ∈ V is the root
element type of the DTD.
Figure 1 is an illustration of a fragment of the DTD graph for conference

proceedings. By means of a DTD graph, we can visualize some important
relationships induced by the DTD, such as the containment relationships among
document elements, which is defined next.
Definition 2 (Directly-contains/Directly-contained-in). Element type ETi

directly-contains element type ETj if there exists an edge (ET i,ETj) in the
DTD graph G. Conversely, ETj is directly-contained-in ETi. ETi is referred
to as an external type, and ETj an internal type with regard to the
containment relationship.
The transitive closure of directly-contains (or directly-contained-in) reflects

the 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 sequence

of element types (ETi, ... , ET j) s.t. ETk directly contains ETk+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 graphic
counterparts of directly-contains/contained-in and contains/contained-in
relationships among element types of the DTD. Literally, the term “a path from
ET1 to ET2” is different from “a path between ET1 and ET2”. The latter does
not concern the direction of the path. Path and edge are important concepts for
the identification of relevant structural properties of documents for semantic
query optimization, which we discuss in subsequent sections.
Notice that the above notions are defined at the type level of document
components, but imply structural relationships at the instance level. As long as
DTDs are available, we rely on DTDs to extract the structure knowledge of
documents, otherwise we need to obtain this useful structure knowledge for
query optimization by means of a document parser.
In addition to the above notions, further notions regarding the properties of the
structural relationships among document components are defined and used for
deriving the core transformation equivalences for query optimization.
PAT Algebra
The PAT algebra (Salminen, 1994) was designed as algebra for searching
structured documents. We adopted the PAT algebra and extended it according
to the features of SGML/XML compliant documents. The PAT algebra is set
oriented, in the sense that each PAT algebraic operator and each PAT
expression evaluate to a set of elements. Herein, we present a restricted version
of 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, etn
introduces a document element type’s name, “r” is a regular expression
representing a matching condition on the textual content of the document
elements, 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 the
same 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 those
whose 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 second
argument, while ⊃ returns all elements of the first argument that contain an
element of the second argument.
In the subsequent discussion, we use ext(E) and τ(E) as shorthands to denote the
element extent determined by the expression E after evaluation and the result
type of the elements in ext(E), respectively.
Following is a query example formulated according to the PAT algebra with
regard to the DTD shown in Figure 1:
Query example. Find all the paragraphs containing both “xpath” and “xlink” in
any 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, and
structure indices.
Content indexing has been extensively exploited in information retrieval (IR)
systems. Attribute indexing corresponds to the classical type of indexing pursued
in conventional DBMSs. Structure indexing is specific to structured-docu-
ments. It is similar to path indexing (Bertino, 1994) studied in object-oriented
databases. However, in our case the indexing mechanism needs to consider the
containment relationship between the relating elements.
When the containment relationship between the elements of two different
element types is expected to be frequently taken as a criterion for querying the
document database, a structure index between the two element types is
favorably built. Structure indices may be defined either from an external type
to an internal type or vice versa, corresponding to the “contains” and “contained-
in” relationships, respectively. To serve the purpose of this chapter, it suffices
to indicate that a structure index is simply defined as a map between the elements
of the two types related via the containment relationship. We introduce an
additional PAT operator, Iτ(E1)(E2), to indicate the application of a structure index
which is defined between the two types, τ (E1) and τ (E2), with the subscript
“τ(E1)” showing the return type of the index operation. This index operator will
be used in relevant equivalences and transformation rules.
82 Che
Equivalences for Document Query

Optimization
Our approach to XML query optimization is based on equivalent transformations
applied to the queries represented as PAT algebraic expressions. Equivalences
are the laws in our approach, based on which we derive the transformation rules
to 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 PAT
operators.
• Equivalences derived from the constraints imposed by the DTD of the
documents.
• 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 complexity
of their potential interactions are rather high, we also apply certain criteria in the
selection of the equivalences to restrict their number. Otherwise, we would
obtain an unmanageably large set of potential transformations. The criteria we
observe are as follows:
• Equivalence must have the potential to imply a profitable transformation.
• Equivalence must not imply transformations to further complicate or
expand 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 equivalent
to E1 under condition c; when the condition c is omitted, the corresponding
equivalence holds unconditionally. Furthermore, we introduce the following
shorthand 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 PAT

operators. We identified 31 generic equivalences in Che (2003). Due to lack of
space, we present only a few of them below:
Subset laws (5 stands for any subset of ext(E))

ε1. 5 – E ←→ φ
ε2. 5 ⊃ ⊂ E ←→ 5
‘–’ 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 a
subset relationship. The proof of the above equivalences is straightforward
except for the commutativity and associativity rules. In the following, as an
example, 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 the

PAT algebra is consistent with the given DTD. A single operand can be either
atomic, 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 set

exist, but need to take more than just one operator into account for deducing an
empty result, thus are precluded from our consideration according to our rule
selection criteria mentioned before.
Equivalences Based on Properties of DTD Structure
Although we have ruled out in the previous section the situations where
complicated exploitation of the DTD knowledge is needed, there are particularly
interesting situations that the DTD structure can be used most profitably to
achieve query optimization. We show a few of such special cases and present
the 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, the
element type Authors shown in Figure 1 is contained in element type Article and
in ShortPaper. But the types that are not shared, i.e., exclusively contained-in
another type, bear potential for query optimization.
Definition 4 (Exclusivity). Element type ETj is exclusively contained in

element type ETi if each path (e j,...,ek) with ej being an element of type ETj
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 that
the free(E) condition holds is when E is a plain element-type name etn. The free
PAT expression notion often serves as a necessary condition to make an
equivalence hold. The following equivalence comes from the exclusivity and the
free of restriction notions.
ε11. E1⊂E2 ←→ E1 if τ(E1) is exclusively contained in τ(E2) and

free(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 in
the above equivalence imposes no condition on the elements of E1, and thus the
equivalence 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 not
appropriate to transform queries involving subexpressions of the second form,
and we need to introduce the counterpart of exclusivity, obligation, for this
purpose.
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 ET j.
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 be
worthwhile to check whether a third element type, called entrance location,
exists that could render us opportunities for applying a potential structure index
or shortening the navigation path needed for evaluating an involved containment
operation.
Definition 6 (Entrance location). Element type EL is an entrance location

for τ(E1) and τ(E2) of a given DTD if in any document complying with the
DTD, all paths from an element e1 of τ(E1) to an element e2 of τ(E2) pass
through 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 location
definition. The equivalence corresponding to the ⊃ operation can be defined likewise.
In general, the adding of an additional element type, as introduced by an entrance
location, to a PAT expression is detrimental to the evaluation efficiency of the
query. Therefore, the leftward application of these equivalences is obviously
favorable, while the left to right-side transformation will only be applied under
certain special conditions to ensure final, obvious improvements on the query
expressions, e.g., to enable application of a structure index. We will show this
by the following transformation rule that combines exclusivity and entrance
location:
ε14. E1⊂E2 ←→ E1⊂E3 if τ(E3) is an entrance location for τ(E1)

and τ(E2), τ(E3) is exclusively contained in τ(E2), and free(E2) and
free(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 location
can be defined, but omitted herein.
Equivalences Applying Structure Indices
Using the index operation introduced in Section 3, the equivalence exploiting

structure 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 is
to directly apply the equivalences on query expressions for generating more
alternatives for each input query expression, and then according to a certain
criterion, e.g., cost comparison, choose the one with the cheapest cost. The
second way is to conduct only beneficial transformations on query expressions
toward the goal of optimization, which is usually achieved with resort to
heuristics.
The strategy adopted in our work is strongly heuristics-based as it applies only
deterministic transformations on query expressions for optimization. Here, the
determinism consists in: (1) all transformation rules are unidirectional, of
which each obtains determinate improvement on its input queries, (2) once a new
transformation is performed, the previous candidate (i.e., the input expression to
the transformation rule) is immediately discarded. The whole optimization
process conducted according to this strategy is a linear, deterministic process,
which step-wise improves on an input query and leads to the unique, final, optimal
alternative of the input query. Query optimization thus accomplished is highly
efficient 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 is
reached. Examples of significant improvements may be a potential structure
index being introduced or the input query expression being completely rewritten
to be more evaluation-efficient. In both cases, equivalent transformations are
performed according to XML-specific semantics at the PAT algebra level. So
the key transformations pursued in our system are heuristics-based semantic
transformations, which are usually conducted more efficiently by starting from
a carefully chosen standard format. In our system, this standard format is
achieved via a normalization step, called normalization phase, which also
carries out necessary simplification on input query expressions. The second
phase is, of course, the semantic optimization phase. During semantic transfor-
mation, in order to introduce a major improvement into an expression, element
names may be substituted and the newly introduced element names may have
redundancy with other parts of the expression. Therefore, a final cleaning-up
or simplification phase is employed.
In the following, we present sample transformation rules (Che, 2003), and then
show 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 of
the 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 R 2 - R5), and a bottom-up simplification (like
R6 - 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 intersection
with a selection operation; their correctness is self-evident. R6 is yet another
basic law of the set theory. R7 is to delete redundant restriction imposed by the
containment 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 readily
achievable, rather, relies on deep exploration of DTD knowledge such as
obligation, exclusivity, and entrance location.
Numerous cases have been identified for introducing structure indices into a
query (Che, 2003). The simplest case is to directly use an available structure
index 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 the
index operation into a query expression.
The second case is designed to reveal the applicability of a potential structure
index that is not directly available. The corresponding rule combines the
commutativity and associativity laws into a single transformation:
R9. (E1 ⊃ ⊂ (E2 ⊃ ⊂ E3))⇒((I τ(E1)(E3) ∩E1) ⊃ ⊂ E2) if a structure index

between τ (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 — is
explored.
Simplification Rules
The third phase reapplies most of the simplification rules of Phase 1, and
introduces 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 in

the earlier part of the chapter to show how our deterministic transformation idea
works.
90 Che
Transformation Example
The query retrieves all the paragraphs containing both “xpath” and “xlink” from
any 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”(Paragraph) ) ⊂ Article)
(σr=“xpath”(Paragraph ∩ σr=“xlink”(Paragraph) ) ⊂ Article)
(σr=“xpath”(σr=“xlink”(Paragraph ∩ Paragraph) ) ⊂ Article)
⇒ (∩ deletion by R6)
(σr=“xpath”(σr=“xlink”(Paragraph) ) ⊂ Article)
⇒ (index introduction by R8)
(I Paragraph(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 XML
databases, the work addressing equivalences for XML query optimization is rare.
In this chapter, we elaborated on the equivalences that we developed for XML
query 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 optimal
one is decided based on cost comparison.
Currently, a lot of work is continuing on various aspects related to XML data
management, 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 XML
databases is a rarely explored but fascinating realm.
Our optimization is performed at the logical level — PAT expressions. One
interesting extension to our current work is to complement the logical (plan)
optimization by introducing a compact physical (cost-based) optimizer to achieve
further better optimization result.
Acknowledgments
The author would like to show great appreciation to his former colleagues at
Fraunhofer-IPSI (formerly known as GMD-IPSI), Germany. This continuing
research at the author’s current affiliation was originally initiated at GMD-IPSI
in 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-Oriented
Database Management Systems. In J.C. Freytag, D. Maier & G. Vossen
(Eds.), Query Processing for Advanced Database Systems. Morgan
Kaufmann Publishers, 383-418.
92 Che
Bohannon, P., Freire, J., Roy, P. & Simeon, J. (2002). From XML Schema to
Relations: A Cost-Based Approach to XML Storage. Proceedings of the
18th International Conference on Data Engineering (ICDE’02), (pp.
64-73).
Böhm, K., Aberer, K., Özsu, T. & Gayer, K. (1998). Query Optimization for
Structured Documents Based on Knowledge on the Document Type
Definition. Proceedings of IEEE International Forum on Research and
Technology Advances in Digital Libraries (ADL’98), (pp. 196-205).
Chan, C. Y., Felber, P., Garofalakis, M. & Rastogi, R. (2002). Efficient Filtering
of 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 Efficient
Index Structure for Regular Expressions. Proceedings of VLDB 2002,
(pp. 263-274).
Chaudhuri, S. & Gravano, L. (1996). Optimizing Queries over Multimedia
Repositories. Proceedings of SIGMOD’96, (pp. 91-102).
Che, D. (2003). Implementation Issues of a Deterministic Transformation
System for Structured Document Query Optimization. Proceedings of
2003 International Database Engineering & Application Symposium.
Che et al. (2003). Query Processing and Optimization in Structured Document
Database Systems. Manuscript in preparation for publication on the VLDB
Journal.
Chien, S., Vagena, Z., Zhang, D., Tsotras, V.J. & Zaniolo, C. (2002). Efficient
Structural Joins on Indexed XML Documents. Proceedings of VLDB
2002, (pp. 263-274).
Consens, M. & Milo, T. (1994). Optimizing Queries on Files. Proceedings of the
1994 ACM SIGMOD International Conference on Management of
Data, (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 Data
with STORED. Proceedings of ACM SIGMOD 1999, (pp. 431-442).
Fernandez, M. F. & Suciu, D. (1998). Optimizing Regular Path Expressions
Using 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 Using
an 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 and
PAT arrays. New York: Prentice Hall.
Gottlob, G., Koch, C. & Pichler, R. (2002). Efficient Algorithms for Processing
XPath Queries. Proceedings of VLDB 2002, (pp. 95-106).
Grust, T. (2002). Accelerating XPath location steps. Proceedings of SIGMOD
Conference 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 the
International Workshop on the Web and Databases (WebDB), (pp. 151-
170).
Lee, K., Lee, Y. K. & Berra, P. B. (1997). Management of Multi-Structured
Hypermedia Documents: A Data Model, Query Language, and Indexing
Scheme. Multimedia Tools and Applications, 4(2), 199-224.
Li, Q. & Moon, B. (2001). Indexing and Querying XML Data for Regular Path
Expressions. Proceedings of the 27th International Conference on Very
Large Databases, (pp. 361-370).
McHugh, J., Abiteboul, S., Goldman, R., Quass, D. & Widom, J. (1997). Lore:
A Database Management System for Semistructured Data. SIGMOD
Record, 26(3), 54-66.
McHugh, J. & Widom, J. (1999). Query Optimization for XML. Proceedings of
the 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 Processing
Scheme for Integration of Structured Document Repositories and Rela-
tional Databases. Proceedings of the Fifth International Conference on
Database Systems for Advanced Applications (DASFAA 1997), (pp.
145-154).
Navarro, G. & Baeza-Yates, R. (1997). Proximal Nodes: A Model to Query
Document Databases by Content and Structure. ACM Transaction on
Information Systems, 15(4), 400-435.
Özsu, M. T., Iglinski, P., Szafron, D. & El-Medani, S. (1997). An Object-
Oriented SGML/HiTime Compliant Multimedia Database Management
System. 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 Text
Search. Acta Linguistica Hungarica, 41(1), 277-306.
94 Che
Shanmugasundaram, J., Tufte, K., Zhang, C., He, G., DeWitt, D.J. & Naughton
J.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 Pattern
Matching. Proceedings of ICDE’02, (pp. 141-150).
Yan, T. W. & Annevelink, J. (1994). Integrating a Structured-Text Retrieval
System with an Object-Oriented Database System. Proceedings of the
20th VLDB Conference, (pp. 740-749).
Specifying Coherent Refactoring of Software Artefacts 95
Chapter V
Specifying Coherent
Refactoring of
Software Artefacts with
Distributed Graph
Transformations
Paolo Bottoni, University of Rome “La Sapienza”, Italy
Francesco Parisi-Presicce, University of Rome “La Sapienza”, Italy

and 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, while
preserving its behavior. Even though the input/output view of a system’s
behavior does not change, refactoring can have several consequences for
the 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 modifications

must be reflected in the system model, generally expressed through UML
diagrams. We propose a formal approach, based on distributed graph
transformation, to the coordinated evolution of code and model, as effect
of refactorings. The approach can be integrated into existing refactoring
tools. Due to its formal background, it makes it possible to reason about the
behavior preservation of each specified refactoring.
Introduction
Software is subject to changes and a piece of software may need changes for
several reasons. One such reason is the introduction of new requirements that
cause the need for design changes. The introduction of a new requirement can
be a consequence of either the iterative development process chosen for the
project that constructs the system incrementally, or the fact that the requirement
was overlooked in the initial specification and design of the system. As a simple
example, 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 option
of using the new algorithm.
Object-oriented programming has made many changes easy to implement, often
just by adding new classes, as opposed to more traditional approaches requiring
many modifications. But adding classes may not be sufficient. Even in the simple
example 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” into
algorithm-specific elements and general ones, the latter to be “moved” to a new
class 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 able
to reuse (part of) it. As an example, consider the case of two teams developing
two class libraries independently. The two libraries may contain different classes
implementing the same basic objects (windows, lists) or the same operations to
manipulate them with different names. In order to integrate the libraries, it is best
to remove these inconsistencies, by changing one library to use the basic classes
or the operation names of the other one. Simple modifications such as the change
of an operation name are not easy to implement, as they require searches for the
procedures that can invoke them or for the other operations that they would
override with the new name.
The two modifications above are examples of what is called refactoring of

code. Actually, software applications consist of code as well as specifications
and documentation, these being valuable company assets. The diffusion of UML
in large programming organizations is creating a wealth of documentation as
collections of UML diagrams, inspected by developers and designers, or used to
communicate with the project shareholders. Documentation repositories facili-
tate software reuse and design pattern identification. Ideally, refinements or
adaptations should be traceable to the original material, and code transformations
reflected 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, this
can have consequences for the computing process, as expressed for instance by
the 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). It
is demonstrable that they preserve program behavior, and it is usually known in
which way they modify static specifications, i.e., class diagrams. Refactoring
can also occur in design, involving modifications of interaction, state machine, or
activity diagrams.
However, not all transformations induced by refactoring are actually mapped
back to the relevant documentation. Since refactoring is usually performed at the
source code level, it may be difficult to maintain consistency between the code
and its specification – expressed for example with UML diagrams – which
usually refers to the code original version. In particular, one has to identify the
relevant diagrams when modifying a piece of software. Two strategies can be
adopted to preserve consistency: either restoring the specification after a chosen
set of changes, or coherently defining the effects of each refactoring on the
different 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 more
intricated.
We discuss an approach to the problem of maintaining consistency between
source code and diagrams, both structural and behavioral, using the formal
framework of graph transformation. In particular, Abstract Syntax Trees
describe the source code, while UML diagrams are represented as graphs,
conforming to the abstract syntax presented in the UML metamodel. The UML
diagrams 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 modeling
coherent refactorings as graph transformations distributed on several graphs.
Complex refactorings, as well as checking of complex preconditions, are
decomposed into collections of distributed transformations whose application is
managed by control expressions in appropriate transformation units.
In the rest of this introduction, we set the background for our work, by introducing
the refactorings used in the motivating example and reviewing some approaches
to refactoring and software evolution via graph rewriting, and illustrating
motivations for the coherent refactoring of code and models. Background
notions on graph transformation are then given. Next, the problem of maintaining
consistency among specification and code is reformulated as the definition of
suitable distributed graph transformations, and our approach is illustrated with
two important refactorings. The next section discusses the principles under
which one can establish correspondences between abstract representations of
the code and of the model. Section 6 discusses forms of behavior preservation
and sketches out how formal results for graph transformation help in reasoning
about 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. For
instance, if a new method is introduced or has its name changed, a check is
needed to ensure that no method with the same signature is already present in
the inheritance hierarchy. Here, we only mention additional checks other than
checks for name clashes.
RenameVariable and RenameMethod change the name of a variable or method to
highlight structural or behavioral analogies in a set of classes: all references to
these features must be renamed. RenameMethod is one of the constituents of the
ChangeMethodSignature refactoring, with sub-refactorings such as
ChangeReturnType and ChangeParameterType, or addition and removal of
parameters. The EncapsulateVariable refactoring hides information by making a
variable private and providing public getter and setter methods for accessing and
updating it. All direct references to the variable are replaced by dynamic calls
to these methods. InsertClass expands the inheritance hierarchy by introducing a
new class B between a class A and its original superclass C. B becomes the
superclass for A and has C as its superclass. PullUpMethod allows replicated
methods to be moved from subclasses into a common superclass. To apply this
refactoring, the body of the pulled up method must not refer to any variable only
defined in subclasses. ExtractMethod derives from the composition of several
primitive refactorings, but it is so widespread that it can be considered as a single
one. It removes a block of code from a method and uses it to create a new
method, 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 as
parameters, and that the removed code form a block, i.e., it has a single entry
point and a single exit point.
Related Work
Several tools have been developed to assist refactoring. Some are packaged as
stand-alone executables, while others integrate refactorings into a development
environment. Many tools refer directly and exclusively to a specific language, for
example C# Refactory (http://www.xtreme-simplicity.net/) for C#, or
CoreGuide6.0 (http://www.omnicore.com) for Java. Xrefactory (http://
www.xref-tech.com) assists in modifying code in C and Java. All of these
provide a variety of refactorings, typically renamings and method extraction.
However, none of them mentions diagrams and the effects on other views of the
system, 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 of
languages, allows transformations of both the code and the class model, with
changes 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 with
several 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: pushing
up/down, methods/fields, and extract method/interface. The only diagrams
mentioned are class diagrams which are reverse engineered from the .java
files.
Reverse engineering is present in Fujaba (Niere et al., 2001), where the user can
reconstruct the model after a chosen set of changes of the code. A more efficient
option would be to define the effects of a refactoring on the different parts of the
model. This is more easily realized on structural models, where transformations
on such diagrams are notationally equivalent to the lexical transformation on the
source code, than on behavioral specifications. Modern refactoring tools,
however, work on abstract representations of the code, rather than on the code
itself, 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) illustrate
refactoring of statecharts, typically to extract a set of states to be part of a
composite state. Transformations of concrete diagrams are specified by pre and
post-conditions, written as OCL constraints. Metz et al. (2002) consider the
UML metamodel to propose extensions to use case models, which would allow
significant refactorings of such models and avoid improper current uses. These
papers, however, do not consider the integration with possible source code
related to these models.
Current class diagram editors do not extend changes to all other related
diagrams, limiting their “automation” to the source code, with the result that
direct intervention is needed to restore consistency among possibly various UML
diagrams representing the same subsystem. We adopt UML metamodel in-
stances and draw a correspondence between these and abstract syntax trees
representing code. Hence, a common graph-based formalism can be used as
basis for an integrated management of refactoring both the code and the model
in an integrated way.
Graph rewriting has been introduced as a basis for formalising refactoring in
work 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 AST
representations is not exploited. Moreover, integrated refactoring of model and
code by graph transformation has not been considered up to now.
Outline of the Approach
Our approach aims at precisely specifying integrated refactoring of model and

code, while maintaining the consistency between them achieved during the
development of a software project.
Indeed, software development follows typical patterns. Authors can start some
modeling activity, update and refine their models, start writing code, and modify
it. If a CASE tool is available, code can be generated from models, e.g., skeletons
of classes or collaborations for some pattern. Moreover, developers can decide
to compile the code, reverse-engineer, and update some parts of the model from
the 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 they
can 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 one
another, either by circumstance or by construction. To this end, we assume that
at any time a pair of graphs exists providing abstract representations of the code
and of the model. The code representation is in the form of an AST, while the
model is given through UML diagrams, and constitutes an instance of the UML
meta-model. The checking phase produces an interface graph IG and a pair of
graph morphisms from IG to the AST and UML graphs respectively. The
morphisms establish the correspondence between code and models. The rela-
tions between these graphs must be managed by the CASE tool. The subsequent
phases 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 on
the 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 of
code, they are usually restricted to the manipulation of structural aspects of the
model, namely class diagrams. Although this is intuitively justifiable by the stated
assumption that refactoring does not affect the behavior of systems, the
combination of refactoring with other forms of code evolution can lead to
inconsistencies between the model and the code. This could be avoided by a
careful consideration of what a refactoring involves, as shown in the following
two subsections.
Modification of Collaborations
In the refactoring ExtractMethod, a block of code blk is removed from a method

morig in a class C, a new method mnew is created, block blk is inserted as the
body of mnew and a call to mnew replaces the original code in morig. If the
execution of morig is represented in a collaboration diagram (Figure 1a), but the
refactoring tool cannot manipulate such a diagram, then the activation of mnew
cannot be represented. Suppose that mnew is subsequently moved from C to a
coupled 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 assume
that the last addition of the call to meth is significant enough to show in the
collaboration. But, as we have lost the consistency between the model and the
code, a simple-minded addition of the call to meth as a descendant of the call to
morig would result in the inconsistent model of Figure 1b. This can be avoided
if all the steps in this process are reflected in the collaboration: the extraction of
blk to mnew would be reflected by a self-call stemming from the activation for
morig, the movement of mnew to class D would transform the self-activation to
a call to this new class and the consequent activation of mnew in it, so that the
call 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 complex
processes, involving several classifiers, where the state evolution of the involved
elements is modeled. Suppose that an action is performed to the effect of setting
a field variable to some value, say x = 15. Hence, a state s appears in the model
indicating that an assignment has to occur at that time. If the EncapsulateVariable
refactoring is subsequently applied to the variable x, the code x = 15 is replaced
Figure 1. (a) Original sequence diagram; (b) inconsistent situation from

not reflecting the extraction of mnew; (c) desired consistent situation
:C :C :E :C :D :E
morig morig morig

meth mnew
meth
a) b) c)
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. Let

us consider the design of an intelligent Audio player, able to dynamically identify
a MusicSource, for example, on the basis of some preferences, and to obtain from
this source a piece of Music. It then sets up an environment, in which it causes
the 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 music
source to select some piece of music. This prevents reuse of the Audio class in
a non-controlled environment. Figure 2 shows components of the UML model:
class (2a), sequence (2b) and two activity diagrams (2c).
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
}
}
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 }
With a view to the possibility of reuse, the programmer decides to protect the
preferences, by applying the EncapsulateVariable refactoring. After this first
step, the affected code looks as follows, where the parts in bold mark the changed
elements. The new situation is reflected in the model diagrams of Figure 3.
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
}
}
The code above presents several possibilities for refactorings, allowing the
introduction 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 the
way in which they define the environment. On the other hand, content sources
must have a generic ability to accept a player and sending the appropriate content
to it, while the different forms of content will have specific realizations of the play
method. To this end, a first step is to extract the code for playing in an
environment from playMusic to a setEnvironment method. Method playMusic is
then renamed to playContent, while findMusicSource is renamed to findSource
and the variable musicSource to source, while in class Music, provideMusic is
renamed to provideContent. Refactorings are then performed to introduce new
classes and interfaces in an existing hierarchy, by creating and inserting the
abstract class AbstractPlayer and the interfaces Content and ContentSource. We
can now pull up methods and variables from Audio to AbstractPlayer. Finally, all
return and parameter types referring to the concrete classes are now changed
to the newly inserted types. The resulting code is reported below. Again, parts
in bold show the modified parts with respect to the previous version. The reader
can 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 }
Figure 2. Components of the UML model for the first version of code – (a)
class diagram; (b) sequence diagram; (c) activity diagrams
Audio # ms MusicSource
+ MusicDescription preferences + Music provideMusic(Audio requester)
# MusicSource findMusicSource()
# void playMusic()
- env Music
# play(Environment env)
Environment
(a)
a:Audio ms:MusicSource toPlay: Music

playMusic()
findMusicSource()
ms
provideMusic(a)
toPlay
play(env)
(b)
Audio::playMusic()
Audio::provideMusic()
a:Audio ms:MusicSource toPlay:Music
a:Audio ms:MusicSource
findMusicSource()
provideMusic(a)
start retrieval
ms:
set environment toPlay: Music

[found]
a.preferences
retrieve music
play(env)
(c)
The Formal Background
The algebraic approach to graph transformation (Corradini et al., 1997) is the

formal basis for our work, as graphs are natural means to represent code and
model structures. To handle model and code-related graphs in a separate but

consistent way, we apply concepts of distributed graph transformation. Finally,
the concept of transformation units is used to obtain a global control on structured
graph 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 of
edges 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 value
or object, expressed by elements of an algebra on some algebraic signature Σ.
Here, we consider typed attributed graphs. For graph manipulation, we adopt the
double-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 # ms MusicSource
# MusicSource findMusicSource() + Music provideMusic(Audio requester)
# void playMusic()
+ MusicDescription getPreferences()
+ void setPreferences(MusicDescription desc)
- env Music
Environment # play(Environment env)
(a)
Audio::provideMusic()
a:Audio ms:MusicSource toPlay: Music
playMusic() a:Audio ms:MusicSource
findMusicSource()
start retrieval
ms
provideMusic(a)
getPreferences()
getPreferences()
desc
retrieve music
toPlay
play(env)
(b) (c)
based on category theory. Using typed graphs, structural aspects appear at two
levels: the type level (modeled by a type graph T) and the instance level (modeled
by 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 is
defined, i.e., graph objects occurring in both L and R have the same type and
attributes and, if they have the same edges, will also have the same source and
target vertices. The left-hand side L represents the modification pre-conditions,
while the right-hand side R shows its effect. Vertex identity is expressed via
names, while edge identity is inferred from the identity of the connected vertices.
Additionally, graph rules comprise attribute computations where left-hand sides
may contain constants or variables of set X, while right-hand sides capture the
proper 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. NACs
are 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). For
a rule to be applicable, none of the prohibited graph parts Ni – L present in a NAC
may occur in the host graph G in a way compatible with a rule match m. A match
is an injective graph homomorphism m: L ∪ R → G ∪ H, such that m(L) ⊆ G and
m(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 14
for 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 objects
of L not belonging to R and symmetrically, that part of H is added which is
matched by new graph objects in R. Operationally, the application of a graph rule
is 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 the
remaining structure D= G–m(L–R) is still a proper graph, i.e., no edge is left
which 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 is
not possible. Third, glue D with R–L to obtain graph H. A typed graph
transformation system GTS=(T,I,R) consists of a type graph T and a finite set
R of graph rules with all left and right-hand sides typed over T. GTS defines
formally 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 two

abstraction levels: the network and the object level. The network level contains
the description of a system’s architecture by a network graph, and its dynamic
reconfiguration by network rules. At the object level, graph transformations
manipulate local object structures. To describe a synchronized manipulation on
distributed graphs, a combination of graph transformations on both levels is
needed. In a distributed graph each network vertex is refined by a local graph.
Network edges are refined by graph homomorphisms on local graphs, which
describe how the local graphs are interconnected. Each local graph may be typed
differently, only restricted by the fact that an interface type graph is fully mapped
to all connected local type graphs. We use distributed graphs where the network
graphs consist of three vertices: for the model, for the code and for their
interface. Furthermore, two network edges are needed, starting from the
interface vertex and going to the model and code vertices, respectively. The
corresponding refinement graphs are called model graph, code graph and
interface graph. The interface graph holds exactly that subgraph which
describes the correspondences between the other two local graphs.
A distributed graph rule r is a network rule n — a normal graph rule — together
with a set S of local rules — graph rules on local graphs — for all those network
vertices which are preserved. Each preserved network edge guarantees a
compatibility between the corresponding local rules. The rules must also be
consistent with common attribute values. In this chapter, network rules are
always identities, as the network is not changing. Two local rules, on the model
and the code graph, are synchronized by applying a common subrule on their
interface graph. We show here only local rules with grey levels indicating subrule
parts. We introduce two operators to assemble a distributed rule from local ones:
asOftenAsPossible means to apply a local rule as often as possible at different
matches in parallel, while || just denotes the distributed application of rules.
Transformation Units
Transformation units (Kreowski et al., 1997) are a general concept to control rule
application, by control conditions specified by expressions over rules. We use it
in the context of distributed graph transformation, in which a transformation unit
consists of a set of rules and a control condition over C describing how rules can
be applied. Typically, C contains expressions on sequential application of
rules, 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 passing
parameters to them, to be matched against specific attributes of some vertex. By
this mechanism, we can restrict the application of rules to those elements which
carry an actual reference to the code to be refactored. To this end, the rules
presented in the transformation units are meant as rule schemes to be instantiated to
actual rules, assigning the parameters as values of the indicated attributes.
Refactoring by Graph Transformation

We present the general setting of refactoring by graph transformation and
analyse a sample refactoring which involves transformation of the code and
more than one UML diagram. Furthermore, we show the use of transformation
units over distributed graph transformations to enforce synchronization and
atomicity 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 of
graphs, obeying the constraints imposed by a type graph. For the code, we refer
to the JavaML definition of an abstract syntax for Java (Badros, 2000), and we
consider the type graph provided by its DTD. Indeed, any JavaML document is
structured as a tree, i.e., a special kind of graph where an XML element is
represented by a typed vertex and its attributes by vertex attributes. The graph
edges show the sub-element relation and are untyped and not attributed. We call
this graph the code graph. For UML (OMG, 2002), the abstract syntax of the
UML metamodel provides the type graph to build an abstract representation of
the diagram that we call the model graph.
As an example, Figure 4 shows the code graph for class Audio. For space
reasons, we omit the representation of fields ms and env and method
findMusicSource. Figure 5 presents the model graph for the class diagram of
Figure 2a (without dependencies). Only the important fields of model elements
are shown. Details of model elements occurring in more than one figure are
shown only in one. Vertices that would be directly connected to a class vertex
in the code graph, appear in the model graph as feature elements for which the
class is an owner. Figures 6 and 7 present the components of the model graph
for the sequence and activity diagrams of Figure 2.
The model graphs, though presented separately, are different views of one large
graph representing the whole model. Indeed, behavioral diagrams are associated
with model elements which own or contribute to the model’s behavior. As an
example, 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 class
Audio
: java-class-file : java-source-program
c1‘: class a1‘: field : type

name = „Audio“ name= „preferences“ name= „MusicDescription“
visibility = public
m1‘: method : type

name= „playMusic“ name= „void“
id = „Audio:mth1“ primitive = true
visibility = protected
3 1 : assignment-expr
: block op = „=„ : lvalue a2‘: var-set
name= „ms“
2
: local-variable c6‘: send
name = „toPlay“ message= „findMusicSource“
: type
id = „Audio:var1“
name= „Music“
c7‘: send : target a2‘: var-ref
message= „provideMusic“ name= „ms“
c8‘: send : arguments o8‘: this

message= „play“ : target
o6‘: var-ref
i1‘: arguments o5‘: var-ref name= „toPlay“
name= „env“ idref=„Audio:var1“
Figure 5. Abstract graph for the class diagram of Figure 2a

type c1:Class owner feature a1:Attribute type c2:Class
name= „Audio“ owner name= „preferences“ name= „MusicDescription“
owner visibility= #public
:AssociationEnd feature m1:Method
name= „playMusic“
:AssociationEnd m2:Method
feature name= „findMusicSource“ visibility=#protected
visibility=#protected specification
o1:Operation
:Association :Association specification o2:Operation
a3:AssociationEnd
c4:Class
name= „env“
name= „Environment“
c3:Class visibility=#private
name= „MusicSource“ type type
type c5:Class
owner o3:Operation name= „Music“
a2:AssociationEnd
feature specification owner
name= „ms“ o4:Operation
visibility=#protected m3:Method
specification feature
name= „provideMusic“
visibility=#public :Method :Parameter
p1:Parameter name= „play“ name= „env“
name= „requester“ visibility=#protected kind=#in
:Parameter
kind=#in
kind=#return
feature of class Audio, and in Figure 7 as the element whose behavior is defined
by the component of the model graph for activity diagrams.
Conversely, object o2:operation appears as the specification for playMusic in
Figure 5, and as the operation for a CallOperationAction object in Figure 6. In the
next section, transformation units for distributed transformations are used to
Figure 6. Abstract graph for the sequence diagram of Figure 2b

:CollaborationInstanceSet
:InteractionInstanceSet
activator :Stimulus
:Stimulus activator :Stimulus

predecessor
activator :Procedure o4:Operation :Procedure

:Procedure name= „play“
:CallOperationAction
c7:CallOperationAction
o2:Operation
name= „playMusic“ c8:CallOperationAction
receiver predecessor o3:Operation

sender receiver name= „provideMusic“ i1:InputPin
o8: Object receiver
name= „a“ o7: Object sender destination
c1: Class o6: Object
sender name= „m“ :DataFlow
receiver name= „Audio“ name= „toPlay“
source
c3: Class
:Stimulus o1:Operation :OutputPin c5: Class
name= „MusicSource“
name= „findMusicSource“ name= „Music“
:Procedure c6:CallOperationAction :ReadLinkObjectEndAction

o5: Object
:LinkEnd name= „env“
a3:AssociationEnd
Figure 7. Abstract graph for the activity diagram of Figure 2c for executing
playMusic
behavior m1: Method
name= „playMusic“
:ActivityGraph
:Partition :Transition :Partition :Partition

contents target contents
:CallState source :SubActivityState ag:ActivityGraph
source
:Procedure :Procedure contents
target
:Transition :CallState
c6:CallOperationAction c7:CallOperationAction
:Procedure
o1:Operation o3:Operation
name= „findMusicSource“ name= „provideMusic“
o4:Operation
name= „play“
contents :ActionState target
:Transition
source
:Action :Procedure
modify code and model graphs in a coordinated way, based on correspondences

(further discussed in Section 5) between elements in the two graphs, indicated
by 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 the

hierarchy 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 of
inheritance must be evaluated by inserting edges of type gen from a class to its
ancestors, before checking the precondition. This can be easily done by rules not
shown here, but similar rules are presented in Bottoni et al. (2003).
Figure 8. Rule for variable encapsulation in the code graph
encapsulate_variable_code(in String cname, in String varname):
: type : type
name = t name = void
c‘: class c‘: class
name = cname name = cname
m1‘: method
a‘: field name= „set“+varname
name= varname id = cname + „:mth“ + d
a‘: field visibility = private visibility = x
name= varname
visibility = x
m2‘: method
1: type : block
: return name= „get“+varname
name = t
id = cname + „:mth“ + c
visibility = x : asignment-expr
: var-ref op= „=“
name= „varname“ : formal_arguments
1: type : lvalue
name = t
: type p1‘: formal_argument
name = t name = „arg“
id = cname + „:frm“ + d
: var-ref
name= „arg“ a1‘: var-set
id = cname + „:frm“ +d name= „varname“
Code graph transformation is now specified by rule encapsulate_variable_code

in Figure 8, where cname identifies the class to be modified, and varname the
variable to be encapsulated. This rule is complemented by NACs, two of which
are shown in Figure 9, reporting also the nodes in the LHS of Figure 8. These two
NACs check the absence of methods with the same signature in the class, while
the others check the absence in the whole hierarchy. All accesses to the variable
are substituted by method calls. Hence, Figure 10 shows the rule replacing direct
access to the variable with a call of the getter, while Figure 11 shows the rule for
value updates.
Figure 9. Two NACs for the rule in Figure 8, to check that no method exists
with the same signature as the inserted setter and getter methods
1: type : type
name= t name = t
c‘: class
c‘: class name = cname
name = cname
: formal_argument
name = „arg“
a‘: field
a‘: field name= varname
name= varname : formal_arguments
: method : type : method

1: type name= „get“+varname name= void id= „set“+varname
Rules operate locally on the components of the model graph for the diagrams
above. Figure 12 shows the encapsulate_variable_model rule acting on the class
diagram. Negative application conditions analogous to those for the code graphs
are also used, guaranteeing a check of the overall consistency of the represen-
tations. Consequently, we also need to compute the transitive closure of the
inheritance relation for model graphs (not shown). Rules
encapsulate_variable_model and encapsulate_variable_code are applied in paral-
lel along their common subrule shown in grey.
Figure 10. Rule to replace accesses to varname in cname with calls to the
getter
field-access(in String cname, in String varname):
1: var-ref 1: var-ref
id = i id = i
: target
ac: field-access c2‘: send

field= varname m‘: method m‘: method name= „get“+varname
c‘: class a‘: field c‘: class a‘: field

name= cname name= varname name= cname name= varname
Figure 11. Rule to replace updates of varname in cname with calls to the
setter
field-set(in String cname, in String varname):
1: lvalue 1: lvalue : arguments
2: expr-elems c3‘: send

name= „set“+varname
ac: field-set
field= varname m‘: method
m‘: method 2: expr-elems
c‘: class a‘: field c‘: class a‘: field

name= cname name= varname name= cname name= varname
The effect on activity diagrams is shown by the rule getEncVarInActivity in Figure

13, replacing variable access with a call of a getter. For simplicity, we omit all
input and output pins. We do not present the whole distributed rule, but only the
local rule acting on the model graph. If the variable replacement in the model
graph corresponds to some variable replacement in the code graph, all possible
rule applications of getEncVarInActivity have to be applied synchronously with
code rule field-access along their common subrule, which is shown in grey. An
analogous rule exists for replacing variable updates with calls of the setter
method.
Figure 12. LHS and RHS of the rule for variable encapsulation on the class
diagram component of the model graph
encapsulate_variable_model(in String cname, in String varname):
op2: Operation
c: Class c: Class
owner feature
name = cname name = cname
owner
owner owner
m2: Method
feature name= „set“+varname
a: Attribute feature visibility = x
name= varname a: Attribute feature
visibility = x name= varname
visibility = private m1: Method
name= „get“+varname
op1: Operation visibility = x
type type
1: Classifier 1: Classifier type p1: Parameter
name = t name = t name = „arg“
type
: Parameter
kind = #return
Finally, we consider the required modifications for sequence diagrams, for the
case of variable encapsulation. Since sequence diagrams do not show read and
write 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 the
refactoring 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 is
necessary 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 the
stimulus s for which s’ is the successor (or predecessor) in the new activation
sequence, and pass it as a parameter to the rule. For space reasons, we omit the
representation of the relative rule getEncVarInInteraction.
The rules in Figures 10, 11, and 13 must be applied at all possible instances of their
LHS in the distributed graphs. There may be several such instances, and we want
to apply a transformation in a transactional way, i.e., the overall application is
possible only if corresponding parts can be coherently transformed. Hence,
transition units specify some form of control on the application. In particular, the
control construct asOftenAsPossible states that a local rule must be applied in
parallel on all (non-conflicting) instances of the antecedent. Contextual elements
can be shared by different instances, but no overlapping is possible on elements
removed or transformed by the rule. Moreover, the construct || indicates the
distributed application of two or more rules.
Figure 13. Rule for modifying variable access in activity diagrams
getEncVarInActivity(in String cname, in String varname):
1:CallState
1:ActionState
2:Procedure
2:Procedure
ac:ReadAttributeAction
m1: Method
a: Attribute op: Operation
name= varname name= „get“+varname
c: Class
name = cname c: Class
m1: Method name = cname
op: Operation
name= „get“+varname a: Attribute
name= varname
To sum up, EncapsulateVariable is expressed by a transformation unit as follows:
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;
The user can also decide to request a modification of interaction diagrams. In this
case, he or she has to interactively provide a value for the stimulus after or before
which to place the new call, and the transformation unit is completed by the
following construct.
asOftenAsPossible getEncVarInInteraction(cname,varname,stimulus) end

asOftenAsPossible setEncVarInInteraction(cname,varname,stimulus) end
By applying the transformation unit, both code and model graphs are transformed
to reflect the existence and usage of the new methods. As an example, the graph
in Figure 14 is a subgraph of the resulting code graph (the body of playMusic is
not shown as it remained unchanged) obtained by applying the transformation
unit EncapsulateVariable, i.e., the local rule encapsulate_variable_code has been
applied once with arguments cname = “Audio” and varname = “preferences”.
Extract Method
In the words of Martin Fowler, “If you can do Extract Method, it probably means
you 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 to
lack 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 class
hierarchy is checked for variable encapsulation. In general, we can assume that
the code and model graphs are complemented by all the needed gen edges. The
pre-condition that the code to be extracted be a block is easily checkable on the
Figure 14. Code graph for class Audio after the EncapsulateVariable
refactoring
: java-class-file : java-source-program
c1‘: class a1‘: field : type

name = „Audio“ name= „preferences“ name= „MusicDescription“
visibility = private
: type
a3‘: field name= „Environment“
m1‘: method name= „env“
name= „playMusic“ visibility = private : type
id = „Audio:mth1“ name= „void“
visibility = protected primitive = true
: type
m3‘: method name= „MusicDescription“
name= „getpreferences“
id = „Audio:mth2“ : var-ref : type
visibility = public : return name= „preferences“ name= „void“
primitive = true
m4‘: method
name= „setpreferences“
: formal_arguments p2‘: formal_argument
id = „Audio:mth3“
: block name= „arg“
visibility = public
id = „Audio:frm1“
: lvalue a2‘: var-set
: asignment-expr
name= „preferences“
op= „=“
: var-ref : type
name= „arg“ name= „MusicDescription“
id = „Audio:frm1“
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 method
vertex, 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. The
code graph is inspected to identify all the var-set and var-ref elements where the
name of the variable is not the name of a formal-argument of the original method
or 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 that
there are no var-set or var-ref elements for that variable in the subtrees remaining
with the original method. The creation of the call for the new method is achieved
by substituting the removed subtrees with a send element with the name of the
new 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 by
simply showing the presence of the new method in the class, as the effects on
the referred variables and the existence of a call for this method are not reflected
at the structural level. For the activity diagrams, we need to identify the Action
associated with a given Operation. Such an Action can be further detailed through
a collection of Actions associated with it. So, we need to identify all those vertices
which correspond to roots of the moved subtrees, detach them from the
description of the Operation, and exploit them to create the description of the
Operation associated with the new method.
For interaction diagrams, one must identify the existing instances of Stimulus
occurring before and/or after the extracted code, and insert the Stimulus to a
CallOperationAction, for an Operation with the name of the new Method, with
equal receiver and sender. Moreover, each instance of CallOperationAction,
originating from the original Operation instances and related to a vertex in the
extracted subtrees, must now be related to an instance of Stimulus, whose
activator is the Stimulus for the new Operation. The existing predecessor and
successor associations for the first and last such instances of Stimulus are
transferred to the new Operation. These transformations must be applied as often
as possible, so as to affect all the descriptions of the behavior of the refactored
method. Indeed, calls to such methods can occur in different scenarios, meaning
that the sequence diagrams for all such scenarios must be modified.
Building Correspondences between Code

and Model Graphs
In order to manage distributed transformations involving the Abstract Syntax
Tree (AST) viewed as a graph and the graph representing the UML model, we
need 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 between
types of vertices in the two graphs. To this end, we adopt for AST the concrete
representation given by JavaML, an XML-based specification, while the graph
for the UML model is constructed in accordance with the UML metamodel.
In this section, we sketch the principles directing the construction of the
correspondences, as the complete construction is beyond the scope of this
chapter. In particular, we consider the structural and behavioral aspects of the
specification separately.
From the structural point of view, we can proceed top-down and see that
JavaML class vertices correspond to UML class vertices, and a JavaML field to
a UML Attribute. However, care must be taken in managing aspects of the
structural definition involving relations to other classes. For example, the
subclass relation is represented in UML by the presence of a pattern involving
two Class vertices, a Generalization vertex, and two associations relating the
latter vertex to the other two, one with the role of specialization, the other a
generalization. In JavaML, a superclass vertex, with a name attribute, constitutes
a leaf of the tree rooted in the class vertex. In such a case, IG would contain only
a 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 checking
that the superclass relation is consistently represented in the two graphs. A
similar situation occurs for the implements construct.
As concerns behavioral aspects, the method vertex in JavaML contains all the
information present in the code to characterize the method, in particular its
signature and its body. However, in the UML metamodel, this information is
distributed across an Operation vertex, maintaining information about the signa-
ture, and a Method vertex which simply contains the code of the method body. As
regards the signature, similarly to before, we relate Method and Operation
vertices and we check the agreement of the type information, without associating
the type subvertices for method to the Classifier vertices describing those types in
UML. This is due to the fact that a type vertex is present in JavaML every time
it is necessary, but, in a UML diagram, it needs to be present only once, and
associated with other vertices an arbitrary number of times.
To model not only the static declaration of a method, but also its behavior through
collaboration, 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 in
correspondence with the stmt-elems vertex, usually a block, which is the root of
the subtree for the description of the method vertex. In general, we want to put
into relation semantically equivalent elements, so we will consider the different
types 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 which
corresponds to the sequence of statements in the original code. The UML model
on the other hand, does not require an order to be specified for independent
actions. Control flow actions indeed exist, such as ConditionalAction or LoopAction,
and idioms such as Iteration can be expressed. However, actions not related
through some chain of DataFlow objects, need not be realized in any given order.
If desired, though, the modeler can prescribe the existence of ControlFlow
objects, defining predecessor and successor Actions.
The process of building such correspondences, i.e., of introducing elements in the
interface graph and establish the morphisms from this to the code and model
graphs can be modeled by rewriting rules. Figure 15 shows two local rules whose
distributed application on the code and model graph, respectively, produces the
following effect: if there are, both in the code and model graph, elements
representing a class s which is a superclass for a class c whose representations
Figure 15. Two rules to establish correspondences concerning class

inheritance
: java-class-file : java-class-file
c1‘: class : superclass c1‘: class : superclass

name = c name = s name = c name = s
: class c2‘: class

name = s name = s
c1:Class :Class c1:Class c2:Class

name= c name= s name= c name= s
specialization generalization specialization generalization
:Generalization :Generalization
in the two graphs have already been put in correspondence, as witnessed by the
identifiers c1 and c1’ for the two instances, then the two representations of class
s are put in correspondence, as witnessed by the generation of the identifiers c2
and c2’.
Behavior Preservation in Refactoring
The refactorings in Section 4 are historical ones, whose behavior preservation

properties are widely discussed. In general, it is important to have a methodology
to formally verify properties of new refactorings. The approach based on graph
transformations provides a formal basis to perform these checks and to generate
conditions 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 studied
here. Some of them are briefly described next (Mens et al., 2002):
• Type preservation: the refactoring does not change the type of any entity
not deleted.
• Access preservation: the refactoring maintains the access of a method to
at least the same variables accessed before the refactoring, possibly
through intermediate method calls.
• Update preservation: each refactored method causes the same variable

changes as before.
• Call preservation: each method causes the execution of at least the same
methods called before the refactoring.
The refactorings presented here are based on typed graph transformations.

Since these transformations always guarantee that all the resulting graphs are
correctly typed over the same type graph, type preservation (according to the
type graph) is always exhibited by them.
Well-Formedness Constraints
This kind of behavior preservation is not sufficient to ensure that the resulting
graph is an acceptable code or model graph. Well-formedness constraints are
needed to rule out undesired configurations of the produced graph (instance of
the 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. With
the 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 refactoring
if it produces unwanted effects. For example, a new method m defined in class
C should not override an existing method m with the same signature in a subclass
of C, or be overridden by an existing method with the same signature defined in
a superclass of C. This constraint is needed, for example, in both sample
refactorings presented in the section, Refactoring by Graph Transformation.
Not all constraints can be expressed by simple “forbidden” graphs. More general
constraints can be defined by using propositional logic (Matz, 2002) to compose
“atomic” constraints, formed by simple forbidden graphs, and injective graph
morphisms 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 have
the same name and a parameter of the same type as another method in the same
class, we can write the formula NOT two_methods_with_same_signature where
the constraint graph is presented in Figure 16. This formula is satisfied only if it
there are not two methods named mnew in a model graph having each exactly one
parameter of the same type.
Figure 16. Constraint graph expressing the well-formedness of methods

with one parameter
two_methods_with_same_signature:
: Class owner
name = target
feature
owner : Method
name=mnew
feature
parameter
: Method type
name=mnew : Classifier : Parameter
kind = #in
parameter type
: Parameter
kind = #in
Knowing the maximum number of arguments for a method, we can construct

similar forbidden configurations for each number of arguments. Generalizing this
idea, 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 the

application of refactoring rules, we can enlist the help of established results on
consistent graph transformations in Heckel et al. (1995). That approach consists
of first translating graph constraints into post-conditions of transformation rules
and then forming pre-conditions out of those post-conditions by applying the rules
backwards. In the special case of a forbidden subgraph as constraint, this
construction would yield a number of NACs for the rule, preventing the
application of the rule if it causes the construction of the forbidden subgraph.
For example, the application of this construction to the constraint in Figure
16 would yield NACs for the rule in Figure 13, in the case of method
“get”+varname.
Conclusions
We have presented a graph transformation-based approach to maintaining
consistency between code and model diagrams in the presence of refactorings.
The approach allows the coordinated transformation of two graphs representing
the abstract syntax, as derived from the code by a parser, and the UML model
of the software system. A correspondence is established between these two
graphs, starting from the correspondence between types of vertices in the
abstract syntax trees, as defined by the JavaML markup language, and types of
elements and associations in the UML diagrams, as defined by the UML meta-
model.
Although the approach has been demonstrated using Java and the JavaML
coding of its abstract syntax, it can be applied to any type of abstract syntax for
object-oriented languages, provided that a non-ambiguous correspondence
between the abstract syntax and the UML model components can be estab-
lished. As a consequence, an integrated tool which is able to perform refactoring
on code and model diagrams while maintaining the original correspondences
between these components is imaginable. This would require integrating the
ability of modern refactoring tools to manipulate ASTs, with a more general
interpreter for transformation units. Indeed, it is not needed that the tool exploits
graph transformations in order to manipulate the tree. As all refactorings are
individually described by a transformation unit, and a tool has a finite number of
them available, it is sufficient that the tree transformation is wrapped. In this way,
the parameters can be communicated to the other parts of a distributed
transformation. If the transformation occurs on a part of the code for which the
corresponding parts of the model have been identified, the relevant modifications
would automatically be performed.
The opposite process could also be envisaged in which a refactoring of a model
would reflect a modification of the corresponding code. This can be easily
performed on structural diagrams, for which we have seen that there is a close
correspondence between elements of JavaML and of the UML meta-model.
Future work will have to identify refactorings in the behavioral diagrams for
which 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 from
the WWW: http://www.cs.washington.edu/homes/gjb/JavaML
Bottoni, P., Parisi Presicce, F. & Taentzer, G. (2003). Specifying Integrated
Refactoring with Distributed Graph Transformations. In J. L. Pfaltz, M.
Nagl, & B. Böhlen (Eds.), Applications of Graph Transformations with
Industrial Relevance. Second International Workshop, AGTIVE 2003,
LNCS 3062, Springer, pp. 220-235.
Bottoni, P., Schuerr, A. & Taentzer, G. (2000). Efficient Parsing of Visual
Languages based on Critical Pair Analysis (and Contextual Layered Graph
Transformation). 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 and
double pushout approach. In G. Rozenberg (Ed.), Handbook of Graph
Grammars and Computing by Graph transformation, Vol. 1. World
Scientific, 163-246.
Fischer, I., Koch, M., Taentzer, G. & Volle, V. (1999). Visual Design of
Distributed Systems by Graph Transformation. In H. Ehrig, H.J. Kreowski,
U. Montanari & G. Rozenberg (Eds.), Handbook of Graph Grammars
and 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 Graph
Grammars: 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 transformation
units. International Journal on Software Engineering and Knowledge
Engineering, 7(4), 479-502.
Matz, M. (2002). Design and Implementation of a Consistency Checking
Algorithm for Attributed Graph Transformation. (In German.) Diploma
Thesis, Technical University of Berlin.
Mens, T. (2000). Conditional Graph Rewriting as a Domain-Independent For-

malism for Software Evolution. In Proceedings of AGTIVE’99, LNCS
1779, (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 Diagrams
from Java Code using Patterns. Proceedings of the Second Workshop on
Soft 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 UML
models. Proceedings of UML 2001, LNCS, 2185 (pp. 134-138). Springer-
Verlag.
Section II
Elaboration of
Transformation
Approaches
Declarative Transformation for Object-Oriented Models 127
Chapter VI
Declarative
Transformation for
Object-Oriented
Models
Keith Duddy, CRC for Enterprise Distributed Systems Technology
Anna Gerber, CRC for Enterprise Distributed Systems Technology

Michael Lawley, CRC for Enterprise Distributed Systems Technology

Kerry Raymond, CRC for Enterprise Distributed Systems Technology

Jim Steel*, CRC for Enterprise Distributed Systems Technology

Abstract
This chapter provides a context and motivation for a language to describe

transformations of models within an object-oriented framework. The
requirements 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 these

requirements. A concrete syntax is introduced along with some example
transformations. Finally, we discuss the tools required to use the language
within a model-driven software engineering paradigm. The authors aim to
demonstrate the principles of model transformation within an object-
oriented framework, and show how this can be applied to the development
of software systems.
Introduction
In Model-Driven Architecture - A Technical Perspective (2001), the Object
Management Group (OMG) describes an approach to enterprise-distributed
system development that separates the specification of system functionality
from the specification of the implementation of that functionality on a specific
technology 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 system
evolution, high-level models that truly represent and document the implemented
system, support for integration and interoperability, and the ability to migrate to
new platforms and technologies as they become available.
While technologies such as the Meta Object Facility (MOF v1.3.1, 2001) and the
Unified Modelling Language (UML, 2001) are well-established foundations on
which to build PIMs and PSMs, there is as yet no well-established foundation
suitable for describing how we take an instance of a PIM and transform it to
produce an instance of a PSM.
In addressing this gap, our focus is on model-to-model transformations and not
on model-to-text transformations. The latter come into play when taking a final
PSM model and using it to produce, for example, Java code or SQL statements.
We believe that there are sufficient particular requirements and properties of a
model-to-text transformation, such as templating and boilerplating, that a
specialised technology can be used. One such technology is Anti-Yacc (Hearnden
& Raymond, 2002) and we deal briefly with such concrete syntax issues later in
the chapter.
This chapter focuses on a particular program transformation language, designed
specifically 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 we
then describe is designed to satisfy a set of identified requirements and is
illustrated with a variety of example transformation specifications. We pay

particular attention to how its features easily handle complex transformations
and enable modular, composable, and extendable transformation rules without
imposing 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 level
need to be automatically transformed into components, code, and configurations.
The use of a transformation language designed to support the features of modern
object-oriented specification and implementation technologies leads to more
flexible, maintainable, and robust transformations than present ad-hoc ap-
proaches.
The Meta Object Facility (MOF) is a technology specification standardised by
the OMG in 1997. It provides an object-oriented framework for the specification
of the abstract syntax of modeling languages. Space limitations do not permit a
detailed description of MOF features, however, one can think of MOF models
as corresponding to a slightly simplified UML Class Diagram.
The benefits of using this facility for the specification of languages such as the
Unified Modelling Language (UML) are that there are standard mechanisms
for automatically deriving:
• a set of interfaces in CORBA IDL or Java for programmatic access to
object model repositories,
• a concrete syntax based on XML DTDs and/or schemas known as XML
Model Interchange (XMI), and
• a customisable human-usable textual notation or HUTN (Human-Usable
Textual Notation, 2002) for representing model instances.
However, to date, the common MOF foundation of OMG languages such as

UML, the Common Warehouse Metamodel (CWM) and the Enterprise
Distributed Object Computing (EDOC) model has not enabled the use of a model
in one language to be transformed into a model in another language, except by
the following limited means:
• An XML document representing one model in the standard XMI form may
be manipulated using XSLT to produce another model.
• A program may traverse the model using CORBA or Java interfaces, and
populate 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 for

describing the generic transformation of any well formed model in one MOF
language into a model in some other MOF language (or perhaps in the same
language) is not yet available in a standard form. The OMG has issued MOF 2.0
Queries/Views/Transformations RFP (2003), known as QVT for short. It
requires 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 expresses
complete transformations,
• ensure that incremental changes to source models can be immediately
propagated to the target models, and
• express all new languages as MOF models.
In developing our response to the QVT RFP, the authors considered a number
of alternative approaches (Gerber, Lawley, Raymond, Steel & Wood, 2002). The
results, along with a review of other submissions to the QVT RFP, are
summarised below.
Chapter 13 of the OMG’s Common Warehouse Metamodel Specification (2001)
defines a model for describing transformations. It supports the concepts of both
black-box and white-box transformations. Black-box transformations only asso-
ciate source and target elements without describing how one is obtained from the
other. White-box transformations, however, describe fine-grained links between
source and target elements via the Transformation element’s association to a
ProcedureExpression. Unfortunately, because it is a generic model and re-
uses concepts from UML, a ProcedureExpression can be expressed in any
language 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 specific
model instances.
Varró and Gyapay (2000) and Varró, Varraó and Pataricza (2002) describe a
system for model transformation based on Graph Transformations (Andries et
al., 1999). In their approach, a transformation consists of a set of rules combined
using a number of operators such as sequence, transitive closure, and repeated

application. Each rule identifies before and after sub-graphs, where each sub-
graph may refer to source and target model elements and associations between
them (introduced by the transformation).
This style of approach to model transformation introduces non-determinism in
the 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 of
state changes, one needs to be very careful about the order of rule application
and repeated rule application to ensure termination of the transformation
process. A common technique is to delete elements from the source model as
they are transformed, but this requires that an element is transformed with a
single rule rather than allowing multiple rules to address different aspects of the
transformation.
Peltier, Ziserman and Bezevin (2000) and later, Peltier, Bezevin and Guillaume
(2001) and Alcatel, Softeam, Thales and TNI-Valiosys (2003) in their QVT RFP
response 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 the
concrete representations of model instances. As such, they propose MOF as the
common meta-model for representing models, XMI as the concrete expression
of model instances, and XSLT as the transformation tool to operate on these
concrete instances.
Their rules have a mix of both procedural and declarative styles that is in part due
to the fact that a given rule may only define a single target element per source
element and that target element construction is explicit. They also require explicit
ordering of the execution of rules.
XSLT (W3C, 1999) is explicitly designed for the transformation of XML
documents 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 is
based on XML. These reasons make it wholly unsuitable as an expressive model
transformation language.
The UML 1.4 specification introduces a new Action Semantics language (ASL),
which has also been proposed by both Kennedy Carter (2003) and Tata
Consultancy Services (2003) as a model transformation language. The ASL
provides a number of low-level constructs that can be composed to provide
specifications of actions. However, in order to be fully expressive for describing
actions, ASL is defined at a very low level of abstraction, lower than appropriate
for model transformation. Furthermore, it is an imperative language, so it does
not provide for implicit creation, or unordered rule evaluation.
Codagen Technologies (2003) propose an extension to XQuery and XPATH for

selecting/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 for
constructing target model elements. Because there can only be a single creation
rule that gives rise to a target model element, this proposal also effectively uses
explicit object creation, which we believe is an unfavourable approach to building
scalable and re-usable transformation definitions.
Finally, Compuware & Sun Microsystems (2003) propose a language that is
based on OCL 2.0 for queries/selection, is declarative, uses implicit creation, and
results in links between target model elements and the source model elements
that lead to their creation. However, the language is defined as a minimal
subtyping of the MOF meta-model and consequently provides little in the way of
structuring mechanisms to guide the user in writing transformation definitions.
Design Requirements for OO-Based

Transformation
Consider the problem of representing data described by an object-oriented class
diagram in a relational database. Figure 1 shows possible models of the concepts
involved in these two domains.
This is an interesting transformation problem because the two models are
familiar to many people, and they are not so similar that a transformation is
essentially one-to-one. Additionally, there are simple alternative transformations
Figure 1. Simple source and target models
NamedElt
name : String
Named
1 -name : String
Classifier
isAbstract : boolean
type
* attr Table col Column type Type

DataType Class Attribute
multivalued : boolean
super 1 * 1 * * 1
0..1 key *
sub *
possible that result in different performance characteristics that we can also

explore.
Let us consider what such a transformation might involve. Firstly, we might
expect each Class to have a corresponding Table, each DataType to have a
corresponding Type, and each Attribute of each Class to have a corresponding
Column in the corresponding Table. Since our class model doesn’t contain any
information about the combination of attributes (if any) that constitute a key, we
will also need a Column per Table to represent an object-id.
However, note that an Attribute may be multi-valued, so it would be rather
inefficient 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 can
perform the requisite joins.
If an Attribute’s type is a DataType, then the corresponding Column’s type
would be the Type corresponding to the DataType. But if the Attribute’s type is
a Class, then the corresponding Column would need to be a foreign key, so its
type would be that of the (primary) key of the referenced table which is the
object-id Column.
So far, describing the transformation has been relatively straightforward. Things
get 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 with
its attributes split between several tables. An alternative transformation involves
creating a Column for every Attribute owned by a Class and for every Attribute
owned by a supertype of the Class.
Below we show, step by step, how one would express the transformations
described above in our language. However, before we look at these details we
reflect on the high-level natural-language description of the transformation we
have just outlined in order to motivate the design of our language.
The first thing to notice is that the description above is naturally declarative. It
describes the things we want to generate and the reasons why we want to
generate them, but it does not say how or when to create them, not does it involve
a description of traversing either the source or the target models. Additionally,
while there are natural dependencies between parts of the description, there is
no explicit statement of “do this then do that”. Rule ordering is implicit, not
explicit. Since the declarative style is a natural way to communicate a transfor-
mation description in a human language, we believe it is also suitable, indeed
preferable, for a formal language for specifying transformations to be declara-
tive.
A set of functional and usability requirements for a transformation language has
been 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-transformation
language must be able to:
• match elements, and ad-hoc tuples of elements, by type (include instances
of sub-types) and precise-type (exclude instances of sub-types);
• filter the set of matched elements or tuples based on associations, attribute
values, and other context;
• match both collections of elements not just individual elements. For
example, 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 ordered
association links), either when matching source elements or producing
target elements;
• handle recursive structure with arbitrary levels of nesting. For example, to
deal 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 readability

and expressiveness concerns, require that:
• there is no requirement to explicitly specify the application order of the
rules, and all rules are matched against all relevant source elements;
• creation of target objects is implicit rather than explicit. This follows from
the previous requirement; if there is no explicit rule application order, then
we cannot know which rule creates an object and are relieved of the burden
of having to know;
• a single target element can be defined by multiple rules. That is, different
rules can provide values for different attributes of the same object;
• patterns can be defined and rules are able to be grouped naturally for
readability and modularity;
• embedding of conditions and expressions in the language is explicit and
seamless;
• transformation rules are composable.
Our experiences have shown that there are three fairly common styles to
structuring a large or complex transformation, reflecting the nature of the
transformation. They are:
• Source-driven, in which each transformation rule is a simple pattern (often
selecting a single instance of a class or association link). The matched
element(s) are transformed to some larger set of target elements. This style
is often used in high-level to low-level transformations (e.g., compilations)
and tends to favour a traversal style of transformation specification. This
works 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 of
source elements (involving some highly constrained selection of various
classes and association links). The matched elements are transformed to a
simple target pattern (often consisting of a single element). This style is
often used for reverse-engineering (low-level to high-level) or for perform-
ing optimizations (e.g., replacing a large set of very similar elements with
a common generic element);
• Aspect-driven, in which the transformation rule is not structured around
objects and links in either the source or target, but more typically around
semantic concepts, e.g., transforming all imperial measurements to metric
ones, replacing one naming system with another, or the various parts of the
object-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 to
determine which of several transformation rules (that may or may not apply to
any given object) should then have responsibility for creating the target object.
Typically the target object is only required if any one of the transformation rules
can be applied, but no target object should be created if none of the rules can be
applied. This is extremely difficult to express if explicit creation is used.
A Declarative Object-Oriented
Transformation Language
We describe a declarative object-oriented transformation environment that
satisfies the requirements described in the previous section. We present both a
formal model for transformations and a concrete syntax and illustrate the
transformation language through a series of simple examples.
This section presents the transformation language that we have designed to
address the problems faced when realising the MDA, by illustrating how the
language 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 in
a 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 rule
may also supersede another transformation rule. This allows for general-
case rules to be written, and then special-cases dealt with via superseding
rules. For example, one might write a naive transformation rule initially,
then supersede it with a more sophisticated rule that can only be applied
under certain circumstances. Superseding is not only ideal for rule optimi-
zation and rule parameterization, but also enhances reusability since
general purpose rules can be tailored after-the-fact without having to
modify them directly.
• Tracking relationships are used to associate a target element with the
source elements that lead to its creation. Since a tracking relationship is
generally established by several separate rules, other rules are able to
match elements based on the tracking relationship independently of which
rules were applied or how the target elements were created. This allows
one set of rules to define what constitutes a particular relationship, while
another set depends only on the existence of the relationship without
needing to know how it was defined. This kind of rule decoupling is essential
for rule reuse via extending and superseding to be useful.
Establishing and maintaining Tracking relationships is also essential for
supporting round-trip development and the incremental propagation of
source-model updates through the transformation to the target model(s).
• Pattern definitions are used to label common structures that may be
repeated throughout a transformation. A pattern definition has a name, a set
of parameter variables, a set of local variables, and a term. Parameter
variables can also be thought of as formal by-reference parameters.
Pattern definitions are used to name a query or pattern-match defined by
the term. The result of applying a pattern definition via a pattern use is a
collection of bindings for the pattern definition’s parameter variables.
Scope -scope
-supercedee * -tracking -var

-superceder -trule Tracking Var -var
0..1 TRule * -domain -name *
* -trule * * -local
0..1 -src * -name 1 1
-trule -extendee -superceder
-extendee 0..1 0..1 * -tracking
-tracking
Term 0..1
0..1 PatternDefn -supercedee
-extender -trule* * -extender **
*
-name
-transformation 1
-body
-source
-extender
Transformation -target Expr
-term * -patternDefn * * -extendee -arg
-name
*
1 -srcModel
1
-tgtModel
* -defn *
-transformation -arg *

Figure 2. Transformation model
0..1 CompoundTerm SimpleTerm -simpleTerm 0..1 CompoundExpr SimpleExpr VarUse *
-representation
-compoundTerm 0..1 -expr -use
* -tgt
AndTerm OrTerm IfTerm MofTerm TrackingUse PatternUse CollectionExpr FunctionExpr NamedExpr

-ifTerm : Term -domain -kind -operator -name
-thenTerm : Term
-elseTerm : Term
*
-use
MofFeatureOrder MofInstance MofLink MofLinkOrder StringConstant IntConstant BooleanConstant EnumConstant

-lesser : MofFeature -type -type -lesser : MofLink
-greater : MofFeature -greater : MofLink
MofFeature
-extraction
-feature
Declarative Transformation for Object-Oriented Models
137
The MOF model diagram in represents our current proposed Transformation

model (DSTC, IBM & CBOP, 2002). The important classes are explained in the
following text.
The lower part of Figure 2 is an expression language metamodel constructed
specifically for identifying MOF model elements in patterns and rules. Its two
main abstract metaclasses are Term and Expression. Terms are evaluated to be
either true or false with respect to the models supplied for transformation. An
Expression represents some kind of value referenced by a Term. VarUse is a
particular 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 valid
MOF type.
The top left part of Figure 2 shows the main structuring parts of the model. TRule
represents a transformation rule, which is a statement that for all model elements
that can be bound to the Vars of the TRule’s src Term such that this Term
evaluates to true the TRule’s tgt Terms must also evaluate to true. Generally, this
involves creating new MOF model elements in the target model(s) and setting
their attributes. In order to know when and how many model elements to create,
Trackings are used. A Tracking is a statement of a functional dependency
between a set of source model elements and a target model element. This allows
several independent rules to require a target object to exist without needing to
explicitly coordinate which rule is responsible for actually creating the instance.
Transformation rules may be related to other transformation rules in either or
both of the following two ways:
• A rule that extends another rule augments its source matching term with
the source term of the extended rule.
• A rule that supersedes another rule restricts the source matching term of
the superseded rule with the negation of its source term.
Rule extending and superseding allow for Transformations, which supply a

namespace for rules and pattern definitions, to be reused and specialised. In
particular, they allow rules to be written simply for the general case, and then
superseded for some special or exceptional cases.
Concrete Syntax by Example
We now present the transformation described earlier using an SQL-like concrete

syntax one rule at a time, based on one rule per concept-to-concept mapping. We
then link these together and fill in details to provide the total transformation from
our OO model to our Relational model.
The first key element of our transformation is that a Class will be transformed
into a Table with an object-id Column, so this becomes our first rule. We also
want to make sure that we preserve a tracking relationship between the table we
create and the class from which we create it. The next major mapping, from an
Attribute to a Column, is similar, as is the rule for DataTypes. As such, we start
with 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 names
to be mapped to the names of their corresponding Tables and Columns. We can
make sure we have the right Class-Table or Attribute-Column pair by looking up
the tracking relationships we established earlier. We can then write a rule from
an 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 the
ability to express rules as fine-grained mappings rather than having to write
complex, coarse-grained rules.
However, further inspection of our class diagram reveals that DataType names
must also be mapped. Rather than adding another OR clause to our rule, we
introduce 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 transformation
of an attribute will be contained by the appropriate table, i.e., the table resulting
from the transformation of the attribute’s containing class. We do this by again
looking up the tracking relationships established in our earlier rules. This gives
us 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 that
we 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 values
and one column for the Class’s object-id.
This new rule for attributes will need to match a subset of the cases that were
true for the previous rule, and we can reuse the earlier Attribute rule’s matching
pattern by using rule extension. However, we also want to indicate that the
earlier Attribute rule should not run when this new Attribute rule runs, and we
can do this using rule supersession.
So now we have a rule for transforming Attributes to Columns, and another for
linking 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 the
main Table for the Class. Therefore, we make a new rule that will supersede the
rule that puts Columns in Tables, and link the Attribute’s Column to a new Table
with 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 appropriate
type. So we need rules for mapping DataTypes to Types, and for assigning the
appropriate Type to a Column. The latter case requires two rules, since an
Attribute with a Class type is typed for a key value, but an Attribute with a
DataType 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 include

inherited attributes as columns in the tables of subclasses. To do this, we need
to 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 each
inherited attribute. To handle the linking of these columns to their tables, we need
to change the Attribute to Column tracking to include Class as a source, by
modifying 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 transformations

using a declarative language, we believe that the use of an appropriate concrete
syntax such as the SQL-like one introduced above will allay their fears and allow
them to reap the benefits of not needing to worry about rule order and explicit
object creation that a declarative language affords. Additionally, an equivalent
graphical syntax would be a useful addition for simple transformations, although
our experiences indicate that more complicated transformations are better
handled textually.
Advanced Transformations
As with expert systems, a substantial transformation embodies a significant
investment in capturing domain knowledge and, therefore, the careful organisation
and structuring of the transformation will aid its long-term maintenance and
evolution.
Several features of the transformation language described in this chapter are key
to supporting both re-use and maintenance of transformation definitions. These
features are the supersedes and extends relationships, and dynamic typing of
variables.
Duddy, Gerber, Lawley, Raymond & Steel (2003) describe in detail how
superseding and extending can be used in the context of a transformation to an
Entity Java Bean (EJB) model. Specifically, they show how a mapping that
results in remote access to EntityBeans can be modified to instead employ the
Session Façade pattern (Brown, 2001) using a SessionBean that delegates
methods to local EntityBeans. One could also use an extra source model as a
parameterisation, or marking model, to provide finer grain control over which
rules are applied to which source model elements.
Dynamic typing simplifies rule writing: if an object bound to a variable does not
have the attribute or reference mentioned in a term, then the term simply
evaluates to false rather than requiring explicit runtime-type introspection and
narrowing (down-casting). Dynamic typing also allows meta-transformations

and libraries of transformations matching common structural patterns to be
easily developed without the use of cumbersome reflective methods. Such
transformations may, for example, deal with mapping names in nested namespaces
to structured names in a single flat namespace.
Transformation Tool Set

The transformation language described previously is just one piece of the
automated development environment. Other tools that deal with the input and
output of concrete textual representations of models, and the graphical visualisation
of 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 both
an XML DTD and an XML Schema from a model, and a set of rules for
transferring data between conformant XMI documents and MOF-compliant
repositories. The main use of XMI is for interchange of models and model
instances 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 creating
a human-friendly language for an arbitrary MOF model. By exploiting the
inherent structure in a MOF model (containment, association cardinalities, etc.),
and allowing for some on-the-fly customisation (e.g., for default values) it is
possible to fully automate the generation of both parsers and printers of the
HUTN language for a given MOF model.
Most commonly, the ultimate goal of a transformation process is to generate code
or some other textual representation of a system. While it would be reasonable
to realise this goal by transforming an abstract model to a model corresponding
to the concrete syntax of the target language (Java, Cobol, HTML, etc.), this task
is particular enough to warrant and benefit from a specialised tool.
The motivation of the AntiYacc tool is to provide a simple means to render the
content of a MOF-based repository in a textual form corresponding to some
specified syntax. It is capable of producing text that conforms to an arbitrary
user-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 takes
a set of grammar rules decorated with code fragments to construct a stream of
lexical tokens from a traversal of a graph of MOF objects. An AntiYacc
specification also includes lexical rules that convert the token stream into text,
typically addressing issues such as horizontal and vertical white space, and
delimiters.
Finally, it would often be very useful to be able to visualise or edit a graphical
representation of the models being transformed. However, since much of the
time their metamodels may be purpose-designed and therefore have no standard
graphical representation (let alone a tool to display/edit the model), it would be
extremely useful to be able to generate such a tool in a manner analogous to the
HUTN 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 tool
is 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 models
describing the system to be built in platform-independent terms then generating
the system implementation for a particular, technology specific, platform. This
is the vision embodied in the OMG’s Model Driven Architecture (MDA).
We have described the functional and non-functional design requirements
identified for a language suitable for writing transformation definitions and
presented a language satisfying these requirements along with examples of a
usable, familiar concrete syntax for the language. We have also briefly touched
on issues relating to advanced transformations and mentioned a number of
additional technologies required for dealing with textual and graphical forms of
the models.
It should be noted that the transformation language presented here is evolving as
we gain further experience and as a result of the OMG’s RFP process. In
particular, influenced by the Compuware/Sun submission, we are extending the
concept of Trackings to more closely approximate a class model. Also, compo-
sition of transformations is essential for the use and extension of existing
transformations. While there is no explicit mention of this in the language
presented here, the ability to reference elements in one MOF model from another
MOF model should be sufficient for simple composition of transformations.
However, more sophisticated forms of composition, such as producing a
transformation that maps A to C from one that maps A to B and one that maps
B to C or producing a transformation that merges A and B to produce C from the
A to B and B to C transformations, is the subject of future research.
Additionally, the transformations discussed in this chapter have generally dealt
with transformation in a single direction, from model A to model B. Another use
of a declarative transformation language, and one in which the declarative nature

offers an advantage over imperative alternatives, is in the application of a single
transformation to perform transformations both from A to B, and back again.
This is another aspect that is currently under investigation by both the authors and
the larger OMG community.
References
A Human-Usable Textual Notation for the UML Profile for EDOC: Request
for Proposal. (1999). OMG Document ad/99-03-12.
Alcatel, Softeam, Thales & TNI-Valiosys. (2003). Response to the MOF 2.0
Queries/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 WebSphere
Developer 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 Views
and Transformations on Models using MOF, OCL and Patterns. OMG
Document ad/2003-03-24.
DSTC, IBM, & CBOP. (2003). MOF Query/Views/Transformations Initial
Submission. 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. Proceedings
of 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, Bell
Laboratories.
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 the
Workshop 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 Visual
Control 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 Automatic
Transformation 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 Document
formal/2002-01-02.
XSL Transformations (XSLT) v1.0. (1999). W3C Recommendation. Retrieved
from 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 Conceptual
Models to Data Models
Antonio Badia, University of Louisville, USA
Abstract
This chapter describes transformations between conceptual models (mainly
entity-relationship diagrams and also UML) and data models. It describes
algorithms to transform a given conceptual model into a data model for a
relational, object-relational, object-oriented and XML database. Some
examples are used to illustrate the transformations. While some
transformations are well known, some (like the transformation into XML or
into object-relational schemas) have not been investigated in depth. The
chapter shows that most of these transformations offer options which
involve important trade-offs that database designers should be aware of.
Introduction
Conceptual models aim at capturing the structure of reality, are high-level and
computer independent. Data models, on the other hand, aim at representing
reality in the computer, and are therefore less abstract. It is assumed that, in
creating an Information System, a conceptual model will be developed as part of
the 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 models
and data models are one of the most vital transformations in the development of
an Information System (Elmasri and Navathe, 2003). The purpose of this chapter
is 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 and
important data models (relational and object-oriented) have been developed and
are well understood. However, new data models like XML and the Object-
Relational data model are not included in these mappings. Translation into XML
is the focus of some research lately, but this is a relatively new area and not much
work has been done yet. Translation into Object-Relational databases is a
virtually unexplored topic, perhaps because it is felt that existing mappings into
the (pure) relational models are easy to extend to this case. However, Object-
Relational databases provide options to the designer that are not available in the
relational case. Therefore, some guidance is needed for the choices that appear
in the mapping process.
In this chapter, we review existing mappings and extend them to include these
new data models. We start with a review of the basic concepts, to establish some
vocabulary and make the chapter self-contained, followed by a description of
recent work in the area, including new and existing translations. One of the
purposes of the chapter is to put all of this research in a wider perspective and
examine the different approaches, something that is missing from the current
literature.
Background
For lack of space, we do not discuss conceptual or data models in depth; we
assume the reader is familiar with the basic ideas. However, we review some
basic concepts to establish a vocabulary.
Conceptual Models
We briefly review Entity-Relationship models and UML class diagrams. There

are other conceptual models, like Object-Role-Modeling (ORM); we will not
include them here.
An Entity-Relationship (E-R) (Chen, 1976; Thalheim, 2000) model is based on
three basic concepts: entity types, attributes and relationships. E-R models
are usually depicted in E-R diagrams; an example is given in Figure 1. Entity
150 Badia
Figure 1. E-R diagram
ssn name dname

locations
(1,1) (1,M)
street
Employee Department
(1,M)
(1,M) (0,M) address

(0,M)
Date city zip
reviews
hourly rate salary started manages
pname
(1,M) (1,M)
Hourly Salaried (1,M)

budget
employee employee
Project
types are depicted as rectangles with a name inside, attributes as ovals, and
relationships as lines with a diamond shape on them.
Entity types represent things either real or conceptual. They denote sets of
objects, 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 its
extension; particular objects are called entities.
Relationships are connections among entity types. Relationships may involve any
number of entity types; those involving two entity types (called binary relation-
ships) are the most common. However, n-ary relationships (involving n > 2 entity
types) are also possible (in particular, relationships relating one entity type to
itself are allowed). Relationships are fundamental in an E-R model in that they
carry very important information, in the form of constraints: participation
constraint tells us whether all objects in the extension of an entity type are
involved in the relationship, or whether some may not be. For example,
Department and Employee have a relationship Works-for between them. If
all employees work for some department, then participation of Employee in
Works-for is total. However, if there can be employees which are not assigned
to a particular department, then participation is partial. Cardinality constraint
tells us how many times an object in the entity type’s extension may be involved
in 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 type
E and relationship R a pair of numbers (min,max), where min represents the
minimum number of times an entity in E appears in R (thus, min represents the
participation constraint by being 0 for partial and 1 for total), and max represents
the maximum number of times an entity in E appears in R (thus, max represents
the cardinality constraint by being 1 for one-to relationships and greater than 1
for many-to relationship; the latter case is traditionally represented by using the
letters M or N). Thus, the (1,1) by Employee and Works-For indicates that all
employees work for exactly one department; the (0,M) by Department and
Manages indicates that not all departments manage projects, but those that do
may manage more than one.
Entity types and relationships may have attributes, which are properties with a
value. Attributes convey characteristics or descriptive information about the
entity type or relationship to which they belong. Attributes may be simple or
composite (made up of simpler parts, like the attribute Address of entity
Department in the example, which is made up of parts named street, city
and zip), single or multivalued (being capable of having one or several values
for a particular entity; multivalued attributes are displayed as dual ovals, like
locations in our example, meaning that some department may have multiple
locations), primitive or derived (a derived attribute value is computable from
other information in the model). A key attribute is an attribute whose value is
guaranteed 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 entity
types are assumed to have at least one key attribute.
A contentious issue is whether attributes are required (i.e., every entity of the
type must have a value for each attribute of the type) or optional (i.e., some
entities of the type may or may not have values for some attributes). Different
authors take different views on this issue, some even arguing that it is a mistake
to consider attributes optional (Bodart et al., 2001). Since this has an impact
when transforming E-R models into different data models, we will point out how
to deal with each view.
Some E-R models admit weak entities, entities with no key attributes; these
entities are connected by a one-to-many relationship to a regular entity, called the
strong 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 strong
entity. As a typical example, entity Employee has an associated weak entity
Dependent (shown as a double box). Clearly, an employee may be associated
with 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 associated
dependents also go away.
Many proposals for additional features have been made over the years. The most
successful one is the addition of class hierarchies, by introducing IS-A (class/
subclass) relations between entities. This addition, obviously motivated by the
success of object-oriented methods for analysis, allows the designer to recognize
commonalities among entities; usually this means shared attributes exist. Shared
152 Badia
attributes are removed and put together in a new entity (class) that is a
generalization of the others, and a class-subclass relationship is created. As in
object-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 line
joining the involved entity types. The IS-A relationship can be annotated to
distinguish several situations: whether the subclasses are disjoint or not; and
whether the subclasses together cover the superclass (i.e., every entity of the
superclass must also belong to one of the subclasses) or not. Note that both
dimensions are orthogonal to each other; hence, two annotations are needed to
determine the exact situation.
The Unified Modeling Language (UML) (Rumbaugh et al., 1999) is the
conceptual model for object-oriented design. In its current incarnation, it is a
large, complex model made up of several different parts. Here we concentrate
on static diagrams, which are the diagrams explaining the structure of informa-
tion in the system and its interconnections. The previous E-R diagram is given
in Figure 2 as a UML diagram for illustration purposes.
A static or class diagram has many similarities to an E-R diagram. The world
is 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 be
modeled by a structured domain, a domain with an internal structure (as an
example, see address in Department). In theory, a multivalued attribute
requires its own separate class; however, modern versions of UML allow
specifying a cardinality constraint on the link between attribute and class. This
seemingly minor point is very important since it gives the model the flexibility to
deal with optional attributes (by setting minimum cardinality to 0) and multivalued
attributes in a uniform framework, similar to XML (however, this is far from an
accepted norm; see next subsection). It is usual in class diagrams to give a data
type for attributes, and it is possible to give them a default value. In UML,
classes also have methods, procedural attributes which describe the behavior of
the objects of the class. Methods, though, cannot be completely specified in the
conceptual 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 top
one 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 association
by a dashed line). However, unlike relationships, associations cannot involve
more 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 to
the related classes; see Review in Figure 2); the resulting class is sometimes
Figure 2. UML diagram
Department
Employee
1..1 1..N
dname
ssn 1..N
address:{street,
name
1..N city,zip}
Reviews
1..1
0..N 0..N locations

Date Manages
1..N 1..N
Salaried 1..N
Hourly Project
Employee
Employee
pname
hourly rate salary budget
called an association class. Associations can have roles and cardinality and
participation constraints, though. Two special kinds of association are aggrega-
tion and composition. Their semantics are somewhat vague; aggregation is
supposed to represent a part-whole relationship, while composition is supposed
to be somewhat stronger then aggregation, in that an object contains another one
as a part. The main difference seems to be that objects that stand in a composition
association have a lifetime dependence: when an object that contains another is
destroyed, the contained objects must be destroyed, too (in some versions,
composition may involve an arbitrary number of objects). Thus, what we called
weak entities in the E-R model should be captured as a class associated by
composition with another class. However, the semantics of UML are informal
and fail to capture the special meaning that a part-whole relationship has
(Moschnig-Pitrik et al., 1999). Aggregations are displayed with a hollow
diamond, and associations with a filled diamond. Another special association is
the one between class and subclass, called a generalization. This is displayed
as an arrowhead.
Data Models
Here we briefly review the relational, object-oriented, object-relational and

semistructured (XML) data models.
The relational data model (Date, 2004) is well known; we simply overview its
main concepts here. A domain is a non empty set; intuitively, it provides a pool
of values. Every domain is assumed to come with a name (an infinite number of
names, technically). Given a schema or list of domain names R = {A1,…, A n},
154 Badia
a relation on R is a subset of the Cartesian product A1 x …x An. The elements

of the relation are called tuples. A key K for relation r in schema R is a subset
of R (i.e., a set of attributes) such that, for any two tuples in r, they are the same
if they have the same value for K.
A relational database schema is a set of relation schemas plus a set of integrity
constraints. An integrity constraint is a predicate over relations expressing a
constraint; by far the most used integrity constraint is the referential integrity
constraint. A referential integrity constraint involves two sets of attributes S1
and S2 in two relations, T1 and T2, such that one of the sets (say S1) is a key for
one of the relations (called the primary key). The other set is called a foreign
key if T2[S2] is a subset of T1[S1]. Referential integrity constraints are the glue
that holds the relations in a database together. It is therefore necessary to
specify, when talking about a relational database, which are the primary keys and
the 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 standard
data model for Object-Oriented databases. In ODL, classes are declared by
giving them an interface (using the keyword interface); each class is a collection
of 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 is
a set of properties (attributes or relationships) whose values are unique for each
object in the extent (composite keys are called compound in ODMG). The
extent is the name of the set of objects under the declaration. Obviously,
inheritance among classes is supported directly in the model, and declared using
the keyword extends. Values of attributes are typically literals (atomic or
complex) but can be oids. Values of relationships are always object names or a
collection applied to object names. In the ODMG model, only binary relationships
are explicitly represented, through a pair of inverse references (using the
inverse 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; they
include types like Date and Time. Also, the user can define structured literals as
needed (using the Struct constructs). Collection literals specify a collection of
objects or literals. Types of collections are: Set, Bag, List (homogeneous), Array
and Dictionary. Each collection has a group of built-in operators.
Finally, objects have object identifiers (oids) and a value (unlike literals, which
have 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; they
correspond 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) data
model is exemplified by the latest version of SQL, SQL-99 (Melton, 2003). It can
be seen as an attempt to capture as many as possible of the object-oriented
concepts introduced in the previous subsection and wrap them around a
relational shell. A more modest view of it regards the model as extending the base
of the relational model (instead of the model itself) by making it easier to add
more complex data types to serve as domain definitions. Here we will describe
the basics of the standard (Melton, 2003), since each commercial DBMS has its
own version of the model, with different names and different syntax.
The basic idea is to substitute domains by (possibly complex) types, called User
Defined Types (UDTs). The name comes from the fact that the model provides
constructors 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 and
structured types. Distinct types are based on a single built-in data type. Distinct
types are not compatible with any other type (including the one they are based
on). The following is an example of an UDT called age based on the built-in type
integer:
CREATE TYPE age AS INTEGER (CHECK age BETWEEN 0 and 100) FINAL;
FINAL refers to whether type can be extended with subtypes: distinct types
cannot, structured ones can. Optionally, operations and comparisons can be
defined for types. Structured types can have internal structure, with parts called
attributes. Attributes do not have to be built-in; they may be complex (SQL99
offers “built-in” structured types ARRAY and ROW), but cannot be of the type
being defined (i.e., recursion is not allowed). Structured types do not have
identity. 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 UNDER
another; (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 of
the type become attributes of the table. Typed tables also have inheritance
hierarchies, corresponding to the hierarchies of the types. Subtables cannot have
primary keys, but supertables can. They can also have UNIQUE, NOT NULL,
CHECK and integrity constraints. There is also a self-reference value created
automatically, unique for each row of the table. SQL99 provides REFERENCE
156 Badia
types, which give structured types an id. Maximal supertables must specify the
self-referencing column (it is inherited by subtables, which cannot specify such
a column on their own). References can be generated by system, by using some
built-in type, or by using some attributes of the type.
Semistructured data is assumed not to have a strict type, but to posses
irregular, partial organization (Abiteboul et al., 1999). Because, in addition, the
data may evolve rapidly, the schema for such data is usually large, dynamic, and
is not strictly respected. Data models have been proposed that try to adapt to
those characteristics. Several of them have in common that they can be thought
of as directed, labeled graphs (trees, in some cases) (Papakonstantinou et al.,
1995). In this model, nodes are objects, and edges point to other objects which
are components of the given object. However, this model, while very general,
gives very few constraints as to what the data looks like. In practice, some
information about the components of objects is usually available. Thus, in most
cases the term semistructured data is reserved for data that does have some
(loose) structure. XML (Bray et al., 1999) provides the tools to describe such
information, either through a DTD or an XML Schema (note, however, that XML
has additional properties over semistructured data — order, attributes — while
semistructured data does not assume the existence of any schema. Hence, both
terms are, strictly speaking, different).
Basically, in XML an object may have attributes and elements. Simple parts of
an object can be represented by attributes or elements, while complex parts are
represented by elements, since they in turn are also objects. Elements are
defined by a pair of matching start and end tags. Elements may have embedded
subelements, indicated by nested pairs of tags (empty elements are also
allowed). A root element may be declared which is not a subelement of any other
element. Subelements have associated information to indicate a cardinality
constraint, in the form of a pair of attributes minOccurs and maxOccurs: none
or several occurrences (a Kleene star, indicated by ‘*’ in DTDs) is represented
by setting minOccurs to 0 and maxOccurs to ‘’unbounded’’; none or one
occurrences (indicated by ‘?’ in DTDs) is represented by setting minOccurs to
0 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 represented
by 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 are
expressed as an equation attribute name = value within the starting tag of the
corresponding element; the names must be unique within an element. Attributes
can be mandatory (expressed with the keyword #REQUIRED) or optional
(expressed with the keyword #IMPLIED). Keywords ID and IDREF are used to
establish links among elements, denoting the pointed at and pointing elements in
the link, respectively. Atomic elements and attributes are simply of #PCDATA
or 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 of
what 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 components
of an object. An XML document is well-formed when it respects the general
XML syntax (nested, balanced tags), and is valid (with respect to a given XML
schema or DTD) if it respects the tag definitions of that XML schema or DTD.
DTDs do not distinguish between entity types and relationships; relationships are
implicitly expressed through the element-subelement connection. Because rela-
tionships are attached to objects, XML DTDs are much better at handling
hierarchical 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/end
tags), and enforces type checking and references. It classifies elements as
simple type (integers, strings) or complex type (regular expressions, like in
DTDs). For a complex type, it defines the structure. An XML schema also
introduces 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 complex
type T is declared by giving it a name, a path selector (that leads from the root
to T) and a field (to say which element(s) within T form the key). Note that a key
can be made up by several elements; also, several alternative keys can be
specified. Foreign keys are defined with a keyref keyword and a reference for
the key being denoted, using also a path and a field selector. Therefore, integrity
constraints 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 be
modeled with derived types. There are two ways to derive: by extension and by
restriction. In the second, types are derived by giving a base type and restricting
the properties (cardinalities, choices) of the elements.
Translations
We divide the translations according to the target data model, as this creates the
more salient differences. We first give an algorithm that uses the E-R model as
source, 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 relational

design, given in Figure 3. Applied to the E-R model of Figure 1, the algorithm
creates the tables of Figure 4 (keys are underlined, foreign keys in italics).
Intuitively, the algorithm maps every entity (including weak ones) to a table, and
every 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 model
are those generated by the key, then all the relations generated by the algorithm
are guaranteed to be in fourth normal form (Elmasri & Navathe, 2003). Even
when additional functional dependencies exist, they usually involve attributes of
a certain entity, and therefore normalization of the database can proceed on a
table-by-table basis. There are a few tricky cases, though, in which the E-R
model does not have enough information to guarantee normal form, usually
involving n-ary relationships (Camps-Pare, 2001).
If all attributes are considered required, then the above translation works
correctly. If attributes are considered optional, the above translation is still
correct but allows for the introduction of nulls in the database. When using SQL
to define the tables, required attributes should be considered non-nullable, and
optional attributes should be considered nullable. Unfortunately, without any
further 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 RA E; 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 RA E.
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).
optional), the only way to get rid of nulls is to break up every table into a set of
tables, each one containing the key of the entity and one of its attributes. This
way, entities with no value for a given attribute simply would have no entry in the
appropriate table, but no nulls would be produced. However, this approach
produces a heavily partitioned database, with most queries requiring a large
number of joins. Hence, the issue is usually ignored in the process.
The above algorithm admits some inlining, as follows: when a binary relationship
R exists between entities E1 and E2, and R is one-to-many or one-to-one, it is
possible to express R not by creating a new table, but by modifying the table
corresponding to the entity on the one side (if R is one-to-one, either entity will
do). Say this entity is E1; then the key of E2 is added to the schema of E1, together
with any attributes R may have. Note that if participation of E1 in the relationship
is not total, this will result in some nulls; hence, this procedure must be used only
when participation of E1 is total or nulls can be dealt with adequately. In the
database of our example, we could create, instead of tables Employee and
Works-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 a
subtype of entity type E2, a table must be created for each. However, there are
two 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. This
implies 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 tables
Employee(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 not
be necessary (would remain empty); but then, queries asking for all
employees would have no direct reference. Note also that if there were
overlap (although obviously not the case in this example), information
about employees could be duplicated.
160 Badia
2. Give as the schema of the superclass (E2) only those attributes that are
proper of E2 and in the subclass (E1) only those attributes that are proper
of the superclass. This implies that objects which are in subclass E2 will be
stored in two tables: in the table for E1, the inherited attributes will be taken
care of; in the table for E2, we will put only those attributes that are proper
of E2. Applied to the E-R model of Figure 1, this approach creates tables
Employee(ssn,name), Hourly-Employee(ssn,hourly-rate),
Salaried-Employee(ssn,salary). Note that if the two subclasses
are a cover, the table for the superclass is still needed. Note also that if the
subclasses 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/subclass
relationship (overlap, cover). Clearly, queries that refer to the whole superclass
frequently will be more efficient over the first option, while queries that refer
to specific classes more frequently will be more efficient over the second
option.
As for the translation from UML, the basis is exactly the same: each class is
translated into a table, and each association is also translated into a table. Note
that all associations in UML are binary, and hence no rule is needed to handle
other kinds of associations. Note also that when associations have attributes, or
have an arity greater than two, they get promoted to classes (the so-called
association classes); in this case, the class and the associated associations should
be translated as one since they represent a single relationship. As an example,
the class Review in Figure 2 represents a ternary relationship, and is connected
by three binary associations to classes Employee, Department and Project. A
single table should be created, containing the attributes of class Review and
representing the associations by adding the primary keys of Employee, Depart-
ment and Project as foreign keys in the new class. Otherwise (if we treated
association 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 to
compute. Finally, in those cases in which attributes have cardinality constraints,
we still follow the same procedure as for the E-R model, simply identifying
attributes as multivalued if their max cardinality is greater than 1 (attributes
whose min cardinality is 0 are considered nullable in the database, but must still
be present in the table).
From E-R and UML to Object-Oriented
Translations from UML to Object-Oriented databases are straightforward, since

both are based on the same underlying model. Thus, we start by explaining the
translation from UML into ODL. Intuitively, each class in UML will become a
class in ODL, and each association will be captured as a relationship attribute
with an inverse (recall that all associations in UML are binary). Complex
attributes become structured attributes, and multivalued attributes can be
captured with a SET constructor. Weak entities, although not recognized in
UML, should be identified to make them a complex attribute of the class they
depend upon. The reason is that, since composition is not recognized in ODL, this
is the best way to keep the semantics of weak entities (their life dependency and
lack of key). Association classes can be treated as regular classes, since ODL
cannot deal directly with relationships with attributes or with arities greater than
two. Inheritance, of course, is modeled directly both in UML and ODL. The
procedure can be described in Figure 5.
Note that this procedure does not involve object identifiers (oids) at all; it is
expected that any objects created in the database will get an oid because that is
part of the object-oriented model. Applied to the E-R model of Figure 1, this
approach creates the classes shown in Figure 6. Note that some arbitrary data
types were chosen to complete the declaration. Note also that key declarations
are optional in ODL, but that regardless of key declaration every object of the
class 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
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;}
When starting with an E-R diagram, all of the above applies. The most important
difference is that there will be n-ary relationships. To translate an n-ary
relationship R involving entities E1,…, En, one must do the following: R must be
reified, just like a binary relationship with attributes. Thus, a class R’ must be
created, with attributes all attributes of R, and then n binary relations between
R’ and each Ei’ must be established. The final result is the same as the procedure
shown above, since the process of reification is basically the same transforma-
tion that takes place in UML when an association class is created to represent
n-ary relations (n > 2).
To conclude, we point out that, contrary to popular belief, the object-oriented

data model does not handle optional attributes any better than the relational
model. Each class declaration specifies a series of attributes that every object
in the class must have; hence, optional attributes in the conceptual model create
undefined 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 respect
to the (purely) relational data model. These degrees of freedom, in turn, raise
different possibilities about the translation from conceptual models. Unfortu-
nately, almost no research has been done on possible different translations, their
weaknesses and strengths, and their comparison. Here, we outline two different
approaches 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 relational
database, 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 internal
ROW or ARRAY constructor, at least if an upper bound in the number of
values 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 one
table.
Because this is almost the same translation as the purely relational, we call this
approach conservative. There is also another possible approach, which is more
extreme, in that it uses the full-blown potential of the object-relational model. In
the extreme approach, we treat the data model as one of objects represented in
tables (i.e., in tabular form). Hence, we not only map subtypes into subtables and
multivalued attributes into complex attributes, we also map weak entities into
complex subelements of the strong entity. That is, given weak entity E1 related
by 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 of
the type created for E1.
1-M relationships can also be mapped by embedding the entities in the M side into
the 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 a
complex type corresponding to the entity. This table is then embedded as a
subtable (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 may
be involved in other relationships; these are handled by using REF types. Binary
relationships without attributes can be implemented through REFs (or sets of
REFs), 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 indirectly
through references. Since this creates differences in how the relations are
physically stored on disk, and therefore on access patterns, which option to use
depends on the expected workload (queries), size and performance requirements
of 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 may
have several Employees, each Employee belongs to a single Department). One
option is to create the complex type for Department using the complex type for
Employee as a (multivalued, complex) element. In this approach, there is only
one table (Department), and queries asking about Department information
(including Employees per Department) may run somewhat faster, since
Departments are explicitly joined to Employees. However, queries about Em-
ployees may be somewhat slower (of course, the final performance depends on
many other factors, like clustering, indices, etc.). This approach is somewhat
biased towards Department (considered a “primary” type), in detriment of
Employee (considered a “secondary” type). Moreover, if Employee is con-
nected by another relationship to another entity, this second relationship has to
be handled by reference — unless it is also 1-M. In our example, Employee is
involved in a 1-M relationship with Dependant. Then it is possible to inline the
dependant type within the Employee type, which in turn is within the Depart-
ment type. Direct access to dependants may be slow and complex in this
schema, though. However, Employee is also involved in a many-to-many-to-
many relationship with Department and Project. Then it is not possible to
inline this relationship since this would cause redundancy (a project would be
repeated on each employee that reviewed it). In this case, using a separate
Review table with references to Employees may be a better choice. The
problem applies to any relationship that is many-to-many, which cannot be
embedded without causing redundancy.
In contrast, the original option is to create a complex type for Department, one
for Employee, a table for each, and handle the relationship either with a separate
table (as in the relational model), or by using references (sets of references to
Employee on each Department, and a reference to Department on each
Employee). This approach is more neutral, in that both Departments and
Employees are considered “top level” tables. Further relationships with other
tables, like Project, are easier this way. On the other hand, every join between
Departments and Employees needs support from separate indices and/or
algorithms. Note that both approaches would create subtables Hourly-
Employee(hourly-rate) and Salaried-Employee(salary), under table
Employee. A possible heuristic to decide between the conservative and extreme
approaches is this: the extreme approach works well for weak entity types, and
for 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 the
conservative approach.
Finally, we note that both approaches can handle required attributes but have
problems with optional attributes. Since both approaches ultimately make object
types 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 is
decidedly a hierarchical model while E-R is more of a flat model (all entities are
at the same level) (Mani et al., 2001; Lee et al., 2003; Conrad et al., 2000; Dos
Santos et al., 2001). This presents two options as to how to transform an E-R
model into XML: to somehow transform the E-R model to fit the hierarchical
nature 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 the
previous subsection. In the case of XML, the first option may be taken to an
extreme by choosing some entity type to become the root of the XML model, and
embedding 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 be
to identify some entity types in the E-R model which are somehow “more
important” and use them as first elements under an artificial root; this is the
approach used in Bird et al. (2000). The second approach is basically to use the
E-R to relational translation, and express the resulting (flat) database in XML
Schema. 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. Assume
that, when applied to the E-R model of Figure 1, this method chooses Employee
as the root; this results in the DTD of Figure 7.
Note that this approach is inherently biased. Also, many-to-many relationships
are described as one-to-many, since this is the only type of relation compatible
with the hierarchical organization. Moreover, attributes in relationships are lost,
166 Badia
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)>
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 be
expressed in the algorithm of Figure 8. To start the algorithm, we declare one
complex element D to be the root element of the schema; D represents the whole
database. Then, one element is created per entity type and one per relationship;
links are established through keys and foreign keys. Inheritance is modeled with
derived 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 XML
Schema. If an attribute is optional but not multivalued, we use ‘?’; if an attribute
is optional and multivalued, we use ‘*’. Hence, XML is the only data model that
can adequately deal with optional attributes.
The decision to consider attributes as subelements instead of XML attributes is
based on two factors: it allows for more parallelism with the relational model, and
hence facilitates integration of the two; and it allows saving the XML attributes
for 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 consider
a hierarchical organization, by making the entity on the many side a subelement
of the entity on the 1 side. However, many-to-many associations still require two
separate elements and the use of primary keys and foreign keys in XML Schema
to be adequately modeled.
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 A 1,…,A n
Create a new element ER.
A dd each attribute A i 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,…,A n
Create a new element ER.
A dd each attribute A i 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.
Conclusions and Further Research
In this chapter, we have surveyed transformations between conceptual models

and data models. These transformations are vital in the design and development
of Information Systems. While some of them are well understood, new data
models (like object-relational, and XML) create new challenges in developing
satisfactory transformations.
Clearly, the most important difference among transformations comes from
differences among data models, in particular the importance given to objects and
relationships: in the object-based paradigm objects (actually, classes) come first,
and only binary relations (as special attributes of objects) are considered. These
models have trouble handling n-ary relations (n > 2) and relations with attributes.
XML, with its strong hierarchical view, also has problems at handling certain
types of relationships. On the other hand, the relational data model transforms
168 Badia
everything into relations, and hence objects are diluted in that the information
about 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 be
best described using both constructs. Another conclusion is that all data models,
except XML, fail to accommodate irregular data. In particular, all models except
XML cannot deal with optional attributes without resorting to nulls or other
special values.
The most important conclusion of this overview is that there is a severe lack of
research in transformations for the object-relational and semistructured data
models, as can be seen from the fact that several translations, with different
advantages and drawbacks, are possible, and none is considered the right
translation. The object-relational data model offers several possibilities for all but
the most trivial conceptual models; the trade-offs among these options are not
well understood. Hopefully, new research will shed light into these issues in the
near future.
References
Abiteboul, S., Buneman, P. & Suciu, D. (1999). Data on the Web: From
Relations to Semistructured Data and XML. Morgan Kaufmann.
Bird, L., Goodchild, A. & Halpin, T. (2000). Object Role Modeling and XML
Schema. Proceedings of E-R 2000, Springer-Verlag (pp. 309-322).
Bodart, F., Patel, A., Sim, M. & Weber, R. (2001). Should Optional Properties
Be 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 Markup
Language (XML) 1.0.W3C Recommendation (2 nd edition). Retrieved
from the WWW: http://www.w3.org/TR/REC-xml-20001006
Camps-Pare, R. (2002). From Ternary Relationship to Relational Tables: A
Case Against Common Beliefs. SIGMOD Record, 31(2), 46-49.
Cattell et al. (Eds.). (2000). The Object Data Standard: ODMG 3.0. Morgan
Kauffman.
Chen, P. (1976). The Entity-Relationship Model-Toward a Unified View of
Data. ACM Transactions on Database Systems, 1(1), 9-36.
Conrad, R., Scheffner, D. and Freytag, J. C. (2000). XML Conceptual Modeling
Using UML. Proceedings of ER 2000, Springer-Verlag, (pp. 558-571).
Date, C. (2004). An Introduction to Database Systems (8 th 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 between
XML and Relations Models (Invited Paper). In B. Omelayenko and M.
Klein (Eds.), Knowledge Transformation for the Semantic Web. IOS
Press.
Mani, M., Lee, D. & Muntz, R. (2001). Semantic Data Modeling Using XML
Schemas. 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 Categories
and Their Application in Object-Oriented Analysis. IEEE Transactions on
Knowledge and Data Engineering, 11(5), 779-797.
Papakonstantinou, Y., Garcia-Molina, H. & Widom, J. (1995). Object Exchange
Across Heterogeneous Information Sources. Proceedings of the 11 th
International Conference on Data Engineering, IEEE Computer Soci-
ety, (pp. 251-260).
Rumbaugh, J., Jacobson, I. & Booch, G. (1999). The Unified Modeling
Language Reference Manual. New York: Addison-Wesley.
Sahuguet, A. (2001). Everything You Ever Wanted to Know About DTDs, But
Were Afraid to Ask. Extended Abstract. Third International Workshop
WebDB, LNCS, Springer, (pp. 171-183).
dos Santos Mello, R. & Heuser, C. A. (2001). Structure-Based Conversion of
a 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, and
hence does not have the ability to capture multivalued attributes (or many-
relationships). Indeed, without such a constructor the standard does not
even 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 we

consider it available here.
An Algorithm for Transforming XML Documents Schema 171
Chapter VIII
An Algorithm for
Transforming XML
Documents Schema
into Relational
Database 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 transact
business over the Internet. People like to do their transactions from their
homes to save time and money. For example, customers like to pay their
utility bills and other banking transactions from their homes through the
Internet. Most companies, including banks, maintain their records using
relational database technology. But the traditional relational database
technology is unable to provide all these new facilities to the customers. To
make the traditional relational database technology cope with the Web and
XML 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, we

present a new and simpler algorithm for this purpose. This algorithm
transforms 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 structures
that 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 vague
schema (Buneman, 1997; Suciu, 1999; Buneman, 1997). Beside the Web, there
are 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 on
the Web (W3C, 2003). This language also provides a hierarchical format for the
data exchange over the Web with structure (St. Laurent, 1999; Bray, Paoli,
Sperberg-McQueen, & Maler, 2002). Information in an XML document is
represented as nested element structures, which start with a root element. An
element can have an attribute or a sub-element (for further details about XML
see W3C (2003) and Bray et al. (2002)). An XML document has an optional part,
which is called Document Type Declaration/Description (DTD). A DTD of
an 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 noticeable
differences between a RDB schema and an XML document schema (DTD). We
give a complete comparison between them in Table 1. The basic difference
between them is that a DTD represents a hierarchical structure whereas a RDB
schema represents a relational (tabular) structure. We can consider XML
documents schema analogous to the classical hierarchical data model.
XML is considered as the best tool for representing and exchanging information
on the Web (St. Laurent, 1999; Bray, Paoli, Sperberg-McQueen & Maler, 2002).
The language allows users to define and also display data on the Web. These
features make XML powerful and different from Hypertext Markup Language
(HTML) (Suciu, 1999; Comer, 2000). XML enables the user to define his own
structures using the syntax of the elements in a DTD. A DTD describes the
structure of information in an XML document in a hierarchical way (Bray, Paoli,
Sperberg-McQueen & Maler, 2002). The structure of a DTD consists of
elements 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 types
of data value can be assigned to attributes, i.e., string-type or entity. The data
value 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 the
element. As it has been mentioned in Table 1, a DTD does not support the
concept of the composite ID (or key). An attribute can be referenced in another
element through a field called IDREF, and it is a type-less attribute. The concept
of 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 they
can perform their transactions from their homes through the Internet. For these
financial organizations to provide their customers with this facility, it is necessary
and beneficial that the databases (which are mostly RDBs) should be presented
and processed in the XML format. We therefore need a technique that will
process and transform an RDB and queries into an XML format and vice versa.
This technique (or transformation) is essential because most of the commercially
available database management systems (DBMSs) are relational DBMSs.
This transformation will integrate and handle heterogeneous RDBs in the same
manner. Researchers agree that the currently available RDB technology inde-
pendently is not adequate to achieve this objective of using them on the Web
without such transformation (Shanmugasundaram et al., 1999). Recently, some
researchers 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
XML document and its DTD can be stored in the
as two different entities, and they are stored in
same file or in two different files.
two different files.
It is optional for a XML document especially for
It is mandatory for a database.
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 Since it is optional, it can, therefore, be defined
creating its instances (or tuples) 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 DTD
as a schema of the XML document, and they have used the tree data structure
during 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, there
are many syntax options that are available for writing DTDs. Most of the existing
transformation algorithms (from DTD into RDB schema) are unable to handle
DTDs written in different ways (Shanmugasundaram et al., 1999; Men-Hin &
Fu, 2001). In this chapter, we propose a different approach for transforming any
DTD of an XML document into relational database schema. This approach can
handle DTDs written in different ways and transform them into relational
database schema in a simple and elegant way.
The remainder of this chapter is organized as follows. We describe and analyze
the existing approaches for transforming a DTD of an XML document into a
relational database schema. We then present our proposed approach for
transforming a DTD into a relational database schema, and demonstrate the
proposed approach in a case study. Finally, we give our concluding remarks and
future direction of this work.
Background Related Work

Investigators have produced many different techniques for transforming DTDs
into relational database schemas (Eisenberg & Melton, 2002; Yan, 2001;
Chidlovskii, 2001; Marni & Lee, 2002; Men-Hin & Fu, 2001; Shanmugasundaram
et al., 1999). There are three main issues that need to be handled during this
transformation. These issues are: (i) the complexity of the DTD element
specifications, (ii) the resolution of the conflict between arbitrary nesting in a
DTD and relational schema, (iii) set-valued attributes and recursion
(Shanmugasundaram et al., 1999). In the following paragraphs, we give a brief
description of the works of these investigators and give, in Table 5 (at the end
of this chapter), a comparison of these transformation approaches and our
proposed 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 (Shanmugasundaram
et 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 Step
2 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 works

in six steps, and they are briefly given below:
• Step 1: Simplifying the DTD: This step simplifies DTDs of XML
documents using the rules similar to regular expression rules. The informa-
tion that is useful in constructing schema prototype trees is preserved in the
DTDs. The value types (e.g., #IMPLIED, #FIXED, etc.) for the character
data (CDATA) are removed from the DTDs.
• Step 2: Determining the Root Node: In this step, roots of the prototype
trees are determined from the simplified DTDs using the set of rules that
are suggested for this purpose.
• Step 3: Constructing Schema Prototype Trees: The prototype trees are
constructed from the roots that are determined in the previous step using
a set of rules.
• Step 4: Generating a Relational Schema Prototype: This step realizes
a prototype relational database schema from the prototype tree using the
following rules:
(i) Regard all the necessary attributes and elements in the simplified DTD
as the attributes that are treated in the entity- relationship (ER) Model.
(ii) Inline all the necessary descendants of the schema prototype tree
starting from the root. The necessary descendants refer to all the leaf
nodes in the schema prototype tree, and the nodes marked with a “#” if
they exist.
• Step 5: Discovering Functional Dependencies (FDs) and Candidate
Keys: In this step the traditional relational database design techniques are
applied in order to produce suitable relational schemas. These design
techniques reduce the redundancy and inconsistency in a relational data-
base schema, and discover the functional dependencies and the candidate
keys by analyzing the newly constructed relational database schema.
• Step 6: Normalizing the Relational Schema Prototypes: This step
applies the normalization rules on the relational database schema, after
determining the FDs and candidate keys of a relational database schema in
the previous step.
In the first algorithm of Men-Hin and Fu, functional dependencies are found in
Step 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 finding
functional dependencies.
Both of these algorithms-the first and the modified algorithms- use the tree data
structure in their transformation processes (or algorithms). The use of this data
structure affects the performance of the transformation process because
creating and maintaining the tree structure are costly procedures. Also, these
two 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 informal
proposal for a bi-directional transformation between an XML document and a
RDB. This transformation can do a complete or a partial transformation at
schema level as well as tuple level (or row level). The partial transformation may
however miss some semantics. This draft for the bi-directional transformations
also suggests a transformation of the data types. The authors did not give any
proper formal algorithm for these transformations. It is, therefore, difficult to
comment about the real effectiveness of these transformations.
Williams et al. have proposed 18 steps for transforming DTD into a relational
database schema and 11 steps for the reverse transformation (Williams et al.,
2000). Both of these transformations do not use the tree data structure, but some
steps in both of these transformations are unclear. For example, in Step 9 and
Step 13 of the transformation of a DTD into a relational database schema, data
types are assigned to attributes of a DTD without any explanation and justifica-
tion. This type of vagueness in the transformation processes makes them difficult
to understand and to draw any conclusion about their correctness and accuracy.
Marni and Lee (2002) have proposed a process for transforming a DTD into a
relational database schema using a regular tree grammar. The use of the regular
tree grammar is helpful in maintaining semantics constraints in the transforma-
tion process. The theory of regular tree grammars provides a useful formal
framework for understanding various aspects of XML schema languages. The
two normal forms (NF1 and NF2) are used for the representation of regular tree
grammars. NF1 is used in the XML document validation process, and to check
whether a given XML schema satisfies the structural constraints imposed by the
schema languages.
XML Schema (or DTD) provides several unique data modeling features such as
union type “+”, which does not exist in the traditional database models, such as
the relational database model. In Marni and Lee (2002), NF2 is used for
representing the basic of the conversion definition of the two schema languages,
that is, a schema that supports union types (e.g., XML-Schema Language), and
a 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 XML
schema into relational database schema. The entities and relationships, which
form the basic items of data modeling, are represented as elements and attributes
of a DTD.
The process of mapping XML schema (or DTD) into RDB schema has several
issues, and they have been pointed out (Marni & Lee, 2002). One of the most
important among them is the semantic constraint which exists in the XML model.
Since relational database schema cannot express these constraints in the XML
schema languages, a useful and meaningful subset of those constraints should
therefore be found in the mapping process. This process of finding the subset
needs simplification of an XML schema. The concept of inlining technique is
used for generating an efficient relational schema (Marni & Lee, 2002).
However, the inline technique that is presented in this work generates a huge
number of relations. In addition, this work does not present any proposal for
assigning data types to attributes of tables after or during the transformation
process. The transformation process of an XML DTD to relational data schema
is the mapping of each element in the DTD to a relation, and it maps the attributes
of 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 ER
model. The attributes in an ER model are often represented as elements in a
DTD. 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, lastname

and 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 lastname
were defined as attributes, then they could not be nested under name because
DTD attributes cannot have a nested structure. A direct mapping of elements to
relations therefore leads to an excessive fragmentation.
Proposed Transformation Approach

Our proposed transformation approach (or process) works in two steps. The first
step takes a DTD written in any form using the syntax available for writing DTDs
and transforms it into a standard form that is devised keeping in view the syntax
of a relational database schema. The second step of our proposed approach
takes a DTD in the standard form and transforms it into a relational database
schema.
In our proposed approach, we do not include the processes of finding functional
dependencies (FDs), assigning data types to attributes of relations after the
transformation (note that DTD supports only one data type, i.e., PCDATA), and
normalization of the relation schema. The reason for this is that these three
processes are database design techniques and they depend on the perception of
a 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 transformation
process, i.e., DTD in relational schema. In other words, these three processes
are difficult to automate. Consequently, we have separated the processes that
should be done manually from the processes that can be automated. This
separation makes our algorithm simpler and has helped in our objective to
transform any DTD into a relational schema. In this section, we propose only
those processes of the transformation that can be automated.
The proposed approach consists of two algorithms (or steps): (i) Pre-Processing
Algorithm and (ii) Transformation Algorithm. Figure 1 shows a general view of
our proposed transformation process. The first algorithm (i.e., Pre-Processing
Algorithm) transforms any DTD that is written in any form (referred to as
DTD 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 simple
uniform 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
DTD a DTD s RDB_Schema

Pre-Processing Transforming
Algorithm Algorithm
Pre-Processing Algorithm
As it has been mentioned earlier, there is no standard and fixed method for
writing a DTD of an XML document. In other words, different users can write
DTDs in different ways using the options provided by the syntax of DTD. The
main objective of the Pre-processing is to enable the overall transformation
process to handle DTDs that are written in different ways. Hence, the main
function of this algorithm is to transform DTDs written in different forms into a
uniform and standard form. The output of this algorithm is the standard DTD
denoted 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 (or
syntax). The main objectives of the standard DTD are listed below:
(i) to provide input to Transformation Algorithm in a uniform and standard
form; and
(ii) to enable the overall transformation process handle DTDs written in
different ways.
The proposed syntax/format of the standard DTD is given in Figure 2. In the

figure, 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 a
standard DTD and the number of repetitions depends on the corresponding XML
document structure. For example, in the standard Library DTD given in Figure
3, 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 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 >
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
(DTDa) and transforms it into the standard DTD (DTD s).
In the Global Schema Extraction Algorithm (Men-Hin & Fu, 2001), elements and
attributes are treated equally and represented as separate nodes in the prototype
tree. The same approach is used in the DTD-splitting Schema Extraction
Algorithm (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
Figure 4. Pre-processing algorithm (continued)
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;
transforms all sub-elements of a main element into attributes of that main

element.
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.
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
The outer loop deals with elements of the DTDs and transforms them into
corresponding tables/relations. The inner loop transforms every attribute of the
element into the attributes of the corresponding relation. In Step (iii) of the
algorithm (Figure 5), it transforms ID and IDREF attributes of an element into
the primary key and foreign key of the relation, respectively. Note that since the
syntax of DTD does not support the concepts of composite key, our proposed
transformation process, therefore, does not support this concept.
Case Study: Library DTD

In this section, we take a DTD that is written in a general form and demonstrate
the workings of our proposed transformation process. For this purpose, we take
a Library DTDa 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 and
produces 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 DTDa, 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
DTD s, then Transformation Algorithm is applied to DTDs. This algorithm
transforms the Library DTDs (Figure 3) into a Library RDB-Schema given in
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)> ] >
Table 2. Trace of the pre-processing algorithm for Library DTDa

Root_element n i Main_element m j
sub-elements ID IDREF Lno
4 1 Books 4 1 title N N 1
Library
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 algorithm

Schema_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
Regular
Global DTD-splitting Williams
Basic Inlining SI&HI * Tree Our Approach
Extracting Extracting et al.
Grammars
no such
Data
Structure
relational regular tree abstract data
graph graph tree tree grammars
Used structure structure is
used
ensures that
preserves some some rules
creates a each support pre-pressing
eliminates operators to are
Operators relation for element is XML- algorithm
operators preserve some specified to
Handling every element represented schema processes
from DTD sub-elements handle
in the DTD only once (not DTD) them
occurrences them
in a relation
number of
actual data simple, direct
the attributes of the
handles fields are preserves maintains mapping &
common schema is less
Advantage fragmentation available in entities and semantics maintains the
elements than the
Problem ** relational definitions constrains semantics of
are shared algorithms
schema RDB
basic inlining
some rules
large of the
number of
number of mapping
possible works with a complex data types
large no. of joins in are vague
✦ relations it
minimal limited number mapping assigning is
Disadvs. mapping such as
dependencies of elements and process with human
creates for assigning
is attributes intervention
particular of data
exponential
elements types to
attributes
didn’t didn’t high

Prfce✦✦ low low low low
mention mention (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 primary
keys and foreign keys, respectively. Note that all attributes of the relational
database schema given in Figure 7 are typeless attributes and they can be given
data types through user intervention. This issue and some other issues related to
this work are identified in the section on Future Direction.
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
A Few Words About Automation
We have automated the proposed transformation process by implementing both

its modules, i.e., Pre-Processing Algorithm and Transformation Algorithm. We
have used the programming language Delphi Version 7 as the implementation
language. The first module parses the input DTD, checks its syntax and finds out
syntax errors (if any), and transforms the input DTD into the standard form. The
second module transforms the standard DTD in a relational schema.
Concluding Remarks and Future

Directions
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 different
syntax options, into a relational database schema. This transformation process
consists of two algorithms: (i) Pre-Processing Algorithms, and (ii) Transforma-
tion Algorithm. We have defined: (a) the format of a standard DTD that is closer
to a relational database schema, (b) Pre-Processing Algorithm that transforms
any DTD (that is written in any form) of an XML document into this standard
format, and (c) the Transformation Algorithm that transforms the standard DTD
of the original DTD into a relational database schema. We have demonstrated
the complete working of our proposed algorithm using a case study. Our
proposed approach is simpler, formal and different from the existing approaches
that have been suggested by Shanmugasundaram et al. (1999), and others (Men-
Hin & Fu, 2001; Williams et al., 2000; Eisenberg & Melton, 2001; Eisenberg &
Melton, 2002). Most of these approaches use the tree data structure, which
requires costly operations in creating and maintaining it. Our approach does not
use a tree data structure and this makes it simpler and more efficient than those
approaches that use the tree data structure. We have also given a brief
comparative study of our proposed approach and some existing approaches in
Table 5.
Future Directions
We are actively working on the complete and comprehensive implementation of

the proposed transformation algorithm. We have briefly mentioned some of the
results of our initial implementation in this chapter. After a complete implemen-
tation of our proposed algorithm, we will analyze the results of our transformation
process, and compare them with the results of others. We are also working on
making our proposed algorithm to be bi-directional so that our new algorithm will
transform relational databases schema into a DTD as well.
We also suggest that investigation should also focus on issues that are related to
the bi-directional transformation (i.e., XML documents schema into RDB
Schema, and vice versa). These issues are:
(i) Handling of IDREFS: It can be an interesting study to translate the concept
of 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 character
data type and RDB schema supports multiple data types. Upon the
completion of the transformation process, we get typeless RDB schema. It
therefore needs further study on when and how data types should be
assigned 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: Morgan
Kaufmann.
Abiteboul, S. & Vianu, V. (1997). Querying the Web. Proceedings of the
ICDT.
Bray, T., Paoli, J., Sperberg-McQueen, C. M. & Maler, E. (2002). Extensible

Markup 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: Addison
Wesley.
Buneman, P. (1997). Semi structured data. Proceedings ACM Symposium on
Principles of Database Systems, (pp. 117-121).
Chidlovskii, B. (2001). Schema Extraction from XML Data: A Grammatical
Inference 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. ACM
SIGMOD Record, 31(2),101-108.
Eisenberg, A. & Melton, J. (2001). SQL/XML and the SQL Information Group
of 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 Theory
Regular Tree Grammars. Proceedings of the 28th VLDB Conference,
Hong Kong.
Men-Hin, Y. & Fu, A. (2001). From XML to Relational Database. Proceedings
of the Eighth International Workshop on Knowledge Representation
meets Databases (KRDB2001), Italy.
Shanmugasundaram J., Tufte, K., Zhang, C., DeWit, D. & Naughton, J. (1999).
Relational Database for Querying XML Documents: Limitations and
Opportunities. Proceedings of the 25 th 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 ACM
SIGMOD (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, Chinese
University of Hong Kong, Dept. of Computer Science.
190 Ma
Chapter IX
Imprecise and
Uncertain Engineering
Information Modeling
in Databases:
Models and
Formal Transformations
Z. M. Ma, Université de Sherbrooke, Canada
Abstract
Computer-based information systems have become the nerve center of

current manufacturing systems. Engineering information modeling in
databases is thus essential. However, information imprecision and
uncertainty extensively arise in engineering design and manufacturing. So
contemporary engineering applications have put a requirement on imprecise
and uncertain information modeling. Viewed from database systems,
engineering information modeling can be identified at two levels: conceptual
data modeling and logical database modeling and correspondingly we
have conceptual data models and logical database models, respectively. In
this chapter, we firstly investigate information imprecision and uncertainty
Imprecise and Uncertain Engineering Information Modeling 191
in engineering applications. Then EXPRESS-G, which is a graphical

modeling tool of EXPRESS for conceptual data modeling of engineering
information, and nested relational databases are extended based on
possibility distribution theory, respectively, in order to model imprecise
and uncertain engineering information. The formal methods to mapping
fuzzy EXPRESS-G schema to fuzzy nested relational schema are developed.
Introduction
Nowadays computer-based information systems have become the nerve center
of current manufacturing systems. Engineering information modeling in data-
bases is thus essential. From the point of view of database systems, engineering
information modeling can be identified at two levels: conceptual data modeling
and logical database modeling. Correspondingly, we have conceptual data
models and logical database models for engineering information modeling,
respectively. Product data models, for example, can be viewed as a class of
conceptual data models that take into account the needs of engineering data
(Shaw, Bloor & Pennington, 1989). Much attention has been directed at
conceptual data modeling of engineering information because conceptual data
models can capture and represent rich and complex semantics in engineering
applications 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 for
the exchange of information. STEP provides a means to describe a product
model throughout its life cycle and to exchange data between different units.
STEP consists of four major categories: description methods, implementation
methods, 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 schema
language, can model product design, manufacturing, and production data and
EXPRESS model hereby becomes a major one of the conceptual data models for
engineering information modeling (Eastman & Fereshetian, 1994). Note that,
however, not being the same as ER/EER and IDEF1X, EXPRESS is not a
graphical schema language. In order to construct an EXPRESS data model at a
higher abstract level, EXPRESS-G is introduced as the graphical representation
of EXPRESS. Here EXPRESS-G can only express a subset of the full language
of EXPRESS. In addition to EXPRESS-G, it is also suggested in STEP that
IDEF1X or ER/EER can be used as one of the optional languages for EXPRESS
data 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 such
relational databases, nested relational databases, and object-oriented databases
can be used. Also some hybrid logical database models (e.g., object-relational
databases) or some special databases based on these database models (active
databases, deductive databases, and constraint databases) are very useful for
this purpose.
It should be noticed, however, that information is not always crisp in real
applications. Imperfect Information exists extensively in engineering applica-
tions. Imprecision is most notable in the early phase of the design process and
has been defined as the choice between several design alternatives. In addition
to product design, imprecise and uncertain information can be found in other
activities related to engineering. Concerning the representation of imprecision
and uncertainty, attempts have been made to address the issue of imprecision and
inconsistency in design by employing intervals (Kim et al., 1995). Other
approaches to representing imprecision in design include using utility theory,
implicit representations using optimization methods, matrix methods such as
Quality Function Deployment, probability methods, and necessity methods. An
extensive review of these approaches was provided in Antonsoon and Otto
(1995). All of these methods have had limited success in solving design problems
with 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, many
traditional database models have been extended. Being the most common
database model, the relational model has been extended to handle null values,
fuzzy values, partial values, intervals, and probabilistic values. It should be noted
that it is very difficult for a relational data model based on a flat relational table
to 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 (Yazici
et al., 1999). Also some attention has been paid to information uncertainty and
imprecision 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). But
EXPRESS has no the capacity of modeling imprecise and uncertain information,
although imprecise and uncertain information exists extensively in engineering
applications.
A classical database is generally created by first developing a high-level
conceptual data model and then mapping this conceptual model into an actual
implementation. The ER model, for example, is extensively used for the

conceptual design of relational databases (Teorey, Yang & Fry, 1986). Similarly,
engineering information modeling generally starts from conceptual data models
and then the developed conceptual data models are mapped into logical database
models. But less research has been done in developing design methodologies for
implementing fuzzy databases, although some fuzzy conceptual data models and
logical database models have been developed. It is especially true for fuzzy
engineering information modeling in databases. Extending EXPRESS-G to
model fuzzy information in a product data model was initially presented by Ma
et al. (2000), where some main concepts and graphical representations were
given. Modeling imprecise information, however, was not considered (Ma et al.,
2000). In particular, the logical database model for product data with imprecise
and uncertain information and its design methodology were not provided.
In this chapter, we concentrate on a fuzzy nested relational database model and
fuzzy EXPRESS-G model. After introducing the basic knowledge on fuzzy set
and possibility distribution theories, EXPRESS-G, and nested relational data-
bases, we extend EXPRESS-G and nested relational databases using possibility
distribution theory, respectively, so that fuzzy engineering information can be
modeled at two levels: conceptual data model and logical database model. Based
on the investigation that nested relational databases can support an EXPRESS
model, we develop the formal methods to mapping from fuzzy EXPRESS-G to
fuzzy nested relational databases.
The remainder of the chapter is organized as follows: The basic knowledge about
possibility distribution theory, EXPRESS-G, and nested relational databases are
given. Based on possibility distribution theory, EXPRESS-G and nested relational
databases are extended. The formal methods to mapping fuzzy EXPRESS-G
schema to fuzzy nested relational schema are developed. The chapter then
concludes.
Basic Knowledge
Information Imprecision, Uncertainty and Possibility

Distribution Theory
Inconsistency, imprecision, vagueness, uncertainty, and ambiguity are five basic

kinds of imperfect information in database systems (Bosc & Prade, 1993; Klir
& Folger, 1988). Intuitively, imprecision and vagueness are relevant to the
content 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 to
choose 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, ai2, ..., aim] or
[ai1-ai2] for the discrete and continuous universe of discourse, respectively,
meaning that exactly one of the values is the true value for the single-valued
attribute, or at least one of the values is the true value for the multivalued
attribute. Imprecise information hereby has two interpretations: disjunctive
information and conjunctive information. In addition to range values, there exists
one 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, and
it means that we can apportion some, but not all, of our belief to a given value or
a group of values. For example, the sentence, “I am 95 percent sure that Tom
is 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 with
respect to the same piece of information. For example, that it is almost sure that
John is very young involves information uncertainty and vagueness simulta-
neously. Imprecision, uncertainty, and vagueness are three major types of
imperfect information. Vagueness and uncertainty can be modeled with possi-
bility theory (Zadeh, 1978). Therefore, we mainly concentrate on fuzzy extension
of 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 a
universe of discourse, then a fuzzy value on U is characterized by a fuzzy set F
in 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 set
F. Thus the fuzzy set F is described as follows:
F = {µ (u1)/u1, µ (u2)/u2, ..., µ (un)/un}
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 is
described by a possibility distribution πX (Prade & Testemale, 1984; Zadeh,
1978).
πX = {πX (u1)/u1, πX (u2)/u2, ..., πX (un)/un}
Here, for each ui ∈ U, πX (ui) denotes the possibility that X takes value ui. 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 graphical
symbols to form a diagram (Eastman & Fereshetian, 1994; Shaw, Bloor &
Pennington, 1989). Note that it can only represent a subset of the full language
of EXPRESS. EXPESS-G provides support for the notions of entity, type,
relationship, cardinality, and schema. The functions, procedures, and rules in
EXPRESS language are not supported by EXPRESS-G.
EXPRESS-G has three basic kinds of symbols for definition, relationship, and
composition. Definition and relation symbols are used to define the contents and
structure of an information model. Composition symbols enable the diagrams to
be spread across many physical pages.
Definition symbols. A definition symbol is a rectangle enclosing the name of
the thing being defined. The type of the definition is denoted by the style of the
box. Symbols are provided for simple type, defined type, entity type, and schema.
• Simple type symbols. A number of predefined simple types offered by
EXPRESS language include Binary, Boolean, Integer, Logical, Number,
Real, and String. The symbol for them is a solid rectangle with a double
vertical 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 data
types 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, a

dashed line, a thick solid line, and a thin solid line, which are employed to connect
related definition symbols. The symbols for these three lines are shown in
Figure 5.
A relationship for an optional valued attribute of an entity is displayed as a dashed
line, as is a schema-schema reference. A supertype-subtype relationship is
displayed as a thick solid line. All other relationships are displayed as thin lines.
196 Ma
Figure 1. Simple type symbols
Binary Boolean Integer Logical Number Real String
Figure 2. Type definition symbols
Select Enumeration DefType
Figure 3. Entity definition symbol

Entity name
Figure 4. Schema definition symbol

Schema name
Figure 5. Relationship line styles
Dashed line Thick line Thin line
Note that the lines with open circles denote relationship directions in EXPRESS-
G.
Composition symbols. Graphical representation of models often spans many
pages. Each page in a model must be numbered so that we can keep track of
where we are in the model and enable inter-page referencing. In addition, a
schema may utilize definitions from another schema. Therefore, there are two
kinds of composition symbols for page references and inter-schema references,
which are shown in Figure 6 and Figure 7, respectively. EXPRESS-G provides
two levels of modeling, namely, schema level model and entity level model.
Therefore, we discuss the fuzziness in the entity level model and in the schema
level model in the following, respectively.
Nested Relational Databases
There is the restriction of first normal form (1NF) in traditional relational

databases, which assumes that each attribute value in a relational instance must
Figure 6. Position symbols for page references
Page #, Ref # (#, #, ... Page #, Ref # Name
Reference onto this page
Figure 7. Position symbols for inter-schema references
Schema.def Schema.def
alias alias
Definition referenced from another schema Definition used from another schema
be atomic. It is clear that this assumption limits the expressive power of the
traditional relational database model in modeling complex objects with rich data
types and semantic relationships in the real applications.
The first attempt to relax this limitation was made by Makinouchi (1977). In this
initial work, attribute values in the relational instance may be atomic or set-
valued. We call such relational databases non-first normal form (NF2) relational
databases. After Makinouchi’s proposal, NF2 database model is further ex-
tended (Motor & Smets, 1997; Schek & Scholl, 1986; Yazici et al., 1999). The
NF2 database model in common sense now means that attribute values in the
relational instances are either atomic or set-valued and even relations them-
selves. So NF2 databases are called nested relational databases also. In this
chapter, we do not differentiate between these two notions. It can be seen that
the NF2 database model is a generalized relational data model, but it can model
complex 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 appears
on the left-hand side of a rule; otherwise, it is simple.
Definition. An NF2 schema may contain any combination of simple or higher

order attributes on the right-hand side of the rules. An instance of relation r,
198 Ma
Figure 8. Hierarchy structure of car product
Car
Car_Id Interior Chassis Gearbox Engine
Interior_Id Dashboard Seat Engine_Id Size Turbo
denoted by r, consists of attributes (A1, A2, ..., An). A tuple of an NF2 relation
is 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, but
an element of the subset of the Cartesian product of associated domains D jl, Dj2,
..., 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 Car
structure 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 NF 2 relational instance for the Car product data model is illustrated in

Table 1.
Based on NF2 database model, the ordinary relational algebra operations have
been extended. In addition, two new restructuring operators, called the Nest and
Table 1. Nested relation for car product

Interior Gear- Engine
Car_Id Interior_Id Dashboard Seat Chassis 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 Pack
and Unpack in Ozsoyoglu et al., 1987), have been introduced. The Nest operator
can gain the nested relation including complex-valued attributes. The Unnest
operator is used to flatten the nested relation. That is, it takes a relation nested
on a set of attributes and desegregates it, creating a “flatter” structure. The
formal definitions and the properties of these two operators as well as the
ordinary 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 capacity
of modeling complex objects with hierarchical structure, which are very common
in engineering areas. Let’s look at the Instance-As-Type (IAT) problem
proposed in Erens, Mckay and Bloor (1994) and Li, Zhang and Tso (2000). The
IAT means that an object appears as a type in one information base, but also as
an 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 IAT
problems can result in the more difficulty and cost in the maintenance of
information consistency. So we must resolve them in product data modeling, or
update anomaly occur. It is shown in Table 2.1 that the NF2 data model can avoid
the IAT problems naturally.
Extended EXPRESS-G
Since entity and schema are keys of the EXPRESS-G information model, in this
section we extend EXPRESS-G for fuzzy information modeling in entity level
and schema level models, respectively. In an entity level model, we mainly
investigate the fuzziness in data types, attributes, entities, and relationships. In
a schema level, we mainly investigate the fuzziness between schemas. The
corresponding notations are hereby introduced.
Fuzziness in Entity Level Model
An entity level model is an EXPRESS-G model that represents the definitions and
relationships that comprise a single schema. So the components of such a model
consist of type, entity, relationship symbols, role, and cardinality information.
200 Ma
Figure 9. Simple range-valued type symbols
Figure 10. Simple fuzzy type symbols
Imprecise and Uncertain Role Names
As we know, entities consist of attributes and an attribute corresponds to a

domain of values with a certain type. In EXPRESS-G, the attributes of an entity
are role named. The text string representing the role name is placed on the
relationship line connecting an entity symbol to its attribute representation. For
an aggregation attribute, the role name on the relationship line is followed by the
first 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 be
imprecise or fuzzy. An entity Engine, for example, has an attribute Size, which
data type is Real and values may be either fuzzy or imprecise in the preliminary
phase of its design. Such role names that may take imprecise and fuzzy values
are different than ones that only take crisp values. In the EXPRESS, it is allowed
that attributes take null values by using the keyword “optional” in explicit
attribute definition. In order to represent range values and fuzzy values in
EXPRESS-G, we give the symbols for range-valued and fuzzy attributes that
take 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 at
enumeration type. As we know, an enumeration type is an ordered list of values
represented by name, where the list has a perfect boundary. A value named
either belongs to the enumeration type or does not belong to the enumeration
type. It is possible, however, that a value belongs to the enumeration type with
degree, namely, the value is fuzzy. For example, an enumeration type is
HairType = ENUMERATION OF (Black, Red, Brown, Golden, Grey) and the
hair type of a person is red and brown.
Figure 11. Ranged-valued type definition symbols
DefType Select Enumeration
Figure 12. Fuzzy type definition symbols
DefType Select Enumeration
A defined data type is created based on the underlying type. The defined data
type generally has the same domain of values as the underlying type unless a
constraint 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 of
simple type, collect type, or enumeration type may be fuzzy or imprecise. The
imprecision and fuzziness for the values of select type or entity type are shown
in 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. A
value of a select type is a value of one of the types specified in the select list
where each item is an entity type or a defined type. The imprecision or fuzziness
of a value of select type comes from the imprecision or fuzziness of its
component type, fuzzy or imprecise entity type and defined type.
The symbols for modeling imprecise and fuzzy type are shown in Figure 11 and
Figure 12, respectively.
Fuzzy Entity Modeling
Fuzzy entity modeling can be classified into two levels. The first level is the
fuzziness in the entity sets, namely, an entity has a degree of membership in the
Figure 13. Entity with fuzzy instances
Figure 14. Entity with membership degree
µ (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 entity
Research 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 rectangle
as well as the name of the entities. Let E be an entity and µ (E) be its grade of
membership 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 E2 such that for any entity
instance e, e ∈ E2 implies e ∈ E1, then E2 is called a subtype of E1, and E1 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 in
EXPRESS. 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, S2, …, Sn with
membership functions µE, µS1, µS2, ..., and µSn, respectively, the following
relationship is true:
(∀e) (∀S) (e ∈ U ∧ S ∈ {S1, S2, …, Sn} ∧ µS (e) ≤ µE (e))
For the fuzzy subtype with multiple fuzzy supertypes, let E be a fuzzy subtype and
S1, S2, …, Sn be its fuzzy supertypes, which membership functions are respec-
tively µE, µS1, µS2, ..., and µSn.
(∀e) (∀S) (e ∈ E ∧ S ∈ {S1, S2, …, Sn} ∧ µE (e) > 0 ∧ µS (e) ≥ µE (e))
The fuzzy supertype/subtype in fuzzy EXPRESS-G can be represented with a

fuzzy relationship.
Fuzzy Relationship Modeling
As mentioned above, there are dashed lines, thick solid lines, and thin solid lines
in EXPRESS-G. Dashed lines and thin solid lines connecting attributes represent
Figure 15. Fuzzy relationship line styles
µ (A)/A µ (A)/A
Figure 16. Fuzzy schema definition symbol
Schema name
that attributes must belong to the corresponding entity. In fact, it is also possible
that 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 degree
to indicate a fuzzy attribute-entity relationship. We can place membership
degrees upon dashed lines and thin solid lines. In addition, we use thick dashed
solid lines to represent the fuzzy supertype/subtype above. The symbols for these
three lines are shown in Figure 15, where A and µ denote the name of an attribute
and its membership, respectively.
Fuzziness in Schema Level Model
A schema level model is one that displays the schemas, and the relationships
between these schemas. Since fuzziness can occur in entities, the relationships
among these entities may hereby be fuzzy. Following two kinds of schema
relationships Use and Reference in EXPRESS-G, fuzzy Use and Reference
relationships in fuzzy EXPRESS-G are denoted by normal width relation lines
and dashed relation lines with membership degrees as shown in Figure 16.
Through the discussion above, three levels of fuzziness can be found in fuzzy
EXPRESS-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 fuzziness
at the level of entity and attribute (the first level). The fuzziness at the third level
means that attributes take fuzzy values. The second level of fuzziness means that
each instance of an entity belongs to the entity with a membership degree. The
first level of fuzziness means that attributes comprise an entity with membership
degrees or entities comprise a schema with membership degrees.
204 Ma
Figure 17. Fuzzy EXPRESS-G data model
Number
Real
Real
Real
String
Type
0.5/Thickness
Body_Id
Capacity
Volume
Material
Length
Air tank
Real
Real
Radius
Light oil tank

Over height
String
Tank_Id
0.7/Water tank
Tank
An Example Illustration
In Figure 17, we give a simple fuzzy EXPRESS-G data model utilizing some
notations introduced above. Entity Tank is a supertype, which has three
subtypes, namely, Air tank, Water tank, and Light oil tank. Among these three
subtypes, it is known for certain that entities Light oil tank and Air tank are the
subtypes of entity Tank. In other words, the membership degrees that Light oil
tank and Air tank are the subtypes of Tank are 1.0, respectively. However, it
is 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 of
Tank is 0.7. In addition, entity Light oil tank is a fuzzy entity with fuzzy
instances. The entity Air tank has eight attributes. The attribute Body_Id is a
perfect one with string type. Attribute Thickness is an attribute associated with
a membership degree 0.5, which means the possibility that entity Air tank has
attribute 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. The
attributes Length and Radius are imprecise ones that can take range values. It
should 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), where
pM is a special attribute and used to represent the membership degrees of the
tuples, 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 be
unk, inap, nin, and onul.
3. The power set of the set in (1). The corresponding attribute values are
multivalued ones with the form of {ail, ai2, ..., aim}.
4. The power set of the set in (1). The corresponding attribute values are
imprecise range-valued ones of the form [a il, ai2, ..., aim] and [ail-ai2] 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 <a i1, ai2, ..., aim> which is an element of Dil × 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 crisp

one from the range [0, 1]. Let t be a tuple in a given NF2 relation. Then the
attribute value of t on pM, denoted t [pM], represents the possibility that t belongs
to the NF2 relation.
Let us look at the preliminary design of a pressured air tank presented by Otto
and Antonsson (1994). In this design, there are two design parameter values that
need to be determined: length (l) and radius (r). In addition, there are four
performance parameters in the design:
• Metal volume m: the preference ranks of m are set because it is proportional
to 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 structure
information in product data model using fuzzy NF2 database model. A possible
database schema and an instance are partially represented in Table 2 (for space
limitation). Note that the attribute pM can be omitted from the fuzzy NF 2 relation
when 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,” “about
1.0e+06,” “about 2.5e+04,” “about 1.0e+07,” “less than 627.50,” “less than
106.75,” “less than 630.00,” and “less than 112.50” are all fuzzy values. Assume
that 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 Fuzzy

Nested Relational Databases
In this section, we define the formal approaches to mapping EXPRESS-G data
model with imprecise and uncertain information to fuzzy NF2 database schema.
The issue is essentially concerned with the design of logical databases for a
product data model from a conceptual data model for a product data model.
Nested Relational Databases Support to EXPRESS

Model
The entity instances are identified by their unique identifiers in the EXPRESS
information model. The entity identifiers are just like the keys in (nested)
relational databases, but they are different. The keys are the component parts
of information content whereas the entity identifiers are not. We can view an
entity as a database relation and view the instances of the entity as the tuples of
the database relation. When we would like to represent entity instances in
relational databases, we have to solve the problem of how to identify entity
instances in relational databases. In other words, we must indicate keys of the
tuples originated from entity instances in the relational databases. As we know,
in EXPRESS information, there are attributes with UNIQUE constraints. When
an 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 identify
instances. Therefore, an EXPRESS information model must at least contain such
an attribute with UNIQUE constraint when relational databases are used to
model an EXPRESS information model.
In EXPRESS, there is the entity for which attributes are other entities, called
complex entities. Complex entities and subtype/supertype entities in an EX-
208 Ma
PRESS information model can be implemented in relational databases via the

reference relationships between relations. It is clear that, based on such
organization principles, the objects related in structural relationships with one
another are represented in separate relational databases. In order to obtain some
information, one may have to query multiple relational databases by using join
operations. Besides, it is very hard to have a complete and clear picture about
an information model from the query answers. Relational databases obviously
are not suitable to support the EXPRESS information model because of the
restriction of first normal form (1NF) in traditional relational databases. Nested
relational databases can solve the problems above very well.
Formal Mapping
Generally speaking, an entity in EXPRESS-G can be mapped into a relational

schema and the role names in the entity mapped into the attributes of the
relational 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 classified
into three levels. The second level and the third level of fuzziness, namely, the
fuzziness at the level of instance/entity and the fuzziness at the level of attribute
value, can be represented in fuzzy NF2 databases. Relational database models
and nested relational database models only focus on instance modeling and their
meta-structures are implicitly represented in the schemas. The fuzziness at the
level of entity and attribute cannot be modeled in fuzzy NF2 databases due to the
limitation of NF 2 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 entities
as a component part or that is the underlying types of enumeration and
select types.
2. Subtype entities. A subtype entity is the entity that is in supertype/subtype
relationships 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 fuzzy
NF2 relational schema and its role names become the simple attributes or
structured 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 a
structured 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 define
themselves.
• 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 some
of 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. For
fuzziness of entity instances, the special attribute “pM” must be included in the
structured attributes or the relational schema to indicate the membership degree
of entity instances.
Second, let us look at case (2): subtype entities. Following similar methods as
described above, a subtype entity can be mapped into a fuzzy NF2 schema. It
should be noted that, however, the key attributes of all the supertypes must be
replicated in the subtype.
Table 2. Air tank relation

Tank Tank_body Overall
_Id Body_Id Material Length Radius Volume Capacity height
TA1 BO01 Alloy [25, 600] [10, 100] about about less than
2.5e+03 1.0e+06 627.50
TA2 BO02 Steel [30, 650] [15, 110] about about less than
2.5e+04 1.0e+07 630.00
210 Ma
A member entity in case (1) is not mapped to a class, but to a complex attribute
of another class that is composed of the member entities. But, the fuzziness in
the member entity can be handled according to the same principles as the
common entity.
Following the formal rules given above, we map the fuzzy EXPRESS-G model
in Figure 17 into the fuzzy nested relational database in Table 2. Note that
attribute “0.5/Thickness” in Figure 17 cannot be mapped into the fuzzy nested
relational database due to its first level of fuzziness.
It should be noted that we do not discuss the mapping of data types in fuzzy
EXPRESS-G models. We assume that fuzzy nested relational databases support
the data types in fuzzy EXPRESS-G models. In fact, the data types supported
by different database products vary. More and more data types are supported
by some latest release of database management systems. Our focus here is on
mapping the entities and the attributes associated with entities in fuzzy EX-
PRESS-G models. We have identified all three kinds of entities in fuzzy
EXPRESS-G models and given the mapping methods that map fuzzy entities and
attributes into fuzzy nested relational databases. So the mapping methods given
in the chapter can be used to solve the problem of fuzzy engineering data model
transformations.
Conclusions
In this chapter, we have proposed a fuzzy extension to EXPRESS-G that can
capture the imprecise and uncertain engineering information. In addition, fuzzy
nested relational databases have been introduced. The formal approaches to
mapping a fuzzy EXPRESS-G schema to a fuzzy nested relational database
schema have been developed in this chapter.
It should be noted that EXPRESS-G is only a subset of the full language of
EXPRESS. Clearly, it is necessary to extend EXPRESS for imprecise and
uncertain engineering information modeling and then map fuzzy EXPRESS
models into databases. In addition, it is also very interesting to formally compare
transformation modeling among EXPRESS-G and other conceptual data models,
such as ER/EER, UML, and IDEF1X. We will investigate these issues in our
future 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 Data
Model for Managing Vague and Uncertain Information. International
Journal of Intelligent Systems, 14, 623-651.
Bosc, P. & Prade, H. (1993). An Introduction to Fuzzy Set and Possibility Theory
Based Approaches to the Treatment of Uncertainty and Imprecision in
Database Management systems. Proceedings of the Second Workshop
on Uncertainty Management in Information Systems: From Needs to
Solutions.
Buckles, B. P. & Petry, F. E. (1982). A Fuzzy Representation of Data for
Relational Database. Fuzzy Sets and Systems, 7(3), 213-226.
Caputo, M. (1996). Uncertainty, Flexibility and Buffers in the Management of
the Firm Operating System. Production Planning & Control, 7(5), 518-
528.
Chaudhry, N., Moyne, J. & Rundensteiner, E. A. (1999). An Extended Database
Design 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 Fuzzy
Conceptual Data Modeling. Proceedings of the 1998 IEEE International
Conference on Fuzzy Systems, 2, 1320-1325.
Chen, P. P. (1976). The Entity-Relationship Model: Toward a Unified View of
Data. ACM Transactions on Database Systems, 1(1), 9-36.
Codd, E. F. (1987). More Commentary on Missing Information in Relational
Databases (Applicable and Inapplicable Information). ACM SIGMOD
Record, 16(1), 42-50.
Colby, L. S. (1990). A Recursive Algebra for Nested Relations. Information
Systems, 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 in
Product Design: A Comparison. Computer-Aide Design, 26(7), 551-572.
Erens, F., Mckay, A. & Bloor, S. (1994). Product Modeling Using Multiple
Levels 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). Uncertainty
Management 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 Null
Values. Proceedings of the 1988 International Conference on Very
Large Data Bases, 50-61.
Grabot, B. & Geneste, L. (1998). Management of Imprecision and Uncertainty
for Production Activity Control. Journal of Intelligent Manufacturing, 9,
431-446.
Guiffrida, A. & Nagi, R. (1998). Fuzzy Set Theory Applications in Production
Management Research: A Literature Survey. Journal of Intelligent
Manufacturing, 9, 39-56.
Gyseghem, N. V. & Caluwe, R. D. (1998). Imprecision and Uncertainty in UFO
Database Model. Journal of the American Society for Information
Science, 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 Design
and Concurrent Engineering under Imprecision. Journal of Intelligent
Manufacturing, 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 Uncertain
Information in Relational Database for Engineering Design and Production
Management: Review and Future Work. Proceedings of the 1998 ASME
Design Engineering Technical Conference.
Li, Q., Zhang, W. J. & Tso, S. K. (2000). Generalization of Strategies for Product
Data 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 to
Resolve the Conflicts in Schema Integration of Multiple Databases in
Virtual Enterprise. Proceedings of the 1999 ASME Design Engineering
Technical Conference.
Ma, Z. M., Zhang, W. J. & Ma, W. Y. (1999). Incomplete Information in Product
Concept Design and Its Modeling in Relational Databases. Proceedings of
the 1999 Lancaster International Workshop on Engineering Design,
99-114.
Ma, Z. M., Zhang, W. J., Ma, W. Y. & Chen, G. Q. (2000). Extending
EXPRESS-G to Model Fuzzy Information in Product Data Model. The
2000 ASME Design Engineering Technical Conference.
Makinouchi, A. (1977). A Consideration on Normal Form of Not-Necessarily
Normalized Relations in the Relational Data Model. Proceedings of Third
International 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: Issues
and 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 Product
Design. Proceedings of Fuzzy-IEEE 1994, 346-351.
Otto, K. N. & Antonsoon, E. K. (1994). Design Parameter Selection in the
Presence of Noise. Research in Engineering Design, 6(4), 234-246.
Ozsoyoglu, G., Ozsoyoglu, Z. M. & Matos, V. (1987). Extending Relational
Algebra and Relational Calculus with Set-Valued Attributes and Aggregate
Functions. ACM Transactions on Database Systems, 12(4), 566-592.
Parsons, S. (1996). Current Approaches to Handling Imperfect Information in
Data and Knowledge Bases. IEEE Transactions on Knowledge Data
Engineering, 8, 353-372.
Petrovic, D., Roy, R. & Petrovic, R. (1998). Modeling and Simulation of a Supply
Chain in an Uncertain Environment. European Journal of Operational
Research, 109, 299-309.
Petrovic, D., Roy, R. & Petrovic, R. (1999). Supply Chain Modeling Using Fuzzy
Sets. International Journal of Production Economics, 59, 443-453.
214 Ma
Prade, H. & Testemale, C. (1984). Generalizing Database Relational Algebra

for the Treatment of Incomplete or Uncertain Information. Information
Sciences, 34, 115-143.
Roth, M. A., Korth, H. F. & Batory, D. S. (1987). SQL/NF: A Query Language
for 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 EXPRESS
Way. 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 Methodology
for 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 and
Automation, 14(4), 513-524.
Venkatramen, S. S. & Sen, A. (1993). Formalization of An IS-A Based
Extended Nested Relation Data Model. Information Systems, 20(1), 53-
57.
Vila, M. A., Cubero, J. C., Medina, J. M. & Pons, O. (1996). A Conceptual
Approach for Deal with Imprecision and Uncertainty in Object-Based Data
Models. International Journal of Intelligent Systems, 11, 791-806.
Wood, K. L. & Antonsoon, E. K. (1992). Modeling Imprecision and Uncertainty
in Preliminary Engineering Design. Mechanism and Machine Theory,
25(3), 305-324.
Yager, R. R. (2000). Targeted e-Commerce Marketing Using Fuzzy Intelligent
Agents. 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 a
Nested 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. Fuzzy
Sets and Systems, 1(1), 3-28.
Zaniola, C. (1986). Database Relations with Null Values. Journal of Computer

System Science, 28(2), 142-166.
Zhang, W. J. & Li, Q. (1999). Information Modeling for Made-to-order Virtual
Enterprise 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 Fuzzy
Databases. Proceedings of the 1986 IEEE International Conference on
Data Engineering, 320-327.
216 Ma
Section III
Additional Topics
Analysing Transformations in Performance Management 217
Chapter X
Analysing
Transformations in
Performance
Management
Bernd Wondergem, LogicaCMG Consulting, The Netherlands
Norbert Vincent, LogicaCMG Consulting, The Netherlands
Abstract
Performance Management (PM) is a way of managing in which the

organisation’s goals and organisation model are made explicit. In this
chapter, several forms of PM are investigated to meet these observations.
The goals and organisation model together form the management model of
the organisation. Steering the organisation towards its strategic goals then
comes down to repeatedly transforming this management model. In this
chapter, these transformations are systematically analysed. In order to do
this, we first provide a framework in which several types of transformation
can be identified. Second, properties of the transformations are stated and
related to different styles of management. In addition, we sketch future
trends 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’s
strategic goals and its organisation model are made explicit. In addition, the
connection between those two issues is made by stating how the organisation
model produces the organisations output. The explicitly stated goals (the what)
and organisation model (the how) form the core of the management model for
steering the organisation.
In PM, running a business is all about transformations. First, of course, a general
notion of transformation applies: the organisation transforms some form of input
to some form of output. More specific to PM, steering the organisation towards
its strategic goals is done by repeatedly transforming the organisation and the
management 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 for
analysing transformations in performance management. Second, we use the
framework to identify several types of transformations and describe which
properties 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, and
approaches to, PM and presents our vision on the subject. Next, the framework
for analysing transformations is presented: the performance management model.
In the following section, we use this model for describing several types of
transformations. The chapter then deals with future trends. Finally, we provide
concluding remarks and an outlook on further research.
Background
In general, organisations try to find, reach and sustain a strategic position in their
environment. Mintzberg (1991) has classified the ways to do this into two
categories: emergent strategies and planned strategies. “Organisations develop
plans 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 goals
are often seen as preceding steps in strategy-formulation. However, these steps
are not always explicitly taken or repeated in formulating or revising the strategy.
Figure 1. General set-up of performance management
Second, the strategy and the corresponding goals are translated into perfor-
mance indicators (PI). PI’s form measurable indicators which give a quantitative
view 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 is
used 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 of
value. Figure 1 sketches the place of the Deming’s cycle in the general set-up
of performance management. In the “do” step, the organisation produces its
products or services and measures its performance through PI’s. This provides
a fact-based insight into the current performance. The results are evaluated and
actions to improve the future performance are defined in the “‘check” step.
Finally, the “act” step consists of implementing the actions. After this, the
strategy may be revised and a new cycle starts. The information that is explicitly
used in the “check” and “act” steps constitutes the so-called performance
management model. This is elaborated upon later in this chapter.
In this chapter, we will consider three aspects of PM as its essence. We define
Performance 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 performance
indicators.
2. Links the strategic goals of the organisation to the operational organisation.

In other words: how the strategy is to be realised is explicitly incorporated
in 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 a

complete overview, we provide a description of some approaches below.
The Balanced Scorecard (BSC) is both an instrument and management model
that aims at providing a balanced view on the organisation’s performance
(Kaplan & Norton, 1992, 2000). It was developed as a reaction to primarily
financial steering. Nowadays, it is a popular instrument in many businesses. The
BSC looks at the business from four perspectives: financial, customer, internal
and innovation & learning. In practice, however, this set-up is sometimes altered
by changing the number and contents of the perspectives. In that way, the BSC
is custom-made for the specific needs of organisations. The BSC is put to work
by searching for key success factors (KSF) within the four perspectives. The
KSF’s are derived from the organisation’s strategy, thereby making its causal
dependencies 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 support
the 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 Scheipers
et al., 2002) is an approach for performance management stemming from the
areas of financial management and management accounting. VBM is a manage-
ment control system that measures, encourages and supports maximizing
shareholder value. It is based on the conviction that the interests of all
stakeholder groups are best served by putting the shareholder first. The term
“value” is more complete than earning-measures only, since it also takes the
notion of risk, the impact of inflation and opportunity costs into account. VBM
requires complete information to calculate “value” properly. In addition, a long-
term strategic point of view is required to describe the expected outcomes. VBM
is advocated to be used at the corporate and strategic business-unit level.
Exploiting VBM requires substantial training, especially for non-experts in
finance. 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) as
well as for processes that deliver services. Six Sigma is a form of “management
by fact”: it uses statistical information and techniques to measure and analyse
business performance. Six Sigma also exploits two variants of cycles for
continuous improvements. First, the so-called DMAIC process, for Define,
Measure, Analyse, Improve and Control, is an improvement system for existing
processes. Second, the DMADV process, having Design and Verify as final
steps, 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 three
types of requirements: (1) revealed requirements (what customers say they
want), (2) expected requirements (what customers demand as standard quality)
and (3) exciting requirements (beyond the customer’s expectations). These
requirements are analysed, prioritised and finally translated to design specifica-
tions. This results in a set of measurable product specifications. QFD is an
explication of the “plan” phase of the Deming-cycle. The remaining three phases
of the Deming cycle are not explicitly covered by QFD. QFD thus provides a
structured approach for the design of a quality product and service portfolio and
the 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 management
is given in Wondergem (2003). Also, other fields provide approaches to quality
and performance management that can be identified. As an example, we mention
the approach to software quality, as described in Locuratolo (2002).
These approaches to PM all formulate performance indicators for measuring
performance and communicating strategic goals. How this is done differs for
different approaches. In general, though, all approaches use an intermediate step
between 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). The
measured items indicate which strategic subjects are important enough to be
measured 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 and
products, such as variability and quality.
In the next section, a model for PM is described. This model is used in later
sections to describe and analyse different transformations in PM.
Performance Management Model

A Performance Management model (PMM) contains the information that is
used for steering transformations in performance management (see also Figure
1). The PMM fits in our notion of performance management by making the goals
and the organisation explicit. The cycle for continuous improvement is not
incorporated in the model, since it does not constitute information for steering,
but the process itself. Therefore, the cycle is described separately as a series of
transformations. The PMM is input for these transformations and, with altered
form and contents, forms its output as well.
PM explicitly models the desired performance in a goal model (GM) and the
factors that drive and produce output in an organisation model (OM). The GM
and OM are parts of the performance management model (PMM). The PMM
is completed by a connection between the GM and OM. This connection
indicates how the OM produces or influences the GM. In that sense, the
connection 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 performance
indicators. The causal relations between the measured items describe dependen-
cies between the strategic goals and subgoals. The PI’s operationalise the
measured items: they make the measurement of the performance considering the
measured items explicit.
Example: Customer Satisfaction: Contact centres are organisations for which

customer satisfaction is of major importance. The management of the
fictive unit “The Contact Centre” (TCC) of a company that sells products
understands this. Therefore, they explicitly manage their organisation on
customer satisfaction. To do this, they constructed the goal model as
depicted in Figure 2. The measured item “Customer Satisfaction” is broken
down into its constituents. Three other measured items appeared to
influence customer satisfaction: satisfaction of the products, the quality of
the 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
Figure 2. Example goal model for customer satisfaction
contact is influenced by three other measured items: the quality of the

processes 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 customer
satisfaction.
In Table 1, example performance indicators for some of the MI’s in the goal
model are provided. The third column of the table provides example
numerical 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,
Table 1. Example indicators

Measured item Performance indicator Example
values
Satisfaction of product % of customers rating the produt flexibility eight or higer 75%
Number of complaints about the product per month 35.6
Quality of process Helpfulness of the call center agents as grade 7.4
% of complaining customers that accepts offer 65%
Channel availability Waiting time in seconds before call is answered 13.1 sec
Availability (uptime %) of the voice response system 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 described
below. The impact value of a causal relation (mi1 à mi2) denotes the part of
mi2 that is explained by mi1. The completeness of an MI, say mi1, is the sum of
all impact values of the causal relations (mi2 à mi1). The score of a PI
expresses the current performance with respect to the PI. The score of a
measured item is then given as the average of the scores of all PI’s that
operationalise it. In order to compute the average of the PI’s, they first have to
be made comparable (Chang & Morgan, 2000).
Organisation Model
The organisation model provides the factors that drive and produce the
organisation’s output. Numerous ways of modeling organisations exist. For our
purposes, 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 model
dependencies on the organisational elements.
Example: Contact centre: The management of the contact centre of the

previous example has also constructed an organisation model. It has done
so based on the COPC model, which is a performance management model
for contact centres (COPC, 2002). The organisation model distinguishes
goals, enablers and drivers (Figure 4). In short: the goals are produced by
the enablers, which, in turn, are directed by the drivers. The goals of the
contact centre consist of quality of contact (see the previous example) and
costs. The enablers describe how the contact centre is organised: which
processes are performed and how are employees and resources used in
that? 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 organisational
elements and links are missed. This would diminish the steering capabilities of the
OM. Furthermore, it is important that the OM provides enough detail, enabling
focused steering.
Figure 3. Example organisation model for contact centers
Handles
Handles connect the goals (measured items) to elements from the organisation
model. The handles can thus be formally described as a relation on GM.MI x
OM.N. However, the handles are often not stated explicitly. Rather, they reside
in 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 to
form in Van den Bosch and Van Wijk (2001).
The scope of the handles is defined as the portion of all connections between
organisation model and goal model that are included in the handles. The scope
delimits the possible effectiveness of the management model. A large scope may
consider 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 about
how to steer, but may miss relevant options.
Transformations in Performance
Management
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 be
done. Analysing the evidence in the light of the PMM thus leads to a series of
actions that can be taken to improve performance. The actions are implemented
and the results are measured again. This starts a new cycle in the management
process.
Figure 4. Transformations in PMM
This cyclic management process can be described as a series of transformations.

Each transformation uses evidence of the current performance (E) and the
current status of the PMM as input. In Figure 4, this is schematically denoted as
a 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 the
organisation, 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 and
Chatterjee (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 transformation
of the PMM can be distinguished: transformation of the goal model, the
organisation model and the handles. These transformations are elaborated in the
following subsections. After that, the section, Future Trends in Transforma-
tions in the Organisation, focuses on future trends for transformations in the
organisation itself.
Transformations of Goal Model
Transforming the goal model can be identified at two levels. First, measured
items and causal relations may be altered. Second, performance indicators and
their 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 such
a transformation can be stated as: the completeness of mi1 is too low, where mi1
is a measured item out of the goal model. The action in the transformation
consists of adding a measured item mi2 and the causal relation (mi2 à mi1). The
post-condition of the transformation then states that the completeness of mi1 is
higher. The proof of this claim hinges on the assumption that the impact value of
mi2 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 complete
enough. Therefore, this MI is augmented with the following underlying
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 through
the notion of completeness, a change of strategy is an external factor to the goal
model. Since organisations reside in dynamic environments, strategies need to be
frequently adjusted and sometimes rigorously changed. As said before, the goal
model forms a strategic map. Therefore, the goal model should properly reflect
the strategic goals and relations between them. Coherence between strategy and
goal model is, however, a subjective issue. This means that transformations that
aim at adjusting the goal model to the strategy heavily rely on the business model
of the individual manager.
Changes in PI’s may stem from several reasons, as is shown in Wondergem and
Wulferink (2002). The corresponding transformations of the goal model there-
fore aim at different improvements. A first reason to alter PI’s is the availability
of source data. With these data, the contents of the PI’s are filled. PI’s for
which the source data is not sufficiently (easily) available, may be deleted or
replaced by more suitable variants. Second, PI’s need to be recognisable, which
means that management needs to either be familiar or become familiar with the
PI’s. If PI’s are not recognisable, this hinders effective steering. Insufficiently
recognisable PI’s are therefore replaced by PI’s that better suit the manager’s
experience. As a third reason to change PI’s, we mention dysfunctional
behaviour (Birnberg et al., 1983). PI’s measure specific aspects of the
organisation’s performance, leaving room for “gaming”: giving insufficient
attention to other important issues. These issues can in turn be covered by PI’s
as well, resulting in a balanced set of PI’s. In addition, the measurement of PI’s
should leave little room for “smoothing” the results. PI’s which are automatically
delivered from a data warehouse may serve this purpose, since their computation
from source data is strictly specified. Fourth, PI’s need to be consistent in
definitions, providing the possibility to compare PI’s. This is for instance required
for benchmarking. Finally, PI’s, or rather, the way in which performance is
measured, 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 may
harm effective steering.
Transformations of Organisation Model
The organisation model reflects the explicitly stated scope managers have for
finding 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 organisation
elements may be added. Adding an organisation element and linking it to the
existing OM, provides managers with a broader scope for steering the organisation.
In certain quality models, such as the Dutch INK model (INK, 2001), several
identified phases describe this growing complexity. Starting, for instance, with
isolated actions, a proceeding phase considers series of actions and their
interdependencies, i.e., processes. The final phase may describe a holistic view
on the organisation and its place within its environment.
Next to the completeness of the OM, its level of detail is also of importance. In
practice, a first measurement of performance using a rather coarse grained
model pinpoints the organisation processes which require improvement. Only
these processes are then described in more detail, thus focusing the energy for
improvement. Providing more detail for existing organisation elements may be
done by decomposing the element. A process, for instance, can be decomposed
into several sub-processes. This enlarges the insight in the problem areas and
enables more specific decisions on improvement issues.
Example: Detailing the organisation model: Consider the example organisation

model of The Contact Center as depicted in Figure 3. Suppose that the
processes do not deliver the expected quality. In order to be able to select
(only) under performing processes, this organisational element is broken
down into the following sub-elements: customer contact, instruction, train-
ing, supervision, reporting and planning. Furthermore, customer contact
processes may be divided into pre-sales, sales, after-sales and service.
Both types of transformation of the OM make it more complex. This coincides

with the growing professionalism with which performance management is
executed: 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 a
change of focus in management instruments.
Transformations of Handles
Handles form the connection between the organisation model and the goal
model. As such, they constitute the possibilities in the OM that a manager
explicitly 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 certain
handles do or do not work. This enhances or concentrates the set of options they
consider in steering. In that way, the set of handles is personally defined and
alters over time. In this respect, the professionalisation of management aims at
providing managers with the right set of handles.
Future Trends in Transformations in the

Organisation
In this chapter, we discuss future and emerging trends in performance manage-
ment by focusing on organisational transformations. To this end, we view
organisations as a set of activities, coordination-mechanisms and responsibilities,
in line with the set-up of Mintzberg (1983). In this set-up, we distinguish three
categories of transformation, which will be elaborated on in the following
subsections:
1. Transformation of the responsibilities: from effort-driven towards re-
sult-driven management.
2. Transformation of coordination: from yearly to dynamic resource
allocation.
3. Transformation in activities: from competitive advantage to sustained
competitive advantage.
Toward Result-Driven Business Management
Performance Management can be used to transform the control style and the
budgeting process of the organisation. In addition, it makes the current way of
working more explicit and thus transparent. This leads organisations toward a
result-driven style of management.
The control style and organisation’s budgeting process can have an impact on the
way an organisation will set up its performance management model. Different
control styles can be identified. Goold and Cambell, (as described in Strikwerda,
2000), have defined three control styles: strategic planning, strategic control and
financial control. An organisation should select a dominant style to make clear
what the organisation expects from the PMM (De Waal, 2001). In addition, this
signals the dominant type of performance indicators which will be used. Financial
control will use primarily financial indicators, while strategic planning requires
information from non-financial sources as well.
The nature of the budgeting process influences the construction of the PMM. In
result-based budgets, as opposed to cost-based budgets, the relationship be-
tween performance and patterns of action-reaction is more complex. This
requires detailed insight into the causal relationship between the MI’s and the
links with handles. The use of a balanced scorecard will thus coincide with the
construction of more professional models of performance management.
Example: Results and indicators: The contact center from example two is
directly responsible for the quality of contact only. The contact center has
two goals: (1) quality of contact, and (2) costs. In the case of financial
control, the contact center mainly will be reviewed on the total costs.
Examples of financial Performance indicator Measured item

control
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 Costs of tools used in the contact centers The additional costs to process
channel the complaint
In the strategic planning style not only the costs, but also the quality
becomes more important. Then Table 1 gives a reflection of relevant
performance indicators. Organizations that change their control style from
financial to strategic or vice versa thus also transform their performance
management model.
Toward Dynamic Resource Allocation
The Deming circle, as stated before, is widely used to manage the process of
continuous performance improvement. The Deming circle is executed at strate-
gic, tactical and operational levels. The integration between the management
levels (vertical integration) and between the departments on the same level
(horizontal integration) should ensure that the actions are coordinated and all
directed toward the strategic goals. The Deming circle can be seen as the
operationalisation of management control. Management control consists of
several control subsystems each with their own view on strategy (Simons, 1995).
We mention two types: (1) the diagnostic control subsystem, where strategy is
seen 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 our
consulting practice, we see that performance management often solely focuses
on the diagnostic control system (Wondergem & Eskens, 2003). The diagnostic
control system, however, is a single-loop learning process, while successful
implementation of performance management requires at least a double-loop-
learning process (Kaplan & Norton, 1992). In single-loop learning, the actions
are directed towards realising the target of the PI’s. Double-loop learning
enables organisations to analyse and revise the assumptions underlying the PMM
and uses the evidence to define new norms. With double-loop learning, the
organisation can plan the strategy and the necessary actions to realise the
business strategy. In that, the organisation uses the PMM to operationalise the
business strategy and can evaluate the strategic map and the causal relation-
ships. Double-loop learning can make the connection between the diagnostic and
interactive control system. Finally, deutero learning can be distinguished (Argyris,
1982). Deutero learning is about the speed and quality of the learning process and
thus influences the flexibility and adaptability of the organisation. Considering the
increased dynamic nature of the business environment, we envision that deutero
learning 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 of
evaluating the chosen strategy increases and the speed and frequency of
walking, through the Deming circle should keep the same pace. As an effect, the
strategic planning horizon shortens and budgets become obsolete sooner. As a
consequence, information should be available in real time and actions are
focused on short-term results. To make sure that the organisation develops the
right 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 forecasts
and align their resource allocation with the strategic requirements. This is in line
with the vision of the Working Council for CFO’s (WCC, 2001).
Example: The responsibility of the Contact Center for only the quality of the
contact is based on the assumption that the product (make and sell) and the
service of the product (sense and respond) can be separated and that the
Contact Center is only a service entrance and not a sales point. Nowadays,
however, customers do not separate sales and service; customers calling
a contact center also want information about products or even want to buy
products (cross-selling). Fulfilling customer needs with additional product
features (extra games for a Nintendo) has a high impact on the satisfaction
of the product.
When the satisfaction of the product is declining and the customer Contact
Center meets all of their goals (quality of contact, quality of process,
employee satisfaction, channel availability), it is not the current planning

that should be revised, but the assumptions that lie beneath it. Changing
these assumptions will transform the performance management model.
Toward Sustained Competitive Advantage
In the end, Performance Management should help an organisation to create

superior performance and sustained competitive advantage. When taking an
inside perspective on strategy, the actions should be focused on the enablers:
processes, employees and resources. In this light, we mention several research
questions that deserve renewed or ongoing attention. First, we mention the issue
of process optimisation. A second question amounts to how the productivity of
the employees can be increased. A third question centers around how to exploit
synergies out of the resources, both tangible and intangible. Given the complexity
of the causal relations between MI’s and the organisation model, a resource-
based view on performance management may well become more relevant. We
thus propose more attention be given towards an “enabler-oriented” vision on
performance management.
Conclusions
We have described a framework for analysing transformations in performance
management, including the performance management model. Using this frame-
work, several types of transformation were described. The framework describes
which elements of the organisation and its management model can be trans-
formed by performance management, as well as the factors that play a role in
the transformations. In addition, an initial description of the properties of the
transformations was given and future consequences for the organisation
were 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 the
organisation model. As an additional aspect, the section about future directions
sketched possible paths of evolution for organisations that use performance
management. Actually using the information in PM was only briefly touched
upon in this chapter. It is, however, an important issue since it heavily influences
the success of the implementation of PM. The combination of insights into which
information is necessary for steering, how to organise performance management
and knowledge of effective ways of actually using the information, will provide
better means for successfully implementing performance management.
References
Argyris, C. (1982). Reasoning, Learning and Action: Individual and
Organisational. San Francisco, CA: Jossey-Bass.
Birnberg, J.G., Turpolec, L. & Young, S.M. (1983). The organisational context
of 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 Star
Publishing.
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 Modelling
and Knowledge Bases XIII. IOS Press.
Mazur, G.H. (1993). QFD for Service Industries. Proceedings of the Fifth
Symposium 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 Henry
Mintzberg. Long Range Planning, 24(2), 108-111.
Mintzberg, H. (1994). The rise and fall of strategic planning: Reconceiving
roles 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 Innovative
Control Systems to Drive Strategic Renewal. Boston, MA: Harvard
Business School Press.
Strikwerda, H. (2000). Het ontwerpen van een Organisatie: de
Concernstructuur. Financial Times/Prentice Hall. In Dutch.
Van den Bosch, F.A.J. & Van Wijk, R. (2001). Creation of managerial
capabilities through managerial knowledge integration: A competence-
based perspective. In R. Sanchez (Ed.), Knowledge Management and
Organizational Competence. New York: Oxford University Press, 159-
176.
WCC. (2001). Beyond Measurement Alone. Report of the Working Council
for Chief Financial Officers, London. Retrieved from the WWW:
www.cfo.executiveboard.com
Wondergem, B.C.M. (2003). Het Selecteren van een Geschikte Methode Voor
het Formuleren van Indicatoren. Proceedings of the Conferentie
Informatiewetenschap 2003, Eindhoven, The Netherlands, November
2003. 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 de
Balanced 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 Conversion
with the Focus
on Continuous Media
Maciej 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 multimedia

conversion. The authors hope to familiarize readers with the idea of
multimedia objects transformation, especially time-dependent data (like
video and audio streams). After a short introduction, the chapter gives
fundamentals with broad references to the discussed field. The presented
way of modeling conversions including an abstract model, categories of
transformation and a processing model, leads to an application of the
graph-based model in the deployment considering model-specific issues,
236 Suchomski, Märcz, and Meyer-Wegener
functional correctness, scheduling, management of resources and admission

control. RETAVIC and memo.REAL are ongoing projects and the means of
evaluation of the models of conversion as well.
Introduction
Multimedia data are ubiquitous today. The formerly separated areas of music
recordings, radio, and television are all moving to digital formats, which in
essence means that all recordings are becoming data and can be stored and
manipulated as data. Standard data storage systems can be used for sound and
video, and both can be transmitted over computer networks. The multimedia
computer 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 are
anything but homogeneous. They are equipped with many different kinds of
displays and audio/video boards, not to speak of software. Hence, the same piece
of 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 the
other even increase this variety. The simplest way is to create copies in all known
formats, but this has many deficiencies, in particular when updates are neces-
sary. As an alternative, transformations are available. So it seems to be a useful
approach to keep media assets in a single copy and in a neutral format, and to
transform them on request into the format needed by a particular user. This is
even more useful in a large archive of media assets that is used by applications
on many different platforms, e.g., in an authoring or teaching scenario. Assume
for instance an archive of medical images and videos which must be kept without
any loss of information and thus will potentially be rather large. In lectures and
other presentations, however, a compressed version on a laptop computer will be
more appropriate. While some of the images and videos can be transformed
offline before the presentation, a discussion could create the need to access other
objects 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 of
media data that belong to a single medium, i.e., text, image, audio, or video. Of
course, media objects can be combined into multimedia objects (MMO), but their
handling must be clarified before. If a media object is available in one form and
is then requested in another, it must be transformed. In this chapter, the term
“conversion” will be used to denominate all forms of transformation on
multimedia data. Many conversion algorithms and programs are at hand, so they
should 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 conversions

need to be registered and classified.
Many conversions affect the quality of the media objects. In order to cope with
the resource limitations in the network and in the end-user devices, the quality
must often be reduced. It is important to describe the quality in a number of
characteristics like resolution and number of different colours. This allows to
find a balance between resource requirements on the one hand and perceived
quality on the other.
A specific problem arises with media objects that have inherent time, i.e., audio
and video. They are often referred to as streams. To create the requested form
before beginning the playout would lead to a significant latency that many users
do not accept. So the media object should be transformed during the playout,
which requires real-time processing. This imposes tough requirements on the
system that manages and delivers the media objects especially according to these
real-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. The
different forms of media objects — often defined by standards — must be well
understood to be handled properly. Next, after looking at other projects and
systems with similar goals, a model of conversion is defined. It allows for
classification 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-time
operating system.
Fundamentals
This section provides technical definitions in the discussed field. Obviously, the
meaning of media data and multimedia data should be defined first. Media data
are text, image (natural pictures, 2D and 3D graphic, 3D pictures), audio (natural
sounds including human voice, synthetic) and video (natural video, 2D and 3D
animation, 3D video). These data have a special digital representation when used
in computers that is called media object (MO). Multimedia data combines
more than one of mentioned media data and is represented by multimedia
objects (MMO’s).
While text and image are well known and reasonably simple to understand, the
emphasis here is on audio and video — called audio stream and video stream
respectively 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 with
a certain frequency. The characteristic distinguishing these streams from other
kind of data is the time constraint: The occurrence of the events (samples or
frames) is ordered, and the periods between them are constant. These charac-
teristics specify the continuous properties of a data stream (and justify why they
are called time-dependent data or timed data). Thus a media or multimedia object
with this time constraint is usually referred to as a timed MO or a timed MMO
respectively. Because continuous properties are almost always present in
MMO’s, the term timed is usually skipped (just as non-timed is skipped when
referring to MO’s which are not time-dependent, e.g., images). By the way, the
terms “timed” and “time-dependent” are often interchanged with the term
“continuous”.
In reality audio-video streams (as well as non-timed objects) often contain
additional information that describes the stream (object) itself. It is called meta
information, and it includes among others: stream properties (e.g., duration, bit
rate) and quality properties (such as resolution, frame or sample rate, etc.). Meta
information heavily depends on the data it describes, and because each type of
media object differs from the other (e.g., stream properties are not present in
non-timed objects), meta information contains different properties. Because an
MMO consists of more than one MO, it must first identify the MO’s it includes
and second it must store some arrangement information (additional properties in
meta 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 adopted
here from Gemmel et al. (1995): A quant is a portion of data that is treated as
one logical unit occurring at a given time. Representatives of quanta are a
sample, a frame, a text, or a combination of them (e.g., a GOP), etc. So, an
abstraction of the streams mentioned so far is a multimedia stream as a timed
data stream that consists of quanta.
In order to explain the transformation of MO’s and MMO’s in the following
sections, a logical description is needed. Some models of MO’s and MMO’s have
already been defined and discussed in the literature. It is common that each MO
has 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 relations
among the included MO’s, i.e., data on temporal/spatial relations.
Figure 1. Conversion process using multiple converters
converter graph
converter chain
converter converter converter
converter converter
Based on this model of MO’s and MMO’s, all components of the conversion
process will now be described. This process is depicted in Figure 1. A converter
applies a conversion function to an MMO. It may add, remove, or change content
as well as format and media type of any part. A chain of converters couples
a few converters in order to perform a conversion process with a more complex
functionality. A chain is a directed, one-path, acyclic graph, i.e., a sequential line
of converters, which passes MMO’s from one node only to the next. A graph
of converters consists of more than one connected converter chains. It is used
for instance, if an MMO must be split into MO’s in order to use media-specific
converters, i.e., converters working only with a given type and/or format of
media object.
Regarding timed (M)MO’s, this general model of conversion graphs must be
extended to reflect the timing. Instead of whole (M)MO’s, only quanta are
passed from one converter to the next in the chain, and that must be done at a
particular point in time, e.g., every 40 milliseconds for a video with 25 frames per
second. The main goal in modeling timed MO or MMO conversions is to define
such 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 in
2001 added jitter-constrained data streams which suit multimedia very well.
These streams consist of a time stream and a volume stream. The former is
defined 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 the
average 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 phase
to 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 by
the ITU-T as, “a set of qualities related to the collective behavior of one or more
objects” (ITU, 1997), i.e., as an assessment of a given service based on

characteristics. 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, communication
breaks), etc. (Vogel et al., 1995; Plagemann et al., 1995; Hafid and Bochmann,
1998). A more elaborate description and classification of QoS characteristics
can be found in ITU (1997).
In addition to QoS, it is useful to also take Quality of Data (QoD) and Quality
of Experience (QoE) into account, as presented in Figure 2. Starting with the
data 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 QoSSRV. The
network delivers the data to the client with QoSNET and influences as well the
overall quality. Additionally, the client side responsible for receiving and presen-
tation to the end user has its own QoSCLI. The end user finally perceives the
delivered data and feels some level of experience (QoE; also called subjective
QoS) that is most important in the whole process of multimedia delivery.
However, discussing all those aspects in more detail goes beyond this work. A
possibility 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 and
that the T(QoD) requested by the user must be provided. Then it is necessary
to control the quality during serving (or processing). In other words, only the
QoSSRV is of interest at this point.
In order to guarantee a certain QoS during a conversion process at the server
side, the whole process with all involved components (mostly converters) must
be scheduled in a real-time environment — with the possibility to control all parts
of the process precisely.
Figure 2. Qualities involved in the process of delivering MMO’s to the

client
End -Point of
Interest
NETWORK
CLIENT SERVER
QoSNET
QoE <= QoSCLI QoSSRV + T(QoD) QoD
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 usually
the support can neither meet all requirements nor handle all possible kinds of
media data. In order to better solve the problems associated with the large
diversity of formats, frameworks have been proposed, e.g., DirectShow, Java
Media Framework (JMF), CORBA A/V Streams, and MME Toolkit. But to our
knowledge, no published work develops a theory of multimedia transformations
in a broad range, i.e., considering the other solutions. Of course, the use of filters
in multimedia networking and mobile communication has been covered exten-
sively.
The pioneers, Pasquale et al. (1993) and Yeadon (1996), introduced some
generalizations 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 (Pasquale
et al., 1993). He classified filters into three groups regarding their functionality:
selective, transforming, and mixing. Yeadon (1996) presented five generic filter
mechanisms: hierarchical, frame-dropping, codec, splitting/mixing, and parsing.
He also proposed the QoS-Filtering Model which uses a few key objects to
constitute the overall architecture: sources, sinks, filtering entities, streams, and
agents. There are many other papers, e.g., Margaritidis and Polyzos (2000) and
Wittmann 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 about
multimedia transformations.
The Microsoft DirectX platform is an ideal example of media transformations in
an 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 components
working with different formats. These are specially designed “filters” (also
called media codecs). Filter graphs are built manually or automatically (Microsoft,
2002a). Unfortunately, DirectX is only available under one OS family, and it does
not support QoS or real-time, so use at the client side is limited.
The Java Media Framework (JMF) by Sun (Sun Microsystems, 1999) is a
competitor 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 of
processor 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 multimedia
software components called the presentation processing engine (PPE) frame-
work. PPE relies on a library of reusable modules implementing primitive
transformations (Posnak et al., 1996). They also proposed a mechanism for
composing processing pipelines from these modules.
Another work of some importance is VirtualMedia (Marder, 2000). It defines a
theory of multimedia metacomputing, i.e., a new approach to the management
and processing of multimedia data in web-based information systems. Marder
(2001) offered a solution for application independence of multimedia data by
introducing 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), the
author 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 (media
signatures as well as filter signatures). Unfortunately, an implementational proof
of concept is still missing.
Other work in the field of audio/video transformation relates to the concept of
video transcoding (Kan & Fan, 1998; Keesm et al., 1996; Morrison, 1997), a
method allowing for interoperability in heterogeneous networks by changing
format, resolution, and/or transmission rate. So, they refer to a converter as a
transcoder. 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 transformations
between different formats and networks topologies, i.e., different video stan-
dards like H.263 and MPEG-4. Dogan (2002) gives a good overview and
proposes a solution, but he covers only H.263 and MPEG-4, and he does not
address the problem of transformation between different standards.
Last, but not least, related work that must not be omitted is an open-source
program for audio/video transcoding (Östreich, 2003). It is called “transcode,”
and it is still under heavy development, but a stable version is available. The goal
is to produce a utility for video-stream processing that can be run from a Linux
text console. The approach uses raw (uncompressed) data between input and
output, i.e., transcoding is done by loading modules that are either responsible for
decoding and feeding transcode with raw video/audio streams (import modules),
or for encoding the frames (export modules). Up to now, the tool supports many
popular 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 are
ready 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 of
MMO’s that work in real-time if necessary and guarantee QoS. An architecture
based on conversion graphs is defined that includes an abstract model of
converters, 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 basic
converter model. It must describe the conversion itself, the transport of data
during the conversion process, and the QoS guarantees. Due to the high diversity
and complexity of multimedia conversions, existing converters are used. In a
case of timed MMO’s however, they must be adjusted to provide real-time and
QoS.
In general a converter can be regarded as a black box. It converts incoming
media objects moi, 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 not
match. In many cases, n and m are less than three.
The functionality of the conversion is described by a set of conversion
functions C Ck : mo'k = CCk (mo1, mo2, ..., mon). Generally these functions consist
of three parts. First, each function maps the parameters of the incoming
stream(s) to those of its outgoing stream. For timed MO’s, these parameters are
defined by the model of jitter-constrained periodic streams and include average
quanta size with jitter (for volume streams) or average event distance with jitter
Figure 3. Black-box view of a converter
mo1 mo'1
mo2 mo'2
converter
mon mo'm
(for time streams). Second, the functions describe the format conversions FCk :
f 'k = FCk(f1, f2, ..., fn) which map the incoming media-object format description(s)
(f i = 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, in
contrast with the others parts which must be defined during a converter analysis
based on a given converter.
Categories of Transformations
To organize the set of all converters, their conversion functions are grouped in
categories with individual features (Figure 4). The first category is that of
media-type changers. Converters in this category transform the media type of
one of the incoming media objects (moi.type) into another media type for an
outgoing media object (mo’k.type), where ∃i,k: moi.type ‘≠mo’k.type and fi ‘≠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. The
content, however, should remain the same — which is naive in many real
applications, but it is the goal of this operation. A typical example is that the media
type must be changed due to hardware limitations (no audio device), or that
clients are handicapped people. Hence, speech recognition is used to turn audio
into text, and “readers” do it the other way around.
Converters of the second category do not change the media type, but the format
of 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
lossless format change

lossy format change
media type
format content changers
changers
changers
lossy media type change

lossless media type change
some formats require compression and thus a loss of information. The content
of mo1 and mo2 is considered to be the same, if mo 1 can be transformed into mo2
and vice versa without using external knowledge or information. So format
changers are split into two subcategories, namely, lossless and lossy. Lossless
changers have an inverse conversion function C’hC with ∀i∃h : moi = C’hC (C1C(mo1,
mo2, ..., mon), C2C(...), ..., CmC (...)). For lossy conversions, the format change implies
a content loss which must be known to the clients and must be acceptable for
them. More details can be found in Marder (2002). Examples of this category are
the typical encoders and decoders, many of which compress media objects (e.g.,
DivX, MPEG, H.26x, RLE). A format change can be caused by hardware
limitations (channel coding, colour reduction, down-sampling) or by user demand
(resizing).
Finally, the third category of converters are those which explicitly change the
content of a media object, while the format is not affected: ∃i,k: moi.type =
mo’k.type and fi = f’k and moi.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 occur
because of resource limitations. In order to guarantee a certain QoS, uncon-
trolled quanta loss must be avoided. However, a special converter can be
scheduled as a lossy converter with a controlled (statistical) quanta loss. This
often means lower resource requirements for the whole converter graph,
compared to the guarantee of no quanta loss. Normally these lower resource
requirements are preferred, but the decision between lossless and lossy delivery
must be made by the user (accepting the quanta loss). This kind of content
change in particular makes sense, if the quanta loss is not even noticed by the
user, 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) from
its input stream, processes these quanta and writes a sequence of quanta into its
output 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, an
output, and a conversion (or processing) part. The conversion part is treated as
a black box again. These three parts are organized in the main loop, which is the
characteristic 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 the
last quant (end of stream) and writing the associated output. For timed MO’s, the
Figure 5. Main processing loop of a converter
converter begin
input quanta from

stream(s)
main loop
process quanta
output pro cessed

quanta
end
main loop operates periodically, so there is a time limit for the processing of each
quant. Since size and contents of the quanta may differ significantly, the
processing time varies. Some quanta are processed completely before the end
of the period, while others need more time than available. It has been observed
that the maximum cumulative deviation from the end of the period is much more
useful in calculating the effects than the distribution of processing times. This is
described by the jitter-constrained periodic time streams that have already been
introduced.
While they model the time jitter and thus the maximum lateness, it is equally
important to handle the deviation of transferred data volumes, e.g., for the
calculation of buffer sizes. This is described as a jitter-constrained periodic
volume stream. The jitter in volume streams results from different quant types
and compression levels. In summary, each converter instance must have a
description of all incoming media objects moi and all outgoing media objects mo’k
as jitter-constrained periodic time and volume streams. Please note that these
descriptions are data-dependent, i.e., the streams are different for different
media objects. It is then necessary to find mappings from the description of the
input streams to the description of the output streams.
To achieve that, the use of resources by the converter must be taken into
account. All resources are managed by the underlying operating system.
Resource usage can again be characterized by jitter-constrained periodic time
and volume streams. Processing the quanta is done in periods with jitter, hence
the use of resources is also periodical (in general with a shorter period), and the
volume of data handled varies around an average size (which may be smaller that
the average quant size), so the same kind of model can be used.
Deployment of the Graph-Based Model
Model-Specific Issues
The section Fundamentals has introduced the notion of conversion chains or

graphs, respectively, which allow for the construction of a large set of transfor-
mations from a given set of converters. The descriptions of all the converters
involved in such a graph must be combined to handle the full complexity of
conversions, especially the calculation of the resource usage and the scheduling.
To prevent the accumulation of jitter over the whole conversion process, the
converters are coupled by buffers. This means that converters write their
outgoing quanta into dedicated buffers, from which they can be read by
subsequent converters (Figure 6).
Because some conversions can be performed in arbitrary order, usually more
than one conversion graph can be built for the same transformation task. For
example, 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 QoS
guarantees during the streaming and conversion process.
Building Functionally Correct Conversion Graphs
Before the timing constraints of a conversion can be taken into account, it is

important to decide about the logical structure. There are three ways of building
functionally 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

buffer buffer
mpeg-video
to DivX buffer
demux: mux:
mpeg-sys asf
mpeg-audio
disk buffer to wma
network
buffer buffer
The first assumes that converters are coupled by interfaces. It means that the
format of the output data of one converter is accepted as input by the consecutive
converter. In other words, the interfaces of output and input (metadata of
quanta) must be the same (or at least must allow for the creation of a connection
that makes sense). This means that the input interface of the subsequent
converter includes or extends the output interface specification of the previous
converter. For instance, if the first converter produces quanta in YCrCb colour
format, the second converter must accept this format (it may accept other
formats as well).
The second method is based on the functions of the converters. Each converter
performs a specific task. The managing application stores information on
functions of available converters and on functionally correct chains (e.g., colour
conversion, resizing). Based on this, converters that have the requested function-
ality are chosen to build a chain. For example, display on screen (RGB colour
space) with resolution and colour space different from the source is requested.
So, converters doing resizing and converters doing colour conversion are chosen
in order to build a conversion graph for this task.
These two methods both have their limitations. In particular, they might lead to
a logically correct chain based on interfaces that does not provide the requested
functionality. Similarly, a logically correct chain based on functionalities may
result in which the interfaces do not match each other (so no quant can be passed
from one converter to the next, because that would require a compatible type of
quant). So the two methods can only be applied with some limitations. In order
to be on the safe side, a third and most reasonable method is defined. It combines
both methods and builds a chain using the functions as well as the interfaces of
the converters. The result is a logically correct chain in all respects, i.e., function
and data correctness are provided. The way to build up correct conversion
graphs respecting both functionality and interfaces is given by a couple of
optimisation algorithms, e.g., Greedy, Simulated Annealing or Evolutionary
Algorithms (Michalewicz & Fogel, 2000). In Marder (2002), which was already
described as related work, signatures for media objects and converters (alias
filters) were introduced. Based on these signatures, a set of functionally correct
conversion graphs can be found with the aid of optimisation algorithms. The work
also proposes information how to use these algorithms. Additionally, converter-
graph transformations can be used for further optimisations.
Scheduling, Resource Management, and Admission

Control
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 are
dropped, or that the jitter in frame presentation or recording must not exceed a
given maximum.
Here, a real-time environment with an efficient resource scheduling is needed
that 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 multimedia
transformation is to provide the scheduling parameters to the RTOS and to do an
admission 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 not
depend on time (e.g., memory), and a dynamic part referring to active resources
which depends on time (e.g., CPU, DMA, busses). While the static part is
described by the volume required over the whole transformation process, the
dynamic part is treated as a bandwidth (resource use per second). “Bandwidth”
here means the number of operations or the amount of data that must be
processed or transmitted in the time interval between quant arrival (before
processing) and quant departure (after processing). Processing a quant must not
affect the resources needed for the next quant. Hence, the time interval between
quant arrival and quant departure must be long enough to handle all possible
operations on a quant. This can be determined by worst-case analysis or —
considering the high jitter in execution times of quant processing — by mean
values plus a bounded jitter. Both worst-case and mean-plus-jitter can be
described as jitter-constrained periodic streams.
Now, a significant part of the scheduling is the description of the converters
involved, including resource requirements as jitter-constrained periodic streams,
which must be done separately for each converter. This description is easy to
find for converters without content dependencies, i.e., the resource require-
ments can be derived directly from the parameters of the input formats fi =
moi.format. Otherwise the resource requirements of a converter depend on the
media object itself, i.e., the format fi plus the content moi.content. At the moment,
these content-dependent resource requirements are merged into the jitter value
of the jitter-constrained periodic streams. The calculation of an accurate jitter
value from format fi and some characteristic content-description parameters
(e.g., motion complexity) is yet to be developed.
For each input object moi, the function R : s = R (mo ) yields the dynamic
C
r r
C
r i
resource requirements of a converter in the form of a jitter-constrained volume

stream( s r ) for each resource r. Additionally, s r =Sr describes the average
volume of the stream, and frate is the mean quant rate, which is defined by user
requirement (e.g., quant playout rate at the end of the chain). Then the required
bandwidth on resource r is given by QCr = R r (moi)*frate. The static

C
dynamic
resource requirements are unchanged over the lifetime, independent of quant
rate, and are given directly by QCr = RCr (moi).
static
The buffers needed to couple the converters also require resources, i.e., the
buffer size in the resource memory. They can be calculated with the aid of the
jitter-constrained periodic streams (Hamann et al., 2001).
The sum of all requirements must not exceed the maximum system bandwidth on
each resource. If the maximum system capacity for a resource r is given by Cr,
then the following condition must always hold:
 
∀r :  ∑ Q Cr ≤ C r  .
C running 
So, a converter graph is only schedulable, if:
 
∀r :  ∑ Q Cr + ∑ Q Cr ≤ C r  ,
 CrunningC new chain 
which means that the additional requirements of the new converter chain must
be less or equal to the available resources, or the sum of all chains, including this
one, must be less than or equal to the system capacity. In some situations (with
dependencies 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 have
followed different development directions such as multimedia transformations
on 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 has
provided the background for the investigation of conversion. Two ongoing
projects, memo.REAL (Märcz, 2003) and RETAVIC (Suchomski, 2003), are the
means to evaluate the models of conversion. An overview is given in Figure 7.
Figure 7. Overview of ongoing projects

converters media data
analysis
benchmarking
memo.REAL
models

(data,
conversion,
resources)

jitter-
adoption
constrained
to realtime
periodic
& QoS stream
(ratecontr.) scheduling
& admission
(bandwidth)
RTOS
4-6)81+ (DROPS)
runtime
(CSI)
The tasks covered by each of the projects are marked in grey, and the
surrounding ellipses represent exterior factors.
The first step is analysis and benchmarking of existing converters with available
media data. The outcome is used in a modeling phase that covers three different
aspects: data, conversion, and resource models (by applying the theory of jitter-
constrained periodic streams). The next step is to develop scheduling and
admission control methods that are strongly influenced by RTOS. In these
projects, DROPS (Härtig et al., 1998) is used. The execution of a conversion
process is also placed in an RTOS, which serves as a fully-controllable run-time
environment. To enable a converter to run in an RTOS, it has to be adapted to
this environment, i.e., it has to be extended to use the component streaming
interface (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: a
given non-real-time converter, the analysis of behaviour, and the description in
terms 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 study
projects) have already been finished. They have contributed to RETAVIC and
memo.REAL by producing usable outcome that proves the theoretical ideas.
Namely, a benchmark for AV compression, a bit-rate control algorithm for an
MPEG-4-based codec extending it with real-time capabilities (Militzer et al.,

2003), a format description of media data (Feidler, 2003), bandwidth models of
conversion and resources for scheduling and buffer optimization, and a compo-
nent streaming interface (Schmidt et al., 2003) have been developed. Currently
the focus is on making the whole system complete in order to show a working
example.
Conclusions
While the overall subject of multimedia conversion is very complex and thus still
includes unsolved problems, some initial solutions are available. It is common
knowledge that converters should be organized in chains or graphs instead of
building new converters for each task. In order to make such a conversion graph
executable in a real-time environment, models are needed for the different
components involved. This includes the data being processed. It consists of
quanta which are manipulated and transferred in periods. The converters used
must be described by their functionality, i.e., the mapping of input to output, as
well as the resource requirements. The model of jitter-constrained periodic
streams turned out to be very useful here, for the timing and for the data volumes
handled. This model is rather simple in that it only needs four parameters per
stream. Still it allows for a variety of derivations needed in this context. Based
on such a description, initial scheduling of conversion graphs in a real-time
environment becomes possible. A simple bandwidth model allows us to prevent
the over-use of resources.
Much more work is required. The models need to be refined. In parallel, a system
is being built to evaluate the decisions made on their basis. This will significantly
influence the work on the models, because their simplicity is an advantage that
should not be given up without reason.
References
Abdelzaher, T.F. & Shin, K.G. (1999). QoS Provisioning with qContracts in Web
and Multimedia Servers. Proceedings of the 20th IEEE Real-Time
Systems Symposium, Phoenix, AZ, USA, December 1-3, (pp. 44–53). Los
Alamitos, CA: IEEE Computer Society.
Battista, S., Casalino, F. & Lande, C. (1999). MPEG-4: A Multimedia Standard
for 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 Quality
of 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 Constrained
Periodic Streams. Proceedings of the Fifth International Symposium on
Modelling, Analysis and Simulation of Computer and Telecommunica-
tion Systems, Haifa, Israel, January 12-15. Los Alamitos, CA: IEEE
Computer Society.
Hamann, C.J., Märcz, A. & Meyer-Wegener, K. (2001). Buffer Optimization
in Realtime Media Servers Using Jitter-constrained Periodic Streams
(Technical Report SFB 358 - G3 - 01/2001). Dresden, DE: Technical
University.
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 Minimum
Buffer Requirement for Compressed MPEG-2 Bitstream. Signal Pro-
cessing, 67(2), 223-235.
Keesm, G., Hellinghuizen, R., Hoeksema, F. & Heideman, G. (1996). Transcoding
of 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. Los
Alamitos, CA: IEEE Computer Society.
Marder, U. (2000). VirtualMedia: Making Multimedia Database Systems Fit for
World-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 multimedialen
Informationssytemen. Ph.D. thesis. Kaiserslautern, DE: University.
Margaritidis, M. & Polyzos, G. (2000). On the Application of Continuous Media
Filters over Wireless Networks. Proceedings of IEEE International
Conference 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 the
WWW: 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. Retrieved
February 10, 2002, from the WWW: MSDN Library, DirectX 8.1 C++
documentation.
Microsoft Corp. (2002b). Introducing DirectShow for Automotive. Retrieved
February 10, 2002 from the WWW: MSDN Library, Mobil and Embedded
Development documentation.
Militzer, M., Suchomski, M. & Meyer-Wegener, K. (2003). Improved p-domain
Rate Control and Perceived Quality Optimization for MPEG-4 Real-Time
Video 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 Transactions
on 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 in
Continuous Media Networks. In D. Shepherd, G.S. Blair, G. Coulson, N.
Davies & F. Garcia (Eds.), Network and Operating System Support for
Digital Audio and Video, Fourth International Workshop, NOSSDAV
’93, (pp. 259-268).
Plagemann, T., Saethre, K.A. & Goebel, V. (1995). Application Requirements
and QoS Negotiation in Multimedia Systems. Proceedings of Second
Workshop on Protocols for Multimedia Systems (PROMS’95), Octo-
ber. Salzburg, Austria.
Posnak, E.J., Lavender, R.G. & Vin, H.M. (1997). An Adaptive Framework for
Developing Multimedia Software Components. Communications of the
ACM, 40(10), 43-47.
Posnak, E.J., Vin, H.M. & Lavender, R.G. (1996). Presentation Processing
Support for Adaptive Multimedia Applications. In M. Freeman, P. Jardetzky
& H.M. Vin (Eds.), Proceedings of SPIE Vol. 2667 [Multimedia
Computing and Networking 1996, San Jose, CA, USA, January 29-31,
1996, (pp. 234-245).
QNX. (2001). QNX Neutrino RTOS (version 6.1). QNX Software Systems
Ltd.
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 the
Ninth International Conference on Distributed Multimedia Systems,
Miami, FL, USA, September 24-26.
Suchomski, M. (2003). The RETAVIC Project. Retrieved July 25, 2003, from
the 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 Video
Metadata Model supporting Personalization & Recommendation in Video-
based Services. Proceedings of the First International Workshop on
Multimedia Data and Document Engineering (MDDE 2001).
Wittmann, R. & Zitterbart, M. (1997). Towards Support for Heterogeneous
Multimedia Communications. Proceedings of 6th IEEE Workshop on
Future 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. Linux

Journal.
Vogel, A., Kerherve, B., Bochmann, G. & Gecsei, J. (1995). Distributed
Multimedia and QoS: A Survey. Proceedings of IEEE Multimedia, 2(2),
10-19.
Coherence in Data Schema Transformations 257
Chapter XII
Coherence in
Data 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 Conceptual

Schema in its operational life cycle phase, introducing Semantic Change
Patterns as a novel notion in Conceptual Schema evolution. Each pattern
outlines a coherent way to accommodate new information needs, both on
the level of the existing data structure, and on the level of the data instances
(data coercion). An initial catalogue of Semantic Change Patterns is
proposed, based on actual schema changes observed in business cases. The
catalogue exposes some of the schema evolution expertise that can be found
in maintenance practice.
258 Wedemeijer
Introduction
Evolving Conceptual Schemas
According to the classic 3-Schema Architecture (ANSI/X3/Sparc, 1975), the

Conceptual Schema captures and defines the semantics of, and the relationships
between, 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 used
will evolve in order to meet the ever-changing user requirements (Lehman &
Belady, 1978). As the operational information system evolves, its Conceptual
Schema will be subject to change. To paraphrase Lehman and Belady, it is our
experience, and the motivation of this chapter, that any Conceptual Schema that
is used can and will evolve over time. In other words, a Conceptual Schema, once
designed, may claim to be stable in its operational life, but it cannot be assumed
to 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” to
designate the unique schema that captures and defines the semantics and
relationships of all the data handled by the operational information system.
It is remarkable that contemporary modeling theories and design practices
regarding Conceptual Schemas tend to overlook evolution of the operational CS
in the operational life cycle phase of information systems. Most approaches
seem to be restricted to the system development phase only, relying on a single
design effort to deliver a once-and-for-all CS. However, this fails to recognize
the 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. This
notion regarding CS evolution has not been recognized before in the literature,
but we have found it to be embraced by business practitioners engaged in the
area of schema maintenance.
Once the need for change in the data schema has emerged, an appropriate
pattern can be selected and applied to the problem at hand. The pattern outlines
how new information needs can be accommodated on the level of existing data
structure and on the level of data instances (data coercion). As such, the patterns
comprise some of the know-how experience from maintenance, and make that
knowledge available to data administrators and researchers.
Objectives of this chapter are to introduce the notion of Semantic Change
Patterns, to argue its relevance in Conceptual Schema evolution, and to propose
an initial catalogue of patterns. We believe that the use of Semantic Change
Patterns can and will be instrumental in achieving the quality and consistency that
engineers 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 abstract

model that completely captures the relevant semantics of the “Universe of
Discourse” (abbreviated UoD), being that part of the real world that the
information system is about (Figure 1).
At the same time, the CS is the unique intermediary schema between on the one
hand, schemas that expostulate how data is queried and transacted by user
applications, and, on the other hand, the data storage schema for files and
databases. The former view of the data is usually referred to as External
Schemas; the view of data used in Database Management Systems is commonly
called the Internal Schema. However, we will not discuss this aspect of the CS.
In addition, the implications of our semantic change patterns for External
Schema or Internal Schema maintenance are beyond the scope of this chapter.
Figure 1. Conceptual Schema as an abstract model of the Universe of

Discourse
ch3: 3SA (full)

"reality"
Universe of Discourse
perceived reality
"Best" Model
engineering
abstractions
Limited Models
conceptual realm:
Symbolic Models
Conceptual
Schema
External data-realm: Internal

Schemas Schemas
Dependent 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 that
would assume perfect anticipation: the CS design effort would suffice to cope
with 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 viewpoint
of UoD and semantics as perceived by the user community. This notion of
semantics is lacking in all of the above approaches.
We therefore need to introduce the notion of semantic change that we define
to be any change in the operational Conceptual Schema that validly reflects
change 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 changes
exclusively. Rather, the definition guides us to distinguish between semantic and
non-semantic changes, by looking for the corresponding change drivers in the
real world. The definition also allows for a semantic change to affect multiple
constructs of the CS at once or, the other way round, a single CS construct to
be affected by several semantic changes. Finally, notice how the definition
allows for delay (i.e., a CS change may be postponed) and anticipation (i.e., a CS
change 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 information

structure 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 an
operational information system’s CS constitutes a semantic change as we
understand it.
For one, an abundance of data model theories exists for CS specification, such
as the relational data model, E-R and Extended E-R models, UML class
diagrams, 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 their
underlying data model theories (McBrien & Poulovassilis, 1998). Such theoretic
differences do not derive from the outside world and do not reflect evolution of
environment in any way (Bézevin, 2000). Even if the data model theory is firmly
fixed, two CSs modeling the same UoD may differ. This is because many data
model theories are “rich”, i.e., they provide alternative ways to capture and
model a particular real-world feature (Saiedian, 1997; Knapp, 1998). Hence, a
real-world feature can be modeled first in one way and later in another, even if
there is no change in the real world. Again, such differences, commonly referred
to as semantic heterogeneity or discrepancy (Kent, 1991; Tseng, Chiang &
Yang, 1998), do not derive from the outside world and do not reflect evolution
of environment in any way.
Regrettably, standard data model theories such as E-R and UML come in many
variants 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, we
cannot rely on standard data model theories. Instead, we have to employ a
semantic data model theory that is “essential” as opposed to “rich” to avoid the
kinds of theoretic differences and heterogeneities as explained above. Main
features 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 of
the CS life cycle. Several authors have studied the notion of design primitives
(Batini, Ceri & Navathe, 1992; Fernandez & Yuan, 2000; Hartmann, 2000). In
CS design, an abstracted model is created and gradually adjusted and improved
to capture the semantics of the UoD. However, our interest lies with the
operational CS. We regard design adjustments to be part of the schema
development phase, and do not consider it as true CS evolution. The amount and
characteristics of adjustments in the design phase are a hallmark of the
designer’s ability and experience in modeling, rather than an expression of real
changes 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 description

of the database contents” (Elmasri & Navathe, 2000). Indeed, contemporary
theories and design practices for conceptual data modeling concentrate on a
single 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 need
for 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 many
changes 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 turbulent
environment. Hence, we should study the actual changes as they occur in the
CSs of operational information systems, and use that understanding to improve
future CS designs.
Change Driven from the Real World
First principles say that the CS ought to change only if the information structure
of the UoD changes. Literature has it that major business events like mergers,
acquisitions and diversifications are the change drivers that cause change in the
CS (ANSI/X3/Sparc, 1975; Galliers, 1993; Orna, 1999). In theory, CS changes
can only be justified by true structural changes in the UoD. However, we feel
that 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 in
modeling guidelines, may present engineers with legitimate opportunities to
change the CS. Such CS changes may be unjustified, but in practice, they are
quite common. The same principles also suggest that the timing of a CS change
must coincide with the change driver. However, it is our experience that some
CS changes may be postponed for quite some time, while other changes may
even precede the change in the UoD. The currency conversion to Euro is an
example where CSs have been prepared well in advance of an upcoming change
in the real world.
Change of a Single Construct at a Time
Formally, every CS is composed of elementary constructs that the data model

theory provides. Hence, change in the CS can only be effected by changing this
composition. For example, one can add a single “entity” construct into a CS. One
may surmise that a complete understanding of CS changes is achieved by
analyzing the possible changes of constructs in the data model theory, a research
approach referred to as taxonomy (Roddick, Craske & Richards, 1993).
However, Brèche (1996) already pointed out the gap between “schema changes
by means of primitives closely related to the respective data model,” sometimes
referred 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 some
significance in the CS, and therefore the new entity will always be related to
something else in the schema. We feel that an understanding of syntactic
changes only is inadequate (Liu, Chryssanthis & Chang, 1994). The shortcom-
ings are in both a lack of real-world semantics, and in ignoring the impact of
change.
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 of
data” (Goralwalla, Szafron, Tamer, Öszu & Peters, 1998). Lossless schema
transformations have been extensively studied (De Troyer, 1993; Bommel,
1995). However, CS evolution in an operational business environment need
generally not be lossless. Loss of data can even be intentional, for instance when
an obsolete data construct is eliminated from the CS.
Change is the Mere Application of a Pre-Defined

Schema-Evolution Operator
Some database management systems provide evolution operators that will

perform data conversions when the Internal Schema is changed. However, such
conversions 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 the
responsibility of the maintenance engineer to select suitable operators, tailor
these to the problem at hand, and execute them in the appropriate order. The
database evolution operators reduce the time required to accommodate the CS
change in all data and components of the information system, but they are not
founded on CS semantics or real-world understanding that still lies with the
engineer.
264 Wedemeijer
Change is Due to Schema Merging
Corporations generally use more than one information system. If there is an

overlap in their respective Universes of Discourse, then an integrated CS is
called for to ensure a valid, complete and consistent model of the combined
universes (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 CS
operation. Some authors even state that: “empirical research has found more
evidence 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 the
CS design phase. However, schema changes in the “systems development
phase” are fundamentally different from the kinds of changes that are necessary
in the operational phase. Therefore, it cannot be assumed that such design
approaches will suit the needs of maintenance engineers. Indeed, to accommo-
date a change in a running information system and database calls for different
techniques than to change a system being developed.
Design approaches fail to systematically incorporate the knowledge of actual
changes as observed in operational CSs. The customary design approach is to
create 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 life
cycle.
Theoretic approaches to schema-evolution and change taxonomies are primarily
concerned with the potential for change that the data model theory may bring
about in the CS. They do not yield insight into the types of actual changes in
operational CSs or their complications.
CS Change in Business
Changing an operational CS is no small matter. The desired change ought to be

well understood before it is committed. The consequences of changes must be
carefully considered, not only for the stored data but for other components of the
information system as well: existing business procedures, applications and user
interfaces, user training, etc. It is no surprise that engineers try to keep the impact
of change as small as possible. In effect, they aim for an adapted CS that is an
adequate model of the new UoD, but at the same time as close to the old CS as
possible. Indeed, the major difference between CS change in the operational
phase versus design is the need for data coercion. In design, no operational data
has 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 services

and to avoid operational problems in data handling. Therefore, CS change
requests are carefully weighed against other pressing business needs (Orna,
1999). Only if the change is unavoidable will valuable business resources be
allocated, and even then reluctantly, i.e., compatibility is demanded in order to
reduce 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 coerced
in advance of an upcoming CS change, or that evade data conversions
altogether.
System Constraints on CS Change
Although the 3-Schema Architecture makes a clear distinction between the

structural level of the CS and the level of data instances, it is impossible to change
one in complete isolation of the other. Any change in an operational CS must be
conducted in such a way that the correlation between these two levels is
safeguarded (Ewald & Orlowska, 1993; Peters, Tamer & Öszu, 1997). In
addition, the engineer must determine what other components of the running
information system may be impacted by the change. Again, changes in the CS
must well be coordinated with changes in the other components to safeguard the
correct operation of the system.
266 Wedemeijer
Solution: Semantic Change Pattern as a

Tool
Notion of Semantic Change Pattern
It is our experience that many CS modifications are not new and innovative, but
appear to be modeled on some basic “model to be copied” whenever appropriate.
A pattern, as commonly understood in information systems engineering, is an
abstracted, generalized solution that solves a range of problems with shared
characteristics. Gamma, Helm, Johnson and Vlissides (1995) have it that: “each
pattern describes a problem (..), and then describes the core of the solution to that
problem, in such a way that you can use this solution a million times over, without
doing it the same way twice.”
We understand the notion of semantic change pattern to be: any change in the
operational 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, the
patterns described in current literature concern design only. The semantic
change 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 either
External 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 be
found in the literature (McLeod, 1988; Brèche, 1996). Their examples however
are contrived by theoretical arguments, and not by abstracting actual CS changes
observed in practice. Indeed, viable patterns can only be identified in their natural
habitat, i.e., the running business. We therefore conducted a series of case
studies, tracking a number of operational CSs and studying their changes in
entities and references over time. For the sake of feasibility, changes in attributes
and constraints were ignored.
Catalogue of Semantic Change Patterns
In the case studies, we found 12 semantic change patterns to occur on at least

three occasions. This constitutes a small catalogue of semantic change patterns
that we will now describe. To fully understand a semantic change pattern, we
need 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 from
elementary schema changes, and
• the impact of change on stored data and on other components of the
information system.
A few patterns are outlined in some detail, but due to space limitations, we cannot
describe all patterns in full detail. Instead, we simply show the patterns as a set
of diagrams: before and after the change. We add a brief description to convey
the essence of the pattern, so that the reader will be able to apply the change
patterns in a practical situation by adjusting the appropriate pattern to meet the
needs at hand. We express the diagrams in a variant of the Entity-Relationship
data model theory, but this does not limit the validity of the patterns. The
semantics 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 clearly
demonstrates 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 schema
integration: the real world is unaffected, but user perception thereof is
extended and users require that extra information be captured that extends
on data captured about existing real-world objects.
• The pattern syntax is to insert a new entity, and add a reference to an
existing entity that now becomes an “owner” entity. A new specialization
is induced in the existing entity, i.e., the set of instances that is being
referred to by the new member entity. Data manipulation routines must be
adjusted in order to ensure referential integrity when owner instances are
updated or deleted.
• The pattern comes with little or no complications, and no conversion of
stored data is needed.
268 Wedemeijer
Figure 2. Append an entity
Superimpose an Entity
This semantic change pattern resembles the previous one syntactically. It is

another demonstration of schema extensibility, but more rarely seen.
• The need to change emerges if a new way of grouping and organizing
existing objects is perceived. In other words, users regard an existing entity
to be dependent on something new, something not yet captured in the CS.
Whereas the previous “append” pattern adds details, the importance of this
pattern is to add new structural elements. This pattern is likely to be used
when the UoD is expanded, and particularly in schema merging.
• Like the previous pattern, the syntax is to insert a new entity, and to add a
reference. 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 would
be larger if the new reference is defined as compulsory: all stored instances
must be updated to include correct references. It becomes even more
extensive if the new reference is incorporated into the primary key: this will
set off a cascade of foreign-key changes in all dependent entities.
Figure 3. Superimpose an entity
Figure 4. Move attributes out into a new entity
Move Attributes Into a New Entity
In design, the creation of a new entity from a coherent set of attributes is a

common normalization procedure. The same change in maintenance may be
called “belated normalization”. While this semantic change pattern resembles
the previous ones in syntax, the difference is that there is no extension of the
UoD, but only a change in its information structure.
Connect by Reference
This semantic change pattern exactly matches an elementary change in any

taxonomy, i.e., to add a single construct to the CS. The amount of real-world
knowledge captured in the CS is extended, but only marginally so. The diagram
shows the insertion of an optional reference, i.e., the connection is between
specializations. 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, the
benefit of having the reference explicitly represented in the CS is rarely
considered worthwhile.
Figure 5. Connect by reference
270 Wedemeijer
Figure 6. Impose a reflexive reference
reflexive
Impose a Reflexive Reference
This semantic change pattern resembles the connect-by-reference pattern, but

it differs in semantics and applicability. Self-referring links between instances
are often known and noted by users even if the designers have not included the
reflexive reference in their CS designs. Therefore, core entities should be
examined for the existence of a reflexive relationship.
Connect by Intersection
We borrow our terminology from the concept of “intersection-record” in

classical networked databases. Such records served a rather technical purpose
of establishing a many-to-many link in the database. This pattern is named after
it because of the striking similarity in appearance. Notice how this pattern again
resembles the Append-an-entity pattern syntactically, while differing in seman-
tics. The diagram shows an interesting variant of the pattern where not one, but
two “intersection entities” are inserted to constitute the reference.
Figure 7. Connect by intersection
Figure 8. Eliminate a dependent entity (cluster)
Eliminate a Dependent Entity (Cluster)
On the CS level, elimination is the reversal of the Append pattern, however, not
on the data level. There are numerous reasons why information in the CS may
turn obsolete, but obsolescence alone does not constitute a need to change the
CS. Indeed, eliminations are rarely committed as soon as possible, but are often
postponed 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 a

pattern where it is redirected towards an owner entity, i.e., it moves higher in the
CS 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. It
is 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 users
feel that the current way of modeling a reference can be simplified.
Figure 9. Redirect a reference to owner entity
272 Wedemeijer
Figure 10. Extend entity intent
Extend Entity Intent
Entity intent is its definition, i.e., the accurate description of relevant real world
objects in the UoD that it is supposed to record. To extend the intent is to allow
more real world objects to be recorded by the entity. For example, a “car” entity
may be extended to also record motorcycles.
This pattern is a clear illustration of extensibility. The semantic change is not very
evident in the CS diagram. The extension is often left implicit, or it may even go
unnoticed. Nonetheless, the CS is changed and the extended entity will structur-
ally have more instances on record. Also, instances may be kept on record that
were 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. The
diagram shows an example where two entities are restricted at the same time.
The reference between the entities is restricted accordingly.
Figure 11. Restrict entity intent
Figure 12. Promote a specialization
Promote a Specialization
A particular concept is perceived to be so much more important and different

from similar ones that users want to have it explicitly modeled in the CS. The
former generalization does not become invalid, it just becomes less important in
the CS. However, the generalization may completely disappear from the CS if
this pattern is applied repeatedly. Users perceive the new CS as a better model
because it is more explicit, easier to understand. In particular, access to the data
is easier, as users no longer need to sieve out the irrelevant information of other
instances.
Syntactically, the pattern resembles a “horizontal fragmentation” or “table
divide” operator. It takes a generalized entity, divides it into two (or perhaps
more) independent entities, and relocates data instances to exactly one of the
new entities.
Relax a Reference
Relaxation comes in two flavors: either a 1:1 reference is relaxed to N:1

cardinality, or an N:1 reference is relaxed to optional. The diagram shows the
Figure 13. Relax a reference
274 Wedemeijer
latter variant. This semantic change pattern is not very frequent. The few
examples that we observed in our cases are all associated with minor CS design
flaws that emerged in operation.
Discussion
Validity
Two arguments underpin the validity of the described patterns. First, these
patterns are based on real changes in operational Conceptual Schemas seen to
evolve in the business environment. We extracted the catalogue of 12 semantic
change patterns from a series of case studies, where we established that this
dozen patterns accounts for over 75% of the observed semantic changes.
Evidently, these patterns embody proven practices that can be encountered in the
business environment.
Second, we have found that practitioners readily recognize these patterns, and
we take this as another mark that the notion of Semantic Change Pattern has
practical value and significance. In fact, we are convinced that the listed patterns
are already known and used in practice, but have failed to be recognized as an
important tool for maintenance.
Absent Patterns
We remind the reader that we excluded attributes and constraints from our
investigations, so no change patterns involving attributes and constraints are to
be expected. For entities and references however, certain patterns may have
been 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:1
cardinality,
• Generalize entities into one unified entity, in particular to enfold a hierarchic
stack 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 we
expect to see these patterns in the first place? Expectations are guided by what
is advocated as good design practices. Please bear in mind that most literature
focuses on the design phase, and it cannot be assumed that patterns intended for
design will meet the needs of maintenance engineers working in a turbulent
business environment. We already mentioned how the conservative tendency to
safeguard current investments in running information systems generally pre-
vents extensive restructuring of the CS. We consider this call for compatibility
to be a major reason why theoretically attractive patterns like generalization and
reification are unfit for maintenance. A good pattern for design is unacceptable
in 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 engineer

with a proven way to resolve a need for change in the CS, whatever the reason
for change, as we did not restrict our search for semantic change patterns to
justified changes only. Still, the patterns have yet to find their way into the
common body of engineering knowledge. The notion of semantic change
patterns is novel and as yet we cannot show an example where a pattern was
selected and named explicitly before being applied. However, we believe that
engineers do employ the patterns, albeit implicitly, and without recognizing the
pattern beforehand.
Real changes in user requirements are rarely straightforward and simple, and we
do not contend that every demand for change can be met by a single semantic
change pattern. However, the engineer, when faced with a general desire for
improvement, can use the patterns as partial solutions and combine them. The
engineer can select appropriate patterns, justify the choice to stakeholders, adapt
the pattern to the needs at hand, and proceed to make the desired CS change in
a correct way. In this way, comprehensive solutions can be reached to meet new
user requirements in a best possible way.
We surmise that semantic change patterns can and will assist engineering efforts
in all phases of the CS life cycle.
276 Wedemeijer
Future Trends
At the time of writing, the catalogue of Semantic Change Patterns outlined in this
chapter is bound to be an incomplete set. However, completeness has not been
our aim. We want to outline realistic patterns of semantic change for the engineer
to learn and copy from.
As the importance of schema maintenance will continue to increase, researchers
and practitioners will detect more and more change patterns in operational
environments. Hence, the catalogue will continue to be extended. Moreover, we
hope to see semantic change patterns of attributes and constraints added to the
catalogue.
Pro-active use of the patterns in the design phase of the CS life cycle allows a
designer 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 in
requirements. This may uncover flaws in the design that the designer can correct
by applying the pattern.
The semantic change patterns can also be useful in the reverse-engineering of
a legacy CS. Knowing common patterns will help to understand the evolution
history and hence will ease the recovery of the schema.
Finally, the semantic change patterns offer an excellent opportunity to replace
the schema-evolution operations of today’s database management systems with
data conversion solutions that are semantically meaningful. This will provide
maintenance engineers with easy to configure data conversion routines that are
well coordinated with the corresponding CS changes.
Conclusions
This chapter introduced the notion of Semantic Change Patterns and outlined a
catalogue of a dozen patterns relevant in Conceptual Schema evolution. Seman-
tic change patterns have their value in enabling the graceful evolution of database
schemas. The patterns are targeted toward adjusting Conceptual Schema
semantics and database contents in accordance with changing user perception
of 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 also
be carefully weighed. As enterprises try to keep the impact of change as small
as possible, the adapted CS is required to be a good model of the new UoD, and
at the same time to be “as close to the old CS as possible”. This usually translates
into the demand for compatibility, thus reducing the need for complex data
conversions and application reprogramming.
The best argument for validity of the semantic change patterns is that these are
based on actual changes observed in operational Conceptual Schemas evolving
in the live business environment. The dozen patterns that we extracted from a
series of case studies, accounts for more than 75% of the observed semantic
changes. In other words, maintenance engineers apply the patterns, without
them having been recognized before.
Much has yet to be learned about the relation between organizational need for
information and the systems -or indeed the Conceptual Schemas- that deliver it.
The literature points out change drivers such as organizational change, mergers
and diversifications, Business Process Reengineering projects, and ongoing
innovations in information system technology and databases. How such change
drivers are related to specific changes taking place in Conceptual Schemas at the
core of operational information systems is not yet well understood. We believe
that the notion of semantic change pattern is a significant step towards that
understanding.
References
ANSI/X3/Sparc Special Interest Group on Management of Data. (1975). Study
Group on Data Base Management Systems Interim Report. ACM-SIGMOD
Newsletter, 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 the
IRMA2000 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 Object

Databases. 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 Multiple
Databases in Distributed Environments. ACM Transactions on Informa-
tion Systems, 14(4), 421-470.
De Troyer, O. (1993). On Data Schema transformations. Dissertation, Tilburg
University, 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 Schema
Evolution. CAiSE’93 Conference Advanced Information Systems Engi-
neering. Springer Verlag, LNCS 685, 22-38.
Feldman, P. & Miller, D. (1986). Entity Model clustering: Structuring a data
model by abstraction. The Computer Journal, 29(4), 348-360.
Fernandez, E.B. & Yuan, X. (2000). Semantic Analysis Patterns. ER’00
Entity-Relationship Approach. Springer Verlag, LNCS 1920, 183-195.
Galliers, R.D. (1993). Towards a Flexible Information Architecture: Integrating
Business 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 Data
planning: Lessons from the field. MIS Quarterly, 11-34.
Goralwalla, I.A., Szafron, D., Tamer Öszu, M. & Peters, R.J. (1998). A
temporal approach to managing schema evolution in object database
systems. 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 Cardinality
Constraints. ER’00 Entity-Relationship Approach. Springer Verlag, LNCS
1920, 126-139.
Kent, W. (1991). Solving domain mismatch and schema mismatch problems
with 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’95

Entity-Relationship Approach. Springer Verlag, LNCS 1021, 296-307.
Lehman, M.M. & Belady, L.A. (1978). Laws of Program Evolution, Rules and
Tools for Programming Management. Proceedings of the Information
Technology 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 Schema
Evolution through the Specification and Maintenance of Changes on
Entities and Relationships. ER’94 Entity-Relationship Approach. Springer
Verlag, LNCS 881, 132-151.
McBrien, P. & Poulovassilis, A. (1998). Formalisation of semantic schema
integration. Information Systems, 23(5), 307-334.
McLeod, D. (1988). A learning-based approach to metadata evolution in
object-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 master
change. Managing Information, 6(1), 42-45.
Peters, R.J. & Tamer Öszu, M. (1997). An axiomatic model of dynamic schema
evolution 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 Schema
Versioning 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 with
conflicting schema structures in heterogeneous database systems. Data &
Knowledge Engineering, 27(2), 231-248.
Veldwijk, R. (1995). Tien Geboden Voor Goed Database Ontwerp. Database
Magazine (in Dutch).
Wedemeijer, L. (1999). Design the flexibility, maintain the stability of
Conceptual 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 data
model 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 beyond
the scope of this chapter to discuss this variant in full detail. We refer to
Wedemeijer (2002). Main features of our data model theory are:
• By definition, an entity is an aggregate of attributes. The entity extent or
population is the current set of instances recorded in the database. The
entity intent is its definition, i.e., the accurate description of relevant real
world objects in the UoD that it is supposed to record.
• The structure of an entity is its references and specializations, as defined
by the modeling primitives of entity aggregation and generalization.
• A relation of a real-world object is its property to be related to one other
real-world object within the UoD. Relations in the real world are captured
as references in the CS. The entity modeling the object with that property
is called the referring, or member entity. The entity modeling the related
object is called the referred, or owner entity.
For all clarity: objects and relations are encountered in the Universe of
Discourse, whereas entities, instances and references are constructs that exist
in the Conceptual Schema.
Graphical Conventions
We use the following graphical conventions that make for compact and easy to
read 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 the
member entity upwards to the owner, with N:1 cardinality. This notation is
used to suggest some “pointer” attribute in the member entity.
• References may have 1:1 cardinality; i.e., each owner instance is referred
to by at most one member instance. This is depicted by omitting the head
of the arrow.
282 Wedemeijer
• A reference is compulsory if the arrow is drawn from the boundary of the

member entity. The reference is optional if the arrow is drawn from the
interior, suggesting it to be coming from some specialization within the
member entity, whether or not that specialization is drawn.
• To avoid cluttering the diagrams, we abstain from depicting attributes and
conceptual constraints.
Model Transformations in Designing the ASSO Methodology 283
Chapter XIII
Model Transformations
in Designing the
ASSO Methodology
Elvira Locuratolo, ISTI, Italy
Abstract
ASSO, an innovative conceptual methodology which combines features of

database design with the formal method B, has been defined in order to
ensure the flexibility of semantic data models, the efficiency of object
models and design correctness. Starting from a directed acyclic graph of
classes supported by semantic data models, a formal mapping generates
classes supported by object models. The classes supported by semantic
data models are then extended with aspects of behavioural modelling: a
relationship with the B model is established and the consistency proofs of
the whole schema are reduced to small obligations of B. This chapter
evidences how ASSO is based on model transformations. These have been
introduced with various purposes: to map semantic data models to object
models, to integrate static and dynamic modelling, to link formal and
informal notations and to relate the conceptual schema and the logical
schema of the methodology.
284 Locuratolo
Introduction
Methodologies used in designing database applications can be based on informal
models that, although easy to understand, are unable to cover both static and
dynamic aspects of modelling in an integrate way and may cause inconsistencies.
Further, they can be inadequate to guarantee that the schema supported by the
database system satisfies the requirements specified at conceptual level. Finally,
they cannot ensure the coexistence of two quality requirements classically
conflicting, i.e., flexibility in reflecting the changes occurring in real life on the
schema and efficiency in accessing information.
B (Abrial, 1996), a formal method of software engineering, uses mathematical
notations for modelling static and dynamics and for performing consistency
proofs. The refinement of B, supported again by proofs, allows the derivation of
correct implementations; however, the direct use of B for developing database
applications presents some shortcomings since B lacks the high level abstraction
mechanisms used for modelling database schemas and its refinement has not
been 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 to
ensure easiness in schema specifications, flexibility in reflecting the changes
occurring in real life on the schema, consistency between static and dynamic
modelling, correctness of implementations and efficiency in accessing informa-
tion. Formality in ASSO is completely transparent to the designer until he decides
to make proofs.
Designing formal environments for the specification and the development of
database applications is currently an interesting topic of research (Mammar &
Laleau, 2003). This is because the growing use of databases in various
application domains where economical interests require a certain degree of
safety, e.g., e-business or financial systems, favours the call for the integration
of databases and formal methods (Laleau, 2000, 2002).
ASSO results from the intuitions of researchers or students with backgrounds
coming from different disciplinary areas. MetaASSO (Locuratolo, 2002), the
approach employed to design ASSO, highlights these intuitions while providing
a high-level description of interacting components, called methodological tools.
The following methodological tools have been designed to achieve quality in
ASSO:
the Revisited Partitioning, a formal method working on static
aspects of database conceptual schemas; the Structured Database
Schema, a formal conceptual model which integrates consistently
static and dynamic aspects of modelling whilst still allowing the

Partitioning applicability; the Relationship between ASSO and B,
link established between a formal methodology designed at
conceptual level and a formal method designed at a lower
abstraction level.
The Revisited Partitioning (Locuratolo, 1998; Spagnolo, 2000) maps a graph of

classes supported by semantic data models to a graph of classes supported by
object models (Cardenas & McLeod, 1990). This method achieves the flexibility
of semantic data models and the efficiency of object models while guaranteeing
the design correctness. The model on which the Revisited Partitioning works is
extended with aspects of behavioural modelling; proof obligations for proving
the schema consistency are given. The model evolution defines the Structured
Database Schema (Locuratolo, 1997). This model has been designed from one
hand with the intent to establish a relationship with the model supported by the
B-Method and from the other with the intent to still allow the Revisited
Partitioning applicability. The Structured Database Schema integrates the
specification of both structural and behavioural information at a high abstraction
level. A correct translation from the Structured Database Schema to the B
model (Locuratolo & Matthews, 1998) puts into evidence that many formal
details explicated at the abstraction level of B are implicitly specified at the
abstraction level of ASSO and that expensive proof obligations to prove
consistency at the B level are reduced to a set of cheap obligations at the ASSO
level.
Support tools for B, such as the B-toolkit (B-Core), can be used to prove the
ASSO 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 correct
model transformations and how these have been introduced with various
purposes: for mapping semantic data models to object models; for integrating
static and dynamic modelling, for linking formal and informal notations, for
representing information at different levels of abstraction, and for linking
together the conceptual and the logical models of the methodology. The theory
is clarified by examples. The innovative aspects of ASSO are evidenced
comparing the methodology with related works.
The chapter is organised as follows: the following section gives a background
description and then illustrates the mapping from semantic to object models.
Next, the chapter describes the model transformations resulting in ASSO. The
chapter then illustrates the relationship between the ASSO model and the B
model. 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 the
B-Method which can be usefully exploited for comparing ASSO with related
works.
Database Design
The database design process (Elmasri & Navathe, 1997) consists of two parallel
activities: the first involves the content and the structure of data, whereas the
second relates to the design of database applications. Traditionally, database
design methodologies have primarily focused on the first of these activities,
whereas software design has focused on the second. It is being recognised by
database designers and software engineers that the two activities should proceed
in parallel and design tools are increasingly combining them. ASSO comprises a
phase of conceptual database design and a phase of logical design. The goal of
the former phase is to produce a conceptual schema, i.e., a high-level description
of the database structure and behaviour independent from the particular Data-
base Management Systems (DBMS) which will be used. The goal of the latter
phase 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 on
the definition of data and their properties. The applications, which access and
modify the database, are a complement of the static description. The data-driven
methodologies generally consist of two steps: the conceptual schema construc-
tion and the logical schema generation. In order to make the conceptual schema
easy to be understood, high level abstraction models, such as Semantic Data
models (Cardenas & McLeod, 1990) or Entity-Relationship Models (Chen,
1976), are employed with a diagrammatic representation. The abstraction
mechanisms of these models closely resemble those used in describing their
applications. In order to represent the complementary dynamic aspects, state-
based and data-flow models are employed; however, as the models employed to
represent statics and dynamics are either informal or have non-integrated
formalisations, it is not possible to prove that the specified operations preserve
the database consistency. The construction of the conceptual schema is followed
by the generation of the logical schema. Within this step of design, information
specified in the conceptual schema is represented in terms of relational models.
The generation of the logical schema is a complex step since the mapping process
is 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 implemented

schema; however, as the correctness is not guaranteed, the application user must
refer to the low level logical schema in any case.
ASSO differs from the approach of Batini et al. since the Structured Database
Schema is a formal model, which integrates structure and behaviour guarantee-
ing consistency. The conceptual schema of ASSO is correctly mapped into the
logical schema. The design correctness renders it possible to develop database
systems that permit writing applications by referring to the conceptual schema
rather than to the logical schema. The conceptual schema is supported by a data
model, which ensures semantic expressiveness and flexibility, whereas an object
model 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. These
methodologies focus on the identification and organisations of the objects, which
compose an application. The object-oriented methodologies employ the same
model along the whole life cycle. This renders the mapping smoother, thus
reducing the risk of introducing errors. Object-oriented methodologies, however,
have always been very week when dealing with data design. They approach data
design at a late stage of the software development process, after the consolida-
tion of object-oriented specifications, by gathering data descriptions from various
sources and then assembling data definitions from them. An example of
methodology which overcomes this problem is IDEA (Ceri & Fraternali, 1997).
This methodology takes advantages from the object-oriented concepts, but it is
driven by the database technology: data design comes first and application design
follows. The generalisation hierarchies of IDEA do not require transformations
in the passage from analysis to design, because they are supported by a high-level
specification language, called Chimera, and by the object model with exactly the
same meaning. Generally, the generalization hierarchies are total and exclusive,
so that, differently from ASSO, the objects of a superclass are partitioned into
the objects of the subclasses.
B-Method
The B-Method (Abrial, 1996) is a formal method of consolidated industrial

interests. The approach consists of two phases: first a consistent and complete
formal specification is constructed from informal requirements; then steps of
refinement 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-Machine

defines a state as a mathematical data model, and a set of operations, which
modify data and provide results as an animation of the data model. The static
aspects of the systems are specified by listing variables and by writing properties
of the variables in the invariant. The invariant is formalised using first order logic
and set theory notation, whereas the operations, including a special operation,
called initialisation, specify the dynamic aspects of the system. These are
formalised using the generalised substitution language. Dynamic modelling is
powerful enough to represent pre-conditioned operations, i.e., state transfor-
mations which can be activated only when certain conditions are met; partial
operations, i.e., transformations which can be defined only on a subset of the
state space and non-deterministic operations, i.e., transformations from one
state to a state chosen among a set of possible ones. A specification is consistent
if the initialisation establishes the invariant and if each operation preserves the
invariant. First order logic formulas, called proof obligations, are proved in
order to guarantee the model consistency. Analogously, refinement proof
obligations are proved in order to ensure the design correctness.
Specifying a database application with the B notation is a tedious process since
many 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 been
proposed (Facon, Laleau & Nguyen, 1996; Shore, 1996). ASSO differs from
these approaches, as a conceptual level and a logical level have been linked
together: specifications in ASSO are written using a formal notation which
exploits the concepts of class and is-a* relationship, i.e., the classic is-a
relationship extended with a behavioural specialization constructor. The proofs
of inherited transactions are avoided and only a restricted number of obligations
need to be proved (Andolina & Locuratolo, 1997). The Revisited Partitioning
transformations are steps of correct refinements, which does not require proofs.
Refinement in ASSO is very promising since conceptual schema specifications
are transformed into logical schema specifications supported by object models
(Locuratolo & Matthews, 1999). This differs from the most recent proposals of
database applications refinements, which are implemented using the relational
database model (Mammar & Laleau, 2003).
A correct translation from the Structured Database Schema into models
supported 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 be
used to prove the ASSO schema consistency. When the designer wishes to
check the consistency of his specification, he invokes the automatic translation
and can use the B proof obligation generator to prove it. However, when an
ASSO 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 reduction

of the essential obligations to small obligations is obtained (Locuratolo &
Matthews, 1999).
The innovative aspects of ASSO result from correct model transformations. The
next section describes the differences between semantic and object models.
Semantic and Object Models

Semantic data models and object systems (Cardenas & McLeod, 1990) have
similar mechanisms of abstraction; however, while semantic data models have
not been implemented efficiently (Nixon & Mylopoulos, 1990), object systems
have reached a remarkable level of efficiency; on the contrary, while semantic
data models are appropriate for conceptual design, object models can display
serious shortcomings in their ability to describe the dynamic nature of the real
world entities (Richardson, 1991). Semantic data models enhance flexibility,
whereas object models enhance efficiency (Cardenas & McLeod, 1990). The
link between semantic data models and object systems is a means to achieve both
of the conflicting requirements of flexibility and efficiency (Locuratolo &
Rabitti, 1998).
In order to clarify the differences between semantic and object models, let us
refer to a graph (such as that of Figure 1a) which can be supported by both
semantic data models and object systems. This graph, called conceptual classes
(Locuratolo & Rabitti, 1998), is supported by a semantic data model, if the
following properties hold:
• Classification: each node of the graph is a class. A node coupled with an
is-a link is a specialised class. In Figure 1a there are: the class person with
attribute income, the class employee with attribute salary, the class
student with attribute identifier, the specialised class employee and the
specialised class student;
• Inheritance: a specialised class (such as the specialised class employee)
inherits all the attributes from the higher level classes and may have
additional attributes. As an example, the specialised class employee
inherits the attribute income from the class person and has the additional
attribute salary;
• Object inclusion: the objects of a specialised class are object subsets of
higher level classes. As an example, the employee objects are a subset of
the person objects.
290 Locuratolo
Figure 1. Conceptual and logical classes
Person
income
Person
Is-a Is-a
Student Employee
Employee Student
salary identifier 1.b
1.a
Person Person
Student Employee or Student Stud_Empl Employee
1.c 1.d
The graph of Figure 1a, in the following called logical classes, is supported by
an object system if, besides the above properties of classification, inheritance
and object inclusion, there is also the restriction that each object instance
belongs 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 the
specialised class employee inherits all the attributes from the class person, the
class employee can be considered as enclosed in the class person, but the sets
representing the object instances of the two classes are really two disjoint sets.
The object intersection of the conceptual classes in Figure 1a is represented in
Figure 1b, whereas the object intersection of the logical classes is represented
in Figures 1c and 1d. In Figure 1b the intersection between the object instances
of the class student and of the class employee may be not empty, whereas in
Figure 1c no object instance can belong simultaneously to both the class student
and 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 represents
this last case evidencing that the object instances, which are simultaneously
student and employee, define a class, the class student·employee, which is
enclosed indirectly in both the class student and the class employee.
The following properties make the difference between semantic and object
models:
• Semantic data models: each object instance can belong to any class of the
graph. This enhances flexibility while limiting efficiency.
• Object models: each object instance belongs to one and only one class of
the graph. This enhances efficiency while limiting flexibility.
In order to show how object models limit the flexibility in reflecting the changes
occurring 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 class
student and must be inserted into a class student •employee. If John completes
his studies later on, the corresponding object instance must be removed from the
class student•employee and must be inserted into the class employee. On the
contrary, in semantic data models, the object instance corresponding to John can
be inserted into the class employee when the student John becomes an
employee and can be removed from the class student when John completes his
studies.
The Revisited Partitioning maps conceptual classes into logical classes linking
features of formal and informal methods. This method is correct, i.e., the
objects of the obtained classes are all and only those of the original conceptual
classes and each of them has all and only the original declared attributes. The
method is complete, i.e., it generates all the classes implicitly enclosed in the
conceptual classes.
The Revisited Partitioning is composed of two phases, called representation
and decomposition, respectively. The former permits describing the conceptual
classes, whereas the latter permits decomposing them while reconstructing
hierarchies supported by object systems. The logical classes represented in
Figure 1d encloses one class more than the original conceptual classes repre-
sented in Figure 1b. The next section describes the model transformations
resulting in ASSO.
Structured Database Schema

The Structured Database Schema (Locuratolo, 1997, 2002) is a model that
extends the conceptual classes on which the Revisited Partitioning works. It has
been designed on the one hand with the intent to still permit the applicability of
the Revisited Partitioning and on the other with the intent to establish a
relationship between ASSO and B, a formal method of consolidated industrial
292 Locuratolo
interests. The Structured Database Schema is based on the concepts of class

and is-a* relationship between classes. In the following their definitions are
given:
• Definition (class): A class is a tuple (name, Att, Const, Op) where name
is a term connoting the class name and denoting the class objects. The term
name, called class extension, represents a subset of a given set. Att is a
finite set of terms called attributes; each of them is defined as a function
from the extension name to either a given set or the extension of another
class. Both extension and attributes define the class state variables,
whereas the predicate, which formalises their definitions, is called class
constraints. Const is a predicate on the class state variables, which
formalises a set of properties, called class application constraints. Op is
a finite set of operations defined as functions from predicates establishing
the class constraints to predicates establishing the class constraints. A
special operation, called initialisation, belongs to Op. This associates
initial 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 been
designed in order to reflect some features of the model supported by B: the
operations have first been designed as basic operations, i.e., operations that add
objects, remove objects, modify attributes or let the class unchanged, and have
then 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 with

class root then the specialized class name is defined:
• the objects of the specialised class name are a subset of the
objects of class root.
• The specialised class name inherits both attributes and opera-
tions from class root; it has specific operations and may have
specific attributes.
If a class name is in is-a* relationship with a class root, then an inherited

operation 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 also
instantiated on the class name. These two last specific operations on the class
name are called specialisation. Other specific operations on the class name are
possible.
The two definitions of class and is-a* relationship allow introducing the following
definition of Structured Database Schema.
• Definition (Structured Database Schema): A Structured Database

Schema is a connected acyclic graph whose nodes are classes and whose
links are is-a* relationships between classes.
The definition of Structured Database Schema as a graph has been given in order
to allow the applicability of the Revisited Partitioning, after steps of behavioural
refinement, 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 supported
by the Structured Database Schema (Locuratolo, 2002):
• Class name1 of GIVEN-SET with (att-list; const; op-list)
• Class name2 is-a* name1 with (att-list; const, op-list)
The former is the basic constructor used to specify the root class of a Structured
Database Schema. The latter is used to specify the remaining classes. Within
these forms, name1 and name2 denote the class names; att-list, const and op-list
denote respectively the attributes, the application constraints and the operation
list of the class name 1 in the former specification and of the class name2 in the
latter specification. The class and the is-a constraints are implicitly specified with
the class constructors.
Figure 2 presents the specification of the conceptual schema. This specification
describes 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 each
employee 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 is
specialised both when the person is employed and when the person becomes a
student.
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 other
specific operation has been specified.
The given Conceptual Schema shows that the specifications supported by the
Structured Database Schema provide the advantages of both formal and
informal notations while exhibiting the quality features of the object-oriented
style. Similar to the informal specifications written using the friendly database
conceptual languages, ASSO allows the implicit specification of many details
explicitly specified by the formal notations. But, as opposed to the informal
notations, the ASSO specifications permit some properties of the model, such as
its consistency, to be proved. Further, the ASSO notation is powerful enough to
represent pre-conditioned, partial and non-deterministic operations that are
given at an abstraction level higher than the level provided by database
conceptual languages.
As an example of behavioural refinement, let us consider the class student in
Figure 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 )
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
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
new.student(pers) =
ADD student (s, max(ran(identifier))+1)
END)
each new student one and only one identifier that has not been used before. A
possible step of behavioural refinement consists in associating with each new
student the maximum of all existing identifiers incremented by one. A Structured
Database Schema behavioural refinement is a modular refinement of classes;
i.e., if a class is refined, the entire Structured Database Schema is refined. After
a step of behavioural refinement for the class student, the Conceptual Schema
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 root
class person•employee takes attributes, initialisation, and constraints of both the
classes person and employee. The operations are parallel compositions of the
corresponding operations on the classes person and employee. Each structured
database schema also takes a copy of the class student implicitly splitting this
class 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 instance
belongs to one and only one class.
The logical schema specifies more information with respect to the conceptual
schema, since the person •employee •student class is explicitly specified.
The definition of Structured Database Schema based on graph has been given
in order to apply the Revisited Partitioning after some steps of behavioural
refinement; however, before performing any model transformation, the concep-
tual schema consistency needs to be proved. In order to prove the Conceptual
Schema 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) will
be captured through properties (Locuratolo, 2002) and will be used in order to
prove the Structured Database Schema consistency:
• Property (B-Machine and Class): A B-Machine whose initialisation

establishes the class constraints and whose operations preserve the class
constraints can be associated with each class, and a class can be associated
with each B-Machine whose initialisation establishes the class constraints
and whose operations preserve the class constraints.
If the initialisation establishes the class constraints and the operations preserve
the class constraints, a class can be identified with a B-Machine whose state
variables are constrained to satisfy the class constraints. This means that in
order 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 if

the initialisation establishes the application constraints and each of the
remaining operations preserves the application constraints.
In order to prove the class-machine consistency, a process of translation from

ASSO classes to B-machines able to generate the application constraint
obligations while avoiding the generation of the class constraint obligations has
been proposed (Locuratolo & Matthews, 1999). The translation from an ASSO
class to a B-Machine has been performed by associating both a base machine
and a class machine with each class. The base machine is the means to constrain
the state variables to satisfy the class constraints. The base machine contains the
class variables, base operations and initialisation, without the invariant, thus
generating no proof obligations. The base machine is embedded within a class
machine that declares the class operations and asserts the application constraints
on the form of invariant. The encapsulation principle of B (Abrial, 1996) ensures
that only the base operations can modify the class variables. As the base
operations preserve the class constraints, this principle ensures that operations
on classes preserve the class constraints. Thus, only the obligations related to the
application constraints are generated and proved.
• Definition (Structured Database Schema consistency): The Structured

Database Schema is consistent if each class-machine corresponding to a
class 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 model
in which operations and application constraints involve only variables of single
classes. The model (Locuratolo, 2001) has been enriched in order to allow
operations and application constraints to involve variables of two or more
classes. In order to prove consistency of the enriched Structured Database
Schema, 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 the
attributes of the class-machine root restricted to the class name and the
specific attributes of the class-machine name;
• the initialisation (resp. an operation which inserts objects) of the
specialised class-machine name is the parallel composition (Abrial,
1996) of the inherited initialisation (resp. the inherited operation which
inserts objects) with the corresponding specialisation;
• for each remaining operation on the class-machine root, the inherited
operation 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 a
class-machine. However, the distinction between class-machines and
specialised class-machines will be retained for convenience.
• Definition (Structured Database Schema): A Structured Database
Schema 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 the

previous one; however, this permits seeing the model supported by ASSO as a
set of independent class-machines, i.e., root class-machine and specialised
class-machines that allow the decomposition of large consistency obligations into
a set of small obligations.
• Definition (Structured Database Schema consistency): A Structured

Database Schema is consistent if the root class-machine is consistent and
each specialised class-machine is consistent.
The proof of the inherited operations can be avoided. Thus, in the case of
operations and application constraints involving only single classes, the specialised
class-machine consistency is reduced to the class-machine consistency, whereas,
in the case of operations and application constraints involving variables of
specialised class-machines, the consistency proof of the specialised machine can
be optimised.
Conclusions and Further Developments

The design of ASSO, an innovative database design methodology for quality, has
been based on correct model transformations: starting from a directed acyclic
graph of classes supported by semantic data models, classes supported by
objects models are generated exploiting the Revisited Partitioning. The classes
supported by semantic data models have been extended with aspects of
behavioural modelling; proof obligations have been given. The class evolution
has been designed with the intent to establish a relationship with the model
supported by B, a formal method of software engineering appropriate for
commercial use, while still applying the Revisited Partitioning. The resulting
model is an innovative model called Structured Database Schema. The
specifications, supported by the Structured Database Schema are only those
which satisfy the class and the specialisation constraints. This restriction is the
key to reduce the consistency proofs of the whole schema to the consistency
proofs of simple B-Machines.
In the following, two possible methods based on model transformations will be
proposed. They allow using some of the results achieved in designing ASSO. The
former 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 distinction
between concept intension and concept extension, where the former refers
to the information content of the concepts, and whereas the latter to the set
of objects which fall under the concepts. The revisited Partitioning can be
applied to the extensional side, whereas no similar approach has ever been
designed for the intentional side. A method based on correct model
transformations could be designed in order to derive knowledge implicitly
contained in hierarchies of concepts.
• Raising the Abstraction Level of B: The ASSO experience can be
exploited for designing methods to be used in specific application areas
starting from widely accepted general purpose methods. An example
consists in raising the abstraction level of B. An approach composed by two
phases could be designed: the former is a logical formalisation of classes
supported by object systems in terms of B-Machines, the latter is a process
of schema transformations, which provides a model where only specifica-
tions of both the class and the specialised classes can be given and where
only 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 children
Paola and Floriano for their help and advice.
Figures 2, 3 and 4 have been reprinted from “Designing Methods for Quality” by
Elvira Locuratolo in Information Modelling and Knowledge Bases XIII, edited
by Hunnu Kangassalo, Hunnu Jaakkola, Eiji Kawaguchi and Tatjana Welzer, p. 287
and 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 specialisation
modelling. 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: An
Entity-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: Prentice
Hall.
Castelli, D., & Locuratolo, E. (1994). A Formal Notation for Database Concep-
tual Schema Specifications. In H. Jaakkola (Ed.), Information Modelling
and Knowledge Bases VI, IOS Press.
Castelli, D., & Locuratolo, E. (1995). ASSO: A formal database design meth-
odology. In H. Jaakkola (Ed.), Information Modelling and Knowledge
Bases VI, (pp. 145-158). IOS Press.
Castelli, D., & Locuratolo, E. (1995). Enhancing Database System Quality
through Formal Design. Fourth Software Quality Conference, University
of Abertay Dundee & Napier University, pp. 359-366.
Ceri, S., & Fraternali, P. (1997). Database Applications with Objects and
Rules. Edinburgh Gate Harlow Essex, UK: Addison Wesley Longman.
Chen, P. P. (1976). The entity-relationship model: Towards a unified view of
data. 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 into
B specifications. In A. Bryant & L.T. Semmens (Eds.), Proceedings of
the Methods Integration Workshop, Electronics Workshops in Com-
puting, BCS.
Jarke, J., Mylopoulos, J.W., Schmidt, J. W., & Vassiliou, Y. (1992). DAIDA: An
environment for evolving information systems. ACM Transactions on
Information Systems, 10(1), 1-50.
Laleau, R. (2000). On the interest of combining UML, with the B formal method
for 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 bases
de 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 IEI
B4-05-02.
Locuratolo, E. (2002). Designing methods for quality. In H. Kangassalo, H.
Jaakkoala, E. Kawaguchi & T. Welzer (Eds.), Information Modelling
and Knowledge Bases XIII, (pp. 279-295). IOS Press.
Locuratolo, E., & Matthews, B.M. (1998). Translating structured database
schemas into abstract machines. Proceedings of the 2nd Irish Workshop
on Formal Methods, Cork, Ireland.
Locuratolo, E., & Matthews, B. M. (1999). ASSO: A formal methodology of
conceptual 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 Databases
in 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 ASSO

and 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 in
object databases. Acta Informatica, 35(3), 181-210.
Mammar, A., & Laleau, R. (2003). Design of an automatic prover dedicated to
the 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 semantic
data 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 of
Management 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: Prentice
Hall.
Rumbaugh, J., Booch, G., & Jacobson, I. (1999). The Unified Modelling
Language Reference Manual. Reading, MA: Addison-Wesley.
Shore, R. (1996). An object-oriented approach to B. In H. Habrias (Ed.),
Proceedings of the 1 st Conference on the B-Method, Nantes, France.
Spagnolo, A.M. (2000). Incrementare la qualità in ambito Basi di Dati. Tesi di
Laurea. Università degli Studi di Pisa – Corso di Laurea in Scienze
dell’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 of
Nijmegen, The Netherlands (1995). He is currently an assistant professor at the
University of Nijmegen. He gives courses in foundations of databases and
information 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 for
hyperdocuments and Web sites; semi-structured data; equivalence and transfor-
mation of data models; the transformation of conceptual data models into
implementations; and the transformation of database populations, operations and
constraints. 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 Computer

Science, King Saud University, Riyadh, Saudi Arabia. He received a BSc
(Honors) in Mathematics from the University of Ibadan, Nigeria (1970) and a
Postgraduate Diploma in Computer Science from the University of Lagos,
Nigeria (1972). He earned an MSc and PhD in Computer Science (1973 and
1976, respectively) from the University of Birmingham, UK. His research areas
include modeling, systems design and implementation, and Web databases. He
has 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 Computer

Science at King Saud University in Riyadh, Saudi Arabia. He received a BSc in
Computer Science from King AbdulAziz University, Jeddah, Saudi Arabia
(1995). His research areas include Web databases, wireless computing, and
Internet security.
Antonio Badia received a Licenciatura in Philosophy from the Universidad de

Barcelona before studying Computer Science and Artificial Intelligence at the
Universitat Politecnica de Catalunya. He then joined the graduate program at
Indiana University and received a PhD in Computer Science. He is currently an
assistant 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 US
Navy. His research interests include conceptual models, query languages, query
processing and optimization, active databases, knowledge management, and
applications of information systems to intelligence tasks.
Paolo Bottoni graduated in Physics in 1988 and obtained his doctoral degree in
Computer Science (1995). Since 1994, he has been with the Department of
Computer Science of the University “La Sapienza” of Rome, first as a re-
searcher, and, since 2000, as an associate professor. His research interests are
mainly in the area of interactive computing, and include: definition of pictorial and
visual languages, visual simulation, formal models of visual interactive comput-
ing, agent-based computing. On these topics, he has published 100 scientific
papers 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 Computer
Science from the Beijing University of Aeronautics and Astronautics, Beijing,
China (1994). Afterwards, he gained several years of postdoctoral research
experience in different institutes. His recent research interest covers two major
areas: advanced database technology (especially XML database management)
and bioinformatics.
Keith Duddy is co-leader of the Pegamento Project within the Enterprise

Automation Group at the DSTC. Since 1998, this project has been extending the
Object Management Group’s core MOF and UML modeling technologies to deal
with enterprise modelling issues and mapping of those models to a range of
distributed technology platforms. Keith was a contributor to the OMG Standards
for CORBA Trader and Notification services. He was co-author of ‘Java

Programming with COBRA’ (Wiley, 1997), the first book on this subject. He has
since been editor for the OMG standards ‘UML Profile for CORBA’ and ‘UML
Profile for Enterprise Distributed Object Computing (EDOC)’. Keith has served
three terms on the OMG architecture board.
Anna Gerber is currently a research scientist with the Distributed Systems

Research Centre (DSTC) in Brisbane. Her present work involves research into
and prototyping of model-driven development techniques, and includes contribu-
tions to DSTC’s work on the Object Management Group (OMG) Enterprise
Distributed Object Computing (EDOC) standard and OMG Meta Object Facility
2.0 Query/View/Transformation (MOF QVT) proposals. Anna’s research
interests include enterprise modelling, mapping workflow and business process
models to middleware technologies facilitating automatic generation of imple-
mentations, and generation of tools such as domain specific graphical editors
from 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 semantic
Web. Hacid graduated as an engineer in Computer Science from the University
of Tizi-Ouzou, Algeria, and received his PhD in Computer Science from the
National Institute of Applied Sciences, Lyon, France.
Jean-Luc Hainaut is a full professor in Information System and Database

Engineering at the Institute of Informatics of the University of Namur, Belgium.
He is heading LIBD (Laboratory of Database Applications Engineering), the
purpose of which is to develop general methodologies and CASE tools to assist
practitioners in solving such engineering problems as database design, database
reverse engineering, federated databases, database evolution, temporal data-
bases, XML and Web engineering. He is the author of two books (in French) on
database modelling and database design, and of more than 50 recent journal and
proceedings papers. Two of the major results of the research activities, namely
the DB-MAIN CASE environment and a wide spectrum database reverse
engineering methodology, are being marketed by a young spin-off of the LIBD.
Renate Klempien-Hinrichs is a research assistant in theoretical computer

science at the University of Bremen in Germany. In 1992, she received a diploma
in Computer Science from the University of Passau. Her doctoral thesis on
context-free hypergraph grammars with node and hyperedge rewriting was
completed in 2000. In between, she was a fellow within the European Research
Network GETGRATS at the University of Bordeaux in France. Her research
interests are mainly directed towards formal methods and include computing by
graph transformation, context-free generation of graphs and graph-like objects,
syntactic picture generation, and gender and teaching issues in computer
science.
Hans-Jörg Kreowski is a professor of Theoretical Computer Science at the

University of Bremen, Germany. He holds a diploma degree in Mathematics and
a 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 (Foundations
of Systems Specification), receiving the IFIP Outstanding Service Award in
1996. He currently chairs the German Forum Informatikerinnen und Informatiker
für Frieden und gesellschaftliche Verantwortung [forum of computer scientists
for peace and social responsibility]. His research is in the area of theoretical
computer science with emphasis on graph transformation, algebraic specifica-
tion, rule-based systems, and syntactic picture processing, as well as on
computers and society.
Sabine Kuske is a research assistant and lecturer in Theoretical Computer

Science at the University of Bremen, Germany. From 1982-1991, she studied
first business management with emphasis on tourism in Spain, and secondly
computer science at the University of Bremen. From 1991-1993, she received
a doctoral grant from the University of Bremen. In 2000, she obtained a doctoral
degree for her thesis on transformation units, a concept that offers a structuring
principle for graph transformation systems. Her research interests concern
programming and specifying with graph transformation, structuring principles for
graph transformation, and application of graph transformation to the UML.
Michael Lawley holds a PhD from Griffith University in Brisbane, Australia, in

the area of integrity constraint checking for object-oriented databases. Cur-
rently, Dr. Lawley is the co-project leader for the Pegamento Project at the
DSTC, also in Brisbane. He has published widely in the area of workflow design
and verification, as well as the integration of workflow with other middleware
technologies. He is a contributor the OMG standard ‘UML Profile for Enterprise
Distributed Object Computing’. His current interests are in the area of model
transformation 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. Her

research interests include quality modeling, database design methodologies,
formal methods and re-engineering methods. She is the author of numerous
articles in books and journals. She has collaborated with the Rutherford Appleton
Laboratory at Oxford and other foreign institutions. She also carries out teaching
activity in mathematics and computer science at the University of Pisa.
Z. M. Ma received his PhD from the City University of Hong Kong (2001). His
current 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 and
scheduling, decision making, and robot path/motion planning. He has published
many journal, conference, and book chapter papers in these areas. He is
currently editing and authoring two upcoming books being published by Idea
Group Inc. and Kluwer Academic Publishers, respectively.
Andreas Märcz was born in Großenhain near Dresden in the former GDR (east
part of Germany). From 1983-1995, he attended elementary, grammar and
secondary school in Dresden and got a university-entrance diploma (German
Abitur). Because of his interest in databases and software engineering he
studied Information Technology at the Dresden University of Technology (TU-
Dresden) (1995-2000). In 2000, he graduated with an MSc in Computer Science
and got a position as database chair at TU-Dresden with scientific, teaching and
administration activities. His current research scopes on format independence
for multimedia databases, especially for time dependent objects and therefore
resource management.
Klaus Meyer-Wegener studied computer science from 1975-1980 at Darmstadt

Institute of Technology, receiving the degree Diplom-Informatiker. From 1980–
1986, he served as a research assistant with the Department of Computer
Science at University of Kaiserslautern. In 1986, he received a PhD (Doktor-
Ingenieur). From 1986–1990, he served as assistant professor in the Department
of Computer Science, University of Kaisers-lautern. From October 1987 through
December 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 of
Computer 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 of
Computer Science (Database Systems) at the University of Erlangen and
Nuremberg.
Francesco Parisi-Presicce is with the Department of Information and Soft-

ware Engineering at George Mason University, on leave from the Università di
Roma “La Sapienza,” where he has been professor of Computer Science in the
Department of Information since 1993. He received his PhD and MS in
Mathematics 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 graph
transformation community since its inception, and applies graph transformations
to information systems security, formal methods in secure system development,
network security and visual modeling techniques. He is the author of more than
100 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 his
PhD in Computer Science from the University Claude Bernard (1996). His main
research interest concerns databases and data mining. In the past, he contributed
to database reverse engineering.
Kerry Raymond is the distinguished research leader at DSTC, responsible for

the management of exploratory research projects. She has a PhD from the
University of Queensland in distributed systems. Her personal research interests
are in the Enterprise Automation research group which seeks to increase the
extent of automatic generation of systems from high-level descriptions and
enterprise models to provide rapid application development and evolution. Her
current research focuses on the development of a generic transformation engine
to implement the automatic generation of systems, and the role of knowledge
representation and ontologies in automatic systems generations.
Abad Shah is an associate professor in the Department of Computer Science at

King Saud University in Riyadh, Saudi Arabia. He received his BSc in Math-
ematics and Physics from Punjab University, Lahore, Pakistan (1967), an MSc
in Applied Mathematics from Quaid-I-Azam University, Islamabad, Pakistan
(1981) with Quaid-I-Azam Award, an MS in Computer Science from Rensselaer
Polytechnic Institute, Troy, New York (1986), and a PhD in Computer Science
from Wayne State University, Detroit, Michigan (1992). His research areas
include modeling, object-oriented databases, temporal databases, Web data-
bases, software engineering, information modeling. He has more than 40
research 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 the
Distributed Systems Technology Centre. He has extensive experience in
metamodeling 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’s
Pegamento project on a language for describing model transformations. His
research 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 a

degree of Technician in Electro-Energy and an honored university-entrance
diploma. Between 1996-2001, he studied at the Wroclaw University of Technol-
ogy (PWR). In 2000, he was nominated to a one-year Socrates/Erasmus
Scholarship at the New University of Lisbon, Portugal. In 2001, he received the
USENIX Student Research Grant and later received his MSc in Computer
Science (Multimedia Information Systems). Since 2002, he has been a research
assistant at the Friedrich-Alexander University of Erlangen-Nuremberg in
Germany. His current scientific work concerns a real-time audio-video conver-
sion for MMDBs.
Gabriele Taentzer is an associate professor of Computer Science at the

Technical University of Berlin and member of the steering committee of
International Conferences on Graph Transformation (ICGT). Her research
interests include the development of new graph transformation concepts and
their application in different areas of software engineering, visual languages and
distributed systems. She leads the development of the graphtransformation
environment AGG (http://tfs.cs.tu-berlin.de/agg) which offers a variety of tools
to work with graphs and graph transformation and supports the integration of
graph transformation into Java applications.
Norbert Vincent received an MSc in Economics from the Vrije Universiteit

Amsterdam in 1994, specializing on the theme ‘Business Process Redesign’. He
currently is working on his PhD on Performance Management of the Business
Value of IT at the Erasmus University Rotterdam. Professionally, Norbert
Vincent currently works as principal consultant for LogicaCMG. There, he
advises organisations on business and IT strategy, business transformation and

cost and performance management. His current focus is on ERP and the
performance of organisations.
Lex Wedemeijer has been working in the areas of data administration and data
management in several Dutch companies for more than 20 years. His main
interests are in quality and evolution of data schemas, both its theoretical
foundations 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 data
architect at ABP Netherlands, Europe’s largest pension fund.
Bernd Wondergem received an MSc in Computer Science from Utrecht

University (1996), specializing on the theme ‘Organization & Information’. He
received a PhD in Information Retrieval from the University of Nijmegen (2000).
His research centered around compact and tractable descriptors for information
discovery. In addition, he received an MSc in Management and Organisation
from Tias Business School (2002). Currently, he is a guest lecturer on Perfor-
mance Management at the University of Nijmegen. Professionally, Bernd
Wondergem currently works as principal consultant for LogicaCMG Consulting,
the advisory unit of LogicaCMG. There, he works with companies and other
organisations on improving their performance. In particular, he focuses on
translating the organisation’s strategy in the required management information
and on building performance-oriented organisations.
Index 311
Index
Symbols alias filters 248

anti-Yacc 128
1NF relational model 8 application reprogramming 265
3-schema architecture 258 approximate dependencies 175
arbitrary entity 275
A arbitrary nesting 174
abstract syntax tree (AST) 99 aspect-driven transformation 135
abstracting power 55 ASSO 284
abstraction level 285 associations 152
abstraction mechanism 286 associativity 83
access preservation 120 atomic objects 155
action management 220 attribute value indices 81
action semantics 119 attribute-oriented data model 55
action semantics language (ASL) 131 attribute-oriented model 53
action tuples 44 attributed graph 106
active database 192 attributes 149
activity diagrams 97 audio 237
acyclicity 59 audio stream 237
admission control 237 availability of source data 227
advanced transformations 143
affected code 103
B
aggregation 153 B-machine 287
aggregation attribute 200 B-method 287
algebraic approach 105 balanced scorecard (BSC) 220
algebraic signature 106 balanced tags 157
algebraic transformation 78 behavior preservation 120
312 Index
behavioral analogies 98 component streaming interface (CSI)

behavioral aspects 119 251
behavioural modelling 285 composite key 154
behavioural refinement 293, 294 composition 153
belated normalization 269 composition symbol 196
binary graph 5 compound attributes 8
binary relationship 150 compound transformation 15
binary relationship-type 57 computer-based information systems
bool 35 190
bridge entity type 15 conceptual classes 291
business processes 221 conceptual data models 54
conceptual models 148
C conceptual schema 6, 258
call preservation 121 concrete syntax 137
candidate keys 175 conjunctive information 194
cardinality constraint 150 constraint obligation 296
cardinality information 199 constructor-oriented data model 55
Cartesian product 198 constructor-oriented model 53
causal relationship 260 constructors 55
chain of converters 239 containment relationship 79
change pattern 266 contextual elements 115
change taxonomies 264 contiguous subtrees 117
class application constraint 292 continuous improvement 220
class constructor 293 control condition 30
class diagrams 97, 260 control flow actions 119
class extension 292 conversion 236
class hierarchy 151, 296 conversion algorithm 236
class of patterns 16 conversion graph 239, 243
class state variables 292 conversion networks 237
class-machine 296 converter 239
classification 289 CORBA IDL 129
cleaning-up phase 87 correct translation 288
code evolution 101 correctness 287
code representation 100 D
coding scheme 238
coexistence constraint 12 dangling condition 107
collaboration diagram 101 data coercion 265
collection type 155 data model 53, 148
common superclass 98 data model theories 261
common warehouse metamodel (CWM) data semantics 53
129 data structure 53
commutativity 83 data type 133
compatibility 265 data-driven methodologies 286
complex entities 208 database design 52, 283
complex objects 197 database design process 286
compliant documents 80 database interoperability 2
Index 313
database management systems entity identifier 207

(DBMS) 286 entity instances 207
database platform 262 entity Java Bean (EJB) model 143
declarative object-oriented transforma- entity types 149
tion language 135 entity-relationship 149
decomposition 291, 296 entity-relationship model 52
decomposition operator 11 EntityBeans 143
definition symbol 195 enumeration type 200
Deming’s cycle 219 equivalence 82
dependent entities 268 equivalent transformation 76
design correctness 283 estimated cost 77
design primitives 261 evaluation efficiency 86
determinism 87 evolution operator 263
deterministic transformation 77, 87 excessive fragmentation 177
directed graph 61, 224 exclusivity 84
DirectX 241 existing hierarchy 104
disjoint classes 296 expected requirements 221
disjunctive information 194 explicit constraints 56
distributed application 115 explicit constructor 55
distributed graph 107 EXPRESS 191
distributed graph transformation 107 extend entity 272
distributivity 83 extensible markup language (XML) 172
document indexing 77 external schema 259
document queries 76 extract method 116
document schema (DTD) 172
document type declaration/description F
(DTD) 172 facets 157
domain 153, 205 families of transformations 11
DROPS 251 figurative representation 78
DTD graph 78 filter 241
dynamic aspect 287 filter graph 241
dynamic modelling 285 foreign key 13, 154, 173, 184
dynamic resource allocation 229 foreign-key change 268
dysfunctional behaviour 227 functional dependencies (FDs) 56, 178
E fuzzy conceptual data models 193
fuzzy data 194
edge concept 80 fuzzy nested relational database model
element content indices 81 193
element extent 81 fuzzy occurrences 201
elementary operator 15 fuzzy set 194
embed 42 fuzzy subtype 202
end tags 156 fuzzy supertype 202
enterprise distributed object computing
(EDOC) 129 G
enterprise-distributed system develop- generalization 153
ment 128 generalization hierarchies 287
entity collection 6
314 Index
generalized aggregation 57 intra-model transformations 4

GER model 6 intuitive meaning 59
global scope 60 inverse reference 154
goal model (GM) 222 inverse transformation 9
graph 32 irregular structures 172
graph class expression 30, 34 is-a-hierarchy 57
graph homomorphism 106
graph morphism 100 J
graph of converters 239 Java media framework (JMF) 241
graph rule 106
graph transformation 31, 97, 130 K
graph transformation unit 36
key attribute 150
H key performance indicators (KPI) 220
key success factors (KSF) 220
hierarchical relation 157
hierarchy structure 198 L
horizontal fragmentation 273
hybrid schema 6 labeled graphs 156
lattice of models 4
I lexical transformations 97
local graph 107
impact value 224 logical data model 54
implicit constraints 56 logical database tuning 52
imprecision 193 logical schema 287
inclusion dependencies 56
inconsistent model 101 M
independent actions 119
independent evolution 100 marking model 143
index structures 81 markup language 78
informal notation 285 matrix method 192
information retrieval (IR) 81 maximal postcondition 9
inheritance 154, 289 MDA 128
inheritance hierarchy 57 measurable indicator 219
inheritance of attribute 151 media codec 241
inheritance relation 113 media data 237
initialisation 292 media object (MO) 236
inline technique 177 “member” entity 268
inserted types 104 membership degrees 205
instance graph 106 membership function 194
instance mapping 9 meta information 238
integrity constraints 154 meta object facility (MOF) 129
inter-model operators 4 method extraction 99
inter-schema references 196 min-max cardinalities 6
interface graph 100, 108 minimal precondition 9
internal schema 259 MO.content 238
interoperability 128 MO.format 238
intersection entities 270 MO.type 238
Index 315
model diagrams 99 object-relational structure 7

model driven architecture (MDA) 145 object-role modeling (ORM) 4, 149
model evolution 285 obligation generator 288
model transformation 128 OCL 2.0 131
model-driven architecture 128 OCL constraint 99
model-driven transformation 17 OO-databases 7
MTDL 131 operational models 3
multimedia computer 236 operational organisation 220
multimedia conversion 235 operational phase 264
multimedia data 236, 237 optimisation algorithms 248
multimedia objects (MMO) 236 optional attribute 152
multivalued attribute 14, 152 optional reference 269
mutation 12 optional type 173
mutation transformations 12 ordering constraints 134
organisation model (OM) 222
N owner entity 271
name clashes 98 P
negative application conditions 107
nest operator 198 page references 196
nest-unnest 11 partial operation 288
nested element structure 172 partial organization 156
nested loops 184 participation constraint 150
nested relational databases 196 PAT algebra 80
network graph 107 PAT expression 80
network rule 107 path concept 80
NF2 model 7 path indexing 77, 81
nodes 156 pattern definitions 136
non-deterministic operation 288 performance indicators (PI) 219, 224
normalization 88, 178 performance management (PM) 218,
normalization phase 87 225
normalization rules 175 performance management model (PMM)
normalization theory 4 222
normalized schemas 60 permitted values 55
physical schema 6
O platform independent models (PIMs)
object identifiers 154 128
object inclusion 289 platform specific models (PSMs) 128
object instance 15, 290, 296 possibility distribution theory 193
object intersection 290 potential indices 82
object management group (OMG) 128 potential transformations 82
object model 285 power set 205
object-id 133 predicate-driven transformation 16
object-oriented methodologies 287 presentation processing engine (PPE)
object-oriented models 128 242
object-oriented programming 96 primary key 8, 154, 173, 184, 261
object-oriented specification 129 primitive refactoring 98
316 Index
product data mode 207 result-driven business management

product type 29 229
profitable transformation 82 RETAVIC 236, 250
project-join 11 revealed requirements 221
projection 42 reverse engineering 6, 99
proof obligation 288 revisited partitioning 285, 291
prototype tree 175 rewriting operator 5
root class 293
Q root element 79
QoS-filtering model 241 root entities 209
quality function deployment (QFD) 221 root node 175
quality of data (QoD) 240 rule application 33
quality of experience (QoE) 240 rule-based transformation 29
quality of service (QoS) 237, 239 S
quantitative performance 219
query algebra 78 schema equivalence 2
query expression 77 schema evolution 263
query optimization 75 schema extensibility 268
query processing 76 schema extraction algorithm 183
QVT 130 schema integration 264
schema merging 264
R self-activation 101
REAL 236 self-call stemming 101
real-time operating system (RTOS) 249 self-referring links 270
real-time processing 237 semantic change 260
refactoring 97 semantic checking 60
refactoring actions 99 semantic data model 55, 289
reference relationship 203 semantic heterogeneity 261
referential integrity 154, 267 semantic optimization phase 87
regular expression 80, 175 semantic relationships 197
relation schema 56 semantics constraints 176
relation values 205 semantics preservation 10
relational algebra 198 semistructured data 172
relational data model 153 semistructured data management 77
relational database (RDB) 172, 192, separate nodes 183
196 sequential application 108
relational database technology 172 serial attributes 14
relational model 52 set-oriented construct 14
relational shell 155 set-oriented equivalences 83
relationship cardinalities 53 significant refactoring 100
relationships 149 simplification phase 87
relaxation 274 single schema 199
removed subtrees 117 software engineering 31
resource usage 246 source schema 10
restrict entity 272 source-driven 135
restructuring operators 198 source-driven transformation 131
Index 317
specialised class 292 terminal graph 39

stable description 262 textual content 80
standard generalized markup language time constraint 238
(SGML) 76 timed MMO 238
standard relational model 4 timed MO 238
state machine 97, 101 tracking relationships 136
statecharts 99 traditional optimization 76
static declaration 119 transcode 242
static description 286 transcoder 242
static diagram 151 transformation algorithm 173
STEP 191 transformation database 9
strategic goals 218 transformation plan 17
strategic map 222 transformation reversibility 9
structural changes 262 transformation rules 81, 136
structural inverse 10 transformation tool set 144
structural mapping 9 transformation unit 36, 109
structural predicate 16 transformation-based database engi-
structural properties 82 neering 1, 75, 127, 217, 257
structure index 81 transformational theory 3
structured database schema transformations of data 129
285, 288, 291 transitive closure 79
structured database schema consis- transitive closure of inheritance 112
tency 297 transitive inclusion 4
structured document 76 tree data 173
structured domain 152 tree grammar 176
structured-document database 76 TRule 137
sub-element 173 tuples 154
subclass 151, 287 type modeling 200
subrule 113 type preservation 120
substitution language 288 type transformation 208
subtype 13 type-compatible 80
subtype/supertype relationship 208
subvertices 119 U
superclass 287 UML 31, 97, 149
superimposed entity 275 UML class diagram 129
supertype 13 UML class model 8
surrogate key 58 UML metamodel 99
sustained competitive advantage 232 unidirectional 87
symmetrically reversible 10, 12 unified entity 275
syntactic changes 263 unified modeling language (UML) 128,
system evolution 128 151
T union types 176
unique identifier 207, 293
table divide 273 universal relation schema assumption
tags 78 61
target-driven 135 universe of discourse 259
318 Index
update preservation 121

user defined types (UDTs) 155
user interface 265
user training 265
user-defined operator 13
V
validity 274
value-based management (VBM) 220
variable replacement 114
vertex 105
vertex identity 106
video 237
video stream 237
VirtualMedia 242
visual languages 31
W
weak entity 151, 271
well-formedness constraints 121
World Wide Web Consortium (W3C) 76
X
XML 149
XML model interchange (XMI) 129
XPATH 131
XQuery 131
Instant access to the latest offerings of Idea Group, Inc. in the fields of
I NFORMATION SCIENCE , T ECHNOLOGY AND MANAGEMENT!
InfoSci-Online
Database
BOOK CHAPTERS
JOURNAL AR TICLES
C ONFERENCE PROCEEDINGS
C ASE STUDIES
The Bottom Line: With easy
“
to use access to solid, current
and in-demand information,
InfoSci-Online, reasonably
The InfoSci-Online database is the
most comprehensive collection of
priced, is recommended for full-text literature published by
academic libraries.
”
- Excerpted with permission from
Library Journal, July 2003 Issue, Page 140
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
Start exploring at n Continuously Updated
www.infosci-online.com n Advanced Searching Capabilities
Recommend to your Library Today!

Complimentary 30-Day Trial Access Available!
A product of:
Information Science Publishing*
Enhancing knowledge through information science
*A company of Idea Group, Inc.

www.idea-group.com
BROADEN YOUR IT COLLECTION
WITH IGP JOURNALS
is an innovative international publishing company, founded in 1987, special-
izing in information science, technology and management books, journals
Idea and teaching cases. As a leading academic/scholarly publisher, IGP is pleased
to announce the introduction of 14 new technology-based research journals,
in addition to its existing 11 journals published since 1987, which began
Group with its renowned Information Resources Management Journal.
Free Sample Journal Copy
Publishing Should you be interested in receiving a free sample copy of any of IGP's
existing or upcoming journals please mark the list below and provide your
mailing information in the space provided, attach a business card, or email
IGP at journals@idea-group.com.
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
Name:____________________________________ Affiliation: __________________________
Address: ______________________________________________________________________
_____________________________________________________________________________
E-mail:______________________________________ Fax: _____________________________
Visit the IGI website for more information on

these journals at www.idea-group.com/journals/
IDEA GROUP PUBLISHING

A company of Idea Group Inc.
701 East Chocolate Avenue, Hershey, PA 17033-1240, USA
Tel: 717-533-8845; 866-342-6657 • 717-533-8661 (fax)
Journals@idea-group.com www.idea-group.com
NEW RELEASE
Beyond Knowledge
Management
Brian Lehaney, PhD, University of Coventry, UK
Steve Clarke, PhD, University of Luton, UK
Elayne Coakes, PhD, University of Westminster, UK
Gillian Jack, PhD, University of Glamorgan, UK
Beyond Knowledge Management provides a

balance of conceptual and practical aspects of
knowledge management, offering the opportunity for
students and practitioners to understand and effectively
consider knowledge management approaches in their
organizations. Everyday examples are used to lead
the reader into the development of knowledge
management, then further into a conceptual
perspective, and finally to the practical application of
knowledge management in organizations.
ISBN 1-59140-180-1 (h/c) • US$79.95 • ISBN 1-59140-223-9 (s/c) • US$64.95

• 280 pages • Copyright © 2004
Beyond Knowledge Management provides a balance of conceptual and practical

aspects of Knowledge Management, offering the opportunity for students and practitioners
to understand and effectively consider knowledge management approaches in their
organizations.
- Gillian Jack, University of Galmorgan, UK
Its Easy to Order! Order online at www.idea-group.com or

call 717/533-8845 x10
Mon-Fri 8:30 am-5:00 pm (est) or fax 24 hours a day 717/533-8661
Idea Group Publishing

Hershey • London • Melbourne • Singapore
An excellent addition to your library

IDEA GROUP PUBLISHING
Publisher of IT books, journals and cases since 1988
NEW RELEASE
Trust in Knowledge
Management and Systems in
Organizations
Maija Leena Huotari, Ph.D., University of Oulu, Finland
Mirja Iivonen, Ph.D., University of Tampere, Finland
Trust in Knowledge Management and Systems in

Organizations aims at tying trust to knowledge management
(KM). It highlights the complexity of the invisible phenomenon
of trust challenged by the global economy. Fresh insights,
novel theoretical frameworks, and empirical results and ideas
for future research are presented that differ from those since
the 1950s. The eleven chapters (whose authors represent
information studies, economics, administrative scientists,
mass communications, computer science and cognitive
science) explore the multidisciplinary nature of the concepts
of trust and KM. The concept of trust is analyzed by presenting
its extensive description in relation to knowledge and
information-intensive activities and systems for understanding
the dynamics of knowledge-based production at the levels of individuals, information
systems, organizations, networks and society. Systems are considered from the
social or the socio-technological perspective.
ISBN 1-59140-126-7 (h/c) • US$79.95 • ISBN 1-59140-220-4 (s/c) • US$64.95

eISBN 1-59140-127-5 • 296 pages • Copyright © 2004
‘‘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 has
probably 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
Its Easy to Order! Order online at www.idea-group.com or

call 717/533-8845 x10
Mon-Fri 8:30 am-5:00 pm (est) or fax 24 hours a day 717/533-8661
An excellent addition to your library!

Maija-Leena Huotari, Mirja Iivonen, Mirja Iivonen - Transformation of Knowledge, Information and Data - Theory and Applications-IGI Global (2003)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Maija-Leena Huotari, Mirja Iivonen, Mirja Iivonen - Transformation of Knowledge, Information and Data - Theory and Applications-IGI Global (2003)

Uploaded by

Copyright:

Available Formats

Transformation of

Theory and Applications

Patrick van Bommel

Information Science Publishing

Published in the United States of America by

and in the United Kingdom by

Library of Congress Cataloging-in-Publication Data

Section I: Fundamentals of Transformations

Section II: Elaboration of Transformation Approaches

Section III: Additional Topics

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

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

These examples illustrate just a few possibilities of changes in data. Numerous

In this book, the fundamental treatment of moving knowledge, information, or

We therefore aim at generic approaches for the treatment of data transforma-

From Source to Target

Figure 1. Framework for transformation of structures and operations

structure transformation target

• Wellformedness conditions. First, we describe the required properties of

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

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 a

sible. Again, this graph transformation is rule-based. We use this approach to

sets and probability theory. Here we focus on transformations in the context of

ductive approaches by: (a) requiring that initialization adheres to application

Patrick van Bommel, PhD

In this chapter, we develop a transformational framework in which many

Motivation and Introduction

formalized and analyzed in a uniform way. We present a wide spectrum

Schema Transformation Basics

Developing Transformational Theories

Developing a general purpose transformational theory requires deciding on the

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

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

Data Structure Specification Model

Database engineering is concerned with building, converting and transforming

paradigms. Some processes, such as normalization, integration and optimization

The GER is an extended entity-relationship model that includes, among others,

Figure 1. Typical hybrid schema made up of conceptual constructs (e.g.,

Specifying Operational Models with the GER

In this section, we illustrate the specialization mechanism by describing a

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

Figure 3. Defining the main technical constructs of relational data

GER constructs relational constructs assembly rules for a specific DBMS

Figure 4. Two mappings of schema transformation Σ ≡ <T,t> (The inst_of

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

The extent to which a transformation preserves the information contents of a

Proving the Reversibility of a Transformation

2. Basic project-join transformation is applied and yields a normalized rela-

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

Figure 5. Proving the SR property of the decomposition of a relationship

source schema target schema

T11 ⇓⇑ T11' T13 ⇑ ⇓ T13'

Six Mutation Transformations

A mutation is an SR-transformation that changes the nature of an object.

Figure 6. Six mutation transformations Σ1 to Σ3 (Though not primitive,

source schema target schema comment

T2 Transforming relationship type

T3 Transforming attribute A2 into

T4 Not a primitive operator. T4

sophisticated mutation operators can be defined as illustrated in Hainaut (1991)

Other Basic Transformations

The mutation transformations can solve many database engineering problems,

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