Content uploaded by Mohamed Ali Ben Hassine
Author content
All content in this area was uploaded by Mohamed Ali Ben Hassine
Content may be subject to copyright.
Handbook of Research
on Fuzzy Information
Processing in Databases
José Galindo
University of Málaga, Spain
Hershey • New York
InformatIon scIence reference
Volume I
Acquisitions Editor: Kristin Klinger
Development Editor: Kristin Roth
Senior Managing Editor: Jennifer Neidig
Managing Editor: Jamie Snavely
Assistant Managing Editor: Carole Coulson
Copy Editor: April Schmidt, Shanelle Ramelb
Cover Design: Lisa Tosheff
Printed at: Yurchak Printing Inc.
Published in the United States of America by
Information Science Reference (an imprint of IGI Global)
701 E. Chocolate Avenue, Suite 200
Hershey PA 17033
Tel: 717-533-8845
Fax: 717-533-8661
E-mail: cust@igi-global.com
Web site: http://www.igi-global.com
and in the United Kingdom by
Information Science Reference (an imprint of IGI Global)
3 Henrietta Street
Covent Garden
London WC2E 8LU
Tel: 44 20 7240 0856
Fax: 44 20 7379 0609
Web site: http://www.eurospanbookstore.com
Copyright © 2008 by IGI Global. All rights reserved. No part of this publication may be reproduced, stored or distributed in any form or by
any means, electronic or mechanical, including photocopying, without written permission from the publisher.
Product or company names used in this set are for identication purposes only. Inclusion of the names of the products or companies does
not indicate a claim of ownership by IGI Global of the trademark or registered trademark.
Library of Congress Cataloging-in-Publication Data
Handbook of research on fuzzy information processing in databases / Jose Galindo, editor.
p. cm.
Summary: "This book provides comprehensive coverage and denitions of the most important issues, concepts, trends, and technologies in
fuzzy topics applied to databases, discussing current investigation into uncertainty and imprecision management by means of fuzzy sets and
fuzzy logic in the eld of databases and data mining. It offers a guide to fuzzy information processing in databases"--Provided by publisher.
Includes bibliographical references and index.
ISBN-13: 978-1-59904-853-6 (hardcover)
ISBN-13: 978-1-59904-854-3 (ebook)
1. Databases--Handbooks, manuals, etc. 2. Data mining--Handbooks, manuals, etc. 3. Fuzzy mathematics--Handbooks, manuals, etc. I.
Galindo, Jose, 1970-
QA76.9.D32H336 2008
005.74--dc22
2007037381
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 set is original material. The views expressed in this book are those of the authors, but not necessarily of
the publisher.
If a library purchased a print copy of this publication, please go to http://www.igi-global.com/agreement for information on activating
the library's complimentary electronic access to this publication.
351
Chapter XIV
How to Achieve Fuzzy
Relational Databases Managing
Fuzzy Data and Metadata
Mohamed Ali Ben Hassine
Tunis El Manar University, Tunisia
Amel Grissa Touzi
Tunis El Manar University, Tunisia
José Galindo
University of Málaga, Spain
Habib Ounelli
Tunis El Manar University, Tunisia
Copyright © 2008, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.
ABSTRACT
Fuzzy relational databases have been introduced to deal with uncertain or incomplete information
demonstrating the efciency of processing fuzzy queries. For these reasons, many organizations aim
to integrate exible querying to handle imprecise data or to use fuzzy data mining tools, minimizing
the transformation costs. The best solution is to offer a smooth migration towards this technology. This
chapter presents a migration approach from relational databases towards fuzzy relational databases.
This migration is divided into three strategies. The rst one, named “partial migration,” is useful basi-
cally to include fuzzy queries in classic databases without changing existing data. It needs some deni-
tions (fuzzy metaknowledge) in order to treat fuzzy queries written in FSQL language (Fuzzy SQL). The
second one, named “total migration,” offers in addition to the exible querying, a real fuzzy database,
with the possibility to store imprecise data. This strategy requires a modication of schemas, data, and
eventually programs. The third strategy is a mixture of the previous strategies, generally as a temporary
step, easier and faster than the total migration.
INTRODUCTION
New enterprise information systems are requested
to be exible and efcient in order to cope with
rapidly changing business environments and ad-
vancement of services. An information system that
develops its structure and functionality in a con-
tinuous, self-organized, adaptive, and interactive
way can use many sources of incoming information
and can perform intelligent tasks such as language
352
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
learning, reasoning with uncertainty, decision mak-
ing, and more. According to Bellman and Zadeh
(1970), “much of the decision making in the real
world takes place in an environment in which the
goals, the constraints, and the consequences of
possible actions are not known precisely.” Manage-
ment often makes decisions based on incomplete,
vague, or uncertain information. In our context,
the data which are processed by the application
system and accumulated over the lifetime of the
system may be inconsistent and may not express
the reality. In fact, one of the features of human
reasoning is that it may use imprecise or incomplete
information and in the real world, there exists a
lot of this kind of fuzzy information. Hence, we
can assert that in our every day life we use several
linguistic labels to express abstract concepts such
as young, old, cold, hot, cheap, and so forth. There-
fore, human-computer interfaces should be able to
understand fuzzy information, which is very usual
in many human applications. However, the major-
ity of existing information systems deal with crisp
data through crisp database systems (Elmasri &
Navathe, 2006; Silberschatz, Korth, & Sudarshan,
2006). In this scenario, fuzzy techniques have
proven to be successful principles for modeling such
imprecise data and also for effective data retrieval.
Accordingly, fuzzy databases (FDBs) have been
introduced to deal with uncertain or incomplete
information in many applications demonstrating
the efciency of processing fuzzy queries even in
classical or regular databases. Besides, FDBs allow
storing fuzzy values, and of course, they should
allow fuzzy queries using fuzzy or nonfuzzy data
(Bosc, 1999; De Caluwe & De Tré, 2007; Galindo,
Urrutia, & Piattini, 2006; Petry, 1996).
Facing this situation, many organizations aim
to integrate exible querying to handle imprecise
data or to use fuzzy data mining tools, minimizing
the transformation costs. A solution of the existing
(old) systems is the migration, that is, moving the
applications and the database to a new platform
and technologies. Migration of old systems, or
legacy systems, may be an expensive and complex
process. It allows legacy systems to be moved to
new environments with the new business require-
ments, while retaining functionality and data of
the original legacy systems. In this context, the
migration towards FDBs, which constitutes a step
to introduce imprecise data in an information sys-
tem, does not only constitute the adoption of a new
technology, but also, and especially, the adoption
of a new paradigm. Consequently, it constitutes a
new culture of development of information systems,
and this book is evidence of the current interest
and the promising future of this paradigm and its
multiple elds.
However, with important amounts invested in
the development of relational systems, in the enroll-
ment and the formation of “traditional” program-
mers, and so forth, enterprises appear reticent to
invest important sums in the mastery of a new fuzzy
paradigm. The best solution is to offer a smooth
migration toward this technology, allowing them to
keep the existing data, schemas, and applications,
while integrating the different fuzzy concepts to
benet of the fuzzy information processing. It will
lower the costs of the transformations and will
encourage the enterprises to adapt the concept of
fuzzy relational databases (FRDBs). Moreover,
although the migration of the information systems
constitutes a very important research domain, there
is a limited number of migration methods between
two specic systems. We mention some examples
(e.g., Behm, Geppert, & Dittrich, 1997; Henrard,
Hick, Thiran, & Hainaut, 2002; Menhoudj & Ou-
Halima, 1996). To our knowledge, the migration
of relational databases (RDB) towards FRDB is
not even studied.
FDBs allow storing fuzzy values and, besides,
they allow making fuzzy queries using fuzzy or
nonfuzzy data. It should be noted that classic que-
rying is qualied by “Boolean querying,” although
some systems use a trivalued logic with the three
values true, false, and null, where null indicates
that the condition result is unknown because some
data is unknown. The user formulates a query usu-
ally with a condition, for example, in SQL, which
returns a list of rows, when the condition is true.
This querying system constitutes a hindrance for
353
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
several applications because we cannot know if
one row satises the query better than another row.
Besides, the traditional querying does not make
it possible for the end user to use some vague lin-
guistic terms in the query condition or to use fuzzy
quantier such as “almost all” or “approximately
the half.” Many works have been proposed in the
literature to introduce the exibility into the data-
base querying both in crisp and fuzzy databases
(Bosc, Liétard, & Pivert, 1998; Bosc, & Pivert,
1995, 1997, 2000; Dubois & Prade, 1997; Galindo,
Medina, & Aranda, 1999; Galindo, Medina, Pons,
& Cubero, 1998; Galindo et al., 2006; Kacprzyk Kacprzyk
& Zadrożny, 1995, 2001; Tahani, 1977; Umano &Tahani, 1977; Umano &
Fukami, 1994). The essential idea in these works). The essential idea in these works
consists in adding an additional layer to the classic
DBMS (database management systems) to evaluate
fuzzy predicates. In this book, the reader can nd
a chapter by Zadrożny, de Tré, de Caluwe, andZadrożny, de Tré, de Caluwe, and and
Kacprzyk with an interesting review about fuzzywith an interesting review about fuzzy
querying proposals. Also, this book includes other
chapters with new applications and new advances
in the eld of fuzzy queries. Some examples are
the chapter by Takači and Škrbić about prioritiesand Škrbić about priorities Škrbić about priorities
in queries, the chapter by Dubois and Prade aboutand Prade about Prade about
bipolar queries, and the chapter by Barranco, Cam-
paña, and Medina using a fuzzy object-relational
database model.
Among various published propositions for
different fuzzy database models, we mention
the one by Medina, Pons, and Vila (1995) who
introduced the GEFRED model, an eclectic syn-
thesis of other previous models. In 1995, Bosc and
Pivert introduced the rst version of a language
handling the exible queries named SQLf. In their
turn, Medina, Pons, and Vila (1994b) proposed
the FSQL language, which was later extended
(Galindo, 1999, 2005; Galindo et al., 1998, 2006).
Although the basic target in FSQL is similar to the
SQLf language, FSQL allows fuzzy queries both
in crisp and fuzzy databases and it presents new
denitions such as many fuzzy comparators, fuzzy
attributes (including fuzzy time), fuzzy constants.
It allows the creation of new fuzzy objects such as
labels, quantiers, and so forth. There is another
chapter by Urrutia, Tineo, and González studying
both proposals.
This chapter presents a new approach for the
migration from RDB towards FRDB with FSQL.
The aim of this migration is to permit an easy map-
ping of the existing data, schemas, and programs,
while integrating the different fuzzy concepts.
Therefore, all valid SQL queries remain useful
in the fuzzy query language FSQL (fuzzy SQL).
This approach studies the RDB transformations
essentially at the level of the schemas (physical
and conceptual), the data, and, less specically,
the applications.
First, we present a very brief overview about
fuzzy sets and then we present basic concepts
about FRDB. After, we present our three migration
strategies. The rst one, named “partial migra-
tion,” is useful only to include fuzzy queries in
classic databases without changing existing data.
The second one, named “total migration,” offers
in addition to the exible querying the possibil-
ity to store imprecise data. The third strategy is
a mixture of the previous strategies. Finally, we
outline some conclusions and suggest some future
research lines.
Introduction to Fuzzy Sets
The fuzzy sets theory stems from the classic theory
of sets, adding a membership function to the set,
which is dened in such a way that each element is
assigned a real number between 0 and 1. In 1965,
professor L.A. Zadeh dened the concept of fuzzy
sets and then many works and applications have
been made (Pedrycz & Gomide, 1998). We give here
the most basic notions, and for a better introduction,
read the rst chapter of this handbook.
A fuzzy set (or fuzzy subset) A is dened by
means of a membership function mA (u), which
indicates the degree to which the element u is in-
cluded in the concept represented by A. The fuzzy
set A over a universe of discourse U can also be
represented with a set of pairs given by:
A = {mA (u) /u : u ∈ U, mA (u) ∈ [0,1]}
(1)
354
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
where m is the membership function and mA(u) is the
membership degree of the element u to the fuzzy set
A. If mA(u)=0, it indicates that u in no way belongs
to the fuzzy set A. If mA(u)=1, then u belongs totally
to the fuzzy set A. For example, if we consider
the linguistic variable height_of _a_person, then
three fuzzy subsets could be dened identied by
three labels, Short, Medium-height, and Tall, with
membership functions mShort(u), mMedium -height(u), and
mTall(u), respectively, where u takes values in the
referential of this attribute (or underlying domain),
that would be the real positive numbers (expressing
the centimetres of height).
On the other hand, for domains with a non-
ordered referential, a similarity function can be
dened, that can be used to measure the similarity
or resemblance between every two elements of the
domain. Usually, the similarity values are normal-
ized in the interval [0,1], where 0 means “totally
different” and 1 means “totally alike” or equal.
Thus, a similarity relationship is a fuzzy relation
that can be seen as a function sr, so that:
sr : D×D → [0,1]
sr(di, dj) → [0,1] with di, dj ∈ D
(2)
where D is the domain of the dened labels. We
can assume that sr is a symmetrical function,
this is that sr(di, dj) = sr(dj, di), as this is the most
usual, although it does not necessarily have to be
this way.
We can also construct possibility distributions
(or fuzzy sets) on the labels of D, extending the pos-
sibilities for expressing imprecise values (Zadeh,Zadeh,
1978), in such a way that each value dn such a way that each value di ∈ D has
a degree of truth or possibility pi associated to it,
obtaining expressions for specic values that can
be expressed generically as:
{pi/di : pi ∈ [0,1], di ∈ D} (3)
The domains with ordered and non-ordered
referentials can adequately represent concepts of
“imprecision” using fuzzy sets theory. It should be
noted that many of these natural concepts depend,
in a greater or lesser degree, on the context and on
the person that expresses them.
From this simple concept, a complete math-
ematical and computing theory has been developed
which facilitates the solution of certain problems.
Fuzzy logic has been applied to a multitude of
objectives such as control systems, modeling,
simulation, patterns recognition, information or
knowledge systems (databases, expert systems,
etc.), computer vision, articial intelligence, arti-
cial life, and so forth.
Introduction to Fuzzy Relational
Databases
The rst chapter of this handbook includes a brief
introduction to this topic, explaining some basic
models. We give here a brief overview in order to
facilitate the reading of this chapter.
The term “imprecision encompasses various
meanings, which might be interesting to highlight.
It alludes to the facts that the information available
can be incomplete (vague), that we don’t know
whether the information is true (uncertainty),
that we are totally unaware of the information
(unknown), or that such information is not ap-
plicable to a given entity (undened). Usually, the
total ignorance is represented with a NULL value.
Sometimes these meanings are not disjunctive and
can be combined in certain types of information”.
(Galindo et al., 2006, p. 45)
This imprecision was studied in order to elabo-
rate systems, databases, and, consequently, applica-
tions which support this kind of information. Most
works studying the imprecision in information have
used possibility, similarity, and fuzzy techniques.
The research on FDBs has been developed for
about 20 years and concentrated mainly on the
following areas: exible querying in classical da-
tabases, extending classical data models in order
to achieve fuzzy databases (including, of course,
fuzzy queries on these fuzzy databases and fuzzy
conceptual modeling tools), fuzzy data mining
355
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
techniques, and applications of these advances
in real databases. All these different issues have
been studied in different chapters of this volume
and also in many other publications (De Caluwe
& De Tré, 2007; Bosc, 1999; Bosc et al., 1998;
Galindo et al., 2006; Petry, 1996).
The querying of a FRDB, contrary to classical
querying, allows the users to use fuzzy linguistic
labels (also named linguistic terms) and express
their preferences to better qualify the data that
they wish to get. An example of exible query, also
named in this context fuzzy query, would be “list
of the young employees, well paid and working in
department with big budget.” This query contains
the fuzzy linguistic labels “young,” “well paid,”
and “big budget.” These labels are words, in natural
language, that express or identify a fuzzy set that
may or may not be formally dened.
In fact, the exibility of a query reects the
preferences of the end user. This is manifested
by using a fuzzy set representation to express a
exible selection criterion. The extent to which
an object in the database satises a request then
becomes a matter of degree. The end user provides
a set of attribute values (fuzzy labels), which are
fully acceptable for the user, and a list of minimum
thresholds for each of these attributes. With these
elements, a fuzzy condition is built for the fuzzy
query. Then, the fuzzy querying system ranks
the answered items according to their fulllment
degree or level of acceptability. Some approaches,
the so-called bipolar queries, need both the fuzzy
condition (or fuzzy constraint) and the positive
preferences or wishes, which are less compulsory.
(A very interesting chapter about bipolar queries
may be found in this volume in the chapter by
Dubois and Prade.) Hence, the interests of fuzzy
queries for a user are twofold:
1. A better representation of the user’s prefer-
ences while allowing the use of imprecise
predicates.
2. Obtaining the necessary information in order
to rank the answers contained in the database
according to the degree to which they satisfy
the query. It contributes to avoid empty sets of
answers when the queries are too restrictive,
as well as too large sets of answers without
any ordering when queries are too permis-
sive.
This preface led us to establish the denition
of FRDB as an extension of RDB. This extension
introduces fuzzy predicates or fuzzy conditions
under shapes of linguistic expressions that, in ex-
ible querying, permits to have a range of answers
(each one with its membership degree) in order
to offer to the user all intermediate variations
between the completely satisfactory answers and
those completely dissatisfactory (Bosc et al., 1998).
Yoshikane Takahashi (1993, p. 122) dened FRDB
as “an enhanced RDB that allows fuzzy attribute
values and fuzzy truth values; both of these are
expressed as fuzzy sets”.
Then, a fuzzy database is a database which is
able to deal with uncertain or incomplete informa-
tion using fuzzy logic. There are many forms of
adding exibility in fuzzy databases. The simplest
technique is to add a fuzzy membership degree to
each record, an attribute in the range [0,1]. However,
there are others kind of databases allowing fuzzy
values to be stored in a fuzzy attribute using fuzzy
sets or possibility distributions or fuzzy degrees
associated to some attributes and with different
meanings (membership degree, importance degree,
fulllment degree...). The main models are those of
Prade-Testemale (1987), Umano-Fukami (Umano,
1982; Umano & Fukami, 1994), Buckles-Petry
(1982), Zemankova-Kaendel (1985) and GEFRED
by Medina-Pons-Vila (1994a).
This chapter deals mainly, with the GEFRED
model (GEneralised model for Fuzzy RElational
Database), and some later extensions (Galindo
et al., 2006). This model constitutes an eclectic
synthesis of the various models published so far
with the aim of dealing with the problem of rep-
resentation and treatment of fuzzy information
by using RDB. One of the major advantages of
this model is that it consists of a general abstrac-
tion that allows for the use of various approaches,
356
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
regardless of how different they might look. In
fact, it is based on the generalized fuzzy domain
and the generalized fuzzy relation, which include
respectively classic domains and classic relations.
The original data types supported by this model
are showed on Table 1.
PRELIMINARY CONCEPTS
In order to implement a system which represents
and manipulates “imprecise” information, Medina
et al. (1995) developed the FIRST (fuzzy interface
for relational systems) architecture, which has
been enhanced with FIRST-2 (Galindo, Urrutia,
& Piattini, 2004b; 2006). It has been built on some
DBMS client-server architecture, such as Oracle1
and PostgreSQL2 (Galindo, 2007; Maraboli &
Abarzua, 2006). It extends the existing structure
and adds new components to handle fuzzy informa-
tion. This architecture adds a server, named FSQL
server, assuring the translation of exible queries
written in FSQL in a comprehensible language
for the host DBMS (SQL). FSQL is an extension
of the popular SQL language, in order to express
fuzzy characteristics, especially in fuzzy queries,
with many fuzzy concepts (fuzzy conditions, fuzzy
comparators, fulllment degrees, fuzzy constants,
fuzzy quantiers, fuzzy attributes, etc.). The rst
versions of FSQL were developed during the last
decade of the 20th century (Galindo et al., 1998;
Medina et al., 1994b), and the more recent version
is dened by Galindo et al. (2006).
In the following subsections, we present this
language and the supported fuzzy attributes types.
The RDBMS (relational DBMS) dictionary or
catalog which represents the part of the system
allowing the storage of information about the data
collected in the database, and other information
(such as users, data structures, data control, etc.),
is prolonged in order to collect the necessary
information related to the imprecise nature of the
new collection of data processing (fuzzyattributes,fuzzy attributes,
their type, their objects such as labels, quantiers,
etc.). Thisextension, namedfuzzy metaknowledge). This extension, named fuzzy metaknowledge
base (FMB), is organized following theprevailing (FMB), is organized following the prevailing, is organized following the prevailing
philosophy in the host RDBMS catalog. In this
chapter, we designate by fuzzy RDBMS (FRD-
BMS) the addition of the FSQL server and the
FIRST-2 methodology to the RDBMS.
Fuzzy Attributes
In order to model fuzzy attributes, we distinguish
between two classes of fuzzy attributes: Fuzzy at-
tributes whose fuzzy values are fuzzy sets (or pos-
sibility distributions) and fuzzy attributes whose
values are fuzzy degrees. Each class includes some
1. A single scalar (e.g., Behavior=Good, represented by the possibility of distribution 1/Good).
2. A single number (e.g., Age=28, represented by the possibility of distribution 1/28).
3. A set of mutually exclusive possible scalar assignations (e.g., Behavior={Bad, Good}, represented by {1/Bad, 1/Good}).
4. A set of mutually exclusive possible numeric assignations (e.g., Age={20, 21}, represented by {1/20, 1/21}).
5. A possibility distribution in a scalar domain (e.g., Behavior={0.6/Bad, 1.0/Regular}).
6. A possibility distribution in a numeric domain (e.g., Age={0.4/23, 1.0/24, 0.8/25}, fuzzy numbers or linguistic labels).
7. A real number belonging to [0, 1], referring to a degree of matching (e.g., Quality=0.9).
8. UNKNOWN value with possibility distribution {1/u: u ÎU} , where U is the considered domain.
9. UNDEFINED value with possibility distribution {0/u: u ÎU}, where U is the considered domain.
10. NULL value, given by NULL={1/Unknown, 1/Undened}.
Table 1. Data types in the GEFRED model
357
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
different fuzzy data type (Galindo et al., 2006;
Urrutia, Galindo, & Piattini, 2002).
Fuzzy Sets as Fuzzy Values
These fuzzy attributes may be classied in four
data types. This classication is performed taking
into account the type of referential or underlying
domain. In all of them, the values Unknown, Un-
dened, and Null are included:
• Fuzzy Attributes Type 1 (FTYPE1): These
are attributes with “precise data,” classic
or crisp (traditional with no imprecision).
However, we can dene linguistic labels
over them, and we can use them in fuzzy
queries. This type of attribute is represented
in the same way as precise data, but they can
be transformed or manipulated using fuzzy
conditions. This type is useful for extending
a traditional database, allowing fuzzy queries
to be made about classic data. For example,
enquiries of the kind “Give me employees that
earn a lot more than the minimum salary.”
• Fuzzy Attributes Type 2 (FTYPE2): These
are attributes that gather “imprecise data over
an ordered referential.” These attributes ad-
mit, like Table 2 shows, both crisp and fuzzy
data, in the form of possibility distributions
over an underlying ordered dominion (fuzzy
sets). It is an extension of Type 1 that does,
now, allow the storage of imprecise informa-
tion, such as “he is approximately 2 metres
tall.” For the sake of simplicity, the most
complex of these fuzzy sets are supposed to
be trapezoidal functions (Figure 1).
• Fuzzy Attributes Type 3 (FTYPE3): They
are attributes over “data of discreet non-or-
dered dominion with analogy.” In these at-
tributes, some labels are dened (e.g., “blond,”
“red,” “brown,” etc.) that are scalars with a
similarity (or proximity) relationship dened
over them, so that this relationship indicates to
what extent each pair of labels resemble each
other. They also allow possibility distribu-
tions (or fuzzy sets) over this dominion, for
example, the value (1/dark, 0.4/brown), which
expresses that a certain person is more likely
to be dark than brown-haired. Note that the
underlying domain of these fuzzy sets is the
set of labels, and this set is non-ordered.
• Fuzzy Attributes Type 4 (FTYPE4): These
attributes are dened in the same way as Type
3 attributes without it being necessary for a
similarity relationship to exist between the
labels.
Fuzzy Degrees as Fuzzy Values
The domain of these degrees can be found in the
interval [0,1], although other values are also permit-
ted, such as a possibility distribution (usually over
this unit interval). The meaning of these degrees is
varied and depends on their use. The processing of
the data will be different depending on the mean-
ing. The most important possible meanings of the
degrees used by some authors are the fulllment
degree, uncertainty degree, possibility degree, and
importance degree.
The most typical kind of degree is a degree
associated to each tuple in a relation (Type 7)
with the meaning of membership degree of each
tuple to the relation. Another typical degree is
the fulllment degree associated to each tuple in
the resulting relation after a fuzzy query. In this
volume, there are some chapters about these kinds
of relations (see for example the ranked tables in
the chapter by Belohlavek and Vychodil or the
fulllment degrees in the chapter by Voglozin,
Raschia, Ughetto and Mouaddib).
Figure 1. Trapezoidal, linear, and normalized
distribution function
1
0
a b c d
U
358
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
Sometimes is useful to associate a fuzzy degree
to only one attribute (Type 5) or to only a concrete
set of attributes (Type 6), for example, in order to
measure the truth, the importance, or the vague-
ness. Finally, in some applications, a fuzzy degree
with its own fuzzy meaning (Type 8) is useful in
order to measure a fuzzy characteristic of each
item in the relation like the danger in a medicine
or the brightness of a concrete material.
Representation of Fuzzy Attributes
The representation is different according to the
fuzzy attribute type. Fuzzy attributes Type 1 are
represented as usual attributes because they do
not allow fuzzy values. Fuzzy attributes Type 2
need ve (or more) classic attributes: One stores
the kind of value (Table 2), and the other four store
the crisp values representing the fuzzy value. Note
in Table 2 that trapezoidal fuzzy values (Figure 1)
need the other four values. An approximate value
(approximately d, d±margin) is represented with
a triangular function centered in d (degree 1) and
with degree 0 in d–margin and d+margin, where
the value margin depends on the context, as we
will see later). Other approximate values (number
8) use their own margin m.
Finally, we can also represent possibility dis-
tributions in the Type 2 attributes. Some of them
(number 9 and 10) use only the four attributes
dened previously, but we dene here two new
and more exible possibilities:
•Number 11: Discontinuous possibility dis-
tribution, given a list of point with the format
p1/v1,…, pn/vn, where the pi are the possibility
degrees and the vi are the values with such
degrees. Note that we need 2n attributes
(instead of the four) for storing a possibility
distribution with n terms. The rest of the
values have a degree of zero.
•Number 12: Continuous possibility distri-
bution, given a list of point with the format
p1/v1,…, pn/vn, where the pi are the possibility
degrees and the vi are the values with such
degrees. Note that we need 2n attributes
for storing a possibility distribution with n
terms. Now the stored possibility distribution
represents a continuous linear function, and
between vi and vi+1, there is a straight line
joining each consecutive two points.
Fuzzy attributes Type 3 need 2n+1 attributes:
One stores the kind of value (Table 3) and the others
(2n) may store a possibility distribution where n is
the maximum number of elements (degree/label).
Note in Table 3 that number 3 needs only two val-
ues, but number 4 needs 2n values. Value n must
be dened for each fuzzy attribute Type 3, and it
is stored in the FMB (see following section).
Fuzzy attributes Type 4 are represented just like
Type 3. The difference between them is shown in
the next section. Fuzzy degrees (Types 5, 6, 7, and
8) are represented using a classic numeric attribute
because their domain is the interval [0,1].
Table 2. Kind of values of fuzzy attributes Type 2
Number Kind of values
0, 1, 2 UNKNOWN, UNDEFINED, NULL
3Crisp: d
4Label: label_identier
5Interval: [n,m]
6Approximate value: d
7Trapezoidal value: [a,b,c,d]
8Approx. value with explicit m: d±m
9,10,11,12 Possibility distributions (different
formats)
Table 3. Kind of values of fuzzy attributes Types
3 and 4
Number Kind of values
0, 1, 2 UNKNOWN, UNDEFINED, NULL
3 Simple value: Degree/Label
4 Possibility Distribution:
Degree1/label1 + ... + Degreen/Labeln
359
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
The FSQL Language
The FSQL language (Galindo, 2005; Galindo et
al., 2006; Galindo, Aranda, Caro, Guevara, &
Aguayo, 2002) is an authentic extension of SQL
which allows fuzzy data manipulation like fuzzy
queries. It means that all the valid statements in
SQL are also valid in FSQL. In addition, FSQL
incorporates some novelties to permit the inexact
processing of information. This chapter will only
provide a summary of the main extensions added
to this language:
• Linguistic labels: If an attribute is capable of
fuzzy treatment, then linguistic labels can be
dened on it. These labels will be preceded
with the symbol $ to distinguish them easily.
There are two types of labels, and they will
be used in different fuzzy attribute types:
1. Labels for attributes with an ordered
underlined domain (Fuzzy Attributes
Type 1 and 2): every label of this type
has associated a trapezoidal possibility
distribution in the FMB. This possibil-
ity distribution is generally trapezoidal,
linear, and normalized, as shown in
Figure 1.
2. Labels for attributes with a non-ordered
fuzzy domain (Fuzzy Attributes Type 3
and 4). Here, a similarity relation may
be dened between each two labels in
the domain, and it should be stored in
the FMB.
• Fuzzy comparators: Besides the typical
comparators (=, >, etc.), FSQL includes all the
fuzzy comparators shown in Table 4. As in
SQL, fuzzy comparators compare one column
with one constant or two columns of the same
(or compatible) type. As possibility compara-
tors are more general (less restrictive) than
necessity comparators, necessity comparators
retrieve fewer tuples, and these tuples neces-
sarily comply with the conditions (whereas
with possibility comparators, the tuples only
possibly comply with the condition, without
any absolute certainty). Is it necessary to note
that fuzzy attributes Type 2 can be compared
with crisp values but always with the FSQL
language.
• Function CDEG: The function CDEG (compat-
ibility degree) may be used with an attribute
in the argument. It computes the fulllment
degree of the condition of the query for the
specic attribute in the argument. We can
use CDEG(*)to obtain the fulllment degree
of each tuple (with all of its attributes, not
just one of them) in the condition. If logic
operators (NOT, AND, OR) appear in the
condition, the calculation of this compatibility
degree is carried out, by default, using the
traditional negation, the minimum t-norm,
Possibility
Necessity Significance
FEQ or F= NFEQ or NF=
Possibly/Necessarily Fuzzy Equal than…
FDIF, F!= or
F<> NFDIF, NF!= or
NF<>
Possibly/Necessarily Fuzzy Different to…
FGT
or
F> NFGT or NF>
Possibly/Necessarily Fuzzy Greater Than…
FGEQ or F>= NFGEQ or NF>=
Possibly/Necessarily Fuzzy Greater or Equal than…
FLT or F< NFLT or NF<
Possibly/Necessarily Fuzzy Less Than…
FLEQ or F<= NFLEQ or NF<=
Possibly/Necessarily Fuzzy Less or Equal than…
MGT or F>> NMGT or NF>>
Possibly/Necessarily Much Greater Than…
MLT or F<< NMLT or NF<<
Possibly/Necessarily Much Less Than…
FINCL INCL
Fuzzy Included in… / Included in…
Table 4. Fuzzy comparators for FSQL (Fuzzy SQL), 16 in the Possibility/Necessity Family, and 2 in the
Inclusion Family
360
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
and the maximum s-norm (or t-conorm), but
the user may change these values.
• Fulllment thresholds: For each simple
condition, a fulllment threshold τ may be
established (default is 1) with the format:
<condition> THOLD τ indicating that the
condition must be satised with minimum
degree τ∈[0,1] to be considered. The reserved
word THOLD (threshold) is optional and may
be substituted by a traditional crisp compara-
tor (=, <, >, >=, etc.), modifying the query
meaning (e.g., to retrieve the less interesting
items).
• Fuzzy constants: Besides the typical con-
stants (numbers, NULL, etc.), FSQL included
many constants such as fuzzy trapezoidal
$[a,b,c,d], approximate values using
the expression #n (approximately n), fuzzy
predened labels using $LabelName, crisp
intervals with [n,m], UNKNOWN, UNDE-
FINED, NULL, and so forth.
• Fuzzy quantiers: There are two types:
absolute and relative. They allow us to use
expressions like “most,” “almost all,” “many,”
“very few,” and so forth.
Example 1: “Give me all persons with fair hair
(in minimum degree 0.5) that are possibly taller than
label $Tall (with a high degree as qualier)”:
SELECT*FROMPerson
WHERE Hair FEQ $Fair THOLD 0.5
AND Height FGT $Tall THOLD $High;
The FuzzyEER Model
A database design methodology has three phases:
conceptual design, logical design, and physical
design. This study looks at conceptual design,
which is the rst phase during which the analysis
of the database requirements takes place. The base
requirements are independent of the data model
that we use. For the conceptual design, the entity/
relationship model (ER model) or the enhanced
ER model (EER) are usually used. Originally, the
conceptual level allows the use of elementary types
of data which are called classical or crisp. These
data types include numerical, alphanumerical, and
binary data. However, the conceptual model does
not always include these data types because they
are usually not very important, so their denition is
normally included in the data dictionary model.
On the other hand, several works have been
proposed in the literature to introduce the fuzzy
concepts in database modeling. The conceptual
modeling tool used in this work is the fuzzy en-
hanced entity relationship (FuzzyEER) model
(Galindo, Urrutia, Carrasco, & Piattini, 2004c;
Galindo, Urrutia, & Piattini, 2004a, 2006; Urrutia
et al., 2002). This model extends the enhanced entity
relationship (EER) model with fuzzy semantics
and fuzzy notations to represent imprecision and
uncertainty in the entities, attributes, and relation-
ships using fuzzy sets and necessity-possibility
measures. The basic concepts introduced in this
model are fuzzy attributes, fuzzy entities, fuzzy
relations, fuzzy degrees, and fuzzy constraints to
mention those only here. We present in Example
5 (Figure 9) a simplied FuzzyEER conceptual
schema. The book Fuzzy Databases: Modeling,
Design and Implementation (Galindo et al., 2006)
presents more details about this model.
A MIGRATION APPROACH
TOWARDS FRDBs
Designing a system that is able to make use of
quantitative and qualitative data for real world
applications is a challenging problem. Traditional
systems produce representational descriptions that
are often not very useful to the human expert.
Using classic logic, it is possible to deal only with
information that is totally true or totally false; it
is not possible to handle information inherent to a
problem that is imprecise or incomplete, but this
type of information contains data that would allow
a better solution to the problem.
In the section titled Introduction to Fuzzy
Sets, we saw that fuzzy logic is an extension of
361
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
the classic systems (Zadeh, 1992). Fuzzy logic is
the logic behind approximate reasoning instead
of exact reasoning. Its importance lies in the fact
that many types of human reasoning, particularly
the reasoning based on expert knowledge, are by
nature approximate. Note the great potential that
the use of membership degrees represents by allow-
ing something qualitative (fuzzy) to be expressed
quantitatively. Besides, a better communication
can be attained through fuzzy logic because of its
ability to utilize natural languages in the form of
linguistic variables (Zadeh, 1975, 1983).(Zadeh, 1975, 1983)..
Closer to our context, database technology has
an extremely successful track record as a backbone
of information technology throughout the last
three decades. To introduce imprecise data, global
information should be managed as fuzzy. The best
solution is to offer a smooth migration toward this
technology. The migration towards FDBs, or fuzzy
migration, does not only constitute the adoption
of a new technology but also, and especially, the
adoption of a new paradigm. Consequently, it con-
stitutes a new culture of development of information
systems. In fact, the fuzzy migration of information
systems consists in modifying or replacing one or
more of their components: database, architecture,
interfaces, applications, and so forth, and generally
the modication of one of these components can
generate modications of some others.
This chapter is about the migration from crisp
databases (relational) towards FDBs in order to
introduce imprecise information in current infor-
mation systems. This fuzzy migration consists in
deriving a new database from a legacy database and
in adapting data, metadata, and the software com-
ponents accordingly. This migration, due generally
to the apparition of new needs in the enterprise,
must answer these requirements while maintaining
the content of the information unaltered. Once the
ex-database is emigrated, the ex-programs must be
changed of such a manner that they reach the new
database instead of the ex-data.
The denition of the fuzzy migration concept
cited above may involve several problems such
as:
• The schemas modication requires a very
detailed knowledge on the data organization
(data types, constraints, etc.).
• The database source is generally badly docu-
mented.
• The difculty of correspondences establish-
ment between the two databases.
• The database models, source, and target can
be incompatible.
• The values in the FMB (metadata) must be
chosen after thorough studies.
• The communication protocols between the
database and their applications are generally
hidden.
• The administrator and at least some database
users need some knowledge about fuzzy
logic.
• Software using fuzzy information must be
designed with care, especially if it will be
utilized by regular users.
Related Work
Although the information systems migration con-
stitutes a very important research domain, there is a
limited number of migration methods. For example,
Tilley and Smith (1996) discuss current issues and
trends in legacy system re-engineering from several
perspectives (engineering, system, software, mana-
gerial, evolutionary, and maintenance). The authors
propose a framework to place re-engineering in
the context of evolutionary systems. The buttery
methodology (Wu, Lawless, Bisbal, Richardson,
Grimson, Wade, & O’Sullivan, 1997) provides a
migration methodology and a generic toolkit for
the methodology to aid engineers in the process
of migrating legacy systems. Different from the
incremental strategy, this methodology eliminates
the need of interoperability between the legacy
and target systems.
Closer to our subject, the Varlet project (Jahnke
& Wadsack, 1999) adopts a process that consists
of two phases. In the rst one, the different parts
of the original database are analyzed to obtain
a logical schema for the implemented physical
schema. In the second phase, this logical schema
362
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
is transformed into a conceptual one, which is
the basis for modication or migration activities.
The approach of Jeusfeld and Johnen (1994) is
divided into three parts: mapping of the original
schema into a metamodel, rearrangement of the
intermediate representation, and production of
the target schema. Some works also address the
migration between two specic systems. Among
those, Menhoudj and Ou-Halima (1996) present a
method to migrate the data of a legacy system into
a RDB management system. Behm et al. (1997)
describe a general approach to migrate RDBs to
object technology. Henrard et al. (2002) and Cleve
(2004) present strategies to migrate date-intensive
applications from a legacy data management system
to a modern one and take the example of conversion
of COBOL les into a SQL database.
In the context of fuzzy databases, few fuzzy
databases implementations have been developed
in real and running systems (Galindo et al., 2006;
Goncalves & Tineo, 2006; Kacprzyk & Zadrożny,
1995, 1999, 2000, 2001; Tineo, 2000). More infor-
mation about these approaches is available in this
handbook in the chapters by Zadrożny et al. and
Urrutia et al. However, we do not know studies
about the migration to fuzzy databases from clas-
sical or regular ones (Ben Hassine, Ounelli, Touzi,
& Galindo, 2007). This chapter covers this gap.
Presentation of Our Approach
Basically, our approach consists in achieving some
fuzzy characteristics in any existing database,
mainly fuzzy queries. We study how to optionally
migrate the data stored in RDBs towards FRDBs.
This approach is addressed mainly to database
administrators (DBA), and it is intended to meet
the following requirements:
• to provide for methodical support of the
migration process,
• to assist DBA in transforming relational
schemas and database,
• to allow DBA to choose the attributes able to
store imprecise data or/and be interrogated
with exible queries,
• to assist DBA in the list of required meta-
data,
• to exploit the full set of FRDBs features,
• to cover properties of the migration itself
such as correctness and completeness.
We adopted in our migration approach three
strategies answering users’ needs:
• Partial migration: Its goal is to keep the
existing data, schema, and applications. The
main benet in this migration is the exible
querying, but also some fuzzy data mining
methods could be implemented on crisp
data.
• Total migration: Its goal is to store imprecise
values and to benet from the exible query-
ing, fuzzy data mining on fuzzy data.
• Easy total migration: Its goal is to store
imprecise values, to benet from the exible
querying, fuzzy data mining on fuzzy data,
and to keep the existing data and applications
with the minimum required modications.
Consequently, all users’ needs are assured. In
the rst strategy, the existing schemas and data
of the database remain unchanged. There is only
the addition of the FMB and the FSQL server to
treat the exible queries. In the second strategy,
two operations in one are aimed: model imprecise
data and interrogate the database with exible
queries. This strategy requires a modication of
the schemas, the data, and eventually the programs
of the database. The third strategy is a mix of the
previous strategies, and the basic idea is only to
add the required fuzzy attributes, but these fuzzy
attributes do not replace the previous existing
classic attributes. Then, we have a redundancy
problem, but if the space is not a problem, then it
is easy to manage.
363
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
PARTIAL MIGRATION
The principle of this migration is based on the fact
that all what is valid in SQL remains also valid in
FSQL. This migration is destined to the designers
who want to keep their RDB while taking advan-
tage of fuzzy queries. The existing schemas and
data of the database remain unchanged. There is
only the addition of at least two elements (Galindo
et al., 2006):
1. The metabase, named FMB, consisted of 12
tables with metadata about the fuzzy informa-
tion (for some applications, we can use less
than these 12 tables).
2. The FSQL server to utilize fuzzy queries.
This server assures the translation of FSQL
statements to SQL, a comprehensible lan-
guage by the DBMS.
Managing Fuzzy Metadata
At the level of the database, the tables of the FMB
are created in order to store the information about
the attributes susceptible to be interrogated by
exible queries. These attributes, and only these
attributes, must be declared in the FMB of type
FTYPE1. The choice of this type is justied by
two reasons:
A. Consistency: FTYPE1 attributes store only
the previous existing crisp data. We must
respect the following rules:
•All the attributes remain unchanged,
including the attributes identiers.
•The quantiable attributes (with ordered
domain, where we can dene trapezoi-
dal possibility distributions, that is, of
type number, real, etc.) which will be
interrogated by fuzzy queries must be
declared like FTYPE1 in the FMB: The
attributes are not modied but they must
be included in the FMB as FTYPE1.
•To include in the FMB the fuzzy attribute
characteristics, detailed in Table 6, rows
1 and 2. This is optional, but it is manda-
tory if we can use such characteristics.
B. Flexibility: Fuzzy attributes FTYPE1 permit
fuzzy queries allowing the use of:
•Fuzzy constants (see The FSQL Lan-
guage section) like linguistic labels
($Hot), approximate values (#30), the
Figure 2. Denition of labels on the FTYPE1 at-
tribute Salary
1
1
0 0.85 1 2 1.2 1.7 2.2 SALARY * 1000 €
$Low $Medium $High
Table 5. Examples of fuzzy querying on a fuzzy attribute Type 1 (Salary)
Type Query Signication
Classic (SQL) SELECT*FROMEmployee
WHERE Salary = 2200;
List of the employees
with a salary equal to 2200 euros.
Fuzzy (FSQL) SELECT*FROMEmployee
WHERE Salary FEQ #2200;
List of the employees
with a salary near to 2200 euros.
Fuzzy (FSQL) SELECT % FROM Employee
WHERE Salary FEQ $High;
List of the employees
with a high salary.
364
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
values UNKNOWN, UNDEFINED, and
NULL, trapezoidal possibility distribu-
tions as well as, of course, crisp val-
ues.
•Fuzzy comparators, useful in this kind
of attribute (the entire Table 4).
•Fulllment thresholds, fuzzy set opera-
tors (fuzzy union, fuzzy intersection,
and fuzzy minus), and functions to
modify fuzzy constants (concentra-
tion, dilatation, contrast intensication,
etc.).
It is necessary to note at this level that the use
of these different concepts is based on many rules.
For example, the linguistic labels dened for the
FTYPE1 attributes must belong to a numerical
domain, and this permits dening the associated
trapezoidal possibility distributions in the FMB.
Example 2: The attribute Salary can be trans-
formed in a fuzzy attribute Type 1. We can also
dene the labels $Low, $Medium, and $High,
for example, as the trapezoidal possibility distri-
butions described in Figure 2. This attribute is
quantiable and have, for example, the euros as
unit of measure. An attribute Productivity cannot
be quantiable. It can take the values “bad,” “regu-
lar,” and “good,” which cannot be represented by
trapezoidal functions. For this reason, we cannot
transform it to fuzzy attribute FTYPE1. We will
show in the following section that this attribute
can be FTYPE3.
Example 3: Table 5 shows three types of que-
ries (classic and fuzzy) that can be applied to the
attribute Salary (FTYPE1) of Example 2. It should
be noted that the FSQL queries must be preceded
by the creation of the label $High and the margin
for approximate values dened on this attribute
in the FMB.
Finally, the partial migration allows three extra
characteristics that may be very useful for many
enterprises:
•Fuzzy degrees (Table 6, row 4): We can
add some different fuzzy degrees to each
table. These attributes were explained in the
subsection titled Fuzzy Degrees As Fuzzy
Values.
•Fuzzy quantiers (Table 6, row 5): We
could answer to questions like: “Give me
the departments in which most of their em-
ployees have a high salary,” and we can add a
minimum threshold to the condition and also
to the quantier. Note that in this example,
quantier “most” is associated to the context
of employee table. FSQL denes four forms
to use fuzzy quantiers. See Galindo et al.
(2006) for details about fuzzy quantiers in
FSQL.
•Fuzzy data nining: The denition of fuzzy
attributes Type 1 allows using many fuzzy
data mining methods. In this volume, there
is a chapter by Feil and Abonyi summariz-
ing these methods. In particular, FSQL is a
powerful tool for these purposes (Carrasco,
Vila, & Galindo, 2003; Galindo etal., 2006),, 2003; Galindo et al., 2006),
and it is shown in the chapter by Carrasco et
al. in this handbook.
The FSQL Server
At the level of the DBMS, the FSQL server is placed
over the DBMS to treat the exible statements
(queries, deletions, updates, etc.) written in FSQL
language. Figure 3 shows the DBMS architecture
with the FSQL server.
Figure 3. FBD architecture
DB
FMB
RDBMS
FSQL Server
Flexible statements
Classic statements
365
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
TOTAL MIGRATION
This strategy offers, in addition to the exible
querying, the possibility to store imprecise data at
the level of the fuzzy attributes. Therefore, it will
be a total migration towards the FRDB. Contrary
to the previous case, the attributes susceptible to
store imprecise data are of type FTYPE2, FTYPE3,
and FTYPE4, and besides, some degrees may be
included (types 5-8). The modication concerns
only the tables dened or referenced to these
attributes. This strategy comprises three main
steps: (Step 1) schemas conversion, (Step 2) data
conversion, and (Step 3) programs conversion. Note
that this type of decomposition has already been
used by Henrard et al. (2002); Henrard, Cleve, and
Hainaut (2004); Cleve (2004); and Cleve, Henrard,
and Hainaut (2005) to integrate some systems at
the time of the reengineering of a database.
Figure 4 shows, in the left part, the main parts
of the legacy system, comprising programs that
interact with the legacy data through the legacy
DBMS and through the legacy schema. The right
part shows the state of the new system after the
legacy DBMS has been extended with the FSQL
server (Fuzzy DBMS) and the database with the
FMB. The new database comprises the converted
schema and data that have been transformed and
migrated according to the new schema. Legacy
programs have been transformed in such a way that
they now access the data through the API of the
new technology and through the new schema. When
the converted system is deployed, new programs
can be developed, that use the database through the
native interface of the new fuzzy DBMS. Later on,
if and when needed, the legacy programs could be
rewritten according to the new technology.
Step 1: Database Schemas Migration
The schema conversion is the translation of the
legacy database structure, or schema, into an
equivalent database structure expressed in the new
technology (Henrard et al., 2002). In our context,
it consists in modifying the table schemas with
fuzzy attributes which are going to store fuzzy
values. Moreover, the FMB, which stores the fuzzy
Figure 4. System conversion
New system
Fuzzy DBMS
RDBMS
FSQL
New
Pro
g
rams
Legacy
Pro
g
rams
New Data
(
cris
p
+ fuzz
y)
FMB
New schema
Legacy system
DBM
S
Legacy Programs
Legacy Data
(
cris
p)
Legacy schema
Figure 5. Physical schema conversion
Fuzzy physical
schema
(
FPS
)
Target DDL script
(FSQL)
SQL Coding
Source DDL script
(SQL)
Source physical
schema
(
SPS
)
DDL script Analysis
DB
1. Modify fuzzy
FMB
2. Update FMB tables: see
Algorithm 1
366
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
Table 6. Fuzzy metadata stored in the FMB
1. Information concerning fuzzy attributes (see Fuzzy Attributes section):
• Fuzzy type, unit of measurement, comments, etc.
2. Fuzzy attributes FTYPE1 and FTYPE2:
• Fuzzy objects dened on these attributes: trapezoidal labels, qualiers, quantiers, etc.
• Margin for approximate values (the meaning of #n in the context of each attribute).
• MUCH value: The minimum distance in order to consider two values as very separated: This is necessary for
comparators MGT, NMGT, MLT, and NMLT (see Table 4).
• n value: Maximum number of points in the possibility distributions of new types 11 and 12 of Table 2.
3. Fuzzy attributes FTYPE3 and FTYPE4:
• Fuzzy objects dened on these attributes: linguistic labels, qualiers, quantiers, etc.
• n value: Maximum number of elements in the possibility distributions (see Table 3).
• Compatible attributes.
• Similarity measures between labels, only for FTYPE3.
4. Fuzzy degrees:Fuzzy degrees:
• Meanings of these fuzzy degrees (importance, membership, etc.).
• Association: Table, column, set of columns or without association.
5. Quantiers associated to tables or general quantiers for the general system.Quantiers associated to tables or general quantiers for the general system.
attributes information (linguistic labels, similar-
ity relations, etc.), is created. In fact, the FMB is
joined to the data dictionary in order to know the
data types, the fuzzy objects dened over the fuzzy
attributes, and so forth. Hence, the FMB extends
the data dictionary in order to treat the new fuzzy
attributes and their objects. During this process,
the source physical schema (SPS) of the RDB is
extracted and then transformed in a correspondent
physical schema in the fuzzy DBMS. The new
physical schema is used to produce the DDL (data
denition language) code of the new FRDB. In this
section, we present two strategies of transforma-
tions or conversions (physical schema conversion
and conceptual schema conversion).
Physical Schema Conversion
The physical schema conversion consists of analyz-
ing the DDL code of the source RDB in order to
nd its physical schema. The DDL code may be
obtained from the data dictionary, and it expresses
the source physical schema. This relational schema
will be converted in the fuzzy DBMS modifying
attributes and adding the FMB. Table 6 shows
the information stored in the FMB for each fuzzy
attribute. Figure 5 illustrates the process of this
transformation: the source DDL script written
in SQL is parsed to extract the physical schema.
This schema includes all the data structures and
constraints explicitly declared into the DDL code
which will be converted to the target “fuzzy” physi-
cal schema (FPS), according to the Algorithm 1.
This conversion returns the target DDL script, the
new schema, which is easy to create using SQL.
This last is executed then to generate the FRDB.
Among this conversion, some classic attributes are
transformed into fuzzy ones. Algorithm 1 presents
general ideas about this transformation at the level
of the database (modication of the structure of
tables with fuzzy attributes) and at the level of the
FMB (updating tables with fuzzy metadata: labels,
similarity relations, quantiers, etc.). Note that this
strategy can use simple tools only, such as a DDL
parser (to extract the SPS), an elementary schema
converter (to transform the SPS into the FPS) and
a DDL generator.
367
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
Algorithm 1 modies the database schema for
each fuzzy attribute. Note that we do not use the
DDL statements of FSQL, because we want to
show the inner schema in this conversion.
Example 4: Suppose the physical schema con-
stituted of the tables EMPLOYEE, PROJECT, and
WORKS_ON. Figure 6 shows the modications
done at the level of the fuzzy attributes:
•Salary: FTYPE1 with the linguistic terms
low, medium, and high.
•Age: FTYPE2 with the linguistic terms young,
adult, and old.
•Budget: FTYPE2 with the linguistic terms
small, medium, and big.
•Productivity: FTYPE3 with the linguistic
terms bad, regular, and good.
Note that, for example, attribute Budget is
represented now with ve classic attributes, and
the Productivity attribute is transformed in three
attributes. Figure 7 shows the modications done
Algorithm 1. Physical schema transformation
Input: SPS (RDB)
Output: FPS (FRDB)
Begin
To create the FMB tables.
for each attribute A of SPS
do
if A remains classic
then
no modification in its definition;
else
{ /* This treatment is divided in two under-treatments : in the database and in the FMB */
switch
(type of A) { /*
Modify the tables structure according to each fuzzy type */
case FTYPE1:
A remains unchanged.
case FTYPE2:
create at least 5 attributes with the following names:
concatenate the first one with the letter ’T’: AT;
concatenate the others ones respectively with 1, 2, 3, 4, … 2n: A1, A2, A3, A4…;
/* Note that 2n must be at least 4. Then the minimum value for n is 2. */
case FTYPE3 and FTYPE4:
create 2n+1 attributes with the following names:
concatenate the first one with the letter ’T’ (AT);
for each i = 1, … n
do {
/*
n =max. number of elements in the pos. distributions */
concatenate the first attribute with
Pi;
concatenate the following with
i; /* (AP1, A1, AP2, A2,... , APn, An) */
}
}
Update
the FMB tables with the metadata about all fuzzy attributes: see Table 6.
}
End.
Figure 6. Example of physical schema conversion
at the level of the database
Fuzzy Relational Physical schema
EMPLOYEE
Matriculate
Name
Salary
AgeT
Age1
Age2
Age3
Age4
ProductivityT
ProductivityP1
Productivity1
PROJECT
Num_project
Name_project
BudgetT
Budget1
Budget2
Budget3
Budget4
WORKS_ON
Matriculate
Num_project
Nb_hours
FRDB
Relational Physical schema
EMPLOYEE
Matriculate
Name
Salary
Age
Productivity
PROJECT
Num_project
Name_project
Budget
WORKS_ON
Matriculate
Num_project
Nb_hours
RDB
368
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
Figure 7. Example of physical schema conversion at the level of the FMB
369
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
Figure 8. Conceptual schema conversion
DBRE
Source
DDL
scri
p
t
(
SQL
)
SPS
SCS
DDL Analysis
Schema refinement
Conceptualization
FPS
Target DDL
scri
p
t
(
FSQL
)
FCS
Coding
-FDB Design -
Schema conversion
(Fuzzification of some
attributes)
Figure 9. Examples of conceptual schema conversion
(a)
Legacy Conceptual schema
(1..n)
(1..1)
Works_For
(0..n)
(1..n)
(0..n)
(1..1)
Works_On Controls
Salary
Age
EMPL
O
YEE
Matriculate
Productivity
Name
PROJECT
Name_project
Bud
g
et
Num
_p
ro
j
ect
Num_dep
DEPARTMENT
Name_dep
(b)
Fuzzy EER schema
Matriculate
Name
T1: Salary {low, medium, high}
T2: Age {young, adult, old}
T3: Productivity {bad, regular, good}
Num_project
Name_project
T2: Budget {small, medium, big}
Num_dep
Name_dep
DEPARTMENT
(0, approx 20 [0.25, 0.75]) (approx 2, approx 30 [0.25])
PROJECT
Works_On
(
1..n
)
(
1..1
)
Works_For
EMPLOYEE
(0..n)
Controls
(1..1)
370
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
Conceptual Schema Conversion
The conceptual schema conversion consists in
extracting the physical schema conversion of the
legacy database (SPS) and transforming it into
its correspondent conceptual schema through a
database reverse engineering (DBRE)3 process.
Figure 8 describes this process.
First of all, the source DDL script written in
SQL is parsed in order to extract the source physi-
cal schema (SPS). This last is rened through an
in-depth inspection of the way that the program
uses and manages the data. The nal DBRE step
is the conceptualization that interprets the physical
schema into the source conceptual schema (SCS).
Then, a phase for FDB design makes a schema
conversion, introducing new concepts (fuzzy
constraints, fuzzy attributes, etc.) (Galindo et al.,
2004a, 2004c, 2006; Urrutia et al., 2002). This
transformation produces the fuzzy conceptual
schema (FCS), and then the fuzzy physical schema
(FPS), which is coded in the nal DDL script of
the FRDB.
At this level, we have two options:
Algorithm 2. Data transformation
FRDB
3. Data storage
Expert
New
needs
1. Data
Extraction
RDB
2. Data
Conversion
2. Fuzzification
of some data
Figure 10. Data migration
Input: Source data (RDB)
Output: Target data (FRDB)
Begin
for each
attribute A of DML script do
for each
value v in A (for each row in the database table) do
switch (Type of A)
do {
case Classic and FTYPE1:
Insert
v in its reserved field (no change);
case FTYPE2:
if
v=NULL
then
Attribute AT=2 and A1=A2=A3=A4=NULL;
else /* v is a crisp value */
AT=3, A1=v and A2=A3=A4=NULL;
case FTYPE3 and FTYPE4:
if
v=NULL
then
Attribute AT=2 and AP1=A1=NULL;
else /* v is a crisp value as text-label */
AT=3, AP1=1 and A1=v;
}
End
in the FMB tables. We include here a brief explana-
tion of these tables: Table FCL stores all the fuzzy
attributes (type, unit of measurement, etc.). Table
FAM stores the margin for approximate values
and the minimum distance for two values consid-
ered very separated for all FTYPE1 and FTYPE2
attributes. Table FOL includes all fuzzy objects
belonging to all fuzzy attribute types (only labels
in our example). Table FLD includes the denition
of trapezoidal labels for FTYPE1 and FTYPE2
attributes (the four basic values, like in Figure 1).
Table FND stores the similarity relation between
each labels of a FTYPE3 attribute. Of course, the
FMB needs more tables with different information
(Galindo et al., 2006).
371
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
1. To CREATE new tables, copy values from
old tables and, optionally, drop old tables and
rename new tables (the best option).
2. To ALTER old tables and to preserve current
information, we must only store old attributes
values (which will be converted in fuzzy
attributes) in temporary tables, modify the
structures of this tables, convert old attributes
values to fuzzy attributes values, and copy
them according to the new fuzzy attributes
structure (Tables 2 and 3).
It is necessary to note that during the database
design step, the choice of the most suitable fuzzy
attribute type is a delicate task. The presence of an
expert in FRDB design must be counseled strongly
due to the complexity of the assimilation of the
different fuzzy concepts (Ben Hassine, Touzi, &
Ounelli, 2007).
Example 5: Figure 9 shows an example of
conceptual schema conversion from a legacy con-
ceptual schema to a FuzzyEER schema. Attribute
Salary is transformed to FTYPE1, Age and Budget
to FTYPE2, and Productivity to FTYPE3. The other
attributes and primary keys remain unchanged.
The constraints of the source ER schema can be
transformed also to fuzzy constraints using the
fuzzy (min, max) notation as this presented in the
relationship Works_On. For example, in the PROJ-
ECT side, the (min, max) constraint indicates that
in each project must work a minimum of approxi-
mately two employees (with a minimum degree of
0.5). At the same time, the number of employees
in each project must not exceed approximately 30
(with a minimum degree of 0.25).
Step 2: Data Migration
The data conversion consists in transforming the
data of the RDB (crisp) to the format of the data
dened by the fuzzy schema. It involves data
transformations that materialize the schema trans-
formations described above. These transformations
include three stages as shown in Figure 10. The rst
step consists in extracting the data from the data-
base. This extraction takes in account the different
kind of constraints, data coherence, security, and so
forth. The second step consists in converting these
data in such a way that their structures coincide
with the new format of the target FRDB schema.
This transformation is made automatically using
algorithm 2, or manually using expert knowledge
as we will explain later. Finally, the data will be
stored in the FRDB.
However, during this transformation, there is a
modication in the data representation for fuzzy
attributes at the level of the database tables (see
Tables 2 and 3 and the example in Figure 6) while
introducing the data values according to their types
Table 7. Table EMPLOYEE source
Matriculate Name Salary Age ···
005201 Habib 2000 50 ···
005202 Mohamed Ali 2000 45 ···
005203 José 2100 40 ···
005204 Amel 2200 NULL ···
Table 8. Example of data conversion of the table EMPLOYEE for attribute FTYPE2 Age
Matriculate Name Salary AgeT Age1 Age2 Age3 Age4 ···
00521 Habib 2000 3 50 NULL NULL NULL ···
00522 Mohamed Ali 2000 4 1 (Id. for Adult) NULL NULL NULL ···
00523 José 2100 6 40 30 50 10 ···
005204 Amel 2200 0 NULL NULL NULL NULL ···
372
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
(label: 4, approximate values: 6/8, unknown: 0, pos-
sibility distribution: 9-12, etc.), and at the level of
the FMB tables while introducing their parameters
(four parameters for trapezoidal labels, etc.).
It should be noted that if we want to “fuzzify”
some previous data, then the transformation is not
automated. Fuzzy information may be more real
than crisp information. For this reason, the inter-
vention of an expert in FRDB design and in the
database domain is strongly counseled in order to
choose the most suitable type among the different
types of fuzzy values mentioned previously (Ben
Hassine et al., 2007). Sometimes, the crisp data
can be kept. In other cases, they will be trans-
formed, using some standard rules, in linguistic
terms, intervals, approximate values, and so forth,
Especially in some contexts, NULL values may be
transformed into UNKNOWN values.
Algorithm 2 presents the automatic modica-
tion. This step shows the advantages of the migra-
tion towards the FRDBs in terms of imprecise data
modeling. It is important to note that in the legacy
database, all attributes are crisp: Then, the transla-
tion is very easy; we have to choose between two
values: NULL or crisp. Another easy transforma-
tion is, for example, to store approximate values
for FTYPE2 attributes: Attribute AT=6, A1=v,
A2=v−margin, A3=v+margin, and A4=margin
(values in A2, A3, and A4 are only for increasing
the efciency).
Example 6: Suppose the relation Employee
described in Table 7, schema in Figure 6, where
we assigned the FTYPE1 to the attribute Salary,
and the FTYPE2 to Age. Since the attribute salary
does not have any transformation at the level of the
database, only the attribute Age is transformed,
as shown in Table 8.
All fuzzy data are represented by a number.
Also, every fuzzy object has an identier in the
FMB. In our example, the attribute AgeT stores
the kind of data stored about the Age (see Table
2). The parameters of this data are stored in the
remaining attributes.
•The employee Habib keeps the crisp value
50 years. This value (50) and its type (3) are
stored respectively in the elds Age1 and
AgeT.
•The age of Mohamed Ali receives the lin-
guistic label adult, which must be rst of
all created (with the command CREATE
LABEL) and stored in the FMB as shown
in Figure 7. The identier of this label will
be stored in the eld Age1, while specifying
its type (4) in the eld AgeT.
•The employee José stores an approximate
value of 40 years old with a margin of 10. We
store 40 in the eld Age1 and its identier in
AgeT (6).
•The age of Amel stores NULL value, but in
this case we can translate it to UNKNOWN
(because we know that every person has some
Age).
Step 3: Programs Migration
The modication of the structure of the database
requires, in the majority of the cases, propagation
to the level of their related programs. Since that
is not the rst interest of this work, we present an
overview of programs conversion. In fact, if we
want to use exible queries and to store imprecise
data, the communication between programs and
the database must be through the FSQL server.
The programs must be modied according to the
representation, interrogation, and storage of the
new data. Moreover, we must decide what to do
with fuzzy values in each program. Note that emi-
grating these programs not only means to convert
DBMS calls in programs, but in addition requires
the reengineering of imperative programs to ac-
cept fuzzy values and surely the reconstruction
of user interfaces.
We draw our inspiration from the strategies
of programs conversion proposed by Henrard et
al. (2002, 2004) and Cleve (2004). One of these
strategies relies on wrappers that encapsulate the
FRDB. This strategy allows interaction of the
application programs with the legacy data ac-
373
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
cess logic through these wrappers instead of the
legacy DBMS. These wrappers are in the form of
a software layer permitting the translation of the
previous statements written in SQL to the FSQL
language (fuzzication in the statement, not in the
data). The FSQL server translates in turn these
queries to SQL language (defuzzication in the
statement). The fuzzy returned answers will be
defuzzied in order to be treated by the applica-
tion programs. This process is depicted in Figure
11. The second strategy consists in rewriting the
access statements in order to make them process
the new data through the new fuzzy DBMS-DML.
Each DML statement must be located, its param-
eters must be identied, and the new fuzzy DML
statement sequence must be dened and inserted
in the code. This task may be complex because
legacy program will manage imprecise data instead
of legacy crisp ones.
The third strategy generalizes the problems
met in the second strategy. In fact, the change
of paradigm when moving from standard crisp
data in RDB to imprecise ones in FRDB induces
problems such as whether the user wants now to
use fuzzy information in FSQL statements and
the manipulation of the imprecise data returned
by these statements. The program is rewritten in
order to use the new fuzzy DBMS-DML at its full
power and take advantage of the new data system
features. This strategy is much more complex than
the previous one since every part of the program
may be inuenced by the schema transformation.
The most obvious steps consist of:
1. Identifying the statements and the data objects
that depend on these access statements,
2. Deciding whether each statements will be
now fuzzy or not,
3. Rewriting these statements and redening
its data objects, and
4. Treating the possibly fuzziness in returned
answers.
EASY TOTAL MIGRATION
As we have shown, the migration of programs
may be a very hard task in this process, but it is
mandatory and essential in the total migration.
With the Easy Total Migration, we achieve a
total fuzzy database (storing fuzzy values, fuzzy(storing fuzzy values, fuzzystoring fuzzy values, fuzzy
querying, and fuzzy data mining on fuzzy data)
and also keep the existing data and applications
with the minimum required modications. The
basic idea is to mix partial and total migration;
that is, fuzzy attributes with fuzzy values are du-
plicated: one with fuzzy values and the other with
only crisp values. In this process, we use the three
Figure 11. Programs migration based on wrappers
Defuzzified data
Data
Defuzzification (FSQL SQL)
Fuzzification (SQL FSQL)
Legacy programs
Wrapper
FSQL server
RDBMS
FRDB + FMB
Resulting data
Stantard Crisp Statement
Carrying out the statement
⇒
⇒
374
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
steps of the total migration with some modica-
tions: (Step 1) schemas conversion, (Step 2) data
conversion, and (Step 3) programs conversion. The
steps 1 and 2 are equal but now we preserve the
old attributes. For example, if the Age attribute is
a fuzzied attribute and converted to FTYPE2,
then we preserve the existing Age attribute and
add the new attributes AgeT, Age1, Age2, Age3,
and Age4 (like in Table 8).
The program conversion is now easier, but we
must manage the new fuzzy attributes in some DML
statements in order to achieve legacy programs
running exactly like before the migration:
1. SELECT: No modications required (except
if the SELECT uses the asterisk, *, because
it represents all the attributes and in the new
FRDB there are more attributes).
2. DELETE: No modications required.
3. INSERT: The values of the fuzzied attri-
butes must be inserted again in the same row
in the corresponding new fuzzy attributes
(Algorithm 2).
4. UPDATE: The values of the fuzzied attri-
butes must also be updated in the same row
in the corresponding new fuzzy attributes
(Algorithm 2).
The main drawback of this migration strategy
is the redundancy in the fuzzied attributes (ex-
cept the FTYPE1). The main advantage is the easy
program migration. In some situations, this is the
best option, using this strategy as an intermediate
and temporary step to a total migration.
CONCLUSION
Several real applications need to manage impre-
cise data and to benet its users from the exible
querying (Bosc et al., 1998). Several theoretical
solutions have been proposed (Bosc & Pivert, 1995;
Buckles & Petry, 1982; Galindo, 1999; Medina
et al., 1994; Umano, 1982; Zemankova-Leech &
Kandel, 1985). Unfortunately, the repercussions
of these works on the practical level are negli-
gible, even with the existence of some prototypes
as FSQL server (Galindo et al., 1998, 2006). In
this chapter, we proposed a migration approach
from RDBs towards the generation of FRDBs.
This approach is addressed mainly to database
administrators and enterprises interested in such
a fuzzy migration.
We proposed three possible strategies for this
migration. The rst strategy, is called partial mi-
gration and enjoys some of the advantages of the
FRDBs while preserving the existing schema, data,
and applications. The second approach, named total
migration, consists in beneting from all FRDBs
advantages (imprecise data storage, exibility in
queries, etc.). It allows an easy mapping of the exist-
ing data, schemas, and programs, while integrating
the different fuzzy concepts. This strategy, based
on the Henrard et al. (2002) approach, has three
levels of conversions: conversion of the physical
schema that generally can be preceded by a con-
ceptual schema conversion, data conversion, and
applications conversion. We studied in detail the
rst two levels. The applications conversion, or
migration of programs, may be a very hard task
in this process, but it is mandatory and essential in
the total migration and must be made with experts
in fuzzy databases and in the database domain.
The third strategy, called easy total migration, is
a mixture of the previous two strategies, generally
as a temporary step. This option is easier and faster
than the total migration and may be a good option
in order to make the migration of programs slowly
but painstakingly.
As for perspectives on the future of this work,
we mention (1) the automation of conversion of
the schema, data, and applications, following
the algorithms dened in this chapter and (2) the
addition of an expert system to help the designer
choose the appropriate fuzzy attributes type and
other fuzzy objects (labels, quantiers, etc.). This
last point also contributes to the use of the FRDBs
easier in real applications. In fact, one of the meted
problems during the FRDBs design is to determine
the attributes (columns) susceptible to store fuzzy
375
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
data and to choose their respective data types. The
type assignment to these attributes is not an obvi-
ous task. This choice asks the designer, on the one
hand, to know in a detailed way the properties of
every fuzzy attribute type and, on the other hand,
to really qualify the attribute in order to affect it
the most suitable type among the four types of
fuzzy attributes mentioned previously. We started
working in order to solve this problem, and we
have implemented an expert system to choose the
suitable attribute type. It can also easily treat other
fuzzy models by enriching its knowledge base. We
are working now to combine this expert system
in such a way that the migration process will be
automated. We think that the automation of this
migration will be a useful starting point in order to
generalize the FDBs in the real database world.
ACKNOWLEDGMENT
This work has been partially supported by the
“Ministry of Education and Science” of Spain
(projects TIN2006-14285 and TIN2006-07262)
and the Spanish “Consejería de Innovación Ciencia
y Empresa de Andalucía” under research project
TIC-1570.
REFERENCES
Behm, A., Geppert, A., & Dittrich, K. R. (1997).
On the migration of relational schemas and data
to object-oriented database systems. In J. Gyrks,
M. Krisper, & H. C. Mayr (Eds.), Proceedings
of the 5th International Conference on Re-Tech-
nologies for Information Systems (pp. 13-33).
Klagenfurt, Austria: Oesterreichische Computer
Gesellschaft.
Bellman, R. E., & Zadeh, L. A. (1970). Decision-
making in a fuzzy environment. Management
Sciences, 17(4), 141-175.
Ben Hassine, M. A., Ounelli, H., Touzi, A. G., &
Galindo, J. (2007, July). A migration approach from
crisp databases to fuzzy databases. In Proceedings
of the IEEE International Conference FUZZ-IEEE
2007), London, UK (pp. 1872-1879).
Ben Hassine, M. A., Touzi, A. G., & Ounelli, H.
(2007). About the choice of data type in a fuzzy
relational database. In B. Gupta (Ed.), Proceed-
ings of the 22nd International Conference on
Computers and Their Applications (CATA-2007)
(pp. 231-238).
Bosc, P. (1999). Fuzzy databases. In J. Bezdek
(Ed.), Fuzzy sets in approximate reasoning and
information systems (pp. 403-468). Boston: Kluwer
Academic Publishers.
Bosc, P., Liétard, L., & Pivert, O. (1998). BasesBases
de données et exibilité: Les requêtes graduelles.
Techniques et Sciences Informatiques, 17(3), 355-
378.
Bosc, P., & Pivert, O. (1995). SQLf: A relational
database language for fuzzy querying. IEEE
Transactions on Fuzzy Systems, 3, 1-17.
Bosc, P., & Pivert, O. (1997). Fuzzy queries against
regular and fuzzy databases. In T. Andreasen, H.
Christiansen, & H. L. Larsen (Eds.), Flexible query
answering systems. Dordrecht: Kluwer Academic
Publishers.
Bosc, P., & Pivert, O. (2000). SQLf query func-
tionality on top of a regular relational database
management. In O. Pons, M. A. Vila, & J. Kacprzyk
(Eds.), Knowledge management in fuzzy databases
(pp. 171-190). Heidelberg: Physica-Verlag.
Buckles, B. P., & Petry, F. E. (1982). A fuzzy rep-
resentation of data for relational databases. Fuzzy
Sets and Systems, 7, 213-226.
Carrasco, R., Vila, M. A., & Galindo, J. (2003).
FSQL: A exible query language for data mining.
Enterprise Information Systems, IV, 68-74. Hing-
ham, MA: Kluwer Academic Publishers.
Cleve, A. (2004). Data centered applications
conversion using program transformations.
Unpublished doctoral dissertation, Namur.
376
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
Cleve, A., Henrard, J., & Hainaut, J.-L. (2005).
Co-transformations in information system re-
engineering. In Proceedings of the 2nd Interna-
tional Workshop on Meta-Models, Schemas and
Grammars for Reverse Engineering Collection.
Electronic Notes in Theoretical Computer Sci-
ence, 137(3), 5-15.
De Caluwe, R., & De Tré, G. (Eds.). (2007). Preface
to the special issue on advances in fuzzy database
technology. International Journal of Intelligent
Systems, 22(7), 662-663.
Dubois, D., & Prade, H. (1997). Using fuzzy sets in
exible querying: Why and how? In T. Andreasen,
H. Christiansen, H. L. Larsen (Eds.), Flexible query
answering systems (pp. 45-60). Kluwer Academic
Publishers.
Elmasri, R., & Navathe, S. B. (2006). Fundamentals
of database systems (5th ed.). Addison-Wesley.Addison-Wesley.
Galindo, J. (1999). Tratamiento de la imprecisión en
bases de datos relacionales: Extensión del modelo
y adaptación de los SGBD actuales. Doctoral dis-Doctoral dis-
sertation, University of Granada, Spain. Retrieved
February 9, 2008, from http://www.lcc.uma.es
Galindo, J. (2005). New characteristics in FSQL:
A fuzzy SQL for fuzzy databases. WSEAS Trans-
actions on Information Science and Applications,
2(2), 161-169.
Galindo, J. (2007). FSQL (fuzzy SQL): A fuzzy
query language. Retrieved February 9, 2008, from
http://www.lcc.uma.es/~ppgg/FSQL
Galindo, J., Aranda, M. C., Caro, J. L., Guevara,
A., & Aguayo, A. (2002). Applying fuzzy da-Applying fuzzy da-
tabases and FSQL to the management of rural
accommodation. Tourist Management Journal,
23(6), 623-629.
Galindo, J., Medina, J. M., & Aranda, M. C. (1999).
Querying fuzzy relational databases through fuzzy
domain calculus. International Journal of Intel-
ligent Systems, 14, 375-411.
Galindo, J., Medina, M., Pons, O., & Cubero, J.
C. (1998). A server for fuzzy SQL queries. In T.
Andreasen, H. Christiansen, & H. L. Larsen (Eds.),
Lecture Notes in Articial Intelligence (Vol. 1495):
Flexible query answering systems (pp. 164-174).
Springer.
Galindo, J., Urrutia, A., Carrasco, R., & Piattini, M.
(2004c). Relaxing constraints in enhanced entity-
relationship models using fuzzy quantiers. IEEE
Transactions on Fuzzy Systems, 12(6), 780-796.
Galindo, J., Urrutia, A., & Piattini, M. (2004a).
Fuzzy aggregations and fuzzy specializations in
fuzzy EER model. In K. Siau (Ed.), Advanced top-
ics in database research (pp. 105-126). Hershey,
PA: Idea Group Publishing.
Galindo, J., Urrutia, A., & Piattini, M. (2004b).
Representation of fuzzy knowledge in relational
databases. In Proceedings of the 15th International
Workshop on Database and Expert Systems Appli-
cations (pp. 917-921). IEEE Computer Society.
Galindo, J., Urrutia, A., & Piattini, M. (2006). Fuzzy
databases: Modeling, design and implementation.
Hershey, PA: Idea Group Publishing.
Goncalves, M., & Tineo, L. (2006). SQLf vs. Sky-
line: Expressivity and performance. In Proceed-
ings of the 15th IEEE International Conference
on Fuzzy Systems Fuzz-IEEE 2006, Vancouver,
Canada (pp. 2062- 2067).
Henrard, J., Cleve, A., & Hainaut, J.-L. (2004).
Inverse wrappers for legacy information systems
migration. In T. Philippe & V. D. H. Willem-Jan
(Eds.), Proceedings of the 1st International Work-
shop on Wrapper Techniques for Legacy Systems
(WRAP’04) (pp. 30-43). Technische Universiteit
Eindhoven Publish.
Henrard, J., Hick, J. M., Thiran, P., & Hainaut,
J.-L. (2002). Strategies for data reengineering.
In Proceeding of the 9th Working Conference on
Reverse Engineering (pp. 211-220). IEEE Computer
Society Press.
Jahnke, J. H., & Wadsack, J. P. (1999). Varlet:
Human-centered tool support for database reen-
gineering. In J. Ebert, B. Kulllbach, & F. Lehner
377
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
(Eds.), Proceedings of the Workshop on Software-
Reengineering, Bad Honnef, Germany.
Jeusfeld, M., & Johnen, U. A. (1994). An execut-
able meta model for re-engineering of database
schemas. In Proceedings of the Conference on
the Entity-Relationship Approach (pp. 533-547).
Manchester, UK: Springer-Verlag.
Kacprzyk, J., & Zadrożny, S. (1995). FQUERY
for Access: Fuzzy querying for Windows-based
DBMS. In P. Bosc & J. Kacprzyk (Eds.), Fuzziness
in database management systems (pp. 415-433).
Heidelberg, Germany: Physica-Verlag.
Kacprzyk, J., & Zadrożny,S.(1999). Theparadigmżny, S.(1999).Theparadigmny, S. (1999). The paradigm
of computing with words in intelligent database
querying. In L. A. Zadeh & J. Kacprzyk (Eds.),
Computing with words in information intelligent
systems (Part 1. Foundations, Part 2. Applications,
pp. 382-398). Heidelberg/New York: Springer-
Verlag.
Kacprzyk, J., & Zadrożny, S. (2000). On a fuzzy
querying and data mining interface. Kybernetika,
36, 657-670.
Kacprzyk, J., & Zadrożny, S. (2001). Computingżny, S. (2001). Computingny, S. (2001). Computing
with words in intelligent database querying: Stand-
alone and Internet-based applications. Information
Sciences, 134, 71-109.
Maraboli, R., & Abarzua, J. (2006). FSQL-f
representación y consulta por medio del leguaje
PL/PGSQL de información imperfecta. Degree
thesis, Universidad Católica del Maule, Ingeniero
en Computación e Informática, Chile.
Medina, J. M., Pons, O., & Vila, M. A. (1994a).
GEFRED: A generalized model of fuzzy relational
databases. Information Sciences, 76(1-2), 87-109.
Medina, J. M., Pons, O., & Vila, M. A. (1994b).
An elemental processor of fuzzy SQL. Mathware
and Soft Computing, 3, 285-290.
Medina, J. M., Pons, O., & Vila, M. A. (1995).
FIRST: A fuzzy interface for relational systems. In
Proceedings of the 6th International Fuzzy Systems
Association World Congress, Brazil.
Menhoudj, K., & Ou-Halima, M. (1996). MigratingMigrating
data-oriented applications to a relational database
management system. In Proceedings of the 3rd
International Workshop on Advances in Databases
and Information Systems (ADBIS 1996) (pp. 102-
108), Moscow.
Pedrycz, W., & Gomide, F. (1998). An introduc-
tion to fuzzy sets: Analysis and design. MIT Press.
ISBN 0-262-16171-0.
Petry, F. E. (1996). Fuzzy databases: Principles
and applications (International Series in Intelli-
gent Technologies). Kluwer Academic Publishers
(KAP).
Prade, H., & Testmale, C. (1987). Fuzzy relational
databases: Representational issues and reduction
using similarity measures. Journal of the American
Society of Information Sciences, 38(2), 118-126.
Silberschatz, A., Korth, H. F., Sudarshan, S.
(2006). Database systems concepts (5th ed.). Mc-
Graw-Hill.
Tahani, V. (1977). A conceptual framework for
fuzzy query processing: A step toward very intel-
ligent database systems. Information Processing
and Management, 13, 289-303.
Takahashi, Y. (1993). Fuzzy database query lan-
guages and their relational completeness theorem.
IEEE Transactions on Knowledge and Data En-
gineering, 5(1), 122-125.
Thiran, P., & Hainaut, J.-L. (2001). Wrapper devel-
opment for legacy data reuse. In Proceedings of the
8th Working Conference on Reverse Engineering
(pp. 198-207). Washington, DC: IEEE Computer
Society Press.
Tilley, S. R., & Smith, D. B. (1996). Perspectives
on legacy system reengineering. Carnegie Mellon
University: Software Engineering Institute.
Tineo, L. (2000). Extending RDBMS for allowing
fuzzy quantied queries 1. In M. Revell (Ed.),
Lecture Notes in Computer Science, 1873, 407-416.
Berlin: Springer-Verlag.
378
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
Umano, M. (1982). Freedom-O: A fuzzy database
system. In M. Gupta & E. Sanchez (Eds.), Fuzzy
information and decision processes (pp. 339-347).
Amsterdam: North-Holland.
Umano, M., & Fukami, S. (1994). Fuzzy relational
algebra for possibility-distribution-fuzzy relational
model of fuzzy data. Journal of Intelligent Infor-
mation Systems, 3, 7-27.
Urrutia, A., Galindo, J., & Piattini, M. (2002).
Modeling data using fuzzy attributes. In Proceed-
ings of the 22nd International Conference of the
Chilean Computer Science Society (SCCC’02) (pp.
117-123). Chile: Computer Science Society.
Wu, B., Lawless, D., Bisbal, J., Richardson, R.,
Grimson, J., Wade, V., & O’Sullivan, D. (1997).
The buttery methodology: A gateway-free ap-
proach for migrating legacy information systems.
In Proceedings of the 3rd IEEE Conference on
Engineering of Complex Computer Systems
(ICECCS97) (pp. 200-205). Italy: IEEE Com-
puter Society. Retrieved February 9, 2008, from
https://www.cs.tcd.ie/publications/tech-reports/re-
ports.99/TCD-CS-1999-15.pdf
Zadeh, L. A. (1965). Fuzzy sets. Information and
Control, 8(3), 338-353.
Zadeh, L. A. (1975). The concept of a linguistic
variable and its application to approximate reason-
ing (parts I, II, and III). Information Sciences, 8,
199-251, 301-357 ; 9, 43-80.
Zadeh, L. A. (1978). Fuzzy sets as a basis for a
theory of possibility. Fuzzy Sets and Systems,
1(1), 3-28.
Zadeh, L. A. (1983). A computational approach to
fuzzy quantiers in natural languages. Computa-
tional Mathematics Applications, 9, 149-184.
Zadeh, L. A. (1992). Knowledge representation in
fuzzy logic. In An introduction to fuzzy logic appli-
cations in intelligent systems. Kluwer Academic.
Zemankova-Leech, M., & Kandel, A. (1985).
Implementing imprecision in information systems.
Information Sciences, 37, 107-141.
KEY TERMS
CDEG Function: Function dened in FSQL to
compute the Compatibility DEGree of each row.
This value is the fulllment degree of each row to
the fuzzy condition included in the WHERE clause
of a SELECT statement in FSQL language. This
function may be used with an attribute in the argu-
ment and then it computes the fulllment degree for
the specic attribute. If the argument is the symbol
asterisk, *, then it computes the fulllment degree
using the whole condition, even whether it includes
fuzzy conditions on different attributes.
Fuzzy Attribute: In a database context, a fuzzy
attribute is an attribute of a row or object in a data-
base, which allows querying by fuzzy information
and/or storing this kind of information.
Fuzzy Database: If a regular or classical da-
tabase is a structured collection of records or data
that is stored in a computer, a fuzzy database is a
database which is able to deal with uncertain or
incomplete information using fuzzy logic. There
are many forms of adding exibility in fuzzy
databases. The simplest technique is to add a
fuzzy membership degree to each record, that is,
an attribute in the range [0,1]. However, there are
other kinds of databases allowing fuzzy values to
be stored in fuzzy attributes using fuzzy sets, pos-
sibility distributions, or fuzzy degrees associated
to some attributes and with different meanings
(membership degree, importance degree, fulll-
ment degree, etc.). Of course, fuzzy databases
should allow fuzzy queries using fuzzy or nonfuzzy
data, and there are some languages that allow these
kinds of queries, like FSQL or SQLf. In synthesis,
the research in fuzzy databases includes the fol-
lowing four areas: exible querying in classical or
fuzzy databases, extending classical data models in
order to achieve fuzzy databases (fuzzy relational
databases, fuzzy object-oriented databases, etc.),
fuzzy data mining techniques, and applications of
these advances in real databases.
FSQL (Fuzzy SQL): Extension of the popular
language SQL that allows the management of
379
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
fuzzy relational databases using the fuzzy logic.
Basically, FSQL denes new extensions for fuzzy
queries, extending the SELECT statement, but it
also denes other statements. One of these fuzzy
items is the denition of fuzzy comparators us-
ing mainly the possibility and necessity theory.
Besides, FSQL allows the denition of linguistic
labels (like hot, cold, tall, short, etc.) and fuzzy
quantiers (most, approximately 5, near the half,
etc.). The more recent publication about FSQL is
the book Fuzzy Databases: Modeling, Design and
Implementation by Galindo et al. (2006).
Fuzzy Comparators: They are different tech-
niques to compare two values using fuzzy logic.
FSQL denes fuzzy comparators like FEQ (fuzzy
equal), NFEQ (necessarily fuzzy equal), FGT
(fuzzy greater than), NFGT (necessarily fuzzy
greater than), and so forth.
Fuzzy Metaknowledge Base (FMB): (FMB):: In a
fuzzy database, the FMB is the extension of the
data dictionary in order to store the fuzzy metadata,
that is, information about fuzzy objects: fuzzy
data type of each fuzzy attribute, the denition
of labels, the margin for approximate values, the
minimum distance for very separated values, fuzzy
quantiers, and so forth.
Fuzzy Migration: Migration from crisp
databases towards fuzzy databases in order to
introduce imprecise/fuzzy information in cur-
rent information systems. This fuzzy migration
consists in deriving a new database from a legacy
database and in adapting data, metadata, and the
software components accordingly. It does not only
constitute the adoption of a new technology, but
also the adoption of a new paradigm.
Fuzzy Query: Query with imprecision in the
preferences about the desired items. These prefer-
ences may be set usually using fuzzy conditions
in the queries. These fuzzy conditions include
many possible forms like fuzzy preferences (e.g.,
I prefer bigger than cheaper), fuzzy labels (e.g., hot
and cold), fuzzy comparators (e.g., approximately
greater or equal than), fuzzy quantiers (e.g., most
or approximately the half), and so forth. One basic
target in a fuzzy query is to rank the resulting items
according to their fulllment degree (usually a
number between 0 and 1).
FuzzyEER Model: Conceptual modeling tool,
which extends the Enhanced Entity Relationship
(EER) model with fuzzy semantics and fuzzy
notations to represent imprecision and uncertainty
in the entities, attributes, and relationships. The
basic concepts introduced in this model are fuzzy
attributes, fuzzy entities, fuzzy relations, fuzzy
degrees, fuzzy degrees in specializations, and
fuzzy constraints. A complete denition of this
model is published in the book Fuzzy Databases:
Modeling, Design and Implementation (Galindo
et al., 2006).
Legacy System: Existing system in a concrete
context, for example, an existing database.
SQL (Structured Query Language): A com-
puter language used to create, retrieve, update, and
delete data from relational database management
systems. SQL has been standardized by both ANSI
and ISO. It includes DML (Data Management
Language) and DDL (Data Denition Language).
The statement for querying is the SELECT com-
mand.
ENDNOTES
1 Oracle is possibly the most powerful database
system. The last versions are object relational
databases and designed for grid computing.
Some distributions are free but with some
limits (such as, to store up to 4GB of user
data). It began three decades ago with only
one relational database and actually it runs
on all major operating systems, including
Linux, UNIX (AIX, HP-UX, Mac OS X,
Solaris, Tru64), and Windows. Ofcial web
page: http://www.oracle.com
2 PostgreSQL is a powerful, open source
relational database system. It has more than
380
How to Achieve Fuzzy Relational Databases Managing Fuzzy Data and Metadata
15 years of active development and a proven
architecture that has earned it a strong reputa-
tion for reliability, data integrity, and correct-
ness. It runs on all major operating systems,
including Linux, UNIX (AIX, BSD, HP-UX,
SGI IRIX, Mac OS X, Solaris, Tru64), and
Windows. Ofcial web page: http://www.
postgresql.org
3 AA DBRE is a technology used to recover
the conceptual schema that expresses the
semantics of the source data structure
