Pro/3 knowledge can either be stored in a 3KB-type database (Pro/3's native database system based Visual Prolog's chain database), or in an SQL database. 3KB-type knowledge bases can be stored in two or more databases in the case of multi-DB configurations. There is no multi-DB configuration concept with SQL-type knowledge bases.

A 3KB-type database is stored in one OS file with name xxx.3kb - xxx is referred to as the name of the knowledge base.

 

DATABASE

A 3KB database is a collection of chains ("record sets") and index tables stored in a single operating system file. A database contains a knowledge base or a part of a knowledge base (refer to multi-DB configurations).

 

CHAINS

A chain is a set of records identified by a chain name.

 

RECORD ADDRESS
A database record has a unique 12-digit long hexadecimal address prefixed by the database identifier and a colon e.g. A:000000C91110. Record addresses are typically embedded in square brackets when combined with other information.

 

INDEX TABLES

Index tables are used to speed up access to records. Index tables are automatically administered by Pro/3 and largely transparent to the KE. Some elements of interaction with the KE is involved in connection with multi-database KBs.

Index tables are not used by the inference engine.

TOKEN:            Language|FirstToken
SYN1:               Language|KB_Id
REALM:            Realm|KBid
RULE:               Chain|Realm|SentNo|SubNo [UNIQUE]
RTYP:               RecordType|ChainRT
 
RECORD TYPE SENTENCE GROUP/TYPE TOKEN index SYN1 index RULE index RTYP index REALM index
2 p3_pDP,p3_pSM,p3_pDR          
2 v|t X X     X
2 v|s X       X
2 ALL OTHER         X
20 v|t X X   X X
20 v|s X     X X
20 ALL OTHER       X X
+/-  3/30/5/50       X X X
4/40         X X
6         X X

 

KNOWLEDGE BASE (KB)

A knowledge base (KB) consists of either a single database, or a superstructure of two or more databases. More specifically, a KB consists of a main database and zero, one or several external databases. Configurations where external databases are used are referred to as multi-DB configurations. A KB does not make any use of index tables in external databases. Further, a KB only uses a explicitly listed set of one or more chains in each external database. The collection of chains used by a KB is called the access scope. Each chain in the access scope can exist only in one database.

DB Identifier

Each database is assigned a one-letter database identifier. This assignment takes place when the database is created and is stored as sentence in the database. A multi-DB configuration must locally assign a different identifier for each of the external databases accessed. These locally assigned identifiers do not have to match the identifiers stored in external databases. 

You can change the DB identifier i.e. by (1) changing the DB is in the KB-sentence; and (2) regenerating indexes and graphs (ref. KB-menu).

 

ACCESS SCOPE (in multi-DB configurations)

The access scope of a KB consists of all chains in the main database (internal chains) and a selection of chains from external databases (if any). These are called external chains. The access scope can only include one occurrence of a chain name in its access scope .

 

OPENING A KB

Opening external databases

Sentences defining external chains are reviewed by Pro/3 upon the KB-open command. Pro/3 automatically opens the external databases and checks that all external chains are declared as public (in the external database), and that access can be granted as required (i.e. read-only or read-write). Error messages are given if this is not the case, and the KE has to decide either to revoke the external chain definition or to abort the session. Pro/3 then reviews the public-table, i.e. whether or not any chain is declared as public read-write. Error messages will also be issued if external databases cannot be found or are undefined (ref. DB is in the KB sentences over). The KE has the option of entering a new DB identifier and KB file name.

Index tables

All index tables have to be re-generated if either at least one external or public chain has been updated since last index table update, or if a new external chain has been added, removed or changed as judged by the contents of the chain locator file. The KE will be prompted to confirm index re-generation. However, consistency problems might be experienced if index re-generation is ignored.

 

DATABASE GARBAGE COLLECTION - MAKING A COPY

The size of the database file will never shrink even if you delete large volumes of records. Instead areas of free space will build up inside the file. This will be the case if you successively re-derive sentences. You can organize this free space in an efficient manner through the Garbage collection command in the KB-menu.

To reduce the database file you will have to follow the garbage collection by making a copy of the main database to another file (the Make copy-command In the KB-menu). You should in this case consider deleting all derived sentences prior to garbage collection.