Hi,
Hi,
Logical Databases
Logical databases are special ABAP programs that retrieve data and make it available to application programs. The most common use of logical databases is still to read data from
database tables by linking them to executable ABAP programs.
However, from Release 4.5A, it has also been possible to call logical databases using the function module LDB_PROCESS. This allows you to call several logical databases from any
ABAP program, nested in any way. It is also possible to call a logical database more than once in a program, if it has been programmed to allow this. This is particularly useful for programs with type 1.
Logical databases contain Open SQL statements that read data from the database. You do not therefore need to use SQL in your own programs. The logical database reads the
program, stores them in the program if necessary, and then passes them line by line to the application program or the function module LDB_PROCESS using an interface work area.
Logical Databases - Views of Data
A logical database provides a particular view of database tables in the R/3 System. It is always worth using logical databases if the structure of the data that you want to read corresponds to a view available through a logical database.
The data structure in a logical database is hierarchical. Many tables in the R/3 System are linked to each other using foreign key relationships. Some of these dependencies form tree-like hierarchical structures. Logical databases read data from database tables that are part of these structures.
Tasks of Logical Databases
As well as allowing you to read data from the database, logical databases also allow you to program other tasks centrally, making your application programs less complicated. They can be used for the following tasks:
Reading the same data for several programs.
The individual programs do not then need to know the exact structure of the relevant database tables (and especially not their foreign key relationships). Instead, they can rely
on the logical database to read the database entries in the right order during the GET event.
Defining the same user interface for several programs.
Logical databases have a built-in selection screen. Therefore, all of the programs that use the logical database have the same user interface.
Central authorization checks
Authorization checks for central and sensitive data can be programmed centrally in the database to prevent them from being bypassed by simple application programs.
Improving performance
If you want to improve response times, logical databases permit you to take a number of measures to achieve this (for example, using joins instead of nested SELECT statements). These become immediately effective in all of the application programs concerned and save you from having to modify their source code.
Structure of Logical Databases
A logical database is made up of three components.
They are:
Structure
The structure defines the data view of the logical database. It determines the structure of the other components and the behavior of the logical database at runtime. The order in
which data is made available to the user depends on the hierarchical structure of the logical database concerned.
Selections
The selections define a selection screen, which forms the user interface of the executable programs that use the logical database. Its layout is usually determined by the structure. You can adapt the selections to your own requirements and also add new ones. When you link a logical database to an executable program, the selections of the logical database become part of the standard selection screen of the program (screen number 1000). If you call a logical database using the function module LDB_PROCESS, the selections are filled using interface parameters.
Database program
The database program contains the ABAP statements used to read the data and pass it to the user of the logical database. The structure of the database program is a collection of special subroutines. It is determined by the structure and the selections. You can adapt the database program to your own requirements and also extend it.
Example
Suppose that in the logical database structure, LFB1 is a branch of LFA1, and that the following selection criteria are defined in the selection include:
SELECT-OPTIONS: SLIFNR FOR LFA1-LIFNR,
SBUKRS FOR LFB1-BUKRS.
A section of the database program would then read:
FORM PUT_LFA1.
SELECT * FROM LFA1
WHERE LIFNR IN SLIFNR.
PUT LFA1.
ENDSELECT.
ENDFORM.
FORM PUT_LFB1.
SELECT * FROM LFB1
WHERE LIFNR = LFA1-LIFNR.
AND BUKRS IN SBUKRS.
PUT LFB1.
ENDSELECT.
ENDFORM.
An executable program (report) linked to the logical database could contain the lines:
GET LFA1.
WRITE LFA1-LIFNR.
GET LFB1.
WRITE LFB1-BUKRS.
In this example, the runtime environment calls the routine PUT_LFA1 after the event START-OF-SELECTION. The event GET LFA1 is triggered by the statement PUT LFA1. Once the corresponding event block in the program is complete, PUT LFA1 branches to the subroutine PUT_LFB1. From this subroutine, the event GET LFB1 is triggered in the application program. If LFB1 is the last node to be read, processing
resumes with the SELECT loop in PUT_LFB1. Otherwise, the program flow moves to the subroutine PUT_<node> of the next node. At the end of the SELECT loop of the last node, processing resumes in the SELECT loop of the node at the next level up. The example of programming using nested SELECT loops is only used to make the program flow clearer. In a real logical database, you would avoid doing this in order
to minimize the number of database accesses.
Regards,
Phani,
POINTS IF HELPFUL.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.