|
WILL BE REMOVED IN V5.9 REFER TO NEW KNOWLEDGE BASE CLUSTERING FUNCTIONALITY Multi-KB configurations (MKCs) refer to any configuration where a KB is accessing chains in one or more external databases (DBs). Access can be read-only or read-write. The terminology multi-KB configuration rather than multi-DB configuration, is used since each external database itself is an independent knowledge base (in technical terms although not necessarily in conceptual terms).
It is important to note that each KB in the configuration maintains its own dependency graph, and that in this respect, knowledge nodes in external databases are ignored. This is a particularly valid point of view in case of cyclic multi-KB configurations, which by design are such that an imaginary global dependency graph would have had cycles in it (dependency graphs cannot be acyclic). First a warning! Do not use MKCs until you are an experienced Pro/3 user. MKCs give room for many types of KE errors (missed-out external chains, conflicting chains (external and internal), index problems and other), and they are much harder to troubleshoot. MKCs came about mainly for two reasons, to get around performance issues in very large KBs (e.g. bigger than 300 MB), and to allow for smarter test and production configurations. Today's much more powerful processors and bigger RAMs, have made the first reason less important. It is now practical to work with fairly big single KBs. |
|||||||||||||||||
|
|
|||||||||||||||||
|
An open or active MKC always consists of a main DB and one or more external DBs. A DB consists of several chains. The access-scope in a MKC consists of all chains in the main DB and one or more chains in each of the external DBs. In other words, only a sub-set of the chains in an external DB forms a part of the access scope. A chain is either the set of all sentences in a particular sentence group plus all sentence rules which conclude (infer; derive) sentences in that group; all the definitions of a particular function; and also all inexact rules of the same class. Only the main database is explicitly opened by the KE - external databases are opened automatically by Pro/3 based on the contents of the script-file associated with the KB (XXX.xml for knowledge base XXX.3kb). All KBs must have a script-file (although the file serves no practical purpose for one-database KBs), which is generated automatically by PRO3.EXE. It can be edited as required.
Access to an external chain is either READ or WRITE. See pro3_Script.xsd for details. The presence of external chains are also stored in the main database using the chain is in external DB sentences. These sentences are adjusted (added, deleted or updates) according the contents of the script file (which is read when the main database is opened).
Note that the index tables in the main database cover records in the entire access scope. This impose some problems and overheads since external databases can be updated while separately opened or opened from another main database. (A database can serve as an external database for different KBs, and also as main database in another KB). Pro/3 uses KB timing event is in the KB sentences to administer this.
The upper window shows the timing sentences in the database containing the external chains (that is the update times of the database's public chains and its index tables). The lower window shows the single timing sentence in the database using the external chains. Clearly, the index tables in the latter database were updated after changes in the "source" database and the tables are thus up-to-date.
CROSS-DATABASE
UPDATES
The following chains can not be declared as public (i.e. can not be used as external chains):
|
|||||||||||||||||
|
EXTERNAL CHAINS - PUBLIC CHAINS The chains in the access scope in a MKC fall into two groups - internal chains and external chains. The external chains are the chains belonging to external DBs, while the internal chains are the chains belonging to the main DB. Note that a given chain can only belong to one DB in a MKC, i.e. a chain cannot be both internal and external, and secondly an external chain cannot belong to more than one external database. This constraint is only concerned with chains within the access scope, such that the same chain can very well exists in two or more of the external DBs as long as only one of these chain existences form a part of the access scope. External chains are either declared in the access scope as read-only or as read-write. The latter means that records in the chain can be added, deleted or changed while used as an external chain. A chain must be declared as public before it can be opened as an external chain. This can only be done while the chain is internal, that is, the database to which it belongs must be opened as the main DB. Declarations of chains as public as well as external, are stored in the KB as ordinary sentences:
|
|||||||||||||||||
|
Note that each function (i.e. the definitions which make up a function) is a chain itself. With respect to being internal, external and or public, they are just like any other chain. Note however that Pro/3 built-in functions are globally callable i.e. do not declare them as public or external. The Pro/3 function library source files include sentences which declare them as public. |
|||||||||||||||||
|
WINDOWS FOR DEFINING PUBLIC AND EXTERNAL CHAINS Since declarations of public and external chains are stored as any other factual knowledge, all standard ways of inputting, modifying or deleting such declarations are available. Two windows in the KB-menu can also be used for this purpose:
The first prefix of the external chains in the list is the corresponding database identifiers. The second prefix W signifies that the chains are read-write (as opposed to R for read-only).
The prefix R signifies that the chains are public read-only (as opposed to W for read-write). |
|||||||||||||||||
|
WORKING WITH PUBLIC AND EXTERNAL CHAINS Processing of external databases and external chains take place when a KB is opened and include the following:
It is important to note that opening of external chains take place in connection with the opening of the KB. Changes to external database or external chain declarations which take place during a session with the KB do not take effect until the next opening of the KB. The same is essentially valid for public chain declarations as well, however this is unimportant since the current version of Pro/3 does not allow a database to be concurrently opened by two or more KBs. In other words, public chain declarations are not relevant until the database where they are declared is closed. The processing which takes place when the KB is closed is as follows:
Consider the following financial problem. A bank has agreed to finance the full cost of building a factory for making wireless tranceivers. The construction will take 10 months and the first sales revenues are expected 2 months after completion of the construction. All non-financial project costs for the first 12 months is 100 mill. USD. The loan matures in five equal installments, however a one year grace period is given such that the first installment is due at the end of the second year. 10% interest is due every 12 months - the first interest payment is to be paid 12 months after the disbursement of the loan. The factory has no revenues to cover the first 10 mill. interest payment, and the bank has agreed to cover these costs in the financing plan by increasing the loan amount to 110 mill. However, the interest costs will in this case increase to 11 mill. and the loan should then rather be 111 mill. The problem is principally unsolvable, but can in practice be resolved through iteration until the required laccuracy is achieved. A KB cannot contain cycles in the dependency graph, and recursive/self-referential problems as the one above will result in such cycles. One way around this is to use two KBs, where each KB uses the other as an external DB. Consider the KB "L" which derives one sentence stating the required loan amount, and the KB "I" which derives one sentence which states the amount of interest paid during the year of construction. The dependency graph in each KB ignores knowledge nodes in the external DB, and consequently each dependency graph s acyclic. We basically need only one rule in each database, that is, if the first year interest X is payable, then the loan (100,000,000.00+X) is required in the loan KB, and if the loan X is required, then the first year interest (X*10%) is payable. However, since there are no first year interest payable sentence to start the iteration, one starter rule is added to the loan KB: if false(first year interest X is payable), then the loan 100,000,000.00 is required. We can the proceed as follows:
A considerably more complex MKC is used in solving the Einstein Puzzle. MULTI-KB SENTENCE DERIVATION WINDOW A special processing window is included in Sentences-menu to make the operations above a little easier to carry out:
The window makes it possible to carry out sentence derivation activities in a MKC in one operation, i.e. sentence derivation in across a set of inter-related KBs (whether cyclic or not). The list of KBs in the set is defined in the window (and subsequently stored and retrieved from a derivation script-file e.g. rederivation.xml). See pro3_Script.xsd for details.
The following actions can be carried out with the set:
1+2 combined and 1+2+3 combined can also be done. |
