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.
Given two tables TABA and TABB. Table TABA contains 2 entries and table TABB 4 entries.
The tables are first appended to one another. This results in the cross-product of the two tables, in which each record of TABA is combined with each record of TABB.
Usually the entire cross-product is not a meaningful selection. You should therefore limit the cross-product with a join condition. The join condition describes how the records of the two tables are related.
In our example, Field 3 of TABB identifies Field 1 of TABA. The join condition is then:
TABA - Field 1 = TABB - Field 3
With this join condition, all the records whose entry in Field 1 is not identical to the entry in Field 3 are removed from the cross product. The column for Field 3 in the view is therefore unnecessary.
STRUCTURE OF A VIEW:
Often some of the fields of the tables involved in a view are of no interest. You can explicitly define the set of fields to be included in the view (projection).
The set of records that can be displayed with the view can be further restricted with a selection condition.
In our example, only those records with value 'A' in Field 4 should be displayed with the view.
A selection condition therefore can also be formulated with a field that is not contained in the view.
The join conditions can also be derived from the existing foreign key relationships. Copying the join conditions from the existing foreign keys is supported in the maintenance transaction.
The field names of the underlying table fields are normally used as field names in the view. However, you can also choose a different field name. This is necessary for instance if two fields with the same name are to be copied to the view from different tables. In this case you must choose a different name for one of the two fields in the view.
Selection with a database view, however, is usually more efficient than selection with a nested SELECT statement.
As of Release 4.0 you can formulate the join condition directly in OPEN SQL.
A view has type character and can be accessed in programs like all other types and can be used to define data objects.
DATA BASE VIEWS:
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.
INCLUDES IN DATA BASE VIEWS:
You can include entire tables in database views. In this case all the fields of the included table become fields of the view (whereby you can explicitly exclude certain fields). If new fields are included in the table or existing fields are deleted, the view is automatically adjusted to this change. A new or deleted field is therefore automatically included in the view or deleted from it.
If an append structure is added to a table included in a view, the fields added with the append structure are automatically included in the view.
To include a table in a view, you must enter the character '*' in field View field in the view maintenance, the name of the table to be included in the field Table and the character '*' again in the field Field name.
If you do not want to insert a field of the included table in the view, you must enter a '-' in field View field, the name of the included table in field Table and the name of the field to be excluded in field Field name.
As of Release 4.6C, fields of the base tables of a database view can be included in the view without modifications using an append view. This is analogous to enhancing a table using an append structure. An append view is assigned to exactly one database view. But more than one append view can be created for a database view.
MAINTENANCE VIEWS:
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.
You can maintain complex application objects in a simple way using a maintenance view. The data is automatically distributed on the underlying database tables.
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 Utilities -> Tab.maint.generator.
(116)
RELATED POSTS
SAP QUARY ADMISTRATION DAY 31
DATA FORMATION FOR OUTPUT DAY 32
SAVING LISTS IN BACK GROUND DAY 33
ALV GRID CONTROL IN REPORTS DAY 34
INTERACTIVE REPORTS BASICS DAY 35
No comments:
Post a Comment