Hi Bjorn,
I understand your question as: if a table exists in the SAP dictionary with a given name and structure, what does that table look like in the database?
In the SAP dictionary there are three types of database tables:
- transparent table
- pooled table
- clustered table
For a transparent table there is an exact 1:1 relation between dictionary and database. If a table exists in the SAP dictionary with name "TABXYZ" and fields "MANDT", "COL1" and "COL2", then you will also find a database table named TABXYZ with fields MANDT, COL1 and COL2. The data type of a field in the dictionary is mapped to a data type of the underlying database system, e.g. with Oracle a field with type CHAR(n) in the dictionary becomes VARCHAR2(n) in the database.
A pooled table does not exist as a separate database table. Instead, groups of pooled tables are stored together inside a physical pool. At the database level there is only one table (namely the physical pool). This table has a field called TABNAME, which contains the name of the "logical" (i.e. pooled table) that each specific row belongs to. You can see this in the SAP dictionary: in SE12, enter "ATAB" as the table name and look at the structure. ATAB is the most important physical pool in the SAP database; in ECC 6 systems ATAB contains over 1800 pooled tables. The actual columns of a pooled table are not visible at database level: they are grouped together in the phsyical pool columns VARKEY (for the primary key fields) and VARDATA (non-key fields); both columns are of raw (binary) type. The database interface of the SAP kernel takes care of converting between these binary containers and the logical field names as defined in the dictionary.
Like pooled tables, clustered tables do not exist as separate database tables; they are part of a physical cluster. At the database level only the physical cluster exists as a table. Whereas with pooled tables, one row of the pool belongs uniquely to one logical table, one row of a physical cluster contains data of several clustered tables. The idea is that data of a "master" table is kept physically together with data of "subordinate" tables that share a cmmon primary key. This is beneficial for performance. Because the combination of the "header" row with its subordinate records may exceed the maximum size of a physical row in the cluster, the rows for a common key have a sequence number. You can for example look in SE12 at the cluster RFBLG (a cluster containing accounting tables). The first four fields of RFBLG (MANDT, BUKRS, BELNR, GJAHR) define the common part of the primary key of the master and subordinate tables. PAGENO is the sequence number. TIMESTMP is an internal timestamp, PAGELG the length of the page (binary data) and VARDATA holds the actual data in binary form. PAGENO, TIMESTMP, PAGELG and VARDATA exist in all clusters; the fields coming before this (common key fields) are specific to each cluster.
Transparent tables form the overwhelming majority. In the ECC 6 system I have here, there are 69984 transparent tables, 2019 pooled tables and just 77 clustered tables. That does not mean that they are unmiportant: pooled tables are often small but critical (mostly customizing) tables; and some of the most critical tables in the system are clustered, e.g. the core accounting table (BSEG, clustered inside RFBLG) or the change document tables CDPOS and PCDPOS (in physical cluster CDCLS).
I hope this clarifies things (at least if I got your question right).
Regards,
Mark
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.