ABAP DICTIONARY OBJECTS

Topics
▪ Introduction
➢ RDBMS Concept
➢ Data Modeler
➢ SAP Architecture
▪ Data Dictionary Objects
➢ Domain
➢ Data Elements
➢ Tables
Topics
▪ VIEWS
➢ Types of view
➢ Creation of Views
▪ Search Help
▪ Table Maintenance
Generator
Topics
▪ Introduction
➢ RDBMS Concept
➢ Data Modeler
➢ SAP Architecture
▪ Data Dictionary Objects
➢ Domain
➢ Data Elements
➢ Tables
RDBMS CONCEPT
▪ Relational Database Management System

▪ Database – Collection of data.

▪ A database management system - a collection of interrelated data and a set of programs to access
those data. A relational DBM system - a collection of tables which represents the data and the
relationship among the data.

▪ A table is a two-dimensional matrix which consists of lines and columns(fields). A row in a table
represents a relationship among a set of values.

▪ A field or combination of fields which uniquely identifies every line in a table is known as the
primary key.

▪ A combination of fields in a table is known as the foreign key if it is also the primary key in another
table. Represents the relationship between objects.

www.applexus.com
RDBMS Concept Contd…..

▪ The data is stored in relational database tables in the R/3 system.

▪ In the R/3 system, this data model is managed in the ABAP dictionary.

▪ The data required by all the applications is collected together and managed in a pool known as the
relational database

▪ All the application programs address this database, normally by means of the extensively
standardized SQL (Structured Query Language).

www.applexus.com
Relationship & Cardinality

• Entity – An entity is a thing or object in the real world that is distinguishable from all other objects
and for which information is to be stored. For example, each person in an enterprise is an entity.

• Entity types – Entities are divided into entity types according to their properties. Each entity type is
assigned attributes which describe the entities of the entity type.

www.applexus.com
ATTRIBUTE

▪ Attributes define the possible properties for entities of an entity type.

▪ An attribute consists of a name and a definition of the possible values for the attribute. For example,
the attribute color with the values white, black, yellow, and so on.

▪ One or more attributes are labeled as key attributes. The values of the key attributes uniquely
identify an entity within its entity type.

▪ Example:- Attributes of the entity type Student – Student Id, Name, Address, Department.

▪ Here Student Id is the primary Key.

www.applexus.com
Relationship Category

A relationship category can be

▪ hierarchical
▪ aggregating
▪ referential
▪ external

www.applexus.com
Relationship

▪ A relationship is an association among several entities.

▪ Relationships between two entity types are defined by specifying the two entity types involved, that
is, the source entity type (the independent) and the target entity type (the dependent entity type).

Eg: Student , Department

▪ The relationship is oriented; from the independent entity type to the dependent entity type.

www.applexus.com
Hierarchical Category:

Hierarchical Category:

▪ The target entity type is existentially dependent upon the source entity type

▪ The target entity type is generated from the source entity type

▪ The target entity type represents a semantic refinement

▪ The key of the source entity type becomes part of the key of the target entity type. The relationship
between two entities may not be changed

www.applexus.com
Aggregating Category

Aggregating Category:

▪ The target entity type is existentially dependent upon the source entity type

▪ The target entity type is generated from the source entity type.

▪ At least one other source entity type, different from the first one, is involved in the formation of the target
entity type.

www.applexus.com
Referential Category

▪ Referential Category:

▪ The target entity type is existentially dependent upon the source entity type

▪ The source entity type determines the context of the target entity type, but this does not generate the
target entity type.

www.applexus.com
External Category:

External Category:

▪ Relationship between an entity type within a data model and an entity type outside the data model.

www.applexus.com
CARDINALITY

▪ The cardinality (n : m) describes the relationship with respect to the number of dependent entities
(entities of the target entity type of the relationship) and referenced entities (entities of the source
entity type) allowed for the relationship.
▪ The possible values for the left sides of the cardinality have the following significance:

n=1
Each dependent entity has one referenced entity.

n=C
Dependent entities can exist that do not refer to an entity of the source entity type.

www.applexus.com
CARDINALITY

▪ The possible values for the right sides of the cardinality have the following significance:

m=1
Each entity of the source entity type has one dependent entity.

m=C
Each entity of the source entity type has a maximum of one dependent entity.

m=N
Each entity of the source entity type has at least one dependent entity.

m = CN
Each entity of the source entity type can have any number of dependent entities.

www.applexus.com
Data Modeler

▪ The Data Modeler is a development tool from the ABAP Development Workbench, which you can
use to create data models according to the SAP SERM method (SERM = Structured Entity
Relationship Model).
▪ In addition to supporting modeling functions, the Data Modeler allows you to map the models you
have created to the ABAP Dictionary.
▪ Transaction to create a data modeler : SE11.
• The basic objects of the Data Modeler are data models and entity types, and the relationships and
specializations existing between the entity types

• In the Data Modeler you can create data models with any number of hierarchy levels and in the
process reuse parts of data models.
▪ Modeling involves use of a graphical editor.

www.applexus.com
ABAP Dictionary
Functions • The ABAP Dictionary collects and manages data
definitions.
• It permits a central, non-redundant description of all
the data used in the system.
• All the object definitions in the ABAP Dictionary are
available in the entire R/3 System.
• The ABAP Dictionary describes the logical structure of
the objects of the application development and their
Nunc viverra imperdiet enim. Fusce
representation in structures of the underlying
est. Vivamus a tellus.
relational database.
Pellentesque habitant morbi • It provides a logical view on the application data and
tristique senectus et netus et the organization of this data using the underlying
malesuada fames ac turpis egestas. database system.
Proin pharetra nonummy pede.
• Changes take immediate effect on all the relevant
Mauris et orci.
system components due to the activation mechanism.

www.applexus.com
ABAP DICTIONARY

www.applexus.com
ABAP Dictionary – Type Definitions

• There are three different type categories in the ABAP Dictionary:

✓ Data elements: Describe an elementary type by defining the data type, length and possibly decimal
places.
✓ Structures: Consist of components that can have any type.
✓ Table types: Describe the structure of an internal table.
• Any complex user-defined type can be built from these basic types.
• Example: The data of an employee is stored in a structure EMPLOYEE with the components NAME,
ADDRESS and TELEPHONE. Component NAME is also a structure with components FIRST NAME and
LAST NAME. Both of these components are elementary, i.e. their type is defined by a data element.
The type of component ADDRESS is also defined by a structure whose components are also
structures. Component TELEPHONE is defined by a table type (since an employee can have more
than one telephone number).

www.applexus.com
 ABAP Dictionary – Services
• Input helps (F4 helps) for screen fields can be defined
Slide Style 2 Title with search helps.
• Screen fields can easily be assigned a field help (F1 help)
here by creating documentation for the data element.
• An input check that ensures that the values entered are
consistent can easily be defined for screen fields using
foreign keys.
• The ABAP Dictionary provides support when you set and
release locks. To do so, you must create lock objects in the
ABAP Dictionary. Function modules for setting and
releasing locks are automatically generated from these
lock objects; these can then be linked into the application
program.
• The performance when accessing this data can be
improved for database objects (tables, views) with
buffering settings.
• By logging, you can switch on the automatic recording of
changes to the table entries.

www.applexus.com
ABAP Workbench

www.applexus.com
ABAP Dictionary- SE11

www.applexus.com
Dictionary Objects
• The basic objects for data
modeling in the SAP Data
Dictionary are tables, domains,
data elements and fields and
their relationships (between
tables). These form the active
part of the SAP Data Dictionary
and contain all the field related
metadata of the R/3 System.
• A field is not an independent
object, but is dependent on a
table. A data element
presupposes the existence of a
domain.
• A domain can be defined
without reference to other
Dictionary objects.
Definitions required in • In the table definition, you can assign a data type and
the ABAP Dictionary field length to the field with Direct type entry. In this
case you can enter the short text for the field directly.
• You can assign a data element to the field. The data
type and field length are determined from the
Field name domain of the data element. The short description of
Key flag the data element is assigned to the field as a short
Field type text.
• Search Help can be assigned to a field or table.
Field length
• The structure of the objects of application
Decimal places development are mapped in tables on the underlying
Short text relational database.
• The attributes of these objects correspond to fields of
the table.
• A table consists of columns (fields) and rows (entries).
It has a name and different attributes, such as
delivery class and maintenance authorization.
• A field has a unique name and attributes; for example
it can be a key field.
DOMAIN

• Domains describe the technical attributes of fields ( for example , the data type and the field length).
• Domains also contain details about the value range, stored as a value table or as fixed values.
• Different fields with identical technical attributes are combined in a domain. A domain defines a value
range which describes the valid data values for all the fields which refer to this domain.
• Fields which refer to the same domain (with the assigned data elements), are also changed when the
domain is changed. This ensures that the fields are consistent.
• The value range of a domain can be further restricted by defining fixed values.
• A table can only be the value table of at most one domain. All the fields referring to value range of
this table must therefore use the same domain.

www.applexus.com
DOMAIN
Slide Style 6
Lorem ipsum dolor sit amet
DATA ELEMENT
•Data elements describe the semantic attributes of a
table field ( for example, keywords).
•Field documentation is stored under the relevant data
element, so that you can access the information by
pressing F1 at runtime.
•A data element describes the technical attributes and
meaning of a table field or structure field.
The format specifications for a data element (fixed data
type in the ABAP Dictionary, field length and possibly the
number of decimal places) are copied from the domain
of the data element.
.

www.applexus.com
TABLES

• Tables can be defined independently of the

database in the ABAP Dictionary. The fields
of the table are defined with their
(database-independent) data types and
lengths.
• When the table is activated, a physical table
definition is created in the database for the
table definition stored in the ABAP
Dictionary. The table definition is translated
from the ABAP Dictionary to a definition of
the particular database.

www.applexus.com
Components of table

▪ Components of table definition in ABAP

▪ Table Fields
defines the field names and data types of the fields contained in the table.
▪ Foreign key
defines the relationships between the table and other tables.
▪ Technical settings
control how the table should be created on the database.
▪ Indexes
speed up the selection of data from the table

www.applexus.com
Buffering

www.applexus.com
STRUCTURE

• Structures can be included in tables or other structures to avoid redundant structure definitions.
• A table may only be included as an entire table.
• A chain of includes may only contain one database table. The table in which you are including
belongs to the include chain. This means that you may not include a transparent table in a
transparent table.
• Includes may contain further includes.
• Foreign key definitions are generally imparted from the include to the including table. The attributes
of the foreign key definition are passed from the include to the including table so that the foreign
key depends on the definition in the include.

www.applexus.com
STRUCTURE

www.applexus.com
Foreign Key
Relationship
▪ Define the relationships between
tables in the ABAP Dictionary by
creating foreign keys.
▪ Using foreign keys, you can easily
create value checks for input fields.
Foreign keys can also be used to
link several tables in a view or a
lock object.
• A foreign key links two tables
T1 and T2 by assigning fields of
table T1 to the primary key
fields of table T2.
• Table T1 is called the foreign
key table (dependent table)
and table T2 the check table
(referenced table)..
 ▪
Foreign key 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. If the domains are different, the foreign key
will be inconsistent if for example the field length is
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.
Foreign Key-Cardinality
• 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.
• 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 of the check table, i.e. the key of the
foreign key table only differs from the key of the check table in an additional language key field. This
is a special case of the category Key fields / candidates.

www.applexus.com
 • The Data Class defines the physical area of the database
Technical Settings (tablespace) in which the table should be created.
• Size category: The Size Category defines the size of the
extents required for the table.
Data class • Buffering permission: The Buffering Permission defines
defines the physical area of the database
(tablespace) in which the table should be created
whether the table may be buffered.
• Buffering type: If the table may be buffered, you must
Size category
define a buffering type (full, single-record, generic). The
defines the size of the extents created for the
table Buffering Type defines how many table records are
Buffering permission loaded into the buffer when a table entry is accessed.
defines whether the table may be buffered • Logging: This parameter defines whether changes to the
Buffering type table entries should be logged. If Logging is activated,
defines how many table records are loaded into each change to a table record is recorded in a log table.
the buffer when a table entry is accessed
recorded in a log table (DBTABPRT). To switch on logging,
Logging
the R/3 System must be started with a profile containing
defines whether changes to the table entries
should be logged parameter rec/client. This parameter defines whether all
clients or only selected clients should be logged.
• Logging slows down accesses which change the table!

www.applexus.com
Technical Settings
• Buffering permission: The Buffering
Permission defines whether the table may
▪ Buffering permission be buffered.

▪ Buffering not permitted • Only those tables which are written very
infrequently (read mostly) or for which such
▪ Buffering permitted but not temporary inconsistencies are of no
activated importance may be buffered.
▪ Buffering activated • Tables whose entries change frequently
should not be buffered. Otherwise there
would be a constant invalidation and
reload, which would have a negative effect
on the performance.

www.applexus.com
 • The most important data classes are master data,
transaction data, organizational data and system
data.
Technical Settings • Master data is data that is rarely modified. An example
of master data is the data of an address file, for
example the name, address and telephone number.
• Transaction data is data that is frequently modified. An
example is the material stock of a warehouse, which
can change after each purchase order.
• Organizational data is data that is defined during
Data class customizing when the system is installed and that is
APPL0 rarely modified thereafter. The country keys are an
APPL1 example.
APPL2
• System data is data that the R/3 System itself needs.
The program sources are an example.
• Further data classes, called customer data classes
(USR, USR1), are provided for customers. These should
be used for customer developments. Special storage
areas must be allocated in the database.

www.applexus.com
Technical Settings
• Buffering permission: The Buffering
Permission defines whether the table may
▪ Buffering permission be buffered.

▪ Buffering not permitted • Only those tables which are written very
infrequently (read mostly) or for which such
▪ Buffering permitted but not temporary inconsistencies are of no
activated importance may be buffered.
▪ Buffering activated • Tables whose entries change frequently
should not be buffered. Otherwise there
would be a constant invalidation and
reload, which would have a negative effect
on the performance.

www.applexus.com
Size category • The size category describes the expected storage
requirements for the table on the database.
• An initial extent is reserved when a table is created on
the database. The size of the initial extent is identical
for all size categories. If the table needs more space
for data at a later time, extents are added. These
additional extents have a fixed size that is determined
by the size category specified in the ABAP Dictionary.
• You can choose a size category from 0 to 4. A fixed
extent size, which depends on the database system
used, is assigned to each category.
• Correctly assigning a size category therefore ensures
that you do not create a large number of small
extents. It also prevents storage space from being
wasted when creating extents that are too large.
Delivery Class
▪ Delivery Class defines how database table is going to be transported during installation, upgrade,
and copies within landscapes, clients and customer systems.
Types and use of Delivery Class:
A: Application table for master data and transaction data. Data is maintain by application. These tables
are delivered to customer as empty tables.
C: Customer table used for customize application. Data is maintained by customer.
L: Table used as a repository to store temporary data. These tables are delivered to customer as empty
tables.
G: Customer table where SAP can add data but not modify or delete it.
E: System table in which customers can make entries. System tables are delivered with some data (not
empty).
S: System table delivered by SAP with predefined data as part of system.
W:System table for system administration data. A system table in the delivery class W usually delivered
with predefined data by SAP and can be affected by customer modifications.

www.applexus.com
Creating Tables

▪ Path : Tools -> ABAP Work bench -> Dictionary -> Table -> Table name -> Create
▪ Steps
▪ Creating fields in the table
▪ Maintaining the Technical settings
▪ Creating foreign keys (Optional)
▪ Creating secondary Indexes(optional)
▪ Activating Tables

www.applexus.com
Points to Remember

▪ Table name ‘Z____’ (16 char)

▪ Structure name ‘Z____’ (32 char)
▪ Data Element ‘Z____’ (32 char)
▪ Domain ‘Z____’ (32 char)
▪ Same name cannot be used for Table, Structure and Data element
▪ UNDESCORE not allowed in 2nd and 3rd place for Tables/Structures
▪ All Key Fields to be grouped together at the start without intermediate non-key fields
▪ Maximum of 16 key fields per table allowed
▪ Use MANDT ( type CLNT) as first field for Client dependant tables
▪ Specify the Reference table and field for QUAN & CURR type fields
▪ Save and activate the Domains and Data elements before activating the Table
www.applexus.com
Data Types in ABAP Dictionary

▪ ACCP: Posting period. The length is set to 6 places for this data type. The format is YYYYMM. In input
and output, a point is inserted between the year and month, so the template of this data type has
the form ‘____.__’.
▪ CHAR: Character string. Fields of type CHAR may have a maximum length of only 255 in tables. If
longer character fields are to be used in tables, data type LCHR must be selected. In structures there
are no restrictions on the length of such fields.
▪ CLNT: Client. Client fields always have three places.
▪ CUKY: Currency key. Fields of this type are referenced by fields of type CURR. The length is set to 5
places for this data type.
▪ CURR: Currency field. Equivalent to a DEC amount field. A field of this type must refer to a field of
type CUKY (reference field). The maximum length for this data type is 17 places.
▪ DATS: Date. The length is set to 8 places for this data type. The output template can be determined
with the user profile.
▪ DEC: Counter or amount field with decimal point, sign, and commas separating thousands. A DEC
field has a maximum length of 31 places. In tables, only DEC fields with a length <= 17 may be used.
▪ .
www.applexus.com
Data Types in ABAP Dictionary

▪ FLTP: Floating-point number. The length (including decimal places) is set to 16 places for this data
type.
▪ INT1: 1-byte integer between 0 and 255. The length of this data type is set to 3 places.
▪ INT2: 2-byte integer between -32767 and 32767. Fields of this type should only be used for length
fields. These long fields are positioned immediately in front of a long field (type LCHR, LRAW). With
INSERT or UPDATE on the long field, the database interface enters the length which was actually
used in the length field. The length for this data type is set to 5 places.
▪ INT4: 4-byte integer between -2177483647 and 2177483647. The length is set to 10
places for this data type

www.applexus.com
Data Types

▪ LANG: Language key. Has its own field format for special functions. This data type always
has a length of 1.
▪ LCHR: Character string of arbitrary length, but with a minimum of 256 characters. Fields of this type
must be located at the end of transparent tables and must be preceded by a length field of type
INT2. If there is an INSERT or UPDATE in ABAP programs, this length field must be filled with the
length actually required.
▪ LRAW: Uninterpreted byte string of arbitrary length, but with a minimum length of 256. Fields of this
type must be located at the end of transparent tables and must be preceded by a length field of type
INT2. If there is an INSERT or UPDATE in ABAP programs, this length field must be filled with the
length actually required.
▪ NUMC: Long character field in which only numbers can be entered. The length of this field is limited
to a maximum of 255 places.
▪ PREC: Accuracy of a QUAN field. The length for this data type is set to 2 places.
▪ QUAN: Quantity. Equivalent to an amount field DEC. A field of this type must always refer to a units
field with UNIT format (reference field). The maximum length for this data type is 17 places.

www.applexus.com
Data Types

▪ RAW: Uninterpreted sequence of bytes. Fields of type RAW may have only a maximum length of 255
in tables. If longer raw fields are required in tables, you should select data type LRAW.
▪ TIMS: Time. The length for this data type is set to 6 places. The format is hhmmss. The template for
input and output has the form ‘__.__.__’.
▪ UNIT: Units key. Fields of this type are referenced by fields of type QUAN. The length of this data
type is set to 2 or 3 places.
▪ VARC: Character field of variable length. Creation of new fields of this data type is not supported as
of Release 3.0. However, existing fields with this data type can still be used.
▪ When using the numeric data types CURR, DEC, FLPT, INT2, INT4 and QUAN, you can choose whether
or not a sign should be output on screens.
▪ With the data types CURR, DEC & QUAN, commas separating thousands & decimal points are set by
the system. The output length (no. of places + the no. of necessary editing characters such as
commas separating thousands & decimal points) is therefore greater than the chosen length.
▪ The system omits editing characters if the output length specified in the domain maintenance is too
small.

www.applexus.com
Type categories in ▪ User-defined data types for programs can be
Data Dictionary stored in the ABAP Dictionary.
• Data Elements
• elementary types and reference types.

• Structures
• structured types: consists of
components that also have a type.

• Table types
• describes the structure and functional
attributes of an internal table.
Structure

A structure comprises of components (fields)

• Types are defined for the components

▪ A component can refer to an elementary type (via a data element or by directly
specifying the data type and length in the structure definition),
▪ Another structure
▪ Table type

www.applexus.com
Table types

• A table type describes the structure and functional attributes of an internal

table in ABAP

• In ABAP programs you can reference a table type TTYP defined in the ABAP
Dictionary with the command DATA <inttab> TYPE TTYP

• An internal table <inttab> is created in the program with the attributes defined
for TTYP in the ABAP Dictionary.

www.applexus.com
Table Type

▪ A table type is defined by:

▪ Its line type, that defines the structure and data type attributes of a line of the
internal table

▪ The options for managing and accessing the data ( access mode) in the internal table

▪ The key ( key definition and key category) of the internal table

www.applexus.com
Data Types

Possible ABAP data types:

▪ C: Character
▪ D: Date, format YYYYMMDD
▪ F: Floating-point number in DOUBLE PRECISION (8 bytes)
▪ I: Integer
▪ N: Numerical character string of arbitrary length
▪ P: Amount or counter field (packed; implementation depends on hardware platform)
▪ S: Time stamp YYYYMMDDHHMMSS
▪ T: Time of day HHMMSS
▪ V: Character string of variable length, length is given in the first two bytes
▪ X: Hexadecimal (binary) storage
▪ The characters used in the table have the following significance:
▪ n: number of places of the field in the ABAP Dictionary
▪ m: number of decimal places of the field in the ABAP Dictionary

www.applexus.com
VIEWS

• Data for an application object is often

distributed on several database tables.
Database systems therefore provide you
with a way of defining application-specific
views on data in several tables. These are
called views.
• Data from several tables can be combined
in a meaningful way using a view (join). You
can also hide information that is of no
interest to you (projection) or only display
those data records that satisfy certain
conditions (selection).
• The data of a view can be displayed exactly
like the data of a table in the extended
table maintenance.

www.applexus.com
 ▪ The ability of views to hide data serves both to simplify
usage of the system and to enhance security. System
VIEWS usage is simplified because the user is allowed to
restrict attention to the data of interest.
▪ The simplest form of deriving data is to mask out one
or more fields from a base table (projection) or to
include only certain entries of a base table in the view
(selection).

Simplify usage of the system ▪ More complicated views can comprise several base
tables, the individual tables being linked with a
Enhance security. relational join operation.

www.applexus.com
Views in DB

• A database view is defined in the ABAP Dictionary and automatically created on the database during
activation. Accesses to a database view are passed directly to the database from the database
interface. The database software performs the data selection.
• If the definition of a database view is changed in the ABAP Dictionary, the view created on the
database must be adjusted to this change. Since a view does not contain any data, this adjustment is
made by deleting the old view definition and creating the view again in the ABAP Dictionary with its
new definition.
• The maintenance status defines whether you can only read with the view or whether you can also
write with it. If a database view was defined with more than one table, this view must be read only.
• The data read with a database view can be buffered. View data is buffered analogously to tables. The
technical settings of a database view control whether the view data may be buffered and how this
should be done. The same settings (buffering types) can be used here as for table buffering. The
buffered view data is invalidated when the data in one of the base tables of the view changes.
• Database Views implement an Inner Join.

www.applexus.com
View definition

1. Select the base tables of the view.

2. Link the tables by defining the join conditions.

3. Select the fields of the base tables to be used in the view.

4. Formulate selection conditions which restrict the records in the view.

www.applexus.com
Different type of Views

▪ 4 types of views
▪ Database views
▪ Projection views
▪ Help views
▪ Maintenance views

www.applexus.com
Projection View
▪ Projection views are used to
suppress or mask certain fields
in a table (projection), thus
minimizing the number of
interfaces. This means that only
the data that is actually
required is exchanged when
the database is accessed.

▪ A projection view can draw

upon only one table.

▪ Selection conditions cannot be

specified for projection views.
Help View
▪ Help views can be used as a
selection method in search
helps.

▪ Help views are used to output

additional information when
the online help system is called.

▪ All the tables used in a help

view must be linked with
foreign keys

▪ A help view implements an

outer join.
Maintenance View
▪ Data that is distributed on
more than one table often
forms a logical unit, called an
application object. You should
be able to display, change and
create the data of such an
application object together.
Users usually are not interested
in the technical
implementation of the
application object, such as the
distribution of the data on
several tables.
Maintenance View

• All the tables used in a maintenance view must be linked with a foreign key. This means that the join
conditions are always derived from the foreign key in the maintenance view. You cannot enter the
join conditions directly as in a database view.
• A maintenance interface with which the data of the view can be displayed, changed and created
must be generated from the definition of a maintenance view in the ABAP Dictionary.
• When the maintenance interface is created, function modules that distribute the data maintained
with the view on the underlying tables are automatically generated.
• The maintenance interface is generated with the Transaction Generate Table View (Transaction SE54)
or from the view maintenance screen with Environment -> Tab.maint.generator.
• A Maintenance view implements Outer Join.

www.applexus.com
SEARCH HELP

• The input help (F4 help) is a standard function of the R/3 System. It permits the user to display a list
of possible values for a screen field. A value can be directly copied to an input field by list selection.
• Search Help is a data dictionary object which is used to create a popup window that contains all the
data related to your search. It is an input Help that permits the user to display a list of possible
values for a screen field.If the number of possible entries for a field is very large, you can limit the set
of displayed values by entering further restrictions.
• The display of the possible entries is enhanced with further useful information about the displayed
values. This feature is especially useful if the field requires the entry of a formal key.
• Since the input help is a standard function, it should look and behave the same throughout the
entire R/3 System. The development environment therefore provides tools for assigning a
standardized input help to a screen field.
• The precise description of the input help for a field is usually defined by its semantics. For this
reason, the input help for a field is normally defined in the ABAP Dictionary.

www.applexus.com
Search Help
▪ Information (about the context) known to
the system must be taken into
consideration in the input help. This
includes entries the user already made in
the current input template as well as
information obtained in previous dialog
steps. Normally the input help uses the
context to limit the set of possible values
▪ The input help must determine the values
that can be offered to the user for
selection.
▪ The input help must hold a dialog with the
user. This dialog always contains the
presentation of the possible values (with
supplementary information) in list form and
the possibility to select a value from this
list.
www.applexus.com
 • A collective search help combines several elementary
search helps. The user can thus choose one of several
Types of Search alternative search paths with a collective search help.
Help
• Like an elementary search help, a collective search
help has an interface of import and export parameters.
The data is exchanged between the screen template
and the parameters of the assigned elementary search
helps using this interface
Elementary search helps

Collective search helps

Append search helps

www.applexus.com
Collective Search Help

• Like an elementary search help, a collective search help has an interface of IMPORT and EXPORT
parameters with which it exchanges data. Using this interface, the collective search help can be
attached to fields, tables and data elements exactly like an elementary search help.
Only one search help can be attached to a field, table or data element. Several search paths are
therefore attached with a collective search help.
• You can omit the components for describing the dialog behavior and data selection when you define
a collective search help. The included search helps are listed here. You must assign the parameters of
the collective search help to the interface parameters of the included search help for each inclusion.
• A search help can also be included in several collective search helps and at the same time itself be
attached to fields, tables and data elements. A collective search help can also be included in another
collective search help.
• When you use a collective search help, you are offered the elementary search helps contained in the
collective search help as parallel tab pages. If you repeatedly use a collective search help, the tab
page that was last used is automatically active. This is because most users always use the same
search path.

www.applexus.com
Append Search Help

▪ Append search helps can be used to enhance collective search helps delivered by SAP with
customer-specific search paths without requiring a modification.

▪ The structure of an append search help corresponds to that of a collective search help, but the
append search help takes on the parameters of its appending object so that it cannot be maintained
separately any longer

www.applexus.com
Table maintenance Generator
▪ SAP Table Maintenance Generator (TMG) is a tool to generate a table maintenance program i.e. it
will generate a program to maintain (Create, Edit & Delete) entries in a table.
▪ To generate a table maintenance generator (TMG) for a table, display the table in ABAP Dictionary
(SE11).
▪ Another important thing is when ever you change yourr table structure(Include/delete fields) don't
forget to delete and recreate the table maintenance. Because the structure of the table was
changed. If u try access Table maintenance generator(SM30) after changing the structure then it will
through u a dump.
Transaction code to create entries using TMG is SM30.
One step, two step in Table Maintenance Generator
▪ Single step: Only overview screen is created i.e. the Table Maintenance Program will have only one
screen where you can add, delete or edit records.
▪ Two step: Two screens namely the overview screen and Single screen are created. The user can see
the key fields in the first screen and can further go on to edit further details.

www.applexus.com
TMG contd…

www.applexus.com
A little progress each day adds upto big results.
Thank You
Ganga S

[email protected]
Questions?