WO2000072512A1 - Procede de gestion, dans un systeme informatique, de requetes dans un arbre de contenance - Google Patents

Procede de gestion, dans un systeme informatique, de requetes dans un arbre de contenance Download PDF

Info

Publication number
WO2000072512A1
WO2000072512A1 PCT/FR2000/001329 FR0001329W WO0072512A1 WO 2000072512 A1 WO2000072512 A1 WO 2000072512A1 FR 0001329 W FR0001329 W FR 0001329W WO 0072512 A1 WO0072512 A1 WO 0072512A1
Authority
WO
WIPO (PCT)
Prior art keywords
sub
class
request
requests
execution
Prior art date
Application number
PCT/FR2000/001329
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 WO2000072512A1 publication Critical patent/WO2000072512A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/33—Querying
    • G06F16/332—Query formulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/024—Standardisation; Integration using relational databases for representation of network management data, e.g. managing via structured query language [SQL]

Definitions

  • the subject of the present invention is, in a computer system, a method for managing requests in a capacity tree.
  • the capacity tree is included in a management system
  • the computer system can contain several management systems
  • the term management will be used to conform to the Afnor (Association facie de NORmalisatio ⁇ ) translation of "Management”
  • the term capacity tree will used as translation of the term MIB (Management Information Base) from the OSI standard (Open Systems Interconnection)
  • a computer system comprises 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 that operates using at least two identical or different operating systems.
  • a machine is associated with an operating system
  • a machine includes at least one physical (for example networks, hubs, segments, etc.) or logical (for example a database, etc.) resource.
  • 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 computer system machine.
  • An agent processes requests addressed to him.
  • 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) or other protocols
  • SNMP Simple Network Management Protocol
  • CMIP Common Managment Information Protocol
  • DSAC Disist ⁇ headed Systems Administration and Control
  • the system management commands the agents, and the agent responds and notifies events using an identical management protocol SNMP, CMIS / CMIP or DSAC / AEP (DSAC Administrative Excha ⁇ ge Protocol)
  • the management system includes several agents called "integrating agents" in meaning that they are integrated into the management system
  • the agents and integrating agents of the management system coexist and communicate to mask the heterogeneity of the network
  • 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 likened to a set of services which interact with each other to give a virtual representation of the real world which is the computer system. It is a virtual representation that a 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 the set of objects managed by the management system
  • a managed object is an abstract view defined for management needs, of a logical or physical resource of a system
  • a managed object class is a named set of managed objects sharing the same properties
  • An attribute is a characteristic of a managed object that has a named type and a value The value of an attribute of an object can be consulted or modified by a request
  • naming of objects calls for a naming tree
  • Each object is located in the naming tree with respect to a superior of which he is the subordinate
  • This relationship between subordinate and superior is specified at the level of the classes by a naming link (name binding in English)
  • each instance of the tree is identified by an FDN
  • the name DN is a pair ⁇ attr ⁇ but de ⁇ upper> ⁇ valeur> which allows the unique identification of an instance of the capacity tree compared to a parent instance
  • the FDN name of an instance is a sequence DN names showing the path from the root to this instance
  • a containment tree is a tree made up of class instances Currently, it is possible to build a query to query 30 or update the containment tree and execute it The big problem is that it is not possible to link queries One consequence is that it is not possible to create a query that allows you to work on two different subsets of instances for the same class
  • a capacity tree comprising the list of instances of the Network class, part of which includes an attribute with value A and I other part the same attribute with a different value B
  • these networks are associated with a set equipment such as hubs, routers, etc.
  • this list of Network class instances are subordinate instances of a so-called Quartz instance of a class called Class Tree Inventory
  • a query on this tree can consist in searching, in the Quartz inventory, for the list of instances of class Network including the value attribute B whose number of devices is greater than the average of the number of devices in networks including l value attribute A
  • the processing of this request involves two different subsets of instances of the same Network class
  • the first subset consists of instances of the Network class including the value attribute A and the second consists of the instances of Network class including the same value attribute B which only retains those whose number of devices is greater than the calculated average
  • This query must therefore be broken down into two independent sub-queries
  • a first sub-query includes a filter on the attribute of value A and the calculation of the average of the equipment for the networks including the attribute of value A
  • a second subquery which includes a filter on the attribute of value B and selects the instances of Networks including the attribute of value B whose number of devices is greater than the average calculated in the first subquery
  • a first object of the invention is therefore to give the possibility to a request designer to create a request including sub-requests for the implementation of complex requests.
  • 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 for manipulating objects included in a capacity tree, the objects being interrogable by means of at least one multiple request including at least two sub-requests each including a class of input and output class
  • FIG. 1 is a synoptic view of the architecture of a computer system to which three solutions to three distinct problems can be applied
  • FIG. 2 is a schematic view of a class tree and a capacity tree
  • Figures 3 and 4 are schematic views of a multiple query illustrating the solution comprising respectively two subqueries and any number of subqueries
  • Figures 5A and 5B are respective schematic views of a class tree and d a capacity tree illustrating a third solution to another problem
  • SYS of heterogeneous type has been shown.
  • this system SYS includes at least one manager system SG and at least one machine remote associated with a management protocol
  • the management system can be included in a workstation
  • a remote machine M1 is represented
  • a machine M1 comprises s manipulable objects Manipulation includes commands known to those skilled in the art
  • the machine management protocol M1 can be either a SNMP, CMIS / CMIP or DSAC / AEP type protocol
  • the SG system supports a protocol CMIS type conforming to the OSI (Common Managment Information service) model, known to those skilled in the art
  • This application can be launched via a UT user of this SG management system
  • a user can be an administrator
  • the management system SG 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 A1 is associated with the management protocol of the machine M1
  • an integrating agent is of software type II provides services A service can be a conversion of the management protocol
  • the integrating agent A1 converts the management protocol of the SG management system into a management protocol associated with the machine M1
  • the integrating agent Al converts the management protocol associated with the machine M1 into a management protocol associated with the management system SG
  • An integrating agent is not limited to this type of service and provides other services In general, a conversion to the management protocol takes place naturally between an SG management system and a machine which support different management protocols
  • the management server SG can comprise several integrating agents.
  • the integrating agent A1 is connected to the machine M1 and to the machine M2 via a network RES1 of any type.
  • the network RES1 can be of the LAN type (Local Area Network) or WAN (Wide Area Network)
  • a set of software layers is interposed between the management system SG and the RES network and between the network and the machine M1
  • This set of software layers is based on the OSI model (Open System Intercon ⁇ ection ) Layered architecture of the ISO (International Organization for Standardization) known to those skilled in the art For reasons of simplification of the description, this set of software layers is not shown in FIG. 1
  • 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 SG also includes a capacity tree MIB associated with the agent AG A view of this capacity tree MIB is shown in FIG. 2 The capacity tree can be entirely included in the agent AG
  • the tree of MIB content and AG agent provides a virtual representation of the real world surrounding the SG management system. It is a virtual representation that the UT user or that an 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.
  • the real world is materialized by the machine M1
  • the MIB containment tree is object oriented and is made up of nodes and branches. This tree includes in its nodes all the objects managed by the management system SG. Generally and known to those skilled in the art, to create an object in this MIB database, it is necessary to choose its class, to name it in accordance with the naming links relating to the class, and to value its attributes.
  • a managed object is an abstract view, defined for management purposes, of a logical or physical resource of a system.
  • the containment tree nodes belong to the same class.
  • a class tree is created.
  • the class tree includes 3 classes:
  • B a Network class which represents the discovered networks and is defined by attributes:
  • This containment tree comprises 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
  • each node NET1, NET2 and NET3 has respective subordinate nodes (DEV1, DEV2, DEV3), (DEV4, DEV5, DEV6), (DEV7) instances of the Equipment class
  • the request context is defined as being the set of parameters describing all the elements of a request m filters
  • V a variable defined on a class X
  • the class X can be the class Inventory the class Network or the Equipment class
  • a variable V can have the following form
  • V attl ⁇ op> F (att2) ⁇ o ⁇ > W ⁇ op> G (Z) where attl, att2 are attributes of class X
  • W, Z are variables internal or external to class X
  • ⁇ 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
  • an expression can only refer to attributes of the class current
  • an expression can reference local variables or external variables defined on a class other than the current class
  • 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 IPB cage network
  • 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-in , Exists, Contains,), sorting, grouping (GROUP BY), Single operator, 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 class Inventory
  • 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 consists in sharing 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 the same request According to a preferred variant, the system in charge of dynamically creating pointers which will link all the created subqueries The link of all the subqueries constitutes the multiple query
  • 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 be established in the context of a request reverse chaining This reverse chaining is provided by pointers
  • the first SRO subquery has the following form ⁇ On the Network class
  • expression (1) is a filter on the attribute named "Network IP class" whose value is A More 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 SRO sub-request, the result obtained on the Network class in the final Inventory class
  • the inventory class includes a single Quartz On instance defined therefore on this class a variable moy_dev initialized to the value obtained V_AVG ⁇ ans in the class Network
  • the result attributes appear in an M1 matrix.
  • the second SR1 subquery has the form ⁇ On the Network class (final class)
  • this second sub-request SR1 is the same as previously.
  • a double filter is carried out.
  • a first filter on the networks B and a second filter including a comparison operator expression (5) is a filter on the networks B
  • B expression (6) is a filter on the attribute number of equipment which must be greater than an average
  • the choice of the value of this average in the second sub-request differs according to whether the average is a shared variable or not In accordance with the solution, if this variable is shared, the value of this average is the value calculated in a sub-request If this variable is not shared between two subqueries, the shared variable is calculated normally as for the execution of a non-multiple query For this, another important aspect of the solution is that if moy_dev is a variable shared between the two subqueries For SR1 to have visibility to this shared variable in SRO, this variable must be defined on the final class of SRO In the example illustrated, the final class of SRO is the Inventory class Step 4 The two sub queries are archived in a database Step 5
  • Another step consists, during the validation of the sub-requests, in establishing a temporal order of execution of the sub-requests and in providing each sub-request with at least one pointer to respect the order of execution.
  • a pointer can be an attribute
  • the first subquery and the last includes a single pointer
  • the intermediate subqueries include two pointers
  • the function of a pointer is evoked 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 sub- requests 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
  • the system detects the presence of a multiple request.
  • a chaining mechanism is executed by the system.
  • the chaining mechanism is software and consists - during a first phase to point successively, from the last sub-request SR1 selected, to the first sub-request SRO,
  • the two sub-requests include a single respective pointer (R1, P1) During the first phase e, the pointer P1 points to the first sub-request SRO During the second phase the pointer R1 points to the second sub-request
  • a sixth step consists of displaying the results preferably in an M2 matrix.
  • the columns represent the selected result attributes and the rows the instances that check the sub-query (s).
  • a multiple request RM can be considered as the sequence of ⁇ under requests noted SRi i varying from 1 to n
  • FIG. 4 An example of a multiple query is shown in Figure 4
  • the execution of RM consists in launching the execution of the last sub-request SRn, more precisely that for which one wishes to obtain the results The user therefore conventionally launches the execution of SRn having previously selected the input instance to which the RM multiple request relates
  • the sub-requests SRO and SRn comprise a respective pointer RO 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 to the towards the sub-request SRj -1 from position 0-1)
  • the system then starts the sequential execution of the SRi sub-requests, starting with the first SRO, an SRi sub-request being activated if and only if the execution of the position sub-request SR ⁇ -1 ( ⁇ -1) is finished During this second phase, the same subjunction SRj includes another pointer Rj to point to the towards the subquery SRj + 1 of position 0 + 1)
  • 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 block of the SRi subquery
  • SRj on class X for an instance Xk of class X can have two values if there is a value of VPi for Xk in the SRi subquery, the shared variable VPi will be calculated with this calculated value, otherwise, that is, the instance Xk is not a solution of the SRi subquery, the shared variable VPi is calculated normally as for the execution of a non-multiple query
  • a second major problem is linked to the concept of accounting between distinguished names of the FDN type.
  • V attl ⁇ op> F (att2) ⁇ op> W ⁇ op> G (Z) WHERE attl, att2 are attributes of class X, Class X can be either the Inventory class, the Network class or the Equipment class , and attl, att2 can be either attributes of one of the classes,
  • W Z are variables internal or external to class X
  • F, G are functions that apply to variables
  • ⁇ op> is any arithmetic operator
  • variable V is calculated for each instance of class X
  • 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
  • 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 compatibility rules on instances in order to process a request, not on a subset of instances of the class but on the 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 illustrative example of the fact that its execution is based on compatibility rules This choice is arbitrary in the sense that another aggregation function resting 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 in relation to the total number of networks Writing this request poses two problems
  • the number ⁇ bDev 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
  • the user analyzes the request to be processed and determines whether the compatibility rule should be inhibited on the basis of the above If the use of the compatibility rule is justified, the execution of the request R3 takes place normally If the use of the compatibility rule is not justified, the execution of the R3 request is different Indeed, in the example illustrated, the designer inserts the Nocomp muting operator in the request This operator can be applied on any class where variables are defined In the example illustrated, the query has the following form On the variable Equipment class.
  • 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 is to execute the query 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 request is no longer limited to a subset of instances of a class On the contrary, 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 containment tree via a single request L ' user is not forced to duplicate the variables, this duplication being cumbersome to implement and overloading the writing of the request
  • a third big problem, mentioned in the introduction, is linked 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
  • FIG. 4-a one represented a tree of classes to illustrate the problem
  • This tree includes three types of class
  • the root class is, for example, the class Inventory Two classes Note and Network of this tree are subordinate to the class Inventory Finally, the same Note class is subordinate to the Network class.
  • this tree of classes includes / understands a same class Note which is located at different levels of the tree
  • the figure 4-b represents a tree ⁇ e capacity including instances of the tree of classes of figure 4- at
  • 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 A K instance of the Network class is subordinate to the Quartz instance Finally , two instances Notel and Note4 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 here lies in the processing of the difference, or of the intersection or the union in the same query 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 indirectly subordinate Note classes"
  • 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 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 I 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
  • the selection of a class is carried out by clicking on a mouse button, this selection causing the associated icon to appear in the tree.
  • a fourth step consists in displaying on the final class, a MEN menu presenting the different operators present in the system
  • This menu includes the operators object of the third solution
  • This step consists in selecting an operator in the menu which can be the Union, the Difference or Intersection on the final class
  • the icons selected and coinciding with the final class are memorized for the operation (a filter type window appears on the screen )
  • a sixth step consists in applying the operator and in displaying the results
  • An operator in accordance with the invention performs an operation between nodes of the same class in the class tree, more precisely between the source class and at least one target class Let X the final class to which the requests R4, R5, and R6 apply
  • 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 that 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 defined previously
  • ID is a numeric value
  • the R4 query can be constructed in accordance with the 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 first solution relates to a method for manipulating objects included in a capacity tree, the objects being interrogable by means of at least one multiple request (RM) including at least two sub-requests ( SRi and SRj) each including an input class and an output class
  • RM multiple request
  • SRi and SRj sub-requests
  • the method consists, upon execution of the multiple request (RM), in selecting a starting instance to which the request relates (RM) and in sequentially launching the sub-requests constructed in accordance with the time order fixed, a sub-request being activated only after the running sub-request has ended
  • the method consists, for fixing the time order, in adding to all the sub-requests at least one pointer capable of pointing to another sub-request in accordance with the fixed time order.
  • the method consists, before the execution of a request to detect the presence of a multiple request, and in that it consists in the execution of the request to trigger a consistent chaining mechanism
  • a subquery is activated only if the execution of the previous sub-query is completed.
  • the shared variable VP will be calculated with this calculated value, otherwise, if X k instance is not a solution of the subquery SRi, the shared variable is normally calculated as VP for the execution of a non multi_query
  • This operator is analogous to the filter operator defined above, except that it allows you to define a filter which does not relate to the attributes of the class, but to the variables defined previously for this class.
  • the "value" part of the filter expression can be specified using an element
  • the instances selected for the class in which the filter has been defined are designed in such a way that the values of the associated variables can satisfy the expression of the filter
  • CMIS Query Builder offers a join operation equivalent to that of a relational database
  • a "join” consists of combining the results of two different branches on a query tree
  • Class A with the attributes att-a1, att-a2 and att-a3, includes four instances Class B, with the attributes att-b1 and att-b2, contains three instances.
  • the attributes att-a1 and att-b1 are semantically identical

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention a pour objet un procédé de manipulation d'objets inclus dans un arbre de contenance, les objets étant interrogeables par l'intermédiaire d'au moins une requête multiple (RM) incluant au moins deux sous-requêtes (SRi et SRj) incluant chacune une classe d'entrée et une classe de sortie caractérisé en ce qu'il consiste, à définir au moins une variable partagée VP entre lesdites au moins deux sous-requêtes (SRi et SRj), à fixer un ordre temporel d'exécution des différentes sous-requêtes et à lier l'ensemble des sous-requêtes de façon à ce que le résultat d'une sous-requête (SRi) puisse être exploité par d'autres sous-requêtes (SRj) de la requête multiple (RM), et en ce qu'il consiste, à l'exécution de la requête multiple (RM), à sélectionner une instance de départ sur laquelle porte la requête (RM) et à lancer séquentiellement les sous-requêtes construites conformément à l'ordre temporel fixé, une sous-requête étant activée seulement après que la sous-requête en cours d'exécution soit terminée.

Description

Procédé de gestion, dans un système informatique, de requêtes dans un arbre de contenance.
La présente invention a pour objet dans un système informatique un procédé de gestion de requêtes dans 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 NORmalisatioπ) 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 à au moins un protocole de gestion
Dans ce système informatique, au moins un agent est, en gênerai 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 Exchaπge 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 interagissent 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ères 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
5 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
15 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
2ϋ et un DN Le nom DN est un couple <attrιbut de πommage><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
25 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 a 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 30 ou de mise à jour de l'arbre de contenance et de l'exécuter Le gros problème est qu'il n'est pas possible de lier des requêtes Une conséquence est qu'il n'est pas possible de créer une requête qui permette de travailler sur deux sous-ensembles d'instances différents pour la même classe
Par exemple, considérons un arbre de contenance comprenant la liste des instances de classe Réseau dont une partie comprend un attribut de valeur A et I autre partie un même attribut avec une valeur différente B Comme dans tout système informatique, ces reseaux sont associes à un ensemble d'équipements tels que des concentrateurs, des routeurs, etc Considérons également que cette liste d'instances de classe Réseau soient des instances subordonnées à une instance dite Quartz d'une classe dite Inventaire de l'arbre de classes
Une requête sur cet arbre peut consister à rechercher, dans l'inventaire Quartz, la liste des instances de classe Réseau incluant l'attribut de valeur B dont le nombre d'équipements est supérieur à la moyenne du nombre d'équipements des réseaux incluant l'attribut de valeur A
Le traitement de cette requête fait intervenir deux sous-ensembles différents d'instances d'une même classe Réseau Le premier sous-ensemble est constitué par les instances de classe Réseau incluant l'attribut de valeur A et le second est constitue par les instances de classe Reseau incluant le même attribut de valeur B dont on ne retient que ceux dont le nombre d'équipements est supérieur à la moyenne calculée Cette requête doit donc être décomposée en deux sous-requêtes indépendantes Une première sous-requête comprend un filtre sur l'attribut de valeur A et le calcul de la moyenne des équipements pour les réseaux incluant l'attribut de valeur A Une deuxième sous-requête qui comprend un filtre sur l'attribut de valeur B et sélectionne les instances de Réseaux incluant l'attribut de valeur B dont le nombre d'équipements est supérieur à la moyenne calculée dans la première sous-requête
La décomposition d'une requête en plusieurs sous-requête n'est pas possible Or, les utilisateurs sont de plus en plus amenés a concevoir des requêtes compliquées, beaucoup d entre elles nécessitant une décomposition en plusieurs sous-requêtes
Un premier but de l'invention est donc de donner la possibilité à un concepteur de requêtes de créer une requête incluant des sous-requêtes pour la mise en œuvre de requêtes complexes
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é de manipulation d objets inclus dans un arbre de contenance, les objets étant interrogeables par l'intermédiaire d'au moins une requête multiple incluant au moins deux sous- requêtes incluant chacune une classe d'entrée et une classe de sortie
caractérisé en ce qu'il consiste,
• à définir au moins une variable partagée entre lesdites au moins deux sous-requêtes,
• à fixer un ordre temporel d'exécution des différentes sous-requêtes et à lier l'ensemble des sous-requêtes de façon à ce que le résultat d'une sous- requête puisse être exploité par d'autres sous-requêtes de la requête multiple,
• et en ce qu'il consiste, à l'exécution de la requête multiple, a sélectionner une instance de départ sur laquelle porte la requête et à lancer séquentiellement les sous-requêtes construites conformément à l'ordre temporel fixé, une sous requête étant activée seulement après que la sous- requête en cours d'exécution soit terminée
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 et faite en référence aux dessins annexés
Dans les dessins
la figure 1 est une vue synoptique de l'architecture d'un système informatique sur lequel peut s'appliquer trois solutions à trois problèmes distincts, la figure 2 est une vue schématique d'un arbre de classe et d'un arbre de contenance , les figures 3 et 4 sont des vues schématiques d'une requête multiple illustrant la solution comprenant respectivement deux sous-requêtes et un nombre quelconque de sous-requêtes les figures 5A et 5 B sont des vues schématiques respectives d'un arbre de classe et d'un arbre de contenance illustrant une troisième solution a un autre problème Sur la figure 1 , on a représenté un système informatique SYS distribué de type hétérogène Dans l'exemple illustré, ce système SYS inclut au moins un système gestionnaire SG 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 M1 Une machine M1 comprend des objets manipulables Une manipulation inclut des commandes connues de l'homme du métier Le protocole de gestion de la machine M1 peut-être indifféremment un protocole de type SNMP, CMIS/CMIP ou DSAC/AEP Dans notre exemple, le système SG 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 UT de ce système de gestion SG Un utilisateur peut être un administrateur
Le système gestionnaire SG 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 illustre, un agent intégrateur Al est associé au protocole de gestion de la machine M1 De façon générale, un agent intégrateur est de type logiciel II procure des services Un service peut être une conversion du protocole de gestion Dans l'exemple illustré l'agent intégrateur Al convertit le protocole de gestion du système de gestion SG en un protocole de gestion associé à la machine M1 Réciproquement l'agent intégrateur Al convertit le protocole de gestion associé à la machine M1 en un protocole de gestion associe au système de gestion SG 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 αe protocole de gestion s'effectue naturellement entre un système de gestion SG et une machine qui supportent des protocoles de gestion différents
Naturellement, le serveur de gestion SG peut comprendre plusieurs agents intégrateurs L'agent intégrateur Al est relié à la machine M1 et à la machine M2 par l'intermédiaire d'un réseau RES1 de type quelconque Le réseau RES1 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 SG et le réseau RES et entre le réseau et la machine M1 Cet ensemble de couches logicielle repose sur le modèle OSI (Open System Interconπection) d'architecture en couche de l'ISO (International Organization for Standardization) connu de l'homme du métier Pour des raisons de simplification de la description, cet ensemble de couches logicielles n'est pas représenté sur la figure 1
Dans l'exemple illustre, 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 SG comprend aussi un arbre de contenance MIB associé à l'agent AG Une vue de cet arbre de contenance MIB est représentée sur la figure 2 L'arbre de contenance peut être entièrement compris dans l'agent AG
Pour simplifier la description, on a choisi de séparer, sur la figure 1 I arbre de contenance MIB et l'agent AG Cet arbre MIB assure une représentation virtuelle du monde réel qui entoure le système de gestion SG. C'est une représentation virtuelle que l'utilisateur UT 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 M1
Par définition, l'arbre de contenance MIB est orienté 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 SG. De manière générale et connue de l'homme du métier, pour créer un objet dans cette base MIB, 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 :
• 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.
• 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 de la figure 2 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 suDordoππé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 »
II 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 m filtres
• classes β attributs
• opérateurs
• 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) <oρ> 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 ciasse IPB
Pour des raisons de simplifications de la description, les instances de la classe Reseau 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. • 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-in, 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 I 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 β Sur la classe Réseau
• Filtre classe IP du reseau = A (1 )
• variable V_AVG=AVG (nombre d'équipements pour le réseau) (2) β 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 Plus 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 initialisé à la valeur obtenue V_AVG αans 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 β 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) • 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 à 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é αe cette variable partagée dans SRO, cette variable 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é I 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 aαmettent la même classe de départ, et donc sont lancées sur la même instance de départ. Dans l'exemple illustré, 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 αe 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 M2 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 π sous requêtes notées SRi i variant de 1 à n
RM = SR0 + SR1 + SR1 + + SRi + SRn
Un exemple d'une requête multiple est montré à la figure 4 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 RO 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 0-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 SRι-1 de position (ι-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 0+1 )
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 ciasse 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 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, 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 consiαérabie 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 lie à la notion de comptabilité entre noms distinctifs 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 Reseau ou la classe Equipement, et attl , att2 pouvant être indifféremment des attributs de l'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 β l'attribut attl est évalué avec la valeur d'attribut attl de l'instance Xi (Règle 2),
* 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
* 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 a l'instance Xi si W est une variable externe conformément à la première solution
" 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 Réseau, pour une instance de la classe Réseau, l'évaluation des variables suivantes u 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 a cette instance dans l'arbre " 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 reseau 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 reseau 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 ensemb stes) la règle de compatibilité entre instances est utilisée automatiquement, ce qui pose problème
De tels opérateurs 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 a 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 enregistrés dans un réseau donné par rapport au nombre total de réseau L'écriture de cette requête pose deux problèmes
- les réseaux ne comprenant pas d'équipements SNMP sont éliminés,
- et le nombre πbDev 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 a exécuter la requête en tenant compte des valeurs obtenues à l'étape 3
L'operateur 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 a 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
Sur la figure 4-a, on a représenté un arbre de classes pour illustrer le problème Cet arbre comprend trois types de classe La classe racine est, par exemple, la classe Inventaire Deux classes Note et Reseau de cet arbre sont subordonnées a 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 La figure 4-b représente un arbre αe contenance comprenant des instances de l'arbre de classes de la figure 4-a
Sur cette figure 4-b, 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 l'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 attacnees à 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 I 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 operateur 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 I 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 a 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 surbnllance de l'icône associé dans l'arbre
Etape 4
Une quatrième étape consiste a 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 I 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'arore 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 la 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
De manière générale, la première solution a pour objet un procédé de manipulation d'objets inclus dans un arbre de contenance, les objets étant interrogeables par l'intermédiaire d'au moins une requête multiple (RM) incluant au moins deux sous-requêtes (SRi et SRj) incluant chacune une classe d'entrée et une classe de sortie
caractérisé en ce qu'il consiste,
B à définir au moins une variable partagée VP entre lesdites au moins deux sous-requêtes (SRi et SRj),
B à fixer un ordre temporel d'exécution des différentes sous-requêtes et a lier l'ensemble des sous-requêtes de façon à ce que le résultat d'une sous- requête (SRi) puisse être exploité par d'autres sous-requêtes (SRj) de la requête multiple (RM),
B et en ce qu'il consiste, à l'exécution de la requête multiple (RM), à sélectionner une instance de départ sur laquelle porte la requête (RM) et à lancer séquentiellement les sous-requêtes construites conformément à l'ordre temporel fixé, une sous requête étant activée seulement après que la sous- requète en cours d'exécution soit terminée Dans un exemple, le procédé consiste, pour la fixation de l'ordre temporel, à ajouter à toutes les sous-requêtes au moins un pointeur propre à pointer vers une autre sous-requête conformément à l'ordre temporel fixé.
On a vu que l'exploitation d'un résultat obtenu par une sous-requète dans une autre sous-requête consiste à déterminer le classe d'entrée et la classe finale de toutes les sous-requêtes, et en ce qu'il consiste à placer la variable partagée VP sur la classe finale de chaque sous-requête
Ensuite, consiste à lancer séquentiellement les sous-requêtes de la première sous-requête jusque la dernière sous-requête par l'intermédiaire dudit au moins un pointeur une sous-requête étant activée seulement si l'exécution de la précédente sous-requête est terminée
On a vu également dans notre exemple de réalisation que le procédé consiste, avant l'exécution d'une requête à détecter la présence d'une requête multiple, et en ce qu'il consiste, à l'exécution de la requête à enclencher un mécanisme de chaînage consistant
- lors d'une première phase, à pointer successivement à partir de la dernière sous-requête sélectionnée vers la première sous-requète,
- et lors d'une seconde phase à lancer séquentiellement les sous- requêtes de la première sous-requête jusque la dernière sous requête, une sous-requête étant activée seulement si l'exécution de la précédente sous- requête est terminée.
On a vu que le procédé consiste, Lors de l'exécution de SRj, l'évaluation de la variable VP 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 VP pour l'instance Xk dans SRi, la variable partagée VP sera calculée avec cette valeur calculée, dans le cas contraire, si l'instance Xk n'est pas une solution de la sous- requête SRi, la variable partagée VP est calculée normalement comme pour l'exécution d'une requête non multiple
ANNEXE 1 EXEMPLES DE FONCTIONS ENSEMBLISTES Fonctions mathématiques
-AVG
Syntaxe
AVG(llSt-1 , lιst-2... )
Description Calcule la moyenne des valeurs des éléments des listes lιst-1 lιst-2 et renvoie la moyenne globale
-COUNT Syntaxe
COUNT (lιst-1)
Description
Calcule le nombre d'éléments dans la liste lιst-1
Utilisez cette fonction pour calculer le nombre d'instances d'une classe
-MAX Syntaxe
MAX(lιst-1 , lιst-2...) Description Calcule le maximum des valeurs des éléments dans les listes lιst-1 , lιst-2, etc
-MIN Syntaxe
MlN(lιst-1, lιst-2...) Description
Calcule le minimum des valeurs des éléments dans les listes lιst-1, lιst-2
-MUL Syntaxe MUL(llSt-1 , llSt-2... )
Description
Calcule le produit des valeurs des éléments dans les listes lιst-1 lιst-2
-ROUND Syntaxe ROUND (val) Description Renvoie la valeur arrondie a l'entier supérieur de val
- SUM Syntaxe
SUM(lιst-1 , lιst-2... ) Description
Calcule la somme des valeurs des éléments dans les listes lιst-1 , lιst-2
- ABS
Syntaxe
ABS (val )
Description
Renvoie la valeur positive de val
EXEMPLES D'OPERATEURS
Définir un filtre pour des variables
Cet opérateur est analogue à l'opérateur de filtre défini plus haut, à cette différence près qu'il vous autorise à définir un filtre qui ne porte pas sur les attributs de la classe, mais sur les variables définies antérieurement pour cette classe
Ainsi, en sélectionnant l'entrée du menu Filter-Vanable, une fenêtre de gestion de filtre apparaît Une liste des variables pour cette classe s'affiche dans la partie gauche de cette fenêtre
Tout comme pour un filtre classique, la partie "valeur" de l'expression du filtre peut être spécifiée au moyen d'un élément
- valeur de variable,
- référence à une autre variable (rappelez-vous de préfixer le nom de la variable avec un caractère $) Lorsque la requête est exécutée, les instances retenues pour la classe dans laquelle le filtre a été défini sont conçues de telle manière que les valeurs des variables associées puissent satisfaire l'expression du filtre
Opérateur Jointure
CMIS Query Builder propose une opération de jointure équivalente à celle d'une base de données relationnelle Une "jointure" consiste à combiner les résultats de deux branches différentes sur un arbre de requête
- Une jointure peut être définie dans n'importe quelle classe de la requête
- Plusieurs jointures peuvent être définies dans une requête
Mécanisme d'une lointure
Définir une jointure entre la classe A et B d'une requête revient à - supprimer des classes A et B toutes les instances qui ne font pas l'objet d'une union,
- créer un objet virtuel dans lequel chaque instance est issue de la concaténation des instances compatibles de A et B se joignant correctement
Exemple
La classe A, dotée des attributs att-a1 , att-a2 et att-a3, comprend quatre instances La classe B, dotée des attributs att-b1 et att-b2, contient trois instances. Les attributs att-a1 et att-b1 sont sémantiquement identiques
Les tables suivantes présentent les valeurs des attributs pour toutes les instances des classes A et B
instance att-a1 att-a2 att-a3
Al al ail al2
A2 a2 a21 a22
A3 a3 a31 a32
A4 a4 a41 a42
instance att-b 1 att-b2
Bl al bl
B2 a2 b2
B3 a5 b3
La table ci-dessous indique le résultat d'une jointure entre les classes A et B dans laquelle : att-a1 = att-b1. att-al att-a2 att-a3 attb-2 al ail al2 bl a2 a21 a22 b2
Une fois la jointure exécutée, les instances A3, A4 et B3 sont supprimées

Claims

R E V E N D I C A T I O N S
1- Procède de manipulation, dans un système informatique d'objets inclus dans un arbre de contenance inclus dans au moins un système de gestion, ledit système de gestion étant connecte a au moins une machine par l'intermédiaire d'un reseau, les objets étant interrogeables par l'intermédiaire d'au moins une requête multiple (RM), une requête multiple consistant en une mise à jour ou une consultation des objets de l'arbre via le reseau une requête multiple incluant au moins deux sous-requêtes (SRi et SRj) incluant chacune une classe d'entrée et une classe de sortie, caractérise en ce qu'il consiste, préalablement a I exécution de la requête multiple,
- à définir au moins une variable partagée VP entre lesdites au moins deux sous-requêtes (SRi et SRj),
- à fixer un ordre temporel d'exécution des différentes sous-requêtes et à lier l'ensemble des sous-requêtes de façon a ce que le résultat d'une sous-requête
(SRi) puisse être exploité par d'autres sous-requêtes (SRj) de la requête multiple (RM),
et en ce qu'il consiste, a l'exécution de la requête multiple (RM; a sélectionner une instance de départ sur laquelle porte la requête (RM) et a lancer séquentiellement les sous-requêtes construites conformément à l'ordre temporel fixé, une sous requête étant activée seulement après que la sous- requête en cours d'exécution soit terminée
2- Procède selon la revendication 1 caractérise en ce qu il consiste, pour la fixation de l'ordre temporel a ajouter a toutes les sous-requêtes au moins un pointeur propre a pointer vers une autre sous-requête conformément a l'ordre temporel fixe
3- Procédé selon la revendication 1 ou 2, caractérise en ce que l'exploitation d un résultat obtenu par une sous-requête dans une autre sous- requête consiste a déterminer le classe d'entrée et la classe finale de toutes les sous-requêtes, et en ce qu'il consiste à placer la variable partagée VP sur la classe finale de chaque sous-requête
4- Procédé selon l'une des revendications 1 ou 3, caractérise en ce qu'il consiste à lancer séquentiellement les sous-requêtes de la première sous- requête jusque la dernière sous-requête par I intermédiaire dudit au moins un pointeur une sous-requête étant activée seulement si l'exécution de la précédente sous-requête est terminée
5- Procédé selon l'une des revendications 1 ou 3, caractérise en ce qu'il consiste, avant l'exécution d'une requête à détecter la présence d'une requête multiple, et en ce qu'il consiste, à l'exécution de la reαuête a enclencher un mécanisme de chaînage consistant
- iors d'une première phase, à pointer successivement a partir de la dernière sous-requête sélectionnée vers la première sous-requête, - et lors d'une seconde phase à lancer séquentiellement les sous- requêtes de la première sous-requête jusque la dernière sous requête, une sous-requête étant activée seulement si l'exécution de la précédente sous- requête est terminée
6- Procédé selon l'une des revendications 1 ou 5, caractérisé en ce qu'il consiste, Lors de l'exécution de SRj, l'évaluation de la variable VP 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 VP pour l'instance Xk dans SRi, la variable partagée VP sera calculée avec cette valeur calculée,
B dans le cas contraire, si l'instance Xk n est pas une solution de la sous- requête SRi la variable partagée VP est calculée normalement comme pour l'exécution d'une requête non multiple
PCT/FR2000/001329 1999-05-19 2000-05-17 Procede de gestion, dans un systeme informatique, de requetes dans un arbre de contenance WO2000072512A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR99/06355 1999-05-19
FR9906355A FR2793917A1 (fr) 1999-05-19 1999-05-19 Procede de gestion, dans un systeme informatique, de requetes dans un arbre de contenance

Publications (1)

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

Family

ID=9545764

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2000/001329 WO2000072512A1 (fr) 1999-05-19 2000-05-17 Procede de gestion, dans un systeme informatique, de requetes dans un arbre de contenance

Country Status (2)

Country Link
FR (1) FR2793917A1 (fr)
WO (1) WO2000072512A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5726979A (en) * 1996-02-22 1998-03-10 Mci Corporation Network management system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5726979A (en) * 1996-02-22 1998-03-10 Mci Corporation Network management system

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
FR2793917A1 (fr) 2000-11-24

Similar Documents

Publication Publication Date Title
US20200296184A1 (en) Templating data service responses
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
FR2888018A1 (fr) Procede et systeme de realisation d&#39;une base de donnees virtuelle a partir de sources de donnees presentant des schemas heterogenes
FR2832236A1 (fr) Interface graphique de portail web semantique
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
FR2740884A1 (fr) Interface administrateur pour base de donnees dans un environnement informatique distribue
US8185562B2 (en) Business object browser for business query language
FR2780529A1 (fr) Procede pour l&#39;optimisation des acces a une base de donnees
US11494381B1 (en) Ingestion and processing of both cloud-based and non-cloud-based data by a data intake and query system
US20110082917A1 (en) Quick upload
FR2931272A1 (fr) Procede d&#39;import export de donnees d&#39;une base de donnees
WO2000072512A1 (fr) Procede de gestion, dans un systeme informatique, de requetes dans un arbre de contenance
WO2000072511A1 (fr) Procede de manipulation, dans un systeme informatique, d&#39;objets d&#39;un arbre de contenance
WO2000072510A1 (fr) Procede d&#39;acces, dans un systeme informatique, a des objets d&#39;un arbre de contenance
EP1065828B1 (fr) Procédé d&#39;interrogation à distance d&#39;agents SNMP
FR2825491A1 (fr) Procede d&#39;implementation d&#39;un pluralite d&#39;interfaces d&#39;objets
WO2009004231A2 (fr) Procede de tri d&#39;informations
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
Minde Automatic collection and storage of smart city data with semantic data model discovery and sample data analysis
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
FR2780531A1 (fr) Procede d&#39;administration d&#39;un systeme de traitement de l&#39;information

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