Development and implementation of an expert database

Development and implementation of an expert database

Qi Yudong Li Yibo lacks knowledge about traditional database systems and can only process static data. The narrow application fields of expert systems and the inability to access existing databases prevent the effective application of expert systems. The limitations of the independent development of databases and Artificial Intelligence have prompted the two to learn from each other and develop together. This is the reason for the emergence and development of the expert database eds (expert database syst em. Generally, we refer to a database system with both database management and deduction capabilities and good performance in Expert Systems as expert databases. The basic idea of EDS is to introduce the ES (Expert System) technology, which focuses on Knowledge Expression and Knowledge Processing, into the traditional database, so that the two can be organically combined, to develop a knowledge-oriented problem solving system that can share information. At present, EDS mainly adopts system coupling-"tight coupling" and "loose coupling. Tight coupling refers to the integration of the rule management system into the DBMS so that the DBMS can manage both the database and the rule repository. This method is difficult to implement. Loose coupling refers to the combination of a ready-made Expert System Shell and a ready-made DBMS as two independent subsystems, which manage the rule repository and database respectively. The loosely coupled implementation strategy can give full play to all functions of the original two systems without any changes to the original system. It only needs to design an efficient and flexible interface module that connects ES/DBMS to coordinate the work of the two, so the implementation is short and quick. I. Fault Diagnosis Expert System Structure in the development of fault diagnosis system HF-2000, we adopt loose coupling strategy to establish a fault diagnosis expert database system. This system is a production system that uses the depth priority policy as its control policy. The system is rooted in the W indows platform and adopts the object-oriented programming technology and advanced database technology. At the Database End, we adopt the ms SQL database technology based on the server/client mechanism. In the reasoning control end, Visual C ++ is used for programming to implement a inference engine. The interfaces between the inference engine and the database are directly called through the odbc api to access the database. The construction model of the system is in the form of database-based modeling, as shown in figure 1. Figure 1 The Knowledge Acquisition Structure in Figure 1 is responsible for establishing, modifying, and expanding various databases. The interpretation mechanism is used to describe the solution process and identify the reasons for the success or failure of the solution, answer your questions. The inventory library is used to store the original and intermediate results of the input. The dictionary library is used to store the basic definitions and descriptions of the facts in the rules. The rule library is used to store rules. The waste bin is used to store the reasoning paths for failure in reasoning. Ii. Design of rules and databases 1. the general form of model rules for generative rules is: If <premise> then <CONCLUSION>, it indicates that when the <premise> is established, the credibility of the <CONCLUSION> is obtained. The premise is the form of combination of facts or assertions. For the Rule Model in the system, see Figure 2. 2. Producer database structure: fact_db (fact_id, rank, no) usage: stores the original input facts, intermediate results, and final results. Where: fact_id is the encoding of the fact; rank is used to indicate specific parts of the system, such as "amplification" and "slot"; no indicates the part number in a specific part; for example, "1" indicates "Groove", "1", "2" indicates "Groove", and "2" indicates "Groove. 3. dictionary library structure: dict_db (fac_id, component, appear, why, known) Purpose: store the prerequisites, conclusions, and codes in the rule repository. Where: fact_id is the fact encoding; component is the part name; appear is the natural language explanation of fact_id; known is used to indicate that the fact is known or unknown, to prevent repeated proof of the asserted. 4. the rule repository contains four tables: pre_table, active_pre table, and act_table) and active_act_tab le ). Figure 2 (1) rule repository structure: pre_table (rule_name, fact_id) Purpose: store the prerequisites for each rule. Where: rule_name is the rule name; fact_id is one and condition of the rule_name rule; N and condition of a rule have n records of the rule in this database. (2) Structure of the active rule repository: active_pre_table (fact_id, rank, no) Purpose: store the activated prerequisites to avoid repeated matching of the preconditions of the rule. Where: fact_id is a condition of the rule_name rule, rank is used to represent a specific part of the system, and no represents the part number in a specific part. (3) Post-rule database structure: act_table (rule_name, fact_id, num, num2) Purpose: store the results corresponding to the rule. Where: rule_name indicates the rule name, fact_id indicates the result of the rule_name rule, num indicates the number of preconditions for the rule, and num2 indicates the auxiliary value of the num field. (4) Structure of the activated rule post-Component Library: active_act_table (rule_name, rank, no) Purpose: store the activated post-parts to avoid repeated matching of each rule conclusion. Where: rule_name indicates the rule name; rank indicates a specific part of the system; no indicates the part number in a specific part. 5. Garbage bin structure: garbage_bin_db (fact_id, rule_name, pre_num) Purpose: records the reason for Removing dead branches. Fact_id indicates the fact encoding, rule_name indicates the rule name applied to the node, and pre_num indicates the number of conditions for actual matching. Iii. Design of the control mechanism we use the C ++ language to implement a reverse inference engine using a deep priority policy. The entire reasoning process. The source code of the inference engine for the process of long branches and side pruning in a search tree is as follows: int Ccause: reason (rtree * rtree) {rule prule, rule; int ruleflag; while (1) {While (true) {If (rtree-choose rule (& prule) = 1 {// select the applicable rule rtree-sctact (prule) for the current leaf node ); // put the current application rule into the active rule table ar ruleflag = 1; break;} else {ruleflag = 0; // if no rule is available, set the failure flag if (depth return 0; else {rtree-clipbranch (depth --; Path ++); // cut the dead branches if (depth! = 0) return 0; // if it is not the root of the tree, the failure flag is returned; otherwise, the reasoning is continued.} rtree-setleaf (& prule ); // set the first precondition to the current leaf node depth ++; while (1) {int isucc = 0; isucc = rtree-successdirect (); // whether the fact is immediately established if (isucc = 0) {// If the fact does not exist in the fact Library and the node is not a component, the search rule while (1) {If (rtree-choose rule (& rule) = 1) {// Search rules corresponding to the current leaf node ruleflag = 1; if (backreason (rtree) = 1) {// if the facts are true, the next premise is verified; otherwise, rtree undersuccess () is used for reasoning based on the next rule; // The facts are true, reset the current condition to the current leaf node break;} else {ruleflag = 0; // if no rule is available, set the failure flag break;} If (isucc = 1) {// If the fact is not true immediately, set the failure flag to 0; break;} If (ruleflag = 0) // if the current application rule fails, select the next rule to infer the break; else {If (prule. num = prule. num2) // verify the previous prerequisite successfully and determine whether there is any unverified prerequisite break: // if not, exit the loop else rtree-setleaf (& prule ); // If yes, set this premise to the current leaf node }}if (ruleflag = 1) {rtree-producenewfact (); // if the facts are successfully verified, add this fact return 1 to the warehouse; // return success mark }}( author's address: Graduate team of Shandong Yantai Naval Aviation Engineering College, 264001)