DE19936604C1 - Memory access to memory device with directory structure - Google Patents

Abstract

The object hierarchy is represented by a directory individual scheme (SK) in an access element (ZE) which control memory access of the computer application (DB-A) to the directory. The scheme is extended by at least one freely configurable object (EXT:FindExtendion). On access to the free configurable object and converter function (FindExtendsion) to control memory access, is carrier out. The access element defines fields (F) using objects (OC) defined in the scheme and using attributes (sn,gn,or,tel,tin) assigned to objects in the directory (DIR). The defined fields are combined in the access unit to a table structure (T) needed by the application (DB-A) for the memory access.

Description

The invention relates to a method and an arrangement for an application's memory access to an ob directory hierarchy, especially about a so-called ODBC (Open DataBase Connectivity) and one so-called LDAP (Light Weight Directory Access Protocol) Driver.

A memory access to a database from a database running on a data processing device application under the operating system 'Microsoft Windows' er usually follows using a so-called ODBC driver (Open DataBase Connectivity). This ODBC software interface controls the bidirectional data exchange between the database application and the database. The ODBC-Soft The goods interface realizes database access a so-called relational database. Relational database Ken have a table structure, so that the database in Fields that can be addressed using columns and rows is. An example of a relational database with a Such a table structure is the well-known database 'Mi crosoft Access'.

Furthermore, for example, from the German Offenle supply document DE 195 41 315 A1 with a data processing device connected communication system known where when an access is run on the communication system the application to one in the data processing device stored relational database via such an ODBC Software interface is done.

For access to a database with a directory structure - often referred to in the literature as a directory -  is another software interface for implementing the ODBC protocol required. This implementation takes place, for example wise using a so-called LDAP driver (Light weight Directory Access Protocol), which is used to access an e ne table structure defined ODBC protocol in the for ei access to a directory defined LDAP protocol changes.

From European patent application EP 0 955 761 A1 for example a, e.g. B. in a data processing facility device implemented mechanism for access to a Directory known in which access by the LDAP-Pro tooll is controlled.

The directory usually has a directory hierarchy consisting of individual objects and sub-objects, so that a tree structure, the so-called directory tree ent stands. Through a combination of ODBC and LDAP drivers follows a clear assignment of the objects and of the ob Attributes of the directory assigned to fields in fields a table for the database application. Here, the Objects and attributes of the directory after a fixed before given procedures to the individual fields of the table arranges.

In cases where the objects and objects are clearly assigned Attributes of the directory on a table structure - at for example with customer-specific directories - not is possible, is a development of special, on the ODBC- and the LDAP protocol of additional modules for the LDAP Driver necessary. The development of these additional modules is however, involves considerable effort.

The present invention is based on the object To specify methods and an arrangement of the type specified by which the Auf wall for such memory access to a directory redu can be decorated.  

This object is achieved according to the invention with the Features of claims 1 and 8 respectively.

A major advantage of the method according to the invention or the arrangement according to the invention is that by the extension of the object structure of the directory for the database application mapping schemes by at least represent a freely configurable, an additional function quasi-object the data readable from the directory easily the results of the additional function is expandable.

Another advantage of the invention is that the in add-on that can be implemented in any programming language functions on standard ODBC and of the LDAP driver so that the implementation  wall for these additional functions, in contrast to the addition modules for the LDAP driver, is low.

Advantageous developments of the invention are in the Un claims specified.

An embodiment of the invention will follow hand of the drawing explained in more detail.

Show:

FIG. 1 is a structural diagram schematically showing the essential for a read access of a database application on a database function units;

Fig. 2 is a structural diagram schematically showing egg ner for read access by the database table structure required appli cation;

Fig. 3 is a structural diagram schematically illustrating the wesentli chen for a read access to a directory functional units of an inventive arrangement;

Fig. 4 is a flow diagram illustrating the processes involved in a read access to the directory essential process steps.

Fig. 1 shows a structure diagram with the essential and necessary for a read access of a database application DB-A to differently structured databases functional units. In the case of the databases, a distinction is made between relational databases, that is, databases that are subdivided according to a table structure, and databases, that is, databases that are subdivided according to a tree structure. For read access to a database, the database application DB-A is connected to an ODBC manager ODBC-M (Open DataBase Connectivity) that controls the read access, whereby the database application DB-A provides the instructions necessary for read access by means of so-called SQL requests (Structured Query Language) to the ODBC manager ODBC-M. SQL is a database query language specially developed for queries from relational databases. The ODBC manager ODBC-M converts the received SQL queries into corresponding ODBC messages and forwards them depending on the type of the addressed database - relational database or directory - to different driver units that carry out read access.

If there is read access to a relational database DB1, DB2,. . ., DBn, the ODBC manager directs the appropriate for access to a table structure trained ODBC Queries to an ODBC driver ODBC-T1, ODBC-T2,. . ., ODBC-T3 continue reading out without further conversions leads and the results obtained to the database application DB-A passes. An example of such a relational Database DB1, DB2,. . ., DBn is the well-known database 'Micro soft access'. On the other hand, if the read access is to a Ver DIR, the ODBC manager directs the appropriate ODBC queries to one for read access to the ver DIR specially designed, so-called LDAP Driver LDAP-T (Light weight Directory Access Protocol) white ter. The LDAP driver LDAP-T converts those for access on a table structure trained ODBC queries trained for access to a directory DIR LDAP queries and performs read access to the directory nis YOU. The data determined are then processed by the LDAP driver LDAP-T inserted in a table structure and on hand over the database application DB-A.

For an expansion of the functional scope of the LDAP driver LDAP-T is this with egg in the present exemplary embodiment ner specific expansion unit KSE connected. The ODBC Manager, the LDAP driver and the expansion unit KSE are summarized as an access unit ZE for the Ver drawing DIR.  

Read access to a 'Corporate Di rectory 'based on an electronic phone book ap application as a database application DB-A. A case game for such a phone book application is electronic phone book DS-Win V2.0 under the operating sys Microsoft Windows.

Fig. 2 shows a structure diagram of a table structure required for read access of the telephone book application by means of an SQL query. The figure shows a table 'Participant' with the attributes assigned to a participant surname, first name, organization Org, telephone number TelNum and in a vertical telephone number InvTelNum. The inverted telephone number InvTelNum is usually saved without the leading zeros and is used to identify a calling subscriber when a call arrives at the telephone book application. Depending on the local distance of the calling subscriber, the number received as part of a call setup on the telephone book application has a plurality of leading zeros. If the calling subscriber is located in another region in Germany, for example, the received number usually has a leading zero. If, on the other hand, the calling subscriber is abroad, the received number usually has two leading zeros. For a unique identification of the calling subscriber, the received phone number is mirrored by the phone book application and the subscriber is clearly identified by comparing the last digits of the inverted received phone number with the inverted telephone number InvTelNum stored in the database. An example is a data record of a participant with the last name last name = Spangehl, the first name first name = Peter, the organization Org = ICN TE of the telephone number TelNum = 00498972231950 and the inverted telephone number InvTelNum = 059132279894.

For read access based on the phone book application tion on the directory DIR using the access unit ZE it is necessary that the tree structure of the directory DIR known in the access unit ZE and to those for reading reached through the phone book application necessary tables structure can be mapped.

Fig. 3 shows a structural diagram of the functional units of the access unit ZE which are essential for read access to the directory DIR. For this, a section of the directory tree VB of the directory DIR is shown. The nodes of the directory tree VB are often referred to in the literature as objects, each of which a specific object class OC is assigned. The origin of the directory tree VB is usually identified by the object class OC = Root. Properties assigned to objects are often referred to in the literature as attributes. In the present exemplary embodiment, an object with the object class OC = company is shown for the directory tree VB, to which, in turn, several sub-objects with the object class OC = person are assigned. The sub-objects with the object class OC = Person are assigned attributes sn (corresponds to the last name), gn (corresponds to the first name), or (corresponds to the organization) and tel (corresponds to the telephone number). Two objects of the object class OC = Person are exemplarily shown with the attributes sn = Spangehl, gn = Peter, or = ICN TE, tel = 00498972231950 and sn = Maier, gn = Daniel, or = ZT PA, tel = 00498963682308.

To map the directory tree VB of the directory DIR to the table structure required for read access by the telephone book application using an SQL query (see FIG. 2), three different configurations are available in the LDAP driver LDAP-T of the access unit ZE submits.

In a first step, the object hierarchy of the directory tree VB is mapped in a schema configuration SK. The schema configuration SK predetermined by the directory tree is expanded according to the invention by at least one quasi-object. In the present exemplary embodiment, a quasi-object Ext: FindExtension is shown, the function of which is explained in more detail with reference to FIG. 4. Marking the object with the prefix 'Ext:' makes it clear that this object cannot be assigned to a direct object in the directory tree VB in the schema configuration SK, but that the LDAP driver LDAP-T can access the directory DIR via an additional function stored in the expansion unit KSE - in the present exemplary embodiment via the additional function FindExtension.

In a second step, FK fields F are defined in a field configuration in the LDAP driver LDAP-T. The field definition takes place, for example, by specifying a field name, the length of the field to be defined, the type of the field to be defined, the object class OC of the associated object in the directory tree VB and the attribute assigned to this object. As an example, a table F is defined for the last name and the first name of a subscriber, analogously to the table structure necessary for read access of the telephone book application by means of an SQL query, as described with reference to FIG. 2. Both fields F each have a length of 50 characters and a field type 'string'. Through the specified object class OC = person and the attribute sn or gn, all fields of the directory tree VB with the object class OC = person and the attribute sn or gn are assigned to these fields F. The wei direct is a field F defined analogously to the be described with reference to FIG. 2 registered for a read access the phonebook application using an SQL query required table structure for the inverted phone number of a subscriber which has a length of 20 characters and a field type Has 'integer'. Since the objects of the directory DIR are not assigned an attribute for an inverted telephone number of a subscriber, a direct assignment of an object and an attribute of the directory DIR to this field F is not possible in this case. The quasi-object class OC = Ext: FindExtension specified for this field F and the attribute tin define, according to the invention, access by the LDAP driver LDAP-T to the additional function FindExtension stored in the expansion unit KSE, which means read access in this case controls on the directory DIR.

In a third step, any fields F defined in the field configuration can be combined in a table configuration TK to form the table structure T required for read access by the telephone book application by means of an SQL query. As an example, similar to the table structure T described with reference to FIG. 2, a table 'subscriber' is shown. The table structure T for transfer to the telephone book application is defined by specifying the attribute assigned to the respective field name, the field type and the object class OC.

Fig. 4 now shows a flowchart to illustrate the essential procedural steps for a read access to the directory DIR starting from the database application DB-A. In the case of an incoming call to the database application DB-A - in the present exemplary embodiment to the telephone book application - a call number TelNum = 00498972231950, which is also transmitted as part of the call set-up, is mirrored for identification of the calling subscriber. The DB-A database application then sends an SQL query:

SELECT * FROM participant WHERE InvTelNum = 059132279894

to the ODBC manager ODBC-M. Through the SQL query the those data that are in the fictitious table "participants" of the inverted telephone number InvTelNum = 059132279894 net are to be passed to the database application DB-A.

In a next step, the ODBC manager ODBC-M checks whether the addressed database is a directory DIR. Is if this is not the case, the ODBC manager ODBC-M sends one the ODBC query corresponding to the SQL query received ODBC driver ODBC-T1, ODBC-T2,. . ., ODBC-Tn, the data from the corresponding relational database DB1, DB2,. . ., DBn reads out and transfers it to the database application DB-A. Is the addressed database - as in the present execution game - a directory DIR, reports the ODBC manager ODBC-M an ODBC- corresponding to the SQL query received Query to the LDAP driver LDAP-T which the inverted th phone number InvTelNum assigned object class OC er averages. If the determined object class OC is not equal to Ob Object class OC = Ext: FindExtension is read-only the DIR directory in a conventional manner over existing ones Standard modules of the LDAP driver LDAP-T. Is against - as in present embodiment - the determined object class se OC is the same as the object class OC = Ext: FindExtension the LDAP driver LDAP-T in the expansion unit KSE saved additional function FindExtension with the parameter InvTelNum = 059132279894. The additional function FindExtensi on reflects the inverted telephone number InvTel- Num = 059132279894 and initiates read access to the Directory DIR with the inverted tele now mirrored Phone number that corresponds to the phone number TelNum = 498972231950 speaks.

The associated data sn = determined in the directory DIR Spangehl, gn = Peter, or = ICN TE and tel = 00498972231950 and the inverted phone number with the attribute tin = 059132279894 are complied with by the LDAP driver LDAP-T  accordingly entered in the table "Participants" hand over the database application DB-A.

By expanding the, the object structure of the directory nisse DIR for the DB-A mapping application makonfiguration SK by at least one freely configurable, a quasiob representing an additional function FindExtension jekt can read the amount of data that can be read from the DIR directory in a simple way around the results of the additional function, e.g. B. the inverted telephone number InvTelNum can be expanded.

Another advantage of the invention is that the in add-on that can be implemented in any programming language functions on standard ODBC and of the LDAP driver LDAB-T so that the implementation effort for these additional functions, in contrast to Development of new add-on modules for the LDAP driver LDAP-T, is relatively small.

Claims (11)

1. Method for memory access of an application (DB-A) to a directory (DIR) having an object hierarchy,
in which the object hierarchy is represented by means of a directory-specific schema (SK) in an access unit (ZE) controlling the memory access of the computer application (DB-A) to the directory (DIR),
in which the scheme (SK) is expanded by at least one freely configurable object (Ext: FindExtension), and
in which when the freely configurable object (Ext: FindExtension) is accessed, a conversion function (FindExtension) that controls memory access is carried out. 2. The method according to claim 1, characterized, that in the access unit (ZE) based on the defi in the schema nated objects (OC) and based on the objects (OC) in Ver Attributes assigned to the drawing (DIR) (sn, gn, or, tel, tin) Fields (F) can be defined. 3. The method according to claim 2, characterized, that the defined fields (F) in the access unit (ZE) too one for memory access by the application (DB-A) necessary table structure (T) can be summarized. 4. The method according to claim 3, characterized, that with a memory access to a field (F) of the tables structure (T) by the access unit (ZE) the associated Object (OC) in the directory (DIR) is determined, and that in cases where the identified object (OC) is free is configurable object (Ext: FindExtension), the converter tation function (FindExtension) is called.   5. The method according to claim 4, characterized, that through the conversion function (FindExtension) of the Memory access to the directory (DIR) executed and the read data to the application (DB-A) the. 6. The method according to any one of the preceding claims, characterized, that the memory access to the directory (DIR) by the Access unit (ZE) via an ODBC (Open DataBase Connecti vity) interface and an LDAP (Light Weight Directory Access Protocol) interface takes place. 7. The method according to any one of the preceding claims, characterized, that the application (DB-A) as one under the operating system Microsoft Windows running database application realized becomes. 8. Arrangement for memory access of an application (DB-A) to a directory (DIR) having an object hierarchy, with an access unit (ZE) controlling the memory access of the computer application (DB-A) to the directory (DIR),

• - In which a directory-specific schema configuration (SK) depicting the object hierarchy of the directory (DIR) is arranged, the schema configuration (SK) being expanded by at least one freely configurable object (ext: FindExtension), and
• - In which an expansion unit (KSE) for storing at least one conversion function (FindExtension) is arranged, on the basis of which access to the freely configurable object (Ext: FindExtension) is used to access the memory.

9. Arrangement according to claim 8, characterized, that a field configuration (FK) in the access unit (ZE) for storage of objects (OC) and ob Attributes assigned to objects (OC) of the directory (DIR) (sn, gn, or, tel, tin) defined fields (F) is arranged. 10. Arrangement according to claim 9, characterized, that in the access unit (ZE) a table configuration (TK) for storing each by at least one field (F) defined table structures (T) is arranged. 11. Arrangement according to one of claims 8 to 10, characterized, that the access unit (ZE) through an ODBC (Open DataBase Connectivity) unit and an LDAP (Light Weight Directory Access Protocol) unit is realized.