EP0969391A1 - Method for optimization of database accesses - Google Patents

Method for optimization of database accesses Download PDF

Info

Publication number
EP0969391A1
EP0969391A1 EP99401593A EP99401593A EP0969391A1 EP 0969391 A1 EP0969391 A1 EP 0969391A1 EP 99401593 A EP99401593 A EP 99401593A EP 99401593 A EP99401593 A EP 99401593A EP 0969391 A1 EP0969391 A1 EP 0969391A1
Authority
EP
European Patent Office
Prior art keywords
attributes
objects
class
cmis
optimized
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP99401593A
Other languages
German (de)
French (fr)
Inventor
Jean-Luc Richard
Alain Grignac
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull SAS
Original Assignee
Bull SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull SAS filed Critical Bull SAS
Publication of EP0969391A1 publication Critical patent/EP0969391A1/en
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/289—Object oriented databases
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99932—Access augmentation or optimizing
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99933—Query processing, i.e. searching
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99933—Query processing, i.e. searching
    • Y10S707/99934—Query formulation, input preparation, or translation

Definitions

  • the present invention relates to a method for optimizing access to a database.
  • the information access services of a MIB are based on the standard CMIS (Common Management Information Service recommendation ITU-T X.710), which describes the operations that can be performed on objects specified according to the standard G.D.M.O. (Guidelines for the Definition of Managed Objects, i.e. Guidelines for the definition of administered objects, ITU-T recommendation X.722).
  • CMIS Common Management Information Service recommendation
  • G.D.M.O. Guidelines for the Definition of Managed Objects, i.e. Guidelines for the definition of administered objects, ITU-T recommendation X.722).
  • the present invention uses the information management service in the CMIS standard. This service is attached to the CDSP (figure 4, 42) (CMIS Dispatcher Process) which is a CMIS packet exchange service between entities of the platform OpenMaster TM.
  • CDSP is a packet router for service administration information, i.e. a system for transferring data between two entities using the same protocol.
  • MIB Management Information Base
  • MIB administration information
  • the objects are themselves grouped into classes.
  • the object of a given class has a number of attributes and each instance objects has a name (DN). Addressing is by distinguished name DN (Distinguished Name). For example the DN of the object (51, figure 2) is "a / a / b".
  • Figure 4 shows the operation of a management service of information.
  • This service uses a two-level architecture.
  • the first level consists of a manager entity (4) playing a role administrator who must view and control resources, consult characteristics, etc.
  • the second level consists of agent entities (43a to 43c) distant or local which maintain the objects on which must apply the operations issued by the administrator level.
  • the goal of the agent is to maintain a model of the resource he manages, model documented and standardized in a MIB.
  • At least one agent is installed on each machine on the network and can control a set of resources local or remote under the direction of one or more directors.
  • An administrator communicates with each agent using a protocol standard management.
  • the OpenMaster TM administration system marketed by the company BULL includes one or more ISM Manager (Integrated System Management) administrators and several agents (ISM / Agent). In addition, other agents marketed by other companies can be controlled by the OpenMaster TM administrator via standard protocols.
  • the administrator-agent mechanism is based on an object model, in which the modeling of a constituted resource, for example, of system elements, software, states, users, etc., is based on an approach and a structuring in information objects of management.
  • the "real" equipment of a networked system (a computer, printer, circuit, etc.) are represented by objects abstracts organized in an administration information base (MIB, Management Information Base).
  • MIB administration information base
  • the characteristics of these objects name of a computer, characteristics of peripheral equipment, status of such equipment such as a printer, etc.
  • attributes Objects are called the attributes Objects.
  • MOCs Managed Object Classes
  • MOCs Managed Object Classes
  • MOCs define the information that the MIB will contain for each type of resource, i.e. which attributes the object will have. MOCs can be interpreted as part of the "scheme" of the MIB. Administrator registers MOC object class in the GDMO language and it declares among other things the classes and for each class, attribute list, naming links etc. This description is saved in a module for defining GDMO objects attached to the ISM administrator (41).
  • Each MOC is instantiated in several instances Managed Object Instances (MOIs) actual occurrences of this type of resource.
  • MOIs Managed Object Instances
  • the attributes of the object representing the printer are "printer status” and "user”.
  • a MOC object class "printer” (printers) can therefore be defined with the attributes "printer status” and "user”.
  • the object instances (MOls) of the "printer” class can be the following: ME MOC ATTRIBUTES (instance) Class printer status user Print 1 Printer activated no Print 2 Printer deactivated no Print 3 Printer activated Joe
  • the status of the Printer 1 resource is activated and without current user when instantiating the above example.
  • This example still includes the Imprim 2 and Imprim 3 instances.
  • ISM Monitor provided by the OpenMaster TM administration system (4) displays the MOls and their states.
  • ISM-Monitor (46) can display in tabular form the attributes of any ME: by example the attributes "printer status" and "current user” for a ANY of me from the "Printers" OMC.
  • the set of administered objects forms an information base administration (MIB).
  • MIB information base administration
  • An administration information base has a hierarchy strict tree structure, i.e. each object instance (MOI) has exactly one and only one ME higher.
  • the tree formed by the base MIB administration information is called "containment tree" (containment tree).
  • Instances of administered objects (MOIs) are named by their position in the capacity tree as follows:
  • Each MOI has a relative distinguished name (relative distinguished name, RDN) which differentiates MOls with the same unique MOI superior (father).
  • RDN relative distinguished name
  • One of the attributes of each managed object class (MOC) is chosen to specify the instance's RDN for a higher MOI given. This attribute called the naming attribute is identified in GDMO templates called naming links (name binding).
  • naming links name binding
  • An OMC can have multiple superior naming links potential, but each MOI will use only one of them.
  • Each ME also has a unique Full Distinguished Name for the entire MIB.
  • the global distinguished name (DN) of an object consists of his relative distinguished name (RDN) joined to the distinguished name (DN) of his superior that is, the distinguished name (DN) of an instance of administered objects (ME) contains its own relative distinguished name (RDN) plus names relative distinctive (RDNs) of all its superiors in the containment tree to the root.
  • the administration information base is used to establish other relationships between objects than the relationships made in the tree of capacity by distinguished name. These relationships are made using attributes relationship attributes. These attributes contain the name distinctive global DN (Distinguished Name) of other objects. They are used as references from one object to another.
  • CMIS-DB One of the local object administrators to the ISM-Manager administrator is called CMIS-DB. It is responsible for storing part of the local MIB. The persistence of these stored objects is ensured by ISAM files (Index Sequential Access Method).
  • ISAM Index Sequential Access Method
  • This technology which describes the article structures (records) is a method of accessing files structured in the form of articles cut from one or more indexes and data information.
  • the BOI base object instance makes it possible to identify an object in an administration information base (MIB) which is the starting point for an evaluation of the carried-filter pair in the object tree.
  • MIB administration information base
  • the scope selects a portion of the tree from this base object. For example, the scope "Whole subtree" allows you to select all the sub trees of a given object. Among all the objects in the scope, the objects selected are those for which the evaluation of the filter is true. The operation is performed on the objects actually selected.
  • the administrator sends an M-GET on objects and CMIS-DB reads and returns to the application the value of the attributes of the selected objects.
  • the CMIS-DB administrator To reach a base object instance (BOI), the CMIS-DB administrator must pass from parent object to child object until reaching the node of the base object.
  • This navigation operation can be long, if to move from one node to another, it is necessary to physically read all the threads of a node and among these choose the one with the right RDN, and so on .
  • the computer Once the computer has reached the base object instance, it must read the attributes of the base objects which correspond to the scope in order to be able to evaluate the filter in memory.
  • the generic condition of the storage of objects imposed by the old version of CMIS-DB is to physically read all the objects belonging to the selected scope before evaluating the filter in memory. When you have a lot of objects subordinate to an object, performance can be very poor.
  • CMIS-DB uses data structures making it possible to create generically on the physical disk of the system instances of any class of object of the MIB without first knowing the description according to GDMO.
  • CMIS-DB In the generic representation of CMIS-DB, the knowledge of the structure of the objects is obtained during CMIS M-CREATE operations of creation of instances, issued by client applications to the server CMIS-DB.
  • An object of the present invention is to provide a method for optimizing access to a database organized in trees, and more especially for an administration server managing a very large administration information base (MIB) and allowing to carry out complex operations on a very large number of objects while reducing the search times of the instances selected by the arguments of scope and filter of CMIS operations.
  • MIB administration information base
  • This object is achieved by the fact that the process for optimizing access to a database is characterized in that it allows client applications to ask the CMIS-DB server, by configuration online, to specialize generic representation for object classes for which access times must be optimized in order to reduce the search time for selected object instances, by the completion of a physical storage configuration step of a object class to optimize, which consists of creating an object instance the storage definition class (mocStorageDefinition) in which are declared the attribute or attributes of the class to be optimized which will be indexed during physical storage on disk.
  • micStorageDefinition storage definition class in which are declared the attribute or attributes of the class to be optimized which will be indexed during physical storage on disk.
  • the method comprises a second step of writing an ISAM file (Index Sequential Access Method, sequential access method by index) by managed object class (MOC) optimized, specific file with its own index structure containing the representation of all the instances of this MOC.
  • ISAM file Index Sequential Access Method, sequential access method by index
  • MOC managed object class
  • the method comprises a third step of analyzing the filters conveyed by the CMIS operations issued by users to identify, in a pre-filtering step, whether yes or no the evaluation of this filter can be done using one of the indexes positioned in the base.
  • the value of the physical indexes for index the attributes specified in the class object instance mocStorageDefinition corresponding to the MOC to be optimized includes the unique reference of the father instance node (fatherMOlnodeRef) of the instance of the object managed on 4 bytes long and the succession of attributes 1 to i necessary for the class of managed objects to be optimized.
  • the executor of requests based on administrative information determines the arguments of the physical read operation not allowing to re-read in the underlying base that the only subordinates who are indexed by the values of the attributes selected for pre-filtering.
  • the class of administered objects allows to specify a plurality of attributes indexable which will be physically stored in the index at the time of creation of the object.
  • the plurality of indexes described in the mocStorageDefinition administered object can be reorganized at any time moment by reassigning a different index level to one or more attributes or by activating or deactivating the indexes by modifying the object of class mocStorageDefinition.
  • a request executor module of the information management service CMIS-DB performs, after detection of a possibility of pre-filtering by knowing the mocStorage Definition of each optimized class, reading from the underlying database only objects in the scope that are indexed by attribute values selected for pre-filtering.
  • means are provided for allow the user to choose the attribute or group more discriminating e attribute by sorting the indexes in descending order defined.
  • the main idea of the invention is to use a mechanism indexing found in indexed files of type ISAM (Index Sequential Access Method, or in relational or object-oriented databases to be able to index certain object attributes.
  • ISAM Index Sequential Access Method
  • object databases relational data and ISAM technology Choosing ISAM files for the physical storage of a MIB is known in old versions a common service module for managing non-indexable information for CMISNI-DB database and is still used in the version current. But the same mechanism is applicable on other technologies databases such as DBMS (Database Management System Objects) and RDBMS. The process described therefore does not restrict the mechanism ISAM-only physical storage.
  • the articles (record) in an ISAM file are indexed.
  • For direct access to an article there are two possibilities: either give the article number, or do a search on one of the values which is declared as an index field in the article.
  • ISAM implements a algorithm which reduces the number of physical searches: "B + tree” form data structures which make it possible to accelerate physical research of chains (string) by key calculations and creation of intermediate tables. From a desired value, the "B + tree” allow quick access to find the fastest possible only the articles (record) which have this value in the index.
  • the computer can thus physically search the disk every items (record) that have a certain index value. This operation is more faster than reading all the articles one by one, testing in memory if the value read corresponds to the requested value.
  • CMIS-DB accepts to create objects without knowing their GDMO definition, representing them in the database generic way.
  • the present invention allows the user to index the instances of the managed object classes (MOI) that it interrogates the most often.
  • the administrator must create an instance of objects particular class called "mocStorageDefinition" in which the administrator describes the definition of the index structure which will be applied to managed object instances of the class (MOC) to optimize.
  • MocStorageDefinition an instance objects of class mocStorageDefinition (15) for object class Z (5a, 5b) and another instance for the object class Y (4a, 4b, 4c).
  • a file ISAM is created in which its key is cut in half, one key being for ISAM a single field identified in the article (record) of the file.
  • the first one part contains the reference of the father of the instance and is used by the engine and the second part contains the attribute value (s) indexed to this instance.
  • the present invention therefore allows the user to define a indexed physical representation different from generic representation CMIS-DB, in order to optimize the most frequent accesses.
  • the user can declare the object classes managed (MOC) which he wants to optimize consultations. Optimization consists in choosing in a given managed object class (MOC), the or the attributes intended to be used as a filtering criterion in the searches that the user wants to optimize. These attributes will be named "indexed attributes". From this or these chosen attributes, the CMIS-DB module deduct one or more new indexes to introduce into the representation instances of this managed object class (MOC).
  • a class of objects managed (MOC) is therefore represented by a type of node (5, 4; figure 1) physically different from the generic node (2, 3; figure 1) and specific to each of the optimized managed object classes (MOC).
  • CMIS-DB is considered by applications PoenMaster TM as an object manager that stores and manages part of the MIB in a database.
  • the CMIS-DB server interacts with the CDSP (33, fig. 3) through a interface (32). Interactions between all administrator components ISM are performed using CMIS messages routed by CDSP.
  • FIG. 3 represents the architecture of CMIS-DB according to the invention which includes a CMIS operations handler (31) dialoguing according to the protocol of the (CDSP) (33) with the infrastructure of communication, a programmable user extension module coded in SML (SML MIB toolkit) (34), a module (37) divided into a sub-module query executor (MIB queries performer), a submodule of navigation, range evaluation and filter, one optimizer sub-module per prefiltering (372), a translator from global to local form (38), a import / export module (39), a cache of the capacity tree cache of containment tree (40), a cache of instances of object management (cache of MOls) (49), a memory access module physical (50) which interfaces the server of the underlying database (51), a physical access transaction administrator module (storage transaction manager) (48) and a physical disk (47).
  • CMIS operations handler (31) dialoguing according to the protocol of the (CDSP) (33) with the infrastructure of communication
  • the development program kit (SML MIB toolkit) (34) loads any SML (Systems Management Language) extensions (341) of the user and provides primitives for access to the database in SML Administration Information (MIB) managed by the CMIS-DB service.
  • SML MIB toolkit assesses the pre-conditions and post-conditions set by the user, when each operation based on administrative information (MIB) and executes the SML extensions that are triggered on these conditions.
  • MIB administration information base
  • the mode of operation of the request executor (37) of the administration information base (MIB query performer) depends on arguments of the operations scope and "filter" of the operation.
  • the executor of information base queries administration (MIB query performer) (37) iterates through the list of all threads to read the object management instances (MOI) corresponding to the scope (scope) .
  • MOI object management instances
  • the decision whether a pre-screening can be performed or not depends on the analysis of the filter structure.
  • the optimized search for MOIs selected by a filter consists of do not physically read all MOls belonging to the scope CMIS to apply the filter evaluation to them but to use when it is possible, the indexes that are positioned on their so-called optimized MOCs, so to read only a subset of these MOls instances.
  • This last operation is called “preselection or prefiltering” it does not replace the filter evaluation step on each MOI raised in memory which takes place systematically in both cases.
  • Pre-filtering by indexes can therefore raise MOls which in the end will be rejected by the evaluation stage of the CMIS filter, but it should not forget to read only one of the MOls in the scope that check the filter.
  • CMIS filters must comply with a structure defined to be recognized by the MOls search optimizer that these filters select.
  • scope used in the has no influence on the rules for deciding whether a first selection by indexes is more optimal than a physical reading of all MOls belonging to the scope.
  • a CMIS filter recognized by the optimizer must be an expression logic that selects only MOls of the same class. This class which must be one of the optimized MOCs declared to the CMIS-DB module.
  • the order introduced between the different items does not not reflect a syntax order in the expression of the CMIS filter which can be any, but rather the physical order of the attributes as they exist in the indexes of the optimized OMC.
  • the request executor (37) of the administration information base reads in the underlying base the only subordinates that are indexed by values attributes selected for pre-filtering. Then the requester (37) of the administration information base (MIB query performer) evaluates the filter on each previously selected instance. If the assessment is positive, it executes the operation on the logical representation of the base Administration Information (MIB) and returns the individual response to manager of said common information management service (CMIS handler) (31) or the program development kit (MIB toolkit) (34).
  • MIB base Administration Information
  • CMIS handler common information management service
  • MIB toolkit program development kit
  • the ISAM structure of MOls record records for optimized classes is that of the generic representation of MOls to which we concatenate the attribute or attributes to be used in the secondary indexes specified by the user via the mocStorageDefinition objects.
  • the structure of these additional "indexableAttributeList" fields is as specified below: where indexableAttributeList has the following structure: In the indexableAttributeList field which can be used to activate secondary indexes, the values of the indexable attributes are stored.
  • Figure 5 shows an instance of the class "mocStorageDefinition" displayed on the terminal screen by an interface graph allowing the user to access the CMIS-DB administrator.
  • This window allows the user to define the indexable attributes, to define them classify in order of discrimination, the choice of the most discriminating attribute being established by declaration in the mocStorageDefinition object in order descending attributes to index.
  • this window (61) is produced by ISM-Monitor which allows display a first block containing the first attribute (61, opClass0) by definition constituting the identifier "mocld" of the optimized object class.
  • a second block (62) displays the state attribute of the optimization function and optionally allows to pass it from the active state (unlocked) to the state inactive (locked). In the latter state, the optimization function, i.e. the pre-filter stage is not used.
  • a third block (63) allows display or create the list of indexable attributes, for example, by indicating for each attribute in the list the name of the attribute "Attributld” and possibly to declare if necessary the physical structure of the index by "mappedAs> simple ISAMtype> inttype or mappedAs> simple information ISAMtype> doubletype, which in this case means that the representation attribute attribute is of the double type.
  • a first index block (64a) makes it possible to define the first index, at know the index considered the most discriminating by the administrator of CMIS-DB.
  • Each block (64a to 64e) allows the definition of five levels different indexes and allows to describe an index configuration including in the case of the indexes (64a, 64b, 64c) one or in the case of the index (64e) several attributes or none in the case of the index (64d). In this last case, the fourth index (64d) which does not contain an attribute does not exist.
  • Each block (64a to 64e) can also receive information linking the index with the object's father (withfatherRef> TRUE).
  • index (64d) has an unused "CMIS null” field, which indicates that the class optimized has only four configured indexes.
  • a field (65) allows define the indexes used and activate them according to the user's needs.
  • a field (66) gives the name of the class of the object.
  • a field (67) allows define the naming link with the "mocStorageConfiguration" class.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The access method is optimized by having a database access server specialize the generic representation for classes of objects, for which access time must be optimized. This is achieved by creation of an instance, of an object of the storage definition class, in which is declared the attributes of the class to be optimized. This will be indexed during physical storage on the disc.

Description

La présente invention concerne un procédé pour l'optimisation des accès à une base de données.The present invention relates to a method for optimizing access to a database.

Les services d'accès aux informations d'une MIB reposent sur le standard CMIS (Common Management Information Service recommendation ITU-T X.710), qui décrit les opérations que l'on peut effectuer sur les objets spécifiés suivant le modèle du standard G.D.M.O. (Guidelines for the Definition of Managed Objects, c'est-à-dire Directives pour la définition des objets administrés, recommandation ITU-T X.722). La présente invention utilise le service de gestion d'informations dans le standard CMIS. Ce service est attaché au CDSP (figure 4, 42) (CMIS Dispatcher Process) qui est un service d'échange de paquets CMIS entre entités de la plate-forme OpenMaster™. CDSP est un routeur de paquet pour le service d'informations d'administration, c'est-à-dire un système de transfert de données entre deux entités utilisant le même protocole. Les applications d'administration font appel soit à des agents (43a, 43b, 43c), soit à des services locaux de la plate-forme qui permettent de gérer localement une base d'informations d'administration hiérarchisée sous forme d'arbre d'objets (MIB, Management Information Base), sans accès réseau. Dans ces bases d'informations d'administration (MIB), toutes les ressources sont représentées sous la forme d'objets dans un arbre d'objets tel que représenté en figure 2.The information access services of a MIB are based on the standard CMIS (Common Management Information Service recommendation ITU-T X.710), which describes the operations that can be performed on objects specified according to the standard G.D.M.O. (Guidelines for the Definition of Managed Objects, i.e. Guidelines for the definition of administered objects, ITU-T recommendation X.722). The present invention uses the information management service in the CMIS standard. This service is attached to the CDSP (figure 4, 42) (CMIS Dispatcher Process) which is a CMIS packet exchange service between entities of the platform OpenMaster ™. CDSP is a packet router for service administration information, i.e. a system for transferring data between two entities using the same protocol. Applications administrators use either agents (43a, 43b, 43c) or local platform services which allow local management of a hierarchical administration information base in the form of an object tree (MIB, Management Information Base), without network access. In these bases administration information (MIB), all resources are represented as objects in an object tree such as shown in figure 2.

Les objets sont eux-mêmes regroupés en classes. L'objet d'une classe donnée comporte un certain nombre d'attributs et chaque instance d'objets a un nom (DN). L'adressage se fait par nom distinctif DN (Distinguished Name). Par exemple le DN de l'objet (51, figure 2) est "a/a/b".The objects are themselves grouped into classes. The object of a given class has a number of attributes and each instance objects has a name (DN). Addressing is by distinguished name DN (Distinguished Name). For example the DN of the object (51, figure 2) is "a / a / b".

La figure 4 représente le fonctionnement d'un service de gestion d'informations. Ce service utilise une architecture à deux niveaux. Le premier niveau est constitué d'une entité manager (4) jouant un rôle d'administrateur qui doit visualiser et contrôler des ressources, consulter des caractéristiques, etc. Le second niveau est constitué d'entités agent (43a à 43c) distantes ou locales qui maintiennent les objets sur lesquelles doivent s'appliquer les opérations émises par le niveau administrateur. Le but de l'agent est d'entretenir un modèle de la ressource qu'il gère, modèle consigné et normalisé dans une MIB. Au moins un agent est donc installé sur chaque machine du réseau et peut contrôler un ensemble de ressources locales ou distantes sous la direction d'un ou de plusieurs administrateurs. Un administrateur communique avec chaque agent en utilisant un protocole de gestion standard. Le système d'administration OpenMaster™ commercialisé par la société BULL comprend un ou plusieurs administrateurs ISM Manager (Integrated System Management) et plusieurs agents (ISM/Agent). De plus, d'autres agents commercialisés par d'autre sociétés peuvent être contrôlés par l'administrateur OpenMaster™ via des protocoles standards.Figure 4 shows the operation of a management service of information. This service uses a two-level architecture. The first level consists of a manager entity (4) playing a role administrator who must view and control resources, consult characteristics, etc. The second level consists of agent entities (43a to 43c) distant or local which maintain the objects on which must apply the operations issued by the administrator level. The goal of the agent is to maintain a model of the resource he manages, model documented and standardized in a MIB. At least one agent is installed on each machine on the network and can control a set of resources local or remote under the direction of one or more directors. An administrator communicates with each agent using a protocol standard management. The OpenMaster ™ administration system marketed by the company BULL includes one or more ISM Manager (Integrated System Management) administrators and several agents (ISM / Agent). In addition, other agents marketed by other companies can be controlled by the OpenMaster ™ administrator via standard protocols.

Le mécanisme administrateur-agent est basé sur un modèle d'objet, dans lequel la modélisation d'une ressource constituée, par exemple, d'éléments du système, de logiciels, d'états, d'utilisateurs, etc., s'appuie sur une approche et une structuration en objets des informations de management. Les équipements "réels" d'un système en réseau (un ordinateur, une imprimante, un circuit, etc.) sont représentés par des objets abstraits organisés dans une base d'informations d'administration (MIB, Management Information Base). Les caractéristiques de ces objets (nom d'un ordinateur, caractéristiques des équipements périphériques, les statuts de ces équipements tels qu'une imprimante, etc.) sont appelés les attributs des objets.The administrator-agent mechanism is based on an object model, in which the modeling of a constituted resource, for example, of system elements, software, states, users, etc., is based on an approach and a structuring in information objects of management. The "real" equipment of a networked system (a computer, printer, circuit, etc.) are represented by objects abstracts organized in an administration information base (MIB, Management Information Base). The characteristics of these objects (name of a computer, characteristics of peripheral equipment, status of such equipment such as a printer, etc.) are called the attributes Objects.

Les objets sont divisés en classes d'objets administrés plus souvent appelés MOCs (Managed Object Classes), où chaque MOC représente un type de ressources. Les MOCs définissent les informations que la MIB va contenir pour chaque type de ressources, c'est à dire quels attributs l'objet va avoir. Les MOCs peuvent être interprétées comme une partie du "schéma" de la MIB. L'administrateur enregistre une classe d'objets MOC dans le langage GDMO et il déclare entre autres les classes et pour chaque classe, une liste d'attributs, des liens de nommage etc. Cette description est enregistrée dans un module de définition des objets GDMO attachés à l' administrateur ISM (41). Chaque MOC est instanciée en plusieurs instances d'objets administrés MOIs (Managed Object Instances) représentant les occurrences réelles de ce type de ressources.Objects are divided into classes of objects administered more often called MOCs (Managed Object Classes), where each MOC represents a type of resources. MOCs define the information that the MIB will contain for each type of resource, i.e. which attributes the object will have. MOCs can be interpreted as part of the "scheme" of the MIB. Administrator registers MOC object class in the GDMO language and it declares among other things the classes and for each class, attribute list, naming links etc. This description is saved in a module for defining GDMO objects attached to the ISM administrator (41). Each MOC is instantiated in several instances Managed Object Instances (MOIs) actual occurrences of this type of resource.

Prenons l'exemple de trois imprimantes (Imprim1, Imprim2, Imprim3) représentées par trois instances d'objets (P1, P2, P3) dans une base d'informations d'administration (MIB), Les attributs de l'objet représentant l'imprimante sont "état de l'imprimante" et "utilisateur". Une classe d'objets MOC "imprimante" (printers) peut donc être définie ayant pour attributs "état de l'imprimante" et "utilisateur". Les instances d'objets (MOls) de la classe "imprimante" peuvent être les suivantes: MOI MOC ATTRIBUTS (instance) Classe état de l'imprimante utilisateur Imprim 1 Printer activée aucun Imprim 2 Printer désactivée aucun Imprim 3 Printer activée Joe Take the example of three printers (Imprim1, Imprim2, Imprim3) represented by three object instances (P1, P2, P3) in an administration information base (MIB), The attributes of the object representing the printer are "printer status" and "user". A MOC object class "printer" (printers) can therefore be defined with the attributes "printer status" and "user". The object instances (MOls) of the "printer" class can be the following: ME MOC ATTRIBUTES (instance) Class printer status user Print 1 Printer activated no Print 2 Printer deactivated no Print 3 Printer activated Joe

L'état (status) de la ressource Imprimante 1 est activée et sans utilisateur actuel dans l'instanciation de l'exemple ci-dessus. Cet exemple comporte encore les instances Imprim 2 et Imprim 3. Une application telle que "ISM Monitor" fournie par le système d'administration OpenMaster™ (4) permet d'afficher les MOls et leurs états. De même, ISM-Monitor (46) peut afficher sous forme de tableau les attributs de n'importe quelle MOI : par exemple les attributs "état de l'imprimante" et "utilisateur actuel" pour une MOI quelconque de la MOC "Printers".The status of the Printer 1 resource is activated and without current user when instantiating the above example. This example still includes the Imprim 2 and Imprim 3 instances. as "ISM Monitor" provided by the OpenMaster ™ administration system (4) displays the MOls and their states. Likewise, ISM-Monitor (46) can display in tabular form the attributes of any ME: by example the attributes "printer status" and "current user" for a ANY of me from the "Printers" OMC.

L'ensemble des objets administrés forme une base d'informations d'administration (MIB). The set of administered objects forms an information base administration (MIB).

On appelle "MIBlet" un sous arbre directement attaché à la racine de l'arbre distinct d'une base d'information d'administration (MIB). Malgré la division en MIBlets, la base d'informations d'administration (MIB) du système d'administration OpenMaster™ est reconnue comme une entité composite unique, avec tous les MIBlets attachés à la même MIB. On appelle "Rootlet" un objet MOI à la racine d'une MIBlet. L'administrateur OpenMaster™ voit le système distribué à travers les objets de la MIB et le contrôle du système se fait par des manipulations des objets de la MIB et de leurs attributs. Les objets sont visibles grâce aux agents ou aux gestionnaire d'objets attachés à l'administrateur OpenMaster™ qui cartographient (mapping) les équipements en MIB sous forme d'arbre d'objets. Un agent peut représenter l'état d'un équipement par la voie d'un objet associé correspondant représenté dans la MIB. Cette cartographie peut associer un objet avec plusieurs équipements "réels", de même qu'un équipement peut être modélisé sous la forme de plusieurs objets. L'administrateur OpenMaster™ (4) envoie des commandes aux agents (43a à 43c) et les agents (43a à 43c) envoient des réponses à ses commandes et notifient des événements à l'administrateur OpenMaster™ (4) à travers des agents intégrateurs (45a) en utilisant un protocole tel que SNMP (Simple Network Management Protocol, 45a), CMIP (Common Management Information Protocol, 45b), ou autres tels que (45c) DSAC/AEP (Distributed Systems Administration and Control/ Admidministrative Exchange Protocol). Chaque protocole d'administration fournit un certain nombre d'opérations simples, par exemple le protocole CMIP fournit toutes les fonctions du standard CMIS à savoir les suivantes:

  • l'administrateur (41) peut lire les attributs d'un objet MIB (I' opération M-GET). L'agent (43) répond à une requête M-GET en donnant des informations sur l'équipement;
  • l'administrateur (41) peut modifier les attributs d'un objet MIB (l'opération M-SET). L'agent (43) modifie l'équipement "réel" en fonction des nouvelles valeurs d'attributs fournies par l'administrateur;
  • l'administrateur (41) peut exécuter une action sur un objet MIB (l'opération M-ACTION). L'agent (43) exécute une action sur l'équipement en fonction de l'action demandée par l'administrateur sur l'objet abstrait;
  • l'administrateur (41) peut créer et supprimer des objets de la MIB (les opérations M-CREATE et M-DELETE);
  • l'agent (43) peut notifier un événement survenant sur un objet de la MIB à l'administrateur (I' opération M-EVENT). L'agent envoie des informations d'un événement concernant un objet abstrait pour décrire un événement survenu sur un équipement "réel".
We call "MIBlet" a subtree directly attached to the root of the tree separate from an administration information base (MIB). Despite the division into MIBlets, the administration information base (MIB) of the OpenMaster ™ administration system is recognized as a single composite entity, with all MIBlets attached to the same MIB. We call "Rootlet" an MOI object at the root of a MIBlet. The OpenMaster ™ administrator sees the system distributed through the MIB objects and the control of the system is done by manipulating the MIB objects and their attributes. Objects are visible using agents or object managers attached to the OpenMaster ™ administrator who map the equipment in MIB in the form of an object tree. An agent can represent the state of a device by means of a corresponding associated object represented in the MIB. This cartography can associate an object with several "real" equipments, just as an equipment can be modeled in the form of several objects. The OpenMaster ™ administrator (4) sends commands to the agents (43a to 43c) and the agents (43a to 43c) send responses to his commands and notify events to the OpenMaster ™ administrator (4) through integrating agents (45a) using a protocol such as SNMP (Simple Network Management Protocol, 45a), CMIP (Common Management Information Protocol, 45b), or others such as (45c) DSAC / AEP (Distributed Systems Administration and Control / Admidministrative Exchange Protocol) . Each administration protocol provides a certain number of simple operations, for example the CMIP protocol provides all the functions of the CMIS standard, namely the following:
  • the administrator (41) can read the attributes of a MIB object (the M-GET operation). The agent (43) responds to an M-GET request by giving information on the equipment;
  • the administrator (41) can modify the attributes of a MIB object (the M-SET operation). The agent (43) modifies the "real" equipment according to the new attribute values provided by the administrator;
  • the administrator (41) can execute an action on a MIB object (the M-ACTION operation). The agent (43) performs an action on the equipment according to the action requested by the administrator on the abstract object;
  • the administrator (41) can create and delete objects from the MIB (the M-CREATE and M-DELETE operations);
  • the agent (43) can notify an event occurring on an object of the MIB to the administrator (the operation M-EVENT). The agent sends information about an event concerning an abstract object to describe an event that occurred on "real" equipment.

Une base d'informations d'administration (MIB) a une hiérarchie d'arborescence stricte, c'est à dire que chaque instance d'objet (MOI) a exactement une et une seule MOI supérieure. L'arbre formé par la base d'informations d'administration MIB est appelé "arbre de contenance" (containment tree). Les instances d'objets administrés (MOIs) sont nommées par leur position dans l'arbre de contenance de la façon suivante :An administration information base (MIB) has a hierarchy strict tree structure, i.e. each object instance (MOI) has exactly one and only one ME higher. The tree formed by the base MIB administration information is called "containment tree" (containment tree). Instances of administered objects (MOIs) are named by their position in the capacity tree as follows:

Chaque MOI possède un nom distinctif relatif (relative distinguished name, RDN) qui différencie les MOls ayant un même et unique MOI supérieur (père). Un des attributs de chaque classe d'objets administrés (MOC) est choisi pour spécifier le RDN de l'instance pour un MOI supérieur donné. Cet attribut appelé l'attribut de nommage (naming attribute) est identifié dans les formulaires (templates) GDMO appelés liens de nommage (name binding). Une MOC peut avoir plusieurs liens de nommage supérieurs potentiels, mais chaque MOI utilisera uniquement l'un d'entre eux. Chaque MOI a également un nom distinctif complet (Full Distinguished Name) unique pour la totalité de la MIB. Le nom distinctif global (DN) d'un objet consiste en son nom distinctif relatif (RDN) joint au nom distinctif (DN) de son supérieur c'est à dire que le nom distinctif (DN) d'une instance d'objets administrés (MOI) contient son propre nom distinctif relatif (RDN) plus les noms distinctifs relatifs (RDNs) de tous ses supérieurs dans l'arbre de contenance jusqu'à la racine. Each MOI has a relative distinguished name (relative distinguished name, RDN) which differentiates MOls with the same unique MOI superior (father). One of the attributes of each managed object class (MOC) is chosen to specify the instance's RDN for a higher MOI given. This attribute called the naming attribute is identified in GDMO templates called naming links (name binding). An OMC can have multiple superior naming links potential, but each MOI will use only one of them. Each ME also has a unique Full Distinguished Name for the entire MIB. The global distinguished name (DN) of an object consists of his relative distinguished name (RDN) joined to the distinguished name (DN) of his superior that is, the distinguished name (DN) of an instance of administered objects (ME) contains its own relative distinguished name (RDN) plus names relative distinctive (RDNs) of all its superiors in the containment tree to the root.

La base d'informations d'administration (MIB) permet d'établir d'autres relations entre objets que les relations réalisées dans l'arbre de contenance par nom distinctif. Ces relations sont réalisées à l'aide d'attributs de relation (relationship attributes). Ces attributs contiennent le nom distinctif global DN (Distinguished Name) d'autres objets . Ils sont utilisés comme des références d'un objet à l'autre.The administration information base (MIB) is used to establish other relationships between objects than the relationships made in the tree of capacity by distinguished name. These relationships are made using attributes relationship attributes. These attributes contain the name distinctive global DN (Distinguished Name) of other objects. They are used as references from one object to another.

Un des administrateurs d'objet local à l'administrateur ISM-Manager s'appele CMIS-DB. Il est chargé de stocker une partie de la MIB locale. La rémanence de ces objets stockés est assurée par des fichiers ISAM (Index Sequential Access Method). Cette technologie (ISAM) qui décrit les structures d'articles (records) est une méthode d'accès aux fichiers structurés sous forme d'articles découpés sur un ou plusieurs index et des informations de donnée.One of the local object administrators to the ISM-Manager administrator is called CMIS-DB. It is responsible for storing part of the local MIB. The persistence of these stored objects is ensured by ISAM files (Index Sequential Access Method). This technology (ISAM) which describes the article structures (records) is a method of accessing files structured in the form of articles cut from one or more indexes and data information.

Lorsque l'application de l'administrateur veut sélectionner un des objets pour poser une opération CMIS comme par exemple un M-GET, il doit spécifier l'instance d'objet de base (BOI, Base Object Instance), la portée (scope) et le "filtre" comme argument de l'opération .When the administrator's application wants to select one of the objects to pose a CMIS operation like for example an M-GET, it must specify the Base Object Instance (BOI), the scope (scope) and the "filter" as an argument for the operation.

L'instance d'objet de base BOI permet d'identifier un objet dans une base d'informations d'administration (MIB) qui est le point de départ d'une évaluation du couple portée-filtre dans l'arbre d'objets. La portée (scope) sélectionne une portion de l'arbre depuis cet objet de base. Par exemple, la portée (scope) "Whole subtree" permet de sélectionner tous les sous arbres d'un objet donné. Parmi tous les objets de la portée (scope), les objets sélectionnés sont ceux pour lesquels l'évaluation du filtre est vrai. L'opération est effectuée sur les objets réellement sélectionnés. L'administrateur envoie un M-GET sur des objets et CMIS-DB lit et retourne à l'application la valeur des attributs des objets sélectionnés.
Pour atteindre une instance d'objets de base (BOI), l'administrateur CMIS-DB doit passer d'objet père en objet fils jusqu'à atteindre le noeud de l'objet de base. Cette opération de navigation peut être longue, si pour passer d'un noeud à l'autre, il faut lire physiquement l'ensemble des fils d'un noeud et parmi ceux-là choisir celui qui a le bon RDN, et ainsi de suite. Une fois, que l'ordinateur a atteint l'instance de base objet, il doit lire les attributs des objets de la base qui correspondent à la portée (scope) pour pouvoir évaluer le filtre en mémoire. Or, la condition générique du stockage des objets imposée par l'ancienne version de CMIS-DB est de lire physiquement tous les objets appartenant à la portée (scope) sélectionnés avant d'évaluer le filtre en mémoire. Lorsqu'on a beaucoup d'objets subordonnés à un objet, les performances peuvent alors être très faibles. Pour comprendre le problème, il convient de rappeler que le stockage générique dans les versions précédentes de CMIS-DB permet de gérer des objets dans la base sans requérir de pré-déclaration de leur format dans le serveur. Ceci est un avantage par rapport à d'autres systèmes qui demandent d'abord de compiler la description des objets dans la base d'objets pour pouvoir les traiter, et ne permettent donc pas de créer d'instance de la classe des objets tant que cette classe n'a pas été décrite. CMIS-DB, par contre, effectue automatiquement cette opération, mais le stockage générique par défaut des objets de la MIB pose les problèmes de performances décrits précédemment. CMIS-DB utilise des structures de données permettant de créer génériquement sur le disque physique du système des instances de n'importe quelle classe d'objets de la MIB sans en connaítre au préalable la description selon GDMO.The BOI base object instance makes it possible to identify an object in an administration information base (MIB) which is the starting point for an evaluation of the carried-filter pair in the object tree. The scope selects a portion of the tree from this base object. For example, the scope "Whole subtree" allows you to select all the sub trees of a given object. Among all the objects in the scope, the objects selected are those for which the evaluation of the filter is true. The operation is performed on the objects actually selected. The administrator sends an M-GET on objects and CMIS-DB reads and returns to the application the value of the attributes of the selected objects.
To reach a base object instance (BOI), the CMIS-DB administrator must pass from parent object to child object until reaching the node of the base object. This navigation operation can be long, if to move from one node to another, it is necessary to physically read all the threads of a node and among these choose the one with the right RDN, and so on . Once the computer has reached the base object instance, it must read the attributes of the base objects which correspond to the scope in order to be able to evaluate the filter in memory. However, the generic condition of the storage of objects imposed by the old version of CMIS-DB is to physically read all the objects belonging to the selected scope before evaluating the filter in memory. When you have a lot of objects subordinate to an object, performance can be very poor. To understand the problem, it should be remembered that generic storage in previous versions of CMIS-DB allows you to manage objects in the database without requiring a pre-declaration of their format in the server. This is an advantage compared to other systems which first ask to compile the description of the objects in the object database in order to be able to process them, and therefore do not allow creating an instance of the class of objects as long this class has not been described. CMIS-DB, on the other hand, automatically performs this operation, but the default generic storage of MIB objects poses the performance problems described above. CMIS-DB uses data structures making it possible to create generically on the physical disk of the system instances of any class of object of the MIB without first knowing the description according to GDMO.

Dans la représentation générique de CMIS-DB, la connaissance de la structure des objets est obtenue lors des opérations CMIS M-CREATE de création des instances, émises par les applications clientes vers le serveur CMIS-DB.In the generic representation of CMIS-DB, the knowledge of the structure of the objects is obtained during CMIS M-CREATE operations of creation of instances, issued by client applications to the server CMIS-DB.

Ce sont les applications qui formatent correctement les M-CREATE en utilisant en ligne les descriptions GDMO enregistrées dans le module OpenMaster™ qui compile et stocke les définitions GDMO des objets gérés par l'administrateur ISM. These are the applications that correctly format M-CREATE using online GDMO descriptions saved in the module OpenMaster ™ which compiles and stores GDMO definitions of managed objects by the ISM administrator.

Un but de la présente invention est de proposer un procédé pour l'optimisation des accès à une base de données organisée en arbres, et plus particulièrement pour un serveur d'administration gérant une très grosse base d'informations d'administration (MIB) et permettant de réaliser des opérations complexes sur un très grand nombre d'objets tout en diminuant les temps de recherche des instances sélectionnées par les arguments de portée (scope) et filtre des opérations CMIS.An object of the present invention is to provide a method for optimizing access to a database organized in trees, and more especially for an administration server managing a very large administration information base (MIB) and allowing to carry out complex operations on a very large number of objects while reducing the search times of the instances selected by the arguments of scope and filter of CMIS operations.

Ce but est atteint par le fait que le procédé pour l'optimisation des accès à une base de données est caractérisé en ce qu'il permet aux applications clientes de demander au serveur CMIS-DB, par configuration en ligne, de spécialiser la représentation générique pour les classes d'objets pour lesquels les temps d'accès doivent être optimisés afin de diminuer les temps de recherche des instances d'objets sélectionnées, par l'accomplissement d'une étape de configuration du stockage physique d'une classe d'objets à optimiser, qui consiste en la création d'une instance d'objet de la classe de définition de stockage (mocStorageDefinition) dans laquelle sont déclarés le ou les attributs de la classe à optimiser qui seront indexés lors du stockage physique sur disque.This object is achieved by the fact that the process for optimizing access to a database is characterized in that it allows client applications to ask the CMIS-DB server, by configuration online, to specialize generic representation for object classes for which access times must be optimized in order to reduce the search time for selected object instances, by the completion of a physical storage configuration step of a object class to optimize, which consists of creating an object instance the storage definition class (mocStorageDefinition) in which are declared the attribute or attributes of the class to be optimized which will be indexed during physical storage on disk.

Selon une autre particularité, le procédé comprend une deuxième étape consistant à écrire un fichier ISAM (Index Sequential Access Method, methode d'accès séquentiel par index) par classe d'objets administrés (MOC) optimisée, fichier spécifique avec sa structure d'index propre contenant la représentation de toutes les instances de cette MOC.According to another particularity, the method comprises a second step of writing an ISAM file (Index Sequential Access Method, sequential access method by index) by managed object class (MOC) optimized, specific file with its own index structure containing the representation of all the instances of this MOC.

Selon une autre particularité, le procédé comprend une troisième étape consistant à analyser les filtres véhiculés par les opérations CMIS émises par les utilisateurs pour identifier, dans une étape de préfiltrage, si oui ou non l'évaluation de ce filtre peut se faire en utilisant un des index positionnés dans la base.According to another particularity, the method comprises a third step of analyzing the filters conveyed by the CMIS operations issued by users to identify, in a pre-filtering step, whether yes or no the evaluation of this filter can be done using one of the indexes positioned in the base.

Selon une autre particularité, la valeur des index physiques pour indexer les attributs spécifiés dans l'instance d'objet de la classe mocStorageDefinition correspondant à la MOC à optimiser comporte la référence unique du noeud de l'instance père (fatherMOlnodeRef) de l'instance de l'objet managé sur 4 octets de long et la succession des attributs 1 à i nécessaires à la classe d'objets managés à optimiser.According to another particular feature, the value of the physical indexes for index the attributes specified in the class object instance mocStorageDefinition corresponding to the MOC to be optimized includes the unique reference of the father instance node (fatherMOlnodeRef) of the instance of the object managed on 4 bytes long and the succession of attributes 1 to i necessary for the class of managed objects to be optimized.

Selon une autre particularité, lorsqu'un préfiltrage par les attributs indexés dans la base de données sous-jacente est utilisable, l'exécuteur des requêtes sur la base d'informations d'administration (MIB query performer) détermine les arguments de l'opération de lecture physique ne permettant de relire dans la base sous-jacente que les seuls subordonnés qui sont indexés par les valeurs des attributs sélectionnés pour le préfiltrage.According to another particular feature, when a prefiltering by attributes indexed in the underlying database is usable, the executor of requests based on administrative information (MIB query performer) determines the arguments of the physical read operation not allowing to re-read in the underlying base that the only subordinates who are indexed by the values of the attributes selected for pre-filtering.

Selon une autre particularité, la classe d'objets administrés (mocStorageDefinition) permet de spécifier une pluralité d'attributs indexables qui seront physiquement stockés dans l'index au moment de la création de l'objet.According to another particular feature, the class of administered objects (mocStorageDefinition) allows to specify a plurality of attributes indexable which will be physically stored in the index at the time of creation of the object.

Selon une autre particularité, la pluralité des index décrits dans l'objets administré mocStorageDefinition peut être réorganisée à tout moment en réaffectant un niveau d'index différent à un ou plusieurs attributs ou en activant ou désactivant les index via la modification de l'objet de classe mocStorageDefinition.According to another particular feature, the plurality of indexes described in the mocStorageDefinition administered object can be reorganized at any time moment by reassigning a different index level to one or more attributes or by activating or deactivating the indexes by modifying the object of class mocStorageDefinition.

Selon une autre particularité, un module exécuteur de requête du service de gestion d'informations CMIS-DB effectue, après détection d'une possibilité de préfiltrage par la connaissance de la mocStorageDefinition de chaque classe optimisée, la lecture dans la base de données sous-jacente des seuls objets de la portée qui sont indexés par les valeurs des attributs sélectionnés pour le préfiltrage.According to another particular feature, a request executor module of the information management service CMIS-DB performs, after detection of a possibility of pre-filtering by knowing the mocStorage Definition of each optimized class, reading from the underlying database only objects in the scope that are indexed by attribute values selected for pre-filtering.

Selon une autre particularité, des moyens sont prévus pour permettre à l'utilisateur d'effectuer le choix de l'attribut ou du groupe d'attribut e plus discriminant en classant par ordre décroissant les index définis.According to another particular feature, means are provided for allow the user to choose the attribute or group more discriminating e attribute by sorting the indexes in descending order defined.

Selon une autre particularité, l'optimiseur reconnaít les filtres qui peuvent donner lieu à un préfiltrage pour les index : ce sont les filtres constitués d'une clause ET englobant :

  • un item d'égalité sur l'attribut objectClass, valeur égale à l'identifiant d'une des MOC optimisées,
  • une expression logique constituée uniquement de clauses ET (AND) englobant des items de comparaison sur les attributs déclarés dans les index de cette MOC optimisée.
According to another particularity, the optimizer recognizes the filters which can give rise to a pre-filtering for the indexes: these are the filters made up of an AND clause including:
  • an equality item on the objectClass attribute, value equal to the identifier of one of the optimized MOCs,
  • a logical expression made up only of AND (AND) clauses including comparison items on the attributes declared in the indexes of this optimized MOC.

D'autres particularités et avantages de la présente invention apparaítront plus clairement à la lecture de la description ci-après faite en référence aux dessins annexés dans lesquels :

  • la figure 1 représente un exemple d'une base d'informations d'administration (MIB) stockée dans un service commun de gestion d'informations indexé (CMIS-DB),
  • la figure 2 représente, un arbre d'objets constituant une partie de la MIB,
  • la figure 3 l'architecture du module de gestion d'information pour base de donnée CMIS-DB,
  • la figure 4 représente l'architecture de l'entité manager du produit OpenMaster™,
  • la figure 5 représente une fenêtre d'affichage d' une instance d' objet de classe "mocStorageDefinition" générée par une interface graphique utilisateur (GUI) faisant partie de ISM-MONITOR et permettant la définition et l'activation ou désactivation des attributs indéxés d'une classe d'objet optimisée.
Other features and advantages of the present invention will appear more clearly on reading the description below made with reference to the appended drawings in which:
  • FIG. 1 represents an example of an administration information base (MIB) stored in a common indexed information management service (CMIS-DB),
  • FIG. 2 represents a tree of objects constituting a part of the MIB,
  • FIG. 3 the architecture of the information management module for the CMIS-DB database,
  • FIG. 4 represents the architecture of the manager entity of the OpenMaster ™ product,
  • FIG. 5 represents a window for displaying an instance of an object of class "mocStorageDefinition" generated by a graphical user interface (GUI) forming part of ISM-MONITOR and allowing the definition and the activation or deactivation of the attributes indexed d 'an optimized object class.

L'idée principale de l'invention est d'utiliser un mécanisme d'indexation que l'on trouve dans les fichiers indexés de type ISAM (Index Sequential Access Method, methode d'accès séquentiel par index) ou dans les bases de données relationnelles ou orientées objets pour pouvoir indexer certains attributs d'objets. Il faut rappeler que le stockage physique des informations nécessite de choisir une technologie de base. Il existe principalement la technologie des bases de données objets, les bases de données relationnelles et la technologie ISAM. Le choix des fichiers ISAM pour le stockage physique d'une MIB est connu dans les anciennes versions d'un module de service commun de gestion d'informations non indexables pour base de donnée CMISNI-DB et est toujours utilisé dans la version actuelle. Mais le même mécanisme est applicable sur d'autres technologies de bases telles que les SGBDO (Système de Gestion de Bases de Données Objets) et les SGBDR. Le procédé décrit ne restreint donc pas le mécanisme de stockage physique à la seule technologie ISAM.The main idea of the invention is to use a mechanism indexing found in indexed files of type ISAM (Index Sequential Access Method, or in relational or object-oriented databases to be able to index certain object attributes. Remember that physical storage information requires choosing a basic technology. It exists mainly object database technology, databases relational data and ISAM technology. Choosing ISAM files for the physical storage of a MIB is known in old versions a common service module for managing non-indexable information for CMISNI-DB database and is still used in the version current. But the same mechanism is applicable on other technologies databases such as DBMS (Database Management System Objects) and RDBMS. The process described therefore does not restrict the mechanism ISAM-only physical storage.

Les articles (record) dans un fichier ISAM sont indexés. Pour accéder directement à un article, il y a deux possibilités : soit donner le numéro de l'article, soit faire une recherche sur une des valeurs qui est déclarée comme champ d'index dans l'article. ISAM implémente un algorithme qui permet de diminuer le nombre de recherches physiques : les "B+tree" forment des structures de données qui permettent d'accélérer les recherches physiques de chaínes (string) par calculs de clés et création de tables intermédiaires. A partir d'une valeur recherchée, les "B+tree" permettent de faire des accès rapides pour retrouver le plus rapidement possible les seuls articles (record) qui ont cette valeur dans l'index. L'ordinateur peut ainsi aller chercher physiquement sur le disque tous les articles (record) qui ont une certaine valeur index. Cette opération est plus rapide que de lire un par un tous les articles, de tester en mémoire si la valeur lue correspond à la valeur demandée.The articles (record) in an ISAM file are indexed. For direct access to an article, there are two possibilities: either give the article number, or do a search on one of the values which is declared as an index field in the article. ISAM implements a algorithm which reduces the number of physical searches: "B + tree" form data structures which make it possible to accelerate physical research of chains (string) by key calculations and creation of intermediate tables. From a desired value, the "B + tree" allow quick access to find the fastest possible only the articles (record) which have this value in the index. The computer can thus physically search the disk every items (record) that have a certain index value. This operation is more faster than reading all the articles one by one, testing in memory if the value read corresponds to the requested value.

Pour créer un ensemble d'objets dans une base, la plupart des agents qui gèrent des bases de gestion d'informations MIB demandent à connaítre, en langage GDMO, la définition des objets managés.To create a set of objects in a database, most of the agents who manage MIB information management databases ask know, in GDMO language, the definition of managed objects.

Dans la présente invention, CMIS-DB accepte de créer des objets sans connaítre leur définition GDMO, en les représentant dans la base de manière générique. La présente invention permet à l'utilisateur d'indexer les instances des classes d'objets managés (MOI) qu'il interroge le plus souvent. Pour cela, l'administrateur doit créer une instance d'objets particulière de classe appelée "mocStorageDefinition" dans laquelle l'administrateur décrit la définition de la structure des index qui seront appliqués aux instances d'objets managés de la classe (MOC) à optimiser. Ainsi comme représenté figure 1 l'administrateur a créé une instance d'objets de classe mocStorageDefinition (15) pour la classe d'objet Z (5a, 5b) et une autre instance pour la classe d'objets Y (4a, 4b, 4c). Ainsi, pour chaque type de classe (MOC) d'objets optimisés et managés, un fichier ISAM est créé dans lequel sa clé est coupée en deux, une clé étant pour ISAM un simple champ identifié dans l'article (record) du fichier. La première partie contient la référence du père de l'instance et est utilisée par le moteur de parcours et la seconde partie contient la ou les valeurs des attributs indéxés de cette instance.In the present invention, CMIS-DB accepts to create objects without knowing their GDMO definition, representing them in the database generic way. The present invention allows the user to index the instances of the managed object classes (MOI) that it interrogates the most often. For this, the administrator must create an instance of objects particular class called "mocStorageDefinition" in which the administrator describes the definition of the index structure which will be applied to managed object instances of the class (MOC) to optimize. As shown in Figure 1 the administrator has created an instance objects of class mocStorageDefinition (15) for object class Z (5a, 5b) and another instance for the object class Y (4a, 4b, 4c). So, for each type of class (MOC) of optimized and managed objects, a file ISAM is created in which its key is cut in half, one key being for ISAM a single field identified in the article (record) of the file. The first one part contains the reference of the father of the instance and is used by the engine and the second part contains the attribute value (s) indexed to this instance.

La présente invention permet donc à l'utilisateur de définir une représentation physique indexée différente de la représentation générique de CMIS-DB, afin d'optimiser les accès les plus fréquents. En effet, pour optimiser les recherches d'instances d'un certain nombre de classe d'objets managés (MOC), l'utilisateur a la possibilité de déclarer les classes d'objets managés (MOC) dont il veut optimiser les consultations. L'optimisation consiste à choisir dans une classe d'objets managés (MOC) donnée, le ou les attributs destinés à être utilisés comme critère de filtrage dans les recherches que l'utilisateur veut optimiser. Ces attributs seront nommés "attributs indexés". De ce ou de ces attributs choisis, le module CMIS-DB en déduit un ou plusieurs nouveaux index à introduire dans la représentation des instances de cette classe d'objets managés (MOC). Une classe d'objets managés (MOC) optimisée est de ce fait représentée par un type de noeud (5, 4 ; figure 1) différent physiquement du noeud générique (2, 3 ; figure 1) et spécifique à chacune des classes d'objets managés (MOC) optimisées.The present invention therefore allows the user to define a indexed physical representation different from generic representation CMIS-DB, in order to optimize the most frequent accesses. Indeed, for optimize searches for instances of a certain number of object classes managed (MOC), the user can declare the object classes managed (MOC) which he wants to optimize consultations. Optimization consists in choosing in a given managed object class (MOC), the or the attributes intended to be used as a filtering criterion in the searches that the user wants to optimize. These attributes will be named "indexed attributes". From this or these chosen attributes, the CMIS-DB module deduct one or more new indexes to introduce into the representation instances of this managed object class (MOC). A class of objects managed (MOC) is therefore represented by a type of node (5, 4; figure 1) physically different from the generic node (2, 3; figure 1) and specific to each of the optimized managed object classes (MOC).

L'objet de configuration "mocStorageConfig" contient l'ensemble des classes "mocStorageDefinition" (14, 15) définies pour le module CMIS-DB. La classe "mocStorageDefinition" (14, 15) permet à l'utilisateur de définir pour chaque classe à optimiser identifiée par l'identifieur "moclD" quels sont les attributs à indexer. Les opérations autorisées sur les objets de classe "mocStorageDefinition" sont:

  • les objets M-CREATE et M-DELETE sur une base de données CMIS-DB ne contenant encore aucune instance de la classe à optimiser.
  • les opérations M-GET,
  • les opérations M-SET sur les seuls attributs "usedlndex" et index 1, index 2, index 3, index 4 et index 5.
The configuration object "mocStorageConfig" contains the set of classes "mocStorageDefinition" (14, 15) defined for the CMIS-DB module. The class "mocStorageDefinition" (14, 15) allows the user to define for each class to be optimized identified by the identifier "moclD" which attributes are to be indexed. The authorized operations on objects of class "mocStorageDefinition" are:
  • M-CREATE and M-DELETE objects on a CMIS-DB database not yet containing any instance of the class to be optimized.
  • M-GET operations,
  • M-SET operations on the attributes "usedlndex" and index 1, index 2, index 3, index 4 and index 5 only.

La description en langage GDMO de la classe mocStorageDefinition est la suivante :

Figure 00130001
Figure 00140001
The description in GDMO language of the class mocStorageDefinition is as follows:
Figure 00130001
Figure 00140001

Toutes les opérations CMIS relatives aux objets gérés par CMIS-DB sont acheminées entre l'application de gestion et CMIS-DB par l'infrastructure (CDSP) de communication de l'entité manager de OpenMaster™. Ainsi, CMIS-DB est considéré par les applications PoenMaster™ comme un administrateur d'objets (object manager) qui stocke et gère une partie de la MIB dans une base de donnée.All CMIS operations relating to objects managed by CMIS-DB are routed between the management application and CMIS-DB by the communication infrastructure (CDSP) of the manager entity of OpenMaster ™. Thus, CMIS-DB is considered by applications PoenMaster ™ as an object manager that stores and manages part of the MIB in a database.

Le serveur CMIS-DB interagit avec le CDSP (33, fig.3) à travers une interface (32). Les interactions entre tous les composants de l'administrateur ISM sont réalisés à l'aide de messages CMIS acheminés par CDSP.The CMIS-DB server interacts with the CDSP (33, fig. 3) through a interface (32). Interactions between all administrator components ISM are performed using CMIS messages routed by CDSP.

La figure 3 représente l'architecture de CMIS-DB selon l'invention qui comprend un gestionnaire d'opérations CMIS (CMIS operations handler) (31) dialoguant selon le protocole du (CDSP) (33) avec l'infrastructure de communication, un module programmable d' extension utilisateurcodé en SML (SML MIB toolkit) (34), un module (37) découpé en un sous module exécuteur de requête (MIB queries performer), un sous module de navigation, d'évaluation de portée et de filtre, un sous module optimiseur par préfiltrage (372), un traducteur de forme globale en forme locale (38), un module d'import/export (39), une antémémoire de l'arbre de contenance d'objets (cache of containment tree) (40), une antémémoire des instances de gestion d'objet (cache of MOls)(49), un module d'accès à la mémoire physique (50) qui interface le serveur de la base de données sous-jacente (51), un module administrateur de transactions d'accès physique (storage transaction manager) (48) et un disque physique (47).FIG. 3 represents the architecture of CMIS-DB according to the invention which includes a CMIS operations handler (31) dialoguing according to the protocol of the (CDSP) (33) with the infrastructure of communication, a programmable user extension module coded in SML (SML MIB toolkit) (34), a module (37) divided into a sub-module query executor (MIB queries performer), a submodule of navigation, range evaluation and filter, one optimizer sub-module per prefiltering (372), a translator from global to local form (38), a import / export module (39), a cache of the capacity tree cache of containment tree (40), a cache of instances of object management (cache of MOls) (49), a memory access module physical (50) which interfaces the server of the underlying database (51), a physical access transaction administrator module (storage transaction manager) (48) and a physical disk (47).

Le kit de programme de développement (SML MIB toolkit) (34) charge les éventuelles extensions SML (Systems Management Language) (341) de l'utilisateur et fournit en SML les primitives d'accès à la base d'informations d'administration (MIB) gérée par le service CMIS-DB. En outre, le kit de développement de programme (SML MIB toolkit) (34) évalue les pré-conditions et les post-conditions posées par l'utilisateur, lors de chaque opération sur la base d'informations d'administration (MIB) et exécute les extensions SML qui sont déclenchées sur ces conditions.The development program kit (SML MIB toolkit) (34) loads any SML (Systems Management Language) extensions (341) of the user and provides primitives for access to the database in SML Administration Information (MIB) managed by the CMIS-DB service. In in addition, the program development kit (SML MIB toolkit) (34) assesses the pre-conditions and post-conditions set by the user, when each operation based on administrative information (MIB) and executes the SML extensions that are triggered on these conditions.

L'exécuteur des requêtes (37) sur la base d'informations d'administration effectue réellement la requête ou l'opération sur la représentation logique de la base d'informations d'administration (MIB). Il navigue en fonction de l'argument de l'instance d'objet de base (BOI, baseObjectInstance) de la requête , pour obtenir l'instance initiale de l'évaluation de la portée (scope) et du filtre.Executor of requests (37) based on information administration actually performs the request or operation on the logical representation of the administration information base (MIB). he navigates according to the argument of the base object instance (BOI, baseObjectInstance) of the request, to obtain the initial instance of evaluation of the scope and the filter.

Le mode de fonctionnement de l'exécuteur des requêtes (37) de la base d'informations d'administration (MIB query performer) dépend des arguments des opérations portée (scope) et "filtre" de l'opération. Lorsque aucun préfiltrage par les attributs indexés dans la base de données sous-jacente n'est utilisable, l'exécuteur des requêtes de la base d'informations d'administration (MIB query performer) (37) parcourt la liste de tous les fils pour lire les instances de gestion d'objets (MOI) correspondant à la portée (scope).La décision de savoir si un préfiltrage peut être éxécuté ou non dépend de l'analyse de la structure du filtre.The mode of operation of the request executor (37) of the administration information base (MIB query performer) depends on arguments of the operations scope and "filter" of the operation. When no prefiltering by attributes indexed in the underlying database cannot be used, the executor of information base queries administration (MIB query performer) (37) iterates through the list of all threads to read the object management instances (MOI) corresponding to the scope (scope) .The decision whether a pre-screening can be performed or not depends on the analysis of the filter structure.

La recherche optimisée des MOI sélectionnés par un filtre consiste à ne pas lire physiquement toutes les MOls appartenant à la portée (scope) CMIS pour leur appliquer l'évaluation du filtre mais à utiliser lorsque c'est possible, les index qui sont positionnés sur leur MOC dites optimisées, afin de ne lire qu'un sous-ensemble de ces instances MOls. Cette dernière opération est appelée "présélection ou préfiltrage" elle ne remplace pas l'étape d'évaluation du filtre sur chaque MOI remontée en mémoire qui a lieu systématiquement dans les deux cas. Le préfiltrage par les index peut donc remonter des MOls qui au final seront rejetées par l'étape d'évaluation du filtre CMIS, mais il ne doit pas oublier de lire une seule des MOls de la portée qui vérifient le filtre. The optimized search for MOIs selected by a filter consists of do not physically read all MOls belonging to the scope CMIS to apply the filter evaluation to them but to use when it is possible, the indexes that are positioned on their so-called optimized MOCs, so to read only a subset of these MOls instances. This last operation is called "preselection or prefiltering" it does not replace the filter evaluation step on each MOI raised in memory which takes place systematically in both cases. Pre-filtering by indexes can therefore raise MOls which in the end will be rejected by the evaluation stage of the CMIS filter, but it should not forget to read only one of the MOls in the scope that check the filter.

Les filtres CMIS doivent obligatoirement se conformer à une structure définie pour être reconnus par l'optimiseur de recherche des MOls que ces filtres sélectionnent.CMIS filters must comply with a structure defined to be recognized by the MOls search optimizer that these filters select.

Excepté la portée (scope) "base object only" qui n'est pas concernée par le mécanisme d'optimisation, le type de portée (scope) utilisé dans les requêtes n'a aucune influence sur les règles permettant de décider si une première sélection par les index est plus optimum qu'une lecture physique de toutes les MOls appartenant au scope.Except the scope "base object only" which is not concerned by the optimization mechanism, the type of scope (scope) used in the has no influence on the rules for deciding whether a first selection by indexes is more optimal than a physical reading of all MOls belonging to the scope.

Un filtre CMIS reconnu par l'optimiseur doit être une expression logique qui sélectionne uniquement des MOls de la même classe. Cette classe qui doit être une des MOC optimisées déclarées au module CMIS-DB.A CMIS filter recognized by the optimizer must be an expression logic that selects only MOls of the same class. This class which must be one of the optimized MOCs declared to the CMIS-DB module.

Cette expression logique doit être constituée d'une clause ET (AND) englobant:

  • un item d'égalité sur l'attribut objectClass, valeur égale à l'identifiant d'une des MOC optimisées.
  • une expression logique constituée uniquement de clauses ET (AND) englobant des items de comparaison sur les attributs déclarés dans les index de la MOC optimisée. Ces comparaisons sur les attributs indexés ne peuvent être que des égalités, sauf lorsqu'une des opérations greaterOrEqual, lessOrEqual ou initialString porte sur le dernier élément de l'index (ou de la partie initiale de l'index) sélectionné.Par exemple pour une moc optimisée construite avec plusieurs index constitués avec les attributs (att.1; att.2; att.3) l'expresion logique pourra être la suivante:
   att.1 = value1 & att.2 = value2 & att.3 = value3
  • et éventuellement une autre expression logique qui porte sur les attributs qui ne sont pas déclarés dans les index de la MOC identifiée.
This logical expression must consist of an AND (AND) clause including:
  • an equality item on the objectClass attribute, value equal to the identifier of one of the optimized MOCs.
  • a logical expression made up only of AND (AND) clauses including comparison items on the attributes declared in the indexes of the optimized JI. These comparisons on the indexed attributes can only be equalities, except when one of the greaterOrEqual, lessOrEqual or initialString operations relates to the last element of the index (or of the initial part of the index) selected. optimized moc built with several indexes constituted with the attributes (att.1; att.2; att.3) the logical expression could be as follows:
att.1 = value1 & att.2 = value2 & att.3 = value3
  • and possibly another logical expression which relates to the attributes which are not declared in the indexes of the identified JI.

Plus formellement, la description des filtres CMIS reconnus par le préfiltrage est donnée par la grammaire suivante :

Figure 00180001
More formally, the description of the CMIS filters recognized by prefiltering is given by the following grammar:
Figure 00180001

Dans cette grammaire, l'ordre introduit entre les différents items ne reflète pas un ordre syntaxique dans l'expression du filtre CMIS qui peut être quelconque, mais plutôt l'ordre physique des attributs tels qu'ils existent dans les index de la MOC optimisée.In this grammar, the order introduced between the different items does not not reflect a syntax order in the expression of the CMIS filter which can be any, but rather the physical order of the attributes as they exist in the indexes of the optimized OMC.

Lorsqu'un préfiltrage est utilisable, l'exécuteur des requêtes (37) de la base d'informations d'administration (MIB query performer) lit dans la base sous-jacente les seuls subordonnés qui sont indexés par les valeurs des attributs sélectionnés pour le préfiltrage. Puis l'exécuteur des requêtes (37) de la base d'informations d'administration (MIB query performer) évalue le filtre sur chaque instance précédemment sélectionnée. Si l'évaluation est positive, il exécute l'opération sur la représentation logique de la base d'informations d'administration (MIB) et retourne la réponse individuelle au gestionnaire dudit service commun de gestion d'informations (CMIS handler) (31) ou au kit de développement de programme (MIB toolkit) (34).When prefiltering is usable, the request executor (37) of the administration information base (MIB query performer) reads in the underlying base the only subordinates that are indexed by values attributes selected for pre-filtering. Then the requester (37) of the administration information base (MIB query performer) evaluates the filter on each previously selected instance. If the assessment is positive, it executes the operation on the logical representation of the base Administration Information (MIB) and returns the individual response to manager of said common information management service (CMIS handler) (31) or the program development kit (MIB toolkit) (34).

La structure ISAM des records d'enregistrement des MOls des classes optimisées est celle de la représentation générique des MOls à laquelle on concatène le ou les attributs à utiliser dans les index secondaires spécifiés par l'utilisateur via les objets mocStorageDefinition. La structure de ces champs "indexableAttributeList" supplémentaires est comme spécifié ci-dessous :

Figure 00200001
   où indexableAttributeList a la structure suivante :
Figure 00200002
Dans le champ indexableAttributeList utilisable pour activer des index secondaires, les valeurs des attributs indexables sont stockés.The ISAM structure of MOls record records for optimized classes is that of the generic representation of MOls to which we concatenate the attribute or attributes to be used in the secondary indexes specified by the user via the mocStorageDefinition objects. The structure of these additional "indexableAttributeList" fields is as specified below:
Figure 00200001
where indexableAttributeList has the following structure:
Figure 00200002
In the indexableAttributeList field which can be used to activate secondary indexes, the values of the indexable attributes are stored.

La figure 5 représente une instance de la classe "mocStorageDefinition" affichée à l'écran du terminal par une interface graphique permettant à l'utilisateur d'accéder à l'administrateur de CMIS-DB. Cette fenêtre permet à l'utilisateur de définir les attributs indexables, de les classer en ordre de discrimination, le choix de l'attribut le plus discriminant étant établi par déclaration dans l'objet mocStorageDefinition dans l'ordre décroissant des attributs à indexer.Figure 5 shows an instance of the class "mocStorageDefinition" displayed on the terminal screen by an interface graph allowing the user to access the CMIS-DB administrator. This window allows the user to define the indexable attributes, to define them classify in order of discrimination, the choice of the most discriminating attribute being established by declaration in the mocStorageDefinition object in order descending attributes to index.

Ainsi, cette fenêtre (61) est produite par ISM-Monitor qui permet d'afficher un premier pavé contenant le premier attribut (61, opClass0) constituant par définition l'identifieur "mocld" de la classe d'objets optimisée. Un deuxième pavé (62) visualise l'attribut état de la fonction d'optimisation et permet éventuellement de le faire passer de l'état actif (unlocked) à l'état inactif (locked). Dans ce dernier état, la fonction d'optimisation, c'est-à-dire l' étage de préfiltrage n'est pas utilisé. Un troisième pavé (63) permet d'afficher ou de créer la liste des attributs indexables, par exemple, en indiquant pour chaque attribut de la liste le nom de l'attribut "Attributld" et éventuellement de déclarer si nécessaire la structure physique de l'index par l'information "mappedAs > simple ISAMtype > inttype ou mappedAs > simple ISAMtype > doubletype, ce qui signifie dans ce cas que la représentation physique de l'attribut est du type double.Thus, this window (61) is produced by ISM-Monitor which allows display a first block containing the first attribute (61, opClass0) by definition constituting the identifier "mocld" of the optimized object class. A second block (62) displays the state attribute of the optimization function and optionally allows to pass it from the active state (unlocked) to the state inactive (locked). In the latter state, the optimization function, i.e. the pre-filter stage is not used. A third block (63) allows display or create the list of indexable attributes, for example, by indicating for each attribute in the list the name of the attribute "Attributld" and possibly to declare if necessary the physical structure of the index by "mappedAs> simple ISAMtype> inttype or mappedAs> simple information ISAMtype> doubletype, which in this case means that the representation attribute attribute is of the double type.

Un premier pavé d' index (64a) permet de définir le premier index, à savoir l'index considéré comme le plus discriminant par l'administrateur de CMIS-DB. Chaque pavé (64a à 64e) permet la définition de cinq niveaux différents d' index et permet de décrire une configuration d'index comprenant dans le cas des index (64a, 64b, 64c) un ou dans le cas de l'index (64e) plusieurs attributs ou aucun dans le cas de l'index (64d). Dans ce dernier cas, le quatrième index (64d) qui ne contient pas d'attribut n' existe pas. Chaque pavé (64a à 64e) peut aussi recevoir une information liant l'index avec le père de l'objet (withfatherRef > TRUE). Sur la figure 5 l'index (64d) comporte un champ non utilisé "CMIS nul", ce qui indique que la classe optimisée ne comporte que quatre index configurés. Un champ (65) permet de définir les index utilisés et de les activer selon les besoins de l'utilisateur. Un champ (66) donne le nom de la classe de l'objet. Un champ (67) permet de définir le lien de nommage avec la classe "mocStorageConfiguration".A first index block (64a) makes it possible to define the first index, at know the index considered the most discriminating by the administrator of CMIS-DB. Each block (64a to 64e) allows the definition of five levels different indexes and allows to describe an index configuration including in the case of the indexes (64a, 64b, 64c) one or in the case of the index (64e) several attributes or none in the case of the index (64d). In this last case, the fourth index (64d) which does not contain an attribute does not exist. Each block (64a to 64e) can also receive information linking the index with the object's father (withfatherRef> TRUE). In Figure 5 the index (64d) has an unused "CMIS null" field, which indicates that the class optimized has only four configured indexes. A field (65) allows define the indexes used and activate them according to the user's needs. A field (66) gives the name of the class of the object. A field (67) allows define the naming link with the "mocStorageConfiguration" class.

Ainsi, l'on comprend que l'utilisateur peut, par déclaration des attributs indexés dans un ordre décroissant, influer sur le choix des attributs les plus discriminants et obtenir des résultats différents en rapidité de l'évaluation d'une opération de portée (scope) ou d'une opération "filtre".Thus, it is understood that the user can, by declaration of attributes indexed in descending order, influence the choice of attributes the most discriminating and get different results in speed of the evaluation of a scope operation or a "filter" operation.

D'autres modifications à la portée de l'homme de métier font également partie de l'esprit de l'invention.Other modifications within the reach of those skilled in the art make also part of the spirit of the invention.

Claims (10)

Procédé pour l'optimisation des accès à une base de données, caractérisé en ce qu'il permet aux applications clientes de demander au serveur CMIS-DB, par configuration en ligne, de spécialiser la représentation générique pour les classes d'objets pour lesquels les temps d'accès doivent être optimisés afin de diminuer les temps de recherche des instances d'objets sélectionnées, par l'accomplissement d'une étape de configuration du stockage physique d'une classe d'objets à optimiser, qui consiste en la création d'une instance d'objet de la classe de définition de stockage (mocStorageDefinition) dans laquelle sont déclarés le ou les attributs de la classe à optimiser qui seront indexés lors du stockage physique sur disque.Method for optimizing access to a database, characterized in that it allows client applications to request the CMIS-DB server, by online configuration, to specialize the generic representation for the object classes for which the times must be optimized in order to reduce the search times for instances of selected objects, by performing a step of configuration of the physical storage of a class of objects to be optimized, which consists of creating an object instance of the definition class of storage (mocStorageDefinition) in which are declared the attributes of the class to be optimized which will be indexed during storage physical on disk. Procédé pour l'optimisation des accès à une base de données selon la revendication 1, caractérisé en ce qu'il comprend une deuxième étape consistant à écrire un fichier ISAM (Index Sequential Access Method, methode d'accès séquentiel par index) par classe d'objets administrés (MOC) optimisée, fichier spécifique avec sa structure d'index propre contenant la représentation de toutes les instances de cette MOC.Method for optimizing access to a database according to claim 1, characterized in that it comprises a second step of writing an ISAM file (Index Sequential Access Method, sequential access method by index) by managed object class (MOC) optimized, specific file with its own index structure containing the representation of all the instances of this MOC. Procédé pour l'optimisation des accès à une base de données selon la revendication 1 ou 2, caractérisé en ce qu'il comprend une troisième étape consistant à analyser les filtres véhiculés par les opérations CMIS émises par les utilisateurs pour identifier dans une étape de préfiltrage si oui ou non l'évaluation de ce filtre peut se faire en utilisant un des index positionnés dans la base.Method for optimizing access to a database according to claim 1 or 2, characterized in that it comprises a third step of analyzing the filters conveyed by the CMIS operations issued by users to identify in a pre-filtering step if yes or not the evaluation of this filter can be done using one of the indexes positioned in the base. Procédé pour l'optimisation des accès à une base de données selon la revendication 1, caractérisé en ce que la valeur des index physiques pour les attributs spécifiés dans l'instance d'objets de la classe mocStorageDefinition correspondant à la MOC à optimiser comporte la référence unique du noeud de l'instance père (fatherMOlnodeRef) de l'instance de l'objet managé sur 4 octets de long dans le cas du stockage physique sur fichier ISAM et la succession des attributs 1 à i nécessaires à la classe d'objets managés à optimiser.Method for optimizing access to a database according to claim 1, characterized in that the value of the indexes physical for the attributes specified in the instance of objects of the class mocStorageDefinition corresponding to the MOC to be optimized includes the unique reference of the father instance node (fatherMOlnodeRef) of the instance of the object managed on 4 bytes long in the case of storage physical on ISAM file and the succession of attributes 1 to i necessary to the class of managed objects to optimize. Procédé pour l'optimisation des accès à une base de données selon la revendication 3, caractérisé en ce que, lorsqu'un préfiltrage par les attributs indexés dans la base de données sous-jacente est utilisable, l'exécuteur des requêtes sur la base d'informations d'administration détermine les arguments de l'opération de lecture physique ne permettant de relire dans la base sous-jacente que les seuls subordonnés qui sont indexés par les valeurs des attributs sélectionnés pour le préfiltrage.Method for optimizing access to a database according to claim 3, characterized in that, when a prefiltration by the attributes indexed in the underlying database can be used, the executor of requests based on administrative information determines the arguments of the physical read operation not allowing to re-read in the underlying base that the only subordinates who are indexed by the values of the attributes selected for pre-filtering. Procédé pour l'optimisation des accès à une base de données selon la revendication 1, caractérisé en ce que la classe d'objets administrés mocStorageDefinition permet de spécifier pour une MOC à optimiser une pluralité d'attributs indexables qui seront physiquement stockés dans l'index au moment de la création de l'objet.Method for optimizing access to a database according to claim 1, characterized in that the class of administered objects mocStorageDefinition allows to specify for a MOC to optimize a plurality of indexable attributes that will be physically stored in the index at the time of creation of the object. Procédé pour l'optimisation des accès à une base de données selon la revendication 6, caractérisé en ce que la pluralité des index décrits dans l'objet administré mocStorageDefinition peut être réorganisée à tout moment par configuration en ligne du serveur CMIS-DB en réaffectant un niveau d'index différent à un ou plusieurs attributs ou en activant ou désactivant les index via la modification de l'objet de classe mocStorageDefinition.Method for optimizing access to a database according to claim 6, characterized in that the plurality of indexes described in the administered object mocStorageDefinition can be reorganized at any time moment by online configuration of the CMIS-DB server by reassigning a different index level to one or more attributes or by activating or disabling indexes by modifying the class object mocStorageDefinition. Procédé pour l'optimisation des accès à une base de données selon une des revendications précédentes, caractérisé en ce que le module, qui exécute l'opération CMIS, effectue une analyse du filtre CMIS donné en argument de la requête permettant de détecter si un préfiltrage par la lecture dans la base de données sous-jacente d'un sous-ensemble des objets de la portée est possible. Si oui, le module lit physiquement les seuls objets de la portée qui sont indexés par les valeurs des attributs sélectionnnés pour le préfiltrage.Method for optimizing access to a database according to one of the preceding claims, characterized in that the module, which performs the CMIS operation, performs an analysis of the CMIS filter given in argument of the request allowing to detect if a prefiltering by the reading in the underlying database of a subset of the objects in the range is possible. If yes, the module physically reads the only objects in the scope which are indexed by the values of the attributes selected for the prefiltering. Procédé pour l'optimisation des accès à une base de données selon la revendication 8, caractérisé en ce que des moyens sont prévus pour permettre à l'utilisateur d'effectuer le choix de l'attribut ou du groupe d'attribut le plus discriminant en classant par ordre décroissant les index définis.Method for optimizing access to a database according to claim 8, characterized in that means are provided to allow the user to choose the attribute or group most discriminating attribute by sorting the indexes in descending order defined. Procédé pour l'optimisation des accès à une base de données selon la revendication 8 ou 9, caractérisé en ce que l'optimiseur reconnaít les filtres qui peuvent donner lieu à un préfiltrage pour les index : ce sont les filtres constitués d'une clause ET englobant : un item d'égalité sur l'attribut objectClass, valeur égale à l'identifiant d'une des MOC optimisées, une expression logique constituée uniquement de clauses ET (AND) englobant des items de comparaison sur les attributs déclarés dans les index de cette MOC optimisée. Method for optimizing access to a database according to claim 8 or 9, characterized in that the optimizer recognizes the filters which can give rise to a pre-filtering for the indexes: these are the filters consisting of an AND clause including: an equality item on the objectClass attribute, value equal to the identifier of one of the optimized MOCs, a logical expression made up only of AND (AND) clauses including comparison items on the attributes declared in the indexes of this optimized MOC.
EP99401593A 1998-06-30 1999-06-25 Method for optimization of database accesses Withdrawn EP0969391A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR9808294 1998-06-30
FR9808294A FR2780529B1 (en) 1998-06-30 1998-06-30 METHOD FOR OPTIMIZING ACCESS TO A DATABASE

Publications (1)

Publication Number Publication Date
EP0969391A1 true EP0969391A1 (en) 2000-01-05

Family

ID=9528044

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99401593A Withdrawn EP0969391A1 (en) 1998-06-30 1999-06-25 Method for optimization of database accesses

Country Status (3)

Country Link
US (1) US6484160B1 (en)
EP (1) EP0969391A1 (en)
FR (1) FR2780529B1 (en)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6560609B1 (en) * 1999-06-14 2003-05-06 International Business Machines Corporation Delegating instance management functions to underlying resource managers
US6854034B1 (en) 1999-08-27 2005-02-08 Hitachi, Ltd. Computer system and a method of assigning a storage device to a computer
FR2801697B1 (en) * 1999-11-26 2002-01-25 Bull Sa METHOD OF ACCESSING VARIOUS PROTOCOLS TO OBJECTS OF A TREE REPRESENTATIVE OF AT LEAST ONE SYSTEM RESOURCE
US6708164B1 (en) * 2000-03-17 2004-03-16 Microsoft Corporation Transforming query results into hierarchical information
US7213017B2 (en) * 2000-03-17 2007-05-01 Microsoft Corporation Systems and methods for transforming query results into hierarchical information
JP3659318B2 (en) * 2000-05-09 2005-06-15 インターナショナル・ビジネス・マシーンズ・コーポレーション Spatial data mining equipment
US20020112043A1 (en) * 2001-02-13 2002-08-15 Akira Kagami Method and apparatus for storage on demand service
US6839815B2 (en) 2001-05-07 2005-01-04 Hitachi, Ltd. System and method for storage on demand service in a global SAN environment
US7188334B1 (en) * 2001-11-20 2007-03-06 Ncr Corp. Value-ordered primary index and row hash match scan
US7281044B2 (en) * 2002-01-10 2007-10-09 Hitachi, Ltd. SAN infrastructure on demand service system
US7305395B1 (en) * 2002-04-24 2007-12-04 Oracle International Corporation Centralized storage and management of database parameters
US7885974B2 (en) * 2002-11-18 2011-02-08 Aol Inc. Method and apparatus providing omnibus view of online and offline content of various file types and sources
US7359922B2 (en) * 2004-12-22 2008-04-15 Ianywhere Solutions, Inc. Database system and methodology for generalized order optimization
US7889676B1 (en) * 2006-04-13 2011-02-15 Infoblox Inc. Systems and methods for storing and retrieving data
US7752300B2 (en) * 2007-11-19 2010-07-06 International Business Machines Corporation Automatically determining management information base modules for a device
US8572157B2 (en) 2011-01-31 2013-10-29 Microsoft Corporation Configuration based approach to unify web services
US11200235B1 (en) * 2018-10-26 2021-12-14 United Services Automobile Association (Usaa) Method and system for improving performance of an issue management system
US11269903B1 (en) * 2019-09-27 2022-03-08 Amazon Technologies, Inc. Indexing and retrieval of configuration data

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0483036A2 (en) * 1990-10-24 1992-04-29 International Business Machines Corporation Data structure within object oriented computing environment
EP0680000A1 (en) * 1994-04-26 1995-11-02 International Business Machines Corporation Data store access in an object oriented environment

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08249185A (en) * 1995-03-15 1996-09-27 Fujitsu Ltd Object data processor
US6266708B1 (en) * 1995-07-21 2001-07-24 International Business Machines Corporation Object oriented application program development framework mechanism
US6226691B1 (en) * 1995-10-02 2001-05-01 International Business Machines Corporation System, method, and article of manufacture for adding object services to a binary class in an object oriented server
US6003040A (en) * 1998-01-23 1999-12-14 Mital; Vijay Apparatus and method for storing, navigating among and adding links between data items in computer databases
US6128611A (en) * 1998-04-30 2000-10-03 International Business Machines Corporation Internet-enabled generic application program for accessing hierarchical data

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0483036A2 (en) * 1990-10-24 1992-04-29 International Business Machines Corporation Data structure within object oriented computing environment
EP0680000A1 (en) * 1994-04-26 1995-11-02 International Business Machines Corporation Data store access in an object oriented environment

Also Published As

Publication number Publication date
FR2780529A1 (en) 1999-12-31
FR2780529B1 (en) 2000-08-04
US6484160B1 (en) 2002-11-19

Similar Documents

Publication Publication Date Title
EP0969391A1 (en) Method for optimization of database accesses
EP0727071B1 (en) Relational data base control system using object-oriented access logic to limit the data base access count, and method therefor
US7925616B2 (en) Report system and method using context-sensitive prompt objects
US7580946B2 (en) Smart integration engine and metadata-oriented architecture for automatic EII and business integration
FR2888018A1 (en) METHOD AND SYSTEM FOR REALIZING A VIRTUAL DATABASE FROM DATA SOURCES HAVING HETEROGENEOUS SCHEMES
US7945584B2 (en) Report system and method using prompt object abstraction
US20100115100A1 (en) Federated configuration data management
US20060037000A1 (en) Configuration management data model using blueprints
US20060161895A1 (en) Configuration management system and method of comparing software components
US20060143144A1 (en) Rule sets for a configuration management system
EP1096394A1 (en) System and procedure utilizing an LDAP directory service for administrating the persistence of EJB components
EP1565811A1 (en) Topology mapping of a multitier compute infrastructure
FR2740884A1 (en) ADMINISTRATOR INTERFACE FOR A DATABASE IN A DISTRIBUTED COMPUTING ENVIRONMENT
Bouzeghoub et al. Quality in data warehousing
US7356758B1 (en) System and method for run-time report resolution of reports that include prompt objects
US7302639B1 (en) Report system and method using prompt in prompt objects
Stefanov et al. Bridging the gap between data warehouses and business processes: a business intelligence perspective for event-driven process chains
EP0977400A1 (en) Method for referencing a collection of object instances in a management information base
US7861161B1 (en) Report system and method using prompt objects
FR2785410A1 (en) METHOD OF OPTIMIZING THE ACCESS TO ALL THE INSTANCES OF OBJECTS OF THE SAME CLASS IN AN ADMINISTRATION DATABASE
EP1047222A1 (en) Process of management of the operating conditions in a computer system
Prakash Eliciting Information Requirements for DW Systems.
FR2805908A1 (en) Method of manipulating objects included a Class Instance Tree (CIT) in a OPENMASTER Trade Mark system using Common Management Information Services (CMIS)
Thakkar et al. Introducing Stream Mill
Zaihrayeu DIT-University of Trento Towards Peer-to-Peer Information Management Systems

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

17P Request for examination filed

Effective date: 20000705

AKX Designation fees paid

Free format text: DE FR GB

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20020103