Chapter 04_ABAP Dictionary Tables in Relational Databases
-
Upload
phani
-
View
10
-
Download
3
Embed Size (px)
DESCRIPTION
abap
Citation preview
ABAP Dictionary Tables in Relational DatabasesIBM Global
Services
© 2005 IBM Corporation
The participants will be able to:
Describe the different types of tables in the SAP ABAP
Dictionary.
Explain the technical settings for optimizing the storage and
maintenance requirements.
Describe performance benefits through indexing.
ABAP Dictionary Tables in Relational Databases |
IBM Global Services
© 2005 IBM Corporation
SAP Table Types
ABAP Dictionary Tables in Relational Databases |
There are 3 different table types in the SAP ABAP Dictionary:
Transparent tables
2. Pool tables
3. Cluster tables
Data in the SAP R/3 system is stored in a relational database
management system (RDBMS). All tables in the SAP R/3 system are
created using the ABAP Dictionary and are stored in the relational
database.
The ABAP Dictionary is SAP’s tool for developers to maintain any
type of table that exist in the physical database.
IBM Global Services
© 2005 IBM Corporation
Transparent Tables
Master Data
SAP stores both master data and transaction data in transparent
tables.
Transactional Data
ABAP Dictionary Tables in Relational Databases |
SAP uses the term master data to refer to control tables and the
traditional files that are necessary to run a business such as
personnel files, general ledger accounts, customer files, etc.
There is a 1:1 correlation between the master data tables in the
Dictionary and the tables in the physical database. For each master
data table in the Dictionary, the same master data table exists in
the physical database.
Commercial data or transaction data is another SAP term used to
refer to data created as a result of performing SAP business
transactions such as creating: invoices, orders, production
schedules, purchase requisitions, stock transfers, etc.
SAP stores both master data and transaction data in transparent
tables (TRANSP).
IBM Global Services
© 2005 IBM Corporation
PROFILE
Transparent (TRANSP) tables have a 1:1 correlation between the
ABAP
Dictionary and the physical database.
DB
ABAP Dictionary Tables in Relational Databases |
Transparent (TRANSP) tables have a 1:1 correlation between the ABAP
Dictionary and the physical database. For each TRANSP table in the
Dictionary, the same table name exists in the physical
database.
Since TRANSP tables exist in the physical database, you can use
either Open SQL or Native SQL to access them.
Transparent tables are created automatically in the database after
you specify the table’s technical settings and activate the table
using the Database Utility. The Database Utility gets invoked
automatically when you activate the table by clicking the
icon.
IBM Global Services
© 2005 IBM Corporation
Pool Table
Cluster Table
Pooled tables can be used to store control data (e.g. screen
sequences,
program parameters or temporary data).
Cluster tables may contain continuous text (e.g.
documentation).
ABAP Dictionary Tables in Relational Databases |
Pooled tables can be used to store control data (e.g. screen
sequences, program parameters or temporary data). Several pooled
tables can be combined to form a table pool. The table pool
corresponds to a physical table in the database in which all the
records of the allocated pooled tables are stored.
Cluster tables may contain continuous text, for example,
documentation. Several cluster tables can be combined to form a
table cluster. Several logical lines of different tables are
combined to form a physical record in this table type. This permits
object-by-object storage or object-by-object access. In order to
combine tables in clusters, at least parts of the primary keys must
agree. Several cluster tables are stored in one corresponding table
on the database.
We will not be working with these two type of tables in the
exercises for this course.
126.unknown
127.unknown
Data class
DB storage
On or off
ABAP Dictionary Tables in Relational Databases |
Technical settings allow you to optimize the storage requirements
and table access behavior of database tables.
The Technical Settings screen appears when you click the icon on
the ABAP Table Maintenance screen.
Data class - Designates the table to an area in the physical
database where similar tables are grouped (in ORACLEä and INFORMIXä
only).
Size Category - Identifies the amount of disk space that will be
required to hold the data records for a table in the database (in
ORACLEä and INFORMIXä only).
Buffering - Determines whether table records will be accessed
directly from the database server or from global memory.
Logging - Creates before and after images of changes to the table
of contents. Logging must be activated by the profile when the
system is started.
IBM Global Services
© 2005 IBM Corporation
ABAP Dictionary Tables in Relational Databases |
Tables in the ABAP Dictionary must be assigned to one of the
following classes of data:
Master Data: Large amounts of data which do not change often. It is
often read, but
rarely updated. An example of master data is the data contained in
an address file,
such as the name, address and telephone number. (APPL0)
Transaction Data: Data with temporary lifecycle, not stored long.
Frequently
updated. An example of transaction data is the goods in a
warehouse, which change
after each purchase order. (APPL1)
Organization and Customizing Data: Specified when the
system is configured and
then not often changed. An example is the table with country codes.
(APPL2)
Two further data classes, USER and USER1, are provided for the
customer. These are used to define user developments.
Defining a data class has the effect of storing the table in a
defined area of the database when the table is created.
IBM Global Services
© 2005 IBM Corporation
Size Categories
A table’s size category identifies the amount of disk space on the
database that
is allocated to the table.
ABAP Dictionary Tables in Relational Databases |
A table’s size category identifies the amount of disk space on the
database that is allocated to the table.
This amount is translated to a number of data records if you hit F4
for help, depending on the underlying database.
If the number of records in a table exceeds the original size
category, then more space will automatically be allocated in the
database. The storage space will be incremented by the amount of
the original size category.
IBM Global Services
© 2005 IBM Corporation
Single Record
ABAP Dictionary Tables in Relational Databases |
Buffering is only recommended for tables with data that typically
does not change or get updated.
Buffering types:
Single record: Only a single record actually being processed is
moved into the buffer. This type of buffering preserves buffer
space but requires more database hits in order to load the table.
Recommended for large tables when only a few records need to be
accessed.
Generic: A subset of the table records are loaded based on part of
the primary key. Recommended if only certain “generic” areas of the
table will be needed.
Full: Results in either all of the table or none of it being loaded
into the buffer. Recommended for a) tables up to 30 K in size, b)
larger tables where access is needed to many records, and c) tables
against which attempts to access data will frequently yield a “no
record found” result.
IBM Global Services
© 2005 IBM Corporation
Logging
On the technical settings screen you can specify “Log data changes”
to
automatically generate a log file of details on the structure of a
table, a list of the
data changes made during a certain period, and statistics.
ABAP Dictionary Tables in Relational Databases |
On the technical settings screen you can specify “Log data changes”
to automatically generate a log file of details on the structure of
a table, a list of the data changes made during a certain period,
and statistics.
In addition to clicking the checkbox “Log data changes” on the
technical settings screen, you must ensure that the System
Administrator has also specified the switch or entry to allow
“Table Logging On”.
Log files do not rely on successful database updates to be
completed before they are written.
The existing logs can be displayed with Transaction code
SCU3.
IBM Global Services
© 2005 IBM Corporation
Maintaining Technical Settings
ABAP Dictionary Tables in Relational Databases |
Activating tables causes the Technical Settings screen to display.
Choose an appropriate data class and size category. Use the F4 help
to list the possible entries.
The Buffering and Logging settings can also be set on this
screen.
When the settings are saved, SAP automatically runs the Database
Utility.
A table’s Technical Settings can be changed at any time.
For successful activation of tables, we need to specify the
enhancement category using the menu path Extras Enhancement
Category in ECC 6.0.
IBM Global Services
© 2005 IBM Corporation
Demonstration
Observation of the technical settings of the SAP Table MARA and
familiarization with the technical settings of a transparent
table.
ABAP Dictionary Tables in Relational Databases |
IBM Global Services
© 2005 IBM Corporation
Practice
Observation of the technical settings of the SAP Table MARA and
familiarization with the technical settings of a transparent
table.
ABAP Dictionary Tables in Relational Databases |
IBM Global Services
© 2005 IBM Corporation
DB
The Database (DB) Utility is a tool used in SAP to serve as a
interface
between the database management software (i.e., ORACLE,
INFORMIX,
DB2, INGRES, etc.) and the ABAP Dictionary
ABAP Dictionary Tables in Relational Databases |
The Database (DB) Utility is a tool used in SAP to serve as a
interface between the database management software (i.e., ORACLE,
INFORMIX, DB2, INGRES, etc.) and the ABAP Dictionary. It is used
to:
Convert data (i.e., change field lengths and data types,
etc.)
Activate objects in the ABAP Dictionary
Create tables and indices
Perform all standard table operations in the database that were
entered in the ABAP
Dictionary
The DB Utility automatically writes the SQL commands necessary to
create, change and delete tables and indexes in the physical
database, and records the tables in the ABAP Dictionary.
As the DB Utility is operating, a log file gets created which
contains information on whether or not the conversion was
successful and the point of failure during the conversion if it was
not successful.
The DB Utility can be run either online or in the background.
You can also manually run the DB Utility from any ABAP Dictionary
screen under the UTILITIES Database Object Database Utility menu or
transaction SE14.
IBM Global Services
© 2005 IBM Corporation
Index
To improve performance, SAP automatically creates a primary index
(id 0) for
transparent tables based on the primary key. You can also define
your own
secondary indexes for transparent tables.
ABAP Dictionary Tables in Relational Databases |
To improve performance, SAP automatically creates a primary index
(id 0) for transparent tables based on the primary key. You can
also define your own secondary indexes for transparent
tables.
Indexes accelerate the reading of tables when the system looks for
records satisfying specific search criteria. The system determines
the most efficient index by which to select data for the specific
request.
An index serves as a sorted copy of the table reduced to specific
fields, with a pointer to the remaining fields.
Database indexes are defined in ABAP Dictionary and stored in the
physical database.
From the ABAP table maintenance screen use the menu path GoTo
Indexes.
A pop-up window appears. In pop up window press the create button
and select the entry ‘Create Index’ from the dropdown. Assign a
3-character id to your index.
Provide a short text and select the field(s) by which the table
needs to be indexed.
Sometimes the presence of an index causes a performance problem.
You can indicate the optionality of the index with different
databases. Secondary index is used for the tables which are not
frequently changed (Eg: Master tables)
Creating an index on an SAP table requires a repair, but it will
not get overwritten with an upgrade.
IBM Global Services
© 2005 IBM Corporation
ABAP Dictionary Tables in Relational Databases |
In the cases where database accesses are necessary and appropriate,
it is imperative to perform those accesses as efficiently as
possible. The single most important method of optimizing a database
access is by using an index.
An index is a set of fields from a table that is sorted and then
stored in a location separate from the table itself. Each record in
the index contains a pointer to matching record(s) in the actual
database table.
IBM Global Services
© 2005 IBM Corporation
ABAP Dictionary Tables in Relational Databases |
This analogy is probably as old as computer science itself, but it
still works well. Think of an index like a telephone book.
If you want to find someone’s phone number, the first thing you
might do is decide where you want to look for that number. One
thing you probably won’t do is start calling all possible telephone
number combinations until you hit upon the right one! You might ask
a friend, or call directory assistance, or look up the information
in a phone book.
Let’s suppose you decide to use a phone book. The next thing you do
is to begin searching for that person’s name in the book. Once you
find the name, you then look across from the name to find the
number.
A DBMS goes through a similar process when performing a query. It
first must decide how it is going to look for the information that
has been requested, just as you did when looking for a telephone
number. One option is to look at each record in the table, one at a
time, until all the matching records have been found. This would be
analogous to trying all possible combinations of telephone numbers
until you found the right one.
As ridiculous as that sounds, sometimes DBMS’s have to do just
that. This is called performing a full table scan.
605.unknown
ABAP Dictionary Tables in Relational Databases |
Another option the DBMS has is to perform an index scan. In this
case, the DBMS looks in a separate file, searching for the
information by a particular key field (or fields). This is like
using the phone book, searching for the correct name.
Once the matching record(s) have been found in the index, the DBMS
follows a pointer from the index to retrieve the actual record in
the table. This pointer consists of a disk address that tells the
system exactly where to find the desired record(s). In our
telephone book example, the analogous process is pretty simple: you
simply look across the line from the name to the telephone
number.
994.unknown
The Index Range Scan
Sometimes an index doesn’t point to a single record, so it has to
go for the
Index Range Scan
ABAP Dictionary Tables in Relational Databases |
This process is analogous to an index range scan that might be
performed by a DBMS. Sometimes an index doesn’t point to a single
record. If you have an index of customers by their last names, this
will probably be the case - you will probably have many customers
with the same last name.
In this case, once the database finds matching record(s) in the
index, its job isn’t over. It now must retrieve all the records
that matched the selected index records, and examine each one to
see if they meet the final selection criteria for the query.
607.unknown
The Unique Index Scan
If each index record matches exactly one record in the table, and
if all the fields
of the index are specified in the query, a unique index scan can be
performed.
ABAP Dictionary Tables in Relational Databases |
In contrast, if each index record matches exactly one record in the
table, and if all the fields of the index are specified in the
query, a unique index scan can be performed. Queries based on a
table’s full primary key always fulfil this criterion - such as by
client (implicit if using Open SQL) and customer number in table
KNA1.
In this case, once the DBMS finds the matching record in the index,
its work is almost done. All it must do is follow the pointer from
the index to the solitary table record that it knows will satisfy
the query.
IBM Global Services
© 2005 IBM Corporation
Unique Index Scan
Index Range Scan
Full Table Scan
A unique index scan is generally faster than an index range scan,
because it has
less data to sort through and retrieve.
ABAP Dictionary Tables in Relational Databases |
In general, indexed reads are much quicker than normal table reads,
and some types of indexed reads are quicker than others. A unique
index scan is generally faster than an index range scan, because it
has less data to sort through and retrieve.
The smaller the amount of data being processed by a query, the
faster it will run.
Here are some guidelines:
Use indexed reads over full table scans.
Use unique index scans when possible.
609.unknown
Summary
There are 3 different table types in the SAP ABAP Dictionary:
Transparent tables, Pool tables & Cluster tables
Technical settings allow you to optimize the storage requirements
and table access behavior of database tables.
Defining a data class has the effect of storing the table in a
defined area of the database when the table is created.
A table’s size category identifies the amount of disk space on the
database that is allocated to the table.
Buffering is only recommended for tables with data that typically
does not change or get updated.
To improve performance, SAP automatically creates a primary index
(id 0) for transparent tables based on the primary key. You can
also define your own secondary indexes for transparent
tables.
ABAP Dictionary Tables in Relational Databases |
IBM Global Services
© 2005 IBM Corporation
What is data class ?
What is size category ?