Naming Database Information Entities

Naming Conventions › Naming Database Information Entities

Naming Database Information Entities

Glossary

The creation of a glossary can be an effective means of establishing naming conventions for database information. The glossary can be stored in the dictionary where it is readily available as a reference tool. Tools such as the glossary also aid in the development of consistent site-specific application coding standards.

Example

The following example shows sample entries from one type of glossary. This example shows one way in which a glossary can be defined; each design team must determine the naming conventions that best suit its needs. Note that the word WORD in this example is a user-defined entity defined to the data dictionary, as follows:

The sample entries from this glossary show one way in which naming conventions can be implemented within an installation. In this glossary, the application designers have determined that certain words are always to be abbreviated and others are never to be abbreviated; the majority of words are to be spelled out completely whenever possible. When stored on the data dictionary, the glossary is readily available as a reference guide for programmers and developers.

ADD CLASS NAME IS WORD
CLASS TYPE IS ENTITY.



ADD WORD ABEND           ABBREVIATED NEVER
ADD WORD ABSOLUTE        ABBREVIATED NEVER
ADD WORD ACCEPT          ABBREVIATED NEVER
ADD WORD ACCOUNT         ABBREVIATED SOMETIMES ABBR ACCT
ADD WORD ACCRUAL         ABBREVIATED NEVER
ADD WORD ACCUMULATE      ABBREVIATED SOMETIMES ABBR ACCUM
ADD WORD ACKNOWLEDGE     ABBREVIATED SOMETIMES ABBR ACK
ADD WORD ADMINISTRATION  ABBREVIATED ALWAYS ABBR ADMIN
ADD WORD ADDRESS         ABBREVIATED ALWAYS ABBR ADDR
     .
     .
     .
     .
     .
     .
ADD WORD YIELD           ABBREVIATED SOMETIMES ABBR YLD
ADD WORD YTD             ACRONYM 'YEAR TO DATE'
ADD WORD YY              ABBREVIATED NEVER
ADD WORD ZERO            ABBREVIATED NEVER
ADD WORD ZONE            ABBREVIATED NEVER

Information entities can use the following naming conventions:

Database elements can be established using approved names from the glossary and can be further defined with synonyms. Element names should have a maximum of 25 characters. The following example lists an element and three synonyms:
```
EMPLOYEE-CODE

DB-REC-EMPLOYEE-CODE
MAP-EMPLOYEE-CODE
WORK-EMPLOYEE-CODE
```
Database Records can be composed of approved, usable names (for example, EMPLOYEE). Records can be given greater flexibility with the addition of suffixes. The following example lists employee records with identifying suffixes:
```
EMPLOYEE-0600
EMPLOYEE-2500
EMPLOYEE-6359
```
In CA ADS process source, as well as in COBOL, CA Culprit, and map source, the elements can be referenced by the element name plus the suffix, as follows:
```
EMPLOYEE-CODE-6359
```
Map work records are composed of the map name followed by the suffix -MAP-RECORD, as in the following example:
```
CEMMILIS-MAP-RECORD
```
Elements in the map record utilize the prefix MAP- and the element name, as follows:
```
MAP-OFFICE-CODE
```
If the map needs more than one work record, a number is added to the word MAP, as follows:
```
CEMMILIS-MAP2-RECORD (the second map record)

MAP2-OFFICE CODE (a record element from the second record)
```
Dialog work records are composed of the dialog name followed by the suffix -WORK-RECORD as in the following example:
```
CEMDULIS-WORK-RECORD
```
Elements in the dialog work record utilize the prefix WORK- and the element name, as follows:
```
WORK-OFFICE-CODE
```
If the dialog needs more than one work record, a number is added to the word WORK, as follows:
```
CEMDILIS-WORK2-RECORD (the second dialog work record)

WORK2-OFFICE CODE (a record element from the second record)
```
Set names are established by concatenating an abbreviation of the owner record (a 7-character maximum) with that of the member record (a 6-character maximum), as follows:
```
EMPL-SKILL
```