ch04.htm

这个是sap开发语言abap的教育文档

<TT>regio</TT> and <TT>land1</TT> <I>together </I>must be valid.
Therefore, a check table (<TT>ztxt005s</TT>) containing valid
combinations of <TT>regio</TT> and <TT>land1</TT> is needed. After
creating this check table, a compound foreign key is needed in
<TT>ztxlfa1</TT> to validate the combination of <TT>regio</TT>
and <TT>land1</TT> against the check table. Incidentally, <TT>ztxt005s-land1</TT>
should also be validated against <TT>ztxt005-land1</TT> (see Figure
4.4).
<P>
<A HREF="javascript:popUp('f4-4.gif')"><B>Figure 4.4:</B> <I>A compound foreign key
validating the combination of region and country against the check
table</I>.</A>
<P>
You create a compound foreign key almost exactly the same way
as a foreign key containing a single field. You begin by positioning
your cursor on a field, in this case <TT>ztxlfa1-regio</TT>, and
then pressing the Foreign Keys button. Because your cursor is
on <TT>regio</TT>, it becomes the <I>check field</I> of the compound
foreign key. Although the foreign key is composed of multiple
fields, only one of those fields will trigger a check against
the database. Because <TT>regio</TT> is the check<I> </I>field,
a value entered into it on the screen triggers a check. If the
check field is non-blank when the user presses the Enter key,
a check is carried out against the check table comparing all fields
of the foreign key. If the check field is blank, no checking is
done <I>even if the other fields contain values</I>.<P>
<CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=600><B>CAUTION</B></TD></TR>
<TR VALIGN=TOP><TD WIDTH=600>
<BLOCKQUOTE>
As with the simple foreign key, the domain names of the check field and its associated field in the check table must match. However, when the foreign key is created, the rest of the domain names in the compound foreign key do not have to match; the foreign key can be created if only their data types and lengths match. Later, if the data type or length in one of these domains is changed, the fields will no longer match and the results of the foreign key check will be unpredictable. For this reason, although R/3 does not enforce that all domain names of a compound foreign key match, it is highly desirable.</BLOCKQUOTE>
<BLOCKQUOTE>
As a rule of thumb, when changing the data type or length of field in a compound foreign key other than the check field, you must check to see whether the foreign key and check table fields are using the same domain. If they are not, you must update them both to have the same data type and length. Failure to do so will result in unpredictable operation of the foreign key.</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<P>
<P>
If you create a foreign key relationship to a check table containing
more than one field in the primary key, all of the primary key
fields of the check table must be included in the foreign key.
They do not all have to be checked (see the section &quot;Generic
Foreign Keys&quot; that follows), but they all must be included.
<P>
Because most check tables contain the <TT>mandt</TT> field, it
forms a part of most foreign keys (see Figures 4.5 and 4.6).
<P>
<A HREF="javascript:popUp('f4-5.gif')"><B>Figure 4.5 :</B><I>A compound foreign
key involving the mandt field</I>.</A>
<P>
<A HREF="javascript:popUp('f4-6.gif')"><B>Figure 4.6 :</B> <I>The definition of the foreign key shown
in Figure 4.5</I>.</A>
<P>
By including <TT>mandt</TT> in the check table, independent and
valid sets of values can be defined for each logon client and
can differ between clients. This capability is highly desirable
to separate the data between clients and ensure that they are
completely independent of each other.
<P>
F4 help is only available on the check field of a compound foreign
key. When invoking F4 help, all of the primary key fields of the
check table will be displayed. The column containing the check
field will be highlighted in the list. The column widths and titles
come from the Header field in the data elements.
<H3><A NAME="UnderstandingCardinality">
Understanding Cardinality</A></H3>
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://ebooks.cs.biu.ac.il/0672312174/button/newterm.gif">
<P>
The <I>cardinality</I> of the foreign key relationship describes,
for each value in the check table, <I>how many</I> rows of data
are allowed to be in the foreign key table. It is entered on the
Create Foreign Key screen (refer to Figure 4.3). Cardinality is
described as X:Y, where X refers to the check table and Y refers
to the foreign key table. X can only have the values <TT>1</TT>
or <TT>C</TT>, and Y can be <TT>1</TT>, <TT>C</TT>, <TT>N</TT>,
or <TT>CN</TT>.
<P>
The values of X mean:
<UL>
<LI><TT>1</TT>: If the application program deletes a row from
the check table it will also delete the corresponding rows from
the foreign key table. For example, if the application program
deletes the value <TT>US</TT> from the check table, it will delete
all rows from the foreign key table where <TT>land1 = US</TT>.
In other words, if there is a value in the foreign key table,
there is always one and only one row having that value in the
check table.
<LI><TT>C</TT>: Deletes are allowed from the check table without
deleting the corresponding rows from the foreign key table. In
other words, there can be values in the foreign key table without
corresponding values in the check table.
</UL>
<P>
The values of Y mean:
<UL>
<LI><TT>1</TT>: There is always one, and only one, row in the
foreign key table for each row in the check table.
<LI><TT>C</TT>: There is, at the most, one row in the foreign
key table for each row in the check table.
<LI><TT>N</TT>: There is always at least one row in the foreign
key table for each row in the check table.
<LI><TT>CN</TT>: There might or might not be rows in the foreign
key table for each row in the check table.
</UL>
<P>
Cardinality is <I>not enforced</I> by the R/3 system. Specifying
cardinality is optional, and the system will not check cardinality
to determine whether that update should be allowed to take place
if an ABAP/4 program updates a table. The only time cardinality
is used is when you create an aggregate object in the DDIC. 
<P>
<img src="../button/newterm.gif" tppabs="http://ebooks.cs.biu.ac.il/0672312174/button/newterm.gif">
<P>
An <I>aggregate object</I> is a DDIC object composed of more than
one table. An example of an aggregate object is a view.
<P>
When you create a foreign key you should specify the cardinality.
If you don't specify it, you will be unable to include the table
in an aggregate object.
<H3><A NAME="ForeignKeyFieldType">
Foreign Key Field Type</A></H3>
<P>
The foreign key field type should also be specified on the same
screen as the cardinality when you create the foreign key (refer
to Figure 4.3). It can be one of the following values:
<UL>
<LI>Key fields/candidates
<LI>Non-key fields/candidates
<LI>Key fields of a text table
</UL>
<H4>Key Fields</H4>
<P>
Choose Key Fields/Candidates if the foreign key field is one of
the primary key fields of the foreign key table. Choose Non-Key
Fields/Candidates if it is not. For example, assume table <TT>t1</TT>
is composed of fields <TT>f1</TT> through <TT>f10</TT>, and its
primary key fields are <TT>f1</TT>, <TT>f2</TT>, and <TT>f3</TT>.
If you were to define a foreign key on field <TT>f3</TT>, Key
Fields/Candidates would be the correct type because <TT>f3</TT>
is part of the primary key. If you were to define a foreign key
on field <TT>f5</TT>, Non-key Fields/Candidates would be correct
because <TT>f5</TT> is not one of the primary key fields.
<H4>Key Candidates</H4>
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://ebooks.cs.biu.ac.il/0672312174/button/newterm.gif">
<P>
A <I>key candidate</I> is a field in a table that, by itself or
in conjunction with another field that is not part of the primary
key, could be used to uniquely identify a row in the table. To
put it another way, if there is way to uniquely select a row from
a table without using primary key fields, key candidates exist
in that table. The key candidates are the fields <I>not</I> within
the primary key that can be used to uniquely identify a row; in
essence they can serve as an alternate primary key.
<P>
For example, <TT>ztxlfa1</TT> has a single primary key field that
contains a unique identifier for each row. If you assume that
the combination of <TT>erdat</TT> and <TT>ertim</TT> (creation
date and time) is also unique for every row, these date and time
fields are key candidates. If either one appeared in a foreign
key, the correct foreign key type would be key fields/candidates.
<P>
When creating a foreign key, you should choose key fields/candidates
if the foreign key field is one of the primary key fields of the
table or is a key candidate. Choose non-key fields/candidates
if it is not.
<H4>Key Fields of a Text Table</H4>
<P>
The R/3 system supports multiple spoken languages, and thus enables
users to sign on using the language of their choice. Because of
this, descriptions in R/3 are stored in special language-dependent
tables called text tables.<P>
<CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=600><B>TIP</B></TD></TR>
<TR VALIGN=TOP><TD WIDTH=600>
<BLOCKQUOTE>
Users can set their own default logon language. This is done in the user profile by choosing the menu path System-&gt;User profile-&gt;User defaults. Changes to your user profile are not effective until you next log on.</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<P>
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://ebooks.cs.biu.ac.il/0672312174/button/newterm.gif">
<P>
A <I>text table</I> is a table that contains spoken-language descriptions
of values in a check table. These descriptions are stored in multiple
languages. The primary key of the text table is the same as the
primary key of the check table, with the addition of a <TT>spras</TT>
(language) column. 
<P>
For example, the <TT>ztxt005</TT> table has country codes in it.
Country names are stored in a separate table named <TT>ztxt005t</TT>
(shown in Figure 4.7) because you actually need many names for
one country code. Because it stores language-specific descriptions
of a generalized code, <TT>ztxt005t</TT> is called a text table.
<P>
<A HREF="javascript:popUp('f4-7.gif')"><B>Figure 4.7 :</B> <I>The text table for ztxt005 is ztxt005t.
It is composed of the fields mandt, spras, land1, landx, and natio</I>.</A>
<P>
The primary key of <TT>ztxt005t</TT> contains the same fields
as the primary key of <TT>ztxt005</TT>, with the addition of a
<TT>spras</TT> (language) column. The <TT>spras</TT> field contains
the language code and enables this table to contain a description
for multiple logon languages.
<P>
The primary key of any text table is composed of the fields <TT>mandt</TT>
and <TT>spras</TT>, followed by the validation field (or fields).
One or more description fields follow this primary key. 
<P>
A foreign key relationship is defined on <TT>ztxt005t-land1</TT>
to check table <TT>ztxt005</TT>. The foreign key field type should
be <I>key fields of a text table</I>.
<H5>Relating Text Tables to F4 Help</H5>
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://ebooks.cs.biu.ac.il/0672312174/button/newterm.gif">
<BLOCKQUOTE>
The foreign key type &quot;key fields of a text table&quot; indicates
to the R/3 system that the foreign key table is a text table.
When you choose this type, the first description that follows
the primary key is displayed in the F4 help, in the logon language
of the user. Therefore, this key type has two special properties:

<UL>
<LI>When the rows of the check table are displayed in response
to an F4 help request, the first description field from the text
table will appear in the same list, as if it were a part of the
check table.
<LI>Only the rows from the text table having the same language
code as the user's current logon language appear in the F4 help
list.
</UL>

For example, text table <TT>ztxt005t</TT> contains a foreign key
relationship from <TT>ztxt005t-land1</TT> to check table <TT>ztxt005</TT>,
and the type is &quot;key fields of a text table&quot;. When you
invoke F4 help on <TT>ztxt005-land1</TT>, the user sees the primary
key columns of the check table <TT>ztxt005</TT>, <I>plus</I> the
contents of the first column that follows the primary key of <TT>ztxt005t</TT>.
Only the rows where <TT>spras</TT> is equal to the current logon
language are displayed. The result is that the user sees descriptions
in his logon language for the codes in <TT>ztxlfa1</TT>.
</BLOCKQUOTE>
<BLOCKQUOTE>
The contents of tables <TT>ztxt005</TT> and <TT>ztxt005t</TT>
are shown in Tables 4.2 and 4.3.<BR>
</BLOCKQUOTE>
<P>
<CENTER><B>Table 4.2&nbsp;&nbsp;Contents of Table </B><TT><B>ZTX005</B></TT></CENTER><CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=432><TT><I><B>land1</B></I></TT>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=432><TT>US</TT></TD></TR>
<TR VALIGN=TOP><TD WIDTH=432><TT>CA</TT></TD></TR>
<TR VALIGN=TOP><TD WIDTH=432><TT>DE</TT></TD></TR>
<TR VALIGN=TOP><TD WIDTH=432><TT>IT</TT></TD></TR>
<TR VALIGN=TOP><TD WIDTH=432><TT>JP</TT></TD></TR>
<TR VALIGN=TOP><TD WIDTH=432><TT>AQ</TT></TD></TR>
<TR VALIGN=TOP><TD WIDTH=432><TT>CC</TT></TD></TR>
</TABLE>
</CENTER>
<P>
<P>
<CENTER><B>Table 4.3&nbsp;&nbsp;Contents of Table </B><TT><B>ZTXT005T</B></TT></CENTER><CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=144><CENTER><TT><I><B>spras</B></I></TT></CENTER>
</TD><TD WIDTH=144><CENTER><I><B>land1</B></I></CENTER>
</TD><TD WIDTH=144><CENTER><I><B>landx</B></I></CENTER>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=144><CENTER><TT>E</TT></CENTER></TD><TD WIDTH=144><CENTER><TT>CA</TT></CENTER>
</TD><TD WIDTH=144><TT>Canada</TT></TD></TR>