WO2000072510A1 - Procede d'acces, dans un systeme informatique, a des objets d'un arbre de contenance - Google Patents

Procede d'acces, dans un systeme informatique, a des objets d'un arbre de contenance Download PDF

Info

Publication number
WO2000072510A1
WO2000072510A1 PCT/FR2000/001327 FR0001327W WO0072510A1 WO 2000072510 A1 WO2000072510 A1 WO 2000072510A1 FR 0001327 W FR0001327 W FR 0001327W WO 0072510 A1 WO0072510 A1 WO 0072510A1
Authority
WO
WIPO (PCT)
Prior art keywords
class
request
instances
variable
tree
Prior art date
Application number
PCT/FR2000/001327
Other languages
English (en)
Inventor
Philippe Baudry
Original Assignee
Bull S.A.
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 S.A. filed Critical Bull S.A.
Publication of WO2000072510A1 publication Critical patent/WO2000072510A1/fr

Links

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
    • 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/24—Querying
    • G06F16/245—Query processing

Definitions

  • the subject of the present invention is, in a computer system, a method of accessing objects from a capacity tree.
  • the capacity tree is included in a management system
  • the IT system can contain several management systems
  • management will be used to comply with the Afnor (Association facie de NORmaiisation) translation of "Management”
  • the term capacity tree will be used as a translation of the term MIB (Management Information Base) from the OSI standard (Open Systems Interconnection)
  • a computer system includes a machine or several machines connected to the management system via a LAN (Local Area Network), WAN (Wide Area Network) or INTERNET This system can be a distributed system or not, heterogeneous or not
  • a distributed system is a computer system environment which operates by means of at least two identical or different operating systems
  • a machine is associated with an operating system
  • a machine comprises at least one physical resource (for example networks, hubs, segments, etc.) or logic (eg a database, etc.).
  • a heterogeneous computer system generally contains a variety of management protocols.
  • each machine is associated with at least one management protocol.
  • At least one agent is, generally located on a machine of the computer system
  • An agent processes requests addressed to it
  • a software agent manages and updates data on the machine on which it is located
  • Each agent supports a protocol such as SNMP (Simple Network Management Protocol), CMIP (Common Managment Information Protocol), DSAC (Dist ⁇ headed Systems Administration and Control) protocol or other protocols
  • the management system controls the agents, and the agent responds and notifies events using an identical management protocol SNMP, CMIS / CMIP or DSAC / AEP (DSAC Administrative Exchange Protocol)
  • the management system includes several agents called "integrating agents" in the sense that they are integrated into the management system.
  • the agents and integrating agents of the management system coexist and communicate to hide the network heterogeneity
  • a machine management system of an OPENMASTER type computer system (trademark registered by the company BULL SA), known to those skilled in the art, is particularly well suited.
  • This system uses CMIS services (Common Managment Information Services) standardized, known to those skilled in the art
  • CMIS services Common Managment Information Services
  • This management system can be assimilated to a set of services which interact with each other to give a virtual representation of the real world which is the computer system.
  • administrator manipulates (monitoring, action) to manage the real world
  • the virtual representation relates to virtual objects of the real world and constitutes an object model This virtual representation is concretized by means of a capacity tree
  • the containment tree is strictly hierarchical
  • the CMIS (Common Management Information Services) service is well suited to the hierarchical structure of the containment tree
  • this tree is software conforming to the protocol CMIP (Common Managment Information Protocol)
  • CMIP Common Managment Information Protocol
  • This tree includes in its nodes all the objects managed by the management system
  • an object managed is an abstract view, defined for management purposes, of a logical or physical resource of a system
  • a class of managed objects is a named set of managed objects sharing the same properties
  • An attribute is a characteristic of a managed object which has a named type and a value The value of an attribute of an object can be consulted or modified by a request addressed to the object
  • naming of objects calls for a naming tree
  • Each object is located in the naming tree by relation to a superior of which he is the subordinate This relation between subordinate and superior is specified at the level of the classes by a naming link (name binding in English)
  • naming links can be defined for the same class, but an object can have only one immediate superior
  • each instance of the tree is identified by an FDN e t a DN
  • the name DN is a pair ⁇ naming purpose> ⁇ value> which allows the unique identification of an instance of the containment tree compared to a parent instance
  • the FDN name of an instance is a sequence of
  • a containment tree is a tree made up of class instances Currently, it is possible to build a query or update the containment tree and execute it A big problem is that the operators are based on a notion of compatibility of FDN names
  • the instances d1 and d2 are compatible because they admit on the common subtree of the classes (class B) the same distinctive name FDN, namely b1
  • the instances d1 and c2 are not compatible because they admit a respective sub-FDN b1 and b2 different on the common sub-tree of classes (class B)
  • the instances b1 and d3 are compatible because they are attached via a branch in the containment tree
  • the instances ai and b2 are compatible because they are both directly attached to the root of the containment tree
  • a first goal of the solution is therefore to give the possibility to a request designer to create a request whose processing is not limited to a subset of instances of a class of the class tree.
  • a second aim is to provide the system with power to query the containment tree, like the so-called "Select” clauses of the SQL language known to those skilled in the art.
  • the object of the solution is a method of interrogation, in a computer system, by means of at least one request from at least one object included in at least one capacity tree included in at least one machine.
  • a request consisting of an update or a consultation of the objects of the content tree, a request including a context comprising all the parameters (classes, attributes, operators, variables, etc.) describing all the elements of a request, at least one parameter relying on the rule of compatibility between instances limiting the processing of the request to a subset of instances of a class, characterized in that it consists in creating a operator capable of inhibiting, on a given class, the compatibility rules on instances so as to process the request on all the instances of the class to which the request relates
  • the solution can be applied to a distributed computer system of heterogeneous type.
  • this system includes at least one manager system and at least one remote machine associated with a management protocol.
  • the management system can be included in a workstation.
  • a remote machine has been represented.
  • a machine includes manipulable objects.
  • a manipulation includes commands known to those skilled in the art.
  • the machine management protocol can be either a SNMP, CMIS / CMIP or DSAC / AEP type protocol.
  • the system supports a CMIS type protocol conforming to the OSI (Common Management Information Service) model, known to those skilled in the art.
  • This application can be launched through a user of this management system.
  • a user can be an administrator.
  • the management system also includes at least one integrating agent associated with a management protocol in order to mask the heterogeneity of the computer system.
  • an integrating agent is associated with the machine management protocol.
  • an integrating agent is of the software type. It provides services
  • a service can be a conversion of the management protocol
  • the integrating agent converts the management protocol of the management system into a management protocol associated with the machine
  • the integrating agent converts the management protocol associated with the machine into a management protocol associated with the management system
  • An integrating agent is not limited to this type of service and provides other services. Generally speaking, a conversion of management protocol takes place naturally between a management system and a machine which support different management protocols
  • the management server can comprise several integrating agents.
  • the integrating agent is connected to the machine via a network of any type.
  • the network can be of LAN (Local Area Network) or WAN (Wide Area Network) type.
  • a set of software layers is interposed between the management system and the network and between the network and the machine This set of software layers is based on the OSI (Open System Interconnection) model of architecture in layer of the ISO (International Organization for Standardization), known to those skilled in the art
  • a request from the management system is transmitted to the agent.
  • a request is, in general, manipulation of objects on a remote machine. The construction of a request is explained in the following description.
  • the management system also includes a capacity tree associated with the agent.
  • the containment tree can be fully understood in the agent.
  • This tree provides a virtual representation of the real world surrounding the management system. It is a virtual representation that the user or an administrator manipulates (monitoring, action) to manage the real world.
  • the virtual representation relates to virtual objects of the real world and is an object model. In the example illustrated, the real world is materialized by the machine.
  • the containment tree is object oriented and is made up of nodes and branches This tree includes in its nodes all of the objects managed by the management system In general and known to those skilled in the art, to create an object in this database, you must choose its class, name it in accordance with the naming links relating to the class, and value its attributes.
  • a managed object is an abstract view, defined for management purposes, of a logical or physical resource of a system In the containment tree, nodes belong to the same class.
  • a class tree is created. In the example illustrated, the class tree comprises 3 classes " B an Inventory class, B a Network class which represents the discovered networks and is defined by attributes.
  • This containment tree includes the root Three nodes 11, Quartz, and 12 constituting instances of the Inventory class are nodes subordinate to the root Three nodes NET1, NET2 and NET3 constituting instances of the Network class are nodes subordinate to the Quartz node Finally, in this tree, each node NET1, NET2 and NET3 has respective subordinate nodes (DEV1, DEV2, DEV3), (DEV4, DEV5, DEV6), (DEV7) instances of the Equipment class.
  • the context of a request is defined as being the set of parameters describing all the elements of a request:
  • B attributes has variable B operators, etc.
  • variable V a variable defined on a class X
  • the class X can be the class Inventory, the class Network or the class Equipment
  • a variable V can have the following form
  • V attl ⁇ op> F (att2) ⁇ op> W ⁇ op> G (Z) where attl, att2 are attributes of class X,
  • W, Z are variables internal or external to class X F, G are functions that apply to variables
  • ⁇ op> is any arithmetic operator
  • a filter is a set of expressions based on the values of the attributes of a given class.
  • a filter can be broken down into several expressions which can be combined via the boolean operators AND- OR - NOT known to skilled man
  • the processing of this request works on two different subsets of instances for the same class Network
  • the first subset consists of the instances of the class Network class IPA network and the second subset is the instances of the class Network of class IPB
  • the instances of the class Network of class of network IPA and IPB will be noted network A and network B respectively
  • the solution consists of a series of steps
  • Stage 1 a first stage consists in defining the operators which intervene in the request R1 These operators are for the majority inspired by relational algebra, supplemented by the concept of variables making it possible to carry out calculations on the data and to relate the classes between them Annex 1 gives an example of operators and the associated function found on an OPENMASTER type machine. For example, there are fundamental operators such as filtering, joining set tests (Is-m, Exists, Contains,), sorting, grouping (GROUP BY), operator Unique, etc. Aggregation functions on variables or attributes like SUM, MIN, MAX, COUNT, AVG, are also available
  • Stage 2 a second stage consists in determining the final class also called class of exit, for the first and the second subquery
  • This class of output is the class on which one selects the attributes and variables results
  • the two subqueries admit the same input class, and therefore will be launched on the same input instance
  • the input class corresponds to the Inventory class of the class tree.
  • the global query relates to a Quartz instance of this Inventory class
  • the global query must therefore have the Root class as input class
  • a global request relates to one or more base instances whose class must correspond with the starting class of the global request
  • the solution is to share the data between at least two subqueries.
  • the two subqueries will interact in the sense that they will both share at least one variable.
  • Step 3 the solution includes a third step of building the request. This building step can be carried out in two ways.
  • a first way consists in creating the request in a unitary manner More precisely, we create a sub-request and we save it as being a sub-request of a multiple request Successively, we create and save the other sub-requests as subqueries of a same request According to a preferred variant, the system is responsible for dynamically creating pointers which will link all the created subqueries The link of all the subqueries constitutes the multiple request
  • a second way consists in creating the request in a decomposed way.
  • the sub-requests are created independently of each other.
  • the user selects the last request created and then selects a functionality of the own system. to establish in the context of a request reverse chaining This reverse chaining is provided by pointers
  • V_AVG AVG (number of devices for the network) (2) B On the Inventory class (entry class and final class)
  • expression (1) is a filter on the attribute named "IP class of the Network" whose value is A Pius precisely, expression (1) is a filter on all networks A and therefore eliminates all networks B
  • expression (2) the variable A_AVG consists of an aggregation function AVG which calculates for all networks A the average of the number of devices
  • the request comprising an aggregation function, the processing of this request only relates to a subset of instances which includes the IPA attribute
  • the definition of network filter A eliminates networks B, and vice versa
  • the solution therefore consists in exporting, in the first sub-request SRO, the result obtained on the Network class in the final inventory class
  • the inventory class includes a single Quartz instance We therefore define on this class a variable moy_dev i ⁇ itia sé to the value obtained V_AVG in the class Network
  • the result attributes appear in an M1 matrix.
  • this second sub-query SR1 The method of construction of this second sub-query SR1 is the same as previously.
  • a double filter is carried out.
  • B expression (6) is a filter on the attribute number of equipment which must be greater than an average
  • (7) we choose the attributes that we want to display in a matrix M2 In the example illustrated, the attributes IP address of the network, number of devices for this network, avgDev will appear in this M2 matrix
  • moy_dev is a variable shared between the two subqueries For SR1 to have visibility of this shared variable in SRO, this variable must be defined on the final class of SRO In l illustrated example, the final class of SRO is the Inventory class Step 4:
  • Step 5 Another step consists, during the validation of the sub-queries, in establishing a temporal order of execution of the sub-queries and in providing each sub-query with at least one pointer to respect the order of execution.
  • a pointer can be an attribute.
  • the first and last subquery includes a single pointer.
  • the intermediate subqueries include two pointers. The function of a pointer is mentioned in one of the following steps. In the example illustrated, the execution of the sub-request SRO precedes the execution of the sub-request SR1.
  • a fourth step consists in executing the request This execution consists in selecting and launching the last sub-request having selected the starting instance to which the multiple request relates.
  • the execution of such a request is possible on condition that the subqueries admit the same starting class, and therefore are launched on the same starting instance
  • the starting instance is the Quartz instance If the input classes differ, we choose the Root class as the input class
  • Step 7 During the execution of the last sub-request SR1, the system detects the presence of a multiple request A chaining mechanism is executed by the system
  • the chaining mechanism is software and consists
  • the two subqueries include a single respective pointer (R1, P1)
  • the pointer P1 points to the first SRO subquery
  • the pointer R1 points to the second subquery
  • Step 8 A sixth step is to display the results preferably in a matrix.
  • the columns represent the selected result attributes and the rows the instances that check the subquery (s).
  • a multiple query RM can be considered as the sequence of n sub queries noted SRi, i varying from 1 to n:
  • RM SRO + SR1 + SR1 + ... + SRi + ... SRn
  • the execution of RM consists in launching the execution of the last subquery SRn, more precisely that for which one wishes to obtain the results.
  • the user therefore conventionally launches the execution of SRn by having previously selected the input instance to which the multiple request RM relates.
  • the sub-requests SRO and SRn comprise a respective pointer R0 and Pn.
  • the intermediate sub-requests SRj comprise two pointers Pj and Rj.
  • the system detects in SRn the presence of a multiple request RM.
  • the sub-request SRj includes a pointer Pj to point towards the towards the sub-request SRj-1 of position (j-1), and
  • SRi starting with the first SRO, an SRi sub-request being activated if and only if the execution of the position sub-request SRi-1 (i-1) has ended.
  • the same SRj sub-request includes another pointer Rj to point towards the towards the sub-request SRj + 1 of position
  • VPi be a variable shared between SRi and SRj
  • the shared variable VPi can be a parameter of an aggregation function F in the subquery SRj
  • this shared variable VPi must therefore be defined on the final class of the SRi subquery
  • SRj on class X for an instance Xk of class X can have two values
  • the shared variable VPi is calculated normally as for the execution of a non-multiple query
  • V attl ⁇ op> F (att2) ⁇ op> W ⁇ op> G (Z) WHERE attl, att2 are attributes of class X, Class X can be either Inventory class, Network class or Equipment class , and attl, att2 can be indifferently attributes of I one of the classes, W, Z are variables internal or external to the class X, F, G are functions which apply to variables, and ⁇ op> is a any arithmetic operator
  • variable V is calculated for each instance of class X
  • Vi be the calculated value of the variable V for the instance Xi of class X, and Pi the father instance of the instance Xi Among others, for each calculated value Vi of the instance Xi
  • dev_Name is an external variable which does not include an aggregation function
  • fDev takes the value of dev_Name calculated for the first instance of the Equipment class compatible or attached to this instance in tree
  • nbDEV LENGTH (dev_Name)
  • this dev_Name variable is an external variable including an aggregation function.
  • this variable is evaluated with the list of dev_Name calculated for the instances attached (compatible) to the current network
  • nbDev will therefore be the number of devices attached to the network fl
  • alINetw List (network name)
  • the network name attribute is evaluated with the list of network names for the parent instance of the current network (HERE the Inventory entry), to all networks
  • rule 3 states that F (att2) is calculated with the list of values of the attribute att2 of instances Xi subordinate to Pi if F is an aggregation function
  • the big problem is that if the request includes an aggregation function, the processing of this request only relates to a subset of compatible instances of a given class.
  • the compatibility rule intervenes as soon as 'a variable in a query refers to an external variable It is the same for operators and filters specifying variables in their expressions
  • Such operators and filters are based on a notion of compatibility of FDN distinctive names limiting the processing of a request to a subset of instances of a given class.
  • a request can relate to arbitrary instances of a class of. the containment tree
  • the second solution consists in creating an additional operator NoComp allowing to inhibit on a given class the rules of compatibility on instances in order to process a request, not on a subset of instances of the class, but on the set of instances of a class
  • an R3 request concerned by the problem cited above can be of the type "For each network, give the percentage of the number of devices recorded in the capacity tree compared to the total number of SNMP type equipment »
  • nbDev LENGTH (dev_Name)
  • prctDev Number of devices / nbDev
  • the LENGTH function is given in appendix 1 This aggregation function is chosen as an example of illustration of the fact that its execution is based on compatibility rules This choice is arbitrary in the sense that another aggregation function relying on the same rules could have been chosen as an example PrctDEV calculates the percentage of the number of devices registered in a given network compared to the total number of networks Writing this request poses two problems
  • nbDev calculates, for a network, the number of compatible devices and not on the total number of devices of SNMP type
  • the user builds the request by disregarding the compatibility rules, in the calculation of variables, or in the execution of certain operators
  • a NoComp operator of software type is created Consider, for example, a class X and VX a variable of this class X
  • This new Nocomp operator has, among other things,
  • the second solution can consist of a series of steps step 1
  • nbDev variable calculates well for a network the total number of SNMP equipment.
  • a second step consists in reading all the instances concerned by the request. We extract, from the instances read, the value of the attribute object of the query which is included in the respective instance.
  • a third step consists in memorizing, in any memory of the system, the values of the attributes of the instances read
  • Step 4 A fourth step consists in executing the request taking into account the values obtained in step 3.
  • the operator created specific to the second solution gives a user the possibility of inhibiting the compatibility rules on instances.
  • a query is no longer limited to a subset of instances of a class.
  • the user can now consider in a single request all the instances of a class.
  • the operator can now apply a join operator or a set test on non-compatible instances of the capacity tree via a single request.
  • the user is not forced to duplicate the variables, this duplication being cumbersome to implement and overloading the writing of the query.
  • a third big problem, mentioned in the introduction, is related to the presence of the same class at different levels in the class tree. Indeed, the GDMO model allows the same object class to be subordinated to several different classes in the class tree
  • this tree includes three types of class.
  • the root class is, for example, the Inventory class.
  • Two classes Note and Network of this tree are subordinate to the class Inventory.
  • the same Note class is subordinate to the Network class.
  • Another containment tree comprising instances of the class tree.
  • a Quartz instance is an instance of the Inventory class.
  • Three Notel, Note2 and Note3 instances of the Note class are subordinate to the Quartz instance.
  • An instance K of the Network class is subordinate to the Quartz instance.
  • two Notel and Note4 instances are subordinate to instance K.
  • the same instance of the same class can be located at two different levels of the containment tree
  • the problem resides HERE in the treatment of the difference, or of the intersection or of union in the same request on instances of the same class located at different levels of the tree
  • R5 query can be of the type "Give, for a Quartz instance of the Inventory class, the list of instances of the Note class attached, but not appearing in any other indirectly subordinate Note class"
  • the result of this request includes all instances of the Note class attached to the Quartz instance, removing the instances that appear under the classes indirectly attached to the Network class
  • a final example of an R6 request can be of the type "Give for the Quartz instance, the list of instances of the Note class directly attached to this Quartz instance and appearing in each of the other Note classes indirectly subordinate"
  • the third solution consists in providing three new operators B a union operator suitable for unifying instances of the same class located at different levels of the class tree, B a difference operator suitable for performing a subtraction between instances of the same class located at different levels of the class tree, B an intersection operator capable of intersecting between instances of the same class located at different levels of the class tree
  • the third solution therefore consists in having operators allowing the union, the difference, and the intersection of classes located at any level in a hierarchical object environment.
  • the third solution may consist of another series of steps
  • This embodiment uses the variable mechanism and therefore the rules for evaluating variables and therefore the rules for compatibility on instances.
  • a first step is to introduce these three operators into the list of existing operators (see Annex 1)
  • a graphical interface visible on a computer screen visualizes the class tree
  • a class in this tree appears for example in the form of an icon Icons are, for example, linked by branches
  • the user can therefore manipulate the nodes of the tree through a mouse
  • Stage 3 The third step is to select the classes located at different levels of the containment tree and subject to union, difference or intersection.
  • source class the class from which the operation starts (final class).
  • target class the class pointed to by an operation.
  • the selection of a class is carried out by clicking on a mouse button, this selection causing the associated icon in the tree to be highlighted.
  • a fourth step is to display on the final class, a MEN menu presenting the different operators present in the system.
  • This menu includes the object operators of the third solution.
  • This step consists of selecting an operator from the menu which can be Union, Difference or Intersection on the final class.
  • the icons selected and coinciding with the final class are memorized for the operation (a window of filter type appears on the screen).
  • a sixth step is to apply the operator and display the results.
  • An operator according to the invention performs an operation between nodes of the same class of the class tree, more precisely between the source class and at least one target class. Let X be the final class to which the requests R4, R5, and R6 apply.
  • A) The operation of the Union operator is defined by the following definitions: B a- The Union operator can only be applied to the final class X of the query, B b- the target classes of the union must belong to the same class as the source class, B c- the result of l 'operation is the union of the instances which are results of the class X and the instances of the classes compatible with the instances of the source class (final class X), B d- and there is no control of duplication of instances for the result.
  • B The operation of the Difference operator is defined by the following definitions: B a- The Difference operator can only be applied to the final class X of the request, B b- the target classes of this operator must belong to the same class as the source class,
  • B b- the target classes of this operator must belong to the same class as the source class
  • B c- the result of the operation is the intersection of DN names between the instances which are results of the final class and between the instances compatible with target classes.
  • NotelD is a DN naming attribute previously defined.
  • ID is a numeric value.
  • the request R4 can be constructed in accordance with this sequence of steps.
  • the request R5 can be constructed.
  • the request R6 can be constructed. First, we select with the mouse target classes NOTE in the class tree.
  • the second solution relates to a method of interrogation, in a computer system, by means of at least one request from at least one object included in at least one capacity tree included in at minus a machine based on the CMIP type management protocol, a request consisting of an update or a consultation of the objects of the capacity tree, a request including a context comprising all the parameters (classes, attributes , operators, variables, etc.) describing all the elements of a request, at least one parameter based on the compatibility rule between instances limiting the processing of the request to a subset of instances of a class, characterized in that it consists in creating an operator capable of inhibiting, on a given class, the compatibility rules on instances so as to process the request on all the instances of the class on which por you request.
  • the second solution consists, once the compatibility rules are inhibited, in reading the attributes of the instances to which the request relates, and in that it consists in memorizing these values in any memory of the computer system.
  • the method of the second solution consists, for example, at the time of the execution of the request to take into account this new operator and during of the execution to process the request with the values of the attributes of the instances read beforehand without using the compatibility rules.
  • the preceding example embodiment shows that the operator evaluates any external variable referencing a variable VX of a class X in an aggregated manner with the values of the variable VX calculated for all the instances read on the class X. Similarly , the operator evaluates a variable of class X referencing an attribute with an aggregation function with the values of the attribute of all the read instances of class X.
  • This third solution offers a definite advantage in that it gives the possibility of performing unions, differences and intersections between classes in a hierarchical object environment, like union clauses and differences in SQL.

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)
  • Computational Linguistics (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention a pour objet un procédé d'interrogation, dans un système informatique, par l'intermédiaire d'au moins une requête d'au moins un objet inclus dans au moins un arbre de contenance inclus dans au moins une machine se reposant sur le protocole de gestion de type CMIP, une requête consistant en une mise à jour ou en une consultation des objets de l'arbre de contenance, une requête incluant un contexte comprenant l'ensemble des paramètres (classes, attributs, opérateurs, variables, etc.) décrivant tous les éléments d'une requête, au moins un paramètre se reposant sur la règle de compatibilité entre instances limitant le traitement de la requête à un sous-ensemble d'instances d'une classe, caractérisé en ce qu'il consiste, à créer un opérateur propre à inhiber, sur une classe donnée, les règles de compatibilité sur instances de façon à traiter la requête sur l'ensemble des instances de la classe sur lesquelles porte la requête.

Description

Titre : Procédé d'accès, dans un système informatique, à des objets d'un arbre de contenance.
La présente invention a pour objet, dans un système informatique, un procédé d'accès à des objets d'un arbre de contenance
L'arbre de contenance est inclus dans un système de gestion Le système informatique peut contenir plusieurs systèmes de gestion Le terme gestion sera utilisé pour être conforme à la traduction Afnor (Association Française de NORmaiisation) de « Management » Egalement, le terme arbre de contenance sera utilisé comme traduction du terme MIB (Management Information Base) issu de la norme OSI (Open Systems Interconnection)
Un système informatique comprend une machine ou plusieurs machines reliées au système de gestion par l'intermédiaire d'un réseau LAN (Local Area Network), WAN (Wide Area Network) ou INTERNET Ce système peut être un système distribué ou non, hétérogène ou non
Un système distribué est un environnement de système informatique qui fonctionne au moyen d'au moins deux systèmes d'exploitation identiques ou différents Une machine est associée à un système d'exploitation Une machine comprend au moins une ressource physique (par exemple des réseaux, des concentrateurs, des segments, etc) ou logique (par exemple une base de données, etc.).
Un système informatique hétérogène contient en général une variété de protocoles de gestion Dans ce système, chaque machine est associée a au moins un protocole de gestion
Dans ce système informatique, au moins un agent est, en général situé sur une machine du système informatique Un agent traite des requêtes qui lui sont adressées Un agent logiciel gère et met à jour des données sur la machine sur laquelle il est situé Chaque agent supporte un protocole tel que le protocole SNMP (Simple Network Managment Protocol), le protocole CMIP (Common Managment Information Protocol), le protocole DSAC (Distπbuted Systems Administration and Control) ou d'autres protocoles Le système de gestion commande les agents, et l'agent répond et notifie des événements en utilisant un protocole de gestion identique SNMP, CMIS/CMIP ou DSAC/AEP (DSAC Administrative Exchange Protocol) Le système de gestion comprend plusieurs agents dits « agents intégrateurs » en ce sens qu'ils sont intégrés au système de gestion Les agents et les agents intégrateurs du (des) système(s) de gestion coexistent et communiquent pour masquer l'hétérogénéité du réseau
Dans ce système informatique, un système de gestion de machines d'un système informatique de type OPENMASTER (marque déposée par la société BULL S A ), connue de l'homme du métier, est particulièrement bien adapté Ce système utilise des services CMIS (Common Managment Information Services) normalisés, connus de l'homme du métier Ce système de gestion peut être assimilé à un ensemble de services qui iπteragissent entre eux pour donner une représentation virtuelle du monde réel qui est le système informatique C'est une représentation virtuelle qu'un administrateur manipule (surveillance, action) pour gérer le monde réel La représentation virtuelle porte sur des objets virtuels du monde réel et constitue un modèle objet Cette représentation virtuelle est concrétisée par l'intermédiaire d'un arbre de contenance
Par définition, l'arbre de contenance est strictement hiérarchique Le service CMIS (Common Managment Information Services) est bien adapté à la structure hiérarchique de l'arbre de contenance Dans l'exemple de mise en oeuvre, cet arbre est un logiciel conforme au protocole CMIP (Common Managment Information Protocol) Cet arbre comprend en ses noeuds l'ensemble des objets gérés par le système de gestion Par définition, un objet géré est une vue abstraite, définie pour les besoins de gestion, d'une ressource logique ou physique d'un système Une classe d'objets gérés est un ensemble nommé d'objets gérés partageant les mêmes propriétés Un attribut est une caractéristique d'un objet géré qui a un type nommé et une valeur La valeur d'un attribut d'un objet peut être consultée ou modifiée par une requête adressée à l'objet
Nommer un objet d'une classe donnée c'est choisir, conformément aux liens de nommage possibles, ce que l'homme du métier appelle le plus souvent son Full Distinguished Name FDN, c'est-à-dire choisir son supérieur dans l'arbre de nommage et choisir un nom que l'homme du métier appelle le plus souvent Distinguished Name DN vis-à-vis de ce supérieur Le nommage des objets fait appel à un arbre de nommage Chaque objet se situe dans l'arbre de nommage par rapport à un supérieur dont il est le subordonné Cette relation entre subordonnée et supérieure est spécifiée au niveau des classes par un lien de nommage (name binding en anglais) Lors de la création d'un objet, il faut choisir un seul lien de nommage parmi les liens de nommage possibles pour les objets de cette classe Plusieurs liens de nommage peuvent être définis pour une même classe, mais un objet ne peut avoir qu'un seul supérieur immédiat En d'autres termes, chaque instance de l'arbre est identifié par un FDN et un DN Le nom DN est un couple <attrιbut de nommage><valeur> qui permet l'identification unique d'une instance de l'arbre de contenance par rapport à une instance père Le nom FDN d'une instance est une suite de noms DN montrant le chemin de la racine jusque cette instance
De manière générale et connue de l'homme du métier, pour créer un objet dans cette base, il faut choisir sa classe, le nommer conformément aux liens de nommage relatifs à la classe, et donner une valeur à ses attributs
Un arbre de contenance est un arbre constitué d'instances de classes Actuellement, il est possible de construire une requête de consultation ou de mise à jour de l'arbre de contenance et de l'exécuter Un gros problème est que les opérateurs reposent sur une notion de compatibilté de noms FDN
Par définition, deux noms FDN sont compatibles si et seulement si leurs sous-FDN calculés sur le sous-arbre de classes commun depuis la racine sont identiques On dira par la suite que deux instances sont compatibles si leurs noms FDN sont compatibles
Considérons un arbre de contenance comprenant une racine, quatre instances subordonnées ai , a2, b1 , et b2 à cette racine Les instances (a1 ,a2) appartiennent à la même classe A et (b1 ,b2) appartiennent à la même classe B Considérons également que l'arbre comprend trois instances (d1 , d2 et d3) subordonnées à l'instance b1 et trois instances (d , c2 et c3) subordonnées à l'instance b2 Les instances (d1 , d2 et d3) appartiennent à une classe D et les instances (d , c2 et c3) appartiennent à la classe C
Dans cet arbre, les instances d1 et d2 sont compatibles car elles admettent sur le sous-arbre commun des classes (classe B) le même nom distinctif FDN à savoir b1 Par contre, les instances d1 et c2 ne sont pas compatibles car elles admettent un sous-FDN respectif b1 et b2 différent sur le sous-arbre commun des classes (classe B) Les instances b1 et d3 sont compatibles car elles sont attachées par l'intermédiaire d'une branche dans l'arbre de contenance De même les instances ai et b2 sont compatibles car elles sont toutes deux directement attachées à la racine de l'arbre de contenance
Cette notion de compatibilité découle naturellement B du modèle hiérarchique de données de l'arbre de contenance,
« et face aux grands volumes de données inclus dans I arbre, il traite et combine entre elles uniquement les instances ayant un lien de parenté (directement ou indirectement attachées par une branche de l'arbre de contenance) Le gros problème est que les traitements entre instances de classes différentes s'effectuent pour les reseaux évoqués précédemment entre instances compatibles entres elles (agrégation de variables externes, opérateurs de jointure, ) Or certains types de requêtes nécessitent une abstraction de ces règles de compatibilité de noms FDN, et nécessitent des calculs dans l'arbre de contenance non pas sur des instances compatibles entre elles mais sur des instances de classes quelconques de l'arbre D'une manière générale, la règle de compatibilité intervient dès qu'une variable d'une requête fait référence à une variable externe II en est de même pour les opérateurs (de jointure par exemple) et filtres spécifiant des variables dans leurs expressions On qualifiera d'interne toute variable définie sur la classe courante et d'externe toute variable définie sur d'autres classes que la classe courante
Un premier but de la solution est donc de donner la possibilité à un concepteur de requêtes de créer une requête dont le traitement ne se limite pas à un sous-ensemble d'instances d'une classe de l'arbre de classes
Un deuxième but visé est de procurer au système une puissance d'interrogation de l'arbre de contenance à l'image des clauses dites « Select » du langage SQL connues de l'homme du métier
A cet effet, la solution a pour objet un procédé d'interrogation, dans un système informatique, par l'intermédiaire d'au moins une requête d'au moins un objet inclus dans au moins un arbre de contenance inclus dans au moins une machine se reposant sur le protocole de gestion de type CMIP, une requête consistant en une mise à jour ou en une consultation des objets de l'arbre de contenance, une requête incluant un contexte comprenant l'ensemble des paramètres (classes, attributs, opérateurs, variables, etc ) décrivant tous les éléments d'une requête, au moins un paramètre se reposant sur la règle de compatibilité entre instances limitant le traitement de la requête à un sous- ensemble d'instances d'une classe, caractérise en ce qu'il consiste, à créer un opérateur propre à inhiber, sur une classe donnée, les règles de compatibilité sur instances de façon à traiter la requête sur l'ensemble des instances de la classe sur lesquelles porte la requête
Description d'un exemple illustrant la solution.
La solution apportée sera mieux comprise à la lecture de la description qui suit donnée à titre d'exemple
La solution peut s'appliquer à un système informatique distribué de type hétérogène Dans l'exemple illustré, ce système inclut au moins un système gestionnaire et au moins une machine distante associée à un protocole de gestion. Le système de gestion peut être compris dans une station de travail Dans l'exemple, on a représenté une machine distante. Une machine comprend des objets manipulables. Une manipulation inclut des commandes connues de l'homme du métier. Le protocole de gestion de la machine peut- être indifféremment un protocole de type SNMP, CMIS/CMIP ou DSAC/AEP. Dans notre exemple, le système supporte un protocole de type CMIS conforme au modèle OSI (Common Managment Information service), connu de l'homme du métier Cette application peut être lancée par l'intermédiaire d'un utilisateur de ce système de gestion. Un utilisateur peut être un administrateur Le système gestionnaire comprend également au moins un agent intégrateur associé à un protocole de gestion afin de masquer l'hétérogénéité du système informatique. Dans l'exemple illustré, un agent intégrateur est associé au protocole de gestion de la machine De façon générale, un agent intégrateur est de type logiciel. Il procure des services Un service peut être une conversion du protocole de gestion Dans l'exemple illustré, l'agent intégrateur convertit le protocole de gestion du système de gestion en un protocole de gestion associé à la machine Réciproquement, l'agent intégrateur convertit le protocole de gestion associé à la machine en un protocole de gestion associé au système de gestion Un agent intégrateur ne se limite pas à ce type de service et procure d'autres services. De manière générale, une conversion de protocole de gestion s'effectue naturellement entre un système de gestion et une machine qui supportent des protocoles de gestion différents
Naturellement, le serveur de gestion peut comprendre plusieurs agents intégrateurs L'agent intégrateur est relié à la machine par l'intermédiaire d'un réseau de type quelconque Le réseau peut être de type LAN (Local Area Network) ou WAN (Wide Area Network) Un ensemble de couches logicielles s'interpose entre le système de gestion et le réseau et entre le réseau et la machine Cet ensemble de couches logicielle repose sur le modèle OSI (Open System Interconnection) d'architecture en couche de l'ISO (International Organization for Standardization), connu de l'homme du métier
Dans l'exemple illustré, une requête issue du système de gestion est transmise à l'agent Une requête est, de manière générale, une manipulation d'objets sur une machine distante. La construction d'une requête est expliquée dans la suite de la description Le système de gestion comprend aussi un arbre de contenance associé à l'agent
L'arbre de contenance peut être entièrement compris dans l'agent. Cet arbre assure une représentation virtuelle du monde réel qui entoure le système de gestion C'est une représentation virtuelle que l'utilisateur ou qu'un administrateur manipule (surveillance, action) pour gérer le monde réel La représentation virtuelle porte sur des objets virtuels du monde réel et constitue un modèle objet. Dans l'exemple illustré, le monde réel est matérialisé par le machine.
Par définition, l'arbre de contenance est oriente objet et est constitué de noeuds et de branches Cet arbre comprend en ses noeuds l'ensemble des objets gérés par le système de gestion De manière générale et connue de l'homme du métier, pour créer un objet dans cette base, il faut choisir sa classe, le nommer conformément aux liens de nommage relatifs à la classe, et valoriser ses attributs. Un objet géré est une vue abstraite, définie pour les besoins de gestion, d'une ressource logique ou physique d'un système Dans l'arbre de contenance, des noeuds appartiennent à une même classe. Un arbre de classes est créé. Dans l'exemple illustré, l'arbre de classes comprend 3 classes " B une classe Inventaire, B une classe Network qui représente les réseaux découverts et est défini par des attributs .
• adresse IP du réseau,
• état du réseau (bloqué ou libre),
• nombre d'équipements pour le réseau, • classe IP du réseau (A, ou B, ou C,...),
• adresse IP de l'équipement ayant permis la découverte du réseau,
• etc
B une classe Equipement qui représente les réseaux découverts. Cette classe comprend des attributs : • adresse IP de l'équipement,
• type de l'équipement (passerelle, concentrateur, etc.),
• type d'équipement SNMP : oui/non
• classe IP du réseau ( IPA, ou IPB, ou IPC, etc.),
• nom de l'équipement, • adresse IP de l'équipement ayant permis la découverte de l'équipement,
• etc.
La valorisation de ces attributs conduit à l'arbre de contenance. Cet arbre de contenance comprend la racine Trois noeuds 11 , Quartz, et 12 constituant des instances de la classe Inventaire sont des noeuds subordonnés à la racine Trois noeuds NET1 , NET2 et NET3 constituant des instances de la classe Réseau sont des noeuds subordonnés au noeud Quartz Enfin, dans cet arbre, chaque noeud NET1 , NET2 et NET3 a des noeuds subordonnés respectifs (DEV1 , DEV2, DEV3), (DEV4, DEV5, DEV6), (DEV7) instances de la classe Equipement. Considérons à nouveau la requête R1 énoncée dans l'introduction : « Dans l'inventaire Quartz, donner la liste des réseaux de classe IPB dont le nombre d'équipements est supérieur à la moyenne du nombre d'équipements des réseaux de classe IPA ».
Il est nécessaire d'apporter quelques définitions qui serviront à la compréhension de la description.
Rappelons la définition d'un contexte de requête. Le contexte d'une requête se défini comme étant l'ensemble des paramètres décrivant tous les éléments d'une requête :
B filtres
B classes
B attributs a opérateurs B variables, etc
Considérons V une variable définie sur une classe X Dans l'exemple illustré, la classe X peut être la classe Inventaire, la classe Réseau ou la classe Equipement On qualifiera d'interne toute variable définie sur la classe X et d'externe toute variable définies sur d'autres classes que la classe X Une variable V peut avoir la forme suivante
V = attl <op> F(att2) <op> W <op> G(Z) où attl , att2 sont des attributs de la classe X,
W, Z sont des variables internes ou externes à la classe X F, G sont des fonctions qui s'appliquent sur des variables
<op> est un opérateur arithmétique quelconque
Rappelons qu'un filtre est un ensemble d'expressions basées sur les valeurs des attributs d'une classe donnée Un filtre peut être décomposé en plusieurs expressions qui peuvent être combinées par l'intermédiaire des opérateurs booléen AND- OR - NOT connus de l'homme du métier
Rappelons également, dans l'exemple illustré, qu'au moins une variable est définie pour une classe donnée et que son évaluation repose sur des règles formelles citées ci-dessus Par exemple, une expression ne peut renvoyer qu'à des attributs de la classe courante De plus, une expression peut référencer des variables locales ou des variables externes définies sur une autre classe que la classe courante La résolution de cette requête impose la décomposition en plusieurs sous-requêtes Le gros problème, tel qu'énoncé dans l'introduction, est qu'il n'existe pas de moyens de décomposition d'une requête en sous-requêtes
Le traitement de cette requête travaille sur deux sous-ensemble d'instances différents pour la même classe Réseau Le premier sous-ensemble est constitué par les instances de la classe Réseau de classe réseau IPA et le deuxième sous-ensemble est les instances de la classe Réseau de classe IPB Pour des raisons de simplifications de la description, les instances de la classe Réseau de classe réseau IPA et IPB seront notées réseau A et réseau B respectivement
Cette requête pose un gros problème de conception avec les opérateurs actuels Ainsi, la définition d'un filtre sur les réseaux A élimine les réseaux B, et vis versa Dans l'exemple illustré, l'interprétation de la requête R1 conduit donc à créer deux sous-requêtes
B une première sous-requête SRO qui calcul, dans l'inventaire Quartz, la moyenne des équipements pour les réseaux A B une deuxième sous-requète SR1 qui sélectionne, toujours dans l'inventaire Quartz, les réseaux B dont le nombre d'équipements est supérieur à la moyenne calculée par l'intermédiaire de la première sous-requête SRO
Dans l'exemple illustré, la solution consiste en une suite d'étapes
Etape 1 une première étape consiste à définir les opérateurs qui interviennent dans la requête R1 Ces opérateurs sont pour la plupart inspirés de l'algèbre relationnel, complétés par le concept de variables permettant d'effectuer des calculs sur les données et de mettre en relation les classes entre elles L'annexe 1 donne un exemple d'opérateurs et la fonction associée que l'on trouve sur une machine de type OPENMASTER Par exemple, on trouve des opérateurs fondamentaux comme le filtrage, la jointure les tests ensemblistes (Is-m, Exists, Contains, ), le tri, le groupement (GROUP BY), l'opérateur Unique, etc Des fonctions d'agrégation sur variables ou attributs comme SUM, MIN, MAX, COUNT, AVG, , sont également disponibles
Etape 2 une seconde étape consiste à déterminer la classe finale appelée aussi classe de sortie, pour la première et la seconde sous-requête Cette classe de sortie est la classe sur laquelle on sélectionne les attributs et variables résultats On détermine cette classe de sortie en fonction de la requête globale à exécuter Par opposition, lorsqu'une requête est exécutée, elle commence par une instance de la classe d'entrée Par construction, dans l'exemple illustré, les deux sous-requêtes admettent la même classe d'entrée, et donc seront lancées sur la même instance d'entrée Dans l'exemple illustré, la classe d'entrée correspond à la classe Inventaire de l'arbre des classes. La requête globale porte sur une instance Quartz de cette classe Inventaire Dans un autre exemple, si les instances d'entrée sont différentes entre sous-requêtes, la requête globale doit donc avoir comme classe d'entrée la classe Racine
De manière générale, une requête globale porte sur une ou plusieurs instances de base dont la classe doit correspondre avec la classe de départ de la requête globale
La solution consiste à partager les données entre au moins deux sous- requêtes. Les deux sous-requêtes vont interagir en ce sens qu'elles vont toutes deux partager au moins une variable.
Etape 3 Dans l'exemple illustré, la solution comprend une troisième étape de construction de la requête Cette étape de construction peut être réalisée de deux manières
- Un première manière consiste à créer la requête de manière unitaire Plus précisément, on crée une sous-requête et on l'enregistre comme étant une sous requête d'une requête multiple Successivement, on crée et on sauvegarde les autres sous-requêtes comme étant des sous-requêtes d'une même requête Selon une variante préférée, le système à la charge de créer dynamiquement des pointeurs qui vont lier toutes les sous-requêtes créées Le lien de toutes les sous-requêtes constitue la requête multiple
- Une seconde manière consiste a créer la requête de façon décomposée On crée les sous-requêtes indépendamment l'une de l'autre Afin de lier les sous- requêtes, l'utilisateur sélectionne la dernière requête créée et sélectionne ensuite une fonctionnalité du système propre à établir dans le contexte d'une requête un chaînage inverse Ce chaînage inverse est procuré par l'intermédiaire de pointeurs
Dans la description, on choisit comme exemple d'illustration le mode unitaire
Dans un exemple, la première sous-requête SRO a la forme suivante B Sur la classe Réseau • Filtre classe IP du réseau = A (1 )
• variable V_AVG=AVG (nombre d'équipements pour le réseau) (2) B Sur la classe Inventaire (classe d'entrée et classe finale)
• variable moy_dev = V_AVG (3)
• attributs résultat (facultatif) Identificateur de l'instance d'inventaire, moy_dev (4)
Dans cette première sous-requête, l'expression (1 ) est un filtre sur l'attribut nommé « classe IP du Réseau » dont la valeur est A Pius précisément, l'expression (1 ) est un filtre sur tous les réseaux A et élimine donc tous les réseaux B Dans l'expression (2), la variable A_AVG est constitué d'une fonction d'agrégation AVG qui calcule pour tous les réseaux A la moyenne du nombre d'équipements La requête comprenant une fonction d'agrégation, le traitement de cette requête ne porte alors que sur un sous- ensemble d'instances qui inclut l'attribut IPA La définition du filtre réseau A élimine les réseaux B, et vis versa La solution consiste donc a exporter, dans la première sous-requête SRO, le résultat obtenu sur la classe Réseau dans la classe finale Inventaire La classe inventaire comprend une seule instance Quartz On défini donc sur cette classe une variable moy_dev iπitia sé à la valeur obtenue V_AVG dans la classe Réseau
Dans l'exemple illustré, les attributs résultats apparaissent dans une matrice M1 On choisi de faire apparaître dans cette matrice l'identificateur de l'instance sur laquelle est lancée la requête multiple et la valeur obtenu moy_dev, c'est-à-dire la moyenne obtenue
Dans notre exemple, la seconde sous-requête SR1 a la forme B Sur la classe Réseau (classe finale) Filtre classe IP du réseau = B (5) nombre d'équipements > moy_dev (6) attributs résultats adresse IP du réseau, nombre d'équipements pour ce réseau, avgDev (7)
B Sur la classe d'entrée Inventaire (classe d'entrée) variable moy_dev = 100 (valeur arbitraire) (8)
Le procédé de construction de cette deuxième sous-requête SR1 est le même que précédemment On effectue un double filtre Un premier filtre sur les réseaux B et un deuxième filtre incluant un opérateur de comparaison l'expression (5) est un filtre sur les réseaux B Concrètement, B l'expression (6) est un filtre sur l'attribut nombre d'équipement qui doit être supérieur à une moyenne Dans l'expression (7), on choisi les attributs que l'on souhaite afficher dans une matrice M2 Dans l'exemple illustré, les attributs adresse IP du réseau, nombre d'équipements pour ce réseau, avgDev apparaîtront dans cette matrice M2
Dans l'expression (8), on défini une variable arbitraire Comme cette variable est partagée avec la sous-requête SRO, son exécution diffère dans le cas de l'exécution de sous-requêtes conformément a la première solution Le choix de la valeur de cette moyenne dans la seconde sous-requête diffère selon que la moyenne est une variable partagée ou non. Conformément à la solution, si cette variable est partagée, la valeur de cette moyenne est la valeur calculée dans une sous-requête. Si cette variable n'est pas partagée entre deux sous-requêtes, la variable partagée est calculée normalement comme pour l'exécution d'une requête non multiple
Pour cela, un autre aspect important de la solution est que si moy_dev est une variable partagée entre les deux sous-requêtes Pour que SR1 ait une visibilité de cette variable partagée dans SRO, cette vaπable doit être définie sur la classe finale de SRO Dans l'exemple illustré, la classe finale de SRO est la classe Inventaire Etape 4 :
Les deux sous requêtes sont archivées dans une base de données. Etape 5 Une autre étape consiste, lors de la validation des sous-requêtes, à établir un ordre temporel d'exécution des sous-requêtes et à munir chaque sous-requête d'au moins un pointeur pour respecter l'ordre d'exécution. Un pointeur peut être un attribut. Dans l'exemple illustré, la première sous-requête et la dernière inclut un seul pointeur. Eventuellement, si la requête multiple comprend au moins trois sous-requêtes, les sous-requêtes intermédiaires comprennent deux pointeurs. La fonction d'un pointeur est évoquée dans une des étapes suivantes Dans l'exemple illustré, l'exécution de la sous-requête SRO précède l'exécution de la sous-requête SR1
Etape 6 .
Une quatrième étape consiste à exécuter la requête Cet exécution consiste à sélectionner et lancer la dernière sous-requête en ayant sélectionné l'instance de départ sur laquelle porte la requête multiple. L'exécution d'une telle requête est possible à la condition que les sous-requêtes admettent la même classe de départ, et donc sont lancées sur la même instance de départ Dans l'exemple illustre, l'instance de départ est l'instance Quartz Si les classes d'entrée diffèrent, on choisi la classe Racine comme classe d'entrée
Etape 7 Lors de l'exécution de la dernière sous-requête SR1 , le système détecte la présence d'une requête multiple Un mécanisme de chaînage est exécuté par le système Le mécanisme de chaînage est logiciel et consiste
- lors d'une première phase à pointer successivement, à partir de la dernière sous-requête SR1 sélectionnée, vers la première sous-requête SRO,
- et lors d'une seconde phase à lancer séquentiellement les sous-requêtes de la première sous-requête SRO jusque la dernière sous requête SR1 , une sous- requête étant activée seulement si l'exécution de la précédente sous-requête est terminée Durant cette seconde phase, lors de l'évaluation de la variable partagée moy_dev sur la classe Inventaire pour l'instance réseau B, si il existe une valeur de moy_dev dans la première sous-requête SRO pour cette même instance, moy_dev sera calculée dans SR1 avec cette valeur déjà calculée Dans le cas contraire, si la variable moy_dev n est pas partagée et est calculée indépendamment de tout autre sous-requête selon des règles d'évaluation normale
Lors des deux phases précitées, le passage d'une sous-requête à une autre est effectué par l'intermédiaire des pointeurs Dans l'exemple de deux sous- requêtes (SRO, SR1 ), les deux sous-requêtes incluent un seul pointeur respectif (R1 ,P1 ) Lors de la première phase, le pointeur P1 pointe vers la première sous-requête SRO Lors de la deuxième phase, le pointeur R1 pointe vers la deuxième sous-requête
Etape 8 Une sixième étape consiste à afficher les résultats de préférence dans une matrice. Les colonnes représentent les attributs résultats sélectionnés et les lignes les instances qui vérifient la ou les sous-requêtes.
Par extension, une requête multiple RM peut être considérée comme la suite de n sous requêtes notées SRi, i variant de 1 à n :
RM = SRO + SR1 + SR1 + ...+ SRi + ... SRn
L'exécution de RM consiste à lancer l'exécution de la dernière sous- requête SRn, plus précisément celle pour laquelle on désire obtenir les résultats. L'utilisateur lance donc de manière classique l'exécution de SRn en ayant sélectionné, au préalable, l'instance d'entrée sur laquelle porte la requête multiple RM. Dans l'exemple illustré, les sous-requêtes SRO et SRn comprennent un pointeur respectif R0 et Pn. Les sous requêtes intermédiaires SRj comprennent deux pointeurs Pj et Rj.
Le système détecte en SRn la présence d'une requête multiple RM.
On comprend que si la requête comprend n sous-requêtes, lors de la première phase, la sous-requête SRj inclut un pointeur Pj pour pointer vers la vers la sous-requête SRj-1 de position (j-1), et
Le système lance ensuite l'exécution séquentielle des sous-requêtes
SRi, en commençant par la première SRO, une sous-requête SRi étant activée si et seulement si l'exécution de la sous-requête SRi-1 de position (i-1) est terminée. Lors de cette seconde phase, la même sous-requête SRj inclut un autre pointeur Rj pour pointer vers la vers la sous-requête SRj+1 de position
(j+ - De façon générale, soit VPi une variable partagée entre SRi et SRj Par exemple, la variable partagée VPi peut être un paramètre d'une fonction d'agrégation F dans la sous-requête SRj
Pour que la sous-requête SRj ait une visibilité de la variable partagée VPi et puisse la prendre en compte lors de son exécution, cette variable partagée VPi doit donc être définie sur la classe finale de la sous-requête SRi
Soit X cette classe finale
Lors de l'exécution de SRj, l'évaluation de la variable VPi pour la sous-requête
SRj sur la classe X pour une instance Xk de la classe X peut avoir deux valeurs
B s'il existe une valeur de VPi pour Xk dans la sous-requête SRi la variable partagée VPi sera calculée avec cette valeur calculée,
B dans le cas contraire, c'est-à-dire que l'instance Xk n'est pas une solution de la sous-requête SRi, la variable partagée VPi est calculée normalement comme pour l'exécution d'une requête non multiple
La solution donne la possibilité aux utilisateurs de concevoir des requêtes compliquées, beaucoup d'entre elles nécessitant une décomposition en sous-requêtes Cette solution évite de recourir à une programmation du type SML-CMIS de leur applicatif qui est lourde, non trivial, et très coûteux en temps Cette solution procure au système une gestion de sous-requêtes simple d'utilisation qui fournit un éventail considérable de possibilité d'interrogations non envisageables pour le concepteur de requêtes D'autre part, cette solution permet de définir de manière naturelle un enchaînement de sous-requêtes Ce concept fort doublé de la notion de partage de variables entre sous-requêtes apportent une autre dimension au pouvoir d'expression du langage, permettant ainsi des réponses simples à des requêtes compliquées Un deuxième gros problème est lié à la notion de comptabilité entre noms distiπctifs de type FDN
Revenons à l'écriture d'une variable
V = attl <op> F(att2) <op> W <op> G(Z) OÙ attl , att2 sont des attributs de la classe X, La classe X pouvant être indifféremment la classe Inventaire, la classe Réseau ou la classe Equipement, et attl , att2 pouvant être indifféremment des attributs de I une des classes, W, Z sont des variables internes ou externes à la classe X, F, G sont des fonctions qui s'appliquent sur des variables, et <op> est un opérateur arithmétique quelconque
L'évaluation des variables sur exécution d'une requête satisfait à des règles précises En effet, la variable V est calculée pour chaque instance de la classe X
(Règle 1 ) Soient Vi la valeur calculée de la variable V pour l'instance Xi de la classe X, et Pi l'instance père de l'instance Xi Entre autres, pour chaque valeur Vi calculée de l'instance Xi
B l'attribut attl est évalué avec la valeur d'attribut attl de l'instance Xi (Règle 2),
B la fonction F(att2) est calculée avec (règle 3)
* la valeur de l'attribut att2 de l'instance Xi si F n'est pas une fonction d'agrégation
* ou la liste des valeurs de l'attribut att2 des instances Xi subordonnées à Pi si F est une fonction d'agrégation
B W sera évaluée avec (Règle 4)
* la valeur Wi calculée si W est une variable interne,
* ou la première valeur calculée de W pour une instance compatible à l'instance Xi si W est une variable externe conformément à la première solution
B F(W) sera évaluée avec (Règle 5) * la liste des valeurs de W calculées pour l'ensemble des instances compatibles à Xi si W est externe,
* ou la valeur Wi calculée si W est interne
A titre d'exemple, considérons sur la classe Equipement une variable
« dev_Name = nom de l'équipement » Considérons également, sur la classe Reseau, pour une instance de la classe Réseau, l'évaluation des variables suivantes
B fDev = dev_Name cette variable dev_Name est une variable externe qui ne comprend pas de fonction d'agrégation Selon la règle 4, pour une instance de Réseau, fDev prend la valeur de dev_Name calculée pour la première instance de la classe Equipement compatible ou attachée à cette instance dans l'arbre B nbDEV = LENGTH (dev_Name) cette variable dev_Name est une variable externe comprenant une fonction d'agrégation. Selon la règle
5, cette variable est évaluée avec la liste des dev_Name calculées pour les instances attachées (compatibles) au réseau courant Comme la fonction LENGTH rend la longueur d'une liste, la variable nbDev sera donc le nombre d'équipements attachés au réseau fl enfin, alINetw = List (nom du réseau) Selon la règle 3, l'attribut nom du réseau est évalué avec la liste des noms de réseau pour l'instance père du réseau courant (ICI l'entrée Inventaire), à tous les réseaux
Lors des règles d'évaluations de variables, la règle 3 énonce que F(att2) est calculée avec la liste des valeurs de l'attribut att2 des instances Xi subordonnées à Pi si F est une fonction d'agrégation
Le gros problème est que si la requête comprend une fonction d'agrégation, le traitement de cette requête ne porte que sur un sous-ensemble d'instances compatibles d'une classe donnée D'une manière générale, la règle de compatibilité intervient dès qu'une variable d'une requête fait référence à une variable externe II en est de même pour les opérateurs et filtres spécifiant des variables dans leurs expressions
De la même façon, pour une requête comprenant au moins un filtre avec au moins une variable ou au moins un opérateur (opérateur de jointure, opérateur de tests ensemblistes), la règle de compatibilité entre instances est utilisée automatiquement, ce qui pose problème
De tels operateurs et filtres reposent sur une notion de compatibilité de noms distinctifs FDN limitant le traitement d'une requête à un sous-ensemble d'instances d'une classe donnée Or, une requête peut porter sur des instances quelconques d'une classe de l'arbre de contenance
A cet effet, la seconde solution consiste à créer un opérateur supplémentaire NoComp permettant d'inhiber sur une classe donnée les règles de compatibilité sur instances afin de traiter une requête, non pas sur un sous- ensemble d'instances de la classe, mais sur l'ensemble des instances d une classe
Afin d'illustrer ce second problème, une requête R3 concerné par le problème cité ci-dessus peut être du type « Pour chaque réseau, donner le pourcentage du nombre d'équipements enregistré dans l'arbre de contenance par rapport au nombre total d'équipements de type SNMP »
La sémantique de la requête qui en résulte peut être du type - Sur la classe Equipement variable dev_Name = Nom de l'équipement filtres SNMP = oui - et sur la classe Réseau (classe résultat)
Variables nbDev = LENGTH (dev_Name) prctDev = Nombre d'équipements/nbDev La fonction LENGTH est donnée en annexe 1 Cette fonction d'agrégation est choisie comme exemple d'illustration du fait que son exécution repose sur les règles de compatibilité Ce choix est arbitraire en ce sens qu'une autre fonction d'agrégation se reposant sur les mêmes règles aurait pu être choisie à titre d'exemple PrctDEV calcul le pourcentage du nombre d'équipements enregistres dans un réseau donné par rapport au nombre total de réseau L'écriture de cette requête pose deux problèmes
- les reseaux ne comprenant pas d'équipements SNMP sont éliminés,
- et le nombre nbDev calcule, pour un réseau, le nombre d'équipements compatibles et non sur le nombre total d'équipements de type SNMP
Selon la seconde solution, l'utilisateur construit la requête en faisant abstraction des règles de compatibilité, dans le calcul de variables, ou dans l'exécution de certains opérateurs A cet effet, un opérateur NoComp de type logiciel est créé Considérons, par exemple, une classe X et VX une variable de cette classe X Ce nouvel opérateur Nocomp a pour fonction, entre autres,
- d'évaluer toute variable externe (c'est-à-dire une variable d'une autre classe que la classe X) référençant la variable VX de manière agrégée avec les valeurs de la variable VX calculées pour l'ensemble des instances lues sur la classe X,
- d'évaluer une variable de la classe X référençant un attribut avec une fonction d'agrégation avec les valeurs de l'attribut de l'ensemble des instances lues de la classe X
- et si un filtre est défini sur la classe X, la règle de compatibilité des instances des autres classes n'est pas appliquée et les instances des autres classes non compatibles avec les instances concernées de la classe X ne sont pas éliminées
Dans notre exemple la seconde solution peut consister en une série d'étapes étape 1 Premièrement, l'utilisateur analyse la requête à traiter et détermine si la règle de compatibilité doit être inhibée en fonction de ce qui précède Si l'utilisation de la règle de compatibilité est justifiée, l'exécution de la requête R3 s'effectue normalement Si l'utilisation de la règle de compatibilité n'est pas justifiée, l'exécution de la requête R3 est différente En effet, dans l'exemple illustré, le concepteur insère l'opérateur d'inhibition Nocomp dans la requête Cet opérateur peut être appliqué sur n'importe quelle classe où sont définies des variables Dans l'exemple illustré, la requête a la forme suivante Sur la classe Equipement variable dev_Name = Nom de l'équipement filtres SNMPstate = SNMP-supporté opérateur NoComp Sur la classe Réseau (classe résultat) Variables nbDev = LENGTH (dev_Name) prctDev = Nombre d'équipements/nbDev
Ainsi, avec la seconde solution, les réseaux n'ayant pas de réseaux de type SNMP ne sont pas éliminés Au contraire, la variable nbDev calcule bien pour un réseau le nombre total d'équipement de type SNMP
Etape 2
Une deuxième étape consiste à lire toutes les instances concernées par la requête On extrait, à partir des instances lues, la valeur de l'attribut objet de l'interrogation qui est inclus dans l'instance respective
Etape 3
Une troisième étape consiste à mémoriser, dans une mémoire quelconque du système, les valeurs des attributs des instances lues
Etape 4 Une quatrième étape consiste à exécuter la requête en tenant compte des valeurs obtenues à l'étape 3.
L'opérateur créé propre à la seconde solution donne à un utilisateur la possibilité d'inhiber les règles de compatibilité sur instances. Un requête ne se limite plus à un sous-ensemble d'instances d'une classe. Au contraire, l'utilisateur peut désormais considérer dans une seule requête l'ensemble des instances d'une classe. L'opérateur peut désormais appliquer un opérateur de jointure ou un test ensembliste sur des instances non compatibles de l'arbre de contenance par l'intermédiaire d'une unique requête. L'utilisateur n'est pas contraint de dupliquer les variables, cette duplication étant lourde à mettre en œuvre et surchargeant l'écriture de la requête.
Un troisième gros problème, évoqué dans l'introduction, est lié à la présence d'une même classe à des niveaux différents dans l'arbre de classes. En effet, le modèle GDMO permet à une même classe d'objet d'être subordonnée à plusieurs classes différentes dans l'arbre de classes
A titre d'illustration, cet arbre comprend trois types de classe. La classe racine est, par exemple, la classe Inventaire. Deux classes Note et Réseau de cet arbre sont subordonnées à la classe Inventaire. Enfin, la même classe Note est subordonnée à la classe Réseau. On s'aperçoit donc que cet arbre de classes comprend une même classe Note qui se situe à des niveaux différents de l'arbre. Un autre arbre de contenance comprenant des instances de l'arbre de classes. Une instance Quartz est une instance de la classe Inventaire. Trois instances Notel , Note2 et Note3 de la classe Note sont subordonnées à l'instance Quartz. Une instance K de la classe Réseau est subordonnée à l'instance Quartz. Enfin, deux instances Notel et Note4 sont subordonnées à l'instance K. On constate également qu'une même instance d'une même classe peut se situer à deux niveaux différents de l'arbre de contenance
Le problème réside ICI dans le traitement de la différence, ou de l'intersection ou de I union dans une même requête sur des instances d'une même classe situées à différents niveaux de l'arbre
A titre d'exemples, considérons une première requête R4 à traiter « donner la liste des instances de la classe NOTE attachées à l'instance Quartz de la classe Inventaire »
On constate que le résultat réel correspond à l'ensemble des instances de la classe Note subordonnée à la classe Inventaire, mais également l'ensemble des instances de la classe Note directement ou indirectement attachées par l'intermédiaire d'une ou plusieurs instances d'autres classes distinctes de la classe Note dans l'arbre En l'espèce, les instances subordonnées à l'instance K de la classe Réseau sont une solution
Un autre exemple de requête R5 peut être du type « Donner, pour une instance Quartz de la classe d'Inventaire, la liste des instances de la classe Note attachées, mais n'apparaissant dans aucune autre classe Note indirectement subordonnée » Le résultat de cette requête comprend l'ensemble des instances de la classe Note attachées à l'instance Quartz, en retirant les instances qui apparaissent sous les classes indirectement attachées à la classe Réseau
Un dernier exemple de requête R6 peut être du type « Donner pour l'instance Quartz, la liste des instances de la classe Note directement attachées à cette instance Quartz et apparaissant dans chacune des autres classes Note indirectement subordonnées »
Le résultat de cette requête est l'ensemble des instances de la classe Note attachées à l'instance Quartz de la classe Inventaire et qui apparaissent également sous les classes indirectement attachées à l'instance Quartz A cet effet, la troisième solution consiste à fournir trois nouveaux opérateurs B un opérateur d'union propre a unifier des instances d'une même classe situées à différents niveaux de l'arbre de classe, B un opérateur de différence propre à effectuer une soustraction entre instances d'une même classe situées à différents niveaux de l'arbre de classe, B un opérateur d'intersection propre à réaliser une intersection entre instances d'une même classe situées à différents niveaux de l'arbre de classe
La troisième solution consiste donc à disposer d'opérateurs permettant l'union, la différence, et l'intersection de classes situées à un niveau quelconque dans un environnement objets hiérarchique
Selon un exemple de réalisation, la troisième solution peut consister en une autre série d'étapes
Cet exemple de réalisation fait appel au mécanisme de variable et donc aux règles d'évaluation de variables et donc aux règles de compatibilité sur instances
Etape 1
Une première étape consiste à introduire ces trois opérateurs dans la liste des opérateurs existants (voir annexe 1 )
Etape 2
Une interface graphique visible sur un écran d'ordinateur visualise l'arbre des classes Une classe de cet arbre apparaît par exemple sous la forme d'icône Les icônes sont, par exemple, reliés par des branches L'utilisateur peut donc manipuler les noeuds de l'arbre par l'intermédiaire d'une souris
Etape 3 La troisième étape consiste à sélectionner les classes situées à des niveaux différents de l'arbre de contenance et sujettes à l'union, la différence ou l'intersection. On appellera classe source la classe d'où part l'opération (classe finale). De même, on appellera classe cible la classe pointée par une opération.
De préférence, dans l'arbre de classes, la sélection d'une classe est réalisée en cliquant sur un bouton de la souris, cette sélection entraînant la surbrillance de l'icône associé dans l'arbre.
Etape 4
Une quatrième étape consiste à afficher sur la classe finale, un menu MEN présentant les différents opérateurs présents dans le système. Ce menu inclut les opérateurs objets de la troisième solution. Cette étape consiste à sélectionner un opérateur dans le menu qui peut être l'Union, la Différence ou l'Intersection sur la classe finale. Sur sélection de l'un des opérateurs booléens objets de la troisième solution, les icônes sélectionnés et coïncidant avec la classe finale sont mémorisés pour l'opération (une fenêtre de type filtre apparaît à l'écran).
Etape 6
Une sixième étape consiste à appliquer l'opérateur et à afficher les résultats. Un opérateur conforme à l'invention effectue une opération entre noeuds de même classe de l'arbre de classes, plus précisément entre la classe source et au moins une classe cible. Soit X la classe finale sur laquelle s'applique les requête R4, R5, et R6.
Le résultat diffère selon le choix de l'opérateur :
A) Le fonctionnement de l'opérateur Union est défini par les définitions suivantes : B a- L'opérateur Union ne peut s'appliquer que sur la classe finale X de la requête, B b- les classes cibles de l'union doivent appartenir à la même classe que la classe source, B c- le résultat de l'opération est l'union des instances qui sont résultats de la classe X et des instances des classes compatibles avec les instances de la classe source (classe finale X), B d- et il n'y a pas de contrôle de duplication d'instances pour le résultat.
B) Le fonctionnement de l'opérateur Différence est défini par les définitions suivantes : B a- L'opérateur Différence ne peut s'appliquer que sur la classe finale X de la requête, B b- les classes cibles de cet opérateur doivent appartenir à la même classe que la classe source,
B c- le résultat de l'opération est la différence de noms DN entre les instances qui sont résultats de la classe finale et entre les instances compatibles des classes cibles.
C) Le fonctionnement de l'opérateur Intersection est défini par les définitions suivantes :
B a- Cet opérateur ne peut s'appliquer que sur la classe finale X de la requête,
B b- les classes cibles de cet opérateur doivent appartenir à la même classe que la classe source, B c- le résultat de l'opération est l'intersection de noms DN entre les instances qui sont résultats de la classe finale et entre les instances compatibles des classes cibles.
NotelD est un attribut de nommage DN défini précédemment. Dans l'exemple illustré, Le terme ID est une valeur numérique. Concrètement, dans l'exemple illustré, la requête R4 peut être construite conformément à cette suite d'étapes.
Premièrement, on Sélectionne avec la souris des classes cibles NOTE dans l'arbre de classes. Deuxièmement, on sélectionne l'opérateur Union qui correspond à la requête R4 sur la classe Note subordonnée à la classe Inventaire.
Troisièmement, on obtient le résultat de la requête R4. Le résultat est : les instances Notel , Note2 et Note3 subordonnées à l'intance Quartz et les instances Note 1 et Note4 subordonnées à l'instance K. Dans ce résultat, conformément aux fonctionnement de l'opérateur Union, deux instances du résultat ont le même nom DN (Notel ) avec des noms FDN différents. En effet, le nom DN pour les instances résultats est Notel et les noms FDN respectifs pour les instances résultats sont FDN = « quartz »/ NotelD = « Notel » FDN = « quartz »/ K/ NotelD = « Notel »
Compte tenu de ces définitions, dans l'exemple illustré, la requête R5 peut être construite.
Premièrement, on Sélectionne avec la souris des classes cibles NOTE dans l'arbre de classes.
Deuxièmement, on sélectionne l'opérateur Différence qui correspond à la requête R4 sur la classe Note subordonnée à la classe Inventaire.
Troisièmement, on obtient le résultat de la requête R5. Le résultat est les instances Note2 et Note3 subordonnées à l'instance Quartz et l'instance Note4 subordonnées à l'instance K.
Le résultat de cette requête R5 montre que l'instance Notel n'est pas incluse dans le résultat car le nom DN des deux instances Notel dans l'arbre est le même.
Compte tenu des définitions, dans l'exemple illustré, la requête R6 peut être construite. Premièrement, on Sélectionne avec ia souris des classes cibles NOTE dans l'arbre de classes.
Deuxièmement, on sélectionne l'opérateur Intersection qui correspond à la requête R6 sur la classe Note subordonnée à la classe Inventaire.
Troisièmement, on obtient le résultat de la requête R6. Le résultat est l'instance Notel . En effet, l'instance Notel subordonnée à l'instance Quartz est la seule instance de la classe Note (classe finale) pour laquelle son nom DN figure dans les instances des autres classes Note indirectement subordonnées à l'instance Quartz.
D'une manière générale, la deuxième solution a pour objet un procédé d'interrogation, dans un système informatique, par l'intermédiaire d'au moins une requête d'au moins un objet inclus dans au moins un arbre de contenance inclus dans au moins une machine se reposant sur le protocole de gestion de type CMIP, une requête consistant en une mise à jour ou en une consultation des objets de l'arbre de contenance, une requête incluant un contexte comprenant l'ensemble des paramètres (classes, attributs, opérateurs, variables, etc.) décrivant tous les éléments d'une requête, au moins un paramètre se reposant sur la règle de compatibilité entre instances limitant le traitement de la requête à un sous-ensemble d'instances d'une classe, caractérisé en ce qu'il consiste, à créer un opérateur propre à inhiber, sur une classe donnée, les règles de compatibilité sur instances de façon à traiter la requête sur l'ensemble des instances de la classe sur lesquelles porte la requête. La deuxième solution consiste, une fois les règles de compatibilité inhibées, à lire les attributs des instances sur lesquelles portent la requête, et en ce qu'il consiste à mémoriser ces valeurs dans une mémoire quelconque du système informatique.
Le procédé de la deuxième solution consiste, par exemple, au moment de l'exécution de ia requête à prendre en compte ce nouvel opérateur et lors de l'exécution à traiter la requête avec les valeurs des attributs des instances lues au préalable sans utiliser les règles de compatibilité. L'exemple de réalisation qui précède montre que l'opérateur évalue toute variable externe référençant une variable VX d'une classe X de manière agrégée avec les valeurs de la variable VX calculées pour l'ensemble des instances lues sur ia classe X. De même, l'opérateur évalue une variable de la classe X référençant un attribut avec une fonction d'agrégation avec les valeurs de l'attribut de l'ensemble des instances lues de la classe X.
On a vu, par ailleurs, dans notre exemple d'illustration que si un filtre est défini sur la classe X, la règle de compatibilité des instances des autres classes par rapport à ia classe X n'est pas appliquée et les instances des autres classes non compatibles avec les instances concernées de la classe X ne sont pas à éliminer. Enfin, on a vu que le procédé de la deuxième solution consiste à appliquer l'opérateur à une classe où sont définies des variables.
Cette troisième solution offre un avantage certain en ce sens qu'elle donne la possibilité d'effectuer des unions, des différences et des intersections entre classes dans un environnement objet hiérarchique à l'image des clauses d'union et de différences du langage SQL.

Claims

R E V E N D I C A T I O N S
1 - Procédé d'interrogation dans un système informatique, par l'intermédiaire d'au moins une requête d'au moins un objet inclus dans au moins un arbre de contenance inclus dans au moins une machine se reposant sur le protocole de gestion de type CMIP, une requête consistant en une mise à jour ou en une consultation des objets de l'arbre de contenance, une requête incluant un contexte comprenant l'ensemble des paramètres (classes, attributs, opérateurs, variables, etc ) décrivant tous les éléments d'une requête, au moins un paramètre se reposant sur la règle de compatibilité entre instances limitant le traitement de la requête à un sous-ensemble d'instances d'une classe, caractérisé en ce qu'il consiste, à créer un opérateur propre à inhiber, sur une classe donnée, les règles de compatibilité sur instances de façon à traiter la requête sur l'ensemble des instances de la classe sur lesquelles porte la requête
2- Procédé d'interrogation selon la revendication 1 , caractérisé en ce qu'il consiste, une fois les règles de compatibilité inhibées, à lire les attributs des instances sur lesquelles portent la requête, et en ce qu'il consiste à mémoriser ces valeurs dans une mémoire quelconque du système informatique
3- Procédé d'interrogation selon l'une des revendication 1 ou 2, caractérisée en ce qu'il consiste au moment de l'exécution de la requête à prendre en compte ce nouvel opérateur et lors de l'exécution à traiter la requête avec les valeurs des attributs des instances lues au préalable sans utiliser les règles de compatibilité
4- Procédé d'interrogation selon l'une des revendications 1 à 3, caractérisé en ce que l'opérateur évalue toute variable externe référençant une variable VX d'une classe X de manière agrégée avec les valeurs de la variable VX calculées pour l'ensemble des instances lues sur la classe X.
5- Procédé selon l'une des revendications 1 à 3, caractérisé en ce que l'opérateur évalue une variable de la classe X référençant un attribut avec une fonction d'agrégation avec les valeurs de l'attribut de l'ensemble des instances lues de la classe X.
6- Procédé d'interrogation selon l'une des revendications 1 à 3, caractérisé en ce que, si un filtre est défini sur la classe X, la règle de compatibilité des instances des autres classes par rapport à la classe X n'est pas appliquée et les instances des autres classes non compatibles avec les instances concernées de la classe X ne sont pas à éliminer.
7- Procédé d'interrogation selon l'une des revendications 1 à 3, caractérisé en ce qu'il consiste à appliquer l'opérateur à une classe où sont définies des variables.
PCT/FR2000/001327 1999-05-19 2000-05-17 Procede d'acces, dans un systeme informatique, a des objets d'un arbre de contenance WO2000072510A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR9906356A FR2793918A1 (fr) 1999-05-19 1999-05-19 Procede d'acces, dans un systeme informatique, a des objets d'un arbre de contenance
FR99/06356 1999-05-19

Publications (1)

Publication Number Publication Date
WO2000072510A1 true WO2000072510A1 (fr) 2000-11-30

Family

ID=9545765

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2000/001327 WO2000072510A1 (fr) 1999-05-19 2000-05-17 Procede d'acces, dans un systeme informatique, a des objets d'un arbre de contenance

Country Status (2)

Country Link
FR (1) FR2793918A1 (fr)
WO (1) WO2000072510A1 (fr)

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PAVLOU G ET AL: "CMIS/P++: extensions to CMIS/P for increased expressiveness and efficiency in the manipulation of management information", PROCEEDINGS. IEEE INFOCOM '98, THE CONFERENCE ON COMPUTER COMMUNICATIONS. SEVENTEENTH ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTER AND COMMUNICATIONS SOCIETIES. GATEWAY TO THE 21ST CENTURY (CAT. NO.98CH36169), PROCEEDINGS IEEE INFOCOM'98 CONFERENCE O, 1998, New York, NY, USA, IEEE, USA, pages 430 - 438 vol.2, XP002132331, ISBN: 0-7803-4383-2 *

Also Published As

Publication number Publication date
FR2793918A1 (fr) 2000-11-24

Similar Documents

Publication Publication Date Title
US11533383B2 (en) Templating data service responses
FR2888018A1 (fr) Procede et systeme de realisation d&#39;une base de donnees virtuelle a partir de sources de donnees presentant des schemas heterogenes
WO2009153498A1 (fr) Procede de generation de requetes de manipulation d&#39;une base de donnees d&#39;initialisation et d&#39;administration d&#39;une grappe de serveurs, support de donnees et grappe de serveurs correspondants
EP0593341A1 (fr) Procédé d&#39;aide à l&#39;optimisation d&#39;une requête d&#39;un système de gestion de base de données relationnel et procédé d&#39;analyse syntaxique en résultant
WO1997017660A1 (fr) Interface administrateur pour base de donnees dans un environnement informatique distribue
EP2727319B1 (fr) Procédé d&#39;affectation d&#39;adresses logiques aux ports de connexion d&#39;équipements d&#39;une grappe de serveurs, programme d&#39;ordinateur et grappe de serveurs correspondants
FR2780529A1 (fr) Procede pour l&#39;optimisation des acces a une base de donnees
FR2931272A1 (fr) Procede d&#39;import export de donnees d&#39;une base de donnees
WO2000072510A1 (fr) Procede d&#39;acces, dans un systeme informatique, a des objets d&#39;un arbre de contenance
WO2000072511A1 (fr) Procede de manipulation, dans un systeme informatique, d&#39;objets d&#39;un arbre de contenance
WO2000072512A1 (fr) Procede de gestion, dans un systeme informatique, de requetes dans un arbre de contenance
EP1065828B1 (fr) Procédé d&#39;interrogation à distance d&#39;agents SNMP
FR2793906A1 (fr) Systeme et procede de gestion d&#39;attributs dans un environnement oriente objet
EP1262867A1 (fr) Procédé d&#39;implémentation d&#39;une pluralité d&#39;interfaces d&#39;objets
FR2805908A1 (fr) Procede de manipulation d&#39;objets inclus dans un arbre de contenance et systeme associe
EP2786274B1 (fr) Procede d&#39;interrogation de base de donnees
EP1009128A1 (fr) Procédé de visualisation, dans un système informatique, d&#39;associations entre objects inclus dans un arbre de contenance d&#39;un système de gestion de machines
EP0977400A1 (fr) Procédé de référencement dans une base d&#39;information d&#39;administration d&#39;un ensemble d&#39;instances d&#39;objet
EP1009127A1 (fr) Procédé de création, dans un système informatique, d&#39;associations entre objets d&#39;un arbre de contenance d&#39;un système de gestion de machines
EP0969360A1 (fr) Procédé d&#39;administration d&#39;un système de traitement de l&#39;information
WO2010103247A1 (fr) Procedes et dispositifs pour la mise a jour d&#39;une application client/serveur sans redemarrage de l&#39;application cote client.
WO2000027073A1 (fr) Procede d&#39;optimisation des acces a l&#39;ensemble des instances d&#39;objets d&#39;une meme classe dans une base de donnees d&#39;administration
FR2810432A1 (fr) Procede de gestion de controle de coherence de parametres associes a des ressources physiques et/ou logiques dans un systeme informatique
WO2001025960A1 (fr) Procede de recherche d&#39;un noeud dans un arbre de contenance d&#39;un systeme de gestion de machines
EP1615147A1 (fr) Transformation optimisée d&#39;opération de recherche LDAP en requête SQL

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

WA Withdrawal of international application
121 Ep: the epo has been informed by wipo that ep was designated in this application