The ABAP/4dictionary is central workbench repository utility providing the data definition and the information relationship that are later used in all the business application within R/3
The ABAP/4 dictionary can be seen as a logical representation or a superior layer over the physical underlying database. This database must support the relational data model. This model is strictly followed by data dictionary.
About Data Dictionary
A Data dictionary in computing terms is the source of information in which system data is defined. The data dictionary is the centralized and structured source of information for business applications. You can say that it is core of a well-structured development environment.
The elements that make up a dictionary are known as metadata. Metadata is the term for the data whose function is to describe other data. Data in dictionary is not the actual data like emp. name or emp. address but rather a type of data whose function is to define the properties of the data such as type, length, and relationship.
Advantages
Advantage of using data dictionary is avoiding inconsistencies when defining data type that will later be used in different applications. This avoids redundancies.
When a type is defined in the dictionary, it is available to any program in the application. A change in the definition of a type of data in the dictionary automatically affects any other data or program, which has this data.
Again, data dictionary is a fast and efficient way to answer questions such as which entries exist in a table of the database, what the structure of table is.
Activation of dictionary objects
For a dictionary object to be effective at runtime, that is, for a dictionary object to be available for use within a program, transaction, and so on, it must be in active status. For objects to become active, R/3 includes the ACTIVATION function.
When a table or aggregated object is activated, it is placed at the disposal of the system as a runtime object in a way that makes it available quickly for the application program to access relevant information of new activated objects.
When a dictionary object is modified, that means that the object previously existed and activated. You need to reactivate the object after modification.
When mass activation is performed massively, it might take a quite a long time. Then it should be in the background system. This type of activation is known as background activation.
The ABAP/4 Data dictionary is the central component of ABAP/4 repository. A Data dictionary is centralized and structured source of information for business application. The ABAP/4 dictionary is the core of the R/3 development system. It is the source of every definition, within R/3, from the very basic domain to the company data model. It is totally integrated with other tools of the development environment like screen painter, menu painter, and editor.
Some of the main available functions in the ABAP/4 dictionary are as follows:
• Add, delete, modify, and manage the definition of the dictionary data.
• Preserve the data integrity.
• Be the central source of information e.g. from the dictionary you get the information about the defined relationship between two tables or even the directory tells whether table is active or empty.
• It also permits documentation of system data.
In the R/3 system instead of working with original objects, you work with internal representation of objects. With this type of operation the system performance is enhanced and has the advantage that the development tools, screen interpreters always access current data.
When any of the data dictionary objects are used in other parts of the development workbench for example, in program, programmer only has to enter a table name or field name. The system automatically knows all the properties and information of the field.
To call ABAP/4 dictionary, from the main menu, Tools ABAP/4 workbench data dictionary or enter transaction SE11.
Data dictionary objects:
• Table: is a 2D data matrix containing rows and columns. Rows contain data while column indicates fields. Table can contain 0 or multiple rows.
• Structure: is a skeletal view of a table. It contains the definition of columns and don’t have any contents. Structure is generally a template based on which a table is created. The basic difference between structure and table is that the structure does not exist at the underlying database system level. Structure exists as definition in the dictionary.
• Views: A view is an imaginary table. It contains data, which is really stored in other tables. The contents for the view are dynamically generated when called from program.
• Data element: is definition of the properties and type for a table field. It is an intermediate object between the object type domain and the table field. A field in R/3 system is always associated with a data element, which at the same time is related to domain.
• Domain: is formal definition of the data type from a technical point of view. It sets the attributes such as data type, length, possible value range and so on.
• Lock objects: These types of objects are used for locking the access to database records in table. This mechanism is used to enforce data integrity that is two users cannot update the same data at the same time. With lock objects you can lock table-field or whole table.
• Search Help Objects: , which gives list of possible values for either primary keys or non-primary keys.
Tables in ABAP/4 dictionary
Tables are the basic objects in R/3 application. There are almost 8000 tables in R/3 system. Following types of tables are available
• Transparent tables
• Pool tables
• Cluster tables
From user point of view, all tables are used to store data whatever be the type of table. There is no difference in the behavior or operation of these tables. All of them can be managed by using standard OPEN SQL. However from an administrator point of view transparent table do exists with the same structure both in the dictionary as well as in the database, exactly with the same data and fields. While other two are not transparent in the sense that they are not manageable directly using database system tools. You can access these tables in R/3 environment from the ABAP/4 dictionary. You cannot use native SQL on these tables. Pool or cluster tables are logical tables, which are arranged as records of transparent table.
A table is made up of rows and columns. When the table is created, its columns are named; data type is supplied for each column. There can be only one data value in each column of each row in a table. Record or as it is called in different RDBMS is nothing but group of fields. While a column is a field of a table, a table is an indexed file. The main index is called as primary key, which can be a single field or combination of keys or fields. A primary key can be defined as a field, which indefinites a single unique record of the table. A table cannot have record with duplicate primary key.
In any RDBMS, tables are related to each other. But to relate table to each other it is necessary that one of the tables contain some information of other table. Mostly tables are related to each other through primary keys. The primary key of one table, if it exists in other table then it is called foreign key. This type of database management system means that there is some redundancy of data. But using normalization procedures available can minimize it. One of the most important functions of foreign key is to ensure data integrity. For example say you have EMP table, which has fields: emp. no., emp.name, dept.code, salary and you have DEPT tables, which has dept.code and dept.desc. Then in DEPT table dept.code is primary key while dept.code in EMP table is foreign key. If you enter dept.code for particular employee in EMP table the dept.code should exist in DEPT table. System will check the value for dept.code in DEPT table, and if does not exist then will flash error. In this case DEPT is called check table while EMP is foreign key table.
Creation of table
Steps to create a table
• Create domain
• Create data element
• Create actual table
Creating Domain
Domain as already explained defines the technical properties of a field such as type and value range. A domain can be created from initial screen of data dictionary by clicking on create and clicking domain Radiobutton. Parameters to be passed are:
Data type: Where you need to enter the data type available in SAP.
Field length: Field length is the number of valid position.
Value table: Name of a table to be entered. The fields referring to this domain may only assume values contained in the value table.
Once the domain is created, save and activate it, so that it can be used for further objects (basic rule of dictionary).
Creating Data Element
The second step of table creation is to create data element. It assigns a certain meaning to the table field, which are defined using that data element. A Data element always needs to be defined over a domain and field is always defined over a data element. This allows all fields with same technical properties to use the same data element.
Parameters to be passed when creating a data element:
Short text: Mandatory field.
Domain: A mandatory field. If the domain does not exist, SAP can take you directly to domain definition screen.
Text element: You can enter description is short or long text for the field. This text is used when
entering data for these fields.
Save and activate.
Creation of actual table
Parameters to be passed for creation of table:
Short description: Mandatory field.
Delivery class: As per User Requirement
Table fields: Specify whether primary key. In this case it is mandatory to enter data element.
Data class: Establishes the physical area of the database.
Size category: Allows you to specify estimated space requirement for the table.
Further down under buffering square box, the system allows specifying whether table is going to be buffered. When a table is buffered, it is loaded into the table buffer from the application server memory and it will remain there until you switch off or reboot system.
If the table is to be buffered, you need to specify the type of buffering. Full is for entire table while partial is for only those records which are being accessed.
Once the table is created, it has to be generated or activated to be able to access by other objects like programs.
No comments:
Post a Comment