CN109684361B - Rule analysis method and corresponding rule analysis device - Google Patents
Rule analysis method and corresponding rule analysis device Download PDFInfo
- Publication number
- CN109684361B CN109684361B CN201811529586.5A CN201811529586A CN109684361B CN 109684361 B CN109684361 B CN 109684361B CN 201811529586 A CN201811529586 A CN 201811529586A CN 109684361 B CN109684361 B CN 109684361B
- Authority
- CN
- China
- Prior art keywords
- rule
- request
- query result
- terminal
- history
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a rule analysis method and a corresponding device for rule analysis, wherein the rule analysis method comprises the following steps: establishing a historical rule mapping table according to a reference request rule of the first terminal and a reference query result matched with the reference request rule; receiving a target request rule of a second terminal; matching the target request rule with the reference request rule, and determining a primary request element and a historical request element; obtaining a query result matched with the historical request element from the historical rule mapping table, and obtaining a query result matched with the primary request element from the database; and combining the query result matched with the historical request element and the query result matched with the primary request element to obtain a target query result matched with the target request rule. The rule analysis method of the invention reduces the calculation amount of rule analysis and the time consumed by rule analysis, and can improve the efficiency and the resource utilization rate.
Description
Technical Field
The present invention relates to the field of databases, and more particularly, to a rule analysis method and a corresponding apparatus for rule analysis.
Background
With the rapid development of internet technology, more and more users perform various internet-related services through internet platforms. In most cases, a plurality of different terminals will connect to the same server and share one data source, for example, a public security system will connect to different terminals for the different terminals to query data.
The server generally queries corresponding data according to a request rule sent by the terminal, and then sends the data to the terminal. When the server runs a rule, the server needs to calculate the condition elements contained in the rule once, and obtains the execution result of the rule according to the calculation results of different condition elements. In the operation process, the more condition elements are included in the rule, the more complicated the logic operation between the condition elements is, the longer the rule running time is, the lower the query efficiency is, and the larger the consumption of server resources is caused.
In view of the above, overcoming the drawbacks of the prior art is an urgent problem in the art.
Disclosure of Invention
The invention provides a rule analysis method and a corresponding rule analysis device aiming at overcoming the defects or the improvement requirements of the prior art, and aims to avoid repeated rule analysis by a server, reduce the calculation amount of the rule analysis and the time consumed by the rule analysis, effectively improve the efficiency of the rule analysis and improve the resource utilization rate of the server, thereby solving the technical problems of longer rule analysis time, low query efficiency and higher server resource consumption of the existing server.
In order to achieve the above object, according to an aspect of the present invention, there is provided a rule analysis method, in which a server establishes a history rule mapping table according to a reference request rule of a first terminal and a reference query result matched with the reference request rule, where the reference request rule includes one or more history request elements;
the rule analysis method comprises the following steps:
receiving a target request rule of a second terminal, wherein the target request rule comprises one or more request elements;
matching the target request rule with the reference request rule to determine a primary request element and a historical request element;
obtaining a query result matched with the history request element from a history rule mapping table; obtaining a query result matched with the primary request element from a database;
and combining the query result matched with the historical request element and the query result matched with the primary request element to obtain a target query result matched with the target request rule.
Preferably, the server establishes a history rule mapping table according to a reference request rule of the first terminal and a reference query result matched with the reference request rule, where the reference request rule includes one or more history request elements and includes:
the method comprises the steps that a server receives a reference request rule of a first terminal, wherein the reference request rule comprises one or more history request elements;
analyzing historical request elements in the benchmark request rule to obtain a benchmark query result matched with the benchmark request rule;
and associating the reference request rule with the reference query result to establish a historical rule mapping table.
Preferably, the server receives a benchmark request rule of the first terminal, where the benchmark request rule includes one or more history request elements, and the method includes:
the method comprises the steps that a server receives a first request rule sent by a first terminal and an update rule associated with the first request rule;
and marking the latest updating rule as a benchmark request rule, wherein the benchmark request rule comprises one or more historical request elements.
Preferably, the server receives a first request rule sent by a first terminal, and the update rule associated with the first request rule includes:
the method comprises the steps that a server receives a first request rule and at least one updating rule sent by a first terminal;
judging whether at least one same historical request element exists between the first request rule and the updating rule which is started at first;
if so, determining that the first request rule is associated with an update rule that is started first;
whether at least one same historical request element exists between two adjacent update rules is judged in sequence from the update rule which is started first until the latest update rule associated with the first request rule is determined.
Preferably, the marking the latest update rule as a benchmark request rule, wherein the benchmark request rule includes one or more historical request elements includes:
judging whether the history request elements in the latest updating rule and the history request elements in other updating rules have equivalent history request elements or not;
if so, establishing association between the history request elements which are equivalent to each other to generate an equivalent relation cluster;
and establishing a reference request rule according to the latest updating rule and the equivalence relation cluster, wherein the reference request rule comprises one or more history request elements.
Preferably, the server receives a benchmark request rule of the first terminal, where the benchmark request rule includes one or more history request elements, and the method includes:
the server receives a first request rule sent by a first terminal;
sending a query result matched with the first request rule to the first terminal;
determining the satisfaction degree of the query result matched with the first request rule according to the feedback information of the first terminal;
when the satisfaction degree is not less than a preset threshold value, the first request rule is marked as a benchmark request rule, wherein the benchmark request rule comprises one or more historical request elements.
Preferably, the determining the satisfaction degree of the query result matched with the first request rule according to the feedback information of the first terminal includes:
the server sends a satisfaction survey request to the first terminal;
receiving a satisfaction conclusion fed back by the first terminal according to the satisfaction investigation request;
and determining the satisfaction degree of the query result matched with the first request rule according to the satisfaction degree conclusion.
Preferably, the determining the satisfaction degree of the query result matched with the first request rule according to the feedback information of the first terminal includes:
the server monitors the first terminal, and performs data operation after receiving the query result matched with the first request rule;
and determining the satisfaction degree of the query result matched with the first request rule according to the data operation.
Preferably, the data operation includes copying, downloading or rule adjustment;
when the data operation is copying and/or downloading, the server judges that the satisfaction degree of the query result matched with the first request rule is not less than a preset threshold value;
when the data operation is rule adjustment, the server judges that the satisfaction degree of the query result matched with the first request rule is smaller than a preset threshold value.
According to another aspect of the present invention, there is provided an apparatus for rule analysis, comprising at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor and programmed to perform the rule analysis method of the present invention.
Generally, compared with the prior art, the technical scheme of the invention has the following beneficial effects: the server establishes a historical rule mapping table according to a reference request rule of a first terminal, and after receiving a target request rule sent by a second terminal, the server firstly matches the target request rule with the reference request rule in the historical rule mapping table to determine a primary request element and a historical request element. Then, obtaining a query result matched with the historical request element from the historical rule mapping table, and obtaining a query result matched with the primary request element from the database; and combining the query result matched with the historical request element and the query result matched with the primary request element to obtain a target query result matched with the target request rule.
The invention analyzes the target request rule of the second terminal based on the existing historical rule mapping table, and when the target request rule and the reference request rule have cross overlapped request elements (historical request elements), the query result corresponding to the historical request elements can be directly obtained from the historical rule mapping table, so that repeated rule analysis by the server can be avoided, the calculation amount of the rule analysis and the time consumed by the rule analysis are reduced, the efficiency of the rule analysis can be effectively improved, and the resource utilization rate of the server is improved.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required to be used in the embodiments of the present invention will be briefly described below. It is obvious that the drawings described below are only some embodiments of the invention, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.
Fig. 1 is a schematic structural diagram of establishing a connection between a server and a terminal according to an embodiment of the present invention;
FIG. 2 is a schematic flow chart illustrating a rule analysis method according to an embodiment of the present invention;
FIG. 3 is a schematic flow chart illustrating step 20 of FIG. 2 according to an embodiment of the present invention;
FIG. 4 is a flowchart illustrating a specific process of step 201 in FIG. 3 according to an embodiment of the present invention;
FIG. 5 is a schematic flow chart illustrating the specific process of step 2012a in FIG. 4 according to an embodiment of the present invention;
FIG. 6 is another specific flowchart of step 201 in FIG. 3 according to an embodiment of the present invention;
fig. 7 is a schematic structural diagram of an apparatus for rule analysis according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
In addition, the technical features involved in the embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other.
Example 1:
currently, when a server queries data according to a request rule of a terminal, the server generally calculates condition elements included in the rule once, and obtains an execution result corresponding to the rule according to the calculation results of different condition elements. In the operation process, the more condition elements are included in the rule, the more complicated the logic operation between the condition elements is, the longer the rule running time is, the lower the query efficiency is, and the larger the consumption of server resources is caused. In particular, when the server is connected to different terminals and request elements of different terminals overlap with each other, the server needs to repeatedly perform analysis and calculation on the same condition elements, which results in lower query efficiency and higher consumption of server resources as the rule running time is longer.
In order to solve the foregoing problems, this embodiment provides a rule analysis method, where an existing history rule mapping table is used to analyze a target request rule of a second terminal, and when a request element (history request element) in which the target request rule and a reference request rule are overlapped with each other exists, a query result corresponding to the history request element may be directly obtained from the history rule mapping table, so that repeated rule analysis performed by a server may be avoided, an amount of computation of the rule analysis and time consumed by the rule analysis are reduced, efficiency of the rule analysis may be effectively improved, and resource consumption of the server may be reduced.
In an actual application scenario, as shown in fig. 1, the server establishes connections with at least two different terminals, for example, the server establishes connections with the first terminal and the nth terminal of the second terminal … …, respectively, where n is a positive integer. The server receives the request rules of different terminals and analyzes the request elements in the request rules of the terminals, so that corresponding query results are obtained according to the request rules and sent to the corresponding terminals.
Here, the rule analysis method of the present embodiment is explained by taking an example in which a server establishes connections with a first terminal and a second terminal, respectively.
Referring to fig. 2 to fig. 6, one implementation of the rule analysis method of the present embodiment is described below, where the rule analysis method of the present embodiment includes the following steps:
step 20: the server establishes a historical rule mapping table according to a reference request rule of the first terminal and a reference query result matched with the reference request rule, wherein the reference request rule comprises one or more historical request elements.
In this embodiment, the server establishes a history rule mapping table according to a reference request rule of the first terminal and a reference query result matched with the reference request rule, where the reference request rule includes one or more request elements. In a specific application scenario, the request element may be a specific parameter, a keyword, or other search condition, and may be determined according to a behavior request or an event request input by a user.
The number of the reference request rules corresponding to the first terminal is one or more, and each reference request rule corresponds to one historical rule mapping table. And the server stores all the historical rule mapping tables corresponding to each terminal in a set cache region, and the cache regions corresponding to the historical rule mapping tables stored in each terminal are mutually independent.
Here, the history request element is a request element that occurs in advance and is stored in the history rule mapping table. For the convenience of the following description, the request element in the reference request rule is described as a history request element with respect to the subsequent initial request element.
As shown in fig. 3, step 20 specifically includes the following sub-steps:
step 201: the server receives a reference request rule of the first terminal, wherein the reference request rule comprises one or more history request elements.
In this embodiment, a server receives a request message sent by a first terminal, where the request message carries a reference request rule, and the reference request rule includes one or more history request elements. In a specific application scenario, the number of request elements included in the reference request rule depends on the actual situation, and is not specifically limited herein.
Step 202: and analyzing historical request elements in the benchmark request rule to obtain a benchmark query result matched with the benchmark request rule.
In this embodiment, the server analyzes the history request elements in the benchmark request rule, and obtains the query result corresponding to each history request element from an existing history rule mapping table and/or a database, and then integrates the query results corresponding to all the history request elements to obtain the benchmark query result corresponding to the benchmark request rule.
Step 203: and associating the reference request rule with the reference query result to establish a historical rule mapping table.
In this embodiment, the reference request rule, the reference query result, and the query result corresponding to each history request element included in the reference request rule are associated to establish a history rule mapping table, and the history rule mapping table is cached in the temporary storage area.
Here, it should be noted that the reference request rule of the present embodiment is only to refer to the request rule sent by the first terminal, so as to distinguish the request rule sent by the second terminal.
There are many different ways for the acquisition of the benchmark request rules, specifically as follows:
the first method is as follows: under a specific application scenario, a user can adjust the request rule according to the query result transmitted by the server until receiving the expected query result. In the query process, the first terminal and the server have multiple rounds of data interaction, and in order to acquire a proper and effective benchmark request rule, the server marks the latest update rule as the benchmark request rule. The specific implementation mode is as follows:
as shown in fig. 4, step 201 specifically includes the following steps:
step 2011 a: the server receives a first request rule sent by a first terminal and an update rule associated with the first request rule.
In a specific application scenario, when at least one of the historical request elements in the first request rule and the update rule is the same, it may be determined that the first request rule and the update rule have an association.
In the actual query process, there may be multiple adjustment updates to the first request rule, so that a certain update rule may not have the same historical request elements as the first request rule, and in order to ensure the accuracy of the server determination, there is also a preferred scheme, as follows:
in a preferred embodiment, the server receives a first request rule and at least one update rule sent by a first terminal, determines whether at least one same historical request element exists between the first request rule and the update rule started first, and if so, determines that the first request rule is associated with the update rule started first. Then, whether at least one same historical request element exists between two adjacent update rules is sequentially judged from the update rule which is started first, if so, the two adjacent update rules can be judged to have relevance, and the like, until the latest update rule which is associated with the first request rule is determined.
And if the same request elements do not exist between the first request rule and the update rule started firstly, determining that the first request rule does not have relevance with the update rule started firstly, and marking the first request rule as a reference request rule.
In this embodiment, the latest update rule is marked as a benchmark request rule, where the benchmark request rule includes one or more historical request elements.
The second method comprises the following steps: in order to improve the coverage rate and the multiplexing effect of the historical rule mapping table, as shown in fig. 5, step 2011a specifically includes the following sub-steps:
step 2012 a-1: whether the history request element in the latest updating rule and the history request element in other updating rules have the same history request element is judged.
In an actual application scenario, there may be identical request elements in different request rules, for example, if the request element a is an LCD and the request element B is a liquid crystal display, the request element a and the request element B are identical request elements; alternatively, when the request element a and the request element B are synonyms, the request element a and the request element B are also equivalent request elements.
Step 2012 a-2: and if so, establishing association between the history request elements which are equivalent to each other so as to generate an equivalent relation cluster.
In this embodiment, when there is an equivalent history request element between the history request element in the latest update rule and the history request element in another update rule, the history request elements that are equivalent to each other are associated to generate an equivalence relation cluster.
Step 2012 a-3: and establishing a reference request rule according to the latest updating rule and the equivalence relation cluster, wherein the reference request rule comprises one or more history request elements.
In the actual query process, when the request element in the target request rule sent by the second terminal is the same as the historical request element in the equivalence relation cluster, it may be determined that the request element in the target request rule is the historical request element, and the server obtains the query result matching the request element from the historical rule mapping table.
And the second mode is further optimized to the first mode, so that the coverage rate and the multiplexing effect of the historical rule mapping table can be effectively improved.
The third method comprises the following steps: in this embodiment, a history rule mapping table is also established according to the satisfaction degree of the query result, so that the applicability of the history rule mapping table is improved. As shown in fig. 6, step 201 further includes the following sub-steps:
Step 2012 b: and sending the query result matched with the first request rule to the first terminal.
Step 2013 b: and determining the satisfaction degree of the query result matched with the first request rule according to the feedback information of the first terminal.
In one embodiment, the server sends a satisfaction survey request to the first terminal, receives a satisfaction conclusion fed back by the first terminal according to the satisfaction survey request, and determines the satisfaction degree of the query result matched with the first request rule according to the satisfaction conclusion. After the satisfaction is obtained, the server determines whether the satisfaction of the query result matched with the first request rule is not less than a preset threshold, and if the satisfaction is not less than the preset threshold, step 2014b is executed. And when the satisfaction degree is less than a preset threshold value, not marking the first request rule as a reference request rule.
In another embodiment, a monitoring program is arranged on the terminal side, and the server monitors the first terminal through the monitoring program arranged on the first terminal side, so as to obtain data operation performed by the first terminal after receiving the query result matched with the first request rule, and determine the satisfaction degree of the query result matched with the first request rule according to the data operation.
In an actual application scenario, the data operation includes copying, downloading, or rule adjustment. When the data operation is copying and/or downloading, the server judges that the satisfaction degree of the query result matched with the first request rule is not less than a preset threshold value, and marks the first request rule as a reference request rule; when the data operation is rule adjustment, the server judges that the satisfaction degree of the query result matched with the first request rule is smaller than a preset threshold value, and the fact that the user is still updating the rule is indicated.
Step 2014 b: when the satisfaction degree is not less than a preset threshold value, the first request rule is marked as a benchmark request rule, wherein the benchmark request rule comprises one or more historical request elements.
In an actual application scenario, different obtaining manners may be combined with each other to obtain a reference request rule that is most matched with an actual requirement, for example, the first manner and the third manner may be combined, or the second manner and the third manner may be combined, so as to improve accuracy, effectiveness, and reusability of the history rule mapping table.
In this embodiment, the server may clear the history rule mapping table in the cache region according to the actual situation, so as to avoid a large amount of useless resources from occupying the memory of the server, and improve the resource utilization rate of the server. In one embodiment, the server establishes association between a reference request rule of the first terminal and a reference query result matched with the reference request rule, and establishes a historical rule mapping table; caching the historical rule mapping table to a temporary storage area, and establishing a life cycle for the historical rule mapping table; and deleting the historical rule mapping table after the life cycle is finished.
In an actual application scenario, the reuse rate of a part of history rule mapping tables may be high, and in order to avoid deleting such history rule mapping tables, the server may prolong the life cycle of the history rule mapping table according to the use condition of the history rule mapping table.
In one embodiment, when the life cycle of the history rule mapping table is close to the end, the server obtains the last time of use of the history rule mapping table, and judges whether the time difference between the last time of use of the history rule mapping table and the current time is smaller than a preset time threshold, if so, the life cycle of the history rule mapping table is prolonged if the history rule mapping table is still used recently.
In another embodiment, the server obtains the frequency of use of the history rule mapping table near the end of the life cycle of the history rule mapping table, wherein the frequency of use is obtained based on a preset time range, for example, the frequency of use of the previous month at the current time. Judging whether the use frequency of the historical rule mapping table is greater than a preset use frequency threshold, if so, indicating that the use frequency of the historical rule mapping table is higher, and prolonging the life cycle of the historical rule mapping table.
In an actual application scenario, the use frequency of the history rule mapping table and the last use time of the history rule mapping table may be combined as a criterion for determining whether the life cycle of the history rule mapping table needs to be extended. Regarding the judgment process, the descriptions of the two foregoing embodiments can be combined, and are not repeated herein.
Step 21: and receiving a target request rule of the second terminal, wherein the target request rule comprises one or more request elements.
In this embodiment, the server receives a target request rule of the second terminal, where the target request rule includes one or more request elements. In a specific application scenario, the request element may be a specific parameter, a keyword, or other search condition, and may be determined according to a behavior request or an event request input by a user.
Here, it should be noted that the target request rule of the present embodiment is only to refer to the request rule sent by the second terminal, so as to distinguish the request rule sent by the first terminal before.
Step 22: and matching the target request rule with the reference request rule to determine a primary request element and a historical request element.
In this embodiment, the server matches the target request rule with the reference request rule, and determines an initial request element and a history request element. The history request element refers to a request element existing in the history rule mapping table, and the initial request element refers to a request element not existing in the history rule mapping table.
In an actual application scenario, when the server includes a plurality of history rule mapping tables, the server may match the target request rule with the plurality of history rule mapping tables one by one to determine the primary request element and the history request element.
Step 23: and acquiring a query result matched with the historical request element from a historical rule mapping table, and acquiring a query result matched with the primary request element from a database.
In this embodiment, the query result matched with the history request element may be obtained from the history rule mapping table, and this way may reduce the amount of analysis and calculation processing of the server, reduce the pressure of data processing of the server, and improve the efficiency of query.
And then, analyzing the primary request element, and acquiring a query result matched with the primary request element from a database corresponding to the server.
Step 24: and combining the query result matched with the historical request element and the query result matched with the primary request element to obtain a target query result matched with the target request rule.
In this embodiment, the query result matched with the historical request element and the query result matched with the primary request element are combined to obtain the target query result matched with the target request rule.
Here, it should be emphasized that the server stores one or more history rule mapping tables corresponding to the first terminal, the server stores one or more history rule mapping tables corresponding to the second terminal, and the server also stores one or more history rule mapping tables corresponding to the nth terminal. The process of obtaining the history rule mapping table corresponding to each terminal can be according to step 20 and the related text description, which is not described herein again.
After receiving the request rule of the nth terminal, the server may obtain a corresponding query result from a history rule mapping table corresponding to other terminals (e.g., other terminals such as the first terminal and the second terminal) except the nth terminal according to the request element in the request rule.
Of course, in an actual application scenario, after the server receives the request rule of the nth terminal, the server may also obtain a corresponding query result from the history rule mapping table corresponding to the nth terminal.
For clarity of the rule analysis method of the present embodiment, the following is illustrated here:
the server corresponding to the public security system establishes connection with different terminals, for example, the server corresponding to a certain public security system establishes connection with a first terminal, and the server also establishes connection with a second terminal. The method comprises the steps that a first terminal sends a request message to a server, the request message carries a first request rule, the first request rule comprises a request element A, a request element B and a request element C, the server analyzes the request element A, the request element B and the request element C, obtains a result corresponding to each request element, and then sends a query result meeting the first request rule to the first terminal. In an actual application scenario, the request element may be information such as a name, a residence, and an identity card number. The request element a, the request element B, and the request element C are history request elements.
The server also establishes a relation between the query result corresponding to the first request rule and the first request rule, and generates a history rule mapping table, wherein the history rule mapping table comprises the query results corresponding to the request element A, the request element B and the request element C, the query result corresponding to the first request rule and the first request rule.
The second terminal sends a second request rule to the server, the second request rule comprises a request element A, a request element B and a request element D, the server matches the request element in the second request rule with a history rule mapping table corresponding to the first terminal, at the moment, the server confirms that the request element A and the request element B in the second request rule are overlapped with the request element A and the request element B in the first request rule in a crossed mode, namely the request element A and the request element B are history request elements, and the server obtains query results corresponding to the request element A and the request element B from the history rule mapping table. And the server confirms that the request element C is the initial request element, and then the server acquires the query result corresponding to the request element C from the database of the server.
And finally, combining the query results corresponding to the request element A and the request element B acquired from the historical rule mapping table and the query results corresponding to the request element C acquired from the database by the server to obtain the query results corresponding to the second request rule.
The invention analyzes the target request rule of the second terminal based on the existing historical rule mapping table, and when the target request rule and the reference request rule have cross overlapped request elements (historical request elements), the query result corresponding to the historical request elements can be directly obtained from the historical rule mapping table, so that repeated rule analysis by the server can be avoided, the calculation amount of the rule analysis and the time consumed by the rule analysis are reduced, the efficiency of the rule analysis can be effectively improved, and the resource utilization rate of the server is improved.
Example 2:
referring to fig. 7, fig. 7 is a schematic structural diagram of an apparatus for rule analysis according to an embodiment of the present invention. The apparatus for rule analysis of the present embodiment comprises one or more processors 71 and a memory 72. Fig. 7 illustrates an example of one processor 71.
The processor 71 and the memory 72 may be connected by a bus or other means, such as the bus connection in fig. 7.
The memory 72, which is a non-volatile computer-readable storage medium based on rule analysis, may be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the rule analysis method and corresponding program instructions in embodiment 1. The processor 71 implements the functions of the rule analysis method of embodiment 1 by executing various functional applications and data processing of the rule analysis method by executing nonvolatile software programs, instructions, and modules stored in the memory 72.
The memory 72 may include, among other things, high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 72 may optionally include memory located remotely from the processor 71, and such remote memory may be connected to the processor 71 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
Please refer to fig. 1 to 6 and the related text description for the rule analysis method, which are not repeated herein.
It should be noted that, for the information interaction, execution process and other contents between the modules and units in the apparatus and system, the specific contents may refer to the description in the embodiment of the method of the present invention because the same concept is used as the embodiment of the processing method of the present invention, and are not described herein again.
Those of ordinary skill in the art will appreciate that all or part of the steps of the various methods of the embodiments may be implemented by associated hardware as instructed by a program, which may be stored on a computer-readable storage medium, which may include: a Read Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and the like.
It will be understood by those skilled in the art that the foregoing is only a preferred embodiment of the present invention, and is not intended to limit the invention, and that any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the scope of the present invention.
Claims (7)
1. A rule analysis method is characterized in that a server establishes a historical rule mapping table according to a reference request rule of a first terminal and a reference query result matched with the reference request rule, wherein the reference request rule comprises one or more historical request elements;
the rule analysis method comprises the following steps:
receiving a target request rule of a second terminal, wherein the target request rule comprises one or more request elements;
matching the target request rule with the reference request rule to determine a primary request element and a historical request element;
obtaining a query result matched with the history request element from a history rule mapping table; obtaining a query result matched with the primary request element from a database;
combining the query result matched with the historical request element and the query result matched with the primary request element to obtain a target query result matched with the target request rule;
the server establishes a history rule mapping table according to a reference request rule of a first terminal and a reference query result matched with the reference request rule, wherein the reference request rule comprises one or more history request elements and comprises the following steps:
the method comprises the steps that a server receives a reference request rule of a first terminal, wherein the reference request rule comprises one or more history request elements;
analyzing historical request elements in the benchmark request rule to obtain a benchmark query result matched with the benchmark request rule;
associating the reference request rule with the reference query result, and establishing a historical rule mapping table;
the method for receiving the reference request rule of the first terminal by the server includes the following steps that:
the method comprises the steps that a server receives a first request rule sent by a first terminal and an update rule associated with the first request rule;
marking the latest updating rule as a reference request rule, wherein the reference request rule comprises one or more history request elements;
the server receives a first request rule sent by a first terminal, and the updating rule associated with the first request rule comprises:
the method comprises the steps that a server receives a first request rule and at least one updating rule sent by a first terminal;
judging whether at least one same historical request element exists between the first request rule and the updating rule which is started at first;
if so, determining that the first request rule is associated with an update rule that is started first;
whether at least one same historical request element exists between two adjacent update rules is judged in sequence from the update rule which is started first until the latest update rule associated with the first request rule is determined.
2. The method of claim 1, wherein the marking the latest update rule as a benchmark request rule, wherein the benchmark request rule includes one or more historical request elements comprises:
judging whether the history request elements in the latest updating rule and the history request elements in other updating rules have equivalent history request elements or not;
if so, establishing association between the history request elements which are equivalent to each other to generate an equivalent relation cluster;
and establishing a reference request rule according to the latest updating rule and the equivalence relation cluster, wherein the reference request rule comprises one or more history request elements.
3. The rule analysis method of claim 1, wherein the server receives a benchmark request rule of the first terminal, wherein the benchmark request rule comprises one or more historical request elements, and comprises:
the server receives a first request rule sent by a first terminal;
sending a query result matched with the first request rule to the first terminal;
determining the satisfaction degree of the query result matched with the first request rule according to the feedback information of the first terminal;
when the satisfaction degree is not less than a preset threshold value, the first request rule is marked as a benchmark request rule, wherein the benchmark request rule comprises one or more historical request elements.
4. The rule analysis method according to claim 3, wherein the determining the satisfaction degree of the query result matching the first request rule according to the feedback information of the first terminal comprises:
the server sends a satisfaction survey request to the first terminal;
receiving a satisfaction conclusion fed back by the first terminal according to the satisfaction investigation request;
and determining the satisfaction degree of the query result matched with the first request rule according to the satisfaction degree conclusion.
5. The rule analysis method according to claim 3, wherein the determining the satisfaction degree of the query result matching the first request rule according to the feedback information of the first terminal comprises:
the server monitors the first terminal, and performs data operation after receiving the query result matched with the first request rule;
and determining the satisfaction degree of the query result matched with the first request rule according to the data operation.
6. The rule analysis method of claim 5 wherein the data operation comprises a copy, a download or a rule adjustment;
when the data operation is copying and/or downloading, the server judges that the satisfaction degree of the query result matched with the first request rule is not less than a preset threshold value;
when the data operation is rule adjustment, the server judges that the satisfaction degree of the query result matched with the first request rule is smaller than a preset threshold value.
7. An apparatus for rule analysis, comprising at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor and programmed to perform the rule analysis method of any one of claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811529586.5A CN109684361B (en) | 2018-12-14 | 2018-12-14 | Rule analysis method and corresponding rule analysis device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811529586.5A CN109684361B (en) | 2018-12-14 | 2018-12-14 | Rule analysis method and corresponding rule analysis device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109684361A CN109684361A (en) | 2019-04-26 |
| CN109684361B true CN109684361B (en) | 2020-10-16 |
Family
ID=66186743
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811529586.5A Active CN109684361B (en) | 2018-12-14 | 2018-12-14 | Rule analysis method and corresponding rule analysis device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109684361B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112418570A (en) * | 2019-08-19 | 2021-02-26 | 阿里巴巴集团控股有限公司 | Production process sheet generation method and device |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101398810A (en) * | 2007-09-30 | 2009-04-01 | 日电（中国）有限公司 | Self-adapting service choice device and method thereof, enquiry system and method thereof |
| CN102479223A (en) * | 2010-11-25 | 2012-05-30 | 中国移动通信集团浙江有限公司 | Data query method and system |
| CN102708129A (en) * | 2011-03-04 | 2012-10-03 | 微软公司 | Using computer engine to improve searching relevance |
| CN107092529A (en) * | 2017-02-10 | 2017-08-25 | 北京小度信息科技有限公司 | OLAP method of servicing, apparatus and system |
| CN107256267A (en) * | 2017-06-19 | 2017-10-17 | 北京百度网讯科技有限公司 | Querying method and device |
| CN107832468A (en) * | 2017-11-29 | 2018-03-23 | 百度在线网络技术（北京）有限公司 | Demand recognition methods and device |
| CN108121733A (en) * | 2016-11-29 | 2018-06-05 | 北京国双科技有限公司 | The querying method and device of a kind of data |
-
2018
- 2018-12-14 CN CN201811529586.5A patent/CN109684361B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101398810A (en) * | 2007-09-30 | 2009-04-01 | 日电（中国）有限公司 | Self-adapting service choice device and method thereof, enquiry system and method thereof |
| CN102479223A (en) * | 2010-11-25 | 2012-05-30 | 中国移动通信集团浙江有限公司 | Data query method and system |
| CN102708129A (en) * | 2011-03-04 | 2012-10-03 | 微软公司 | Using computer engine to improve searching relevance |
| CN108121733A (en) * | 2016-11-29 | 2018-06-05 | 北京国双科技有限公司 | The querying method and device of a kind of data |
| CN107092529A (en) * | 2017-02-10 | 2017-08-25 | 北京小度信息科技有限公司 | OLAP method of servicing, apparatus and system |
| CN107256267A (en) * | 2017-06-19 | 2017-10-17 | 北京百度网讯科技有限公司 | Querying method and device |
| CN107832468A (en) * | 2017-11-29 | 2018-03-23 | 百度在线网络技术（北京）有限公司 | Demand recognition methods and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109684361A (en) | 2019-04-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10783212B2 (en) | Method and apparatus for realizing communication between web page and native application, and electronic device | |
| US20130318536A1 (en) | Dynamic scheduling of tasks for collecting and processing data from external sources | |
| US20110179138A1 (en) | Method of reflecting on another device a change to a browser cache on a handheld electronic device, and assocaited device | |
| CN109388626B (en) | Method and apparatus for assigning numbers to services | |
| CN111221469B (en) | Method, device and system for synchronizing cache data | |
| US10127037B2 (en) | Method for recognizing application type | |
| CN109542851A (en) | File updating method, apparatus and system | |
| US11146660B2 (en) | Information packet download method for preventing high concurrency, electronic device and storage medium | |
| CN104683457A (en) | Concurrency control method and device | |
| WO2020232878A1 (en) | Spring mvc-based timed task processing method, apparatus and computer device | |
| CN111159233B (en) | Distributed caching method, system, computer equipment and storage medium | |
| CN111224831B (en) | Method and system for generating call ticket | |
| CN109684361B (en) | Rule analysis method and corresponding rule analysis device | |
| CN107918617B (en) | Data query method and device | |
| CN110741617B (en) | Resource updating method and device, computer equipment and storage medium | |
| CN105530323B (en) | File upgrading method, related equipment and system | |
| CN109471713B (en) | Method and device for inquiring information | |
| US20150095496A1 (en) | System, method and medium for information processing | |
| CN117033468A (en) | Data query method, device, electronic equipment and computer readable storage medium | |
| CN114693220B (en) | Algorithm warehouse management method and system based on digital twin DaaS platform | |
| CN112784318A (en) | Method, device and storage medium for generating unique identification code of equipment | |
| CN107872493B (en) | Information processing method, terminal and server | |
| CN115361279A (en) | Configuration data updating method and device, electronic equipment and computer readable medium | |
| CN112328245A (en) | Page display method, system, electronic equipment and storage medium | |
| CN109413151B (en) | Proxy server for updating files |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CP01 | Change in the name or title of a patent holder | ||
| CP01 | Change in the name or title of a patent holder |
Address after: 430000 High-tech Avenue 999, Donghu New Technology Development Zone, Wuhan City, Hubei Province Patentee after: Wuhan dream database Co., Ltd Address before: 430000 High-tech Avenue 999, Donghu New Technology Development Zone, Wuhan City, Hubei Province Patentee before: WUHAN DAMENG DATABASE Co.,Ltd. |