Database management system.

In a real-time system, in particular a switching system, large amounts of data need to be managed, which are sometimes in a complex relationship with each other. Access to this data must in real time, as quickly and safely (consistent) are performed.

In previously known switching systems, the various user systems themselves are responsible for the data modules, addressing modes and access procedures. This leads to each user system individual occurrences in the implementation of similar functions. In addition, the lack of uniform structure complicates the insight and support external object-oriented accesses (CMISE).

Data consistency is also been ensured at the user level. This has a coarse granularity with respect to the access control result. Furthermore, limit the methods for Konsistenzsichrung a system availability. In addition, the Konsistenzsicheruung is complicated by the possibility of a direct data access. Access conflicts are characterized, for example, difficult to see.

The invention has for its object to provide a data management system that accesses a user on the user data independently controls and compared with user-individual characteristics of the user data is flexible.

This object is solved by the features of claim 1.

By (central and local) access control system, a user system the data management system of access control tasks (eg control of data consistency in access sequences, control access conflicts with parallel access of several users) is relieved, thereby increasing its availability accordingly.

The exclusive communication of the user with the data management system via access procedures that are exported from the data management system, a good data encapsulation with respect to the user is ensured. This access conflicts are easily recognizable, which are also covered by the access control system.

Finally, the user is largely removed by the indirect data access of data management capabilities.

By instantiating the generic modules, that is, by imparting of user-specific data types and parameters, it is possible from the generic modules easily application-specific data modules (user modules) to generate that respect. The complex functionality (eg concerning. Data consistency assurance) is guaranteed to work flawlessly, because automatically the entire functionality of zugrungeliegenden generic module will also be taken over by the instantiation.

Since identical functions of different application modules are thus only once, namely in the common generic module, implemented (generic functions) must, the implementation, testing, and maintenance is always limited to the generic module.

Moreover, to facilitate the uniform structures of the generic modules external object-oriented accesses (CMISE).

An embodiment of the invention is defined in claim 2nd By the introduction of user access procedures, which are composed of standard access procedures, the independence of the application of the logical data structures of the application is achieved.

In an application access procedure (View) access is performed on one or more object classes. An object class is managed in a user module. An application access procedure contains as parameters the desired attributes of the affected from the access object classes, where it is in these parameters return parameters that are returned to the application after execution of the user access procedure. By user access procedure of application is thus provided an own perspective on the stored application data. Changes in the logical data structures consequently have no impact on the applications.

In the following an embodiment of the invention will be explained in reference to the drawing.

In the drawing, the arrows between the blocks represent a functional relationship (eg a procedure call, the head of an arrow on the called procedure shows).

Fig. 1 and Fig. 2 show the structure of the data management system of the invention EDB, to access the various applications APPL.

The data management system consists of two layers, namely an application-specific system layer, which is hereinafter referred to as application-specific data base ADB, and an application-independent system layer, which is referred to hereinafter as generic data base GDB.

The generic database GDB comprises central and local functions, the central functions in a central control system CU and the local functions are realized in generic modules GM.

The central control system CU contains a central access control system CTCC which hits (individual accesses or access sequences) centrally controls general access algorithms ALG, a system NVSI which realizes access to a background memory for backup of user data, and a central distribution system DDFC that distributing updated user data to the various processors of the real-time system is used. Optionally, a data pool VLP for managing data with variable length are added without existing functions influence.

A generic module GM provides a definition module represents (template) for describing a data container, the data structures to store the user data and the need to access structures, ie addressing methods and elementary access procedures contains. Moreover, the generic modules contain additional structures to support the central functional system, ie structures to support the coordination and consistency of assurance (local access control system CTCL), and structures to support the distribution of user data on different platforms (local data distribution system DDFL). The description of these structures in the generic module is carried out in an independent manner by the user, ie. In an independent from the data layout of the data structures way

Different types of generic modules are produced by combining components (eg local access control system CTCL, local distribution system DDFL and necessary for this additional data definitions, different addressing schemes). The variations are determined by the requirements arising from the data modeling of the corresponding application.

Each generic module contains a set of elementary access procedures relating to the control of a single access. This set includes a procedure GET for reading a data element (attribute), a procedure SET for modifying a data element, and procedures CREATE and DELETE for creating or deleting data elements of the user. Access to the data of a user is only through this special access procedures possible (encapsulation). Data with appropriate Persistenzanforderung be saved in the core image format on a background memory. This ensures that after a restart of the switching computer with the associated charging current data will be as soon as possible available.

The application-specific database ADB comprises views and module instances, the module instances generated by instantiation of the generic modules. By instantiating the generic module, user-specific data types and parameters are imprinted. A module instance is therefore referred to below as the user-specific data module or application module

The views form the interface to the current application APPL. They represent a logical picture of the conceptual data model of the application.

The access control system controls the access of users to the data management system EDB and thereby ensures that an update operation transfers the data management system of a consistent initial state to a consistent end state. To ensure this consistency, the access control system access sequences (transactions or reading sequences) in a holistic (atomic) treated way, ie a transaction example. Either holistically performed or rejected as a whole.

Moreover, coordinated the access control system to simultaneously access of parallel access sequences.

The access control system includes CTCC which performs for the user such control orders (eg START_TA, DO_TA, ABORT_TA) relating to the control of an access sequence in its entirety.

The central data pool VLP manages semi-permanent and transient data of variable length. It includes both the data and a set of primitives to save the data he housed and manipulate.

All managed by the central data pool data is encapsulated by the data pool. All access to this information so they can only be made via the aforementioned primitive. The module instances mentioned can reserve the data pool one block of any length, each reserved data block is identified by an associated at its reservation logical key.

The generic access algorithms ALG comprise functions that are common to the generic modules, one being algorithms for logical organization of data storage (eg, linked list, binary tree), for other mechanisms for the physical storage of the data, ie data structure independent paths through data base internal administrative or access structures. The generic access algorithms are called exclusively from the generic modules.

The DDFC controls the transfer of user data from one platform (processor) to other platforms (processors) while ensuring data consistency between different platforms (processors). The DDFC is called by a DDFL a GMI effort.

A generic module is used, as already mentioned, as a template for a data container that describes a specific data structure (for example, a sorted list, a binary tree), and for this data structure specific access algorithms in an application independent fashion, ie, in a from the data layout independent manner. A generic module comprises a set of elementary access procedures for data management system, which provides the application available, thereby realizing a read or write access to data included in the generic database GDB.

Due to the internal architecture of a generic module that distinguishes between data structure-specific parts and general parts of data access and data handling, general functions can be declared as generic algorithms ALG, which can be used by any generic module, since the in the central module CM contained generic database. Moreover, the generic modules use other general functions that are provided by the central access control system CTCC and the data pool VLP.

A primary purpose, which is pursued by the introduction of generic modules is the reusability and Wiederersetzbarkeit software. The generic modules form a library (Library), can be generated from the application-specific data modules by instantiation, ie. By replacing general data layout information (placeholders in CHILL eg ANY_ASSIGN) by specific layout information

By the insertion of the application procedure VIEW layer between the application and the application module to reach the independence of the application of the logical data structures. By means of a user access procedure an access is performed on one or more object classes, where a user module manages each object class. A user access procedure contains as parameters the desired attributes of the affected from the access object classes, where it is in these parameters return parameters that are returned to the application after execution of application procedure. By user access procedure of application is thus provided an own perspective on the stored application data. Changes in the logical data structures consequently have no impact on the applications.

An application or a user uses to manage its user data exclusively the user access procedures VIEW. a corresponding sequence of user procedure calls through commands to the central access control system is characterized as a transaction for the consistent amendment of dependent data. The implementation of the transaction and store the data on the background storage and distribution of data occurs in an independent manner by the data management system and is therefore completely invisible to the user.

In the following, the flow of a transaction will be explained in more detail.

Fig. 3 shows the phases of a transaction. A transaction contains at least two phases, namely a preparatory phase, which is controlled by the user, and an activation phase, which is controlled by the central access control system.

In the preparatory phase, the transaction is built up step by step, by successively the access procedures (SET, GET, etc.) must be called for individual accesses by the user. Within a transaction can be initiated by calling the appropriate access procedures in principle any number of individual requests.

The preparation phase is started by the procedure START_TA and completed through the procedure DO_TA. The procedure START_TA assigns the transaction to a transaction identifier TA_ID and passes it to the user. The user uses this TA_ID then used as input parameters when calling the access procedures for individual accesses.

In the preparatory phase the calls of access procedures are recorded and prepared for any changes to data affected by access. In the preparatory phase, the user has the option to cancel the transaction by calling the procedure ABORT_TA.

By calling the procedure DO_TA the activation phase is started simultaneously, which is solely controlled by the access control system and therefore Expires regardless of user calls. In the activation phase, therefore, no further calls for individual accesses can be considered.

In the preparatory phase, the coordination of a transaction is carried out, ie all collision cases with other parallel transactions are identified and coordinated. The coordination is carried out such that those transactions that were started earlier, allowed to continue, whereas other parallel transactions are rejected by a corresponding negative feedback is returned to the user. Since all collision cases are consequently resolved in the preparatory phase, transactions can be carried out during the activation phase independently.

Fig. Figure 4 shows the structure of the central access control system CTCC. The central access control system CTCC comprises a transaction management system TMS, a generations management system GMS, a resource management system RMS and a collision management system CMS.

The transaction management system TMS controls the transaction-oriented access to the data objects of the data management system.

The generations management system GMS manages the data generations produced in transactions based on a assigned by the transaction management system during the activation phase of a transaction identifier generation GEN_ID. This management includes the Aufdatieren a data generation newly created, ie transferring the new data generation to their final storage locations in memory and / or on the disk. In addition, said management includes the control of read sequences (sequences of logically associated read accesses to the data objects of the data management system ).

This type of management makes it possible that a group of data objects in a consistent reading sequence (ie all read data objects belong to the same generation) can be read while in parallel takes place a transaction.

The resource management system RMS manages access control data structures that are used by the transaction management system and / or the generations management system for controlling access.

A TGSE is in the form of a SW-Soft, which includes a first output to the old image and a second output to the new image, making it possible to introduce the new image of DOs in parallel with the old image.

Every time a TA wants to bring a new image, a TGSE is the RMS requested and then pasted this from TMS in the access path.

The TGSE not only allows the parallel introduction of a new image, but has, since it is part of the access path, an additional protective mechanism in the form of a lock indicator, via the transaction can close access to the data object DO and thus unauthorized access by working in parallel transactions on to prevent the new images.

The collision management system CMS coordinate write access to one and the same data object, which are triggered by parallel transactions and prevents the oldest data generation is deleted, while a reading sequence will perform a read access to data objects of the data generation.

The following are the summarized in a transaction or a reading sequence individual actions or more specifically the procedures for implementing this single action with reference to FIGS. 5, 6 and 7 will be explained.

Fig. 5 shows a procedure GET, which is contained in a user card and a single read action is carried out which can be accessed both in the context of a transaction, as well as part of a reading sequence. Input parameters of the GET procedure is an identifier of the read action and a logical key that performs the data access path to the data object. If the identifier of the transaction is a transaction identifier TA_ID if the procedure GET is used within a transaction. In the other case, namely if the procedure GET is used within a reading sequence, it concerns with the identifier to an identifier generation GEN_ID. Output parameters of the procedure GET are the data object and a message parameter for the return of check messages.

First, by running on the logical Keys on lists of data access path.

Fig. Figure 6 shows the exemplary structure of a data access path, comprising a plurality of lists, and is stored in the user data module independent VLP. The data access path includes a data block list UBL whose list items represent pointers to data blocks UB, and within a data block UB an object class list OCL and data object lists DOL. The logical key comprises indexes of the said lists, namely the indexes UBL_IX, OCL_IX and DOL_IX by which finally the pointer can be found on a data object or an access control data structure TGSE.

First, the procedure GET runs through the data access path, by calling the procedure RD_BLK implemented in user-independent central data pool VLP. This procedure return value of the physical pointer to a data object list DOL. In the case of a transaction, this pointer is used only in the following to the preparatory phase of the transaction activation phase to execute the actual access.

the procedure ACCESS_OCI with the parameters "pointer to the data object list DOL" and "DOL_IX" is called Next. This procedure examines inter alia the header of the DOL and determines whether it is the parameter passed "DOL_IX" is a valid index.

If the index DOL_IX valid, then the index DOL_IX corresponding list box the list DOL is analyzed. It is examined whether it is stored in the access field (lock box) in the list box identifier ID is a transaction identifier or a generation identifier. This is illustrated in Fig. 5 by a branch block.

If there is a generation identifier is EVAL_GENTREE the evaluated based on the procedure at the data access path subsequent generation tree and then returned the generation identifier corresponding physical pointer to the data object.

If it is a transaction identifier in the identifier ID, the procedure is called ALLOC_TGSE that prepares a subsequent writing action by a procedure SET, and the data object closed to other transactions.

A user-specific data module GMI comprises furthermore a procedure SET, which modifies a data object within a transaction. Input parameters of this procedure are a transaction identifier TA_ID, a logical key for guiding through the data access path and a pointer to the new acquiring data and a longitude of the new data. Output parameter is a parameter for feedback.

7 shows a procedure SET, like the procedure GET accessing the data, which is performed using the procedures and RD_BLK ACCESS_OCI comprises. After have performed the data access procedure SET contained in CTCC procedure ALLOC_TGSE calls requesting a new access control data structure TGSE and the new data and the new data object is copied into the course structure. If the procedure SET was prepared by the procedure GET, eliminates the said assignment of a new access control data structure.

The user-specific data modules further comprise a procedure CREATE that extends a feature class to a data object and a procedure DELETE, which reduces an object class to a data object. These two procedures are for the description of the invention without meaning and are therefore not explained in detail.