Chapter 13
Creating Models and Views
Tasks Map for Creating Models and Views
When you want to ...
Use ...
Described in ...
Create a UDM that is a copy of the
ADM
DMDBA screen 40
or, in statement mode,
GENERATE_UDM
“Generating a UDM from the ADM”
section and “UDM Definitions”
Create a system-generated
formatted screen
DMDBA screen 40
Generate screen form
views? Y
or, in statement mode,
GENERATE_UDM
FORM=YES
“Creating Views with Selected
Fields” section and “UDM
Definitions”
DMDBA screen 41
or, in statement
mode,MODEL
“Generating a UDM from the ADM”
section and “UDM Definitions”
Add a model
Formatted screens are available on
UNIX and VMS operating systems
only.
Creating Models and Views  339
When you want to ...
Use ...
Described in ...
Copy selected records from the
ADM to the UDM
DMDBA screen 49 Selection B
or, in statement mode,
COPY RECORD
“Creating Views with Selected
Fields” section and “UDM
Definitions”
Copy field lists from the ADM to
the UDM
DMDBA screen 49
or, in statement mode,
COPY FIELD_LIST
“Creating Field Lists” section and
“UDM Definitions”
Add a view to the UDM
DMDBA screen 44
or, in statement mode,
VIEW
“Creating Views with Selected
Fields” section and “UDM
Definitions”
Add a field to a screen view
DMDBA screen 61
or, in statement mode,
AT
“Creating Views with Selected
Fields” section and “UDM
Definitions”
Add a field to a non-screen view
DMDBA screen 52
or, in statement mode,
FIELD
“Creating Views with Selected
Fields” section and “UDM
Definitions”
Create view with selected field
values
DMDBA screen 44
or, in statement mode,
VIEW
“Creating Views with Selected Field
Values” section and “UDM
Definitions”
Create composite view
DMDBA screen 49
or, in statement mode,
COPY or
DMDBA screen 44
or, in statement mode
VIEW or
DMFORM utility
“Creating Composite Views” section,
Screens, and “UDM Definitions”
DMDBA screen 61 page 4 or, in statement
mode,AT
COMMENT parameter
“Creating Field-Level Online Help”
section, Screens, and “UDM
Definitions”
Create field-level context-sensitive
online help
DMFORM is available on UNIX and
VMS operating systems only.
Available on UNIX and VMS
operating systems only.
340  Creating Models and Views
Because users cannot access database record definitions and field lists from the ADM,
every database must have at least one model in the User Data Model. If your database
has only one model in the User Data Model, you will want it to look exactly like the
Actual Data Model because any ADM objects not included in the UDM are inaccessible
for data loading or updating. You can create such a model by using the
GENERATE_UDM statement.
If you want to create views for use by various user groups, you can use MODEL and
VIEW statements to customize various models and views and COPY statements to create
and modify new views based on existing ones. Topics in this chapter provide details
about creating models and views. For details about each statement or definition that can
comprise the UDM for your database, see “UDM Definitions.”
VMS
If your operating system is VMS and you want to create models for use by FORTRAN or
COBOL programs, see Programming for BASIS Conventional Records, “Defining Views
for Use by COBOL and FORTRAN Programs.”
Generating a UDM from the ADM
The GENERATE_UDM statement is ideal for quickly creating a User Data Model that
matches the Actual Data Model. If you subsequently change the ADM, you must
regenerate the UDM. The UDM does not automatically reflect changes to the ADM.
Models created through GENERATE_UDM let you create screen views in a simple
default format. An FQM User Data Model named FQMA with default screen views can
be generated by this statement:
GENERATE_UDM FQMA,TYPE=FQM,FORM=YES;
The default format follows these layout rules:

If fields had display sequence numbers defined for them in the ADM, fields are
displayed in display sequence number order.

If fields did not have display sequence numbers defined for them in the ADM,
required fields are displayed in alphabetical order followed by optional fields
displayed in alphabetical order.

Multipage views are created when necessary.

Symbols following label names indicate whether a field is required (=) or optional (:)
and whether the box is scrollable (>).
Creating Models and Views  341
The screen view generated by GENERATE_UDM for EMPLOYEE looks like this:
Figure 13-1: Default screen view generated by GENERATE_UDM
Data boxes created by GENERATE_UDM do not exceed one line except when a field is
a text stream, in which case it is given two lines. If the defined maximum size of a field
exceeds the length of the box, the box is automatically scrollable. For numeric fields like
SALARY and COMM, the data boxes exceed the size of the fields. This lets users enter
ranges of values for the FQM USE/SCREEN Match action.
The COPY statement also lets you to create a default screen format for a view. COPY
gives a little more creative scope than GENERATE_UDM. The fields can be arranged
horizontally instead of vertically. You can leave margins at the top and bottom or sides.
You can also create a title for the screen. Finally, you can opt not to leave a blank space
before each box.
UNIX, VMS
It is optional for others. The following statement creates the screen format shown in
Figure 13-2:
342  Creating Models and Views
COPY RECORD EMPLOYEE TO VIEW EMPLOYEE,FORM=YES, +
VERTICAL=NO,BLANK=YES,TITLE='EMPLOYEES';
EMPLOYEES
Dept = _____________ Enum = _____________
Job Title = ______________________________________ Mgrno = ________
Name = ________________________________________________
Sal/Month = ______________________ Com/Month = ___________________
Ext = _____________
Figure 13-2: Default screen view generated by COPY
Note: When you use the COPY RECORD statement to copy the ADM to the UDM,
field lists are not copied.
Table 13-1 indicates what parameter values get carried over to the UDM via the
GENERATE_UDM or COPY statements and whether changes or deletions in the ADM
affect the UDM and SDM. (N/A means does not apply.)
Creating Models and Views  343
Table 13-1: Effects of ADM definitions on UDM and SDM
ADM definition
Copied
to UDM
Changed
in UDM
when
change is
made to
ADM
Deleted in
UDM
when
deleted in
ADM
Affects the
following
definition in
SDM
Assertions
N/A
N/A
N/A
N/A
CODE_LIST
N/A
N/A
N/A
N/A
DOMAIN_CONTROL_SET
N/A
N/A
N/A
N/A
FIELD
Yes
No
Yes
OCCURS
Yes
No
No
TYPE
Yes
No
No
ALIAS
Yes 1
No
No
BLANK_CONTROL
No
No
No
BREAK
No
No
No
CODE_LIST
No
No
No
COMMENT
No
No
No
COMPRESS
No
No
No
CONTEXT_PARSER
No
No
No
CONTEXT_UNIT
No
No
No
DEFAULT_TEST
No
No
No
DISPLAY_SEQUENCE_
NUMBER
No
No
No
344  Creating Models and Views
Index key type
N/A
ADM definition
Copied
to UDM
Changed
in UDM
when
change is
made to
ADM
Deleted in
UDM
when
deleted in
ADM
Affects the
following
definition in
SDM
DOMAIN
No
No
No
EDIT_BLANKS
No
No
No
ENCRYPTION
No
No
No
FORMAT
No
No
No
HIDDEN_STRING_
DELIMITERS
No
No
No
INIT
Yes 2
No
No
LABEL
Yes
No
No
NORMALIZE
No
No
No
OUTPUT_FORMAT
Yes 3
No
No
PARAMETER_SET
N/A
No
No
PATTERN
N/A
No
No
Index key type
PRECISION
Yes
No
No
Index key type
PRIVACY_CODE
No
No
No
PRIVACY_TEST
No
No
No
RAISE_DATA
No
No
No
SCALE
Yes
No
No
Index key type
SEARCH_CONTROL
No
No
No
Index search
control
Creating Models and Views  345
ADM definition
Copied
to UDM
Changed
in UDM
when
change is
made to
ADM
Deleted in
UDM
when
deleted in
ADM
SECTION_FIELD
(not applicable to
Windows)
No
No
No
SET_EXPRESSION
No
No
No
SET_WHEN
No
No
No
SIZE
Yes 4
No
SORT_SIZE
No
No
No
SORT_STOPWORDS
No
No
No
TEXT
No
No
No
THESAURUS_DATA_
CONTROL
No
No
No
TRANSLATE_CODE
No
No
No
UNIQUE
No
No
No
UNITS
No
No
No
USAGE
No
No
No
FIELD_LIST
Yes 5
No
Yes
PARAMETER_SET
N/A
N/A
N/A
RECORD
Yes
No
Yes
346  Creating Models and Views
Affects the
following
definition in
SDM
INDEX
SIZE
INDEX
TYPE
INDEX
TYPE
INDEX
TYPE
ADM definition
Copied
to UDM
Changed
in UDM
when
change is
made to
ADM
Deleted in
UDM
when
deleted in
ADM
SEARCH_CONTROL_SET
N/A
N/A
N/A
THESAURUS_DATA_
CONTROL_SET
N/A
N/A
N/A
WORD_LIST
N/A
N/A
N/A
Affects the
following
definition in
SDM
1
If the model is created with the COPY command, aliases are carried over from the
ADM to the UDM model.
2
If COPY COPY_INITS_TO_DEFAULTS is YES, initial values of ADM fields
having them are copied to UDM forms.
3
The ADM FIELD OUTPUT_FORMAT qualifier /SEC or /SER, if present, is
copied to the UDM AT statement.
4
The ADM FIELD SIZE parameter determines the length of the /Underscore option
in the UDM AT statement.
5 If the model is created with the COPY ALL, COPY ALL FIELD_LISTS, or COPY
FIELD_LIST statement, field lists are carried over from the ADM to the UDM model.
Creating Models and Views  347
Creating Views with Selected Fields
To keep a user group from seeing restricted data, you can create a view that contains
selected fields from the source record. Such a view cannot be used to add new records to
the database, however, unless it contains all of the fields defined as required in the ADM.
The process of creating views with less than all of their source record’s fields is called
projection. Projections are defined in one of two ways, depending on whether they are
for screen views or non-screen views. In each case you must explicitly define each field
you want to appear in the view.
All
For a non-screen view, use the VIEW definition followed by a FIELD definition for each
field you want to include in the view. You can change the name of the view and fields, as
well as other characteristics. The statements that define a non-screen RECEP view look
like this:
USER_DATA_MODELS;
*
MODEL=FQMA,TYPE=FQM,ACCESS=PUBLIC;
*
VIEW=RECEP,SOURCE=EMPLOYEE,+
PRIVILEGES=(GET,MOD,DEL),+
DEFAULT_SEARCH_FIELD=EMP,+
DEFAULT_DISPLAY_FIELD=EXT;
*
FIELD=EMP,SOURCE=NAME,+
OUTPUT_FORMAT=<30/VR2<;
FIELD=JOB,SOURCE=JOB;
FIELD=EXT,SOURCE=TEL;
UNIX, VMS
For a screen view, you must specify the location of each label and data box on the screen
and various display and error-marking enhancements. You can define the view with a
VIEW statement (with the FORM=YES) and AT statements in a DDL UDM definition.
It is much easier, however, to use the DMFORM utility to generate the AT statements.
Using your favorite host system editor, you can create a Form Definition Language (FDL)
file that looks like this:
348  Creating Models and Views
FORM VIEW=RECEP,MODEL=FQMA,MODEL_TYPE=FQM,+
SOURCE=EMPLOYEE
*
START_LAYOUT
RECEPTIONIST
Employee name: -----------------------------Employee job: -----------------------------Extension:
---END_LAYOUT
*
BOX NAME=EMP,SOURCE=NAME,OUTPUT_FORMAT=<30<
BOX NAME=JOB,SOURCE=JOB
BOX NAME=EXT,SOURCE=TEL
Then you can let the DMFORM utility translate the above file into a DDL file of AT
statements. The translated DDL file looks like this:
*-------------USER_DATA_MODEL
*-------------*
MODEL=FQMA, TYPE=FQM;
*
VIEW/REPLACE=RECEP, SOURCE=EMPLOYEE, FORM=YES;
*
AT(3:3,33:44)/Protected/FL, NAME=L01001, +
PUT('RECEPTIONIST'),FDL_INFO='MARKER=UNMARKED, +
DEFAULT=YES';
AT(7:7,2:15)/Protected/FL, NAME=L01002, +
PUT('Employee name:'), +
FDL_INFO='MARKER=UNMARKED,DEFAULT=YES';
AT(7:7,17:46)/Underscore/EReverse, NAME=EMP, +
SOURCE=NAME, OUTPUT_FORMAT=<30<, +
FDL_INFO='MARKER=-,DEFAULT=YES,CONT=+';
AT(9:9,2:14)/Protected/FL, NAME=L01003, +
PUT('Employee job:'), +
FDL_INFO='MARKER=UNMARKED, +
DEFAULT=YES';
AT(9:9,17:46)/Underscore/EReverse, NAME=JOB, +
SOURCE=JOB, +
FDL_INFO='MARKER=-,DEFAULT=YES,CONT=+';
AT(11:11,2:11)/Protected/FL, NAME=L01004, +
PUT('Extension:'), FDL_INFO='MARKER=UNMARKED, +
DEFAULT=YES';
AT(11:11,17:20)/Underscore/EReverse, NAME=EXT, +
SOURCE=TEL, +
FDL_INFO='MARKER=-,DEFAULT=YES,CONT=+';
Note: If you enter the VIEW and AT statements directly in a DDL file, they will not
look quite so complicated as the AT statements generated by DMFORM because
DMFORM stores some information it needs for translation purposes. A typical AT
statement entered directly into the DDL might look like this:
Creating Models and Views  349
AT(11:11,17:20)/U/ER,NAME=EXT,SOURCE=TEL;
Creating Views with Selected Field Values
Another method of creating a view from a source record definition is very much like
searching the database. The view contains only those record occurrences that satisfy a
restriction specified by a WHERE clause.
For example, suppose Department 101 needs to access only the employee records for its
own department. A view that contains only occurrences whose DNO value is 101 would
suit their needs well for purposes of security and convenience. This view is created by
the following VIEW definition:
VIEW=EMPS101, SOURCE=EMPLOYEE, WHERE=(DNO=101);
The data for the COMM, DNO, ENO, JOB, and NAME fields in the EMPS101 view
would look like this:
COMM
$432.00
350  Creating Models and Views
DNO
ENO
JOB
101
101
4552
5962
101
101
101
101
101
101
6107
7192
7350
10003
10037
10043
Secretary
Secretary
Clerk
Clerk
Secretary
Secretary
101
101
101
101
10053
10055
10085
10090
Secretary
Salesman
Manager
Vice-President
Clerk
Manager
NAME
DOE, ABRAHAM
WILLIAMS,
JAMES
PETERS, BRENDA
LYONS, JEANNE
LEWIS, BILL
BODNARUK, ANN
ANGELLO, LUKE
SCHAUER,
RACHEL
TODD, FAY
SARCHIN, TONY
KELLY, CINDY
ROBINSON, JOHN
When a user enters a search command such as
FQM> FIND EMPS101 WHERE JOB = 'Secretary'
the system automatically imposes the restriction WHERE DNO=101 on the EMPLOYEE
data, so the query retrieves only those secretaries who are in Department 101. (Note that
such a restriction is not applied, however, if the user has been authorized with BYPASS
privilege.)
The restriction can be made more complex by adding other restrictions linked by Boolean
operators. For example,
VIEW=MANAGERS101, SOURCE=EMPLOYEE, +
WHERE=(DNO=101 AND +
JOB='Manager','Vice-President');
creates a view that contains only those employees of Department 101 whose JOB field
value is either Manager or Vice-President.
You can combine a restriction and a projection operation to further customize a view.
Assume that the Secretary of Department 101 handles incoming calls for the department.
A non-screen view would look like this:
USER_DATA_MODELS;
*
MODEL=FQMA,TYPE=FQM,ACCESS=PUBLIC;
*
VIEW=RECEP101,SOURCE=EMPLOYEE,+
PRIVILEGES=(GET,MOD,DEL),WHERE=(DNO=101);
*
FIELD=EMP,SOURCE=NAME,OUTPUT_FORMAT=<30/VR2<;
FIELD=JOB,SOURCE=JOB;
FIELD=EXT,SOURCE=TEL;
Notice that the field DNO is not included in the view.
Screen views created in DMFORM can also have restrictions. The FORM VIEW
statement in the FDL file looks like this:
FORM VIEW=RECEP101,MODEL=FQMA,MODEL_TYPE=FQM,+
SOURCE=EMPLOYEE,WHERE=(DNO=101)
If a record definition is defined with one or more “access” fields, the restriction on a view
can use this access field to define the records in the view on the fly. For example,
suppose you want to create a view that allows an employee to see only his own record or
those of his subordinates.
Creating Models and Views  351
If the EMPLOYEE record definition has an ENO field that contains a valid BASIS user
id, then a view called MYEMPS could be created in this way:
VIEW=MYEMPS,SOURCE=EMPLOYEE,+
WHERE=(ENO=$UID OR MGR_NO=$UID);
In another scenario, the EMPLOYEE record definition could contain a field that contains
a privacy code. Assume it is called ACCESS, and contains the values 5, 10, 15, 20 and
25. DNO, ENO, NAME, SALARY, TEL, and ACCESS fields could contain the
following data:
DNO
100
201
301
301
301
301
100
201
301
101
ENO
1001
1823
2312
2458
2843
2930
3395
3724
3912
4552
NAME
DAVIS, JOE
SMITH, JOHN
MILLER, JOHN
MARTIN, PETER
JAMES, JOYCE
BLACK, THOMAS
BROWN, SANDRA
JACKSON, MARY
LEMON, LINDA
DOE, ABRAHAM
SALARY
$8,000.00
$2,000.00
$2,350.00
$1,050.00
$2,000.00
$2,650.00
$1,700.00
$2,700.00
$2,150.00
$1,050.00
TEL
4231
3873
1504
1506
7328
1508
4227
3870
1512
4296
ACCESS
25
10
10
5
10
20
5
20
10
5
A view called SECURE, defined in this way
VIEW=SECURE,SOURCE=EMPLOYEE,+
WHERE=($READACCESS >= ACCESS);
allows the president of the company to see all occurrences if his READACCESS code is
>=25. Managers, if given READACCESS values 20 to 24, can see all occurrences except
that of the President (ACCESS value is 25) and so on.
Creating Composite Views
You can also create composite views, views created by joining fields from two to 12
source record definitions.
Two record definitions can be joined if each has a field, like ENO, for example, that can
contain identical values. These fields, sometimes called join fields, must have the same
domain. A domain determines a pool of acceptable values. To ensure that the fields are
joinable, they ought to be defined by a DOMAIN definition in the Actual Data Model.
352  Creating Models and Views
The EMPLOYEE and DEPENDENT records, for example, can be joined because each
contains a field that contains ENO values. The ENO value is unique in the EMPLOYEE
view, whereas it may well recur in the DEPENDENT view if an employee has several
dependents.
EMPDEPS
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
EMPLOYEE
DAVIS, JOE
DAVIS, JOE
SMITH, JOHN
MILLER, JOHN
MARTIN, PETER
JAMES, JOYCE
BLACK, THOMAS
BROWN, SANDRA
JACKSON, MARY
LEMON, LINDA
DOE, ABRAHAM
JONES, PAUL
JONES, PAUL
JONES, PAUL
JONES, PAUL
ROWE, TIM
1001
1001
1823
2312
2458
2843
2930
3395
3724
3912
4552
4801
4801
4801
4801
5007
1001
1001
DEPENDENT
DAVIS, MARY ...
DAVIS, JAMES...
3724
JACKSON, GREG...
4801
4801
4801
4801
JONES,
JONES,
JONES,
JONES,
SALLY...
PAUL...
MARY...
KEN...
When a user searches the EMPDEPS view for all employees named JONES,
FQM> FIND EMPDEPS WHERE ENAME = 'JONES'*
his result set contains pointers to both EMPLOYEE and DEPENDENT data.
...
...
...
...
JONES,
JONES,
JONES,
JONES,
PAUL
PAUL
PAUL
PAUL
4801
4801
4801
4801
4801
4801
4801
4801
JONES,
JONES,
JONES,
JONES,
SALLY...
PAUL...
MARY...
KEN...
It is just a coincidence that the employee number field is named ENO in each source
record. They could just as well be called EMP_NO in the EMPLOYEE record and
ENUM in the DEPENDENT record.
The join fields do not have to be included as FIELD definitions in the composite view.
Note: If you have two identically named fields in your source records, you will “lose”
one of them if you use the COPY statement to create the view. Thus, if you want to
create joins with the COPY statement, you should name fields uniquely when creating
your ADM (ENAME for EMPLOYEE.NAME and DNAME for DEPENDENT.NAME,
for example).
BASIS supports directed joins and equi-joins in the creation of composite views. The one
you choose depends on the type of result sets your users need to create.
Creating Models and Views  353
Directed Join
The directed join is shown in the following example:
FQM> FIND EMPLOYEE,DEPENDENT WHERE +
EMPLOYEE.ENO DJOIN DEPENDENT.ENO
In FQM commands, instead of DJOIN, you can use the directed join operator, which
looks like this: :=>>. In composite view definitions, however, you must use :=>> to
represent the directed join operator.
The directed join is used whenever you want a composite view to show an owner-member
relationship that includes all “owners.” The EMPLOYEE record definition is the
“owner.” The DEPENDENT record is the “member.” In a directed join all EMPLOYEE
records, whether or not they have corresponding DEPENDENT records, would appear in
the view. (Ideally, the ADM should contain an assertion to prevent the existence of
DEPENDENT occurrences who have no EMPLOYEE counterpart.)
When users search a view based on a directed join, they must put the restriction on a field
in the owner record.
FQM> FIND EMPDEPS WHERE ENAME = 'JONES'*
creates a result set that contains 4 members, whereas
FQM> FIND EMPDEPS WHERE DNAME = 'JONES'*
creates a result set that contains 133 members. The second query retrieves all
EMPLOYEE occurrences, no matter what their last name, and only the dependent
occurrences whose NAME value begins with JONES.
In a directed join, the join field that comes before the operator becomes the owner, i.e.,
the record whose occurrences always appear in the view, whether they have counterparts
in the joined view or not. Thus,
EMPLOYEE.ENO :=>> DEPENDENT.ENO
makes EMPLOYEE the owner, but
DEPENDENT.ENO :=>> EMPLOYEE.ENO
makes DEPENDENT the owner.
354  Creating Models and Views
Equi-Join
The equi-join, in contrast to the directed join, omits any record occurrence that does not
have a counterpart in the joined record. An equi-joined view of EMPLOYEE and
DEPENDENT would look like this:
EMPDEPS
EMPLOYEE
...
...
...
...
...
...
...
DAVIS, JOE
DAVIS, JOE
JACKSON, MARY
JONES, PAUL
JONES, PAUL
JONES, PAUL
JONES, PAUL
DEPENDENT
1001
1001
3724
4801
4801
4801
4801
1001
1001
3724
4801
4801
4801
4801
DAVIS, MARY ...
DAVIS, JAMES...
JACKSON, GREG...
JONES, SALLY...
JONES, PAUL...
JONES, MARY...
JONES, KEN...
Note that only the employees who have dependents are included in this view. Thus, the
user of this EMPDEPS view would not know that records for Abraham Doe or Tim Rowe
exist.
You can always join conventional records to each other, provided they contain fields from
the same domain. You can join a conventional record to a continuous record or a
sectioned record with the proviso that the join field in a sectioned record must be at the
document level. (Sectioned records are not available on Windows.)
The equi-join operator is := (The word JOIN can be used in place of := for equi-joins in
FQM FIND commands, but when you are equi-joining views in DMDBA, you must use
the := operator.)
Except for the different join operators, statements that create directed and equi-joins are
identical.
Defining Joined Views
If a composite view contains all the fields from each source record definition, you can
define it most easily by using a COPY command. Use this command only if the source
records do not have fields with the identical name. If you are defining a composite view
having fields with an identical name, the COPY command creates the join, but you will
“lose” the first occurrence of the field in the view.
COPY (rec1,rec2) TO VIEW view, +
JOIN=({rec1.}field1 :=>> {rec2.}field2),FORM=YES;
Creating Models and Views  355
If your source record definitions have some identical field names, or your composite view
will

be a non-screen view,

contain only certain fields from each source record, or

have a restriction in addition to the join,
then you need to use a VIEW definition to define the join. You also need to supply a
FIELD definition for each field to be included in the view. Below is the definition of a
composite view with a restriction.
VIEW=EMPDEPS,SOURCE=(EMPLOYEE,DEPENDENT, +
JOIN=(EMPLOYEE.ENO :=>> DEPENDENT.ENO),+
WHERE=(EMPLOYEE.DNO=101);
*
FIELD=EENO, SOURCE=EMPLOYEE.ENO;
FIELD=EENAME, SOURCE=EMPLOYEE.NAME;
FIELD=JOB, SOURCE=EMPLOYEE.JOB;
FIELD=DENO, SOURCE=DEPENDENT.ENO;
FIELD=DNAME, SOURCE=DEPENDENT.NAME;
If your source records have some identical field names, or you want your composite view
to

be a screen view,

contain only certain fields from each source record, or

have a restriction in addition to the join,
then you could use the VIEW definition with FORM=YES and AT definitions.
A more attractive alternative lets you define the screen in an FDL file and then translate it
to AT statements using DMFORM. The FDL file defines the JOIN on the FORM VIEW
statement. Then you define a BOX statement for each field included in your layout. The
FORM VIEW statement with a JOIN looks like this:
FORM VIEW=CLI_SCHED,MODEL=FQMA,MODEL_TYPE=FQM,+
SOURCE=(CLIENT,SCHED),+
JOIN=(CLIENT.CONTRACT := SCHED.CONTRACT)
356  Creating Models and Views
Limitations of Composite Views
Although composite views facilitate retrieval and display, they cannot be used to update
the database. If you require users to update data from several source records at once, you
should define a screen view for each source record. Each view should use as few rows as
possible, although it may contain several pages. A user can join several screen views with
the FQM USE/SCREEN command, allowing him to retrieve and update the records
concurrently. The total number of rows of all joined views, however, cannot exceed 20.
For more information, see Screens, “BASIS/FQM Screens.”
You can join a conventional record to a continuous record or to a sectioned record, but
you cannot join non-conventional records. (Sectioned records are not available on
Windows.)
Another limitation on composite views is that the total of non-text-stream characters in
your composite view cannot exceed 16,100. This limitation is true only when the join is
done in the DDL, not on a FIND command.
Customizing Views
In FQM models, most parameters default to the values supplied for the source field in the
ADM definition. You can change several parameters, such as NAME,
OUTPUT_FORMAT, LABEL, and ALIAS, to suit the needs of users. Parameters such
as TYPE, SIZE and OCCURS can never be changed from what they are in the source
record field.
The NAME of the view field and its source record field do not have to be identical. It is
important to choose names that are meaningful to the users of the UDM.
The OUTPUT_FORMAT specifies the display format used by the TYPE command when
it displays a field value. If you do not specify a different format, the
OUTPUT_FORMAT defined for the ADM record field is used. If you did not specify an
OUTPUT_FORMAT in the ADM, a default format is used. Output formats do not affect
the screen display of the field, except for justification. Numeric fields should be leftjustified in screen views, to ensure their visibility on the screen.
You can also specify a different label to be used with the TYPE command display. If you
do not specify a LABEL, the label defined for the source record field is used. If a label
was not specified in the source record field, the name of the field is used.
Creating Models and Views  357
Some users of the same UDM may prefer different names for the field. Using the ALIAS
parameter, you can supply up to four aliases for a view field. These aliases can be used
instead of the field name in FQM FIND and TYPE commands.
A typical view field definition simply names the field and supplies its source:
VIEW=EMPS, SOURCE=EMPLOYEE;
FIELD=EMP,SOURCE=NAME;
FIELD=DEPT,SOURCE=DNO;
An expanded definition could provide an output format, label, and aliases:
VIEW=EMPS, SOURCE=EMPLOYEE,DEFAULT_SEARCH_FIELD=DEPT,+
DEFAULT_DISPLAY_FIELD=NAME;
*
FIELD=EMP,SOURCE=NAME,OUTPUT_FORMAT=<50>,+
LABEL='Employee',ALIAS=(EMPLOYEE,WORKER);
FIELD=DEPT,SOURCE=DNO,OUTPUT_FORMAT=<10<,+
LABEL='Department';
Referencing a Multifield Index
Sometimes you may want to create a multifield index (MFI) that merges all values of two
or more fields to facilitate searching the database. For example, such an index might
merge all values of fields PLACE.OVERVIEW and PLACE.TEXT. You can then
include the index as a field in the view to be able to search directly using the index.
The multifield index is automatically accessed by the Kernel to optimize a search. This
occurs whether or not the multifield index is included as a field in the view.
The following example shows how a multifield index, TOPIC (which is defined in the
Structural Data Model), can be included as a field called TERM in the view PLACE.
VIEW=PLACE,SOURCE=PLACE,DEFAULT_SEARCH_FIELD=TOPIC;
*
FIELD=TERM,SOURCE=TOPIC;
:
:
All the fields in the TOPIC multifield index do not have to be included in the view. For
more information about multifield indexes, see “Indexes.”
Creating Field Lists
Field lists provide an alternative to entering several field names to be searched or
displayed.
358  Creating Models and Views
Suppose that the users of the CLIENT view in the ADMIN model frequently display the
CNAME and ADDR fields in that order. You can create the following field list in the
ADMIN model:
FIELD_LIST=ADDRESS,VIEW=CLIENT, FIELDS=(CNAME, ADDR);
Users who search and display data using the CLIENT view in the ADMIN model can
search both fields at once and display both fields by referencing ADDRESS in their FIND
and TYPE commands.
Note: Because character fields are searched differently than numeric fields are, a field
list to be used in search commands must have fields of the same data type. However,
because display of data is not affected by data types, a field list to be used only in TYPE
commands can contain fields that are not of the same data type.
Field lists, convenient for users, are easy to define and maintain. (They do not have to be
applied.)
You can create a field list in the ADM and then COPY it to one or more models in the
UDM. However, the fields in the UDM must have the same names as they have in the
ADM. If this is not true, you must define the field lists at the UDM level.
Creating Field-Level Online Help
The FQM SHOW/DDB command displays information about records and fields in a
database. For example, the following command shows information about the CLIENT
record.
Note:
Sectioned records are not available on Windows.
FQM> SHOW/DDB CLIENT FULL=YES
Views in the <TOUR.ALL> database.model
PrivView Name
ilege Style Update Form
------------- ----- ------ ----CLIENT
GAMD
Conv
Immed
Y
Index Structure: Indirect
Source Record
------------CLIENT
Creating Models and Views  359
The following command displays information about the ID field in the CLIENT record.
FQM> SHOW/DDB CLIENT.ID FULL=YES COMMENT=YES
Fields in the <DTOUR.ALL> database.model
MFI
-M
Filter -F
Usage/
Index Thes. -T
Field Name Data Type
Type
Virtual-V Occurs
---------- ---------- ----- --------- -----View: CLIENT
ID
System_key Unique
1:1
Precision: 9
Source: CLIENT.ID
Output format: <8<
Section field: No
On sort: Use DM_STOP_WORDS: No Use DM_LEAD_WORDS:
Stop Numbers: No
Record field comment:
System-generated client number
Column
Width
-----8
No
Also, if you are using screen mode, you can display information about a field by moving
the cursor to the field’s data box in FQM USE/SCREEN and pressing the [HELP] key
associated with displaying field-level context-sensitive help. Information about the field
comes from the UDM VIEW definition in the DDB.
Use the COMMENT field in the UDM AT or FIELD definition to add field-level contextsensitive help. Comments are displayed in 78-character lines. The total number of
characters in the comment cannot exceed 4000. For the above example, the definition
contains COMMENT='System-generated client number'
Remember, if you copy the UDM VIEW from the ADM RECORD, values for RECORD
COMMENT and FIELD COMMENT parameters do not get copied to the UDM.
Troubleshooting
When you compile your UDM definition and apply your definition to create system
records in the database, the system checks for errors and displays messages to help you
correct them. Following are some of those messages and suggestions for responding to
them.
360  Creating Models and Views
Upon Compiling the Definition
Message:
*** ERROR ***USER ERROR(27683). The wrong definition is being
used to update a form field. If the COPY statement is being
used, FORM=YES must be specified.
Cause:
A view with the same name already exists, and it is a screen view. You are trying to
modify it by copying a view to it without specifying FORM=YES.
Note: If you want to copy a screen view to a new view (no view with the same name
exists in the User Data Model), you do not need to specify FORM=YES.
Message:
*** ERROR ***USER ERROR(27363). Field must be defined before
it can be named in a field list.
Cause:
In defining a field list for a view, you probably used the name of the source record field
instead of the name of the view field.
Message:
*** ERROR ***
USER ERROR(27364). ADM field must be defined before it can be
referenced as a source field in a view.
Cause:
You probably have the incorrect name for a field supplied on the SOURCE parameter of
the FIELD definition.
Message:
** WARNING **
Form field size is less than the box size.
data truncation.
This could lead to
Creating Models and Views  361
Cause:
When the COPY statement creates default screen views, it allows extra space in boxes for
numeric fields to allow users to search on ranges with the Match action in FQM.
Remember when entering data that the size of the box is slightly more than twice as large
as the precision of the field value.
At Apply Time
Message:
** WARNING **
View field: DESC.WANDERLUST.OVERVIEW
has a maximum size specification which differs from that of its
source - field values may be truncated.
Cause:
A different size was specified for the view field instead of letting the size default to the
size of the source record field. When an existing record is modified and replaced via this
view, only the number of characters defined in the maximum size of the source will be
placed in the database. The rest are lost.
Message:
** WARNING **
The ADD privilege has been removed from view: DESC.WANDERLUST
as it does not contain all the required fields for the source
record.
Cause:
The view is a projection and does not contain all the fields defined as required in the
source record definition. Note that the ADD privilege will not be restored automatically
if you add all the required fields to the definition. To change this, you must change the
VIEW definition using a DDL file or DMDBA screens.
362  Creating Models and Views