TAW10 - views and maintenance dialog

WHY DO YOU NEED VIEWS?

You typically find data for an application object distributed on several database tables. Therefore, you need database systems to define application-specific views on data in several tables. These are known as views.
You can combine data from several tables in a meaningful way with the help of a view or join. Further, you can hide irrelevant information through projection. Alternatively, you can implement selection to display only those data records that satisfy certain conditions. You can display the data in a view in a format that is similar to the one used in the extended table maintenance.

STRUCTURE OF A VIEW - STARTING SITUATION

Let us understand the structure of a view and how to select data using this view. As shown here, table SCARR contains two entries while there are four entries in table SFLIGHT.
These tables are first appended to one another. This creates a cross product of the two tables, in which each record in SCARR is combined with each record in SFLIGHT.

STRUCTURE OF A VIEW - JOIN CONDITION

The result in the cross product of the two tables needs to be limited with a join condition. This condition defines the relationship between the records of the two tables. Here, CARRID field for SCARR is compared with the CARRID field for SFLIGHT. The join condition is then: SCARR-CARRID = SFLIGHT-CARRID.
Hence, all the records whose entry in Field 1 is not identical to the entry in Field 3 are removed from the cross product. Therefore, the column for Field 3 is not required in the view.

STRUCTURE OF A VIEW - FIELD SELECTION(PROJECTION)

Sometimes certain fields of a table involved in a view may not be relevant.
You can specifically define the set of fields to be included in the view or projection. As shown here, the PLANETYPE field is not relevant and can, therefore, be hidden.

STRUCTURE OF A VIEW - SELECTION CONDITION

You can use a selection condition to restrict the set of records that can be displayed with the view. As shown here, only those records with value DL in the CARRID field are required with the view. Therefore, a selection condition can also be formulated with a field that is not contained in the view.

HOW ARE TABLES (BASIS TABLES) LINKED TO VIEWS?

This slide depicts three different tables consisting of booking details of in-flight passengers that are relevant to travel agencies. Table SCUSTOM contains customer-related data, such as name and address of the customers. Table SBOOK includes booking data, such as the airline, flight number, and passenger number. Table SPFLI holds flight data, such as the city of departure and the city of arrival.
These tables contain different fields which are used to create a view that presents booking data. These are the join conditions:
SBOOK- CLIENT = SCUSTOM- CLIENT

SBOOK-CUSTOMID = SCUSTOM-ID

SPFLI- CLIENT= SBOOK- CLIENT

SPFLI-CARRID = SBOOK-CARRID

SPFLI-CONNID = SBOOK-CONNID

STRUCTURE OF THE VIEW

Here, you have the final view with the fields selected from different tables. If you want to obtain the booking details for an individual customer, then select the respective records for keys MANDT and CUSTOMID in Table SBOOK. You can also obtain the flight data from Table SPFLI by choosing the available records for the keys MANDT, CARRID, and CONNID.

DATA SELECTION WITH VIEWS

The ABAP program shown here illustrates how to use the SELECT statement to fetch data from the view ‘sv_flights’.

SQL: INNER JOIN SYNTAX

You can formulate the join condition directly in OPEN SQL. However, you can also get the same result using an Inner Join, as shown in the example.

INNER AND OUTER JOIN

The group of data that is selected with a view depends on whether the view implements an inner join or an outer join. An inner join consists of only those records which have an entry in all the tables included in the view. However, an outer join includes even those records for which there are no matching entries in some of the tables. Therefore, an inner join can be considered as a subset of the outer join. While database views always implement an inner join, maintenance views implement outer join.

DATABASE VIEWS

A database view is created on the database during activation after it is defined in the ABAP Dictionary. Database interface directly passes access to the database view. If the definition of a database view is changed in the ABAP Dictionary, the corresponding view created on the database must also be adjusted accordingly. The adjustment is made by deleting the old view definition and re-creating another on the database with a new definition. This is possible because a view does not contain any data.

DYNAMIC ATTACHMENT OF TABLE FIELDS IN DATABASE VIEWS

If you include an entire table in a database view, then all the fields of the included table become the fields of the view. This allows you to explicitly exclude certain fields. Any changes made in the table are automatically reflected in the view. Therefore, if an append structure is added to a table included in a view, the fields added with the append structure also appear automatically in the view.

COLLECTING DATA WITH GENERATED MAINTENANCE MASK

An application object is the logical unit of data that is spread across multiple tables. The user can create, display, and edit the data for such an application object as a whole. By using a maintenance view, you can automatically allocate data on the underlying database tables. You must link all the tables used in a maintenance view with a foreign key to form the join conditions from the foreign key in the maintenance view. Additionally, you require a maintenance interface to generate the function modules that distribute the data maintained in the view on the underlying tables.

MAINTENANCE VIEW FROM A MAINTENANCE VIEW

The first screen shows a one-step maintenance view which depicts the data of the table lines as Table Control. In this view, while you can change the function fields with a white background, you cannot do so for the fields having a gray background.
The second screen displays a two-step maintenance view which opens by double-clicking a table line in which the selected data record is presented clearly.

DEFINE MAINTENANCE VIEW 1

While creating maintenance views, you should

  select maintenance view as the view type;

  mention all the key fields of the primary table in the view definition;

  include the client field for client-dependent tables or views; and

  distinguish between the key fields and the function keys.

You can define the maintenance status for the entire table or view as

  read only;

  read, change, delete and insert (default setting);

  read and change; and

  read and change (with time-dependent views).

DEFINE MAINTENACE VIEW 2

This slide illustrates how to copy tables and view fields; apply selection conditions; define the maintenance status; and activate the view.
To copy tables, you must first specify the primary table of the view, under the field Tables, on the tab page Tables or Join Conditions. Next, place the cursor on the primary table and click Relationships. Select the desired foreign key, and then choose Copy.
To copy the view fields, select the fields that you want to copy into the view on the View field tab page. Activate Table fields to display all tables contained in the view; then select a table. As a result, the fields of the selected table are displayed in a dialog box.
The selection conditions determine which data records can be selected via the view. For this, you need to formulate restrictions to the data records on the Selection conditions tab page.
Similarly, the maintenance status defines how you can access the view data via the standard view maintenance. You can define the maintenance status of the view on the Maintenance status tab page.
Finally, an activation log automatically shows up when errors or warnings occur during the activation of the view.

DEFINE MAINTENANCE VIEW

You can arrive at the generation environment for maintenance views in the SE11 screen in the view for Tables/Views. To reach the initial screen of the maintenance transaction, select Utilities, then Table maintenance generator, then choose Development, followed by Other tools, and finally select Table maintenance view.
Here, enter the name of the table or the view. Next, select generated objects and choose Create/Change. Subsequently, a prompt appears where you need to confirm that the maintenance modules should be created.
This commences the process of generating the maintenance view. For this, you first need to start the transaction SM30 and enter the table or view in the Table or View field for which you have generated the maintenance view. Lastly, activate the Maintenance button.

ADVANTAGES AND DISADVANTAGES OF A MAINTENANCE VIEW

Let us look at some of the positive and negative aspects of using maintenance views.
A key advantage of using these views is that maintenance dialogs can be built better and faster than otherwise possible. However, using maintenance views for data maintenance in standard operations may lead to data inconsistencies. Therefore, it should be specifically used for entering that data in customer tables or customizing tables for which there is no overlapping.

VIEW CLUSTERS AND MAINTENANCE VIEW

View clusters are a collection of maintenance views, which have been combined in one maintenance unit for either business or technical reasons. This enables the maintenance of data that are similar from the content point of view. You can navigate within the view cluster using the hierarchy of the tables or views underlying the individual views. It is necessary to generate a maintenance view for every table or view involved, which can in turn be combined in SE54 in a view cluster. The associated data can be maintained by specifying the cluster name with transaction SM34.

ADVANTAGES

One major advantage of view clusters is the ease of navigation. By using view clusters, you can easily navigate to each component of the object. This improves the maintenance of the data of a view cluster.
Another advantage of view clusters is the consistency attained while deleting, copying, saving, retrieving, or manually transporting data. In fact, when an entry is deleted in a superior view, this is reflected in all the dependent entries in the subordinate view.