The name of a view can have a maximum of 16 characters, can consist of letters, numbers, and underscores, must start with a letter, and can be prefixed by a namespace prefix (/.../) of a prefix namespace. The name is in the namespace of the data types in ABAP Dictionary.
The data in a view is read from the database tables involved by the database and is not saved physically.
- Views for a database table can be used to restrict database access to specific fields (known as projection) or to specific rows (known as selection).
- Views for multiple database tables use joins or subqueries to join these tables and to read the required fields and rows.
ABAP Dictionary manages the following categories of views:
- Classic views
- External views
When a view is accessed using the Open SQL statement SELECT, the SELECT statement defined in the DDL statement is executed and the results set is returned as if a SELECT were executed on a database table whose structure matches the structure defined by the view.
Notes
- Views are usually defined in the implementation of data models in ABAP Dictionary and this is not usually the job of a regular ABAP application programmer. Once created, views are used in ABAP programs using Open SQL statements and must be stable enough to allow this.
- When making selections using views, it is also important that suitable indexes are created for the basis tables in the view.
- The CDS views in the ABAP Core Data Services (CDS) are added to the views specified. A CDS view is defined in a (mostly) platform-independent CDS DDL in CDS source code. CDS views expand on the functions provided by the classic views.
1. Classic Views
A classic view (or view for short) is a repository object in ABAP Dictionary defined for existing database tables and their fields in the form-based tool ABAP Dictionary in ABAP Workbench. Alongside the classic views, ABAP Dictionary also manages the CDS views defined in the CDS source code in CDS.
The definition of a classic view consists of the following:
- Basis tables
A list of database tables accessed by the view. Multiple tables are joined using joins.
- View fields
A list of table fields of the basis tables that defines the structure of the view. Except in the case of projection views, a different data element can be assigned to a view field that that used for the corresponding table field of the basis table. This can only happen if the type of the table field is defined using a data element with a domain and if the new data element references the same domain. This makes it possible to adjust the semantic attributes of the view field to the view.
- Key
A key of the view that consists of key fields. The tool derives the key of a view from the key fields of the basis tables and the join conditions. All the key fields must be together at the beginning of the view. Fields that do not belong to the key, but are located between the key fields, are thus marked as key fields. All rows determined by the view must be unique with respect to the key. If no key with this property can be identified, all fields of the view are key fields, which can be bad for performance. In the case of Open SQL accesses to the view, its key behaves like the key of a database table.
- Join conditions
Conditions for joining multiple basis tables using inner joins or outer joins. A join condition compares two fields from basis tables of a view for equality. If no join conditions are specified for a pair of basis tables, the view is used to select the cross product of the basis tables. Each row in a table is combined with each row of the other table. Each join condition then selects the matching rows from the cross product.
- Selection conditions
Used to restrict the read rows to specific values of view fields or other fields.
- The possible relational operators are =, <>, >=, >, <=, <, LIKE, and NOT LIKE.
- Depending on the data type of the view field, constant texts and numbers are allowed as comparison values. System fields can be specified for maintenance views and help views using SYST-... or SY-....
- Multiple comparisons can be joined using AND and multiple comparisons for the same field can be joined using OR. Here, OR is stronger than AND.
The following types of classic views exist, of which only the database views are defined as SQL views on the database:
- Database views
- Projection views
- Maintenance views
- Help views
Like database tables, views have a short text description and (optional) documentation. A status known as a maintenance status determines whether a view is read-only or whether data can be inserted or modified in the view.
Notes
- Projections can be implemented using both database views and with special projection views.
- Only database tables can be specified as the basis tables of classic views, and no other views.
- CDS views defined using the DDL of the ABAP Core Data Services in CDS source code offer all the functions of classic views and more. CDS views are, however, read-only, while some classic views can be modified.
◈ Database Views
A database view is a general view for one or more basis tables. If there are multiple basis tables, they are joined using an inner join. A matching SQL view is created on the database when the view is activated. The structure type defined using the view fields of the database view can be referenced in ABAP programs using TYPE. A database view can be accessed using both Open SQL and Native SQL.
- Basis Tables
The basis tables of database views must be transparent tables, so that the SQL view can access them. The actual join operation is performed on the database.
Note : The basis tables of CDS database views, which are generated for CDS views, can also be other database views.
- View Fields
An include mechanism can be used to add individual fields or all fields from the basis tables as view fields of a database view. When individual fields are used, a different name can be defined for a view field than the name in the basis tables. This name can have a maximum of 30 characters, must meet the naming conventions for component names of structures, and cannot be a reserved name. The reserved names that cannot be used are in the database table TRESE.
To use all fields, the * character is used instead of the field name. If the - character is used for individual fields of a basis table included using *, all fields up to the fields specified with - become view fields. If the structure of a database table whose fields were added in this way is modified, the structure of the view is also modified.
Notes:
1. If a foreign key field is added as a view field, it keeps this attributes and all associated foreign key fields become the foreign key of the view.
1. If a foreign key field is added as a view field, it keeps this attributes and all associated foreign key fields become the foreign key of the view.
2. For CDS database views, the View fields displayed here as key fields are in no way related to the key fields that are defined using DEFINE VIEW for the CDS entity.
- Join Conditions
The join conditions for the inner join can be formulated using equality relationships between any two table fields in the basis tables. The inner join joins the rows of the basis tables in question as a results set containing all combinations of rows whose columns together meet the join conditions. If there are no rows that meet the join conditions in the basis tables in question, no row is created in the results set. If there is a suitable foreign key dependency (including generic and constant foreign keys) between two basis tables, this dependency can be used as a default for defining join conditions in ABAP Dictionary.
- Maintenance Status
The Access setting in the maintenance status of a database view can have the following values:
1. Read only
The database view can only be used to read data with Open SQL.
2. Read, change, delete, and insert
If the database view contains only a single basis table, data can be changed using Open SQL.
A database view with multiple basis tables can only be read with Open SQL. If a database view contains only a single table, data can be inserted in this table using the view with the Open SQL statements INSERT or MODIFY. The following options are available for the content of the table fields not in the view:
- If the table field is defined with NOT NULL on the database, the field is filled with the corresponding initial value.
- If the table field is defined with NOT NULL on the database, and there is not initial value, nothing can be inserted and a database error occurs with a corresponding exception.
- If the table field is not defined with NOT NULL on the database, the field is filled with the null value.
Notes:
- A database view should only be used to insert data in the table if the flag for initial values is set for all table fields that are not in the view.
- It is not usually a problem to modify existing data records using a database view in cases where the database view contains all key fields of the table.
- Like a database table, the maintenance status of a database view has a Display and Maintain setting alongside the Access setting. The setting must match the Access setting. In database views containing multiple basis tables, only the setting Display/maintenance not allowed is possible.
- SAP Buffering
Just like in database tables, it is possible to define for a database view whether the data in the SAP buffer is buffered. The same buffering types can be defined and SAP buffering in Open SQL is handled in the same way for views and for database tables with the only difference being that, when data is modified in one of the basis tables, the entire buffer is invalidated when the buffers are synchronized, regardless of the buffering type In client-specific views, however, this only affects the content of the current client.
The following prerequisites must be met before a database view can be buffered:
- A basis table can occur in no more than nine buffered database views.
- If all fields of the database view are key fields, these fields must also be key fields of the basis tables.
Example
The database view DEMO_SCARR_SPFLI contains fields of the tables SCARR and SPFLI. Other names are assigned to these fields in the view.
The associated database object could be as follows:
CREATE VIEW DEMO_SCARR_SPFLI
(CLIENT,
ID,
CARRIER,
FLIGHT,
DEPARTURE,
DESTINATION )
AS SELECT
T1."MANDT",
T2."CARRID",
T1."CARRNAME",
T2."CONNID",
T2."CITYFROM",
T2."CITYTO"
FROM
"SCARR" T1,
"SPFLI" T2
WHERE
T1."MANDT" = T2."MANDT" AND
T1."CARRID" = T2."CARRID"
The view could be accessed as follows using Open SQL:
SELECT *
FROM demo_scarr_spfli
ORDER BY id, carrier, flight
INTO TABLE @DATA(result).
cl_demo_output=>display( result ).
◈ Projection Views
A projection view is a special view for hiding fields from a single basis table. An SQL view is not created on the database. No selection conditions can be specified for a projection view.
The structure type defined using the view fields of the projection view can be referenced in ABAP programs using TYPE. A projection view can be accessed using Open SQL but not Native SQL. Projection views can be used to access pooled table or cluster tables as well as transparent tables. The database interface transforms an Open SQL statement that accesses a projection view to a platform-specific SQL statement that provides the correct result.
The Access setting in the maintenance status of a projection view can have the following values:
- Read only
- Read, change, delete, and insert
When rows are inserted using projection views, all table fields not in the view are given the type-specific initial values of the field. This is done regardless of whether the fields is defined as NOT NULL on the database.
Note: Like a database table, the maintenance status of a projection view has a Display and Maintain setting alongside the Access setting. The setting must match the Access setting.
Example
The projection view DEMO_SPFLI contains fields of the tables SPFLI. The view could be accessed as follows using Open SQL:
SELECT *
FROM demo_spfli
ORDER BY carrid, connid
INTO TABLE @DATA(result).
cl_demo_output=>display( result ).
◈ Maintenance views
A maintenance view is a special view for performing writes on multiple tables using extended table maintenance. A single maintenance view can be used to modify the content of multiple related database table consistently.
A maintenance view is not defined on the database. The structure type defined using a maintenance view can be referenced in ABAP programs using TYPE. A maintenance view cannot, however, be accessed using Open SQL. Instead, the transaction SE54 can be used to create dialogs called maintenance dialogs for maintenance views, which can themselves be used to edit the tables of the maintenance views jointly in extended table maintenance (transactions SM30 and SM31).
When data records are inserted using maintenance views, all tables fields not in the view are given the type-specific initial values of the field. This is done regardless of whether the fields is defined as NOT NULL on the database.
- Primary Table and Secondary Tables
All database tables grouped in a maintenance view must be joined using foreign key dependencies, which means that the join conditions are always derived from a foreign key in the case of maintenance views. The first table included in the maintenance view is known as the primary table of the maintenance view. The tables added to this primary table using foreign keys are known as secondary tables. The following restrictions apply when selecting the secondary tables of a maintenance view:
➪ The secondary tables must have an N:1 dependency to the primary table or to the transitively preceding secondary table. This makes sure that no more than one dependent data record exists in each of the secondary tables for a specific data record in the primary table. An N:1 dependency exists if the secondary table is the check table in the foreign key in question.
➪ If the secondary table is the foreign key table, the foreign key fields must be key fields of a table or the foreign key must have the cardinality N:1 or N:C.
A help view implements an inner join. All key fields in the primary table must be included in its maintenance view. All key fields of secondary tables that are not part of the foreign key (that is, they are not joined with a key field already in the view using a join condition) must also be included in the view. This makes sure that the records inserted using a maintenance view can be written correctly to the tables in the view.
Note: If a database table is joined with its text table in a maintenance view, the logon language is selected automatically for this table.
- Time-Dependent Key
In maintenance views, the key can be divided into a non-time-dependent area and a time-dependent area. The time-dependent area can, for example, contain date fields and time fields. This means that the rows of these views have chronological importance.
Note: The ability to change time-dependent views makes it possible to restrict which new entries are inserted to those that are only missing time information.
- Maintenance Status
The Access setting in the maintenance status of a maintenance view can have the following values:
➪ Read only
The maintenance view can only be used to read data.
➪ Read, change, delete, and insert
The maintenance view can be used to change, delete, and insert data.
➪ Read and change
The maintenance view can be used to change data, but not delete or insert it.
➪ Read and change (time-dependent views)
The maintenance view can be used to insert only entries whose non-time-dependent part of the key does not differ from existing entries.
Note: Like a database table, the maintenance status of a maintenance view has a Display and Maintain setting alongside the Access setting. The setting must match the Access setting. The setting Display/maintenance not allowed is not possible here.
- Maintenance Characteristics of View Fields
Alongside the maintenance status of the view, characteristics called maintenance characteristics can be defined for each view field:
➪ Standard
There are no restrictions on the view field.
➪ Read-only
The maintenance view cannot be used to perform writes on the view field.
➪ Subset
A field of this type is used to construct subsets when data is maintained in extended table maintenance. Only a subset of the data is displayed. This subset is defined by entering an appropriate value in this field.
➪ Hidden
A field of this type is not displayed in extended table maintenance and cannot be edited there. The content is initialized implicitly.
- Delivery Class
A maintenance view also has a delivery class, which is evaluated in extended table maintenance.
➪ If the view is assigned one of the delivery classes G or E, the customer namespace for the entries of the view must be defined in the database table TRESC.
➪ The transport interface of extended table maintenance must match the delivery class.
Regardless of this, the transport of the basis tables involved in upgrades and in transports between customer systems is determined solely by their delivery class.
◈ Help views
A help view is a special view for use in search helps. The selection methods of a search help can be database tables, database views, and the special help views. Database tables restrict the search help to one table and database views restrict it to inner joins, whereas help views also make outer joins possible. A help view is not defined on the database. The structure type defined using a help view can be referenced in ABAP programs using TYPE. A help view cannot, however, be accessed using Open SQL.
The join conditions of a help view must be applied from existing foreign keys. Tables can be grouped in help views only if they are joined using foreign keys. The first table included in the help view is known as the primary table of the help view. The tables added to this primary table using foreign keys are known as secondary tables. The same restrictions apply when selecting secondary tables of a help view as to maintenance views.
A help view implements an outer join, which means that the full content of the primary table of the help view is always displayed. If records in a secondary table cannot be read due to a selection condition, the content of the corresponding fields of the secondary table are displayed with initial values.
Notes
- Like other views, help views can be used in elementary search helps if the selection is too complex to be defined using a single database table.
- Unlike database views, help views implement an outer join, which is why this type is particularly well suited for including supplementary information such as explanatory texts from secondary tables. If the supplementary information were missing in an inner join, no part of the dataset would be selected.
- If the selection is only made using a table and its text table, it is enough to specify the table directly as a selection method of the search help, since the fields of the text table can also be used as parameters in the search help in this case.
- Help views should not be used if the selection is often restricted using fields of the secondary tables. In this case, a database view should be created instead. It might also be necessary to create additional suitable indexes for the basis tables.
- Selections using help views can only be made quicker by making restrictions on the primary table. When accessing help views from the ABAP runtime environment, special selection routines are generated. These routines always make the selection using the primary table first and then use the records found as a key for selecting the supplementary information.
2. External Views
An external view is a special view in ABAP Dictionary, which defines an SAP HANA View in ABAP programs. The structure type defined using the view fields of an external view can be referenced in ABAP programs using TYPE. An external view can be specified as a source in Open SQL read statements
External views can only be created using the ABAP Development Tools (ADT) and only if the current database is an SAP HANA database. When an external view is activated, an alias with the name of the view is created on the SAP HANA database that points to the SAP HANA view. The names of the view fields of the external view can be defined differently from the names of the view fields of the SAP HANA view. The runtime object of the external view accesses the alias on the SAP HANA database. This performs a mapping of HANA-specific data types to the predefined types in ABAP Dictionary. The following table lists the currently supported HANA-specific data types and indicates which ABAP Dictionary types they are mapped to by default.
| HANA Type | Meaning | Type in ABAP Dictionary |
| SMALLINT | 2-byte integer | INT2 |
| INTEGER | 4-byte integer | INT4 |
| BIGINT | 8-byte integer | INT8 |
| DECIMAL | Packed number | DEC |
| SMALLDECIMAL | Packed number | DEC |
| FLOAT | Binary floating point number | FLTP |
| NVARCHAR | Unicode character string | CHAR |
| VARBINARY | Byte string | RAW |
| BLOB | Byte string | RAWSTRING |
| NCLOB | Unicode character string | STRING |
External views can be displayed in the ABAP Dictionary tool in the SAP GUI-based ABAP Workbench, but not edited.
An external view can only be read using Open SQL if an SAP HANA database is being accessed in which the associated SAP HANA view exists. If not, the non-handleable exception DBSQL_TABLE_UNKNOWN is raised. External views can exist actively and be used as data types in a system whose standard database is not an SAP HANA database. Views of this type cannot, however, be accessed through the standard database connection using Open SQL, only through a secondary database connection to an SAP HANA database. Conversely, when an SAP HANA view in an SAP HANA database is accessed through a secondary database connection in the current system, only an identically named database table or a structure suitable for any view in ABAP Dictionary can exist actively in ABAP Dictionary.
Notes:
- The following restrictions currently apply to the use of external views in ABAP programs:
- The structure of analytic views do not allow them to be read using SELECT *. The same basic rules apply to the statement SELECT in Open SQL as when using the HANA-SQL statement SELECT, with individual columns and the addition GROUP BY needing to be specified. If SELECT * is used, a runtime error occurs.
- Calculation views with parameters can be access only if a default value is defined for each parameter. If not, reads are canceled and produce a runtime error.
- External views should only be used in those cases that are not covered by ABAP CDS or AMDP.
No comments:
Post a Comment