Extended_FSQL_Server: a Server for the description and the

manipulation of FRDB

Amel GRISSA TOUZI

ENIT, TUNISIA
Amel.touzi@enit.rnu.tn

Mohamed Ali BEN HASSINE

ENIT, TUNISIA
med_ali_bh@dcemail.com

Habib OUNALLI
FST, TUNISIA
habib.ounelli@fst.rnu.tn

ABSTRACT
The Fuzzy Relational Databases (FRDB) has been extensively studied in a theoretical level.
Unfortunately, the repercussions of these works on the practical level are negligible.
Medina et al. have developed a server named FSQL, supporting flexible queries on FRDB.
The FSQL Server is based on a fuzzy relational model named GEFRED. This server has been
programmed in PL/SQL language under Oracle. Flexible queries in FSQL are expressed with
an extension of the standard SQL, named FSQL (Fuzzy SQL). The FSQL server uses a Fuzzy
Meta-knowledge Base (FMB) to model the different types of fuzzy attributes. Since Oracle
doesn't recognize FSQL, consequently we must transform an FSQL script in a SQL script
equivalent, which includes the necessary updates of the FMB. This hard task is supposed
already made in the implementation of FSQL server by Medina et al.
We propose in this paper an extension of FSQL server in order to remedy this serious limit
especially in the case of voluminous DB. Our extension consists in transforming a FSQL
script automatically in an SQL equivalent, including the necessary updates of the FMB. This
extension has two enhancements to FSQL, while preserving all its possibilities: (1) a better
extensibility notably in case of addition of new fuzzy types and (2) the possibility of
definition and the manipulation of FRDB directly with the FSQL language. The enhanced
server is operational under Oracle.

Key Words: FSQL, Fuzzy relational database, Flexible queries, GEFRED, FIRST.

1. Introduction language named FSQL (Fuzzy SQL) has been

The Fuzzy Relational Databases (FRDB) has
been widely studied in a theoretic level [1, 2, 7,
14, 15]. However, few works have studied it
from a practical point of view. Among these
works, the one of Medina et al. is very
interesting. They developed a Fuzzy query
interface (FQ) [6] which, as interacting with a
server called FSQL server, permits the flexible
querying on FRDB. This server has been
developed in PL/SQL language for Oracle
Database Management System (DBMS),
following a theoretic model called GEFRED.
To model flexible queries and the concept of
the fuzzy attributes, an extension of the SQL
defined [5, 10]. The FSQL language extends
the SQL language, to support the flexible
queries, with fuzzy comparators, fuzzy
constants, fuzzy quantifiers, new data types
and new commands such as "CREATE
LABEL" and "CREATE NEARNESS"
(definition of linguistic terms and similarity
relations).
Since the FQ software is implemented for the
Oracle DBMS, which only supports SQL and
PL/SQL languages, it is natural that all
extensions made in FSQL won't be supported
directly by Oracle. To make this extension,
Medina et al. defined a Fuzzy Meta-
Knowledge Base (FMB) formed by a set of
tables. This FMB, store all necessary
information to manipulate fuzzy attributes.
This method is difficult since it is necessary to
know the internal organization of the FMB and
the number of trapezoidal linguistic labels for
each fuzzy attribute. Also, this number of
labels changes according to the nature of each
fuzzy attribute. An exam of FQ of FSQL
server [6] allowed us to clear the following
limits:
1) FQ considers that the DB is already defined
in SQL and don't treat the problem of the
equivalence between the fuzzy types of
GEFRED and the standard SQL types. For
example, a FTYPE2 fuzzy attribute
(attribute age in the figure 3) defined in
FSQL is replaced by five SQL attributes
with several lines in the FMB to models its
different linguistic labels (figure 7) and
other fuzzy concepts (fuzzy quantifiers,
nearness, approximate values, etc.).
2) FQ is not appropriated in practice for large
DB.
In this paper, we propose an extension of
FSQL server that permits to solve the previous
problems. The main idea of this extension is to
add a layer that permits to give an automatic
transformation of the FRDB schema in a SQL
language equivalent while updating the FMB.
The users don't have need to know how the
server store and manipulate fuzzy attributes.
Our solution presents the following
advantages: (1) preserves all possibilities of
FSQL Server, (2) operational under oracle's
DBMS, (3) makes transparent the
transformation of a script written in FSQL to
its equivalent in SQL and (4) supports the
description and the manipulation of a FRDB in
FSQL language.
This paper is organized into 7 sections. Section
2 deals with the basic concepts of the fuzzy
relational databases. Section 3 presents the
GEFERD model. Section 4 studies an example
to illustrate the implementation problems of the
fuzzy concepts in RDB. The extended,
E_FSQL_Server, is presented in Section 5.
Section 6 description the software
FSQL_TO_SQL. Finally, in section 7, we
outline some conclusions and suggest some
future lines of research.
2. Fuzzy Relational Databases
We present in this section the basic concepts of
FRDB.
A Fuzzy Relational Database (FRDB) is an
extension of the relational database. This
extension introduces fuzzy predicates under
shapes of linguistic expressions that, at the
time of a flexible querying, permits to have a
range of answers (each with a member ship
degree) in order to offer to the user all
intermediate variations between the completely
satisfactory answers and those completely
dissatisfactory [1]. We can also say that a
FRDB is defined as an enhanced relational
database that allows fuzzy attribute values and
fuzzy truth values; both of these are expressed
as fuzzy sets [15].
The basic model of fuzzy relational databases
is considered the simplest one, and it consists
of adding a grade, normally in the [0,1]
interval, to each instance (or tuple). This makes
keeping database data homogeneity possible.
Nevertheless, the semantic assigned to this
grade will determine its usefulness, and this
meaning will be utilized in the query processes
[9]. The main models are those of Prade-
Testemale [13], Umano-Fukami [14], Buckles-
Petry [3], Zemankova-Kaendel [16] and
GEFRED of Medina-Pons-Vila [11]. This last
model constitutes an eclectic synthesis of the
various models published so far with the aim of
dealing with the problem of representation and
treatment of fuzzy information by using
relational DB.
3. The GEFRED model
The GEFRED model (GEneralised model
Fuzzy heart Relational Database) has been
proposed in 1994 by Medina et al. [11]. It is
based on the generalized fuzzy domain and
generalized fuzzy relation, which include
classic domains and classic relations,
respectively. The data types supported by this
model are showed in the table 1.
To model the flexible queries and the concept
of the fuzzy attributes, Medina et al. introduced
an extension of SQL language called FSQL
(Fuzzy SQL). We present in the following
section this language.
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
the degree of matching (e.g. Quality=0.9).
8. An Unknown value with possibility
distribution Unknown={1/u: u ∈U} on domain
U, considered.
9. An Undefined value with possibility
distribution Undefined={0/u: u ∈U} on
domain U, considered.
10. A NULL value given by NULL={1/Unknown,
1/Undefined}.
Tab. 1: Data types in the GEFRED Model
3.1 The FSQL language
The FSQL language [5, 9, 10] is an extension
of SQL which allows the use of flexible
queries. It means that all valid queries in SQL
are as valid in FSQL. This paper will only
provide a summary of the main extensions
added to this command:
a) Linguistic Labels: If an attribute is able of
fuzzy treatment then linguistic labels can
be defined 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 fuzzy domain
(Fuzzy Attributes Type 1 and 2) and (2)
Labels for attributes with a non ordered
fuzzy domain (Fuzzy Attributes Type 3 and
4).
b) Fuzzy Comparators: Besides the typical
comparators (=,>, etc.), FSQL includes
fuzzy comparators. There are many
comparators, the most used are: FEQ
(Fuzzy Equal than), (NFEQ: Necessarily
FEQ), FGT (Fuzzy Greater than), (NFGT:
Necessarily FGT), FGEQ (Fuzzy Greater
or Equal than), (NFGEQ: Necessarily
FGEQ), FLT (Fuzzy Less Than), (NFLT:
Necessarily FLT), FLEQ (Fuzzy Less or
Equal than), (NFLEQ: Necessarily FLEQ),
MGT (Much Greater Than), (NMGT:
Necessity MGT), MLT (Much Less Than),
(NMLT: Necessarily MLT), FINCL (Fuzzy
INCLuded in), INCL, FDIF (Fuzzy
DIFrent), (NFDIF: Necessary FDIF) [4,
10]. Like in SQL, fuzzy comparators
compare one column with one constant or
two columns of the same type.
c) Fuzzy constants: Besides the typical
constants (NULL), FSQL included many
constants such as $[a,b,c,d], #n, $label,
[n,m], UNKNOWN, UNDEFINED, etc.
d) Fuzzy qualifiers: they are of two natures,
absolute and relative [10].
e) Fuzzy attributes: the classification
adopted for the types of attributes is based
on the approaches of representation and
treatment of the "imprecise" data [9, 10].
These fuzzy attributes may be classified in
four data types. This classification is
performed taking into account the type of
referential or underlying domain. In all of
them the values Unknown, Undefined, and
Null are included:
1) Fuzzy Attributes Type 1: These are
attributes with “precise data”, classic or
crisp (traditional, with no imprecision).
However, they can have linguistic
labels defined over them and we can
use them in fuzzy queries. This type of
attribute is represented in the same way
as precise data, but can be transformed
or manipulated using fuzzy conditions.
This type is useful for extending
traditional databases allowing fuzzy
queries to be made about classic data.
2) Fuzzy Attributes Type 2: These are
attributes that gather “imprecise data
over an ordered referential”. These
attributes admit both crisp and fuzzy
data, in the form of possibility
 distributions over an underlying ordered
dominion (fuzzy sets). It is an extension
of the Type 1 that does, now, allow the
storage of imprecise information.
3) Fuzzy Attributes Type 3: They are
attributes over “data of discreet non-
ordered dominion with analogy”. In these
attributes some labels are defined
("blond", "red", "brown", etc.) that are
scalars with a similarity (or proximity)
relationship defined over them, so that
this relationship indicates to what extent
each pair of labels resemble each other.
They also allow possibility distributions
(or fuzzy sets) over this dominion, like
for example, the value (1/dark,
0.4/brown), which expresses that a
certain person is more likely to be dark
than brown-haired.
4) Fuzzy Attributes Type 4: These attributes
are original and they are defined in the
same way as Type 3 attributes, without it
being necessary for a similarity
relationship to exist between the labels.
3.2 The GEFRED architecture
In order to implement a system which
represent and manipulate "imprecise"
information, Medina et al. have developed
FIRST [12] (Fuzzy Interface for Relational
Systems) to extend the DBMS capacities in
order to represent and manipulate Imprecise
data. It reuses the existing structure and adds
new components to handle fuzzy information.
The schema of the architecture is showed in
Figure 1.
Fig. 1: General schema of FIRST
The main components of FIRST are:
RDBMS: All the operations conceived for the
fuzzy extension will be translated into queries
for the RDBMS host. These queries will be
made using a language supported by the
RDBMS (in general SQL). DB: store all the
permanent information, fuzzy or not, following
the relational model. FMB: built in the host
system catalog as one of its extensions. It
provides information about all the fuzzy
structures (figure 2), data and definitions stored
in the DB. FSQL Server: Its objective is to
extract the queries written with a FSQL
language and translate them in a language
understood by the RDBMS, the SQL language.
To do this translation, it uses the information
stored in the FMB. FSQL Client, FSQL
Fuzzy FORM and Interface Client: These are
the programs that establish an interface
between the user and FSQL server.
The figure 2 shows the relations in the FMB,
its attributes, its primary keys (underlined) and
its foreign keys (with the arrows).
Fig. 2: Relations in the FMB

Fuzzy attributes Type 1 are represented as
usual attributes, because they do not allow
fuzzy values. Fuzzy attributes Type 2 are
represented, under oracle, by 5 traditional
attributes according to the form described in
table 2.
Tab. 2: Internal representation of fuzzy attributes
Type 2 (for an attribute F)
- FT: stores the type of value which the
attribute in question can take (0 for
UNKNOWN, 1 for UNDEFINED, etc.). The
letter T is concatenated the name of the
attribute.
- F1, F2, F3 et F4: The names of these
attributes are formed by concatenate the
numbers 1, 2, 3, and 4 to the attribute name.
They stores the description of the parameters
which define the data and which depend on the
type of value (FT),
Fuzzy attributes Type 3 and 4 are represented,
by a variable number of traditional attributes
according to the form described in table 3.
Tab. 3: Internal representation for fuzzy attributes
Type 3 or 4 (for an attribute F)
- FT: stores the kind of value which the
attribute in question can take (0 for
UNKNOWN, 1 for UNDEFINED, 2 for
NULL, 3 for SIMPLE and 4 for POSSIBILITY
DISTRIBUTION).
- List of n pairs, with n ≥1, with the format
(Possibility value, label): (FP1,F1),...,
(FPn,Fn). In the case of the SIMPLE type, only
first couple is used and the possibility value
will be 1 (to be standardized).
4. Example
We want in this example to model an employee
described by the following information:
matriculate (identifier), name, surname,
address, age, salary, productivity. The
attributes age, salary and productivity are
described as follows:
- Age is of FTYPE2 type having like
linguistic labels YOUNG(18, 22, 30, 35),
ADULT(25 ,32 ,45 ,50) and AGED(50 , 55,
62, 70) defined by trapezoidal possibility
distributions (figure 2). To use the
approximate comparison with the age using
the fuzzy comparators, as MGT (Much
Greater Than), NMGT (Necessity MGT)
and MLT (Much Less Than), we need to
define a margin and a distance. The margin
permits to make some approximations. The
distance specifies when two age values are
different. Let's suppose that for age, the
margin is 5 and the distance is 10.
Fig. 3: Definition of labels on age
- Salary is of FTYPE1 type having like
linguistic labels LOW(50, 80, 120, 180),
MEDIUM (150, 300, 400,5 50) and
HIGH(400, 600, 800, 1000) defined also by
trapezoidal functions (figure 3). Let's
suppose that for the salary, the margin is 10
and the distance is 50.
Fig. 4: Definition of labels on salary
- Productivity is of FTYPE3 type having
like linguistic labels BAD, REGULAR and
GOOD. In this situation, the data are not
quantifiable, but presents resemblances
defined in the table 1. For example, the
 value REGULAR of the productivity
attribute resembles to the value GOOD
with a degree equal to 0.7.
similarity degree BAD REGULAR GOOD
BAD 1 0.3 0.2
REGULAR 0.3 1 0.7
GOOD 0.2 0.7 1 and a treatment in the FMB.
Tab. 4: similarity relations for the productivity
attribute
The creation of a table with the FSQL language
must follow the following steps:
1) create the table EMPLOYE with its
attributes (fuzzy and classic),
2) create the corresponding labels for
FTYPE1 and FTYPE2 attributes type,
3) create the corresponding similarity
relations (NEARNESS ) for the FTYPE3
attributes type,
4) update the FMB.
These steps are modeled with the FSQL script
in the following figure:
/* Creation of EMPLOYEE table */
CREATE TABLE EMPLOYEE(
MATRICULATE# VARCHAR(4) NOT NULL,
NAME VARCHAR(20) NOT NULL,
SURNAME VARCHAR(20) NOT NULL,
ADDRESS VARCHAR(40) NOT NULL,
AGE FTYPE2(5,10) NUMBER(3) DEFAULT
UNKNOWN NOT NULL,
SALARY FTYPE1(10,50) NUMBER(7) NOT NULL,
PRODUCTIVITY FTYPE3(1) NOT NULL,
PRIMARY KEY (MATRICULE#));
/*Definition of linguistic labels */
CREATE LABEL YOUNG ON EMPLOYE.AGE
VALUES 18,22,30,35;
CREATE LABEL ADULT ON EMPLOYE.AGE
VALUES 25,32,45,50;
CREATE LABEL OLD ON EMPLOYE.AGE
VALUES 50,55,62,70;
CREATE LABEL LOW ON EMPLOYE.SALARY
VALUES 50,80,120,180;
CREATE LABEL MEDIUM ON
EMPLOYE.SALARY VALUES 150,300,400,550;
CREATE LABEL HIGH ON EMPLOYE.SALARY
VALUES 400,600,800,1000;
/* Definition of NEARNESS */
CREATE NEARNESS ON
EMPLOYE.PRODUCTIVITY
LABELS BAD, REGULAR, GOOD
VALUES 0.3, 0.2, 0.7;
Fig. 5: FSQL script
An abstract representation of the relation
schema EMPLOYEE will be as follows:
(MATRICULATE, NAME, SURNAME,
ADDRESS, AGE, SALARY, PRODUCTIVITY).
The implementation of this FSQL script under
Oracle, in an SQL equivalent, must be
executed in two steps: a treatment in the DB
1) Treatment in the DB
The CREATE TABLE command is
translated by:
CREATE TABLE EMPLOYEE(
MATRICULATE# VARCHAR2(4) NOT NULL,
NAME VARCHAR2(20) NOT NULL,
SURNAME VARCHAR2(20) NOT NULL,
ADDRESS VARCHAR2(40) NOT NULL,
AGET NUMBER(1) DEFAULT 0 NOT NULL
CHECK (AGET BETWEEN 0 AND 7),
AGE1 NUMBER(3),
AGE2 NUMBER(3),
AGE3 NUMBER(3),
AGE4 NUMBER(3),
SALARY NUMBER(7) NOT NULL,
PRODUCTIVITYT NUMBER(1) NOT NULL
CHECK (PRODUCTIVITYT BETWEEN 0 AND 4),
PRODUCTIVITYP1 NUMBER(3,2),
PRODUCTIVITY1 NUMBER(3) NOT NULL,
PRIMARY KEY (MATRICULATE#));
Fig. 6: SQL script
In our example the table EMPLOYEE will
have the following schema:
(MATRICULATE, NAME, SURNAME,
ADRESS, AGET, AGE1, AGE2, AGE3,
AGE4, SALARY, PRODUCTIVITYT,
PRODUCTIVITYP1, PRODUCTIVITY1).
2) Treatment in the FMB:
For the level of the FMB, CREATE TABLE
leads us to store the information concerning
the fuzzy attributes, the list of the linguistic
labels and the similarity relations in their
corresponding tables. It means to insert for
every fuzzy attribute the suitable tuples in the
FMB tables. Figure 7 summarizes the change
carried out at the level of the FMB.
As we have just seen with this example, the
transformation of a FSQL script to its
equivalent in SQL is not a simple task. This
operation is very delicate and must be made by
hand by the designer of the FRDB.
This task demand to the designer to know:
a) the FMB formed by its different tables with
their details, its different attributes, and,
b) the necessary process to follow to model
the concepts of linguistics labels, similarity
relations, fuzzy constants, etc. while
knowing the attributes types.
To our opinion, this work is very long,
especially if we want to manage voluminous
DB. Consequently the FQ software is limited
to some simple examples of DB and to
academic use.
Fig. 7: Update of the FMB
We propose in the following of the paper an
extension of FSQL server. One of the main
goals of this approach is to make transparent
this transformation; the designer of the FRDB
doesn't have need to know the description of
the FMB nor the mechanism of
implementation.
5. The server: E_FSQL_Server
We propose in this section, our extension of
FSQL server.
5.1 Proposed architecture
We propose in this part, an extension of the
FIRST architecture E_FIRST in order to
support the creation and the manipulation of a
FRDB. In the new architecture (figure 8), we
added a layer (FSQL_TO_SQL) that assures
the interface between a DDL script of a FRDB
modeled in FSQL and its correspondent in
SQL with the update of the FMB. Thus, the
user can interact with the FRDB by two senses:
the first consults the FRDB (simple user) and
the second manipulates and creates the FRDB
(designer).
5.2 Presentation of the FSQL_TO_SQL
layer
This layer presents a tool, called
FSQL_TO_SQL, which permits the
implementation of a FRDB described in FSQL
under oracle 8i.
Fig. 8: E_FIRST architecture
This tool allows an automatic transformation of 5.2.1 Working's Principle
a FSQL script in an equivalent SQL script The working's principle is as follows:
while specifying the modifications made to the
level of the FMB.
Begin
- cut a DDL instruction in several lines containing each one an attribute.
- study every DDL line:
if it contains a classic attribute
then copy this line in a first file (result1.sql).
else make a very specific treatment to every fuzzy attribute.
This treatment divides in two under-treatments:
- Treatment in DB
- translate the command that concerns the DB
- copy the translated command in the file (result1.sql)
- Treatment in FMB
- provide a script writes in the file (result2.sql), containing the
information in the FMB concerning the fuzzy attributes and
the objects defined on them.
End

Fig. 9: Main Algorithm

As result of these two treatments, we obtain 2) insert the tuples in the FMB containing
two files: a file containing the DDL part of the the fuzzy attributes defined on this
DB and a second containing the modification table,
to do in the FMB. We can also regroup the 3) model the different commands
two treatments in a same file since they will be CREATE LABEL, CREATE
executed in the DBMS. This process of NEARNESS in the FMB.
working is illustrated in the figure 10.

5.2.2 Rules to follow

After a detailed study of the GEFRED model
and the FQ software, we defined a set of rules
that we must apply to succeed the
transformation according to the fuzzy attributes
types. In fact, the treatment in the DB and in
the FMB depends to treated command and of
fuzzy attributes type.

Translation of the command CREATE

TABLE
The modeling of this command will be
effectuated while respecting the following
steps:
1) call the classic command CREATE
TABLE with a modification of the
fields containing the fuzzy attributes1,

1
We are interested in this paper to the 3 fuzzy attributes
FTYPE1, FTYPE2 and FTYPE3 Fig. 10: Functioning of FSQL_TO_SQL
We associate to each type of attribute a specific
treatment according to the rules described in
the table 4 and 5.
Attribute Treatment in the database
type
FTYPE1 1) delete FTYPE1 from the command
syntax
1) delete FTYPE2 from the command
syntax,
2) concatenate the attribute with the letter
'T' follow-up of the restriction of its
values (they must be in the interval
[0,10]),
3) concatenate the attribute respectively
with 1, 2, 3 and 4 (Attribute1,…,
FTYPE2 Attribute4). The attribute changes into
2n+1 attributes,
4) add in the same line its type of basis
(classic type defined after FTYPE. By
default is NUMBER),
5) translate the word "DEFAULT"
according to the table 2,
6) translate the restriction according to the
table 2.
1) delete FTYPE3 (resp. FTYPE4) from
the syntax of the command,
2) concatenate the attribute with the letter
'T' follow-up of the restriction of its
values (they must be in the interval
[0,4]),
3) concatenate the attribute n time
respectively with Pi then with i,
knowing that n is provided between
FTYPE3
parenthesis after the word "FTYPE3 or
FTYPE4 FTYPE4" and 1≤i≤n,
4) add its basic type (by default it is
NUMBER(3,2)) for AttributePi and
NUMBER(3) for Attributei (the
attribute changes into 2n+1 attributes),
5) translate the word "DEFAULT"
according to the table 3,
6) translate the restriction according to
the table 3.
Classic Nothing to do
Tab. 5: CREATE TABLE in DB
Type of attribute Treatment in the FMB
FTYPE1, FTYPE2 1) store in the FCL table
FTYPE3, FTYPE4 the information on the
attribute (name, type,
length and a commentary),
2) store the values in
FTYPE1, FTYPE2
brackets that follows
FTYPE1 (n,m) in the
FAM table.
2) store in the FCC table
FTYPE3, FTYPE4 the compatible attributes
with him
Classic Nothing to do
Tab. 6: CREATE TABLE in FMB
Translation of the command CREATE
LABEL
1) insert in the FOL table the identifier of
the linguistic label, its name and its type.
2) insert in the FLD table the parameters of
linguistics label (a,b,c,d), etc.
Translation of the command CREATE
NEARNESS
1) insert in the FOL table the identifier of
the linguistic label, its name and its type.
2) insert in the FND table the list it of the
linguistic labels with their similarity degrees.
6. Description of the software
FSQL_TO_SQL
FSQl_TO_SQL offers a convivial interface that, on
the one hand, presents an editor of FSQL script
description, and on the other hand, gives
automatically its equivalent in SQL with the update
of the corresponding FMB. It is developed in C++
language.
To use FSQL_TO_SQL, the user must, first of all,
load the script of its FRDB modeled in FSQL either
by writing it under the editor or by specifying the
path of the file source containing its script (.fsql).
While clicking on the button "translate" which is in
bar of menu under Action (figure 11),
FSQL_TO_SQL generates its equivalent in SQL
(figure 12).

Translate
FSQL query
Fig. 11: Translation FSQL query
Fig. 12: Translation of FSQL query
FSQL_TO_SQL can moreover detect and signal
the syntactic errors in a FSQL script. If the error is
to the level of the new FSQL objects (FTYPE,
UNKNOWN, LABEL, etc.), our tool displays this
error, the most possible cause of its apparition and
the line where it is happen (figure 13). Otherwise
(the error occurred at the SQL commands level), a
report concerning this error will be generated by
the Oracle DBMS.
Fig. 13: detection of errors
Conclusion
The FRDB have been studied extensively on
the theoretical level. However, the repercussions
of these works on the practical level remain
negligible. The few achieved works limited
themselves to the flexible querying of classic
DB (crisp DB). Among these works, the one of
Medina and al is very interesting. Medina et al.
developed an FRDB server around Oracle named
FSQL Server. This implementation treat only
the flexible querying while supposing that the
DB diagram was already defined.
The diagram definition is made with an
extension of SQL (FSQL) that introduces new
data types for the fuzzy attributes. Since Oracle
doesn't support the FSQL language, a
preliminary stage is necessary to transform the
FSQL commands to their SQL equivalent. We
showed that this transformation (mapping) is
from afar an easy task.
We proposed an extension of FSQL server
while achieving this transformation
automatically. This extension, that preserves
the FSQL acquirements, presents two
following advantages: (1) a bigger extensibility
notably in case of addition of new fuzzy types
and (2) the definition and the manipulation of
fuzzy DB directly with the FSQL language.
As futures perspectives of this work, we
mention (1) the automatic determination of the
trapezoidal functions for the fuzzy attributes
while using techniques of fuzzy clustering and
(2) the addition of a expert system for the
choice of the suitable fuzzy attributes type
among the very numerous types of GEFRED.
We think that this last point will be a useful
start point in order to generalize the fuzzy
databases in the real database world.
References:
[1] P. Bosc, L. Liétard, O. Pivert, "Bases de
données et Flexibilité : Les requêtes Graduelles"
Techniques et Sciences informatiques, 17(3), 1998,
pp. 355-378.
[2] P. Bosc and O. Pivert, "SQLf: A Relational
Database Language for Fuzzy Querying", IEEE
Transactions on Fuzzy Systems, Vol 3, No. 1, Feb
1995.
[3] B. P. Buckles, F. E. Petry, "A Fuzzy
Representation of Data for Relational Databases".
Fuzzy Sets and Systems, 7, 1982, pp. 213-226.
[4] J. Galindo, M. Medina, M. A Vila, J. C.
Cubero, "Fuzzy Comparators for Flexible Queries
to Databases". In: Proc. of IBERAMIA'98. Lisbona
(Portugal), 1998
[5] J. Galindo, J. M. Medina, O. Pons, and J. C.
Cubero, “A server for fuzzy SQL queries,” in
Flexible Query Answering Systems, T. Andreasen,
H. Christiansen, and H. L. Larsen, Eds. New York:
Springer-Verlag, 1998, pp. 164–174. Lecture Notes
in Artificial Intelligence (LNAI)1495.
[6] J. Galindo, the FSQL server + FQ ":
http://www.lcc.uma.es/personal/ppgg/FSQL
[7] J. Galindo, “Tratamiento de la imprecisión en
bases de datos relacionales: Extensión del modelo y
adaptación de los SGBD actuales,” Ph.D.
dissertation, Univ. Granada, Granada, Spain, Mar.
1999.
[8] J. Galindo, A. Urrutia, M. Piattini,
"Representation of Fuzzy Knowledge in Relational
Databases". 15th International Workshop on
Database and Expert Systems Applications (DEXA
2005), published by IEEE Computer Society, 2005,
pp. 917-921.
[9] J. Galindo, A. Urrutia, M. Piattini, Fuzzy
Databases: Modeling, Design and Implementation.
Eds. Idea Group Publishing Hershey, USA, 2005.
[10] J. Galindo, "New Characteristics in FSQL, a
Fuzzy SQL for Fuzzy Databases". WSEAS
Transactions on Information Science and
Applications 2, Vol. 2, 2005, pp. 161-169.
[11] J. M. Medina, O. Pons, M. A. Vila,
“GEFRED. A Generalized Model of Fuzzy
Relational Data Bases”. Information Sciences,
76(1-2), 1994, pp. 87-109.
[12] J. M. Medina, O. Pons, A. Vila, “FIRST. A
Fuzzy Interface for Relational SysTems”. VI
International Fuzzy Systems Association World
Congress (IFSA 1995). Sao Paulo (Brasil), 1995.
[13] H. Prade, C. Testemale, "Fuzzy Relational
Databases: Representational issues and Reduction
Using Similarity Measures". J. Am. Soc.
Information Sciences 38(2), 1987, pp. 118-126.
[14] M. Umano, S. Fukami, M. Mizumoto, K.
Tanaka "Retrieval Processing from Fuzzy
Databases". Technical Reports of IECE of Japan,
Vol. 80, No 204, (on Automata and Languages),
1980, pp. 45-54, AL80-50.
[15] Yoshikane Takahashi, "Fuzzy Database Query
Languages and Their Relational Completeness
Theorem" IEEE Transaction On Knowledge and
Data Engineering, vol 5, N° 1, February 1993
[16] M. Zemankova-Leech, A. Kandel,
"Implementing Imprecision in Information
Systems". Information Sciences, 37, 1985, pp. 107-
141.