A database schema is defined in an ascii text file
that is commonly called the Database Definition.
By convention, the file extension of a Database Defenintion file is .dbd.
The syntax rules for a Database Definition file are: . At least one space between words . One statement per line . No periods at the end of any line . Blank lines, indentations, and extra spacing are allowed . Upper or lower case allowed; that is, DBDs are case insensitive . The @ sign indicates that everything after it is a comment, all text after an @ sign is ignored by the DBD compile process. |
The Database Definition Language is comprised of 10 Database Definition Statement types.
Aside from blank lines and comment lines, the first statement of a
Database Definition is always the DATA BASE NAME Statement.
In addition, a Database Definition must contain at least one TABLE DEFINITION Statement and one DATA DEFINITION Statement.
All other Database Definition Statements are optional. And their placement is discretionary; except that they must follow the DATA BASE NAME Statement, and they must be outside the range of a TABLE DEFINITION Statement. However, the following convention is recommended for placement of Database Definition Statements:
|
Syntax: DATA BASE NAME [IS] <data-base-name> Description: This establishes the internal name of the database. All Application Interfaces (AIs) refer to this name in order to establish their connection. When you compile the DBD, the output files that are created employ the first 48 characters of this name plus a 3-character extension. The DATA BASE NAME Statement is required; and it must be the first statement in the Database Definition. |
Syntax: TD <tablename> <nnnn> RECORDS [{TEMPORARY | TEMP}] [GROW [NNNNN]] [BUFFn] Where: BUFFn is the optional page size: BUFF4 - 4K page [default] BUFF8 - 8K page BUFF16 - 16K page BUFF32 - 32K page BUFF64 - 64K page TD <tablename> [{TEMPORARY | TEMP}] is interpreted as: TD <tablename> 5000 RECORDS [{TEMPORARY | TEMP}] GROW Description: Table Definitions provide the data picture of each data record type in the database. Each Table Definition begins with the TABLE DECLARATION Statement, and is followed by one or more DATA DECLARATION Statements. A Database Definition must have at least one TABLE DEFINITION Statement. Each TABLE DEFINITION Statement must have at least one DATA DEFINITION Statement. The optional key word TEMPORARY causes the specified table not to be included in the permanent data base. Rather, a TEMPORARY table is instantiated as an empty table each time the data base is opened. There is a separate instance of a TEMPORARY table for each instance of the open data base. Any data that is written to a TEMPORARY table is lost when the data base instance is closed. A TEMPORARY table cannot have a keyed field. The optional key word GROW allows the specified table to grow beyond its initial size. When the Data Base is initially created, storage in the .ddd file is pre-allocated only for the first nnnn records of the GROWable table. But the .ddd file will grow as additional records are written, up to NNNN records. If the NNNN parameter is omitted, the table can grow to the maximum possible size of 2,147,479,552. The GROW modifier can also be used with the TEMPORARY modifier. In this case, the table is initially created with <nnnn> records; but it can grow unconditionally to 2,147,479,552 records. [In addition, there can be multiple TEMP GROW tables; and each can grow to the maximum size.] The maximum number of records in a table is 2,147,479,552 (0x7FFFF000). For tables without the GROW attribute the aggregate maximum number of records is also 2,147,479,552 (0x7FFFF000). For tables with the GROW attribute there is no aggregate limit. |
Syntax: [:<level>] <fieldname> <data-type> [{[KEY [<key-modifiers>]] | <field-modifiers>}] Description: Each DATA DECLARATION Statement specifies the name of a field, the field type, the field size, and whether the field is keyed. <fieldname> Declaration
<data-type> Declaration
<Key> Declaration
<Key-modifiers> Definition
<Field-modifiers> Definition
<level> Declaration
|
Syntax: SUPPRESS GI Description: Without this clause the DBD compile process generates a General Interface (GI) that provides access to the entire database. The name of this GI is the same as the first 8 characters of the database name (with no extension). When you are generating your own Application Interfaces (AIs) you have no particular need for a GI. The use of the SUPPRESS GI clause prevents the generation of a GI at compile time, and thus restricts access only to those who know the whereabouts of an AI. |
Syntax: DBOPTION <option> Description: The purpose of the DBOPTION clause is to allow the database developer to specify tuning or construction options. The available options are: DbOption Bnn @ DBD; Specify default page size; nn = {4, 8, 16, 32, 64}; default is 4; DbOption Gnnn @ DBD; Allow nnn records Grow Room in DRL; this allows tables to be added @ at the end of the dbd with DBDCOMP/S if the table has the GROW attribute, @ only the fixed record count counts against nnn; @ the available GROWROOM can be queried with VERIFY DBD GROWROOM; DbOption I @ DBD; Use integral .ttt & .lll files DbOption L @ DBD; Set "No Cache" flag DbOption O @ DBD; Do not Pack on DBD COMP/R DbOption T @ DBD; Use separate .ttt & .lll files DbOption U @ DBD; Use large Update Strand DbOption W @ DBD; Suppress record numbers in recordThe U option affects the size of an internal structure that we call the "update strand." For databases larger than a half million records that do more than trivial updates, it is advantageous to use the DbOption U option. The W option eliminates reduntant system housekeeping data from the data record, reducing the size of each data record by 8 bytes. The result of this option is that deleted records are not purged on DBD COMP/R; |
Syntax: FILE DATA [ON] <drive-path> FILE TREE [ON] <drive-path> FILE LIST [ON] <drive-path> FILE TTT <key-name> [ON] <drive-path> FILE LLL <key-name> [ON] <drive-path> FILE RTL <key-name> [ON] <drive-path> FILE RTB <key-name> [ON] <drive-path> Description: If you have more than one disk storage drive you can use the FILE clause to get drive separation of the three most often accessed files of a database. Drive separation reduces wear and tear on disk drives, and can improve overall efficiency. When we say drive separation we really mean head separation, if you have two drive letters mapped to the same physical drive it does you no good to use the FILE clause. The three largest and most often accessed files of a Thunderbolt database are the data space, the tree space, and the list space. The data space is going to be on the same drive with the DBD, but you can use the FILE clause to specify different drives for the tree and/or list space, or both if you have three drives. When you specify the drive and folder for the tree or list (or both) files, you can use the UNC (Universal Naming Convention). Thus you avoid problems if your installation is the type that has different drive letter mappings for different workstations. |
Syntax: UNIQUE <keyname> <number> UNIQUE <keyname> SZ(tablename) UNIQUE <keyname> SZ(tablename)*factor Description: The UNIQUE clause is used to tune tree structure space, preventing wasted space. |
Syntax: UNIQUERTL <keyname> <RTL-Block-Count> [<RTL-Block-Size> [<Local-List-Size>]]
Description: |
Syntax: UNIQUERTB <keyname> <RTB-Block-Count> [<RTB-Threshhold> [<RTB-List>]]
Description: |
Syntax: TOKENMAP [SENSITIVE] <Table-Name> <Schema-ColName> <Table-ColName> <Column-ColName> <Mapped-Table-ColName> <Mapped-Column-ColName>
Description:
|
Copyright © 2019 , WhamTech, Inc. All rights reserved. This
document is provided for information purposes only and the contents hereof are
subject to change without notice. Names may be
trademarks of their respective owners.