- 2.5.7 Data Name Standards
- 126.96.36.199 Purpose
- 188.8.131.52 Responsibilities
- 184.108.40.206 Objective
- 220.127.116.11.1 General
- 18.104.22.168 Procedures for Developing a Name
Part 2. Information Technology
Chapter 5. Systems Development
Section 7. Data Name Standards
This document provides a uniform method to be followed when naming:
data elements and groups of data elements and,
the items related to data, i.e., record, file, data base, module, program, form, report, system, and user names.
This document provides a standard to use when creating data names. Standardized data names facilitate data sharing, data consistency, and communication between organizational areas in the Service. Standardized data names also assist the data administration effort, by making it possible to eliminate data redundancies and inconsistencies.
The scope of this document is Servicewide. It applies to all Service personnel, as well as contractors, who create, gather, store, manipulate, report and, in general, use Service data in carrying out their functions. It also applies to all personnel and contractors who document and maintain Service data on a data dictionary.
Adherence to these standards if required for any mainframe application exclusive of applications written in AM They are also to be used for any small-scale ADP application as defined in the Small-Scale Applications Handbook (IRM 2553.23). While the use of standards is desirable from the standpoint of ease of systems maintenance in development of standalone microcomputer-based systems, it provides the greatest benefit in the large mainframe and networked mini/microcomputer environments where the potential for data sharing is greater.
These standards must be used in the analysis and design stages of systems development. They must also be followed in the programming stage of systems development for all COBOL applications and, to the extent possible , for programs in other languages. Users of languages which cannot conform to these standards must cross-reference nonstandard names with standard names on the Service-wide Data Dictionary or the Mini/Micro Data Dictionary. (Refer to Exhibit 300-1 for definitions .) This cross-referenced list will provide input to overall IRS strategic data planning in the future.
At a minimum, data names must be documented in a manual dictionary. However, use of an automated data dictionary is recommended.
The Paperwork Reduction Act of 1980 highlighted the fact that data is a resource and has value and associated cost. It emphasized the need to make efficient use of the resource and minimize the cost to the Federal Government of collecting, maintaining, using and disseminating information. This philosophy became known as Information Resources Management (IRM).
This philosophy surfaced at the IRS when, in November 1981, the Assistant Commissioner (Computer Services) initiated action directing an effort be undertaken to standardize data element names and codes across the Service. The concept of data as a valuable organizational resource has been further defined by Treasury Directive 81-04 formerly known as 81-02.A (Responsibilities of a Data Administrator.)
All Service personnel and contractors within the scope of this document are responsible for using these naming standards. This responsibility is specified in the ADP Software Standards and Guidelines under the Development Phase (IRM 2548.3:(1)) and in the Small-Scale Applications Handbook (IRM 2553.23).
The Office of Standards and Data Administration is responsible for the central data administration function in the Service. This includes assisting in the implementation and use of these naming standards; approving names and abbreviations created using this standard; reviewing and documenting acceptable acronyms ; encouraging the use of data dictionaries by Service personnel; and promoting data sharing and consistency by documentation of standard data names in the Servicewide Data Dictionary and the Mini/Micro Data Dictionary.
Application for a standards waiver should follow the procedure in IRM 2.5.1, Systems Development.
The objective of using these naming standards is to develop a name which is unique and self-explanatory. A reader should gain some knowledge of the entity from the name alone.
Only alphabetic (A-Z), numeric (0-9), and special characters (e.g. hyphen, colon, underscore ) which are appropriate to the language being used are allowed in a name. No blanks are permitted.
The first character of the data name must be alphabetic (A-Z).
Data names may not start with a verb.
The maximum length of a name (including special characters) is 30 characters.
Each name must be unique.
Each name must be clear and accurate to reflect a condensed version of the data description.
Abbreviate only when it is necessary to reduce a name to 30 characters or less. Effective with this transmittal, names in COBOL applications will not contain abbreviations for words of four characters or less.
Each name must contain a class word. A class word specifies the nature of the data and must be the right-most word in the name (e.g., TAXPAYER-BIRTH-DATE). Exhibit 300-2 contains the list of preferred class words. Other class words must be submitted to the Central Data Administrator for approval when the data cannot be identified by examples from Exhibit 300-2.
This section comprises the procedures for developing a name.
Write a sentence or a paragraph containing a full but concise description of the entity (user, system, run, module, report, form, file, record, group, data element, schema, subschema , area, set) explaining what it is. This description should be retained as a part of the data dictionary entry.
A close relationship must exist between a data name and its description; one should reflect the other. A general or broad description requires a general name.
Do not use the source or destination of the entity. Avoid: This entry comes from Run 123 and goes into Run 456.
Do not specify the processing done on the entity. Avoid: This amount is the result of price times quantity.
Attach system/function names or form numbers to data items only when the description limits its use to a particular function. For example: EXAMINATION-CASE-START-DATE and COLLECTION-CASE-START-DATE could be used with system names attached because their descriptions would be basically different.
Eliminate those words in the description which are not essential to the meaning. Note that these words are deleted only for the purpose of deriving a name; the full description remains intact in the data dictionary entry.
Unnecessary words usually include articles, conjunctions, prepositions, and some modifiers. However, in some cases these types of words may be necessary to the meaning.
Arrange the remaining words by placing the class word as the last word on the right of the name, and reorganizing the other words into a meaningful order. Some change in the form of a word may be necessary; that is, a verb may be changed to a noun or adjective (example: collect to collection or collected).
In some instances, a good description (as suggested above) will not result in an adequate name. If, after reworking the description, the resultant name is still unacceptable, then persons involved in name development must use their knowledge of the subject data in selecting key words for the name.
Always use common IRS acronyms (required acronyms) for groups of words in the name (e.g., IMF for Individual Master File, DLN for Document Locator Number). A list of these acronyms is included as part of Exhibit 300-3 and Exhibit 300-4. (Note: Those items which are marked by two pound signs are required acronyms and must always be used.)
Separate the remaining words and required acronyms with the appropriate special character.
The list of required acronyms is maintained on the Servicewide Data Dictionary as values under the data element ACRONYMS. The list is also maintained on the Mini/Micro Data Dictionary. (See note above for both lists.)
) Count the remaining alphanumeric characters and special characters. Substitute accepted acronyms or abbreviations found on the lists of acronyms (Exhibit 300-3 and Exhibit 300-4) or approved abbreviations (Exhibit 300-5 and Exhibit 300-6) until the name has 30 or fewer characters (including approved special characters).
When only the singular form of a word is given as the abbreviation's meaning, the plural of the word may be assumed acceptable and vice versa, if that form will make the name more meaningful. Similarly, tenses different from those listed in the meaning may be assumed acceptable without an addition to the approved abbreviation list. For example:
On list: COLM Column INCR Increase
May assume: COLMSColumns INCRD Increased
The list of accepted acronyms is maintained as values under the data element ACRONYMS on the Servicewide Data Dictionary. (Note: Accepted acronyms are those items which are not indicated by two pound signs and are used only to reduce a name to 30 characters or less.) Additionally, this lists is maintained on the Mini/Micro Data Dictionary and the note above applies.
The list of approved abbreviations is on the Servicewide Data Dictionary as values under the data element APPROVED-ABBREVIATIONS. A list of abbreviations related to small-scale applications is maintained on the Mini/Micro Data Dictionary.
Exhibit 300-7 contains four examples of developing valid names by following the steps described above which are:
Write a description of the entity.
Eliminate the nonessential words from the description.
Arrange the remaining words in a meaningful order, with the class word to the right.
Always substitute required acronyms.
Insert the appropriate special character between the remaining words and required acronyms.
Substitute approved abbreviations or accepted acronyms if the name is over 30 characters.
) If there is no appropriate abbreviation on the approved list, use the following steps to develop an abbreviation.
Eliminate vowels right to left to make the most meaningful abbreviation. Never delete the first letter of the word.
Drop nonessential consonants. Use phonetic sounds to help select only those letters needed to understand the abbreviated word(s). For example: Block BLK Opening OPNG
Use a shorter form of the word when the word is lengthy and the shorter form can be understood. For example: Function FUNC Geographical GEOG
Do not abbreviate a word so as to cause confusion in meaning. For example: Use: AUTH for Authority Not: AUTHOR for Authority