Pro/3 knowledge can either be stored in a 3KB-type database (Pro/3's native database system), or in an SQL database. Pro/3 accesses the database via ODBC.

A KB is fully contained in one SQL database, while on the other hand, an SQL database can contain more than one KB. However, this should be avoided in all but special cases as the chain tables (table names) could clash (a chain with the same name in two or more KBs will use the same chain table unless a different chain table prefix is used).

The naming convention for SQL-based KBs is [path]<SqlDatabase>.<KbName.sql. The optional path has nothing to do with the location of the SQL database, but rather indicates the default directory for the KB's configuration file and knowledge source files (if any). An SQL-type knowledge base is stored as a set of tables in one SQL database. A knowledge base named xxx stored in SQL database yyy, is referred to as yyy.xxx.sql.

CHAIN TABLES, MAIN TABLE, PARAMETER TABLE

A Pro/3 SQL-type database has one table per chain, where each record in the table corresponds to a Pro/3 record (for that chain). There is also a main table with one record for every record in the chain-tables, and finally a parameter-table which only has one record.

Naming conventions:

• Chain-table names: <chainTablePrefix><chainName>
• Main table name: p3kb_<kbName>
• Parameter-table name: p3pm_<kbName>

The table names are truncated if necessary (according to the max SQL-name parameter).

Each chain-table has an integer column ref with a unique value for each record in the table. The ref-value and the chain name (which corresponds to a table on a one-to-one basis), uniquely identifies a record.

Refer to the SQL schema template and the the KB Initialization-window for details.

Note that column names and index names are not case sensitive in MySQL. Table names in MySQL under Windows are not case sensitive either. However, to be best prepared for any future changes in this regard, it is a good idea to use case in a consistent manner.

RECORD ADDRESS

Each record in the knowledge base has a unique address with format chain|nnn, where chain is the KB name of the record's chain while nnn is a 9-digit decimal number (e.g. pExists|000000675). Record addresses are typically embedded in square brackets when combined with other information.

CONCLUSION AND CONDITION RECORD FIELDS

The conclusion- and condition-fields are terms. Terms cannot be represented directly in an SQL-type database, thus a conversion from/to strings are required each time they are read or stored in the SQL database. Two alternative string-formats can be used, i.e. Pro/3 term-strings or native Visual Prolog term-strings. There is no significant performance differences between the two formats. Visual Prolog term-string conversions are faster, however this off-set by the more compact format used in Pro/3 term-strings (which makes data exchange with the SQL-server faster). 

INTEGRITY ISSUES

The redundancy between the KB main table and the chain-tables, gives potential for integrity problems i.e. when the two representations do not exactly match. Invalid term-strings represent a second class of potential integrity problems. Pro/3 can report and in some instances repair such problems (refer to the KB-menu).