Dictionary/204 overview

From m204wiki
Jump to navigation Jump to search

Dictionary/204 and data administration

This section addresses a critical question: Why use Dictionary/204 for data administration?

A few of the many reasons for using Dictionary/204 are noted and explained below:

  • All of the Dictionary/204 components are now included in the RKTools product set, as of RKTools version 7.7.
  • Dictionary/204 provides systemwide information about the entities in your DP environment. Only Dictionary/204 maintains this information.

    For example, without using Dictionary/204, there is no way to determine which files exist in the Model 204 environment. Dictionary/204, however, can provide you with an online or printed list of all files, their maximum number of records, what procedures use those files, and many more of the files' attributes and relationships. Similarly, application programmers can query the dictionary about the particular procedures and files they are using.

    For another example, without using Dictionary/204, there is no way to determine the relationship between files and procedures. Dictionary/204 not only provides you with the names of the procedures on the system, but can report on who updates those procedures, when they were last updated, what files they are stored in, which screens are used by the procedures, and many other attributes and relationships between procedures and other types of entities.

  • Dictionary/204 enhances data integrity, for example, by staging files across sessions, which locks other users out of the "staged" file until all of one user's changes have been executed.
  • Dictionary/204 reduces data redundancy by controlling the definition of database entities and by preventing duplicate entities.
  • Dictionary/204 provides additional control over your database environment by providing a general Dictionary Administration facility that enables you to extend the dictionary to suit your changing needs.
  • Dictionary/204 manages information about views.
  • Dictionary/204 provides a convenient user interface to simplify the tasks of data administration and data maintenance.
  • Dictionary/204 provides menu-driven, fill-in-the-blank screens with PF keys to assist you when documenting your data.
  • Dictionary/204 provides the convenience of active file definition, automatic file sizing, and the convenient setting of subsystem parameters and defaults.

Who uses Dictionary/204?

Dictionary/204 is useful to virtually any member of the data processing community, but particularly to dictionary and data administrators, file managers, system managers, and application programmers.

  • Dictionary administrators determine the types of information maintained in the dictionary and who can access and update that information. If you need to maintain information about reports or programmers, an administrator can add those entity types to the dictionary, providing a template for describing REPORTs and USERs in dictionary entries.
  • Data administrators provide better access to and control of data resources by using Dictionary/204 to help document data resources, to provide data definition standards, and to reduce data redundancy.
  • File managers use Dictionary/204 to define information about Model 204 files and then to create the files and define the fields automatically.
  • System managers use a convenient Dictionary/204 interface to create and maintain subsystem definitions for applications.
  • Application programmers use Dictionary/204 to display information about subsystems and files and to store information about procedures and applications that use Model 204 data.
  • Programmers can also use Dictionary/204 to define and modify views of the data for the design and testing of application prototypes.
  • Any Dictionary/204 user can submit ad hoc queries, using the Dictionary Reports facility, to examine information about reports, files, and other database entities, as well as information about their attributes and relationships.

Dictionary/204 facilities

Dictionary/204 provides five facilities for managing information about your data processing environment, as well as three facilities that manage the entities used by Rocket Software products other than Model 204.

In addition to maintaining data about Model 204 entities, Dictionary/204 also manages information about the IIC products and the VSAM interface to Model 204. The names of the Dictionary/204 facilities are shown in the following figure, on the main menu.

The remainder of this section discusses each facility in brief. The current Dictionary/204 release number is displayed at the top right.

Dictionary/204 main menu

Note: Your menu might differ from this one, if you have not been defined as a user of all Dictionary/204 facilities, or if your site has not installed Access/204. (Options 6 and 7 on this screen are available only if their corresponding products are installed.)

Furthermore, since Dictionary/204 became part of RKTools in version 7.7 of that product, you might be accessing the Dictionary/204 facilities through the RKTools main menu or the RKWeb browser interface.

Dictionary administration

The dictionary administrator's responsibilities are described fully in the Dictionary/204 administration topic. These responsibilities include defining the information to be maintained in the dictionary, establishing security and user privileges for Dictionary/204 accounts, adding user-written reports, and maintaining Dictionary/204 facilities. These tasks can be accomplished by using the Dictionary Administration facility.

The type of information that is maintained in the dictionary is controlled by the entity type definitions. By using this facility, the dictionary administrator can expand these definitions to include additional attributes and relationships for the standard entity types.

Furthermore, the administrator can define new entity types to be added to the dictionary. The dictionary administrator provides the templates for the dictionary entries, determining which attributes and relationships apply to the various types of entities.

The other capabilities of the Dictionary Administration facility are described in Dictionary/204 administration.

Documentation and view definition

The Documentation facility is an interface for adding descriptive information to all dictionary entries. The Documentation facility also enables users to add new attributes and relationships to all entries.

This facility also defines entries for entity types that do not have a special defining interface, such as views.

Dictionary Reports

Dictionary/204 provides an online interface for querying and reporting on the entries in the dictionary. The reports can include all the attributes and relationships for a given entry or entity type, or a list of all the entries for a given type of entity -- all screens, all files, and so on. Reports can select entries based on name, entity type, relationship to a specified entry, or specific keywords.

File Management

The File Management facility actively defines Model 204 files. Users can specify the file's attributes and relationships using a convenient interface and can create the physical file definition automatically. File Management provides automatic file sizing and many other time-saving features.

If you have Model 204 physical files that are not defined in the dictionary, the DDGEN utility generates dictionary file and field entries from the physical file. The DDGEN utility is documented in DDGEN and DDGENSET utilities.

Subsystem Management

Dictionary/204 also maintains Model 204 application subsystem definitions. Subsystem Management enables the system manager to define a set of related files and procedures, including the data, procedures, and users associated with that subsystem. This interface maintains information in the Model 204 control file and in the dictionary.

The Subsystem Management interface can be invoked from the Dictionary/204 main menu. System manager privileges are required to use the Subsystem Management facility.

Dictionary/204 terminology

In the Dictionary/204 topics, the term "Dictionary/204" refers to the collection of facilities that are used to perform data administration tasks. Dictionary/204 is a companion product to Model 204. The term "dictionary" (in lowercase) refers to a Model 204 database that contains information about files, fields, procedures, reports, users, and other types of entities in your database environment. Entities can also be thought of as database "objects" in your data processing environment. Entities can be of different types; FILE, FIELD, PROCEDURE, REPORT, and USER are only some of the possible types.

Dictionary/204 is installed with a set of standard entity types. These are defined in Dictionary/204 entity type definitions and in Defining view entries.

Each entity in the environment is defined by an entry in the dictionary. The entry defines the entity in terms of its attributes (characteristics) and relationships. Each dictionary entry contains a complete description of a particular entity and its relationships to other entities. Relationships between entities are reflected in references between entries that correspond to the entities. System relationships (or references) and attributes are those controlled or used by Dictionary/204 facilities; nonsystem relationships and attributes comprise dictionary information supplied by dictionary users but not controlled or used by Dictionary/204 facilities.

See Types of information in Dictionary/204 for further discussion of these concepts. Also, see Entities, entity types, and dictionary entries, which illustrates these distinct levels of information.

By convention, direct reference to particular entity types (FILE, FIELD, and so on), to attributes (NAME, NUMBER OF RECORDS), and the relationships (STORED IN) appear in uppercase throughout the Dictionary/204 topics. When referred to in a generic sense, these terms appear in lowercase. Also, particular file names (PAYROLL), field names (AGE), and so on are in uppercase.

Note: Entries are dictionary definitions or descriptions of the entities and exist only in the dictionary. Entities, however, are "objects" in your data processing environment. The terms relationships and references, while not precisely synonymous, are virtually interchangeable.

Types of information in Dictionary/204

Dictionary/204 maintains standard definitions of such things as data, user accounts, and programs in a Model 204 environment. These definitions are maintained in dictionary entries with one entry for every named entity in the environment.

The basic dictionary terminology is defined in Dictionary/204 terminology, which refers to the following elements of the dictionary:

  • Entries and entity types
  • Attributes
  • Relationships
  • System and nonsystem data (attributes and relationships)

The sections that follow discuss these basic elements.

Dictionary entries

You can define a dictionary entry for each entity in your data processing environment, regardless of what type of entity it is. If you like, picture the Model 204 dictionary as similar to a printed and bound desktop dictionary. Like the Model 204 dictionary, these entries correspond to real-world entities, but they are not identical with them. They are rather a storehouse of information about the world.

In many respects, the Model 204 dictionary is more dynamic than a Webster's English language dictionary. It stores not only information about the characteristics (attributes) of entities, but also data about their relationships to one another. Your desktop dictionary, for example, contains entries that describe DOG, CAT, and MOUSE, but it does not tell you that a dog CHASES a cat, or that a cat CATCHES a mouse. But the Model 204 dictionary also defines all the relevant relationships between entities.

Secondly, the dictionary data can be queried in numerous ways, not simply alphabetically by object. You can obtain reports based on keywords, type of entity, relationships, and attributes.

To continue the metaphor of the desktop dictionary, the Model 204 dictionary is unique because it contains any number of blank pages on which you can define your own entities as the need arises. In addition to retaining information about files, views, procedures, and other standard entities, you can maintain entries about reports, terminals at your installation, departments, and so on. The dictionary is open-ended (or extensible). You can also modify definitions to suit your needs.

Entities and entity types

Numerous types of entities might be useful in a data processing environment. Entities are classified by type to standardize the definitions of those entities. For example, all FILE type entities have a specific set of attributes that represent all the things you want to know about the files: NAME, NUMBER OF RECORDS, and many other characteristics. Entities of the type FILE also have a standard set of relationships to other entities (FIELDS, PROCEDURES, and so on) that need to be documented in the dictionary.

Entities, entity types, and dictionary entries illustrates two important points about entities, entity types, and entries in the dictionary:

  • A one-to-one correspondence exists between entries in the dictionary and entities.
  • Information (attributes and relationships) maintained in the dictionary entry is determined by the type of entity involved: FILEs have a predefined set of attributes and relationships, as do PROCEDURES, REPORTs, and all other types of entities. (Model 204 provides the entry template for standard types of entities; the dictionary administrator sets up the template for other types of entities.)

In this example, the dictionary data maintained on FILEs and PROCEDUREs is preset by Model 204 in an entry template, but the information on REPORTs (except for some attributes supplied by the system itself) is set up by the dictionary administrator. The dictionary administrator decides what attributes and relationships the REPORT entity type has.

Entities, entity types, and dictionary entries

The purpose of an entity type is to ensure a standard set of defining attributes and relationships for all dictionary entries of a particular sort. Entries also can be thought of as occurrences of an entity type. For example, Model 204 might contain entries (occurrences of the entity type FILE) with names such as VEHICLES, CLAIMS, and PERSONNL. Each of these FILE entries in the dictionary share the same definition template: the FILE type template.

The following figure illustrates this perspective on entries and entity types. It shows the existence of relationships between entity types and particular entries.

Another perspective on entity types and entries

An entry is uniquely identified by its entity type and name. Thus, no Model 204 FILEs, PROCEDUREs, FIELDs, and so on, can have the same name. Naming conventions and the uniqueness of entries describes how meaningful names are selected without violating the naming restrictions.

The Model 204 dictionary has standard, predefined entity types, which are defined by standard sets of attributes and relationships.

The entity types are listed below. The complete definitions can be found in Dictionary/204 entity type definitions, except for the VIEW type definitions, which are found in Defining view entries.

Entity types
ACCOUNT IMAGE ID
COBOL FIELD GROUP PC DRIVE
COBOL RECORD PC VOLUME
COBOL VIEW PROCEDURE
COBOL VIEW FIELD RECORD
DEVELOPER DEFAULTS STAGED FIELD
ENTITY TYPE STAGED FIELD GROUP
FACILITY STAGED FILE
FIELD STAGED RECORD
FIELD GROUP SUBSYSTEM
FILE VIEW
GROUP VSAMT CONTROLS
IMAGE BLOCK

Extensibility

The extensibility of the dictionary provides the following capabilities:

  • The dictionary administrator can add new entity types to the dictionary, providing a template for the definition of the new type of entity. (See Data administration scenario.) After the administrator has provided the entry template, it is up to the users of the new entity type to name and define the particular entries of that type.
  • The dictionary administrator can modify the predefined entry templates. But this does not include the deletion of system-controlled attributes and relationships used by Model 204 and other Rocket Software products.

Introducing attributes

An attribute is a property or characteristic of an entity type. Attributes specify characteristics of an entity type that apply only to that entry. For example, the NAME of a PROCEDURE applies only to that PROCEDURE, not to any other entry.

While an attribute belongs to an entity type, the value of the attribute is a characteristic of an entry. For example, NAME and NUMBER OF RECORDS are attributes of the entity type FILE, whereas the name PERSONNL and "5000" are characteristics of a particular file (for example, a PERSONNL file that has 5000 records).

The following attributes are properties of every entity type, and values are required for them. These attributes are also managed automatically by the system:

compact. ENTITY.LI CREATE DATE LAST UPDATED.LI UPDATED-BY NAME.mnote /MML0001E/List structure error

The following attributes also are properties of every entity type, but values for them are not required, nor are they managed automatically by the system. (They are managed by Dictionary/204 users through the Documentation facility.)

compact. SHORT DESCRIPTION .LI DESCRIPTION KEYWORD.LI ALIAS

See Dictionary/204 entity type definitions for a list of the attributes defined for each entity type, except for VIEW types, which are defined in Defining view entries.

Relationships

Relationships indicate how one entity type is related to another type, or how individual entries (occurrences of the entity types) are related. For example, there is a relationship between a particular file and the fields in that file (the FILE entity type is related to the FIELD entity type). Similarly, there are relationships between a particular subsystem and the procedures that are part of that subsystem (that is, between SUBSYSTEM and PROCEDURE).

Dictionary/204 recognizes the following types of relationships:

Relationship Meaning
Named Unidirectional relationship between two entries
Cross-reference Unnamed, bidirectional relationship between two entries
Relationship path Unnamed and indirect relationship between two or more entries derived from their relationship to other entries

Named relationships

A named relationship exists when a unidirectional relationship between two entity types is specified. For example, the named relationship STORED IN between a procedure and a file expresses the fact that the procedure is stored in that file. The USES relationship states that a procedure uses (reads or writes) the file.

These relationships are thought of as unidirectional, because when the procedure is stored in the file, a converse relationship of the same name would not make sense.

To allude to the earlier dictionary entry example, DOG can be defined as related to CAT by the named relationship CHASES. The relationship is diagrammed in the following figure.

A sample named relationship


Once the relationship is defined for the entity types DOG and CAT, this relationship can be defined for all entries of this type:

ROVER chases TABBY

LASSIE chases FLUFF

Cross-reference relationships

A cross-reference relationship exists when two entity types are related to one another in a mutual, unspecified way. For example, a cross-reference between a procedure and a file simply means that the file and the procedure are associated in some way. The procedure might be stored in the file, it might read the file, or it might update the file. The cross-reference states only that the file and procedure are related without specifying the nature of the relationship.

A cross-reference of this type might be used to find all the procedures that are related to a file in order to change or delete the file.

These relationships are bidirectional, because if a file is cross-referenced to a procedure, the procedure is cross-referenced to the file automatically.

Suppose that you define an entity type of DOG OWNER for the previous hypothetical example. It is useful to cross-reference DOG and DOG OWNER, so that you can document that ROVER is associated with MR. JONES and that LASSIE is associated with TIMMY. Establishing this cross-reference would be useful in the event that one of the dogs is picked up by an entry of the type DOG CATCHER.

The diagram now includes three types of relationships, as shown in the following figure.

Three types of relationships

Path relationships

A path relationship defines a relationship between two entity types that is derived from cross-references or named relationships. There can be a maximum of eight entity types in the path. You can define path relationships between any pair in the path, regardless of the direction of the relationships. Path relationships are nondirectional.

It makes sense to define certain paths, but not all paths. In the previous example, there is no need for a path between DOG CATCHER and CAT, although a path relationship could be defined. However, it is useful to define a path relationship between DOG CATCHER and DOG OWNER in case either LASSIE or ROVER is taken to the pound. You could then determine which DOG OWNERS ought to be called by the DOG CATCHER by following the path from DOG CATCHER through the DOG to the DOG OWNER.

See Path maintenance for a more detailed explanation of paths.

Modes of updating system and nonsystem data

Values for dictionary entries are entered in the following ways:

  • Automatically through the Dictionary/204 system
  • Using special product interfaces and facilities that verify the system-controlled data for consistency and integrity
  • Using the Documentation facility (adding nonsystem data)

The following attributes have values that are supplied automatically by Dictionary/204 (once an entry has been created):

  • ENTITY
  • NAME
  • CREATE DATE
  • LAST UPDATED
  • UPDATED-BY

Nonsystem data added through the Documentation facility can have any value; these values are not verified for consistency and integrity.

Facilities and standard entity types

When using a Dictionary/204 facility, it is important to know which entity type the facility controls and uses. The following table shows the entity types that are used by each facility. In some cases, the facility defines and controls entries of that entity type; in other cases, it simply references entries of the entity type for the necessary dictionary data, but does not define them.

Facilities and the entity types they use
Facility Entity types
Dictionary Administration ACCOUNT, ENTITY TYPE, FACILITY, VSAMT CONTROLS
Dictionary Reports All entity types
Documentation Adds: user-defined entity types

VIEW

Updates: all entity types
File Management FIELD, FIELD GROUP, FILE, RECORD
Subsystem Management FILE, GROUP, PROCEDURE, SUBSYSTEM
VSAM View Management COBOL FIELD GROUP, COBOL RECORD, COBOL VIEW, COBOL VIEW FIELD, COBOL RECORD, FIELD, FILE, IMAGE BLOCK, IMAGE ID, STAGED FIELD, STAGED FILE, STAGED RECORDS

The following table provides a list of entity types and shows which facility or facilities can define entries of that type. If the defining facility is not installed, you can use the Documentation facility to maintain entries of that type.

Entity types and the facilities that define them
Entity type Active data defined by...
ACCOUNT Dictionary Administration
ENTITY TYPE Dictionary Administration
FACILITY Dictionary Administration
FIELD File Management
FIELD GROUP File Management
FILE File Management
GROUP File Management
RECORD File Management
STAGED FIELD File Management
STAGED FIELD GROUP File Management
STAGED FILE File Management
STAGED RECORD File Management
SUBSYSTEM Subsystem Management
VIEW Documentation
VSAMT CONTROLS Dictionary Administration
User-defined entity types Documentation

For information concerning the use and operation of Dictionary/204 facilities, see the other Dictionary/204 topics.

Data administration scenario

This section examines how the dictionary entries function in a hypothetical application. For this example, suppose that a large travel agency is using Model 204 to manage personnel and customer information.

Entity types

The following entity types are among those maintained by the company's data processing department.

Entity type Description
FILE

The travel agency database includes standard customer, payroll, and financial files, as well as reference files that describe various vacation packages such as cruises, camps, tours, and safaris. Each of these files is defined by a corresponding dictionary entry.

FIELD A file consists of a series of data elements called fields. Fields include separate entries for name, address, phone number, flight number, and so on.
REPORT The travel agency regularly produces reports containing information retrieved from the database. Some sample reports might be Customer Summary, Travel Management Summary, and Cruise Inventory. Each of these printed or online reports is described in a dictionary entry. First, however, the administrator must add the REPORT entity type to the dictionary and specify its attributes and relationships. This is accomplished through the Documentation facility. Dictionary/204 users can then add the specific reports that are needed by the company.
USER Travel agency reports are prepared for a variety of end users who have different requirements. Some examples of users might be the payroll department, travel agent, or comptroller. USERs can define user classes or individual users. These various users are defined in a dictionary entry of the entity type USER, which must be added to the dictionary by the dictionary administrator.
PROCEDURE A number of standard Model 204 SOUL procedures have been established to manipulate data and to generate reports. Each of these stored requests, called a procedure, is defined by a dictionary entry.
ACCOUNT The dictionary administrator defines each programmer as an ACCOUNT. Programmers at the agency are responsible for developing and maintaining procedures. Each programmer is described in a dictionary entry, but only after the administrator has added the entity type to the dictionary.

FILE, FIELD, ACCOUNT, and PROCEDURE entity types have standard definitions (see Dictionary/204 entity type definitions). The dictionary administrator can add attributes and relationships to these definitions. REPORT and USER must be added by the dictionary administrator, who sets up the definition templates for entries based on the kinds of information the data processing department wants to maintain about those entities. Once these entity types have been added to the dictionary, users can define particular reports and programmers.

Attributes

The administrator determines the basic attributes for each entity type. Examples of attributes for nonstandard entity types are.

Entity Type Attributes
REPORT REPORT TITLE

REPORT TYPE
FREQUENCY
AVERAGE LENGTH
PAPER STOCK
NUMBER OF COPIES

SECURITY CODE
USER
DEPARTMENT

SECURITY LEVEL
POSITION
PHONE

SUPERVISOR

In addition to the attributes selected by the dictionary administrator, Dictionary/204 automatically includes the following attributes in the definition:

NAME ENTITY TYPE CREATE DATE LAST UPDATED UPDATED-BY SHORT DESCRIPTION DESCRIPTION KEYWORD ALIAS

Relationships

The dictionary administrator also determines which entity types are related to other types (explicitly as well as through a path) and the type of relationship and its name (in the case of named relationships).

The dictionary administrator adds these entity definitions by filling in a series of Dictionary/204 screens in an interactive online session.

After the dictionary administrator has defined all the dictionary entities and relationships, the responsibility for filling the dictionary with occurrences of the new entity types rests with the Dictionary/204 users.

As a user, suppose that you want to add a particular REPORT entry. You are prompted by Dictionary/204 to fill in values for the attributes that describe the report. Dictionary/204 also gives you the opportunity to enter additional occurrences of attributes. For example, you might want to add a second REPORT TYPE or a second ROUTING for the report.

Dictionary/204 then prompts you to specify the entries that are related to the REPORT that you have defined. Dictionary/204 displays the USER and FILE prompt, because the dictionary administrator previously indicated that the REPORT entity was related to the USER and FILE entities. You can then specify which users can read the report, as well as the file from which the report will be generated.

When all the specifications for the entry have been supplied, the entry is added to the dictionary. These entries can later be changed, deleted, or displayed.

The Dictionary/204 user might then add entries for the files related to this report, for example, the CRUISE84 file. The relationships to entries for entity type FIELD contained in this file are then added, as well as other required and optional characteristics describing this entry. When the entries for the entity type FIELD are added, the Dictionary/204 generates the definitions used to create the Model 204 file CRUISE84.

Defining relationships

When you define the relationships for an entity type in the dictionary, you can specify on the Add Entity Type References screen that certain entries are directly related to each other. (Remember, relationships can also be thought of as "references" between entries.) For example, both cross-referenced and named relationships can be established for the following pairs of entries:

Entity Type Pair Example
ACCOUNT <-- PROCEDURE ADBJ <-- CRUSERPT
PROCEDURE --> FILE CRUSERPT --> CRUISE84
FILE <--> REPORT CRUISE84 <--> CRUISE SUMMARY
REPORT <-- USER CRUISE SUMMARY <-- TRAVEL AGENT SUPERVISOR

Once the administrator has defined a relationship between entity types, Dictionary/204 prompts users to specify particular relationships when they define entries.

For example, when you add an entry to the dictionary to describe a USER, you are asked to specify the particular REPORTs that the USER reads. When you add a particular REPORT, the associated USERs and FILEs are specified. When you add a particular FILE, the associated REPORTs and PROCEDUREs are specified.

As defined here, these relationships also comprise the following path:

ACCOUNT PROCEDURE FILE REPORT USER

Thus, it is possible to determine which entries along the path are related, even if no direct relationship has been explicitly defined between two entries. For example, you can ask the dictionary which files are related to a particular account, or which reports are generated by a particular procedure. The Dictionary Reports facility allows you to ask the dictionary which file is related to the account ADBJ. The report yields CRUISE84. Or, you can ask which report is related to the procedure CRUSERPT. The dictionary report yields CRUISE SUMMARY.

Entity type relationships in the data administration scenario

The following figures diagram the defined relationships among the entries.

Entity Types

Particular Entries

See also

Retrieved from "https://m204wiki.rocketsoftware.com/index.php?title=Dictionary/204_overview&oldid=117020"