NBSIR 80-2115

PROSPECTUS FOR DATA DICTIONARY

SYSTEM STANDARD

Application Systems Division

Center for Programming Science and Technology

Institute for Computer Sciences and Technology

U S. Department of Commerce

National Bureau of Standards

Washington, DC 20234

September 1980

U.S. DEPARTMENT OF COMMERCE, Philip M. Klutznick, Secretary

Luther H. Hodges, Jr., Deputy Secretary

Jordan J. Baruch, Assistant Secretary for Productivity. Technology, and Innovation

NATIONAL BUREAU OF STANDARDS. Ernest Ambler, Director

TABLE OF CONTENTS

Page

1. PURPOSE OF THIS REPORT 1

2. DATA DICTIONARY SYSTEM 1

2.1 General Functions of the DDS 2

2.2 Types of Entity Descriptions 3

2.3 Types of DDS 6

2.3.1 Passive and Active DDS 6

2.3.2 Stand-alone and Dependent DDS 7 2.4 Roles of the DDS 7 2.4.1 Data Resource Management 7

2.4.2 Data Standardization 7

2.4.3 System Development and Documentation 8

2.4.4 Conversion 8

2.5 Potential Benefits 9

3. OBJECTIVES AND SCOPE OF THE DDS STANDARD 9

4. REQUIREMENTS ISSUES AND PROJECT APPROACH 11

REFERENCES 14

«

-ill-
PREFACE

This report provides Federal computer personnel with

information about Data Dictionary Systems, their use and

benefits, and initial planning for a Federal standard in

order to solicit technical discussions and input from

Federal personnel and system producers regarding appropriate

content for a Federal standard. Comments and suggestions

should be addressed to me at the address below. The conclusions or assertions in this report are subject to change.

In particular, objectives and schedules are dependent on

funds not yet appropriated. The contributions of Belkis

Leong-Hong, John Berg, and Patricia Konig to this report are

appreciated

.

Dennis W. Fife, Chief

Application Systems Division

National Bureau of Standards

Washington, D. C. 20234

-iv-
PROSPECTUS FOR

DATA DICTIONARY SYSTEM STANDARD

Application Systems Division

A Data Dictionary System is an automated information system to assist in organization-wide

data management, without restriction to computer

data. This report describes NBS efforts to

develop a Federal Data Dictionary System standard.

It discusses the scope and purpose of the standard, its intended uses, general issues being investigated, and the basic project approach.

Key words: Computer program; data dictionary

system; data inventory; data management; data

standards; database; database management system;

documentation; software.

1. PURPOSE OF THIS REPORT

A Data Dictionary System (DDS) is a computer software

system that provides for recording, storing, and processing

information about data and its usage. Numerous commercial

and user-developed DDS packages are available and increasingly are being used [1,2,3]. The National Bureau of Standards has initiated a project to develop a Federal standard

Data Dictionary System. This report explains the purpose and

various functions of a DDS, its envisioned benefits, and the

approach for creating a proposed standard. The report is

primarily intended to initiate discussions with Federal

users about detailed requirements and with potential vendors

about implementing the standard software.

2. DATA DICTIONARY SYSTEM

The Federal government, like all large organizations,

collects a large quantity of data for its operations and decision making. Data collection and handling are expensive,

and poor quality can Impede government services and decision

making. For example, problems exist when:

- 1 -
* data is collected redundantly by different departments, or data is collected anew instead of finding

and using equivalent existing data;

* data is collected or recorded inconsistently; for

example, different measuring units or codes are applied when similar data is collected by two different groups

The Data Dictionary System (DDS), when consistently and conscientiously used by data management and computing personnel, will reduce problems such as the above.

2.1 General Functions of the DDS

The DDS is itself an information system about all of an

organization's significant data and data processing entities. Pertinent entities Include individual data items or

elements (such as client name or parts on hand), data groups

(such as client's dependents), data collection forms,

records, files, databases, programs, systems, reports, user

procedures, and users. The content of the DDS, often called

"metadata" but usually called simply the "data dictionary",

consists of formal descriptions of the pertinent entities.

An individual DDS entry, hereafter called an entity description, therefore contains important information about a named

entity (for example, the data element CLIENT-NAME), but does

not contain actual instances of the entity (that is, all existing client names). Rather, the actual instances exist

outside of the DDS; as examples, they are data values stored

in a database or on a magnetic tape located in a vault.

A DDS may be used effectively to describe data elements

and other entities that do not involve computer processing,

as well as to describe computer applications. A fully

developed data dictionary for an organization or project is

a catalog of its data resources, but also is a computer database that fully documents its data collection, processing,

handling, and dissemination activities. A DDS is therefore

an automated documentation and information retrieval system

to support organization-wide data management, without limitation to computer data. A DDS may have more substantial

capabilities as an active component of computer applications, as will be described later in this section.

The term "data dictionary", which stems from the early

applications that simply catalogued and defined data elements, is no longer completely appropriate and descriptive,

but nevertheless continues to be widely used and will be retained in the Federal standard effort until a better term is

evident

- 2 -
To summarize, a DDS provides capability for:

1. Specifying the type of an entity, such as a form, a data element, or a computer file.

2. Uniquely naming an entity and describing it in appropriate terms, such as the range of values of a data element or a narrative description of its meaning .

3. Specifying the flow and the storage locations of

data within the organization or within the computer

installation

.

4. Specifying associations and relationships among the

data entities; for example, appearance on the same

form, or derivation of one entity from another.

5. Specifying and producing reports about the data dictionary content, such as a listing of all data elements or a cross-reference listing of all entitles.

2.2 Types of Entity Descriptions

A DDS provides a prescribed set of different entity

types; each type has a prescribed set of attributes. These

attributes describe an entity of the given type. An entity

description is entered into the data dictionary through the

DDS as one or more text lines that name the entity and its

type, and give values for the applicable attributes. The

entity name, type designation, and other attributes must

follow the prescribed conventions of the DDS. For example,

an entity name may be from one to 30 alphanumeric characters

only; the type designation must be one of the established

codes, such as EL for data element or SD for source document. For some entity types, an available attribute may be

a text field, say up to 150 characters, for entering a narrative description pertinent to each entity.

Figures lA and IB present two examples of actual entity

descriptions, coded in the language of two different commercial DOS's, DATAMANAGER and DATA DICTIONARY. Figure 2 is a very brief summary to illustrate available DOS's, see

[1,2,3] for more information.

- 3 -
FIGURE lA

Example of a Data Element Entity Description

(Coded Using DATAMANAGER)

ADD CUSTOMER-NUMBER

ITEM

ENTERED-AS CHAR 7 CONTENTS FORMAT "ANNNNNN”

HELD-AS ALPHANUMERIC

REPORTED-AS PICTURE 'A9(6)'

DESCRIPTION

'CUSTOMER NUMBER UNIQUELY IDENTIFIES A CUSTOMER ACCOUNT'

CATALOGUE

'SALES', 'BILLINGS', ' ACCOUNTS-RECEI VABLE

ALIAS ASSEMBLER 'CUSNO'

NOTE

'NUMBER ORIGINATES IN SALES DEPARTMENT'

'SOURCE DOCUMENT NUMBER IS FM2152'

'USED BY SALES, BILLINGS, ACCOUNTS RECEIVABLE SYSTEMS'

'USED AS KEY IN THE CUSTOMER NAME AND ADDRESS FILE'

FIGURE IB

Example of a Source Document Entity Description

(Coded Using CINCOM's DATA DICTIONARY)

SF-171 SD ADD NAME=AP-FORM DESC*'APPLIC FORM FOR FED EMPL',

ELEMENT=APPL-SYS , FED-REG-SYS, APPLICANT-REC

USER=PERSONNEL

-A-
FIGURE 2

A Sample of Currently Available Systems

DDS

CONTACT NAME

AND ADDRESS

HARDWARE i MAIN

1 MEMORY

1 COST

1 (*)=GSA Sche

1

1 DATA CATALOGUE IBM 360/370 1 100-125K 1 $12. 9K-37K(*)

Synergetics Corp 1 1 De Angelo Dr

.

1 Bedford, MA 01730 UNIVAC-llOO 1 25-35K 1 $21 . 9K-33K(*)

617-275-0250 1

1 DARCOM IBM 360/65 1 150K 1 Negotiated

US Army Materiel 1 Development & 1 Readiness Cmd. 1 Cmd'r. Autom. Logistid 1 Mgt» Activities 1 Attn. DRXAL-DED 1 P.O. Box 1578 1 St. Louis, MO 1 314-268-6001 1 __ 1 IDD IBM 360/370 1 IDMS DB 1 $15K(*)

CULLINANE CORP IBM 4330/4340 1 20 William St. IBM 303x 1 stand-alone : 1 Wellesley, MA 02181 1 350K vlrtuall

617-237-6600 1 __ 1 PRIDE/Logik IBM 360/370 i 12 8K 1 M. Bryce & Assoc 1 $27K

1248 Springfield Pk DEC-10, DEC-20

|

1 Cincinnati, OH 45215 B-3700, 4800 1 513-761-8400 H6000 1 ICL-1903 1 CDC-CYBER 1 __ 1 RAS/ STADES H 6000 i 29K 1 Negotiated

US Navy Data Autom. IBM 360/370 1 Cmd. (NAVDAC) 1 NARDAC UNIVAC-llOO 1 Bldg. 196 1 Washington Navy Yard 1 Washington DC 20374 1 —

202-433-3571 1 — 1

- 5 -
A DDS could also provide for the user to define additional types of entities and their attributes, and then subsequently to enter entity descriptions according to these

user defined types.

The conventions and attributes of data entity descriptions are especially important in assessing a DDS. Data

descriptions are essential to almost all computer programs.

For example, a COBOL application program requires a DATA

DIVISION. A database management system (DBMS) requires a description of its database using its Data Definition

Language (DDL). Central storage of data descriptions under

a DDS can improve data standardization, integrity, and control considerably, if the DDS can compile and output selected descriptions with the form and content required by other

software. Many DDS packages are specifically designed for

this purpose, so their data descriptions do incorporate the

necessary information at least for one software system such

as a given DBMS or for a category of software such as COBOL

programs. However, the syntax of the DDS language usually

differs substantially from that of the DBMS DDL or the COBOL

DATA DIVISION.

2.3 Types of DDS

There are two principal ways to classify the wide range

of capabilities and implementations found in present DDS.

One way is according to the DDS capability to provide data

entity descriptions to other software. In this respect, the

DDS could be called passive or active. Another classification is according to the dependence of the DDS on other

software for implementing its functions. Here it could be a stand-alone DDS or a dependent one.

2.3.1 Passive and Active DDS. A passive DDS is an information tool that is only accessed by personnel, to enter or

retrieve entity descriptions. With a passive DDS, descriptions of the same data will exist concurrently in other

software such as COBOL programs. Changes in the DDS content

do not automatically produce corresponding changes in the

other data descriptions, and vice versa. Thus a passive DDS

does not control the organization's data descriptions

directly, although it would assist manual procedures to do

so .

An active DDS, through software interfaces and computer

operating procedures, provides the ONLY source for data

descriptions to other processing components such as compilers, assemblers, and DBMS's. The active DDS assists in

the enforcement of data standards and usage throughout the

organization and its computer applications. For example, an

- 6 -
active DDS could produce the DATA DIVISION for any COBOL

program from dictionary data and parameters supplied in the

job stream. The text would be collated with the program

source text and passed to the COBOL compiler. Here the DDS

is said to be active with respect to the COBOL compiler.

2.3.2 Stand-alone and Dependent DDS. A stand-alone DDS is

self-contained; that is, its functions are performed without

relying on any other general purpose software such as a DBMS. A stand-alone DDS may be passive or active. Most of

the current stand-alone implementations have available the

features that make them active when invoked by a user.

A dependent DDS is specifically tailored to operate in

conjunction with another general purpose software system,

usually a DBMS. It requires the DBMS facilities to perform

DDS functions. In some cases, the dependent DDS is implemented as an application under a DBMS, wholly using DBMS facilities. Such an intimate connection does not necessarily

mean that a dependent DDS is automatically active with

respect to the DBMS. However, it may be easier to invoke facilities that would make the DDS active.

2.4 Roles of the DDS

As the central repository of current and accurate information about an organization's data and its handling, a DDS can assist a wide range of management and technical

tasks. The following identifies several application areas

where use of a DDS is appropriate.

2.4.1 Data Resource Management . Because of the impact of

government-directed data collection on the private sector

and also the increasing costs of labor-intensive data handling, government agencies are striving to reduce redundant

data collection and to improve the utility of existing data

resources. A well-developed DDS provides high visibility to

similar data elements, forms, and collection procedures, and

reliably identifies current holdings [4,5]. Officials who

control data collection projects or data usage can use DDS

reports to eliminate unnecessary data gathering and to

redirect data management to reduce costs and improve overall

effectiveness [6,7,8].

2.4.2 Data Standardization . Data collected for one purpose

often cannot serve another because Inappropriate standards

were used in the original collection. NBS is producing

selected government-wide data standards under its Data Element and Representation Standards program, but each agency

must also undertake data standardization for its unique concerns [9]. A DDS can be used to record the data standards

- 7 -
applied to every data element, and to assist auditing to assure that the required standards are in effect. Moreover, an

active DDS can be used as the source of established data

standards when needed by various activities, and also can

participate in computer processes that edit and validate

data against the established standards.

2.4.3 System Development and Documentation . The DDS is a valuable documentation tool over the entire life cycle of

systems, procedures, and software [10,11,12].

During the requirements definition of new systems, data

is collected about data, processes, and usage requirements.

Descriptions of these requirements can be stored in the DDS,

and used in conjunction with analysis and design software to

analyze various aspects of the system under development.

Subsequent changes to the requirements definitions can be

easily made and reported to all affected offices and personnel, thereby minimizing errors due to inadvertent omissions

or changes.

Using the current descriptions of the entities and

their relationships, an active DDS can produce data descriptions for individual software modules. When used in conjunction with design aids, the DDS can produce descriptions of

alternative file or database designs for evaluation.

During development, the DDS can produce data division

and documentation for application programs. It can also

produce the actual DATA DIVISION for COBOL programs, or the

data definition language (DDL) for the DBMS

During software testing, the DDS can help generate the

test data by using the entity descriptions which already exist in the dictionary. During maintenance and modification,

the DDS is useful in determining the effect of proposed

changes on other entities in the operational environment.

The DDS can assist in producing documentation concurrently with development, rather than after the fact. As

applications are designed and programs are written, the pertinent entity descriptions, entered in the DDS, will eliminate the need to divert manpower later for documentation

after the application is completed.

2.4.4 Conversion

Lack of documentation is undoubtedly the

primary barrier to economical and complete conversion of applications from one computer system to another. Poor documentation can force an agency to do a system redesign, and

inappropriate or fragmented documentation can Impede the use

of automated conversion aids. Consistent and thorough use

of a DDS can substantially eliminate documentation problems

- 8 -
and facilitate conversion. Most importantly, an active DDS

can provide the data descriptions necessary to drive automated file conversion software [13].

2.5 Potential Benefits

Using a DDS provides economic and technical benefits. A

DDS may provide immediate savings, or it may facilitate a continuing technical process by making it easier or more reliable to perform. To summarize the benefits:

* Better control of the organization's data resources

through improved (i.e., centralized, rigorous, and

standardized) data definitions, data handling and

data collection.

* Improved transportability of data and software

between computing environments through standardized

data elements and data definitions.

* Improved documentation for databases, programs, and

systems

.

* Automatic compilation of data definitions to be included in application programs or in DBMS database

definition.

* Increased security and access control for the database environment.

* Effective aid to software development, modification,

and maintenance through configuration management of

system components of data and programs.

* Increased cost effective use of data resources

throughout the system development life cycle.

3. OBJECTIVES AND SCOPE OF THE DDS STANDARD

The Federal Data Dictionary System standard will be a software specification which a Federal ADP manager may use

to acquire a DDS. NBS will publish the specification as a Federal Information Processing Standard, so that it may be

used in conjunction with Federal Property Management Regulations (FPMR) for Federal procurement purposes.

- 9 -

1
The objectives of the Federal DDS standard are:

1. To define a standard tool that will provide better

management and control of a using organization's information resources.

2. To aid in the portability of DDS software, application software, and related data.

3. To facilitate selection, evaluation, and procurement

of DDS software.

Portability assists Federal agencies to preserve their

investments in programs and data, by providing the ability

to transfer computer programs and associated data, including

the DDS contents, from one computer system to another,

without being required to:

1. Re-create or re-enter data descriptions, except by

an unload/reload process;

2. Modify significantly the DDS application that is being transported; and

3. Learn additional user languages in order to communicate with another DDS implementation.

The Federal DDS standard must be flexible to use in a wide spectrum of applications. This will be sought with progressive levels of sophistication or capability provided in

the standard DDS. That is, users will find increasing levels

of capability available as necessary to meet increasingly

difficult application needs within their organization.

Guidance will be provided to Federal agencies to help

them determine the appropriate circumstances for using a DDS. The Federal DDS standard will NOT require agencies to

use a DDS in all applications. However, whenever an agency

decides to implement DDS software or services, the Federal

DDS standard specification shall be used as the basis for

procurement action.

A number of working assumptions characterize the capabilities envisioned for the Federal DDS standard. The

Federal DDS standard will:

1. Specify a computer software system.

2. Describe or specify (as appropriate) the functional

interfaces and data interchanges between the DDS and

other software components (e.g., operating system)

that users may need to operate the standard DDS.

- 10 -
3. Specify a data description language sufficient to

document (for human users) the data elements, entities, and aggregates processed in selected application programs and database management software packages.

4. Specify input, output, and manipulation functions

and associated language for human users to apply and

exploit t he DDS

.

5. Provide for definition of data element sources and

users including forms, computer programs, and organizational units.

6. Provide a flexible facility for selecting and reporting desired information.

7. Specify a stand-alone DDS, independent of specific

vendor hardware or supporting software, in order to

enhance the portability of DDS applications.

8. Specify, as a minimum, a passive DDS capability that

shall be provided in its entirety within a standard-conforming DDS, for documenting and cataloging an organization's data resources.

9. Provide for additional functional modules as options

for Federal requirements. This provides desired

flexibility in the standard DDS.

4. REQUIREMENTS ISSUES AND PROJECT APPROACH

To define further the Federal DDS standard, NBS is now

conducting a requirements study to resolve major Issues pertinent to the Federal user community. The study will assess

the feasibility of Including specific DDS functions and

capabilities. To accomplish this, the project approach contains the following elements:

1. Close and continuing interaction with the Federal

community to determine:

* whether a particular capability is useful to the

Federal community;

* whether a sufficiently important segment of

Federal users has indicated the need for a given

capability

;

- 11 -
* whether it is desirable to have the capability in

view of known constraints; and

* whether users plan to incorporate the capability

in their data processing operations.

2. In-depth technological assessments and intensive

consultation with vendors, software suppliers, the

research community, and Federal developers of inhouse data dictionary systems, to determine:

* whether it is technologically practical to develop

a particular capability in the near future, e. g.

3 to 5 year range; and

* if technically feasible, whether it is economical

for the software industry to produce such a capability in a competitive market.

3. Formal solicitation of comments and suggestions from

all affected communities throughout the entire

developmental and standardization process.

4. Continuing interchange with related activities in

the American National Standards Institute, and

5. Periodic reports of current NBS plans.

All of these elements indicate the fundamental intent

to develop a standard DOS that will be adopted by Federal

agencies and implemented by a wide spectrum of suppliers.

At present, NBS staff are identifying, analyzing and

defining DDS requirements as found in existing data dictionary systems developed by private suppliers and Federal agencies, as expressed in literature, and as expressed during

interviews with selected agencies. From this data, NBS

plans to develop a Functional Requirements report in Fiscal

Year 1981. NBS plans various dissemination efforts for this

report, including media announcements and workshops. This

review process, besides confirming that Federal needs are

properly represented, will help NBS to refine and elaborate

the needed capabilities. Further development will proceed so that official review of a candidate standard would take

place early in FY83. Then a recommended standard would be

forwarded for approval by the Secretary of Commerce before

the close of FY83.

The Functional Requirements report, as the next major

step of development, will be organized along the lines intended for the standard. It will establish initial priorities among the wide spectrum of possible DDS capabilities.

- 12 -
extending from and refining the list in section 3 of this

document. Commonly provided and needed facilities will be

organized into logically and operationally related groupings

or modules. More sophisticated and innovative functions

will be described also as additional modules to provide the

progressive capability levels. This report also will show

initial NBS conclusions, drawn from interviews, from the

current literature, and from product analysis, on several

important requirements Issues:

* Feasibility of a single user language for all DDS

f unc t ions

;

* Needed entity types and attributes;

* Active operational modes and interfaces, especially

to support automated file conversion and DBMS interfaces;

* Features to support distributed database systems and

distributed processing systems;

* Feasibility of an effective DDS on small computers

(minis or micros).

To summarize the estimated schedule for the planned project

events

* Fiscal Year 1981 — Disseminate Functional

Requirements

* Early Fiscal 1983 — Publish candidate standard in

Federal Register

* Before Close of — Transmit recommended standard

Fiscal 1983 for approval by the Secretary of

Commerce

.

- 13 -
REFERENCES

Leong-Hong, Belkis, and Beatrice Marron, "Technical

Profile of Seven Data Element Dictionary/Directory

Systems," NBS Special Publication 500-3, February,

1977 . Institute for Computer Sciences and Technology, "A

Survey of Eleven Government-Developed Data Element

Dictionary/Directory Systems," NBS Special Publication 500-16, August, 1977.

Lefkovits, Henry C., Data Dictionary Systems , QED

Information Sciences, Wellesley, MA, 1977.

Bontempo, Charles J., and David G. Swanz, "Data

Resource Management," in Hazel McEwen (Editor),

Management o f Data Elements in Information

Processing, Proceedings of a [First] Symposium sponsored by NBS and ANSI-X3L8, held at NBSGaithersburg , NTIS No. COM 74-10700, January, 1974.

England, L. D., S. L. Eberle, B. H. Schiff, and A.

S. Huffman, "Methodology for Development of Standard

Data Elements Within Multiple Public Agencies," in

Hazel McEwen (Editor), Management of Data Elements

in Information Processing , Proceedings of a Second

Symposium sponsored by NBS and ANSI-X3L8, held at

NBS-Gaithersburg , NTIS No. PB 249-530, October 1975.

Federal Information Locator System Task Force, "Report of the Federal Information Locator System Task

Force to James T. McIntyre, Jr., Director of the Office of Management and Budget," December 31, 1979.

Cavanaugh, Robert J., "Cargo Data Interchange System

(CARDIS)," in Hazel McEwen (Editor), Man? g erne nt o f

Data Elements in Information Processing , Proceedings

of a Third Symposium sponsored by NBS and ANS1-X3L8,

held at NBS-Gaithersburg in September 1977. Published as NBSIR 78-1446, April, 1978.

Hegland, Robert A., "The Standard Data Element System (STADES) for Controlling Data Elements Used in

Navy Computer Programs for the Worldwide Military

Command and Control System (WWMCCS)," in Hazel

McEwen (Editor), Management o f Data Element s in

I nf ormation Processing , Proceedings of a [First]

Symposium sponsored by NBS and ANSI-X3L8, held at

- 14 -
NBS-Gaithersburg , NTIS No. COM 74-10700, January,

1974.

9.

U . S . General Accounting Office, "Emphasis Needed on

Government's Effort to Standardize Data Elements and

Cedes for Computer System," Report to the Congress,

May 16 , 1974

.

10. Sibley, E. H., and H. H. Sayanl, "Data Element Dictionaries for the Information Systems Interface," In

Hazel McEwen (Editor), Management of Data Elements

In Information Processing , Proceedings of a [First]

Symposium sponsored by NBS and ANSI-X3L8, held at

NBS-Galthersburg , NTIS No. COM 74-10700, January,

1974 .

11. Shield, Curg, "An Integrated Dictionary for Systems

and Data Components," In Hazel McEwen (Editor),

Management of Data Elements In Information

Processing, Proceedings of a Second Symposium sponsored by NBS and ANSI-X3L8, held at NBSGaithersburg, NTIS No. PB 249-530, October 1975.

12. Winkler, Anthony J., "Automating Systems Development," Computer Related Information System Symposium

(CRISYS), US Air Force Academy, Colorado Springs,

Colorado, January, 1979.

13. Berg, John L. , editor, "DATA BASE DIRECTIONS — The

Conversion Problem," Proceedings of the Workshop

sponsored by NBS and ACM, held in Ft. Lauderdale,

Florida, November, 1977. (To be published as an NBS

Special Publication 500-xx, 1980.)

- 15 -
iI
N B S- 1 I 4A bl V. a- 7 « <

U.S. DEPT. OF COMM.

BIBLIOGRAPHIC DATA

SHEET

1. PUBLICATION OR REPORT NO. NBSIR 80-2115

2.Qov*t AcMsiion No.

4. TITLE AND SUBTITLE

PROSPECTUS FOR DATA DICTIONARY SYSTEM STANDARD

NodiJtfifit's Acc«$S:ion No.

5. Publication Date September 1980

f* Performing Organizatien Code

7. AUTHOR(S)

Application Systems Division

8. Performing Organ. Report No.

9. PERFORMING ORGANIZATION NAME AND ADDRESS

NATIONAL BUREAU OF STANDARDS

DEPARTMENT OF COMMERCE

WASHINGTON, DC 20234

Pmiddt/Task/WorH l^it No.

vb:.. .

11. Contract/Grant No.

12. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS rSfreer. City, Stale, ZIP) 13. Type of Report & Period Covered

15. SUPPLEMENTARY NOTES

Document describes a computer program; SF-185, FIPS Software Summary, is attached.

16. ABSTRACT (A 200-word or leaa factual summary of moat aignificant information. If document includes a significant bibliography or

literature survey, mention it here,)

A Data Dictionary System is an automated information system to assist in

organization-wide data management, without restriction to computer data.

This report describes NBS effort to develop a Federal Data Dictionary System

standard. It discusses the scope and purpose of the standard, the intended

audience, general issues being investigated, and the basic project approach.

17. KEY WORDS (six to twelve entries; alphabetical order; capitalize only the first letter of the first key word unless a proper name;

separated by semicolons)

Computer program; data dictionary system; data inventory;

data management; data standards; database; database management system;

documentation; software

18. AVAILABILITY [X~l Unlimited

f J Order From Sup. of Doc., U.S. Government Printing Office, Washington, DC

20402, SD Stock No. SN003-003-

fX ! Order From National Technical Information Service (NTIS), Springfield, VA. 22161

19. SECURITY CLASS

(THIS REPORT)

UNCLASSIFIED

20. SECURITY CLASS

(THIS PAGE)

UNCLASSIFIED

21. NO. OF

PRINTED PAGES

19

22. Price

$5 .00

USCOM 4-DC

I r

I

.

I

^

I'

i

¥

'-jI

i 9