Association annotations
Tagged
values
The tagged values specific to Sybase and which are available at
association level are presented in the following table:
|
The ... tagged value |
is used to ... |
Sybase |
|
{fillfactor} |
as for class |
WITH FILLFACTOR |
|
{tablespace} |
as for class |
ON |
|
{partition} |
as for class |
PARTITION |
|
{maxRowsPerPage} |
as for class |
WITH MAX_ROWS_PER_PAGE |
|
{onDeleteCascade} |
maintain referential integrity constraints on associations. |
CREATE TRIGGER ... |
In the case of a
mutual association, it is necessary to specify the tagged values other than
{onDeleteCascade} on each orientation of the association.
The
{onDeleteCascade} tagged value
This tagged
value offers the possibility of deleting the foreign keys that reference a primary key when this key is deleted.
Indeed, when we delete
a tuple with a primary key, we also want to delete tuples with a corresponding
foreign key in the dependent tables.
This is especially true if the table is concerned by an association.
As far as the
implementation of this tagged value is concerned, Sybase does not provide the
ON DELETE CASCADE (standard SQL92) clause on the referential integrity
constraints.
Furthermore, it
is not possible to use the triggers which come with the referential integrity
constraints in a simple way, since these are checked before the launching of
the triggers.
The Sybase
coupling suggests two ways of interpreting the {onDeleteCascade} tagged value:
·
The first
is to ignore this tagged value and to let the application delete associations
between instances before deleting the instances themselves. This option is chosen by default.
·
The second
is to implement this property in the SQL, using the triggers. In this case, you must also simulate the
referential integrity constraints which use triggers on the insertion.
In relation to
this, the {gen cascade} tagged value indicates that the
{onDeleteCascade} tagged value should provoke the generation of the triggers
necessary in the SQL.
The drawback in
this is that it makes the FOREIGN KEY referential integrity constraints
disappear from the produced SQL. REFERENCES ordinarily used on tables which
materialize associations.
This choice
should be avoided if you wish to reverse engineer the produced SQL, as the
associations between the tables no longer clearly appear.