Special Edition Using SAP R/3, Third Edition

More documents

Recommendations

Info

Special Edition Using SAP R/3, Third Edition - CH 3 - Exploring R/3 Architecture Page 20 of 26 Database Services The design philosophy of R/3 is based on the open system concept, which stipulates that communications to and from an open system should be restricted only by the demands of the standards in force. The standard adopted language for the definition of data and its manipulation is SQL. Any database that can interface according to this standard can be used by the R/3 system without the user needing to be aware of the detailed mechanisms of the database server. New products can be used as they become available without discarding the old and reprogramming the system. However, not all database manufacturers offer the same range of SQL functions. The ABAP/4 Development Workbench, used to write all SAP R/3 business programs, has adopted two SQL standards: Open and Native. Open SQL ABAP/4 Open SQL is an extension of the ABAP/4 language, which ensures the success of any application that accesses a database using only the functions of the Open SQL. Any database that supports this set of functions can be used by an R/3 system. Native SQL Many vendors of database systems have enhanced their products by adding functions outside the set specified by the Open SQL standard. These improved functions cannot be used by a system limited to the Open SQL standard. ABAP/4 Native SQL can call the enhanced functions of a specific database system whether all calls are encapsulated in a module specific to that database system. The module must also recognize the calls made in ABAP/4 Native SQL and respond to them by initiating the database commands specific to the particular system that will initiate the enhanced functions. New database systems can be used by R/3 if the calling modules use ABAP/4 Native SQL and if the specific database system includes the special module to interpret the Native SQL commands. SQL Set Operations One of SQL’s most useful facilities is its capability to recognize logical set operations and use them to manipulate sets of records, such as arrays. This feature helps accelerate network communications in client/server architectures. Optimized SQL Instructions If you are seeking a very small number of records from a database, it might take more effort to prepare an optimum search strategy than to seek the result directly. However, if the data volumes are large and diverse, there might be an advantage in using optimized SQL instructions. file://J:\prodinfo\MEMBERS\MA\ir057.html 3/23/01
Special Edition Using SAP R/3, Third Edition - CH 3 - Exploring R/3 Architecture Page 21 of 26 Database vendors offer a range, from optimized instructions in fixed agendas to dynamic buffering of optimized instructions. The R/3 approach is to encapsulate database-specific functions in a system interface that eliminates the need for applications programmers to construct their own for each database. Multiple Database Access Database vendors usually offer a range of gateways and transparent distribution mechanisms that can be used by R/3 to access these sources. Open Data The concept of an open database includes the notion that all data is stored in tables ready to be instantly inspected and used without any need for complex data-retrieval instructions in a language specific to the one vendor. There are at least two routes to achieving this facility: building a specific interface and using a standardized interface such as ODBC. However, it is not enough for a system to be able to locate a specific data element in different types of databases. It is also necessary for the user to be able to work out what that data means. Semantic openness refers to the capability that enables users to locate the data tables and elements that hold the information they need--data that will have the proper meaning when it is placed in the context of interest. The SAP Enterprise Data Model The intention of the Enterprise Data Model is to enable the user of a database network to assemble the data relevant to that enterprise and to attach the correct interpretation to it. This topic is discussed in Chapter 10, "Developing an SAP Open Information Warehouse." Client Caching The purpose of using client caches to buffer communications with databases is to optimize client/server operations. Every application server has an installed database service as part of the R/3 runtime environment. Client caches are located in main memory and hold the data most frequently used by that application. This reduces network traffic and the load on the database server. Typical contents of a client cache include such information as this: ABAP/4 programs Dynpros Information from the ABAP/4 data dictionary Business parameters that usually remain unchanged in a running system file://J:\prodinfo\MEMBERS\MA\ir057.html 3/23/01
Page 1 and 2: Special Edition Using SAP R/3, Thir
Page 19: Special Edition Using SAP R/3, Thir

Special Edition Using SAP R/3, Third Edition

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?