Information Technology Reference
In-Depth Information
Abstraction
Levels
Paradigms
Conceptual
Entity-Relationship
UML
...
Logical
Relational
Object-Relational
XML
...
Physical
Oracle 8
MySQL
Oracle 11G
XML Schema
...
Fig. 1. A representation of the schema abstraction levels and some paradigms
When dealing with the quality of information systems, one has to pay partic-
ular attention to the database component because of the significant role of this
component in the whole system. Typically, a database can be the data provider
of thousands of programs. Any flaw in the schema of this database may cause
data inconsistencies, program malfunction or, at best, program code complexity
to compensate for this defect. The total cost to pay will be even higher: database
and program evolution will prove to be more complex and risky since both sane,
compensating and flawed components will need to evolve.
Although the MDE is often seen as a new approach in the software engi-
neering community, it has been the standard way of developing databases since
the seventies, where the three-level methodologies were designed and progres-
sively applied. They are based on a hierarchy of
schemas
(the database name
for
models
1
), namely the conceptual, logical, physical schemas, the latter being
translated into DDL code. Those three levels are called
abstraction levels
.In
addition, a schema is expressed in a specification language, based on a definite
paradigm (figure 1). Since logical and physical schemas mostly derive from the
conceptual schema through semantics preserving transformations, ensuring the
highest quality of conceptual schemas is particularly important.
In [1], we proposed a database quality evaluation and improvement frame-
work based on transformation techniques. Instead of computing global metrics
for the whole schema, it first tries to identify semantically significant constructs
that represent possible defects in schemas. Let us call
construct
an instance of a
definite pattern comprising data structures and constraints
2
. An n-ary relation-
ship type, an entity type without attributes, a series of attributes with similar
names are all examples of constructs. A defect is a construct that is considered
sub-optimal to translate the intention of the modeler. A
relationship entity type
(an entity type whose instances are used to connect instances of two other entity
1
From this point, we will use the database terminology, i.e. a schema is the represen-
tation of the application domain and is expressed in a specification language called
model (e.g. entity-relationship model, relational model).
2
In the following discussion, for simplicity reason and where no ambiguity may arise,
we will sometimes use the name
construct
to denote such a pattern as well as one of
its instances.
