ch03.htm

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

with database tables. Both can appear as many tables in R/3, but
they are stored as a single table in the database. The database
table has a different name, different number of fields, and different
field names than the R/3 table. The difference between the two
types lies in the characteristics of the data they hold, and will
be explained in the following sections.
<H3><A NAME="TablePoolsandPooledTables">
Table Pools and Pooled Tables</A></H3>
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://ebooks.cs.biu.ac.il/0672312174/button/newterm.gif">
<P>
A <I>pooled table </I>in R/3 has a many-to-one relationship with
a table in the database (see Figures 3.1 and 3.2). For one table
in the database, there are many tables in the R/3 Data Dictionary.
The table in the database has a different name than the tables
in the DDIC, it has a different number of fields, and the fields
have different names as well. Pooled tables are an SAP proprietary
construct. 
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://ebooks.cs.biu.ac.il/0672312174/button/newterm.gif">
<P>
When you look at a pooled table in R/3, you see a description
of a table. However, in the database, it is stored along with
other pooled tables in a single table called a <I>table pool.</I>
A table pool is a database table with a special structure that
enables the data of many R/3 tables to be stored within it. It
can only hold pooled tables.
<P>
R/3 uses table pools to hold a large number (tens to thousands)
of very small tables (about 10 to 100 rows each). Table pools
reduce the amount of database resources needed when many small
tables have to be open at the same time. SAP uses them for system
data. You might create a table pool if you need to create hundreds
of small tables that each hold only a few rows of data. To implement
these small tables as pooled tables, you first create the definition
of a table pool in R/3 to hold them all. When activated, an associated
single table (the table pool) will be created in the database.
You can then define pooled tables within R/3 and assign them all
to your table pool (see Figure 3.2).
<P>
<A HREF="javascript:popUp('f3-2.gif')"><B>Figure 3.2 : </B><I>Pooled tables have a many-to-one relationship
with table pools</I>.</A>
<P>
Pooled tables are primarily used by SAP to hold customizing data.
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://ebooks.cs.biu.ac.il/0672312174/button/newterm.gif">
<P>
When a corporation installs any large system, the system is usually
customized in some way to meet the unique needs of the corporation.
In R/3, such customization is done via <I>customizing tables</I>.
Customizing tables contain codes, field validations, number ranges,
and parameters that change the way the R/3 applications behave.
<P>
Some examples of data contained in customizing tables are country
codes, region (state or province) codes, reconciliation account
numbers, exchange rates, depreciation methods, and pricing conditions.
Even screen flows, field validations, and individual field attributes
are sometimes table-driven via settings in customizing tables.
<P>
During the initial implementation of the system the data in the
customizing tables is set up by a functional analyst. He or she
will usually have experience relating to the business area being
implemented and extensive training in the configuration of an
R/3 system.
<H3><A NAME="TableClustersandClusterTables">
Table Clusters and Cluster Tables</A></H3>
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://ebooks.cs.biu.ac.il/0672312174/button/newterm.gif">
<P>
A <I>cluster table</I> is similar to a pooled table. It has a
many-to-one relationship with a table in the database. Many cluster
tables are stored in a single table in the database called a <I>table
cluster</I>.
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://ebooks.cs.biu.ac.il/0672312174/button/newterm.gif">
<P>
A <I>table cluster</I> is similar to a table pool. It holds many
tables within it. The tables it holds are all cluster tables.
<P>
Like pooled tables, cluster tables are another proprietary SAP
construct. They are used to hold data from a few (approximately
2 to 10) very large tables. They would be used when these tables
have a part of their primary keys in common, and if the data in
these tables are all accessed simultaneously. The data is stored
logically as shown in Figure 3.3. 
<P>
<A HREF="javascript:popUp('f3-3.gif')"><B>Figure 3.3 : </B><I>Table clusters store data from several tables
based on the primary key fields that they have in common</I>.</A>
<P>
Table clusters contain fewer tables than table pools and, unlike
table pools, the primary key of each table within the table cluster
begins with the same field or fields. Rows from the cluster tables
are combined into a single row in the table cluster. The rows
are combined based on the part of the primary key they have in
common. Thus, when a row is read from any one of the tables in
the cluster, all related rows in all cluster tables are also retrieved,
but only a single I/O is needed. 
<P>
A cluster is advantageous in the case where data is accessed from
multiple tables simultaneously and those tables have at least
one of their primary key fields in common. Cluster tables reduce
the number of database reads and thereby improve performance.
<P>
For example, as shown in Figure 3.4, the first four primary key
fields in <TT>cdhdr</TT> and <TT>cdpos</TT> are identical. They
become the primary key for the table cluster with the addition
of a standard system field <TT>pageno</TT> to ensure that each
row is unique.
<P>
<A HREF="javascript:popUp('f3-4.gif')"><B>Figure 3.4 : </B><I>The cdhdr and cdpos tables have the first
four primary key fields in common and are always accessed together
and so are stored in the table cluster cdcls</I>.</A>
<P>
As another example, assume the data from order header and order
item tables is always needed at the same time and both have a
primary key that begins with the order number. Both the header
and items could be stored in a single cluster table because the
first field of their primary keys is the same. When implemented
as a cluster, if a header row is read, all item rows for it are
also read because they are all stored in a single row in the table
cluster. If a single item is read, the header and all items will
also be read because they are stored in a single row.
<H3><A NAME="RestrictionsonPooledandClusterTables">
Restrictions on Pooled and Cluster Tables</A></H3>
<P>
Pooled and cluster tables are usually used only by SAP and not
used by customers, probably because of the proprietary format
of these tables within the database and because of technical restrictions
placed upon their use within ABAP/4 programs. On a pooled or cluster
table:
<UL>
<LI>Secondary indexes cannot be created.
<LI>You cannot use the ABAP/4 constructs <TT>select distinct</TT>
or <TT>group by</TT>.
<LI>You cannot use native SQL.
<LI>You cannot specify field names after the <TT>order by</TT>
clause. <TT>order by primary key</TT> is the only permitted variation.
</UL>
<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>
The use of pooled and cluster tables can prevent your company from using third-party reporting tools to their fullest extent if they directly read data-base tables because pooled and cluster tables have an SAP proprietary for-mat. If your company wants to use such third-party tools, you may want to seek alternatives before creating pooled or cluster tables.</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<P>
Because of these restrictions on pooled and cluster tables and
because of their limited usefulness, this book concentrates on
the creation and use of transparent tables. The creation of pooled
and cluster tables is not covered.
<H2><A NAME="ExploringTableComponents"><FONT SIZE=5 COLOR=#FF0000>
Exploring Table Components</FONT></A></H2>
<P>
You now know what transparent tables are, and the differences
between transparent, pooled, and cluster tables. You will now
learn the components that are needed to create tables.
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://ebooks.cs.biu.ac.il/0672312174/button/newterm.gif">
<P>
A table is composed of fields. To create a field you need a <I>data
element</I>. The data element contains the field labels and online
documentation (also called <I>F1 help</I>) for the field. It is
purely descriptive; it contains the semantic characteristics for
the field, also known as the &quot;business context.&quot; The
labels you provide within a data element will be displayed on
the screen beside an input field. The data element also contains
documentation that is displayed when the user asks for help on
that field by pressing the <BR>
F1 key.
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://ebooks.cs.biu.ac.il/0672312174/button/newterm.gif">
<P>
A data element's definition requires a <I>domain</I> (see Figure
3.5). The domain contains the technical characteristics of a field,
such as the field length and data type.
<P>
<A HREF="javascript:popUp('f3-5.gif')"><B>Figure 3.5 : </B><I>Tables are composed of fields that are composed
of data elements, which, in turn, are composed of domains</I>.</A>
<P>
Domains and data elements are reusable. A domain can be used in
more than one data element, and a data element can be used in
more than one field and in more than one table.
<P>
For example, assume you need to design a customer information
table called <TT>zcust</TT> that must contain work, fax, and home
telephone numbers (see Figure 3.6).
<P>
<A HREF="javascript:popUp('f3-6.gif')"><B>Figure 3.6 : </B><I>A design example using tables, data elements,
and domains</I>.</A>
<P>
To create a field, you usually start by creating a domain for
it. In this case, you might create a generic telephone number
domain, name it <TT>zphone</TT> and give it a data type of <TT>CHAR</TT>
and a length of 12. This would be a generic telephone number domain;
most types of telephone numbers could be stored using this domain.
As such, it can be used to define specific types of telephone
numbers, such as fax or home telephone numbers. 
<P>
After creating the domain to hold the purely technical description
of a field, you then create a data element to hold the descriptive
attributes of the field. In the data element you must enter the
name of a domain to give it technical characteristics. Then, you
enter the labels and documentation (F1 help) to describe the data
you will store. In this example, you would probably create three
data elements, one for each of the home, work, and fax telephone
numbers. In each data element, you would enter field labels describing
the type of telephone number you will store with it, and the F1
help for the end-user.
<P>
Having created the data elements, you can now create the table.
You could create three phone number fields in the table (home,
work, and fax) and assign the corresponding data element to each
field. A data element is assigned to each field. This gives the
field descriptive information from the data element and technical
information from the domain that it references. When the field
is used on a screen, it obtains a label and F1 help documentation
from the data element, and its length and data type form the domain
within the data element.
<P>
In another example, you might need to store a person's name in
three different tables: customer, vendor, and employee tables.
In the customer table you want to store a customer name, in the
vendor table a vendor name, and in the employee table an employee
name. Because it is a good idea to give the same data type and
length to all person-name fields, you can create a single generic
person-name domain, for example <TT>zpersname</TT>. Then you can
create a data element for each business usage of a person's name:
for the customer name, the vendor name, and the employee name.
Within each data element you refer to your <TT>zpersname</TT>
domain to give them all the same characteristics. You could then
use these data elements to create fields within each table.
<H3><A NAME="MaintainingTechnicalCharacteristicsofFields">
Maintaining Technical Characteristics of Fields</A></H3>
<P>
If you need to change the length of the field after you have created
a table, you only need to change it in the domain. If the domain
is used in more than one table, the change is automatically propagated
to all fields that use that domain.
<P>
For example, if the business analysts requested that you increase
the length of your person name field from 12 to 15 characters,
you would change the length in the <TT>zpersname</TT> domain.
When you activate your change, the lengths of all name fields
based upon this domain (in the customer, vendor, and employee
tables) will also change. 
<H3><A NAME="DeterminingWhentoCreateorReuseDomainsandDataElements">
Determining When to Create or Reuse Domains and Data Elements
</A></H3>
<P>
Each R/3 system comes with more than 13,000 preexisting domains
created by SAP. When you create a new field, you must decide whether
to create a new domain or reuse an existing one. To make this
decision, determine whether the data type or length of your field
should be dependent on an existing SAP field. If your field should