Chapter 08 abap dictionary objects views1

Editor's Notes

• #4: A view is an object, like the telescope, that provides a picture of something. We can construct a view with special “lenses” or “filters” to allow us to look at one or more dictionary tables. We can look at parts of one table (selected records and/or fields) or combinations of tables and parts of tables. A view is an ABAP Dictionary object. In many cases, you reference a view in an ABAP program just as you would a table. For example, you can select data from a view. However, a view does not contain data of its own – rather, the view provides specialised access to the data that exists in other tables. For this reason, views are often called virtual tables.
• #5: In its most basic form, a view simply mirrors an entire database table. It looks just like the table and it acts just like the table – but it isn’t actually the table. Of course, if this is all that views could do, they wouldn’t be very useful. Let’s take a look at some of the other capabilities of views. The view name cannot be the same as an existing table name.
• #6: We can use views to: Join several tables Project (or choose) certain fields from one or more tables Select (or choose) certain records from one or more tables Join, projection, and selection are called relational operations.
• #7: The projection operation is used to narrow a view’s focus to certain fields in a table. For example, we might have a view of an employee table that does not contain the salary field. Employees authorised to view salary data would be given authorisation to view the actual table, while other employees might only have authorisation to use the view without the salary data.
• #8: When designing a view, view fields need to be given names. The view field names should be the same as the regular table fields they are reflecting, unless the view is a database view. Only in that situation are you permitted to use different names. When referencing the view field in code, you would refer to VIEW_NAME-VIEW_FIELD_NAME. You can also indicate the following in the View field column: : Include every field from the table. It follows that in the Field name column, you would indicate a * as well. : This removes a specific field from a view. You can use this option in conjunction with the one above to fine-tune which fields you want included in the view.
• #9: The selection operation is used to narrow a view’s focus to certain records in a table. For example, we might sometimes wish to view only the information about employees belonging to a certain staff classification. This might mean creating one view containing partners and principals one view containing principal consultants, and another view containing consultants. Each view would be built using selection criteria that indicated which records to include in that view. As an example of why such a view might be used, staff members might be permitted to view the billing rates of employees in the same staff classification or lower, but not of employees in a higher classification.
• #10: You specify selection criteria by building logical expressions that compare specific fields of a table to hard-coded literal values. (1 & 2) Specify the table and field on which the restricted selection should take place. Any fields, including unprojected ones, can be indicated. (3) Specify the relational operator used to compare the field to the value. You may use EQ, NE, LE, LT, GE, GT, LIKE, and NOT LIKE. (4) Specify the comparison value. Comparison values must be text or numeric literals. Text literals must be enclosed in single quotes. (5) You can specify multiple selection criteria (one per line) and link them using the logical operators AND and OR. Unlike elsewhere in SAP (and most other systems), OR takes priority over AND. Also, OR operations are only permitted between lines which refer to the same field. If the projection and selection operations are both used within the same view, it is possible to specify selection criteria for fields that are not included within the view. For example, it would be possible to create a view that contained only employees making over $100,000 per year even if the view did not contain the salary field.
• #11: The join operation is used to combine information from multiple tables into a single view. For example, we might wish to create a report listing employees by name, along with their salary history. Database design considerations would probably result in the salary history being stored in one table and basic employee information (such as the name) being stored in another. Thus, we might create a view that would combine the data from both tables. We could write our report program using this view, and it would seem to our program as if the data was stored in a single table. Using the join operation within a view is generally the most efficient way to access data from multiple tables. We’ll examine some other methods later on.
• #12: Database design principles often require related data to be stored in separate tables. This is necessary to provide flexibility in one-to-many and many-to-many relationships, and also to prevent data redundancy. For example, if employee name and salary history were stored in the same table, we would encounter one of the following situations: If we stored salary history on the employee record, we would have to create a fixed number of “previous salary” fields in the employee table. For many employees, most of those fields would be blank, and for long-term employees, we might eventually run out of fields. If we stored employee name on the salary history record, we would have many copies of the employee’s name. If the employee’s name changed, that change would have to be made many times. Additionally, we would run the risk of not updating all the data correctly, and the employee and the salary table could get “out of sync.” Whenever possible, redundant copies of the same information should be avoided. As a result, data is often “broken apart” into several tables. This is called normalising the database. The join operation essentially reverses this process. The result of a join is a view that looks like a table with redundant data.
• #13: When data is broken apart into separate tables, it is still necessary to duplicate some data – namely the key fields of the tables involved. For example, the salary history table would contain a field for employee ID number, so that we knew which employee each salary record belonged to. In this case, the employee ID number becomes a foreign key in the salary history table. The key to understanding the join operation is to understand that different tables are joined together using foreign keys. We don’t want every employee’s name associated with every salary history record. Rather, we want each employee’s name to be associated with only those salary records belonging to that employee.
• #14: Therefore, in order to use the join operation in SAP, you must first ensure that the appropriate foreign key relationships exist among the tables to be joined. Also, you must ensure that the semantic attributes of those foreign keys have been maintained (see Chapter 4 for a discussion of semantic attributes and foreign keys). Other notes on the join operation: Views are created with a primary table and up to 10 secondary tables. The primary table can be either a check table or a foreign key table with respect to the other tables in the view (i.e., the primary table does not have to be the check table). Note : When a join operation is employed, only those primary table records that have a match in all secondary tables are retrieved. For example, in a join between employees and salary history, employees with no salary history records would not appear at all.
• #15: You can hard code all the tables you need all at once. Then you would have to hard code the foreign key relationships between them as well. It might be simpler to input the first base table, and from there hit the Relationships pushbutton. Then you can select a related table and the join conditions will be filled in automatically for you.
• #17: The database view is the only type of view in SAP that is physically created at the database level. In other words, the underlying database system also directly recognises the view, apart from SAP. Therefore, database views must be created over transparent tables. With the database view, all three of the relational operations (projection, selection, and join) can be used. Database views can be buffered just like transparent tables. In the technical settings you can decide whether to have buffering off, or on with type single record, generic, or full.
• #20: The projection view is a logical view. In this context, the word “logical” means that the view exists within the ABAP Dictionary but is not recognised by the underlying database system. Projection views must be defined over a single transparent table. The only relational operation that is valid for a projection view is projection.
• #21: Projection Views Database Views Must be built over a single table Can be built over many tables Data can be updatedData can be updated if the view is built over asingle table Data updates must use open SQLData updates can use open SQL or Native SQL Updates are less efficient than usingUpdates are more efficient than usinga Database Viewa Projection View Fields in the view must be named the Fields in the view can be namedsame as the fields in the differently from the fields in theunderlying table underlying table(s) Can’t be bufferedCan be buffered
• #22: Help Views: Help views can be used as selection methods for Search Helps. It might be necessary to create a Help View if you are trying to accomplish an outer join, since database views only create inner joins. Maintenance Views: These views permit maintenance of base table data. Transactions SM30 and SE54 are provided for working with maintenance views. In previous releases, Help Views used to play a major role in matchcodes. However, matchcodes have been replaced by Search Helps, and therefore, Help Views no longer have as big a presence.
• #23: In the code above, we select data from the view YXXEMP_V to write data from the id, name, and salary fields to the screen. The syntax to reference a view in an ABAP program is the same as that used to reference a table.