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
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.
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 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, change, delete and insert (default setting);
read and change; and
read and change (with time-dependent views).
DEFINE MAINTENACE VIEW 2
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
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
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.
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.