|
|
White Paper:
InterPlex
Enterprise Gateway
--
Page 6
pages: 1,
2, 3,
4, 5,
6, 7, 8,
9
Previous
page Next page
InterPlex
SQL Views
Views
are established within the InterPlex SQL mainframe product.
A row is made up of various fields (columns) from DMS, RDMS or
Processor Common Input/Output System (PCIOS) records.
During the InterPlex SQL DMS schema/subschema and file definition
analysis, all areas, sets, records, and field names are stored and default
paths are generated. A
default path consists of a record to record via set relationship.
The ability to add a custom path is available.
A custom path might consist of a DMS record, which contains a field
that is the calc key to another DMS record.
When
the DMS field names are processed, during the schema analysis function,
data name are not generated. There
is another step necessary to mass generate the data names inclusion into
the InterPlex internal database. InterPlex
administration data names generation will automatically create SQL
compliant names by simply taking the field names as they are listed in the
DMS schema/subschema and replacing the dashes with underscores.
There is a function to add alias names to these existing generated
names, such as customer_number
might also be referenced as cust_nbr.
When
defining views, analysis of the data and the links required to generate a
row should be studied. A
working knowledge of the DMS database structures is helpful during the
analysis process. The same
concerns used when building a native DMS application should be applied
during the generation of InterPlex SQL views.
Below is a list of possible concerns that might be used during the
analysis phase of view generation.
-
Do all the target records have a logical relationship and have
links to access them?
-
If the view must access the primary or starting record by
Next-of-Area, is the DMS area of a reasonable size and does not contain
many different record types?
-
If using an upward link, that is a fetch owner of set, is there
another way to get at the target record?
-
If a view contains an Owner record and subsequent member records,
will every owner have at least one member?
When
defining views to be used by the InterPlex Enterprise gateway it is
important for these views to return useful rows of data.
If the target view contains two or more DMS records, there must be
one of each record for a row to be satisfied.
That is, an Owner record to Member record view must have at least
one member record before a row is returned.
If the owner has no members in the target set, a row of data will
not be returned for this owner. Likewise,
if the target set has multiple records for an owner, multiple rows will be
returned during an access on this view.
Public
Versus Private Views
When
a view is built using the InterPlex administration tool, the
public/private flag can be set. This
flag allows or disallows public access to the view’s data.
A private view is only available to the user who builds it whereas
a public view is accessible by all users within the same Data
Access Group. A Data
Access Group or DAG
is a set of DMS records that have been defined for utilization by one or
more users. A user may belong
to one or more DAGs
but the effect is that data access is restricted to records defined within
the group(s) he is assigned. Another
point concerning public versus private views is that each view’s name
must be unique within all schemas. With
this restriction, a private view named sales,
owned by user1, cannot be
accessed by user2. An additional view would be needed for user2 if he needs to access the data in the sales view. The
additional view would have to be duplicated and given a unique name.
Therefore, the use of DAGs to control user
access will simplify the setup and maintenance of your user catalogs.
Query
Usage
The
InterPlex Enterprise gateway product supports queries and updates to the
Unisys DMS database and other mainframe file structures from various
DataServer’s tools and applications.
Queries made to a DMS database through InterPlex SQL use standard
SQL SELECT and FETCH
commands. Using a WHERE clause item that is
a DMS calc or indexed sequential key will greatly improve a query’s
performance.
Update
Usage
Update
capability, which consists of SQL Update, Delete, and Insert, is supported
transparently through the InterPlex gateway.
This transparency will allow applications to be written without
regard to data location. A
few observations need to be made concerning the update capability. The administrator or programmer must have previously
generated the update procedure and mapped with the subschema specific main
program. The subschema
specific main program will need to be registered within the Distributed
Data Process (DDP) software on the Unisys mainframe.
As
with any database, Unisys DMS locks the target data during updates and
this data remains locked until a commit or rollback is received.
There are other nuances concerning a DMS database update.
The simplest suggestion is to treat the transparent updates,
flowing from DataServer databases, as you would an application on the
Unisys mainframe. The same
cares and concerns put forth in a TIP or BATCH DMS program should be
observed here.
|
UNISYS Integrators