Procedure for creating transparent table, data element and domain

Question

Hi,
Can anybody let me know the procedure for creating transparent table, data element and domain.
Thanks,
Mahathi

Answer 1

Hi
Database table and its components
A database table is the central data structure of the ABAP/4 data dictionary.
The structure of the objects of application development are mapped in tables on the underlying 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.
A table has one or more key fields, called the primary key.
The values of these key fields uniquely identify a table entry.
You must specify a reference table for fields containing a currency (data type CURR) or quantity (data type QUAN). It must contain a field (reference field) with the format for currency keys (data type CUKY) or the format for units (data type UNIT). The field is only assigned to the reference field at program runtime.
The basic objects for defining data in the ABAP Dictionary are tables, data elements and domains. The domain is used for the technical definition of a table field (for example field type and length) and the data element is used for the semantic definition (for example short description).
A domain describes the value range of a field. It is defined by its data type and length. The value range can be limited by specifying fixed values.
A data element describes the meaning of a domain in a certain business context. It contains primarily the field help (F1 documentation) and the field labels in the screen.
A field is not an independent object. It is table-dependent and can only be maintained within a table.
You can enter the data type and number of places directly for a field. No data element is required in this case. Instead the data type and number of places is defined by specifying a direct type.
The data type attributes of a data element can also be defined by specifying a built-in type, where the data type and number of places is entered directly.
<b>Two Level Domain Example</b>
A domain defines a field technically and therefore it may
be used at different business levels.
A data element describes the meaning of a domain in a certain business context.
A domain, however, is used for the technical definition of a table field (for example field type and length).
Therefore, although a take-off airport (data element S_FROMAIRP) would have a different business meaning from an airport where a plane lands (data element S_TOAIRP), they could still have the same domain(here S_AIRPID) because technically we could assign the same number of characters whether the airport is a take-off or a landing airport.
<b>Definitions of Table in Database</b>
In SAP R/3 tables are defined as
A) Transparent tables: All of the fields of a dictionary table correspond to a field in the real database table.
B) Pooled tables: Different tables which are not linked to each other with a common key are combined into a TABLE POOL. Several logical tables thus exist as a single real database table.
C) Cluster tables: Several tables linked by a common key may sometimes be combined by the data dictionary and made to exist on the database schema as a single table.
SAP is evolving R/3 tables in transparent tables.
<b>Elaboration on each of the definitions</b>
A transparent table is automatically created on the database when it is activated in the ABAP Dictionary. At this time the database-independent description of the table in the ABAP Dictionary is translated into the language of the database system used.
The database table has the same name as the table in the ABAP Dictionary. The fields also have the same name in both the database and the ABAP Dictionary. The data types in the ABAP Dictionary are converted to the corresponding data types of the database system.
The order of the fields in the ABAP Dictionary can differ from the order of the fields on the database. This permits you to insert new fields without having to convert the table. When a new field is added, the adjustment is made by changing the database catalog (ALTER TABLE). The new field is added to the database table, whatever the position of the new field in the ABAP Dictionary.
Tables can also reside on the database as Pooled tables or cluster tables
Pooled Tables: Different tables which are not linked to each other with a common key can be combined into a Table Pool. The tables contained within this pool are called Pooled Tables. A table pool is stored in the database a simple table. The table's data sets contain, in separate fields, the actual key for the data set to be stored, the name of the pooled table and the contents of the data set to be stored.
Using this schema, several logical tables are combined into a single real database table. Although the data structure of each set is lost during the write to the table pool, it is restored during the read by the ABAP/4 Data Dictionary. The ABAP/4 Data Dictionary utilizes its meta-data to accomplish this.
Since information must be prepared (defined) within the ABAP/4 Data Dictionary when it is read or written to (or accessed), this process itself defines these as not transparent tables
Cluster Tables: Occasionally, several tables may be linked by a common key. The ABAP/4 Data Dictionary can also combine these tables into a single table. Each data set of the real table within the database contains a key and in a single data field, several data sets of the subsequent table for this key.
As mentioned above, these table types require special data handling, therefore they are not transparent tables.
<b>Technical Settings in Dictionary</b>
The data class logically defines the physical area of the database (for ORACLE the table space) in which your table should be created. If you choose the data class correctly, the table will automatically be created in the appropriate area on the database when it is activated in the ABAP Dictionary.
The most important data classes are master data, transaction data, organizational data and system data.
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 customizing when the system is installed and that is rarely modified thereafter. The country keys are an example.
System data is data that the R/3 System itself needs. The program sources are an example.
Further data classes, called customer data classes (USER, USER1), are provided for customers. These should be used for customer developments. Special storage areas must be allocated in the database.
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.
Modifications to the entries of a table can be recorded and stored using logging.
To activate logging, the corresponding field must be selected in the technical settings. Logging, however, only will take place if the R/3 System was started with a profile containing parameter 'rec/client'. Only selecting the flag in the ABAP Dictionary is not sufficient to trigger logging.
Parameter 'rec/client' can have the following settings:
rec/client = ALL All clients should be logged.
rec/client = 000[...] Only the specified clients should be logged.
rec/client = OFF Logging is not enabled on this system.
The data modifications are logged independently of the update. The logs can be displayed with the Transaction Table History (SCU3).
Logging creates a 'bottleneck' in the system:
Additional write access for each modification to tables being logged.
This can result in lock situations although the users are accessing different application tables!
<b>Create transparent table</b>
Go to transaction SE11. Enter name of table you want to create (beginning with Y or Z) and click on create pushbutton
Enter the delivery class and the table maintenance criteria
The delivery class controls the transport of table data when installing or upgrading, in a client copy and when transporting between customer systems .
The display/maintenance indicator specifies whether it is possible to display/maintain a table/view using the maintenance tools Data Browser (transaction SE16) and table view maintenance (transactions SM30 and SM31).
Enter the name of the table field and the data element. The
System automatically populates the technical details for
existing data elements.
So far as possible it is advisable to use existing data elements which befit the business requirements.
However, we may create data elements if need be. The same is shown in the next slide.
To create a data element simply double click on it.
Alternately create a data element by simply choosing the
data type radio button on SE11 initial screen.
<b>Create data element</b>
The system prompts you to create a new data element.
Choose the Yes pushbutton.
Under the data type tab enter the domain name which
determines the technical characteristics of the field.
Further characteristics tab: Allows you to specify a search help assigned to the data element.
It also allows you to specify a parameter id which helps you populate a field from SAP memory.
Field label: Can be assigned as prefixed text to a screen field referring to the ABAP Dictionary. The text is displayed on the screen in the logon language of the user (if the text was translated into this language).
<b>Create domain</b>
If the domain does not exist in the data dictionary the
system prompts you to create one.
Give the technical characteristics under the definition
tab. Value range allows you value restriction at domain
level.
Value range tab:
As explained in the section Consistency through input checks one can restrict the possible values for a field at domain level itself by either entering fixed values or by specifying a value table under the tab Value range.
<b>Currency/Quantity fields in a table</b>
A currency or a quantity field must be assigned a reference field from a reference table containing applicable qty unit or currency unit.
Field of the reference table, containing the applicable quantity unit or currency
A field containing currency amounts (data type CURR) must be assigned a reference field including the currency key (data type CUKY).
A field containing quantity specifications (data type QUAN) must be assigned a reference field including the associated quantity unit (data type UNIT).
<b>Create transparent table continue</b>
Maintain the technical settings of the table by clicking on the tab