2. Objectives
• The participants will be able to:
– Define and Use Foreign Keys
– Understand the Prerequisites for Constructing
Foreign Key Relationships
– Interpret Cardinality and Foreign Key Field Types
– Create Foreign Key Relation
March-2005 Foreign Key Relationships | 2.03 2
3. Definition of Foreign Keys
March-2005 Foreign Key Relationships | 2.03 3
Relationships between tables are represented in the ABAP Dictionary by
foreign keys.
A foreign key is a field (or combination of fields) that represents the primary
key of another table.
4. Uses of Foreign Keys
• Maintain data integrity
• Provide help texts
• Create aggregate dictionary objects
March-2005 Foreign Key Relationships | 2.03 4
5. Prerequisites for Constructing Foreign
Key Relationships
• The foreign key field and the primary key of
the check table must share the same domain.
• A value table must exist for that domain.
March-2005 Foreign Key Relationships | 2.03 5
6. Foreign Keys: Key Terminology
March-2005 Foreign Key Relationships | 2.03 6
Check TableCheck Table
Value TableValue Table
Foreign Key TableForeign Key Table
The table containing the set of
allowed values attached to a domain
The table that is referenced by a foreign
key
The table containing fields that are
the primary key of the other table
7. Foreign Key Terminology: Check Table
= Value Table
March-2005 Foreign Key Relationships | 2.03 7
Check
Table
Value
Table
In many cases, the value table and the check table will be the same
8. Foreign Key Terminology: Check Table
≠ Value Table
Check
Table
March-2005 Foreign Key Relationships | 2.03 8
Value
Table
Sometimes check table is another table containing a subset of the records in
a value table.
9. Establishing a Foreign Key Relationship
in the ABAP Dictionary
March-2005 Foreign Key Relationships | 2.03 9
Data
Dictionary
During defining Foreign Key Relationship, system suggests a Foreign Key
Relationship for you.
10. Cardinality
March-2005 Foreign Key Relationships | 2.03 10
nn :: mmnn :: mm
1
C
1
C
N
CN
When creating foreign key relationships, you should always specify the cardinality
of that relationship
12. Maintaining a Foreign Key
Relationship’s Attributes
March-2005 Foreign Key Relationships | 2.03 12
Enter a description (short text).
Maintain foreign
key type
Check table
Maintain cardinality n : m
13. March-2005 Foreign Key Relationships | 2.03 13
If the primary key of a check table has multiple fields (i.e. it has a composite
primary key), some type of assignment must be made for each field when
creating a foreign key relationship.
Foreign Keys with Multiple Fields
14. Field-By-Field Assignment
March-2005 Foreign Key Relationships | 2.03 14
Check TableCheck TableForeign Key TableForeign Key Table
When performing a field-by-field assignment, all key fields in the check table
are used to determine valid entries in the foreign key table.
15. Partial Foreign Keys
March-2005 Foreign Key Relationships | 2.03 15
When creating a partial foreign key, certain fields are flagged as generic.
These fields are ignored by the system when validating records that are inserted
into the foreign key table.
16. Constant Foreign Keys
March-2005 Foreign Key Relationships | 2.03 16
“BIO”
When creating a constant foreign key, certain fields are assigned a literal value
Only records in the check table with that value in the corresponding field are
used to determine whether records in the foreign key table are valid.
17. Combined use of Partial and
Constant foreign keys
March-2005 Foreign Key Relationships | 2.03 17
Generic foreign key
Constant foreign keyConstant foreign key
18. Demonstration
• Creation of a new transparent table for
holding the payroll data for employees in an
organization and establish a foreign key
relationship with the employee table created
for the previous chapter.
March-2005 Foreign Key Relationships | 2.03 18
19. Practice
• Creation of a new transparent table for
holding the payroll data for employees in an
organization and establish a foreign key
relationship with the employee table created
for the previous chapter.
March-2005 Foreign Key Relationships | 2.03 19
20. Summary
• Relationships between tables are represented
in the ABAP Dictionary by foreign keys. A
foreign key is a field (or combination of fields)
that represents the primary key of another
table.
• Foreign keys maintain data integrity & provide
help texts.
• In order to establish a foreign key relationship
in SAP, the fields involved must share the
same domain, and that domain must have aMarch-2005 Foreign Key Relationships | 2.03 20
21. Questions
• What is a foreign key ?
• What is the need to define a foreign key
relationship ?
• What is meant by cardinality in a foreign key
relationship ?
March-2005 Foreign Key Relationships | 2.03 21
Editor's Notes
Relationships between tables are represented in the ABAP Dictionary by foreign keys.
A foreign key is a field (or combination of fields) that represents the primary key of another table.
For example, if table YORDERS has a field CUSTID indicating which customer placed the order, that field could be established as a foreign key (assuming that CUSTID was the primary key of the YCUSTOMERS table). Note that CUSTID is not necessarily part of the primary key of the table YORDERS.
The table that is referenced by the foreign key (in our example, YCUSTOMERS) is called the check table. The check table is also known as the “referenced” or “parent” table.
The table that contains the foreign key fields (in our example, YORDERS) is called the foreign key table. The foreign key table is also known as the “dependent” or “child” table.
Foreign keys are used for:
Maintaining data integrity
Providing additional texts in the online help system
Creating other dictionary objects that are defined over multiple tables (such as views)
Maintaining data integrity is probably the most important reason to use foreign keys. With foreign keys, it is possible to prevent values from being entered into one table that do not already exist in another table. For example, it becomes impossible to enter orders that do not have valid customer numbers. In this way, foreign keys are similar to domain value tables.
In fact, not only are foreign keys similar to domain value tables, but in order to establish a foreign key relationship in SAP, the fields involved must share the same domain, and that domain must have a value table specified.
Therefore, foreign keys provide an additional data integrity check beyond that which is provided by the value table.
Prior SAP versions required that Foreign Keys must have a Value Table specified.
Let’s review some of the key terminology relating to foreign keys.
Value table: The table containing the set of allowed values attached to a domain.
Check table: The table that is referenced by a foreign key. A check table is either
identical to a value table, or is another table containing a subset of the records in a value table.
Foreign key table: The table containing fields that are the primary key of the other
table. The foreign key table is also known own as the “dependent” or “child” table.
Using Foreign Keys, you can
Create value checks for input fields.
Link several tables in a view or in a lock object.
To see a full list of the allowed values for a screen field, place the cursor inside the field and hit the F4 key.
For example, suppose a foreign key relationship was established between an ORDERS table and a PRODUCTS table in order to ensure that orders contained valid product numbers. In this case, it is likely that the value table and the check table would both be the PRODUCTS table.
In many cases, the value table and the check table will be the same. However, it is important to understand the distinction between the two.
The Value Table is optional in the foreign key definition.
Foreign Key definitions must always have a Check Table assigned.
For example, suppose a telephone company stores general customer information in the CUSTOMERS table and stores specialised information about business customers in the BUSINESS_CUSTOMERS table.
Suppose that there was also a BUSINESS_OWNERS table that listed the owners of all business customers. The BUSINESS_OWNERS table might consist of two fields: Customer ID and the name of each individual owner.
In this case, we would establish a foreign key relationship between the BUSINESS_OWNERS table and the BUSINESS-CUSTOMERS table.
The value table for the customer ID field in the BUSINESS_OWNERS table would be the CUSTOMERS table, but the check table would be the BUSINESS_CUSTOMERS table.
The foreign key table would be the BUSINESS_OWNERS table.
To establish a Foreign Key in the ABAP Dictionary, begin by navigating to the field definition of the Foreign Key Table and entering change mode.
The Foreign Key can then be established by placing the cursor on the Foreign Key Field, and then by clicking the icon in the Application Toolbar.
Based on the Value Table for the domain of the field you selected, the system will suggest a Foreign Key Relationship for you.
When creating foreign key relationships, you should always specify the cardinality of that relationship. Here is a reminder of the possible values for each side of the n : m notation that SAP uses to specify cardinality.
For the left side:
n = 1Each record in the foreign key table refers to exactly one record in the check table.
n = CEach record in the foreign key table refers to zero or one records in the check table.
For the right side:
m = 1 Each record in the check table has exactly one dependent record.
m = C Each record in the check table has a zero or one dependent records.
m = N Each record in the check table has at least one dependent record.
m = CN Each record in the check table has zero, one, or many dependent entities.
Using the Object Navigator edit the Table ZXXFIRSTTABLE which we created in Chapter 2.
Place the cursor on the field for which you wish to create a Foreign Key Relationship. In this example, we will add the Check Table T005S as a Foreign Key for the STATE field so that users will be forced to enter a valid state into the Table ZXXFIRSTTABLE.
Click the icon to create the Foreign Key Relationship for the STATE field.Remember the criteria for establishing a Foreign Key Relationship: the Foreign Key Field and Check Table Field must share the same domain. A value table must exist for that domain.Since the field STATE’s domain (REGIO) has a Value Table (T005S),
SAP will propose T005S as the Check Table for the field STATE when we click the Foreign Key pushbutton. Click Yes when the Create Foreign Key window appears.
You can see a graphical representation of the foreign key relationships in a table by going to Utilities Graphics. The option to view foreign key relationships graphically is not available in previous releases.
Enter a description (short text).
Maintain the semantic attributes (see Data Dictionary Appendix for information on setting up the Cardinality)
Cardinality n : m
n = 1 or C
m = 1, C, N, CN
Foreign Key Field Type (see Data Dictionary Appendix for information on setting up the Foreign Key Field Type)
Not Specified
Non-Key Field Candidates
Key Field / Key Field Candidates
Key Fields of a Text Table
Click the Copy button at the bottom of the screen.
If the primary key of a check table has multiple fields (i.e. it has a composite primary key), some type of assignment must be made for each field when creating a foreign key relationship. The options include:
Creating a field-by-field assignment. Every primary key field in the check table is
matched with a field in the foreign key table.
Using a partial foreign key. Some fields will not be a determining factor in deciding
what check table records provide acceptable values for the foreign key field being
checked.
Using a constant foreign key. Only check table records with a particular constant
(literal) value in a particular field provide acceptable values for the foreign key field
being checked.
When performing a field-by-field assignment, all key fields in the check table are used to determine valid entries in the foreign key table.
For example, suppose there was a YCOURSES table with the key fields faculty (academic department) and course number. This table would provide the master list of courses that an academic institution offers.
Suppose also that there was a YOFFERINGS table with the key fields faculty, course number, and section number. This table would list the times and dates that different sections of each course were offered.
In this case, we would establish a foreign key relationship from YOFFERINGS to YCOURSES using field-by-field assignment.
In other words, the faculty and course number fields for each record in the YOFFERINGS table would have to match the faculty and course number fields for some record in the YCOURSES table.
When creating a partial foreign key, certain fields are flagged as generic. These fields are ignored by the system when validating records that are inserted into the foreign key table.
For example, suppose that we were tracking information about new courses that were under development in a YNEWCRS table. This table would have faculty and course number as the primary key. However, in this table, we would not want to validate the course number against the YCOURSES table, because by definition the new courses are not yet in the YCOURSES table.
In this case, we might use a partial foreign key from YNEWCRS to YCOURSES and flag the course number field as generic. In other words, the table YNEWCRS would be forced to have valid values in the faculty field, but we could enter any course number we wanted.
This example is for illustration purposes. In a real-world application, there would probably be a separate YFACULTY table that would list valid faculties, and the YNEWCRS table would probably be validated against that table.]
Note: If additional fields are added to the primary key of a check table, the new fields are automatically flagged as generic in any previously existing foreign keys.
When creating a constant foreign key, certain fields are assigned a literal value. Only records in the check table with that value in the corresponding field are used to determine whether records in the foreign key table are valid.
For example, suppose there was a table YBIOCRS that contained specific information about biology courses. The primary key of this table would be course number only (it would already be understood that the courses were biology courses). In this case, we would want to validate the course number against the YCOURSES table, but we would only want biology course numbers to be valid. That is, if there was a course “English 402” but no course “Biology 402”, we would not want 402 to be a valid entry in table YBIOCRS. To accomplish this, we could establish a foreign key from YBIOCRS to YCOURSES with the constant value “BIO” in the faculty field.
Note: Assigning a constant value to a field has the effect of restricting the values that are permissible for the other foreign key fields in the foreign key table. Validation is actually turned off for the field that is assigned the constant value. For example, if we changed the above example so that the table YBIOCRS did have a faculty field, it would be possible to enter any value in that field.
Click on the checkbox provided to flag a foreign key field as generic.
Enter a constant value in quotes to define a foreign key relationship with a constant.
It is possible to combine the use of partial and constant foreign keys within the same foreign key relationship.
