1. Changes in the maintenance of the semantic attributes of foreign key
definitions

The following adjustments were made in the maintenance of foreign key definitions:

a) Semantic foreign key and screen foreign keys are not distinguished
This is no longer distinguished as of Release 3.0. The attributes cardinality and dependency factor had to be maintained for the semantic foreign key. Specifying this semantic attribute is now optional for all foreign keys unless specification is necessary for the activation of aggregates such as help views or customizing views.

b) Specification of the cardinality in the usual (n:m) notation

n can have the values 1 or C
m can have the values 1, C, N or CN, where the meaning is as for one-place cardinality.
The cardinality (n:m) describes the foreign key relationship with regard to the number of possible dependent records involved (records of the foreign key table) or referenced records (records of the check table).
n=1: There is exactly one record of the check table for each
dependent record.
When a dependent record is created, an entry which occurs
in the primary key of the check table must be made in the
foreign key fields.
The entry cannot be deleted.
n=C: There may be records in the foreign key table which do not
reference any record of the check table.
When a dependent record is created, an entry may be made
in the foreign key fields but does not have to be made.
This also includes the possibility of deleting an existing
entry without deleting the dependent record itself.
m=1: There is exactly one dependent record for each record of the
check table.
m=C: There is at most one dependent record for each record of the
check table.
m=N: There is at least one dependent record for each record of
the check table.
m=CN: There is any number of records for each record of the check
table.

c) Specification of the type of the foreign key fields

By specifying the type of foreign key fields, the semantic attributes of the foreign key relationship are described with regard to whether the foreign key fields are identifying for the foreign key table.
Specifying the semantic attributes of the foreign key relationships is optional. Therefore the option "not specified" is also provided.

The following types can also be specified:

No key fields or key field candidates:

The foreign key fields are not identifying for the foreign key table. This means that entries in the foreign key fields can be changed.

Key fields or key field candidates:

Key fields or key field candidates belong to the set of identifying fields of the table. The definition of a table requires a unique primary key, called key here. However, several key candidates might exist in a table and all be identifying for this table. Only one is marked as the actual key. Existing entries cannot be changed in key fields.

Key fields of a text table:

This type is a special case of the fact that foreign key fields are key fields. The condition that the dependent table is a language-dependent table for the referenced table is also valid. The key of the text table comprises the key of the referenced table and a language key.

Mapping of the previous dependency factor and the one-place
cardinality on the type and cardinality in (n:m) notation (Release 3.0)

Up to and including Release 2.2, the semantic attributes of the foreign keys were specified by defining the dependency factor and a one-place cardinality.
The changes made in Release 3.0 are upwards compatible, i.e. all the information about foreign keys already obtained can be mapped on the new definition.
The previous one-place cardinality (up to Rel. 2.2) has the meaning of the right side of the cardinality in the (n:m) notation (Rel. 3.0).
The dependency factor (Rel. 2.2) could take the values ID (identifying foreign key), TEXT (foreign key for a text table), OBL (obligatory foreign key) and OPT (optional foreign key).
The following matrix maps the relationship between the dependency factor used up to Release 2.2 and the foreign key field type used as of Release 3.0 and the left side of the cardinality (n).
-------------------------------------------------------------------
(up to 2.2) | (3.0)
Dependency factor | Type of foreign key field | n
--------------------------------------------------------------------
ID | Key fields/candidates | 1
TEXT | Key fields of a text table | 1
OBL | No key fields/candidates | 1
OPT | No key fields/candidates | C ---------------------------------------------------------------------

2. Foreign keys for included fields

The foreign keys of the substructure are also passed on to the table when including a substructure into a table.

As of Release 3.0A there are two options for the behavior when changing the substructure:

a) The inheritance for the substructure is retained. Changes to the substructure are passed on to the including table when activating.

b) Inheritance is not retained. The foreign key behaves like a foreign key for fields that are not included. Changes to the substructure no longer affect the including table (concerning the foreign keys).

Foreign keys for Customizing Includes and Append structures cannot be separated from the inheritance. In these cases, the foreign keys must be maintained in the substructures so that no modification is made to the including table.

3. Key extension for check tables

A key extension is now also possible for check tables which are used in foreign key relationships. New key fields can be appended to the previous key.
When activating the check table, the participating foreign keys are defined as generic concerning the new key field. Using the activation log you can find which foreign keys were automatically adapted as partial keys. If required, these foreign keys can then be redefined in the ABAP Dictionary maintenance transaction.

4. Entering another value table for a domain

If a new value table is allocated to a domain, then all the affected foreign keys are no longer automatically deleted when activating the domain, as was the case before. These foreign keys are retained. However, the activation log logs which affected foreign keys might be inconsistent. These can then be adapted or deleted accordingly.
This simplifies the procedure for implementing a value table which is the check table of the previous value table, where the previous foreign keys are to be retained. There is a transitive foreign key relationship between these foreign key tables in the new value table of the domain. The foreign key relationship between the old and new value tables tables must, of course, be created in this case.