Computers: Universe: Data Fields

Each record in the dictionary file represents a field in the corresponding data file. For instance, the first field of the CUSTOMER.INVOICES file contains customer names. A record called CUSTOMER.NAME should therefore be created on the dictionary to represent it.

The easiest way to enter dictionary records is with the editor. All dictionary records have the same format:

>ED DICT CUSTOMER.INVOICES CUSTOMER.NAME
New record.

----: I
0001= D The customer's trading name
0002= 1
0003= (Enter a space and press RETURN)
0004= Customer Name
0005= 15T
0006= S
0007= (Press RETURN)
Bottom at line 7.
----: FI
"CUSTOMER.NAME" filed in file "CUSTOMER.INVOICES".

Note that the keyword DICT was used before the file name CUSTOMER.INVOICES to refer to the dictionary of the file. In general, where a command takes the form command filename ... you can use command DICT filename... to apply the command to the dictionary of a file.

The first field of the dictionary record is much like the first field of a VOC record, being made up of a one or two letter type, followed by an optional description. In this case, the type is D, meaning 'data' (you will encounter other types in the following sections), and the description is The customer's trading name. This last is there solely as internal documentation, to provide information to anyone who might edit the dictionary record in the future.

The second field (of a D type - other types use their second fields differently) of the dictionary record carries the field number of each data record which carries the CUSTOMER.NAME. In this case, as field 1 of every CUSTOMER.INVOICES record carries the customer's name, the value here is 1.

The third field contains a 'conversion specification'. This is because the form in which some information is typically stored by UniVerse differs from the form in which it is displayed. For instance, dates are stored as the number of days passed since 1967. The way in which a field should be converted before display can be coded. For dates, for instance, the conversion code of D DMY[2,A3,4] would store 1 and display 01 JAN 1968. Text strings like customer names, though, are generally displayed exactly as stored, and so the conversion specification can be left blank. The space entered above is ignored.

The fourth field is the title which will appear at the head of the column of customer names in an enquiry.

The fifth field combines the width of the column displayed in the enquiry with the 'justification' of the column. For instance, to display a right-justified column 10 characters wide, you would enter a format of 10R. To allow 30 characters, left justified but breaking on complete words where possible, you would enter 30T (T standing for 'text' justification). Please bear in mind that this does not set a limit on the capacity of the field. Even if a dictionary record defines a field as having a format of 10R, it may contain 11 characters (or 111). They will simply 'wrap around' the column in an enquiry.

Finally, the sixth field contains either an S or an M. As was explained during our discussion of the UniVerse's data structures (see The UniVerse Paradigm above), fields can be further divided into values, and values into subvalues. If a field is designed to hold more than one piece of information in this way, it is multi-valued and must carry an M in this field of its dictionary record. Otherwise, it is single-valued and carries an S.

In the same way, set up the following records in DICT CUSTOMER.INVOICES

Now try the command:

>LIST CUSTOMER.INVOICES CUSTOMER.NAME PRODUCT UNIT.PRICE QUANTITY

LIST CUSTOMER.INVOICES CUSTOMER.NAME PRODUCT UNIT.PRICE QUANTITY 16:41:00  08-06
-99  PAGE 1
CUSTOMER.INVOICES  Customer Name..  Product.............  Unit Price  Quantity..

0001               ACME Widgets     Castellated Grommets       10.38        2000
                   Limited
0002               Universal        Revolving Stud Pins       427.00           7
                   Thingies Inc.
0003               Imperial         Galvanised Retention       38.00         104
                   Exporters plc    Sprockets
>

The LIST command consulted the dictionary of CUSTOMER.INVOICES to determine the meaning of the words CUSTOMER.NAME, PRODUCT, UNIT.PRICE and QUANTITY, and was therefore able to extract the appropriate data from each record and format it appropriately. Note, for instance, that the customer and product names are being wrapped on word boundaries as a result of their ...T formats, and that the unit price is showing two decimal places even where decimal places were not included as part of the data, thanks to its MD20P conversion. (This conversion code, and others, will be explained in the section on UniVerse Basic).

Note that LIST displays the record keys automatically, using the file name as the column header, and extending the width of the column to accomodate this name. While it's useful to show the keys, this is not the best format to choose.

It is determined by the dictionary record @ID. This dictionary record is created automatically when you create a file, as whatever other fields you may decide on, UniVerse knows that you must have a key to each record. You should never delete the @ID dictionary record, because UniVerse can become confused if it does not find it: but you can edit it to control the way in which the key is shown in enquiries. The table below shows both the 'default' @ID record as it was created by UniVerse, and a modified version which would show the keys more suitably. Use the editor to modify the @ID appropriately.

Rerunning the command we tried earlier now gives the following results:

LIST CUSTOMER.INVOICES CUSTOMER.NAME PRODUCT UNIT.PRICE QUANTITY 17:41:33  08-06
-99  PAGE 1
InvNum    Customer Name..    Product.............    Unit Price    Quantity..

  0001    ACME Widgets       Castellated Grommets         10.38          2000
          Limited
  0002    Universal          Revolving Stud Pins         427.00             7
          Thingies Inc.
  0003    Imperial           Galvanised Retention         38.00           104
          Exporters plc      Sprockets

3 records listed.
>

As you can see, the invoice number now has a more meaningful column header, and a column width more appropriate to its length.

You may have noticed a similarity between the use of dictionaries and the use of the VOC file. VOC records also begin with a line stating their type and providing a description. They are also used to interpret the meaning of words supplied on a command line. In fact, in some versions of PICK, the VOC file is called the Master Dictionary. The similarity applies to another feature. As you know, you can define a synonym for any word by copying its VOC record under a different key. Similarly, you can set up a synonym for any field name by copying its dictionary record. Making a copy of the CUSTOMER.NAME record called CLIENT.NAME allows you to use these words synonymously in RetrieVe enquiries.

However, this can be more than just a convenient way of making synonyms. As you can see above, the customer name is rather cramped. It has a narrow column width designed to allow all four columns to be shown across the screen at once. But what if you wanted to omit the other columns and show the customer's name in a wider column? You could of course edit the CUSTOMER.NAME dictionary record: but that would mean changing it before each enquiry, which would become cumbersome. A better approach is to create a synonym called, say WIDE.CUSTOMER.NAME, and change its format to 50T. Try this, and then enter the command:

>LIST CUSTOMER.INVOICES WIDE.CUSTOMER.NAME

LIST CUSTOMER.INVOICES WIDE.CUSTOMER.NAME 17:53:56  08-06-99  PAGE 1
InvNum    Customer Name.....................................

  0001    ACME Widgets Limited
  0002    Universal Thingies Inc.
  0003    Imperial Exporters plc

3 records listed.
>

As you can see, each customer name fits comfortably within the new column size, and the original CUSTOMER.NAME field definition is still available.

In fact, though, this is not the method I would recommend to achieve this effect. The problem is that it creates two field names for a single field, and this can be a development and maintenance headache. In much the same way that it is good practice to have a single F type pointer to each file (see File Pointers), it is good practice to have a single D type pointer for each data field. You can still set up synonyms similar to the ones described here, though, using I types, which are discussed in the next section.