RDB/VMS Relational Database Operator DEFINE_INDEX — VMS RDB_3.1A
Creates an index for a relation. An index allows Rdb/VMS direct access to the records in the relation, to avoid sequential searching. You can define a sorted index or a hashed index. A sorted index uses the B-tree method of retrieval. A hashed index uses hash addressing for exact match retrievals. Example RDO> DEFINE INDEX EMP_EMPLOYEE_ID FOR EMPLOYEES cont> DUPLICATES ARE NOT ALLOWED cont> TYPE IS SORTED. cont> EMPLOYEE_ID. cont> END EMP_EMPLOYEE_ID INDEX.
Additional information available:
More
When the DEFINE INDEX statement executes, Rdb/VMS adds the index definition to the physical database. If you have invoked the database with the PATHNAME specification, the definition is also added to the data dictionary. You must execute this statement in a read/write transaction. If you issue this statement when there is no active transaction, Rdb/VMS starts a read/write transaction implicitly. You cannot define a hashed index in a single-file database. If you define a hashed index, you must specify a storage map for it with the index-store-clause. The storage area that you specify must have a MIXED page format. An optional keyword that causes Rdb/VMS to create ascending or descending index segments. If you omit the ASCENDING or DESCENDING keywords, ASCENDING is the default. To sort records in a particular way in the result of a particular query, specify the sort order in the SORTED BY clause. Other users are allowed to be attached to the database when you issue the DEFINE INDEX statement.
Format
DEFINE INDEX name ───┬───────────────────────────────┬─────────┐ └─>
D
E
S
C
R
I
P
T
I
O
N typebox (I)typebox (S) typebox (/)typebox (*) text */ ──┘ │ ┌─────────────────────────────<────────────────────────────────┘ └─> Ftypebox (O)typebox (R) ────> relation-name ───┬──────────>────────────┬───────┐ └─> duplicates-clause ──┘ │ ┌────────────────────────────────<─────────────────────────────┘ └─┬───────────>─────────────┬──────────>───────────────────────┐ └─> index-store-clause ───┘ │ ┌─────────────────────────────────<────────────────────────────┘ └─┬─────────────>───────────────┬───────────────────────────┬──┐ ├─>
T
Y
P
E typebox (I)typebox (S) ──┬───>
H
A
S
H
E
D ───┘ │ │ │ └───>
S
O
R
T
E
D ──> sorted-index-param-list ───┤ │ └──────────────> sorted-index-param-list ─────────────────┘ │ ┌───────────────────────── . <─────────────────────────────────┘ └┬┬> field-name ┬┬───────>─────┬┬─>
E
N
D ─┬────>───┬─>
I
N
D
E
X ─> . │└──────<──────┘├>
A
S
C
E
N
D
I
N
G ─┤│ └> name ─┘ │ └>
D
E
S
C
E
N
D
I
N
G ┘│ └────────────── . <────────────┘
Additional information available:
nametextrelation-namefield-nameduplicates-clause
index-store-clausesorted-index-param
name
The name of the index. You can use this name to refer to the index
in other statements. When choosing a name, follow these rules:
o Use a name that is unique among all index names in the database.
o Use any valid VMS name. However, the name cannot end in a dollar
sign ($) or underscore (_).
o Do not use any Rdb/VMS reserved words (see The VAX Rdb/VMS
Reference Manual appendix for reserved words).
text
A text string that adds a comment to the index definition.
relation-name
The name of the relation that includes the index.
field-name
The name of the field(s) that make up the index. You can create a
multisegment index by naming two or more fields, which are joined to
form the index. All of the fields must be part of the same relation.
Separate multiple field names with periods.
NOTE
If field-name refers to a field defined as VARYING
STRING data type, the size of the field must be less
than or equal to 255.
duplicates-clause
duplicates-clause = ───>
D
U
P
L
I
C
A
T
E
S typebox (A)typebox (R)typebox (E) ──┬───────>─┬──>
A
L
L
O
W
E
D ──> └─>
N
O
T ──┘ A clause specifying whether each value of the index must be unique. If you try to store the same value twice in an indexed field defined as DUPLICATES NOT ALLOWED, Rdb/VMS returns an error message and does not store or modify the record.
index-store-clause
index-store-clause STORE ─┬──>
W
I
T
H
I
N ────> storage-area-name ─────────────>─────────┬─> ┌──────┘ │ │ │ └─────>
U
S
I
N
G ───┬────> field-name ───┬──
W
I
T
H
I
N ───────>─────┐ │ └────────── , ───────┘ │ │ ┌───────────────────────────────<─────────────────────────────┘ │ └─┬─> storage-area-name ──>
W
I
T
H
L
I
M
I
T typebox (O)F ─┬> literal ─┬─ typebox (;) ─┬─┐ │ │ └──── , <───┘ │ │ │ └───────────────────────────<──────────────────────────────┘ │ │ ┌─────────────────────────────<────────────────────────────────┘ │ │ │ └─────────────────────> storage-area-name ───────────>────────────┘ The index-store-clause creates a storage map definition for the index. It allows you to choose which storage area files will be used to store index entries. You can store all index entries for one relation in a single storage area, or you can partition the entries over multiple storage areas.
Additional information available:
field-name
The name of the field that specifies what value will be used as a limit for partitioning the index across multiple storage areas. If the index key is multisegmented, you can include some or all of the fields that are joined to form the index key. Separate multiple field names with commas.
storage-area-name
The name of the storage area you want the index stored in. You must define this storage area with the DEFINE DATABASE statement before you refer to it in the store clause. If the index is a hashed index, the storage area must have a MIXED page format.
WITH_LIMIT_OF
The maximum value for the index key that will reside in the specified storage area. The number of literals in this clause must be the less than or equal to the number of fields in the USING clause. Repeat this clause to partition the index entries among multiple storage areas. When you define a multisegmented index using multiple keys and use the STORE USING...WITH LIMITS clauses, if the values for the first key are all the same, then set the limit for the first key at that value. By doing this, you insure that the value of the second key determines the storage area in which each record will be stored. Note that the last storage area you specify CANNOT have a WITH LIMIT OF clause associated with it.
sorted-index-param
sorted-index-param-list =
────┬────┬──────────────────>──────────────────────┬───┬─────────>
│ ├─>
N
O
D
E
S
I
Z
E ─────> number-bytes ────────┤ │
│ ├─>
P
E
R
C
E
N
T
F
I
L
L ──────> percentage ──────┤ │
│ └─>
U
S
A
G
E ─────────┬─────>
U
P
D
A
T
E ───┬────┘ │
│ └─────>
Q
U
E
R
Y ────┘ │
│ │
└────────────────────<─────────────────────────────┘
Additional information available:
NODE-SIZEPERCENT-FILLDESCENDING
NODE-SIZE
The size of each index node. The number and level of the resulting index nodes depend on this value, the number and size of the index keys, and the value of the PERCENT FILL clause.
PERCENT-FILL
Sets the initial percentage of fullness for each node in the index structure. The valid range is 1 to 100 percent.
USAGE-mode
USAGE UPDATE, the default, sets the percent fullness of each index node at 70 percent. USAGE QUERY sets this value at 100 percent. Supplying the PERCENT FILL and USAGE clause is allowed in the syntax; however, the USAGE option takes precedence over an explicit PERCENT FILL value.
DESCENDING
An optional keyword that causes Rdb/VMS to create descending index segments. To guarantee that rows will be sorted in a particular way in the result of a particular query, specify the sort order in the SORTED BY clause
TYPE_IS
Specifies whether Rdb/VMS creates a B-tree index structure (SORTED), or a hashed index structure (HASHED). If you specify HASHED, you cannot choose options from the sorted-index-param-list. Hashed indexes are effective only for exact match retrievals. Sorted indexes are effective for range retrievals.
Examples
Example 1
The following example creates a simple relation index:
DEFINE INDEX EMP_EMPLOYEE_ID FOR EMPLOYEES
DUPLICATES ARE NOT ALLOWED.
EMPLOYEE_ID.
END EMP_EMPLOYEE_ID INDEX.
This statement names the index and names the field to serve as the
index key.
The clause, DUPLICATES ARE NOT ALLOWED, causes Rdb/VMS to return an
error message if a user attempts to store an identification number
that is already assigned.
Example 2
The following example defines a hashed index, and uses the store
clause to partition the index into different storage areas:
DEFINE INDEX EMPLOYEES_HASH
DESCRIPTION IS /* Hash index for employees */
FOR EMPLOYEES
DUPLICATES ARE NOT ALLOWED
STORE USING EMPLOYEE_ID
WITHIN
EMPIDS_LOW WITH LIMIT OF "00200";
EMPIDS_MID WITH LIMIT OF "00400";
EMPIDS_OVER
TYPE IS HASHED.
EMPLOYEE_ID.
END EMPLOYEES_HASH.
Example 3
The following example creates a multisegment index:
DEFINE INDEX EMP_FULL_NAME FOR EMPLOYEES
DUPLICATES ARE ALLOWED.
LAST_NAME.
FIRST_NAME.
MIDDLE_INITIAL.
END EMP_FULL_NAME INDEX.
This statement names three fields. Rdb/VMS concatenates these three
fields to make the multisegment index key.
Example 4
The following example defines the EMP_EMPLOYEE_ID index and causes
the LAST_NAME segment to be defined in DESCENDING order.
DEFINE INDEX EMP_FULL_NAME FOR EMPLOYEES
LAST_NAME DESCENDING.
FIRST_NAME ASCENDING.
MIDDLE_INITIAL.
END EMP_FULL_NAME INDEX.
Having defined such an index on a particular field does not guarantee
that Rdb/VMS will use that index in a particular query retrieval. To
ensure a particular sort order is returned by a particular query, you
have to specify that order in the RSE:
FOR E IN EMPLOYEES
SORTED BY DESCENDING E.STATUS_CODE,
ASCENDING E.LAST_NAME,
DESCENDING E.EMPLOYEE_ID...
Example 5
The following example defines the JH_EMPLOYEE_ID index and sets each
node size to 350 bytes and the initial fullness of each node to 50
percent:
DEFINE INDEX JH_EMPLOYEE_ID FOR JOB_HISTORY
DUPLICATES ARE ALLOWED
NODE SIZE 350
PERCENT FILL 50.
EMPLOYEE_ID.
END JH_EMPLOYEE_ID INDEX.