Professional Documents
Culture Documents
Ab 4 Dict
Ab 4 Dict
application development and shows how they are mapped to the underlying
relational database in tables or views.
Tables, Structures and Views are the three most important objects of
workbench.
The basic objects for defining data in the ABAP/4 Dictionary are tables,
domains and data elements. Domains are used for the technical definition
(for example field type, field length) of a table field, and data elements for the
semantic definition (for example, short description).
Fields are not independent objects: they are dependent on tables and can
The domain is the central object for describing the technical characteristics
objects. Like Data Elements, Domains are also stored as objects in the
Dictionary. And you can reuse the Domain object for different fields within
the same table or among fields in other tables.
These relationships are known as foreign keys and must be explicitly defined
at field level.
Foreign keys are used above all to ensure the consistency of data. Data
entered should be checked against existing data to ensure that there are no
contradictions. (For example: assignment of a printer that does not exist.)
A foreign key provides a link between two tables T1 and T2. Both the tables
should have the same field names existing in them. In table T1 there is a
reference to the primary key of table T2. In T1, the foreign key fields are
assigned to the primary key fields of T2. The table to be checked i.e. Table
T1 is called the foreign key table (dependent table) and table T2 is called the
check table (referenced table).
The fields from the two tables, which are paired to form the foreign key
relationship, should be of the same data type and length. In other word one
foreign key from one table should correspond with the primary key of the
other table.
If a foreign key is defined between two tables, a record of the foreign key
table refers to a record of the check table. A record is identified via its key,
so in the foreign key definition in the foreign key field it is sufficient to refer
to the primary key of the check table.
In order to avoid the comparison of fields with different data types and field
lengths, the same domain is required within the ABAP/4 Dictionary behind
the check field and the referenced primary key field.
CAUTION!
The requirement that the domain be the same applies only to the foreign
key definition for the check field. For all other foreign key fields, it is
sufficient if the data class and field lengths are the same. You should
nevertheless ensure that the domain is the same. When the field length is
changed, the foreign key remains consistent, because both the assigned
fields have been changed (same domain). When the domains are not the
same, the foreign key becomes inconsistent when the field length, for
example, is changed.
In short, A field defined as Foreign key in one table should be defined as
While defining the foreign key relationship the cardinality has to be specified
Cardinality mentions in a foreign key relationship how many dependent
Domains for the foreign key fields in the check table and the reference table
The
The technical settings can be used to determine how the table should be
treated when it is created in the database, whether the table is buffered and
whether changes to entries should be logged.
The buffering settings determine whether the table is buffered and how. The
Buffering Type (Full, Single Record, Generic) parameter specifies how many
records are loaded into the buffer when a table entry is accessed.
In the Logging entry, you can specify whether changes to the table entries
should be logged.
The most important data classes are master data, transaction data,
master data is the data contained in an address file, such as name, address
and telephone number.
data is the stock of goods in a warehouse, which changes each time an order
is processed.
is configured and is then rarely changed. The table with country keys is an
example.
System data is data, which the R/3 System itself needs. Tables containing
The size category describes the probable space requirement of the table in
the database.
You can choose a size category between 0 and 4. Each category is assigned
records of buffered tables are thus read from the local buffer of the
application server on which the accessing transaction is running.
While creating the table we will also see how to create a Data Element and
Domain.
Tables can be created by following the path Tools ABAP/4 Workbench
ABAP/4 Dictionary or Transaction Code SE11. Following this path you can
also create other ABAP/4 dictionary like Structures, Data Elements,
Domains, Views, Matchcodes etc.
Enter a name of the table in the Object Name box and click on the Tables
The name of the table should begin with a Z or Y. let us create a table with
the name YEMP1.
Enter a table name, select the Tables radiobutton and then Click on Create
button.
in the table.
Enter the Data Element Name. Lets create a Data Element called YEMPNO.
Double click on the Data Element name.
If the data element is not existing in the dictionary then you will get a Create
Data Element pop up. If the data element is existing then you will be taken
to the data element information screen in display mode and when you come
back by pressing the BACK icon you will find the field type length and other
information filled.
Click on the enter button if you want to create a new data element
Enter the description of the data element. It is recommended that you give
You can also enter documentation for the data element. Choose Goto
Documentation. Or press F9. The text that you enter here will be displayed
when you press F1 on the field.
documentation like the possible cause of error, what should be done in case
of error etc.
Note : You can also change the docu status with transaction SE61.
/ field
If the domain is not existing then you will get a pop up asking to create one.
Click on the Yes button
Enter the description for the domain in the Short text area
Specify the data type in the Data Type box in the Format area
Specify the field length
application toolbar.
Click on the BACK icon. You will come back to the Data Element
specification screen
In the TEXTS are enter Short, Medium and Long field label names for the
field
You will get a popup screen Specify a Development Class to save the object.
Activate the data element by clicking on the Activate icon
Click on the BACK icon to come back to the table definition screen
Save the table
Click on the local object button
Activate the table by clicking on the Activate button
You will get a pop up as follows :
Enter the Data Class. Enter APPL1 in the data class field. Data Class APPL1
indicates that the field is updated frequently.
Enter the Size Category. The Size Category defines the expected memory
space required by the table on the database. You have 0 to 4 size category
to choose from for your tables. It defines the size of the table extents. Enter
1 in the Size Category. The value 1 in the size category indicates that the
table is small.
Using the Logging flag, you can log / keep track of the changes (Deletes,
Updates etc.) made on the table. The changes are logged in the table
DBTABPRT. To switch on the logging, a parameter rec/client should be set
in the system profile.
The above parameter can have the following values:
rec/client = 000[,...]
rec/client = OFF
rec/client = ALL
This parameter defined whether the all clients or selected clients should be
logged.
You can also specify the buffering type
icon to save the table and click on Generate icon to activate the table.
To create more fields in the table, click on the New Fields button on the
We have added one more field EMPNAME to the table. Now the table structure
looks like this :
This is how you can create a table. You can use the existing data elements
by placing the cursor in the data element box and then pressing the F4 key.
You can also reuse the domains that you create. You can also create Data
Elements with the existing domains.
You can display the table contents by going to Utilities Table Contents
Structures are defined in the same way as tables. However, a structure does
Structures are defined and activated in the ABAP/4 Dictionary. They can
Since structures that are used more than once are defined centrally, they
can also be changed centrally. These changes are then effected at all
relevant points by the active ABAP/4 Dictionary
domains, data elements and the table definition. The runtime object
(nametab) collects this information in a table in a form, which is optional for
application program access.
Summary information about the table (number of fields, total of the lengths
of all table fields, number of key fields, total of lengths of all key fields,
information on whether the table is client specific and how it is buffered,
and so on) is stored in the runtime object. In addition, it contains
information about the table fields (field name, position of the field in the
table, data type, length, decimal places, reference field, check table,
conversion routine, and so on).
an import, you can use the program RDDMASG0 for mass activation.
activated along with the table and are automatically created with it in the
database.
ID. The index ID may contain only letters and figures. The ID '0' is reserved
for the primary index.
Combining the name of the table and the index ID creates the index name in
the database. Table names with fewer than 10 places are filled with
underscores with the ID being added on at the end. The index ID is thus
always located at positions 10-13.
specific fields. This data exists in this copy in sorted form. This sorting
enables fast access to the data records of the table. In order that the
remaining fields can also be read, that is, those fields not contained in the
index, a pointer to the associated record of the actual table are included in
the index.
The database utility allows you to create and delete objects defined in the
object.
Check
Views, Match code objects, lock objects etc. is known as aggregated objects.
Using Views, you can permit access to certain set of data from a table or a
In this way, data from different tables can be combined in a logical manner
Aggregate objects in the ABAP/4 Dictionary are objects, which are formed
tables.
Views make it possible to provide the user with information from fields of
Views are used mainly for programming with ABAP/4 and for the F4 help.
Views are used to represent data which is distributed between many tables
Data of a view is not actually physically stored. The data in a view is derived
join operation
The data that is selected using a view depend on whether the views
Using the inner join, you can retrieve records which are there in the entire
table involved in the view i.e. you only get the records of the primary table
which also have the same record in the secondary tables of the view.
Using an outer join you can also select the records for which there are no
Note :
The join conditions for database views can be formulated using equality
relationships between any base fields. The join conditions for the other view
types must be obtained from existing foreign keys. Tables therefore can only be
combined into a maintenance view or help view if they are linked to one another
with foreign keys.
Dictionary.
Give the view name and click the view radio button
Click on the create button
DB views can be created on the database and are defined in the ABAP
Dictionary once they are activated. They are provided for the user as virtual
tables.
If a DB view is also to be used to insert new records in its (only) base table,
the initialization flag should be set for the base table fields which are not
view fields. In this case, these fields will automatically be filled with the
initial value by the view when a new record is inserted.
Specify the Join condition between the tables in the Join Conditions box
From the popup screen select the combination of the tables relationships
and the click the Copy icon. You will get the joins conditions defined for you.
Next place the cursor in the box of the tables and click on the TabFileds
button on the toolbar to select the fields from each table to include the fields
from those tables to be included in the View. For our Example Lets place it
on SPFLI table.
In the pop up box check the fields that you want to include in the view and
Do the same for the tables whose fields you would like to have as part of the
view. Let us select some fields from SFLIGHT and SCARR tables
These fields will appear in the View Fields area
Save and activate the view. When you save, you will be prompted for a
Development class.
You can also specify the selection condition for the view
Choose Goto Selection Condition or click on the Next Screen icon on the
tool bar
The Selection Condition box will appear in place of View Fields box
Give the condition by specifying the table name, field name, operator,
comparison value and the AND/OR condition in case you want to more
fields in the selection condition
You can type in the detail if you are sure of them or else place the cursor in
You will get a pop box with the table name, which you had selected, in the
first screen
Double click on the table name to get the list of the fields for the table
Check the field(s) on which you want to base the condition and click on the
Note: You could have still displayed the data without specifying conditions. In
short, specifying conditions is optional.
After you display the data from the view, you can download to an
Go the location where the file was created and open the file with the
appropriate application
It also possible to access Pooled and Cluster tables using Projection View.
The remaining fields are the fields of the views defined by join selection and
projection.
From the pop up box select the Projection View type radio button and click
on choose
Place the cursor in the View Fields area and click on the TabFields button
the toolbar
In the pop up box you will get the list of the fields of the table. Check the
After you display the data from the view, you can download to an
Go the location where the file was created and open the file with the
appropriate application
Maintenance Views are more like Database views where you have specify the
foreign key relationship between the tables. The foreign key relationship
should exist between the tables i.e. data from several tables can be
presented to in Maintenance view collectively.
All the tables used in the Maintenance View should have a foreign key
relationship.
From the pop up box select the Maintenance View type radio button and
click on choose
You will get a pop up box with the foreign key relationship of the base table
Mark the Check box and click the Copy icon / button
The candidate table will be displayed in the Tables box and the foreign key
You can also specify Selection Conditions by clicking on the Next Screen
icon. (Follow the Steps in the Database View to specify the Selection
Condition)
Specify the Maintenance Screen numbers in the Overview Screen and Single
Click the Maintain button and you will get the output
You can create New Entries by clicking on the New Entries button on the
application toolbar, Change the field contents, delete etc., but these changes
will not be reflected in the tables
Once
The generated maintenance dialog can be started at any time with the menu
path System Services Ext. table maint.
A maintenance interface for a single database table can also be generated in
the transaction Table view generation. If a text table exists for it, this text
table can be automatically maintained.
All the tables used in a help view must be linked with foreign keys. Only
foreign keys which have certain semantic attributes can be used here
The steps are the same as that for a Database View or Maintenance View
The help view is a type of view, which was specially designed for the
requirements of the possible entries help. Help views are also defined using
the relational operations join selection and projection. However, there are
several important differences to the DB view.
SAP HELP only uses help views. In particular, it is not possible to access
The order of base tables in a help view cannot be changed. The primary
table plays a special role. The help view is used as possible entries help for
exactly those fields which are checked against this table. This is done
automatically. For this reason, a table may not be the primary table of more
than one help view.
There are special restrictions for the foreign key relationships used to set up
a help view. They must be defined so that at most one record of the
successor table is assigned to a record of the predecessor table. The
successor table may also be a text table for the predecessor table. In this
case, only those records of the text table that have the log on language in
the language field are automatically taken into consideration when creating
the view.
Search Help has replaced Matchcodes in 4.0B. Existing Matchcodes have been
converted into Search helps with the same name.
Matchcodes are tools for finding data records, which are stored in the
system. They are an efficient and convenient search help if the key is not
known.
formed from the base tables of this matchcode object by join, selection and
projection. The definition of a matchcode ID can also influence the way in
which the search help is displayed.
some differences:
matchcode object.
The secondary tables must be selected from the secondary tables of the
matchcode object.
The fields must be selected from the fields of the matchcode object. They are
also given the names, which they had when the matchcode object was
defined. Various definitions can also be made concerning the output
characteristics of the fields.
matchcode ids
table
Select the tables that you would want to include in the matchcode
From each selected secondary table, select the fields to be included in the
matchcode.
Click on the fields buttons the toolbar.
Click on Choose Sec. Tables button and select the tables from the list
displayed
Enter the matchcode fields by which you want to search the records
These should have been selected in the matchcode object
You can create nine matchcode ids for a matchcode object
Certain names are not allowed because they are used in database systems or
because of SAA naming conventions. These names may not be used as names
for tables, views or table fields. When creating a table or a view, a check is made
on whether or not the intended name is allowed. The corresponding check is
performed during activation for table fields.
The reserved names are entered in the table TRESE. This table has two fields.
In the first field the reserved names are entered, in the second the reason the
name is reserved. This is normally the (abbreviated) name of the database
system, which causes the name to be reserved. If the name violates the SAA
naming conventions, SAA is entered.
Because the table TRESE can be extended, for example when a new database
system is supported, the activation program distinguishes two cases when
checking the field names. If the field is new, the activation of the table is
rejected. You must then change the field name. If the table was previously
active with the field, only a warning is output and the table is nevertheless
activated.
For transparent tables, structures and pooled/cluster tables, you should use
the name ranges Y* and Z*. The name ranges T9* and P9* are intended for
special tables. T9* is intended for pooled tables in the ATAB pool and P9* for
customer-specific information types (HR).
Note that the names of some SAP objects violate these naming conventions.
These objects were developed before the introduction of the naming
conventions. In view of the problems involved and for the sake of stability, SAP
did not rename these objects. The names of these objects are listed in the
exception table TDKZ and may also not be used when creating customer
objects.
Name length
Domain
10
Data element
10
YNAME12
Data element4
supplement
Matchcode object 4Y*, Z*
Matchcode ID
1
Pool/cluster
10
ZCLUSTER
Lock object
10
EZNAME
Structure
10
ZSTR123 Transp.
table
Index code
Appends
YAPPEND
Fields
YYFELD View
Helpview
H_ZVIEW
Customer includes
Example
Y*, Z*
Y*, Z*
YNAME, Z1234
ZNAME,
9000 to 9999
YMCO, ZMCO
0 to 9
Y*, Z*
YMCO1, ZMCO7
YPOOL,
EY*, EZ*
EYNAME,
YSTRUKT,
10
YTAB1, ZTAB2
3
10
Y*, Z*
Y*, Z*
Y12, ZAB
ZAPPEND,
10
10
10
YY*, ZZ*
Y*, Z*
H_Y*, H_Z*
ZZFELD,
YVIEW, ZVIEW
H_YVIEW,
10
CI_*
CI_KUNDE
Or
2. Tools ABAP/4 Workbench Overview Data Browser
- Data display/maintenance (Data Browser) (SE16)
Index
Tools ABAP/4 Workbench Development ABAP/4 Dictionary (Dictionary
object: Table, enter table name and choose operation)
Goto Indexes or pushbutton Indexes...
Technical Settings
Tools ABAP/4 Workbench Development ABAP/4 Dictionary (Dictionary
object: Table, enter table name and choose operation)
Goto Technical settings or pushbutton Technical settings
Matchcode ID
Tools ABAP/4 Workbench Development ABAP/4 Dictionary (Dictionary
object: Matchcode objects, enter matchcode object name and choose operation)
Goto Matchcode IDs or pushbutton Matchcode IDs
Database Utility
Tools ABAP/4 Workbench Development ABAP/4 Dictionary (Enter
Dictionary object and object name and choose operation)
Utilities Database utility
- Database utility (SE14)
Storage Parameters
Tools ABAP/4 Workbench Development ABAP/4 Dictionary (Enter
Dictionary object and object name and select operation)
Utilities Database utility
Goto Storage parameters or pushbutton Storage parameters
- Database utility (SE14) Goto Storage parameters
Fixed Values
Tools ABAP/4 Workbench Development ABAP/4 Dictionary (Dictionary
object:Domain, enter domain name and choose operation)
Goto Fixed values or pushbutton Fixed values
Maintenance View
Tools ABAP/4 Workbench Development Other tools
Gen.tab.maint.dialog
- Table view generation (SE54)
ExtendedDataDisplay
System Services Ext. table maint.
- Maintain Table Views (SM30)
Transparent Tables :
A transparent table in the dictionary has one-to-one relationship with a table in
the database. Its structure in the R/3 Data Dictionary corresponds to a single
database field. The database table has the same name, the same number of
fields, and the fields have the same names as the R/3 table definition.
The transparent tables hold application data. Application data is master data or
transaction data used by an application.
Pooled Tables :
A pooled table has many-to-one relationship with the table in the database. For
one table in the database, there are many tables in the R/3 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.
A pooled table is stored in a table pool at the database level.
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 hold only pooled tables.