The TIBCO Patterns Table

Before describing the commands to load and search a TIBCO Patterns database, you must be clear about the logical structure of the database. For historical reasons, throughout the document the term database is used as a synonym for table. But in the following section the term database refers to the entire collection of tables, with the term table referring to a single table in that collection

 

The TIBCO Patterns database is similar to a DBMS. It consists of a set of tables. Each table consists of fielded records, every record in the same table having the same number of fields. Every field in a table has a field name associated with it. In TIBCO Patterns the number of fields, the field names, and the field types are established at the time the table is created, fields or field types cannot be changed after a table is created.

TIBCO Patterns has the following three types of tables:

•

Standard Tables: A standard table is not associated with any other table.

•

Parent Tables: A parent table can be associated with any number of child tables.

•

Child Tables: A child table is always associated with a single parent table. Records in a child table can be linked to records in the associated parent table.

The association of parent and child tables forms a star schema. TIBCO Patterns supports only a star schema, it does not support many to many or multi-level schema.

The table type is established when a table is created and cannot be changed. The association between a child table and a parent table is established when the child table is created and cannot be changed after the table is created. Parent tables and child tables must use the Gram Index Prefilter (GIP) (see The GIP Prefilter - Usage Details).

Every record in a standard or parent table must have a unique key value. The key value is a null-terminated string value. This key value is distinct from the field values for the record. Records in a standard or parent table cannot contain a parent key field.

A child table contains two record types:

•

Standard Records: These are identical to records in a Parent or Standard table.

•

Child Records: These records are linked to a parent record in the associated parent table. They contain a parent key field in addition to the record key field. The parent key field links the child record to its parent record. It contains the record key value of the parent record (in Relational Database Management System (RDBMS) terms it is the foreign key field). The parent key field is distinct from the field values for the record. For child records, the combination of the record key and parent record key must be unique.

Every field in the TIBCO Patterns table has a field type. The field type must be one of the following types.

•

LKT_FLD_TYPE_KEY (2) This is only used in the field types header line of record files. It is the field type for the key field. Currently the key field cannot appear as a data field in the table, so a table field never has a field type of LKT_FLD_TYPE_KEY. See Reading a Database From a File (lkt_dbread) for more on record files.

•

LKT_FLD_TYPE_SRCHTEXT (5) This is the default field type and by far the most commonly used. This holds UTF-8 encoded text data. Fields of this type can be used in both inexact matching and exact matching. Predicates are logical expressions similar to SQL select clauses. See Predicate Expressions for a description of predicates and their use

•

LKT_FLD_TYPE_TEXT (4) These fields contain UTF-8 encoded text data that is NOT searched. You cannot specify this field in inexact matching, but it can be used in predicate tests. Although it is not used in matching it is returned with the record data in searches. This field type is useful for fields that are only used in predicate tests, such as a gender indicator field, or as a means of returning foreign key values with the record that might be useful in linking the data returned by a search to additional data in the permanent data store. Another use is to save extra calls to the permanent data store by storing data which needs to use the results of a search, but is not needed in the search. Using this field type for such fields as opposed to LKT_FLD_TYPE_SRCHTEXT can reduce memory usage and database load times.

•

LKT_FLD_TYPE_INT (6) This field type holds an integer value. The range of valid integers is as defined for the "C" int type on the machine the TIBCO Patterns servers are running on. Note that the value of this field is still transmitted as part of the searchable text data of the LPAR record. This text must be an integer string as recognized by the "C" atoi(3) function. Following two special values are there for this field type and all of the other non-text field types:

—

empty indicates there was no data (field length was zero) in the field.

—

invalid indicates there was data in the field, but it could not be translated to the indicated field type. For example, a string value of apple in a field of type LKT_FLD_TYPE_INT. When records are returned the invalid value for non-text fields is encoded as: *** for int and float fields, ***invalid date*** for date fields and ***invalid date time*** for date time fields.

Fields of this type are primarily useful in predicate expressions. They are more efficient in predicate expressions and use less space to store than keeping the value as a text string.

•

LKT_FLD_TYPE_FLOAT (8) This field type holds a floating point value. The range of valid values is as defined for the "C" double type on the machine the TIBCO Patterns server is running on. As for the integer field type the value is sent as text in the searchable text data of the LPAR record. The format is as recognized by the "C" atof(3) function. It might take on the two special field values: empty and invalid.

•

LKT_FLD_TYPE_DATE (10) This field type holds a date value. That is a month, day, year. The value is transmitted as text. A wide array of formats is recognized including:

—

mm/dd/yyyy

—

mm/dd/yy

—

yyyy/mm/dd

—

yyyy-mm-dd

—

yyyymmdd

—

mm/dd (year default to current year)

—

dd-MON-yyyy

—

dd MON yyyy

—

MON dd, yyyy

—

MON dd (year defaults to current year)

where mm is the month number 1-12, dd is the day of the month 1-31, yyyy is the four-digit year, yy is a two-digit year. Values greater than the current two digit year are assumed to refer to the previous century, otherwise the current century is assumed. MON is a month's name. The following month names are recognized (letter case insensitive): january, jan, february, feb, march, mar, april, apr, might, june, jun, july, jul, august, aug, september, sep, october, oct, november, nov, december, dec.

When returned date values are always encoded in the format: yyyy/mm/dd.

•

LKT_FLD_TYPE_SRCHDATE (11) This is the same as LKT_FLD_TYPE_DATE with the important difference that the data is indexed by the GIP prefilter (see The GIP Prefilter - Usage Details). This improves matching accuracy where a custom date query is used in a search (see Simple Query, the LPAR_INT_CUSTOMSCORE parameter). This also allows queries that consist only of a custom date query.

•

LKT_FLD_TYPE_DATET (12) The Date-Time field type is just like the date field type except it also stores the time. It accepts all the same date formats as date fields but also accepts an appended time value in the form: hh:mm:ss where hh is the 24 hour value (00-23), mm is the minute value 00-59 and ss is the second value (00-59). When returned date-time values are always encoded in the format: yyyy/mm/dd hh:mm:ss.nnn where nnn is milliseconds.

•

LKT_FLD_TYPE_ATTRIBUTES (15) This is the container for the Variable Attributes associated with a record. If a table is to hold Variable Attributes the last field in the field set must be of this type. Only the last field of a field set might have this type. For more information on Variable Attributes and how to use fields of type LKT_FLD_TYPE_ATTRIBUTES see Variable Attributes - Usage Details.

The default field type is LKT_FLD_TYPE_SRCHTEXT.

Associated with every field of type LKT_FLD_TYPE_SRCHTEXT and LKT_FLD_TYPE_ATTRIBUTES is a character map. This defines how characters are mapped before inexact matching is performed. Each field can have a different character map. Character maps do things such as letter case folding, removal of punctuation, translating the various types of white space to a common value, normalizing characters as defined by the Unicode standard and any special character to character mapping desired. For a more complete description of character maps see Character Mapping. There is a default character map that is applied if one has not been specified. The character map associated with a field is established at the time the table is created and cannot be changed.