Database Server Models for WMS and WFS Geographic Web Services - Geographical Information Systems: Trends and Technologies - page 155

As an example, there is a FD between the attribute mobileNumberMayor
and the attribute mayor of the City class. This FD is written with an arrow:
“mobileNumberMayor Æ mayor”. The semantic interpretation of such an
FD denotes that a mobile phone number relates only to a single mayor (but
that does not mean anything about the fact that a mayor may have several
mobile phone numbers).
Weaknesses
Functional Dependencies do not express all data semantics. They do not
in fact represent any link that may exist between data from the application
point of view. For example, regarding the Tree class it is not possible to link
the attributes “species” and “phytosanitaryStatus” with a FD. Indeed, a
value of the attribute “species” does not determine a unique value of the
attribute “phytosanitaryStatus” (several trees can be of the same species
with different phytosanitary status). With the “species” attribute of a
tree, it would be useful to obtain, from an agronomic point of view, its
phytosanitary status but the identifying mark of the parcel is not relevant
(for which there is no FD).
A FD does not allow establishing a link between the attribute
“population” and the attribute “density”. The value of density is calculated
from the attribute “area” and the attribute “population” whose value is
obtained using the “surface” function. Once the population is available, it
would be useful, from a social point of view, to provide the density.
The independence of attributes (e.g., “Park” of Hotel and “typeGS” of
GreenSpace) does not allow, for the application of a spatial operator (e.g.,
“inclusion” on spatial representations), obtaining information through a
functional dependency. With a park, it would be useful to obtain from a
tourist point of view, types of green space associated with.
The Functional Dependencies are not suffi cient to recover, at the request
of a user, the relevant attributes (single or calculated). It is important to
establish a link that allows, from a database schema, obtaining a set of
relevant attributes with respect to the user's point of view. This requirement
is related to the impossibility of defi ning external schemas considering the
heterogeneity of potential users.
We present in that sense, three types of links called relevant Links (RL).
The fi rst type is called RLintA-A and concerns relevant links defi ned between
attributes of the same class (the meaning of the acronym is R(elevant)L(ink)
int(ernal)A(ttributeTo)A(ttribute)). The second type is called RLintA-M and
concerns relevant links defi ned between an attribute and a method of the
same class. Finally, the third type is called RLextA-A and concerns relevant
links defi ned between attributes of different classes.