Файл: BC430_EN_Col62_FV_Part_A4_-_ABAP_Dictionary.pdf

Unit 4: Input Checks

BC430

Figure 50: Foreign Key Definitions in the Check Field

In the ABAP Dictionary, the same domain is required for the check field and
referenced key field of the check table so that you do not compare fields with
different data types and field lengths.

Domain equality is essential. Different

data elements can be used, but they must refer to the same domain.

The requirement for domain equality is only valid for the check field. For all other
foreign key fields, it is sufficient if the data type and the field length are equal.
You nevertheless should strive for domain equality. In this case, the foreign key
will remain consistent if the field length is changed because the corresponding
fields are both changed. If the domains are different, the foreign key would be
inconsistent if, for example, the field length were changed.

If the domain of the check field has a value table, you can have the system make a
proposal with the value table as check table. In this case, a proposal is created for
the field assignment in the foreign key.

CAUTION! The constellation that a domain that itself has table SAIRPORT
as value table is used following field SAIRPORT-ID is correct! However, a
foreign key is never defined on this field (avoiding a loop).

108

© 2007 SAP AG. All rights reserved.

2006/Q2

BC430

Lesson: Consistency Through Input Checks

Figure 51: Check Table not Equal to Value Table

If the reusability of the domains is also inserted at unsuitable places, the proposal
may be unsuitable for the check table. In the above case, a primary key field
exists in several tables that is based on the same domain as the check field. The
system proposal is then the value table of the domain. In order to avoid this
problem from the beginning

In the above example for the foreign key definition for field
SBOOK-AGENCYNUM, the system proposal is as follows based on the value
table in the domain:

Check table: SBUSPART

Field assignment:
Check table

Foreign key table

SBUSPART-CLIENT

SBOOK-MANDT

SBUSPART-BUSPARTNUM

SBOOK-AGENCYNUM

This proposal doesn't do what you want:

The SBUSPART table contains all the business partners of airline carriers.
However, only agencies are allowed for field SBOOK-AGENCYNUM. Table
SBUSPART therefore contains invalid data for this field. The system proposal is
therefore incorrect! The right check table is table STRAVELAG. It is a subset of
table SBUSPART due to its foreign key definition on field AGENCYNUM.

2006/Q2

© 2007 SAP AG. All rights reserved.

109

Unit 4: Input Checks

BC430

You must overwrite the system proposal with table STRAVELAG. If you
do not know the correct check table, the system can help you by listing all
the tables in question. This includes all the tables that have a key field with
domain S_ BUSPARNUM.

Figure 52: Semantic Attributes

The cardinality describes the foreign key relationship with regard to how many
records of the check table are assigned to records of the foreign key table. The
cardinality is always defined from the point of view of the check table.

The type of the foreign key field defines whether or not the foreign key field
identifies a table entry. This means that the foreign key fields are either key
fields or they are not key fields or they are a special case, namely the key fields
of a text table.

110

© 2007 SAP AG. All rights reserved.

2006/Q2

BC430

Lesson: Consistency Through Input Checks

There are the following kinds of foreign key fields:

•

Not specified:

No information about the kind of foreign key field can be

given.

•

No key fields / candidates:

The foreign key fields are neither primary key

fields of the foreign key table nor do they uniquely identify a record of the
foreign key table (key candidates). The foreign key fields therefore do not
(partially) identify the foreign key table.

•

Key fields / candidates:

The foreign key fields are either primary key fields

of the foreign key table or they uniquely identify a record of the foreign key
table (key candidates). The foreign key fields therefore (partially) identify
the foreign key table.

•

Key fields of a text table:

The foreign key table is a text table in the check

table. For example, the key of the foreign key table differs from the key of
the check table only in that it has an additional language key field. This is a
special case of the category

Key fields / candidates

.

Figure 53: Text table

Table SMEAL contains the meals served to the passengers during a flight. The
meal names are maintained in table SMEALT.

Table SMEALT is the text table for table SMEAL since the key of SMEALT
consists of the key of SMEAL and an additional language key field (field with
data type LANG).

2006/Q2

© 2007 SAP AG. All rights reserved.

111

Unit 4: Input Checks

BC430

Table SMEALT can contain explanatory text in several languages for each key
entry of SMEAL.

To link the key entries with the text, the text table SMEALT must be linked with
table SMEAL using a foreign key.

Key fields of a text table

must be chosen for the

type of the foreign key fields.

The foreign key relationship is defined from SMEALT to SMEAL.

Only one text table can be linked with a table.

112

© 2007 SAP AG. All rights reserved.

2006/Q2