iii

A111D3 OTDMfib

:NCE & TECHNOLOGY:

"PSTaskGTMloI°^090486

C.2 NBS-PUB

National Bureau of Standards

Library, E-01 Admin. Bldg.

OCT 1

o -j n c: Q w -L L' D U

RECOMMENDATIONS

FOR DATABASE

MANAGEMENT SYSTEM

STANDARDS

NBS Special Publication 500-51

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards
NATIONAL BUREAU OF STANDARDS

The National Bureau of Standards' was established by an act of Congress March 3, 1901. The

Bureau's overall goal is to strengthen and advance the Nation's science and technology and

facilitate their effective application for public benefit. To this end, the Bureau conducts

research and provides: (1) a basis for the Nation's physical measurement system, (2) scientific and technological services for industry and government, (3) a technical basis for equity in trade, and (4) technical services to promote public safety. The Bureau's technical work is performed by the National Measurement Laboratory, the National Engineering Laboratory,

and the Institute for Computer Sciences and Technology.

THE NATIONAL MEASUREMENT LABORATORY provides the national system of

physical and chemical and materials measurement; coordinates the system with measurement

systems of other nations and furnishes essential services leading to accurate and uniform

physical and chemical measurement throughout the Nation's scientific community, industry,

and commerce; conducts materials research leading to improved methods of measurement,

standards, and data on the properties of materials needed by industry, commerce, educational

institutions, and Government; provides advisory and research services to other Government

Agencies; develops, produces, and distributes Standard Reference Materials; and provides

calibration services. The Laboratory consists of the following centers:

Absolute Physical Quantities^ — Radiation Research — Thermodynamics and

Molecular Science — Analytical Chemistry — Materials Science. THE NATIONAL ENGINEERING LABORATORY provides technology, and technical

services to users in the public and private sectors to address national needs and to solve national problems in the public interest; conducts research in engineering and applied science

in support of objectives in these efforts; builds and maintains competence in the necessary

disciplines required to carry out this research and technical service; develops engineering data and measurement capabilities; provides engineering measurement traceability services; develops test methods and proposes engineering standards and code changes; develops and

proposes new engineering practices; and develops and improves mechanisms to transfer

results of its research to the utlimate user. The Laboratory consists of the following centers:

Applied Mathematics — Electronics and Electrical Engineering^ — Mechanical

Engineering and Process Technology^ — Building Technology — Fire Research —

Consumer Product Technology — Field Methods.

THE INSTITUTE FOR COMPUTER SCIENCES AND TECHNOLOGY conducts

research and provides scientific and technical services to aid Federal Agencies in the selection, acquisition, application, and use of computer technology to improve effectiveness and

economy in Government operations in accordance with Public Law 89-306 (40 U.S.C. 759), relevant Executive Orders, and other directives; carries out this mission by managing the Federal Information Processing Standards Program, developing Federal ADP standards

guidelines, and managing Federal participation in ADP voluntary standardization activities; provides scientific and technological advisory services and assistance to Federal Agencies; and

provides the technical foundation for computer-related policies of the Federal Government.

The Institute consists of the following divisions:

Systems and Software — Computer Systems Engineering — Information Technology.

'Headquarters and Laboratories at Gaithersburg, Maryland, unless otherwise noted; mailing address Washington, D.C. 20234. ^Some divisions within the center are located at Boulder, Colorado, 80303.

The National Bureau of Standards was reorganized, effective April 9, 1978.
JUL I 5 c;

COMPUTER SCIENCE & TECHNOLOGY:

RECOMMENDATIONS FOR DATABASE

MANAGEMENT SYSTEM STANDARDS

FIPS Task Group on Database Management System Standards

Center for Programming Science and Technology

Institute for Computer Sciences and Technology

National Bureau of Standards

Washington, D.C. 20234

U.S. DEPARTMENT OF COMMERCE, Juanita M. Kreps, Secretary

Jordan J. Baruch, Assistant Secretary for Science and Teclinology

:^ NATIONAL BUREAU OF STANDARDS, Ernest Ambler, Director

Issued August 1979
Reports on Computer Science and Technology

The National Bureau of Standards has a special responsibility within the Federal

Government for computer science and technology activities. The programs of the

NBS Institute for Computer Sciences and Technology are designed to provide ADP

standards, guidelines, and technical advisory services to improve the effectiveness of

computer utilization in the Federal sector, and to perform appropriate research and

development efforts as foundation for such activities and programs. This publication

series will report these NBS efforts to the Federal computer community as well as to interested specialists in the academic and private sectors. Those wishing to receive

notices of publications in the series should complete and return the form at the end of

this publication.

National Bureau of Standards Special Publication 500-51

Nat. Bur. Stand. (U.S.) Spec. Publ. 500-51, 99 pages (Aug. 1979) CODEN: XNBSAV

Library of Congress Catalog Card Number: 79-600087

U.S. GOVERNMENT PRINTING OFFICE

WASHINGTON: 1979

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, D.C. 20402

Stock No. 003-003-02095-8 Price $3.75

(Add 25 percent additional for other than U.S. mailing).
TABLE OF CONTENTS

Pa ge

1. INTRODUCTION 1

1.1 BRIEF STATEMENT OF THE PROBLEM 1

1.2 BRIEF STATEMENT OF RECOMMENDED SOLUTIONS 2

1.3 PURPOSE AND METHOD OF FIPS TG-24 4

1.4 ACTIONS OF OTHER STANDARDS BODIES 5

1.4.1 American National Standards Institute 5

1.4.2 International Standards Organization 6

1.4.3 Specification Work of Other Bodies. 6

1.4.4 Individual Federal Agency Standards Bodies. 7

2. FEDERAL DBMS STANDARDS QUESTIONS 7

2.1 WHY DBMS STANDARDS? 7 2.1.1 Survey of DBMS Usage By Tg-24 Participants. 7

2.1.2 Government DBMS Usage Trends 8

2.1.3 Current Problems In Data Base Usage 8

2.2 IS NOW THE TIME FOR DBMS STANDARDS? 8

2.2.1 Standards Impact On Database Technology. ... 8

2.2.2 Current Inventory of Standards Candidates. . 9

2.2.3 Sources of DBMS Standard Candidates 9

2.2.4 Timeframe For Standards 10

2.3 WHAT ARE THE ALTERNATIVES? 10

2.3.1 Alternatives To Any DBMS Standards, 10

2.3.2 Standards Other Than Federal 11

2.4 FUTURE OF DBMS TECHNOLOGY 12

2.5 HOW ARE DBMS STANDARDS JUSTIFIED? 12

3. RECOMMENDATIONS FOR STANDARDS 13

3.1 APPROACH AND OVERVIEW 13

3.1.1 DBMS Components 13

3.1.2 Structure of Recommendations 13

3.1.3 General Assumptions 13

- i i i -
3.1.4 General Benefits 14

3.1.5 General Cost Considerations 14

3.2 TERMINOLOGY 16

3.2.1 Background 16

3.2.2 Recommendations 16

3.2.3 Justification 16

3.3 DATA DESCRIPTION LANGUAGE 17

3.3.1 Background 17

3.3.2 Recommendations 18

3.3.3 Justification 19

3.4 DATA MANIPULATION LANGUAGE 21

3.4.1 Background 21

3.4.2 Recommendations 22

3.4.3 Justification 22

3.5 DATA DICTIONARY/DIRECTORY FACILITY 26

3.5.1 Background 26

3.5.2 Recommendations 26

3.5.3 Justification 27

3.6 QUERY LANGUAGE/END USER FACILITIES 28

3.6.1 Background 28

3.6.2 Recommendations 28

3.6.3 Justification 28

4. RECOMMENDATIONS FOR GUIDELINES 30

4.1 BACKGROUND 30

4.2 RECOMMENDATIONS 31

4.3 JUSTIFICATION 33

4.3.1 Assumptions 33

4.3.2 Benefits and Cost Avoidance 33

4.3.3 Costs 33

5. MISCELLANEOUS RECOMMENDATIONS 34

5.1 REDUCING STANDARD ADOPTION COSTS 34

5.1.1 Background 34

5.1.2 Recommendations 34

5.1.3 Justification 34

- i V-
5.2 DATABASE STANDARDS IN OTHER MAJOR AREAS 35

5.2.1 Background 35

5.2.2 Recommendation 35

5.2.3 Justification 35

5.3 TRANSITIONAL STANDARDS ACTIONS 36

5.3.1 Backg round 36

5.3.2 Recommendations 36

5.4 PRIORITIES WITHIN THE RECOMMENDATIONS 37

5.4.1 Background 37

5.4.2 Phasing Recommendations 37

5.4.3 Justification 38

6. REFERENCES FOR TG-24 REPORT 39

7. APPENDICES 43

7.1 APPENDIX 1 - FIPS TASK GROUP 24 CHARTER 43

7.2 APPENDIX 2 - DBMS USAGE SURVEY FOR TG 24 44

7.3 APPENDIX 3 - DBMS TERMINOLOGY FOR TG-24 56

7.4 APPENDIX 4 - DATA DESCRIPTION LANGUAGE 61

7.5 APPENDIX 5 - DATA MANIPULATION LANGUAGE 65

7.6 APPENDIX 6 - DATA DICTIONARY/DIRECTORY 80

7.7 APPENDIX 7 - END-USER/QUERY LANGUAGE 86

V
PREFACE

Under Public Law 89-306 (Brooks Act), the National

Bureau of Standards (Institute for Computer Sciences and

Technology) has responsibilities to develop Federal Information Processing Standards (FIPS). Three major goals are

sought in Federal standards: improved competition among

vendors providing computer systems or services to the

government, improved procurement procedures, and improved

interchange of data and programs within the Federal government. FIPS publications may be either standards or guidelines. A standard is a precise statement of required functions or actions, while a guideline advises and suggests actions. Examples of standards range from the data codes for

state abbreviations to the complex COBOL language specifications. Examples of guidelines include the published recommendations for physical computer security and privacy protection.

To assist the National Bureau of Standards in its consideration of FIPS standards. Task Groups are sometimes established to address specific subject areas. These Task

Groups are advisory bodies made up of volunteer participants

from Federal agencies. Task Group 24 on Data Base Management Systems is such a group. TG-24 purpose, scope, and program of work are contained in its charter. Appendix 1 of

this report.

The issues addressed by Task Group 24 are important,

complex, and highly technical. The recommendations of the

Task Group are valued contributions to our work as representative statements of requirements. They are not necessarily

the technical judgments or current positions of NBS. These

views provide a concrete reference point for others to add

their comments and recommendations. In each area addressed

by the Task Group, NBS has underway a thorough study, including a cost-benefit analysis, leading towards a proposed

Federal standard if warranted by the conclusions of continuing study. Our analyses coupled with continuing input from

Federal agencies will guide the final decisions on Federal

data base standardization. Consequently, we publish this

report to invite additional comment. We will continue to

seek comment as we proceed through the various steps toward

standard i zat i on

.

S. Jeffery, Director

Center for ProgrammingScience and Technology

VT-
ACKNOWLEDGEMENTS

The National Bureau of Standards acknowledges its gratitude to the following TG-24 participants and their sponsoring organizations for their important contributions to

the work of the Task Group.

Robert Ambrose, National Security Agency

Christopher Avery, Department of Agriculture

Ann Bandurski , Naval Ship Research Center

John Berg, NBS, Chairman

Edward M. Carter, USAF

John Cooley, Federal Energy Administration

Michael Corrigan, Defense Communications Agency

Donald R. Deutsch, NBS

Elizabeth Fong, NBS, Executive Secretary

Harry Fujiwara, Department of Housing, Education and Welfare

Dave Gurtner, Veterans Administration

Rick Holt, National Library of Medicine

Wassil Lagoey, US Army

Lois Morin, Office of Management and Budget

Howard Nathanson, Federal Home Loan Bank Board

Janet Nathanson, Pension Benefit Guaranty Corp.

Richard W. Pelc, General Services Administration

Christy Pino, Central Intelligence Agency

Oren P. Phipps, Defense Communication Agency

Ralph Rutherford Jr., Defense Intelligence Agency

Robert Schmid, US Army

Ed Thomas, General Services Administration

In addition, others offered their ideas to the Task Group.

These were:

Julian Adler, State Department

Walter Frederic, Health, Education, and Welfare

R. Michael Gall, Civil Service Commission

Frank Manola, Naval Research Labs

Paul Oliver, US Na vy

Neal Seago, Government Accounting Office

Edgar Sibley, University of Maryland

Dave Weinstein, Central Intelligence Agency

Roxanne Williams, Department of Agriculture

- V i i
EXECUTIVE SUMMARY

The need for standardization in database management

results from the increased usage of database software and

the increased demand for data interchange within the Federal

government. To meet this need. Task Group 24 recommends the

following actions:

++Te rmi nol ogy

.

1. A standard set of data base oriented terms should be

established, should be coordinated with the work of

ISO, and should be included in the current ANSI

standard data processing glossary.

2. Guidelines should be established which encourage

DBMS developers to use this glossary when describing

database concepts.

3. Guidelines should be established whereby vendors are

encouraged to utilize DBMS language syntax which is

compatible with this glossary.

++Da ta Descri pt i on .

1. A two-part data description standard is required

that contains the common description of the data

element (attributes) and the facility to describe

multiple data structure classes.

2. The specification of the standard description of

data attributes should be similar to the attributes

in the PICTURE and TYPE clauses of the CODASYL DDL.

3. The specification of the standard description of

data structures should be required to encompass

current data models such as the hierarchical, network, and relational.

4. Consistent with recommendation 1, the standard

description of the network data structure within the

DDL should be based on the CODASYL DDL.

5. Consistent with recommendation 1, companion data

structure descriptions for the hierarchical and relational data models should be developed.

- V i i i -
1. Develop multiple Data

dards specifications.

Manipulation Language stan2, [Develop a data manipulation language standard

specification:]

(a) For each standard host programming language

(e.g., COBOL, FORTRAN), develop immediately a standard DML specification for each category identified

by TG-24.

(b) As a short range goal, develop a single standard

DML specification for a given category that interfaces with all standard host programming languages.

(c) As a long range goal, develop a single standard

DML specification containing the functionality of

all categories.

++Da_ta D i c t i 0 n a ry .

1. Data dictionaries used by Federal agencies must be

able to produce the standard DDL attribute description as recommended in Section 3.3.2 by the DDL Subcommittee of TG-24. (TG-24 took no position on the

standardization of data dictionaries but addressed

only those data dictionaries with an interface

between the data dictionaries and the DBMS which

must be standardized.)

2. The design of data dictionary must be capable of

combining standard data attribute descriptions with

data structure descriptions to generate the DDL for

one or more DBMS.

3. Establish guidelines on the data dictionary usage.

n- End - user / query F a c i 1 i t i e

1.

2.

Standardi zation

f ac i 1 i t i es is

easily learned,

dent, and there

"styl es."

of syntax and semantics of end-user

not required. Such facilities are

problem and subject-matter depenare a diversity of end-user facility

Guidelines should be developed to aid the specification of requirements of end-user facilities for

Federal procurement purposes.
++ $tandards Adoption.

1. The standards recommended should not be mandatory

until other factors determine a change to the

relevant systems.

2. Standards can be required for new applications or

systems without requiring existing systems to

also conform to the standard.

++ Other Major Areas.

1. TG-24 recommends that the database standards actions

described above apply to database facilities provided by computer services, distributed systems, and

mini computers

.

-X-
RECOMMENDATIONS FOR

DATABASE MANAGEMENT SYSTEM STANDARDS

The Federal Information Processing Standards

Task Group on Database Management System Standards

(FIPS TG-24)

In March, 1977 FIPS Task Group 24 initiated a study of the need for database standards within

the Federal government. The voluntary participants from several Federal agencies considered the

actions of other standards bodies; reviewed the

alternatives to Federal standards; examined the

issues of standards adoption, timing, and impact

on technology; developed a method for justifying

standards, and attempted to anticipate likely database technology advancements.

TG-24 recommended standards in certain

specific technical areas, concluded that standards

were premature in others, and emphasized the need

for certain guidelines.

This final report of TG-24 contains the

recommendations for standards and guidelines as

well as the assumptions, benefits, and costs considerations used to justify the recommendations.

Key words: Database; DBMS; data-description;

data-dictionary; data-directory; d a ta- mani pul a

tion; languages; query; standards.

1. INTRODUCTION

1.1 BRIEF STATEMENT OF THE PROBLEM

Federal government usage of database technology, like

the rapid growth noted in private industry, increases yearly. Each database system differs from the others and inhibits the interchange of skilled personnel, programs or data

among these different systems. Even similar systems have

slight differences that prevent quick interchange.

-1-
The resultant growth in the number of diverse database

system undermines Federal goals sought by the standardization of programming languages and other software components.

In view of the predicted hardware conversions within the

Federal government, and the even greater likelihood of

operating system and peripheral device changes over the next

ten years, database technology will not meet its potential

of facilitating conversion and may even worsen the conversion problem.

Current standards work is being performed in several

areas of database technology but many other areas are being

overlooked. While voluntary DBMS standards actions in the

American National Standards Insti tute(ANSI ) are underway,

these actions require close, cooperative monitoring to insure that they will meet Federal needs and time frames.

1.2 BRIEF STATEMENT OF RECOMMENDED SOLUTIONS

This report contains a specific recommendation to

develop a family of database standards for the Federal

government. The Task Group recommends the following actions:

++Terminol ogy .

1. A standard set of data base oriented terms should be

established, should be coordinated with the work of

ISO, and should be included in the current ANSI

standard data processing glossary.

2. Guidelines should be established which encourage

DBMS developers to use this glossary when describing

database concepts.

3. Guidelines should be established whereby vendors are

encouraged to utilize DBMS language syntax which is

compatible with this glossary.

++Da ta Descri pt i on .

1. A two-part data description standard is required

that contains the common description of the data

element (attributes) and the facility to describe

multiple data structure classes.

2. The specification of the standard description, of

data attributes should be similar to the attributes

in the PICTURE and TYPE clauses of the CODASYL DDL.

-2
3. The specification of the standard description of

data structures should be required to encompass

current data models such as the hierarchical, network, and relational.

4. Consistent with recommendation 1, the standard

description of the network data structure within the

DDL should be based on the CODASYL DDL.

5. Consistent with recommendation 1, companion data

structure descriptions for the hierarchical and relational data models should be developed.

++Data Manipulation .

1. Develop multiple [Data Manipulation Language] standards specifications.

2. [Develop a data manipulation language standard

specification:]

(a) For each standard host programming language

(e.g., COBOL, FORTRAN), develop immediately a standard DML specification for each category identified

by TG-24.

(b) As a short range goal, develop a single standard

DML specification for a given category that interfaces with all standard host programming languages.

(c) As a long range goal, develop a single standard

DML specification containing the functionality of

al 1 categori es

++Data Dictionary .

1. Data dictionaries used by Federal agencies must be

able to produce the standard DDL attribute description as recommended in Section 3.3.2 by the DDL Subcommittee of TG-24. (TG-24 took no position on the

standardization of data dictionaries but addressed

only those data dictionaries with an interface

between the data dictionaries and the DBMS which

must be standardized.)

2. The design of data dictionary must be capable of

combining standard data attribute descriptions with

data structure descriptions to generate the DDL for

one or more DBMS.

-3-
3. Establish guidelines on the data dictionary usage.

++ End-user/query Facilities .

1. Standardization of syntax and semantics of end-user

facilities is not required. Such facilities are

easily learned, problem and subject-matter dependent, and there are a diversity of end-user facility

"styl es."

2. Guidelines should be developed to aid the specification of requirements of end-user facilities for

Federal procurement purposes.

++ Standards Adoption .

1. he standards recommended should not be mandatory

until other factors determine a change to the

rel evant systems

.

2. Standards can be required for new applications or

systems without requiring existing systems to also

conform to the standard.

++Other Major Areas .

1. TG-24 recommends that the database standards actions

described above apply to data base facilities provided by computer services, distributed systems, and

minicomputers.

1.3 PURPOSE AND METHOD OF FIPS TG-24

The work of FIPS TG-24 followed its charter which appears in Appendix 1 of this report. This charter contains

FIPS TG-24's purpose, scope and program of work. Nineteen

Federal agencies contributed to this report over the course

of one year. Several sub-Task Groups addressed specific subjects and reported their findings to the committee.

Viewpoints from experts in the field. Federal government

agency managers facing database decisions, and published material on database technology assisted the Task Group in

meeting its goals. Subcommittees were formed to investigate

and propose standards for each component. The final overall

recommendations were reviewed so that each component's

recommendations are consistent.

In addition to describing specific functional capabilities, each subcommittee considered and addressed issues such

a s

-4-
1. A single standard or multiple standards.

2. To standardize at the syntax level or functional

level.

3. The nature of the interface between the components

and the DBMS as a whole software system, and the interface between components.

4. The impact of the proposed standards on the future

DBMS technology.

5. The cost and benefit of the proposed standards

within each component.

6. An assessment of the cost of implementing and maintaining the proposed standards.

7. A plan for the achievement of the proposed standards.

These issues are individually addressed in the "Justification" subsections within the Chapter "Recommendations for

Standards."

1.4 ACTIONS OF OTHER STANDARDS BODIES

1.4.1 American National Standards Institute. In autumn,

1972 , the American National Standards insti tute (ANSI) committee on Computers and Information Processing committee

(X3) through its Standards Planning and Requirements Committee (SPARC) established a Study Group on Data Base Management Systems with a charter "to investigate the potential

for standards." The Study Group issued an interim report in

1975 and a final report in July 1977. [ANSI 75, TSIC 77]

The final report contained neither specifications for a recommended standard nor recommendations for any action for

standardization of any existing products or specifications.

The report does contain a "framework" which can be used to

consider future standards actions.

After accepting the report, SPARC initiated three pertinent actions: referred actions for subschema data description language specifications and data manipulation language

specifications to the COBOL committee, referred actions for

a Subschema data description language specification and data

manipulation language specification to the FORTRAN committee, and initiated a committee for data description language

speci f i cat i ons

-5-
1.4.2 International Standards Organization* Within the

International Standards Organization (ISO), Technical Committee 97/Study Committee 5/Working Group 3 on DBMS meets

semiannually and has a very ambitious program of work. Its

Scope of Work includes:

1. Define concepts for conceptual schema languages

2. Define or monitor definition of conceptual schema

1 angua ge

3. Develop a methodology for assessing proposals for

conceptual schema languages.

4. Assess candidate proposals for conceptual schema

languages

5. Define concepts for conceptual level end user facilities

6. Define conceptual level end user facilities

7. Take cognizance of and react to other data base

developments as appropriate

8. Develop vocabulary for Data Base Management Systems

1.4.3 Specification Work of Other Bodies . The Conference on

Data Systems Languages ( CODAS YL ) is a voluntary body that

developed the Common Business Oriented Language (COBOL) and

guided that language's evolutionary development. CODASYL

developed detailed language specifications for a FORTRAN

Data Manipulation Language and Subschema Data Description

Language, a COBOL Data Manipulation Language and Subschema

Data Description Language, a host-language independent Data

Description Language, and a draft Data Storage Description

Language. The FORTRAN specifications were published in January 1977 and the latter three will be published in April

1 978.

Though not a standards body the impact of CODASYL work

on languages is well known, and their work in the DBMS areas

has had significant impact already. The various specification developing committees of CODASYL meet at intervals

varying from every six weeks to three or four months. Approximately 25 different vendors and users are represented

in the developmental committees. Proposals for improvements

to the specifications arrive from world-wide sources, including the European Computer Manufacturing Association, the

International Federation of Information Processing Societies, and several vendor user bodies. CODASYL specifications will continue to evolve and will be considered as

-6-
standards candidates by ANSI. However, CODASYL is not a standards making body and CODASYL specifications can not become standards through CODASYL actions alone.

1.4.4 Individual Federal Agency Standards Bodies . Among the

1 a rger Federal agencies participating in T G - 2 4 , it was noted

that several had their own standards-making function and

some were currently considering DBMS standards. For example, the Department of Agriculture has already established a policy to use exclusively one proprietary DBMS for most applications. Similarly, the Army reviewed various options

related to reducing the number of DBMS used by its com-

^ponen ts

2. FEDERAL DBMS STANDARDS QUESTIONS

2.1 WHY DBMS STANDARDS?

2.1.1 Survey of DBMS Usage By Tg-24 Participants. TG-24 surveyed DBMS usage of those Federal agencies participating in

TG-24 in order to understand to some degree the actual usage

of DBMS within the Federal agencies. The survey was not a "rigorous" one but it is useful in indicating the likelihood

of significant trends in the Federal agencies. Details of

the survey and its findings are in Appendix 2.

The informal results support the assumption that

Federal agency usage of database systems parallels the

growth of such systems in private industry. Within the 14

agencies surveyed, 57 distinct DBMS were found. A few years

ago, only large, special purpose database systems were reported and these were primarily in the Department of Defense. Therefore, TG-24 inferred a significant growth in

Federal DBMS usage in recent years. Detailed determination

of the quantities of program code and data now committed to

DBMS systems awaits a more comprehensive and carefully

developed survey.

Contributing to the difficulty of finding information

on Federal use of DBMS is the lack of a central repository

of such information. TG-24 lacked the resources to conduct

a formal user survey. Even when data may exist it is not in

a form that permits ready synthesis of the information needed. TG-24 recognized the value such information would have

for Federal planning and encouraged the development of such

statistics but, at the same time, understood the expense

-7-
which may be involved in determining them.

2.1.2 Government DBMS Usage Trends . In a copyrighted survey

oT iJFMS usage at 360/370 sites [IDC 77], International Data

Corporation found that "of 861 sites in sample, 312 users

(36.2%) reported usage of a DBMS at yearend 1976, and the

figure climbed to 433 sites [planned] by yearend 1978

(50.3%)." If the same percentages hold true for the Federal

Government's 8649 computers (1975), 3131 sites now use DBMS

and 4350 will in 1978.

2.1.3 Current Problems In Data Base Usage. Several Federal

agency managers of data processing shared with TG-24 the issues that concerned them. These were identified as:

1. Need for a common functional requirements specification checklist to aid in the procurement of database

systems

.

2. Need for guidance on when to use what database system and how best to achieve its intended objectives.

3. Fear of a single, universal standard that prevents

effective use of databases because of that agency's

particular needs.

4. Need to identify and standardize subcomponents.

5. Need for assistance in the procurement process.

6. Need for assistance in converting to the standard.

7. Need for a quick, easy, low volume access to data.

8. Need for a standard that assists in reducing change

and promotes user control of changes to product

specifications rather than vendor control.

2.2 IS NOW THE TIME FOR DBMS STANDARDS?

2.2.1 Standards Impact On Database Technology. The Task

Group considered specifically the possiblity that standardization at this time might have a harmful effect on database

technology. The result of this consideration was to note

how difficult such a hypothesis was to prove or disprove.

Further, it was not clear whether such a question was a proper consideration of the Task Group. Stated more directly, the recommendations of the Task Group require justification of cost savings or cost avoidance for the Federal

government as a whole. Such considerations of future DBMS

-8-
technology impacts could properly be considered under potential or future costs but may be secondary to immediate costs

or benefits.

TG-24 reviewed various scenarios in which "premature"

database standards might inhibit new technology. The Task

Group determined that difficulties arose immediately upon

trying to select a metric for considering technology growth.

Certainly subjective conclusions can be found everywhere.

However, any such conclusions must consider three factors -- the type of standard concerned, the manner in which the

selected standard is promulgated, and the extent to which it

is accepted. Different combinations of these factors will

affect different stages of program development cycle with

differing impact on technology.

TG-24 looked for precedents in past standards activities. It reviewed the ASCII, COBOL, and MUMPS standards

history and found no obvious instance where standards have

inhibited or adversely affected technological growth.

2.2.2 Current Inventory of Standards Candidates. The size of

the inventory of potential candidates for standardization

depends on the degree of detail required for the statement

or specification of the candidate. For example, the various

CODASYL specifications are quite detailed statements of syntax and semantics presented in a very formal manner. On the

other hand, some have argued that the user's manual of, say,

a proprietary database system is equally a specification.

Proprietary systems raise a second issue: the availability

of the specifications for use by all interested implement ors

^.2.3 Sources of DBMS Standard Candidates. Identifiable

sources of standard candidates do exist and should be examined. To aid its work, TG-24 reviewed the following

sources

0 Existing computer vendor software

0 Existing proprietary packages

0 Existing specifications from volunteer developmental

groups

0 Existing Federally "owned" software

0 NBS developed specifications

In considering each of the broad areas, TG-24 noted a set of

common requirements:

-9-
0 A clear and precise specification that permits any

vendor to implement it

0 The general availability of such a specification

0 A concrete method to validate the specification and

mediate disputes

0 A body that reviews and updates the specification

0 A method to validate implementations of the specification and mediate different interpretations of it

0 The need to deal with the impact on those systems

not s el ect ed

2.2.4 Timeframe For Standards. Significant time requirements

enter in the consideration of standards and especially so

for DBMS standards. The Task Group concluded that a ten

year life-cycle was the proper timeframe in which to consider DBMS standards. One to two years may be required for

the development of the standard specifications. This time

is not included in the ten year period. Another important

time consideration is the time from the availaility of the

specifications to the availability of the first implementation. This period may also be one to two years. The ten

year period will include periodic reviews.

Development of totally new DBMS specifications would

require significantly longer periods before the preparation

of specifications and the availability of useful products.

2.3 WHAT ARE THE ALTERNATIVES?

In deciding which approach to take in standardizing

DBMS, consideration must be given to existing products, the

feasibility of developing totally new products, and the work

of other standards bodies. At the same time, the feasibility of implementation, the timeframe of the standard's

development, the possible longevity of the standard, and the

manner in which this rather large subject, DBMS, is divided

into discrete components will also affect the decision.

2.3.1 Alternatives To Any DBMS Standards . Several alternatives to standards do exist:

1. Effective conversion tools would reduce the need for

standards. However, "Data Base Directions II--the

Conversion Problem" [BERG 78] reported the findings

of a group of experts which stated that conversion

technology has a need for standards in the area of

-10-
data interchange formats. Given such a standard, a translator that quickly and cheaply converted any

database to any other database might eliminate the

need for standards.

2. Data Dictionary/Directory standards may result in

lessening the need for DBMS standards by providing

common descri pti ons f or all DBMS to use.

3. The Data Description Language used to provide,

bridge, or interface with several Data Manipulation

Languages may permit a multiplicity of DML's while

providing many of the standard's objectives.

4. For smaller agencies, the availability of a single

time-sharing DBMS may be used to satisfy the standarization objectives for Federal applications requiring the interchange of data and programs.

2.3.2 Standards Other Than Federal. The Federal government

could adopt standards from other bo dies or take advantage of

existing de facto standards. These include:

0 ANSI Standards

0 De Facto Vendor Standards -- in the absence of other

standards, the vendor's practice of making the same

product available to all of its customers simplifies

its task of maintaining and correcting the software

it supports. This leads to a general compatibility

between users of the same vendor systems. Generally, users groups have developed to exploit this compatibility through the interchange of information

among the users. However, such de facto vendor

standards are under the control of the vendor and

subject to changes needed to meet vendor goals.

While vendors are sensitive to customer needs, experience has shown that such changes have occurred.

0 Proprietary system issues -- Owners of proprietary

systems may not wish to give up ownership or be unable to provide precise specifications of existing

systems. At the same time, the competitive nature

of the computer industry may result in a gradual

development of proprietary systems toward the standard [BROC 76].

0 International Standards

-11-
0 Individual Government Agency Standards

0 Functional Application Area Standards For example:

Law enforcement, health, library, air transportation, etc.

2.4 FUTURE OF DBMS TECHNOLOGY

TG-24 concluded after a review of pertinent references

that database technology would continue to be characterized

by significant and important work. The Task Group agreed

with those who see change as inevitable over the next ten

years. However, the Task Group concluded that change would

be evolutionary and assumes that no "breakthroughs" will

probably occur in that time period. Further, TG-24 concluded that proper standards planning will enhance the ability

of Federal agencies to cope with breakthroughs if they

shoul d occur.

2.5 HOW ARE DBMS STANDARDS JUSTIFIED?

The first step in any DBMS standardization effort is

developing a proposal for a particular specification. The

next step is to justify the commitment of resources to

develop the specification. TG-24 used a combination of

quantitative and qualitative analysis to justify its recommendations. The Task Group began by systematically identifying the costs and benefits of DBMS standardization and documenting the underlying assumptions. This work assisted

TG-24 in developing aset of priorities that led to the consideration of an interrelated set of DBMS components which

it identified as a "family of standards."

The work will also assist those developing the specifications to compare actual experience against the assumptions

in order to guide the specification development effort.

The difficulty in finding quantifiable costs led the

Task Group to a method depending primarily on qualitative

assessments. Therefore, the justification in the Recommendation Section is presented in qualitative terms.

-12-
3. RECOMMENDATIONS FOR STANDARDS

3. 1 APPROACH AND OVERVIEW

3.1.1 DBMS Components. Dividing DBMS into functional modules

which together would meet the diverse needs of the Federal

agencies provided the basis for organizing the TG-24 standards investigation and recommendations. The components

that TG-24 chose as requiring standards considerations are:

0 Data Dictionary/Directory Facilities

0 Data Description Facilities

0 Data Manipulation Facilities

0 Query and End-User Facilities

3.1.2 Structure of Recommendations . Each of the components

considered is presented in a form indicated by the following

outl i ne

I. Background (problem statement, scope and definition

major approach and methodology)

II. Recommendations (stated briefly and clearly)

III. Justifications

(a) Assumptions

(b) Benefits and Cost Avoidance

(c) Costs (standard implementation, maintenance

and usage)

(d) Di scussions

All technical details and figures will appear in the appendices.

3.1.3 General Assumptions. In listing the assumptions to

justify each of its recommendations for each component,

TG-24 found that some assumptions were common to all or to

many of them. Therefore, a list of general assumptions that

are applicable to the Federal DBMS standardization effort as

a whol e f ol 1 ow

-13-
0 Life cycle of database standard is ten years.

0 The use of DBMS will continue to increase.

0 The databases will grow in size, number, and complexity within the next ten years.

0 Changes in h'ardware and software over the next ten

years will have little effect on the basic functions

performed by data base systems.

0 Present DBMS architectures will be useful even in

emerging new system environments (such as distributed systems) and changes to the DBMS architectures

will be evolutionary over the next ten years.

0 There will be more DBMS conversions within each of

the Federal organizations.

0 Transfer of data among Federal agencies within legislated guidelines will be increasing. Cost and

benefits considered will be limited to those of

Federal agencies.

3.1.4 General Benefits. The general benefits that can be

i d ent i f i ed for DBMS standardization as a whole are as fol1 ows

1. Easier data conversion.

2. Easier program conversion.

3. Improved personnel transferability.

4. Improved data sharing among different computer instal 1 at i ons .

5. Improved DBMS competition among vendors.

6. Improved selection and evaluation of DBMS products

7. Improved DBMS procurement process through larger

vendor choice and competition.

3.1.5 General Cost Considerations . The general cost considerations pa ral lei the set of common standards requirements discussed in the section dealing with the purpose and

approach of TG-24. These are the costs of:

-14-
1. Developing a standard specification. Such a specification can be obtained from volunteer organizations, a government agency, vendors releasing their

proprietary rights, or from a body established to

provide the specifications.

2. Publishing the specification and analyzing the comments received.

3. Validating the specifications and mediating the

differing interpretations.

4. Validating the implementations for conformance to

the specifications.

5. Maintaining specifications over standards' life

spa n

While some of these costs are one-time costs, several are

on-going costs over the life cycle of the DBMS standard. In

addition to the costs associated with developing the standard specification, some costs can be identified with installing the standard DBMS component.

Note that costs associated with converting to a standard can be avoided by requiring use of the standard only

when another form of change forces a conversion. Then the

conversion to the standard has no direct costs. For example, first time users selecting a data dictionary system

would probably pay no more for a data dictionary that produces output compatible with standard database systems then

they would for a non-standard dictionary system.

Similarly, costs resulting from the conversion to improved hardware or software capabilities may be timed to include changes to standard practices. Agencies may shift to

standard practices in a piecemeal fashion as existing nonstandard practices require significant changes.

Costs associated with installing a standard DBMS component when the above considerations are ignored include:

0 Personnel -trai ni ng and temporary loss of productivity

0 Conversion of data

0 Translation costs of programs

Cost will vary with the degree of difference between the

non-standard system and the standard.

-15-
3.2 TERMINOLOGY

3.2.1 Background . The Federal government currently uses many

different data base management systems. Each of these systems is unique in that its developer has adopted terms to

represent syntactic and semantic entities which fit his own

environment. For this reason, many similar data management

functions are described in terms which are quite dissimilar.

In the same fashion, many terms which are shared between

several DBMS may have quite different meanings.

TG-24 recognized that its members used DBMS terms in a dissimilar manner. Consequently, the terminology appearing

in Appendix 3 of this report was developed to help TG-24

members in their written and oral communications. This terminology definition is not intended to be a standard.

Work to date by ANSI has established a standard glossary of data processing terms [ANSI 77]. The absence of

data base terms, however, is quite pronounced. The International Standards Organization/Technical Committee 97 is

currently involved in establishing such a glossary.

3.2.2 Recommendations .

1. A standard set of data base oriented terms should be

established, should be coordinated with the work of

ISO, and should be included in the current ANSI

standard data processing glossary.

2. Guidelines should be established which encourage

DBMS developers to use this glossary when describing

database concepts.

3. Guidelines should be established whereby vendors are

encouraged to utilize DBMS language syntax which is

compatiblewith this glossary.

3.2.3 Ju St i f i c at i on .

++ As sumpt i on s .

1. The proliferation of DBMS will foster invention of

unique DBMS terms for similiar concepts.

2. Terminology standards will continue to be developed

by ANSI and ISO.

++Benefits and Cost Avoidance . Benefits to be derived from

establishing a common set of database oriented terms can be

seen mainly in the areas of training and information

-16-
interchange. A terminology standard would permit preliminary training, (e.g. university, technical school) to address general knowledge of database concepts, these concepts

being embodied in the database glossary. Training at more

specific levels could therefore be shorter in duration and

more productive.

In the same fashion, interchange of information between

individuals using different database systems can be facilitated. Different features can be related to the glossary of

terms, thereby providing a. mapping of information about one

system onto another.

++Co St

. The cost involved in establishing and maintaining

a terminology standard is relatively small since Federal

agencies would rely on voluntary development. The pay-back

for this effort would begin immediately and would easily

justify the expense in establishing the standard.

3.3 DATA DESCRIPTION LANGUAGE

3.3.1 Background . The data description language (DDL) is defined as astand-alonelanguage that describes:

0 Attributes of data elements

0 Logical relationships among units of data (records,

set s , etc .

)

0 Logical structure of the database

0 Logical methods of access to data

The DDL does not include the definition of physical

storage media.

The Federal Government currently uses a large number of

database management systems. Often a single agency supports

more than one DBMS in order to satisfy varying user needs.

Each DBMS has its own language for describing the attributes

and relationships of the stored data. This variety of data

descriptions makes it impossible for agencies, or even different units within an agency, to easily interchange data.

The people who are interested in using the data are forced

to learn the specific DDL which describes it. When data is

exchanged, a new description of data for the target system

must be written and tested before the data can safely be

used

-17-
The current situation is both costly and time consuming. Therefore, the recommendations are aimed at reducing

both the time and cost required to exchange data between

different users.

3.3.2 Recommendations.

1. A two-part data description standard is required

that contains the common description of the data

element (attributes) and the facility to describe

multiple data structure classes.

2. The specification of the standard description of

data attributes should be similar to the attributes

in the PICTURE and TYPE clauses of the CODASYL DDL.

3. The specification of the standard description of

data structures should be required to encompass

current data models such as the hierarchical, network, and relational.

4. Consistent with recommendation 1, the standard

description of the network data structure within the

DDL should be based on the CODASYL DDL.

5. Consistent with recommendation 1, companion data

structure descriptions for the hierarchical and relational data models should be developed.

+ +Expl anat i on . The separation of the description of data

element attributes from the description of data structure

has been recommended because a single standard for both will

not serve the needs of the Federal community. Separation of

data element descriptions from data structure descriptions

allows maximum flexibility while benefiting from the advantages of standardization. It would provide a single standard for data element descriptions and multiple standards

for data structure descriptions. The concept of separation

has been advanced by such noted authorities in the field as

E.F. Codd, M.E. Senko, and James Martin. [CODD 71, SENK 73,

MART 77]

The attributes required to describe data elements by

any DBMS are similar, although the syntax and semantics used

are often very different. A single standard in this area

would simplify the user's task in describing the data elements contained in the data base; it was felt that the

choice of syntax used to describe data element attributes

was irrelevant. The attributes of the CODASYL DDL were suggested because:

-18-
1. They are well documented with a formal specification.

2. They are supported by a maintenance group.

3. They are an extension of COBOL, a widely used computer language.

4. There are currently several DDL implementations

based on the CODASYL proposal

In the data structure area, both the characteristics

and the seman t i c s/ synt ax required to describe it are different. Three discrete data models have been identified,

i.e., hierarchical, network, and relational. Each of these

models has unique characteristics that require a unique

structure description. A single standard would impose one

of the above models on all Federal agencies regardless of

user requirements. For example, a user with an ad-hoc retrieval requirement who may best be served by a relational

data model would be needlessly constrained if a network were

adopted as the single standard.

3.3.3 Justification . ++As sumpt i on s .

0 The amount of data description in the Federal

Government will continue to grow.

0 The amount and complexity of data stored in database

structures by the Federal Government will grow significantly.

0 The increase in DBMS usage will cause an increase in

DDL training requirement.

0 The demand for interchanging of data between DBMS

will grow.

++Benefit and Cost Avoi dance. Savings will be mainly in the

area of:

0 Personnel - After the initial investment of reeducating all personnel in the use of the standard,

DBMS retraining costs would be minimized. Additional costs would be avoided by reducing cost of new

training, and reducing the cost of low productivity

coupled with high error rates during the period of

developing expertise in the use of the new DBMS.

-19-
0 Transfer of Data Descriptions - Cost of transfer of

DDL between source and target DBMS would be minimized because the DDL of the source DBMS could be

directly compiled on the target DBMS. Opportunity

will exist for more automated means of converting

between different DBMS.

0 Transfer of Data - Transfer of data would be simplified because the use of the standard DDL would allow

a two step conversion. The source data would be

converted to an intermediate file. The intermediate

file would be loaded on the target DBMS using the

same DDL. Target users would have no difficulty in

ut i 1 i zi ng the dat a

.

There are other equally important considerations that

are not easily quantifiable. These are timeliness and quality of data. The disruption felt by end users during

conversion is difficult to measure but is a real factor.

The standardization of DDL would encourage transfer of

data between users. Currently, the time and cost involved

in data transfer forces users to do without needed data, or

to duplicate collection and maintenance of data existing

elsewhere. The report of the Federal Paper Commission cited

duplicate collection of data as a serious government-wide

probl em

.

Standardization of DDL would also encourage wide use of

DBMS in the Federal Government. Many agencies are hesitant

to get "locked in" to a non-standard DBMS causing them to

use far less efficient means of storing and accessing data.

Standardization of DDL, as recommended, would contribute both quantifiable and non-quantifiable cost savings in

the Federal Government. In addition, efficient information

processing methods would be fostered.

++ Co St

s

. The Federal government should encourage and participate in voluntary standard action. However, in order to

effect the intended goals the Federal government should be

prepared to accept the costs of developing and maintaining

the Data Description Language specification. The costs will

be initially the development of the specification, whether

in voluntary standards groups or as a Federal effort, and

the subsequent maintenance of the specification.

-20-
3.4 DATA MANIPULATION LANGUAGE

3.4.1 Background. Data Manipulation Language (DML) is the

1 anguage which a programmer uses to cause data to be

transferred between a program and the database. The DML may

not be a complete language by itself. It may rely on a host

programming language to provide the procedural capabilities

required to manipulate data. A user application program is

written using a mixture of host programming language statements and the DML commands. The DML provides the ability to

interact with the database by giving commands to cause an

action and by providing a means to receive responses from

the database or the processors involved. The DML consists

of several data manipulation commands or functions which may

include the following: data retrieval, data addition, data

modification, data deletion and modifications of data relationships.

The diversity of data manipulation functions and

languages causes many problem areas which would benefit from

standardization. The following problems occur with current

DBMS technology when users must contend with two or more

DBMS.

0 There exists a different (non-standard) DML for each

DBMS.

0 The data manipulation functions of each DML differ

in syntax and semantics.

0 The data manipulation functions also differ in syntax and semantics between the various host programming languages for a given DBMS. Specifically, the

DML for the FORTRAN language interface is different

from the COBOL language interface.

0 The functional capabilities provided by DML are different across the set of available DBMS. This causes

problems in conversion and procurement.

TG-24 evaluated the DML of twelve of the more commonly

used DBMS and discovered four groupings. Chart I in Appendix

5 shows the twelve DBMS and their DML. Charts A, B, C, and D show the four categories of DBMS identified, and examples of

the DML for each category.

TG-24 developed the concept "category" to help it

analyze potential standards. The term "category" is an adhoc concept used merely for the purposes of our analysis.

Categories are groupings of DBMS based on some technical

criteria. The criteria used by TG-24 to categorize DBMS were

-21-
the commonality of data manipulation functions and data

structures. Categories should not be equated to data models,

although data structures are used as a major criterion to

categorize data base systems. The term "data model" refers

to the type of data structuring permitted by a DBMS (e.g.,

network, hierarchical, relational, ..) and various data

models appearing in the literatures may have only slight

differences. See for example [MART 77] and [KERS 76] for a discussion of different data models.

Though the concept of "categories" has special utility

for TG-24's analysis, the idea behind this method may be of

use to those who will be performing the follow-on detailed

work. A more comprehensive analysis to categorize DBMS may

require additional criteria. TG-24 does not wish to restrict

the methodology used to categorize DBMS, but the intent of

the analysis should be to support the goal of standardization by eliminating smaller differences, combining similar

functionality, and producing the smallest number of categories.

The following recommendations assume four categories of

DBMS with at most one standard DML for each host programming

language for each category of DBMS and a potential of one

standard DML for al 1 DBMS.

3.4.2 Recommendations.

1. Develop multiple DML standards specifications,

2. (a) For each standard host programming language

(e.g., COBOL, FORTRAN), develop immediately a standard DML specification for each category identified

by TG-24.

(b) As a short range goal, develop a single standard

DML specification for a given category that interfaces with all standard host programming languages.

(c) As a long range goal, develop a single standard

DML specification containing the functionality of

all categories.

3.4.3 Justification . ++ As sumpti on

s

.

1 Database

ti f i abl e tures

.

manag emen

t

categori es

systems fall into limited idenreflecting different data struc-

-22-
2. Increasing numbers of application programs will be

written using the DML.

3. The present interrelationships between data definition languages and data manipulation languages will

remain the same in the next ten years.

4. The existing differences present in the host programming language interfaces are not necessary to

provide the needed data manipulation functionality.

5. The increasing number of computer conversions anticipated within the Federal government will require

reprogrammi ng a large number of application programs

using DML.

6. Data manipulation functions and data structures are

valid criteria for categorizing DBMS.

++Benefits and Cost Avoidance .

0 A greater return from (or a reduction of) required

resources for programmer training, program conversion, data transfer, and application system transfer

will occur with standard DML.

0 Limiting the number of standard syntactic and semantic definitions for data manipulation functions will

simplify the terminology differences and make it

possible to evaluate the capabilities of DBMS.

0 The evaluation, selection, and procurement of DBMS

will be simplified by the standardization of a limited number of data manipulation languages.

0 The proposed standard DML interface will simplify

data sharing in computer networks, community data

bases, and distributed databases.

++Cost_s. The following factors affect the standard's cost:

0 Increasing the number of categories and the number

of host programming language interfaces will significantly increase the cost of specifying and

developing the family of standard DML.

0 Conversion cost. A cost will be associated with converting existing DML to standard DML. The cost will

vary with the differences between existing DML and

the appropriate standard.

However, conversion costs can be avoided by:

-23-
0 installing the standard only for new applications.

0 delaying adoption of the standard until conversion

is required by other factors.

++D i sc uss i on . The first of the recommendations posed above

a 1 1 ows for the development of multiple DML standards. TG-24

seeks to permit flexibility in DBMS standards by providing a family of standards. Such an approach will allow an overall

database architecture to exist that will provide useful

functions and data structures that are not currently provided by any single DBMS using a single DML standard.

The second recommendation is a gradual movement towards

a desirable end goal. It would be very beneficial to the

DBMS end-user community if one standard DML was possible and

practical. TG-24 felt that the standardization effort could

not begin with the single DML standard route, but the effort

may evolve to that end. There are major differences between

the data structures and DML provided by various DBMS today.

For this reason, if the DBMS continue to evolve, it is very

possible that the major differences between DBMS will disappear and all DBMS will provide similar major capabilities.

This would allow a single DML to be practical.

-24-
^1

II-

^1

11=

II

II

II-

•il Hi era rchy

II

HOST PROGRAMMING LANGUAGE

CATEGORY COBOL FORTRAN PL/1 other Al 1

Network

II

II Relational

11 = = = = = = = = = = =

II

IIII- A1

DM Function

Superset

Figure 1 - Relationship of Host Language Standards

to DML standards

The matrix in figure 1 illustrates the DML recommendations. Each of the categories listed down the left hand

edge of the matrix provides the user with a useful viewpoint

of the database. Across the top of the matrix appear examples of existing standard languages. As indicated by the

matrix, each intersection of row and column provides an opportunity for a specific DML. For example, the CODASYL database specifications would be a candidate for the intersection of COBOL and the network category but, of course, would

not satisfy the COBOL /rel at i onal intersection. Similarly,

CODASYL has proposed a FORTRAN DML which is a candidate for

filling the network category and FORTRAN intersection.

The DML recommendation identified each of the intersections as a potential standard. However, TG-24 also noted the

inherent commonalities that would exist in all DML for any

particular category. Save for differences of syntax reflecting the specific host language, the functions performed

essentially remain the same over all the languages. One DML

independent of any particular language could satisfy all the

host languages for any particular category. The matrix indicates this with final right hand column which contains a DML for each category.

-25-
Finally, TG-24 considered the fact that all the different categories were treating the same important data.

The concept of a superset of data manipulation functions

common to all the categories but bundled to eliminate

differences of syntax, data structures, or a particular

viewpoint is not new. Several technical papers have treated

the subject of "reconciling" various data models into a common language for the' user. This lead to the conceptual possibility of "summing" the host language independent DML in

the right hand column into the one common DML found at the

bottom of the column.

The process of abstracting the various DML into a category-common DML and then, further, into a single, common

DML is admittedly speculative and requires demonstrations of

feasibility. However, such an approach would support

directly the goals of standardization and TG-24 recommended

its i nvest i gat i on

.

3.5 DATA DICTIONARY/DIRECTORY FACILITY

3.5.1 Background . A data element d i cti onary/ di rectory (to be

referred to in short as data dictionary (DD)) is a software

tool that is used to identify and interrelate data elements

within an application or enterprise. It is viewed as the

central repository of all descriptive information about each

data element contained within an application database.

The scope of the standardization recommendations excludes data dictionaries that are manual tools for data

resource management. In Appendix 6, the various types of

data dictionaries, the various features that a typical data

dictionary would provide, and some commercial package names

are mentioned for illustrative purposes.

3.5.2 Recommendations .

1. Data dictionaries used by Federal agencies must be

able to produce the standard DDL attribute description as recommended in Section 3.3.2 by the DDL Subcommittee of TG-24. (TG-24 took no position on the

standardization of data dictionaries but addressed

only those data dictionaries with an interface

between the data dictionaries 'and the DBMS which

must be standardized.)

2, The design of data dictionary must be capable of

combining standard data attribute descriptions with

data structure descriptions to generate the DDL for

one or more DBMS.

-26-
3. Establish guidelines on the data dictionary usage.

3.5.3 Justification.

++As sumpt i on

.

0 As databases continue to grow, the need to control

data elements descriptions will increase.

0 Data dictionary usage in the Federal agencies will

increase at a greater rate than the usage of DBMS

within the next 10 years.

0 DD will be a critically important tool used by data

base administrators for the central control of databases.

0 Distributed database management will enhance the

need of data dictionaries.

++ Benefits and Cost Avoidance .

0 A data dictionary which produces standard DDL will

reduce the cost of converting to the standard DDL.

0 The standard DDL produced by the DD to be interfaced

to DBMS will reduce the need for manual coding which

in turn will reduce errors.

0 There will be significant cost savings for transporting data for data interchange and for conversion purposes because a standard DDL would be generated from the data dictionary.

0 Data dictionaries will provide bridges to multiple

DBMS.

++Co_st_. The cost of implementing this recommendation will

be no more than the cost of implementing a data dictionary

that does not produce a non-standard DDL.

++Di scussions . Note that the recommendation proposed for

the data dictionary is to standardize the interface between

the DD and the DBMS. Compliance with this standard will permit the users of DBMS to use any data dictionary that has

implemented the standard interface at no further cost.

-27-
3.6 QUERY LANGUAGE/END USER FACILITIES

3.6.1 Background . There currently exists a tremendous variety of end user

facilities for DBMS, and a substantial variety of taxonomies

for these facilities. [LOUG 77]. Since many of these facilities are quickly learned, and many of them are designed for

ad hoc activity, standardization of syntax and semantics appears unwarranted. Substantial costs may be incurred by a poor match between the facilities needed, and those provided

by a procured DBMS. To avoid this, a match should be

achieved prior to procurement.

3.6.2 Recommendations .

1. Standardization of syntax and semantics of end-user

facilities is not required. Such facilities are

easily learned, problem and subject-matter dependent, and there are a diversity of end-user facility

"styles".

2. Guidelines should be developed to aid the specification of requirements of end-user facilities for

Federal procurement purposes.

3.6.3 Justification.

++As sumpt i ons .

1. End-user facilities will be the subject of intensive

investigation and rapid technical development, e.g.,

the role of intelligent terminals, is just beginning to emerge.

2. A variety of end-user facilities will be needed to

accommodate the different needs and user populations.

3. The problem of matching end-user facilities to requirements will continue to be difficult.

4. Programming effort will continue to be expanded to

improve end-user facilities where facilities are

inadequate or inconvenient for the user group.

-28-
++Benefits and Cost Avoidance.

1. The major benefit of the procurement guideline would

be improved utility of DBMS resulting from procurement of end-user facilities which best fit the needs

and abilities of all user groups which are to use

them

2. The major cost avoidance resulting from the guidelines is due to the decreased need for "customizing"

the end-user facilities, e.g., by programming new

facilities using host languages and the data manipulation language, or by enhancing existing facilities.

3. Usage of the guideline will aid the user primarily

during the procurement process. While not even an

approximate estimate of the number of likely DBMS

procurements can be made without a survey, one procurement error is likely to waste easily several

months time. Additional uses of the guideline would

be to guarantee retention of all existing functions

during conversions, to provide guidance in upgrading

existing facilities, and to assist database administrators in providing the appropriate tools to different user groups.

++Costs .

0 Development of the guideline should be relatively

inexpensive. Maximum use should be made of existing

studies and taxonomies of end-user facilities, and

also of past procurement efforts where lists of

specific requirements were used. A major part of

the development effort should be a follow-up on the

major procurements to check areas where experience

after procurement indicates facilities were lacking.

•i-+ Di sc us si on .

0 General comments. There are many examples of multiple DBMS in use by single organizations. A plausible explanation for this phenomenon is that the different DBMS provide different sets of end-user facilities which are so attractive to different user

groups that the costs of multiple DBMS are

outweighed by user convenience. It may well be that

multiple end-user facilities are in fact required.

It does not follow, of course, that multiple data

dictionaries, data definition languages, and data

manipulation functions are required - ideally different end-user facilities would make use of common

system parts. The guideline should therefore clearly indicate that procurement officers may best

-29-
satisfy their requirements by purchasing several

end-user facilities, from one or several vendors,

plus possibly developing in-house facilities if appropriate, all of which use the same interface to

other DBMS f acil ities.

Comments on first and second assumptions: A necessary and sufficient set of end-user facilities may

eventually be defined as a result of current

research. At that point, a standard for end-user

facilities should be developed. These do not appear

to be surveyable assumptions. The consensus of

TG-24 is that the assumptions will remain valid for

several years.

Comments on third and fourth assumptions: These assumptions have been informally verified by surveying

the experience of TG-24 members. A formal survey

might be appropriate to demonstrate more general

val i d i ty

.

Comments on

nomies of

presented i approaches

line. Th ey

herent in

It is worth

query facil

one half wa half wa s po

end-user facility taxonomy: Three taxoend-user facilities and user groups are

n Appendix 7. They demonstrate possible

which might form the basis of a guidealso demonstrate the

attempting to classify

noting that when TG-24

ities should contain update

s positive they should not,

sitive they should.

d i f f i cul ti es insuch a rich area,

was asked whether

capabil ities,

and the other

4. RECOMMENDATIONS FOR GUIDELINES

4.1 BACKGROUND

Several areas or activities associated with database

management systems do not easily lend themselves to strict

standardization. These activities are concerned with such

functions as the documentation of data base designs and implementations, ancillary operations performed in the database environment, and the establishment of database administration functions. This indicates the need for guidelines in

addition to whatever standards may be necessary. These

quidelines will treat subject matter that are, perhaps,

premature for standardization, or offer too diverse a choice

selection to permit hard and fast direction imposed

-30-
externally, or permit several equally good choices with no

particular Federa 1 -w i de benefit a'chieved by pointing to a pa rt i cul ar choice.

4.2 RECOMMENDATIONS

In addition to those guidelines recommended in the

specific subject areas above, TG-24 concluded that guidelines recommending standards of good practice were needed in

the following areas:

1. Computer security and privacy protection in database

systems

2. Procedures for database recovery, reorganization and

audit. At this time, no Federal guidelines exist. A

working panel report on database auditing [BERG 75]

suggests the need for such a guideline. A group of

audit experts [RUTH 77], supports this point, and

discusses general audit administration, methodology

and tools. While database recovery and reorganization procedures may be too DBMS-specific for inclusion into Federal guidelines, development of general

guidelines or checklists may be possible.

3. Documentation - Currently FIPS Pub 38, "Guidelines

for Documentation of Computer Programs and Automated Data Systems" contains guidelines for the

description of database specifications. These guidelines describe the database specification for a database to be developed during the design stage of

the development phase of the software life cycle.

Guidelines will also be necessary for the documentation of the implemented database, i.e., after it is

developed, tested, and loaded. This would be analogous to the separate guidelines that exist for the

program specification and the program maintenance

manual. The "Database Management Manual" might

describe the database in its final, implemented

form, and all common validation routines, recovery

utilities, reorganization criteria and utilities,

database administration support software, etc.

4. Performance monitoring - An important start has been

made in this area with the issue of FIPS PUB 49,

"Guideline on Computer Performance Management," in

May 1977. In the context of database management.

-31-
guidelines could be developed for the monitoring of

database growth and performance, general criteria

for reorganization, database (re)design hints, etc.

DBMS evaluation and selection - FIPS guidelines on

several activities in the

analysis/evaluation/selection cycle would greatly

assist Federal DP managers considering the database

approach

a. Analysis of existing ("conventional") data processing applications or potential applications (not

yet automated) for implementation under database

t echnol ogy

;

b. Methods for the comparison of available DBMS

packages against application requirements and selection of best candid at e(s);

c. Documentation practices for these activities,

d. Preparation of Request for Procurements - a need

particularly noted by several managers that offered

their comments to the Task Group, and;

e. Methods for benchmarking DBMS as a means to aid

in evaluation of the responses to the Request for

Procurement

.

Database administration functions - Several existing

publications from various sources could provide the

basis for a FIPS guideline for the determination of

the functional duties of Federal database administration staffs.

Requirements analysis - Little guidance now exists

to assist Federal managers in preparing a -good

statement of their needs prior to seeking tools to

meet these needs. Federal managers, particularly in

the numerous smaller agencies, need such help.

-32-
4.3 JUSTIFICATION

4. 3. 1 Assumpti ons.

0 Useful guidelines can be compiled from existing material on good information practices.

4.3.2 Benefits and Cost Avoidance.

0 Guidelines can provide Federal agencies with approved practices drawn from industry experience and

tailored to the special needs of Federal agencies.

Examples of the special needs of Federal agencies

include: procurement practices determined by regulations, statutory constraints of data processing action, and affirmative action programs with regard to

i nf ormat i on pol i cy

0 Guidelines can be maintained and modified to reflect

Federal experience with them so that each agency can

profit from the collective experience.

4.3.3 Costs . Costs associated with guidelines are the direct

cost of compiling and reporting recommended standards of

practice as well as that work needed to develop and test

practices not available from industry sources. In addition,

cost will be experienced in follow-up and verification of

published guidelines.

-33-
5. MISCELLANEOUS RECOMMENDATIONS

5.1 REDUCING STANDARD ADOPTION COSTS

5.1.1 Background

.

To force the adoption of the standards

recommended in this report universally and on a certain date

could result in unnecessary expense to Federal agencies.

Under such a requirement, conversion costs would occur in

the training of personnel, the conversion of existing databases, and the translation of existing application programs.

A less concrete cost would be the loss of productivity experienced by the agency during this period. These costs can

be reduced and even eliminated by judicious timing of standard installation.

5.1.2 Recommendations.

1. The standards recommended should not be mandatory

until other factors determine a change to the

rel evant systems

.

2. Standards can be required for new applications or

systems without requiring existing systems to also

conform to the standard.

5.1.3 Justification.

++As sumpt i on

s

.

1. During a conversion to new systems requiring changes

to programs and data, the use of standard products

adds no additional costs to the conversion process.

2. New applications can be written in the standard product at little or no additional costs. Costs associated with maintaining two concurrent systems will be

low and offset by reduction in conversion costs to

move to the standard system when other system

changes result in rewriting the existing programs

-34-
and converting the existing databases.

3. Incremental installation of standards will be feasi

ble.

++Benefits and Cost Avoidance.

These recommendations will reduce conversion costs.

5.2 DATABASE STANDARDS IN OTHER MAJOR AREAS

5.2.1 Background. TG-24 considered certain other areas where

database systems were major considerations. These were database systems provided by computer processing services

(whether in batch or in the time sharing environment), distributed data processing or distributed data bases, and the

mini/micro computer. TG-24 treated these issues only to the

extent that it could conclude that the basic recommendations

would apply to these systems as well.

5.2.2 Recommendation. TG-24 recommends that the database

standards actions described above apply to data base facilities provided by computer services, distributed systems, and

mi n i computers

5.2.3 Justification . ++As sumpt i on s . The assumptions for these recommendations

flow from the recommendations of each of the detailed standard recommendations. TG-24 assumes no significant differences will be required for each of the subject areas.

+ +Benefits and Cost Avoidance . Applying the same standards

described previously to the database systems provided by

computer processing services, to distributed systems, or to

minicomputers will enhance the database work done in any of

the other areas. It will insure the broadest possible sharing of people, programs, and data. Expanding the area of

standards application will provide a greater payback for the

costs expended in developing standards. Minicomputers, particularly, will benefit from the central discipline exerted

by standards in view of their anticipated growth, diversity

of vendors , and the lack of a common operating system discipline. Distributed systems, especially combining heterogeneous systems, will still have the conversion problem

-35-
between different systems but eased somewhat by the common

standards shared by all the different systems.

++Co St s , Cost associated with standard systems will not be

d i f f e rent than that of non-standard systems. Conversion

costs can be reduced by proper timing of standards usage.

5.3 TRANSITIONAL STANDARDS ACTIONS

5.3.1 Background . TG-24 recognized the timeframe of the many

actions i m p 1 i e d by its recommendations and recommends actions for transitional periods. Development of standard

specifications may take as long as two years with another

year after that for the implementation of a standard product. Standard products will remain merely an assertion of

the vendor until validation procedures are available. What

actions should Federal agencies take until a fully validated

standard product is available?

The question suggests the existence of three time

pe r i od s

1. Until a specification is published.

2. From publication of the specification to its commercial avai 1 abi 1 i ty .

3. From commercial availability to validation.

These periods of time will hold for each specification

resulting from these recommendations. For example, the network DML and relational DML will have two distinct development paths which need not necessarily be concurrent. In addition, vendors may choose to combine step 2 and 3 by withholding a product until it has been validated.

5.3.2 Recommendations. TG-24 recommends the following positions for Federal agencies:

1. Prior to the development of standard specifications

for a Data Description Language, Federal agencies

can prepare for standardization within their own organization by using systems having a Data

-36-
Description Language similar to the CODASYL

1 anguage.

2. In time period 1, select DBMS systems having independent Data Description Languages which describe

data attributes similar to the CODASYL specifications.

3. In time period 2, require database systems under

procurement to meet the standard specification of

the Data Description Language and those standard

Data Manipulation Language specifications which are

appropriate for its application. For existing database systems, solicit translators from the existing

system to the standard systems. Document existing

systems using the standard specifications. Require

Data Dictionary Systems and End User Facilities to

meet the standard interface requirements.

4. In time period 3, require all new applications and

procurements to use the standard systems.

5.4 PRIORITIES WITHIN THE RECOMMENDATIONS

5. 4. 1 Background

Technical interrelations of the recommended family of database standards and payback considerations

argue for establishing priorities in the development of the

recommended standards. These priorities are reflected by

the phasing recommended below.

5.4.2 Phasing Recommendations.

+ +Phase 1

Develop specification for the common attribute

part of the two part data description language standard as

described in Section 3.3.2.

++ Phase 2. Develop specification of the structural description for data structure classes as described in Section

3 • 3 • 3 •

-37-
++ Phase 3.

0 Develop specification for each data manipulation

language.

0 Develop guidelines for using the data description

language specification.

0 Specify interface requirements for data dictionaries

and end-user facilities.

5.4.3 Justification.

++Di scussi on . In preparing these phasing recommendations

J(j^ notes that the network category has progressed further

through these phases than the others. However, the recommendations are stated to avoid implying a preference for, or

the inherent superiority of, the network category.

-38-
6. REFERENCES FOR TG-24 REPORT

GENERAL

[BROC 74] Brock, Gerald W., "The U^._S. Computer Industry - A

Study of Ma rket Power " Ballinger Publishing Company,

Cambridge, Mass. 19/4.

[CODA 76] CODASYL System Committee, "Selection and Acquisition of DBMS," available from ACM, 1133 Avenue of the

Americas, New York, New York, 10036, March 1976.

[CODD 71] Codd, E.F., "A Data Base Sublanguage Founded on the Relational Calculus," IBM Research Report, July,

1971, pp. 48.

[CODD 71b] Codd, E.F., "Further Normalization of the Data

Base Relational Model," IBM Research Report, August

1971, pp.33.

[CODD 72] Codd, E.F., "Relational Completeness of Data Base

Sublanguage," IBM Research Report, March 1972, pp.36.

[COMM 77] The Commission on Federal Paper Work, "The Federal

Information Locator Systems," July 1977, U.S. Government Printing Office.

[DATE 75] Date, C. J., An I n t roduc t i on to Data Ba se Systems , Addison Wesley PubTTshing Company ,~T9/ b

[GAO 77] General Accounting Office, "Millions in Savings

Possible in Converting Programs From One Computer to

Another," Report to the Congress, Sept 15, 1977.

[IDC 77] International Data Corp., "360/370 Migration - 1977" A research report prepared by International Data

Corporation, 214 Third Avenue, Waltham, Mass. 02154,

July 1977.

[MART 76] Martin, James, Principles of Data - Base Management , Prentice Hall, Inc., Englewood Cliffs, New Jersey,

1 976 . [MART 77] Martin, James, Computer Da ta - Ba se Organizations , 2nd Edition, Prentice-Hall, Inc., Englewood Cliffs, New

Jersey, 1977.

[RUTH 77] Ruthberg, Z. G. & R. G. McKenzie (Eds.) " Aud it and

Evaluation of Computer Securi ty , " National Bureau of

-39-
standards Special Publication 500-19, Oct. 1977.

[SENK 73] Senko, M.E., E.B. Altman, et al., "Data Structures

and Accessing in Data-Base Systems," IBM System Journal, Vol 12, No. 1, 1973, pp. 30-93.

[SIBL 76] Sibley, Edgar H. " Comput i n g Su rveys : Special Issue

on Database Management Systems " ACM , Computing Surveys,

T^l. 8, No. 1, March 1976.

STANDARDS RELATED

[ANSI 75] ANSI/X3/SPARC DBMS Study Group, "Interim Report on

Data Base Management Systems," Feb. 1975.

[BERG 75] Berg, John L. (Editor), "Data Base Directions - The Next Step" Proceedings of the Workshop of NBS and

ACM held at Ft. Lauderdale, Florida, Oct. 29-31, 1975,

National Bureau of Standards, ICST Special Publication

No. 451.

[BERG 78] Berg, John L. (Editor), "Data Base Directions - The Conversion Problems" to be published as National

Bureau of Standards, ICST Special Publication, 1979.

[CODA 69] CODASYL Data Base Task Group, "DBTG Report" Oct.

1969 (superseded by 1971 DBTG Report).

[CODA 71] CODASYL Data Base Task Group, "DBTG Report" April

1971, Available from ACM, 1133 Avenue of the Americas,

New York, N.Y. 10036.

[SIBL 77] Sibley, Edgar H. "Standardization and Database

Systems," IFSM TR No. 23, University of Maryland, also

published in Proceedings of the Th i rd International

Conference on Very La rge Data Bases , Oct. 1 977 . [TSIC 77] Tsichritzis, D. & Klug, A. " ANS I /X 3/S PARC DBMS

Framework" University of Toronto, Computer Systems

Research Group, Technical Note 12, July 1977.

COST BENEFIT

[TG-5 77] Task Group 5 members, "Quantitative Methodology

for Assessing the Economic Impact of Federal Information Processing Standards" Task Team Recommendations,

March 21, 1977.

[TG23 77] Task Group 23 members, "Preliminary Report of the

Economic Analysis Study Group for MUMPS" Task Group 23,

-40-
July 26, 1977.

TERMINOLOGY

[ANSI 77] American National Standards Committee X3 - Computers and Information Processing, " Ameri can Nat i onal

Dictionary for Information Processing"^ F IPS PUB 11-1,

Nat i onal Bureau of Standards, Sept. r97 7 .

DATA DICTIONARY

[BRIT 77] British Computer Society, "Data Dictionary Systems

Working Party Report," available from The British Computer Society, 29, Portland Place, London, WIN 4HU, United Kingdom, March 1977.

[CANN 74] Canning, Richard G., "The Data

Dictionary/Directory Function" EDP Analyzer , vol 12,

no. 11, November 1974.

[LEFK 77] Lefkovits, Henry C. "Data Dictionary Systems,"

Q.E.D. Information Sciences Inc. Wellesley, Mass.,

02181, 1977.

[LEON 77] Leong-Hong, Belkis & Beatrice Marron, "Technical

Profile of Seven Data Element Dictionary/Directory Systems" National Bureau of Standards Special Publication

500-3, February 1977.

[PLAG 72] Plagman, B. K. & G. P. Altschuler, "A Data

Dictionary/Directory System Within the Context of an

Integrated Corporate Data Base" Fall Joint Computer

Conference Proceedings, 1972, pp. 1133-1140.

[PLAG 77a] Plagman, B. K. "Data Dictionary/Directory System:

A Tool for Data Administration and Control" Auerbach

I n f ormat i on Ma na gement Series - Data Base Management , No. 22-01-02 , Auerbach Publ i sherTTnc . , 6560 North Park

Drive, Pennsauken, N. J. 08109, 1977.

[PLAG 77] Plagman, B. K. "Criteria for the Selection of Data

Dictionary/Directory Systems," distributed at the Symposium on Management of Data Elements in Information

Processing at National Bureau of Standards, September

1 977 . [UHRO 73] Uhrowczik, P. P. "Data Dictionary/Directories,"

IBM Systems Journal , vol 12, no. 4 1973, pp. 332-350.

DATA DESCRIPTION FACILITIES

[CODA 74] CODASYL Data Description Language Committee,

-41-
"CODASYL Data Description Language Journal of Development," National Bureau of Standards Handbook, 113, Jan.

1974.

[CODA 78] CODASYL Data Description Language Committee, "CODASYL Data Description Language Journal of Development," January 1978.

[CCA 76] Computer Corporation of America, "Data Descriptor

Study," Final Report Contract DAAB-3-75-C-0464, August

16, 1976.

DATA MANIPULATION FACILITIES

[KERS 76] Kerschberg, L., Klug, A., & Tsichritzis, D. , "A

Taxonomy of Data Models." University of Toronto Technical Report CSRG-70, May 1976.

[THUR 77] Thurber, Kenneth J. & Patton, Peter J., "Data

Structures and Computer Architecture" Lexington Books,

DC Heath & Company, Lexington, Mass. copyright 1977.

END-USER FACILITIES

[LOUG 77] Lough, Dennis Elliot and Burns, Allen Dale, "An

Analysis of Data Base Query Languages" NTIS ADA039783,

March 1977.

-42-
7. APPENDICES

7.1 APPENDIX 1 - FIPS TASK GROUP 24 CHARTER

.DATABASE MANAGEMENT SYSTEMS (DBMS)

++ Purpose . To make recommendations within one year to NBS

and the FIPS Coordinating and Advisory Committee on the need

for Federal database management system standards and any appropriate standards activities to meet such needs.

++ Scope . The task group will consider all areas within

current data base technology with a view towards defining

relationships between DBMS and existing FIPS activities and

a more precise statement of the scope for recommended standards activities. The area of study will include: distributed processing and databases, networking, data description

languages, data manipulation languages, data

d i ct i onary/ d i rectory functions, DBMS support functions, and

the role of mini-micro computers in DBMS.

++ Program of Work .

1. Determine the Federal need for DBMS standards. Consider Federal DBMS standards in such technical areas

as DDL-DML, minicomputers and networking.

2. Survey existing DBMS models, determine the relative

merits to the Federal agencies of the various

models, and collect formal specifications.

3. Prioritize the various model specifications for detailed St udy

For such model specification selected for detailed

study, survey existing implementations and review to

what extent each model specification feature was, in

fact, implemented.

For each model specification selected for detailed

study, make a formal recommendation for Federal action.

-43-
7.2 APPENDIX 2 - DBMS USAGE SURVEY FOR TG 24

BACKGROUND

An informal survey of DBMS usage was initiated at the

first TG 24 meeting on March 15, 1977. All participants of

TG 24 were asked to survey their own agency in the use of

DBMS. The purpose of this informal survey was to gather

preliminary data to substantiate the need for DBMS standards. In particular, the survey attempted to find out:

0 Whether Federal agencies are heavily committed

to the use of DBMS.

0 If DBMS are used, how are they being used.

0 Whether TG 24 should conduct a formal survey

on DBMS usage in order to assess the effect of

a DBMS standard with respect to current operations.

The requested information for the informal survey follows:

0 Names of DBMS used within the agency. For each

DBMS the following should be addressed:

0 Type of application

0 Type of usage

0 Kind of user

0 Type of support of central facility

0 Data interchange

It was also agreed that a software system is a Data Base

Management System if it possesses all of the following propert i es

0 It is an integrated set of computer procedures

0 It facilitates usage of data

0 It facilitates storage and maintenance of

large amounts of data

0 It provides frequently used shared functions

0 It potentially serves many functional purposes.

-44-
SURVEY RESULTS

Su r vey Population

14 Agencies responded with the DBMS usage survey.

These are as follows:

1. Agriculture

2 . Air Fo rce

3. Army

4. Central Intelligence Agency

5. Defense Intelligence Agency

6. Federal Energy Administration

7. Federal Home Loan Bank Board

8. General Services Administration

9. Health, Education, and Welfare

10. National Bureau of Standards

11. National Security Agency

12. Office of Management and Budget

13. Pension Benefit Guarantee Corporation

14. Veterans Administration

Detailed data collected from each Agency is tabulated

in Table 1. Summary data is presented below:

Numbers of DBMS In Use Within Agencies

1 agency (FHLBB) has no DBMS at present.

1 agency (NSA) has 14 DBMS in use.

The remaining agencies have 1 or more DBMS. The conclusion

from this fact is that most of the agencies are using DBMS

and some agencies use more than one DBMS.

In - House Written Versus Commerc i al Packages

Among 57 distinct DBMS in use in the survey population,

17 were in-house written. 6 were developed by the Air

Force, 5 were developed by NSA. Roughly 75% of DBMS in use

were commercial package.

Characteristics of In - House Written DBMS

Two in-house written systems are used for document retrieval. The remaining in-house written DBMS are built for

intelligence military applications. Real-time processing

with some on-line and batch usage is typical of the in-house

-45-
written systems.

Commerc i a1 DBMS Packages Pi stribution

(a) Host-Language Type systems - These include Codasyllike systems but not necessarily Codasyl syntax. Systems

include DMS-1100, TOTAL, DMS-II (Burroughs), DBMS-10,

DBMS-11, IDMS. 7 agencies (Army, VA , Air Force, HEW/SSA,

0MB, NBS, NSA) have these systems.

(b) System 2000 - 4 agencies (Army, Air Force, HEW/NIH,

Agriculture) use this system.

(c) IMS - 2 agencies (Air Force, DHEW) use this system.

(d) Report Writers - 2 report writers (Mark IV,

Easytrieve) are used by 2 agencies (Agriculture, NIH).

(e) Bibliographic systems

(CAIN, BASIS, 2 in-house written)

popul at ion.

4 bibliographic systems

are used among the survey

(f) Hardware supporting only one DBMS system - 2 DBMS can

be classified as the sole DBMS operational for the hardware:

IMAGE 3000 on Hewlett Packard, and DMS-II on Burroughs.

(g) Time-Sharing Service - 3 agencies (Army, GSA, Agriculture) use the CSC Infonet Time-sharing service which has

System 2000, DML and Aladin. The Pension Benefit Guarantee

Corporation uses Compu-Serv time-sharing service which has

System 1022.

(h) Early generation DBMS systems - 5 early generation

systems are used among the survey population. These are

FFS, NIPS, IDS-I, MARS and MARK III. Users were system programmers and the usage is batch for report generation purposes.

(i) Research systems - 1 system INGRESS which is a relational DBMS developed by University of California, Berkeley,

is used by 2 agencies (NBS, NSA). Usage is experimental

research oriented and no production applications have been

developed. The Army is using UNIBASE written in ANS Cobol

74 for research in DBMS portability.

Usage and Users

(a) For Host-language and CODASYL-like systems, the usage

is predominantly batch, transaction-oriented and used mostly

to produce reports. Users were either subject-matter specialist or clerks for invoking a pre-defined transaction and

system programmers for coding transactions.

-46-
(b) For systems such as System 2000, ADABAS, 1022, GIMII, usage is predominantly on-line querying and updating.

(c) The majority of the users of DBMS are reported to be

subject-matter specialists with programmers doing the system

interface type of task.

(d) Agriculture has an experience with self-imposed standards. System 2000 at Agriculture has about 28 applications. Some are small applications with less than 100

records. The other DBMS in use at Agriculture are IMAGE-3000, Infonet DML and in-house written ones. Forestry

uses FS-GIM. This might be due to the agency imposed standard DBMS practice to define all applications using one

DBMS.

(e) In two cases (Army and NSA), DBMS-11 is being used experimentally as a back-end to a host computer 370/158.

-47-
<u (U -k) 1 c c u 0) H •rt 0) u

-( r-( -n 1 ^ • c C 3 (V Ul o 0 Ul o Ul (11 3 Q) Ul a jJ (0 •H c >, • 0) o (0 o

nj XI (fl 4J

u 'O

a

0) jJ (0

a

a 3

•o • 3 m 1 <o a Ul Ul >1

ij 1 10 > 1) r-l 3 0) >, rH c

<D 1 3 4)

W <0 4J rHM -H

in 1 -H 3 -H >i n> (0 <u 4J D 1 u o r-i O 0) <u )J 1 O M a a s 0

t3 1 0) Q. 0) 3 3 1 a C 1 O rH 01

(0 1 c 01 0) J3

u 1 r-t c • c c c

01 1 u

O JJ d) •H Ul •H •H x: x: x: •H J= JZ

cn 1 o o rH 4J rH r-i o u o 0 l-t 0 U 0

<0 1 •i—i 1 !-> 1 u 1 1 JJ JJ 4J jj 1 jj JJ JJ

U) 1 (tj

a Q. (0 (0 c o c c 10 (0 10 10 c (0 10 (0 s (0 3 E CO O Oi O o CQ (9 ca 03 0 CQ (Q 1 rH • Ul 1 1 1 •H rH 0) e <a n CO iH ro Ul •H g •H >1 • a s <o 10 ;j •a • Ul Ul Cu in m rH • o 01

<GO e e «

0) c •o JJ jJ >1 *j •H c JJ c w

Ul )-l (0 >1 Ul 10 Ul 01 >1 3 Q OJ >i >i e 0) 0 > -H w >. Ul c

•H 0) c x: rH •H J.'

O 1 4J e o> o jj <0 c a 1 IB (0 0) c u 04 c JJ 0) ^! > e g D •r4 <0 3 <u JJ g o •H C 0) u B 10 01 0

in Ul • 4J -H Ul (0 0) 01 rl

C 1 cs Ul o 0) 01 cn 10

W 0 1 in W Ul cu rH u c • 10 JJ c 0. M ^ 1 c <u <v (0 rH 0 c c c 10 10 jj 1 10 01 i-l o a w 01 •H 0 (0 (U g u

(0 1 Ul 10 (0 c JJ JJ -H e e ai O 1 4J C JQ •r-( rH e 4J 4J c c 0 JJ 01 »J 0 8

•H 1 O

u 01 (U 01u o OJ . 3 3 i) 01 • <!) •H < r^ 1 0) •H (0 -H u -u Di o Ul u c tJ XI a> as Ul jO rH a 1 iJ 4J 4-1 3 Ul "O W 0 0 -H c c e e XI < a 1 o (0 ffl «-< ^ >1 3 X a; 3 ^ ^ 10 10 0> •H •rj w < 1 s O CQ 01 CQ u 04 U JJ Oi JJ « s: jJ Eh CQ

0)g I (0 I Z II >1 

U I C I 0> I Di I < II S O

CQu< w M rH 0) 0 M > > M CO 00 00

M s rH c 0 M * 0 0 0

CO 0 0 z Z rH iH rJ 00 Q >tH ro Z) rH rH rH

0) 1 c < c c i IH 1 0 > M a< c c c 0 CO

u < c

10 1 M

X 0 0 0 M < 0 0

rH 3 1 00 > rTl 1 0 c « M H IH ro CO

td

U 1 0 0 rH 0 JJ JJ

u IH z z S

(0 1 0 T3 0 rH 01 01 01 01 00 !3

X OQ

m

B 1 0 C 0 0 K c c JJ JJ vo OQ 01

a < 1 (M 10 CM U 0 Eh 0 0 JJ .t;< c C c M >

Eh •0 1 0 a: >u <IH •H 0 0 0 0) JJ C 1 CO n 0 00 c c U 00 u 0 c H CO rH

10 i E VD

g

MM 3 \£) ^ s 0 •H 1 01 z u wu e\ Jj< 1 ro M M ^< 3

to 1 2< JJ 5 0 00 CO

u C5 0 z jQ S 1 Ul 0 01 < cs 0 J 0 J 0 0) 0 0) £ 1 HI Ul 0

ca 1 >iC 0 r- 01 t~ Ul OQ CO CO CO < (0 r- 0)

Q 1 Wm 10 0 IH U,

m

Q rH

Q rH 0 ro

D

M Cli

u

W ro 01

-1oIcm

0) 4Ju

•Hc

-48-
d) to

M

H 1 'O 'O 1 Vj

V Ul

r ) rtt r" « VI/ 0 0) 0) CO "H io ^ >n< /ft m

rA rn UJ (Q wj fO to JJ 3 »H 0 D 4J D to JJ

At

rn ^ B

to ^ to 03 (0 '»% W ^ B 'D 4_ UJ 'r-l to g

\J d^ ^ d) ^ 0 Jj '"H rH

Ql 4J d) (0 fO J_l Li (11

m c 0

(0

C 4-} 3 'H "1J iTT lU rtl

B •^J UJ d) • 0 u 0 -Q JJ G CJ

"^J 4J • CC d) d) 3 Jj J-* c u D *r~i jj to Tj C 0 01 1 4—' u ) yj UJ to "H C 01 CJ "O

(0 1 VO 0 03 •H J3 1 *}^ 4J ^ ^ to • 4J ^ ^

CD 1 0 ^ C -J d) UJ • M UJ 0 c to U) 1 I £ d> w. w ^ C 0 0 1 > 1 to D 1 C -H (0 d) -4-> •H 0 CU JJ c to 1 0 ^4 D x: JJ D 05 «H 0 a> E 0) a 0 JJ •O 1 -H U 0 CT 4J 'U to CT e 1 cN d) e to to U) C 1 4J 0) d) rH C 1 JJ 4J (0 to •H

<0 1 Qj ni

m 1 

y l-M U/ UJ

U

g JJ rH 1 (0 J3 Q C 3 nt u 0 ^ g to to d* 1 f— <—

0) 3 W rti w 1 1 u c 10 c

T* r'/T

u

C \J rH

u

(0 1 J

J (0 0 Q) 1 JJ

B vJ ^ JJ JD 03 (0 0)

to 1 fO

u >, c liirt UJ p»y di "v. ""i Lri ~J >1-H 0

t—

/-V JU E-t ja

— JJ to to UJ 'U .U UJ « JJ X}

u to

CO

B rH 1 U 1 k-i 1 1 1 1 1 nil c 1 1 1 1 1 lU 1 n 0) c 0 (J B " (J vj W W VU c

/ft 1 1 C JJ rH

C Di 0) yi

U »o •H

C VJ "rH

W 0)

i_i CO 01 -r-i Oi 0 nJ "3 1 1 ^ (0 0 0. j_j —J j J ^ j_) »^ e

>1G Cu S to

u d)

r t u_i (Tir i 0)

w to dJ to 0 fO fO

D

w , 1 Q fO Dl 4J Ul 0 u (0 £ to £ fO vj UJ J >J 0 (D IJH Ml (0 X! fO d) c c (0 M c g (1! 1—1 d) M 0 ^ 1^ (0 nj - >j

?i rtt

VJ-i VJ

M to d> s u

0/ • e 0 0 U J-"

C ^ w QJ - '"^ JJ 0 u 1 (1) C «-l 0) c r\U Ijw V4 U £ ^ JJ ^ U to JJ * c to

Q) 1 H •r-1 0 0 c c c c dJ 3 to JJ 0 B (0 A. 1 (0 C) JJ - 0 e ^ rnTj 0 dJ 0 ""H C 'rH (\i It 1 >i c c U 0) ^ ^

jj

tr" 1 4J

D 0 jj 0 4J 0 to

U 01 1 •f-i >^ >J 0 -H D rH

C 1 10 cn 0) 0 -u - u 0 d) -H 4J to fO d) D^-rH to 0 a 0 1 (0 (Q CU U (0 en 0 u dj 0 • •H C iH (0 0 ^ 1 Vj 0 "3 U c u c - JJ C 4J —

c to C JJ C CT iH 01 4J 1 4J U -P H 0) c fO c 0 CT £ 0 to C *H W 03 U d} Cu 1 r-1 ^ CO (iiH CO

In

r\

C c ^U r-1r /tl

B /Tl UJ 'O

C

r 1 1 (0

D d) 0

J—w

•H 1 Jj "H c u c " ?*t ^ dJ 0 rH rH 1 H U 0) -U C 4-* J-* fO jJ nJ 0 to t!J 0) B <a c e u x: c jC to 4-' 4 * C C -C CT* 0 JJ JJ O. 1 H u o> U C Q) Q) rtt ni fll 'U »U w ^ flW C fll UJ frt 'U d) 0 H

Cli Oh (tJ 10 6 to (0

B *^1 UJ ~ 1 1 (J

B E-t

GO

w 1 c •DC uJ t <£< 1 

JJ c

rtw

C 0 4-) 0 d)

u cu r* c 0

,0

MM d) ^3 0) (0 < 0 ^ U fO B w e ^ 0

d) 0)

W -H

d) £ to 1 CP

g IJ

fli 1

li' CO ^ u a> d) d) •0 1 0> 0) %4 1 U 4J c mj c JJ t/T

(Tt t •Ci 0 u ^ to

w iTt 10 % 1 UJ vj 1*4 >, 1 >iO >c UJ >nO

rnU 1 M

HJ

m

r 1 "E*

w

Q

w 0

Li 1 _j 11 Q 0

(Q 1 c M GO -H

u s 0 JJ ^ 0 c\o

X 1 0 < ffl 0 <0

M

u 0 1 w 4J S C rH *J 0 Q H 0 -H rH

•D 1 M

— 0) --1

C CM 1 JJ rH

C 1 M « Q e <u a> 1 (0 0) fO 1 M w 0 * 0) s * na B w e 1 a 0 CO CT> >i c d) M d) «

CO 1 ij 01 in s <o 0) S 01 0 JJ 1 JJ 0 01 T, 1 0 C ro Q C C Q CO CO to l-H MH C

OQ 1 fa -H 1 S 10 0 M 01 ^ >1 S s C 0 O 1 < 5 < t-i CQ S s: s £ -O r-t CO 0 CO Cu M X

01 1 e 1 (0 1 «

2: 1 u 1 >1 

u t £ C 1 0) 1 a> 1 •H < 1 <:

-49-
1 u x: 4-> 1 10 to 1 1 >i 10 CU 01 4-1 cri >J-i -rt 4J QJ X g JD 4-> D 4-1 •r-l C (13 rH lO )J QJ (0 to JJ •'^ i4 4J U Oj 3 >i a> c e k >J (0 CTja 0

(0

O -H QJ )J QJ

C

-y 10

a It) UH Sj Dj to to >i u c 0 Q) 3 U 0) 0 1-1 10 to <D -n •H u U) QJ 3 Z rH a i3 4J <u u

r. ^

QJ 1 CP 3 u x: QJ Q) C (0 — « tJ> c m 1 (0 to CJ c e 0 to CPEh c c U 1 U w 4J -r* 6 •H D C 05 •n 0

q; I O >i c 4J -no 4-> to W 1 J3 • fO XI XI c U g tt, u u D 1 1 n QJ cn 3 x: g 0 OJ • 1 "O -U 4J o tJ u ta Oi Cb Ifl X> 1 (0 (U 10 Q) (0 i-l QJ 10 M QJ ^4 C I U3 -H > u a, QJ 0^ QJ u o n 1 (1) D rH •rl -rl 0 U 4J 4-) 1 C fO c w c c M c

0) 1 • H .» -H •H

C (0 0 x: QJ Oi QJ • x: 0 g

cn 1 rH 0)

O rH QJ Ti x; -H

U SJ -rH toU

d 0

(0 1 1 4J QJ 1 -U QJ

U 4J 4J Q) 3 >J >H 4J ai4J

W 1 c to a. c XW Q) to fO QJ QJ QJ to 3 3 D o 'a fi o QJ D g u m 3 c a e CQ to to

OJ 4-)

g c 1 D> C 3 o o U 0) iH • r-l 10 c U o u

jJ •r^ •H <u -MM 4J rH c

4J

U

m rH 0 C D 4.) 0 -H

0)

U c u JJ 1 E - 0) « 1 0) rH g N

Q) 1 cn 0 a •rH & 1 (0 U u m rH ' C -u 0 H

fn 1 (0 c 'D (0 • 4J 1 e 0 to 3 C 1 u - • 0) •H 0 1 o to -H 1 u Cue c >1 >1

jj 1 0 -H a) IB

U rH QJ tjl (Q 1 4J 4-1 ij g c P (0 o c U 1 (C U U 0) 0) 0) c

••-1 1 M 0) tfl e <o 3 4J

r-l 1 0 -r-i

C nj c OJ 0 c

Cu 1 i3 0 <0

C •H rH -O to 3

nj >-iu iTJ (0 OJ c QJ 0 < J a 4J g s: Eh 10 CC U 1 - c c c <u (0 iH X 0) 0 o 0 rH 4J rH U IH -rH iH (0 0) D 4J b

4J

g -ran s o QJ

0) 1 (1) Z 4J QJ VDC

U 1 rH Ul 0 4J ro QJ

O

(0 1 •H >, I4H 0} 01 4J ac 3 1 4J CO c >1 tJ s (0 1 M w P 03

>^ 1 W X3 >i •"^ 10

H CTi "3 1 s 0)

C (0 S 1 Q) H) )H C 4-1 0 fl) > D c o o C 'H 1 ^ 0) o Q) b M !h C 1 > \o g o QJ

(0 1 « -r) (U t~ QJ r~- ^ to 05 W 4J M QJ W 1 D to (0 (0 +» t U O S 1 z a> s to C £ CO to CO 0 O m 1 U U QjCQ s (0 CO Q -U O Q 1 > ttD M M S M b CO M CO VO

QJ I g I to 1 z II >. I u I C I OJ I cn I < I a I QJ rH

to ro 3 -H

CJ • • • •

QJ 0) OJ - a o» D> CP cn

OJ to 10 10 (0 10 4J (0 to u (0

to

u s 3 3 3

OJ a-u jC J3 x: 3 4J c; u CJ o \ to p p • 4J 4J >l g ro to QJ 10 (0 X) X5 n ja

QJ to 3 +J a •D to •n -o cr CJ c C 3 c c

0) 10 ro ro (0

•r-> 0) QJ X} 0) OJ c 0) OJ C 3 c C •r( C c H to • •H -iH rH •H

rH to rH rH 1 rH rH 1 4J 1 1 c« 1 1 C >i to c c o c c o ja o o o o 1 1 1 >1 1 rH .H 1 T3

ro 0) -H 4J

C 0 OJ • SjC 0 O CJi to OJ . -rH U • C ID QJ to •H (0 -rH 4H to 4J rH C g a

rH

C 3 10 c c to 0 m rH >1

a ro cr to

O to 0 > to

u - to ^4

a

g •H QJ

U QJ

U cn 4J -H 0

ro to 4J

a rl QJ o C Sh -U

4J - (0

u

a

u QJ QJC

U -U CJ 4.)C 4-1

a

g 4J QJ

to QJ tt! QJ -H ro OJ 01 10 > 3 -r-ii-' CT>rH c u - -C cng c 0 0 to TJ a 0 -a g u ro •rH •H -o 3 a n C to 0) M C - M a X! (0 4.J ro 4J 4J <0 to g TJ

lO to

g to to QJ Z QJ

C > X - to CJ g >«( to g CJ^ 4J CJ •rH 0 to QJ g to 0 3 C -H rH U • rH U 10 >i - o Vj 0 QJ x: a to to Oi Ih to to tn MH ih g a a c o C - CJi to

'-^ QJ 10 ro CP 0 H •H 10 0 QJ 4J u u C -H u 4-1 £ M rH C

to 3 CT> TJ •'^ 4J 0 QJ QJ Ol OJ -rH • ^4 C 4J C O OJ > u •p CT 4-> C TJ to

QJ 0 C

O o X rH

C to T3 to

Q

C to

g > -H QJ -H )H C •rH 0 3 •H 3 >, '•a 0 QJ 10 O 4J g 4J <0 S. > HJ, 3S ca (0 05 to JJ TJ c >, c rH CO 0 X3 0 4J rH o < Q

•r4 OJ 0) rH > u

4J c rH

M

10 QJ rH 0 Z T3 g a to MH u S C u 0 u c c o 10 0 rH 4J H 0 o >

ItH OJ

C s M

CO

C > QJ (3S Z 0 M QJ CJ 0) o " -D CP r-l ro ^ C (0 H c O

10 c 0 QJ

u 0 O S - 4J ro O •H O QQ

•H ^ (0

u c o CM

M Z rH Q o \> * QJ 0 o

td ID t~-

C

M CO CO rH

g

U

U

U CO r-H QJ ^ O 4-1 -a S U O M 1 4J CO

O

bC ro S ro S O CO CO to o o z 0 01 m rH C 2 O < >.rH VO M U S M < o ^ VO WrH VO

>tg

-50-
• •V •

0) •

iH D> C7> C 10 to to 0 10 to to 3 3 3

01

CT> JS .C

flj o uu

to 1 (0 4J -p • U 1 3 (0 to 10 0)

i) 1 J3 D»

Ul 1 (0 D 1 o u "O 10 1 c c c 3

-D 1 (0 10 10 (0 C 1 i3

<Q 1 0) a> a> 1 Q> c c c c

Q) 1 li -r-4 •H -H •rH 3 ! 0 r-l 1—(

rH

<n 1 e 1 1 1 1 CO 1 c c c c D 1 K o o o o 1 c 1 1 - 1 (0 o to 10 C (0 c

>t -r-l

O 0 >! to (0 p •rH to O -H •P

(0 ••H

C c •1-1 Oi to 0 p 0 3 (0 -H -rH c • •H CT 3 -P 01 c P O rH CT to e 0

10 (0

O E 01 •H 1 E C 10 to Vh CI P

(U 1 uC (0 0 to to 1 0 o o tp c o

1^ ! y-t •D (0 c c to •rH

6-1 1 c c M -H -O -H 1 •H (0 >> 0) "a c a C 1 rH Qi (0 (0 0 1 JJ c •p CO to 1 c o c 0) •u 1 1—

>1 r-H 4) •H to

(0 1 E (0 • a>

u to 6 P u

U 1 0) £ c to •rH (U •H .rH

•'^ 1 •H 4-J ^ CO rH £ H 1 to • 4J •r-l CO C 0 to CO •H Q< Qj 1 c e u to to rH CJ 0 PCS CJ to Ok 1 to (D to >i a> •rH -rH •rH (0 to a> to u < s -u S 10 E-i E -P -P s S P o r~- c

00 (0 o

r-H r—

rH o

0) 1 rH U 1 o \ o o

(0 1 ? o o r~ ? 1 >1 ro

n

D 1 0)

M ro

V4 1 X

(0 1 o S in (9 (0 S 1 93 03 in M M

•O 1 C

u on c c C 1 0 c c o o o

10 1 o CO 0 1 M a >-}

Q

cn 1 CO < w <: < S 1 U) OS m 1 Q < M M ffi a 1 M s: s Z M

0) I g I to i Z II >. I u I • 1 1 >i (/]

C -U rH 1 C C j3 -tJ 0^ c (0 to 0

•H

a * 'O rH (D p w (1> fO c CO 0 W 'H 0 •rH >i • (0 ^ 0 D U •H p en U3 p to p 3 'DO Qi 0 (0 p to

CO >i •C Q) 0) rH o c 0 CO (0 ^ U Jj W 3 C * (0 4-* CT* 4J (U Vj (-1 lO CQ C C fT3 4-) Q) to CP QJ **~* 4J £ • P

fO 'D

U a; c c

to

C i-i fO V) £ ftJC to 0 to

tO 4j "D ^ a 3 •H

a. Q4 -u (D P to 0) 0) a c -p 0 w U 0) to 1-i c c >i 0 0 U OJ c iH 0) H •H J= •H 3 e

rH rH

U rHU 6 1 C C fO .Q T3 'U P 1 rH (0 c c -H -H ^ 3 C C <0 c ID U o 2 0^ to fO to CQ 0 U C7>

>C 1 1 1 cy 1 * 1 1 1 p P

10 Q4 > C

U

U 10 to c U

>i 0 •r-t

Q CJ

G

u <u

Ui rH -U to CT* ^ *' 1 0 d) e •1—1 <D C • fO i-I C 0 J-* a 3 0 W ftJ 6 > CJ D -r-i D 0 u C (D 4-J Cli ^ Cil 0 a 0 "TD to * T3

"•^ to 4J

C >i i-i

C "-H to ^ fO 13 C -H CU >1 0 0 E -C C to rH p W c 0 fO D 4-* fO C P -o

(0

C 0 0 fO 3 to 0 C 0) c ^ ^

''^ UH JZ > 0 to

U E -P c u c a 0 Oj H 0 U C 4J rH a O £ to C fO c c 3

(U fO 0 ttJ to -p

Q)

O

C 03 >i to

C 4-*

u rH - c > vw <U 0) rH nj -H c *• 0) xi a; c •H J3 M-l 0) CU c c e

0)

U £3

C .-H •H d)

cr» ca

a 0 lO a: en

-4-* £ iTJ * t>i

U c to c u to o ^ c U K C •rt 4^ M CO 0 0 (0 c C Q) fO <p CT* 0 •rH l-i to CO ^ E SI 4J ^ C (P 4-) 4-) 4J Ol P p e s 4J M •> n 0

'D (V r- C C 0 m

(0 •rH \ •C 0

rH vo fH (0 ro B QQM S c CQ u C M °o C U ffl c 0 w 0 M 0 < M

CO ffi to S O M CO £ O P- z z M M M m 5 < 0 z IC V M Uc

rH 0)

10 >i u u P rH C C rH 0) 0) 0) O -P <

-51-
CO 1 0) >, 0) 1 0 1 >, >1-p 0 0* in i3 u c 4> SI 10 ^ in c c u g 3 4J •H

Oi I/l -U 0 'D (1) crv 0 0 3 "D "-1 Ci W (1) tj> CP c y o in 4) 10 D -H in in -H a) (0 0 u 0) g 4> -P 10 -rH >i O >—1

1)D rH CT*

y 10 ry\ 0 (0 10 3 U

jQ

M rO 10 (0 <Si (0

u 3 >^ QJ

in in

u 0] 1—1

•» Q4 • y (1) in 4J 3 3 0 >i 3 (0 >l in rH

"O f-H (D > m c in >. c U 4J

4) iH •H -fH j:; jC J3 to 10 QJ

C

(li 10 <n

y

u (1)y o 3 >J

C

(/} 1 3 6 o <u 4J 4J 1) QJ c 4J "D •H no cr 4) 0 U 1 tn u <0 D 10 (0 (1) in H (0 4) (0 c p in i) 1 •» d) U (T jQ j3 C 3 g J3 CO (0 p -p u

in 1 0) fO 3 • fO fO 4J D 1 C C -U 'D 1 - X o in cr in £ g d, 1 >-i n] (0 C U 4) c c <u c •> -P c u 1 -t 6 •H O <0 (0 DiJ-l (0 x: in •H 4) 0 13 C 1 1 tn C (0 y -H e s IM rH

(0 1 C )-< -P <U 1 f •H -o 0) JJ rH e e P 4J 1 0 Q) U C 1 • c c JJ in • c <0 (0 (0 m » U -rH a> 1 •H (0 13 W •H •H U •H u u >! 4> UH 1 >i 6 -n rH >-{ U iH l-t 0 CD iH y cr> CP U -n

(0 1 •H (0 1 u

v 1 1 Qi jj 10 c 1 1—1 4) 0 0 QJ J3 T3

in 1 C >-i 3 c 0 0 in c c 0) (0C (0 c rH Qi

u

u 3 3 C

D 1i O

w

O JJ

J 3 o o (0 -U 0 < in CLi 0 in (0 » tJ> 1 0) r-l u u in J3 • c ja o 0 0 g 4J

4) -H 0 c c c in <v • rH

(0 c (0 4J

g nj

•>-•

u c o g J3 CO 4) QJ

10 Q) (0

D >1-i-> S u (U 4J c U • (0 (0 CO •

in c (D in (0 •H 0 4J >, 4) J> <o •H Oj 3 in (0 CO in • _Q 10 c u 'D lO 6 (1) CT" g 0 in C W c CQ C 1 0) u c (0 Qj <D in d) c -iH

V 1 U 10 -H c a) iH (0g .H 10 r-l 04 I 10 10 u o 4J 4) ^ P rH ^ 1 "O c >, (0 0 cn 0 3 (Q 'rH ^ 1 ID U (0 (Q y s "O Qj 0 10 Q CQ 1 <0 U 9> r-4 4J 1) C Vj C 1 u c r-l 0 -U (0 -P >1 1 0 1 c o 0 0> Dj in g 10 c H 1 0) •H !u C -D in (0 >-( u •rH (0 4» •U 1 CP 4J >i • •H (1) 1 > (0 c 1

rH

y

tj 1 ecu

H nj (0 in ^ iH 0) •H

C 4) rH 6 u c U 1 iH u (0 3 jC 10 •H g rH 10 •rH (0

<-< 1 M

M U> • iH (0

U 13 c "D CU

u UHU

>H 1 o u 3 in 0) Oi 0 Q) <D 1 E <D 1—1 ••-1

u XJi 4) 3

Cu 1 n) 10 S 4JuC £ c 0 c •H 3 >, 0 c in Q< 1 U )-i S (V c u-i 0) D U 0 u • H 3 tT 10 QJ c < Eh ••-> > r-l M cu 0 u U in - 14^ Eu CQ 4* CU Oi CQ ^

r—\(0 > c 0 o 0 N

r~ (0n o

0) 1 \ r«. o c 4) S )-l 1 o CO

<a 1 vo 41 fn in 0 tH ^ 1 n 4-) as g

n

•O 1 1—tto S; 4)

C

U 1 •H

M (Qn •P 0 jg

(0 1 19 3 t-i 4* 10 (0 S 1 M J3 c jj 5; '>\* M 1 0 C 10 0 CQ CO C7< O 1 c 0) 0 M c c C 1 0 0) u CO f—1 -rH 0

10 1 9 » s M c 10 -P 1 Ui O CQ 0 3 3 •-3 CO 1 M J3 Q 00 ,^ S 1 1 o 4; J 0 CO U g Eh

CQ 1 c z 3 0 JE •H 0 0 Q 1 M H < Q 1 > U

0) 1 1 1 c 1 1 C 1 0) 1 g Ij 0 3 "D ki 4) rH "CJ 0 e 1 C Q) c in 0 dJ 'H 'O C QJ U)

10 1 M

O

u •H DC J»J CO 1 JJ CiJ 10 P (0 •H 4J Z 1 c c c •O (0 C 4) U >i to 1 >t 1

0) 0) f-l •H

C rH nj r-( < U a> to rH 0 -PU

in CP >i (0 6 O 10 ffi fO 4J J= c u 0 -H 0 CO -H 4J

U 1 C -H

u 13 vj in in

p 0 10

Q

u

U 10

C 1 0) —1 c (1) <C 4J OJ c OJ 4) -H rH -rH <4H - 4J » 3 •H

a> 1 rH 0) 'O (0 Ti nj (0 cue (D -P -H sue sue D> 1 <D 0^ 0 0 QJ (0 4) U 0 0 a 4) < 1 Q < U. [b ^ OQ u > g X u S ac UH u X CO E

-52-
* I 01 1 >n CO 1 dJ 1 0 ^ d) 0 -P 0 J3 4-» C d) 0

CJ CO 4J ^ m d) V-i CO

M ^ V4

4-> 0 CO 1 'U 4-* CU •H fO 1 fO >i rH iH

CO (0 3 d) ^ * d' 03 d> H C to to fO CP to (0 * ^ XT V-i n3 D U J-i > 4-J fO ** 0 0 d) dJ 03 to to >1 Q) rH 4-> I J3 dJ £ ^ CQ (0 J-* » C —1

••'WE 4-J •* dJ

C fO CJ^ _Q 0 m CP ro >i .c c 1 'O d) c C "'\ 'H U C M J-i c 0 dJ CJ CO

tn 1 CT d) •H d) 4-J -r-l

H V-l tP 0 03 4J 4-1 >i

U 1 ftj s-i 6 4-J c U

U 4-J (U 0 3 M 03 CO

(U 1 *»

u

w 0 ^ -r-t (0 dJ V-i 4-* i-i CT >i ^ X}

U) 1 ^0 • 1 * 0 to f—t 0 J-* CIt • S4 1 s 1 C ^ U U) C »H • Qj 1 C U dJ c 'D W) I fTJ 1 0 m d) c m d» £ £ J c 0 C ^

'O 1 -H

U d) s-i 0 ^ • ^-1 dJ d) 0 CT OJ d)

C 1 £-* >i CO 4J > 4-* £

(0 1 me dJU

g XI

u 4J CO -H x: dJ CP dJ

u CO d) £ 1 C (0 d> m dJ >1 U >i4J CP C C c m 0) C 03

(U 1 x: >i e rH d) CO 0 D •H -H •H CO -H ^

cn 1 O

U 4-> c u 0^

u >j • Ti e 4-> -n fO 0 .H 4J tH c u rH tJl t! 1 4-> <D O 0 1 fO 0 4J Qj OJ (T3 CO XI f V4 1 03 1 0

CO 1 O Q) fO 3 C CO ^ 0 DC dJ ^ C 0 c c ^

ID CQ CT'n 0 4-J jQ CQ tJ'-H 3 CP S to 03 J-* 4-* CJ Ui CJ 0 0*

>i 1 C t to Q) Q) a * 0 > > 0 M 0 (0 '"^ C

•H Jj 0 0 u Jj 4-* dJ 4J ^ (C U rVC CO

ft3 d) c c 'O ^ U) Q) 0

4-5 (TJ > u 0 w 0 >1 C C 0 H i>J •H • "'^ C 0 C^ 4J rH C

•H

C Jj

H d> OJ -H

Q) 1 6 fOC (u >

{X 1 d) 4J d) dJ c s ! m d) > dJ 4J OJ • H 0 CQ

b*' I c CJ c £ >1 03 •H I-H 1 c c 0 rH -p 4-* 4-J C 1 OJ T-l C Q> * fO 0 t * Cj c 0 4-* 4J

•r-t I »—* u c i-H rH

C CO 4-* fO c C 4-*

W 1 (1) -H 0 d) 0 03 %4 4J

U

m 1 c 4J

a •H c a - 'O CP

u c •H £ £ ? U 1 C CO w u C CO CO u dJ 4J d) -H •H 1 0 -H dJ . c 0 dJ 4J 03 £ d) CP u M 1 [fl 4-» rH 03 CO i-J c 03 m 0 c 03 <\> 4J di 1 (T3 ^ 0 c M U fO iH CO U Cij CP to Qj 1 0 4J 0 d) 0 i-l 0 0 dJ 0 03 03 C 0 < 1 (/} 0 jJ to CO tX Q Cd 'H

00 s c CO 0 CQ f\u 0

i-i rH 00 0 rH

r-i 0 rH 0 rH rH fH 0 t 1 c CO CJ rH cu Q4

<D 1 w CQ rH ro 0 (H U 1 CJ Cli t5 1 CQ H 1 ^ 1 It n »> CQ CJ CJ 'O 1 •J *^ M u M u W 1 Q Q ^ 1 c s c u X 1 M 0 c 0 c 1 c 0 0 (J "u 1 0 0 0 0 0 C 1 0 > 0 CN 0 CO 0 rH

fO 1 M CO CO 1 rH 0 CO

T

T

03 1 us <D -r < M CO CO 1 CO CO 0 'D CQ c^ CO 'S, CQ 1 0 g M < CO CQ U 1 Q n M s M CQ Q

'O 1 1 C C (0

HI i-H 'O 0 c 0 £ 1 0 0 c

fO 1 'H ^ H dJ dJ y-< to Z 1 0 >i (T3 J-* 4-* 4J 4-* 0 c iH 0 rH >i 0 W ro 3 fO 3 0 'O c OJ 4J >. 1 W -H 2 4J £ 2 4J J= < 0 C D 03 c -H >i U 1 }^ CO •H 4J •H AJ •H 0 03 0 U C 1 ^ 4-> r-i 4-J H OJ c -H c

OJ 1 :s 0 c S CO

m S CO ro 0 (0 4J OJ 4JU dJ a> 1 W C dJ U C dJ II) u u 03 D 4J OJ dJ CP < \ n: w e X t-H E X M X X Q 4J Z CQ CO 2 CO <

-53-
>1 >i 1 m 1 tn 1 JJ •O JJ 1 u

XI • i3

u (Uu a>u 0 a> c U) (0 0) n3 QJ (0 w (1) to <l> ij JJ •H 4J w g -H g -H 3 1—1 3 •n ajj

rH • "a

M • • c gU

g

u ja jQ (0 1 <y -H 0) w (0 (0 Q) <0 Q> 3 3 g c tn iH I/) tJl >j a. c tn to >i 0 10 D (0 D 0) (0 4J tri tn (0 J3 JJ • in •H s in o 0 g n O - to D o e M ^ u x: c • fl c • 0) JS u (0 a, <u u 10 m JJ 10 to U Tl

x: s:

a x;

u £ c *j +j jj JJ i) X} 1 K e u u CT> U (0 jj (0 tn rH (0 to 3

(0 1 (0

g JJ JJ 4J 0 4J J3 JJ >.

m X) cn -H (0

n •r^ 3 to

U 1 j3 10 (0 rOU (0U (0 J= 10 XI

g 01 Vj rH

01 1 XI XI <U jQ

a £l

u

g Q>

m IJ 0) (0

in 1 - a> 4J 4J

g -H

g •rH • J= c • D 1 c o T) •o 'O (0 -o u o g u "a g U 0) U 10 to 1 o u C c m c c c XI 10 u (U 0) JJ 03 0) c (0 0) CT> JJ JJ "D 1 10 <o 6 <0 D 0) in -r-l (0 (0 a (0 10 to C 1 4J •n 3 X3 XI CT" tn in tn jQ to -rH 10 1 O >t 4) flj 4-* (1) 0) 3 0 0) 0 3 U rH 1 10 J3 C c o c c c 3 tn 0) u u c ^ 0) 0) 10

a> 1 (n -H •H 0) •r-l c •H •r-l • tn • JJ

a 0) •H Ou 0) JJ

g --^ cn 1 C -D i-H r-( -n iH •H iH i-H c to u in 0 JJ rH JJ U 0 g o

(0 1 (0 <u 1 1 XI 1 Oi 1 1 O 'O -u 4J "D -t-l

g JJ 1 jj JJ e (0 oj

(0 1 ^ in c CO c c C c •H c tn (0 c tn > <0 c >, (0 (0 0)U

D o O 10 o o O (0 -H CQ 10 --1 « X)

g OXlg CQ Cii (3^ to

D 1 • 1 1 UJ C C -H jj c 0) . 0

(0 (0 *w c a) >J rH > §'§ JJ g c c 0) •H rH Cr-H g <D a> c •0 (0 • C JJ g (0 •H c > c H 3 JJ a c C (0 10 0) 0

rH XI

C 0 (0 (0 (0 •H -H 3 -H Q> rH g rH 0) U JJ 1 C 10 •o u e 0) rH u >1 c JJ 10

0) 1 •H > > rH > 0 <a •H 0)

g

Oi t to a> x: to

H 0) in 0 9)

u iH to

u

u ^1 tn U •H 3 o (0 •H fU a to 0

0) in "o cr JJ >1 • U (0 <u 1 u jj 01 •D (0 rH JJ Q) -H u o c C 1 0 0) c Q a 0 u o 0 C H 0 1 u C - 01 (0 Pi c (0

•rH 1 a, 0 C7>

C 0: - jj 0)

a rH

JJ 1 JJ •H

C rH x: r-t

C JJ o> 10 • (0

(0 1 Q) c JJ rH JJ . 0 tJ (0 0 c •iH 0 rH 0) 0)

u

U 1 D> i)

U JJ c c u 0 c 0 rH •H to Oi

•rH 1 (0

g 3 IJ 3 0 ro 0 s ^ H JS > (0 (0 c

rH 1 to 3 -O 0 0 -H 0) to >. 9 a>

a a> to Ch 1 to y 0 a u JJ tn w u u u JJ (0 -H in 0 u a 1 0 U d) U (O 0 M 0) 0 c 0) JJ 0) < £ Q u to 0 04 4J s H s JJ

CO rH c c 0 rH 0 0

r-H JJ 0 I-H <S) rH rH V£) •H 0 0

r- It

u 3 V£> rH cu a> ro « 0

0) 1 < XI 1 Q c a> U 1 > cn (U 0 S 0) to -r

(0 1 MM

X CQ in 3 » 1 0) X Q U M 3 0 0 Q

-D 1 to

u 0 0 J=

)J 1 3 rHQ c JS f 1 10 1 c 0 rH u 0 1 c U S 1 0 jC <U u C c c •H u Q 0 0 a

•a

r 0 0 0 c 1 •H 4) c CO v£> CN Di 0 c

(0 1 r-t

— c 0 cn 0 3 H r- 0 1 0 u fsl \0 cn 0 0 1 tn X cn ai 1 1 Cd •H XJ U (M S 1 Cfl H s U cn cn Q rH U a> s: CM

OQ 1 z: ^ c Q z Q

M 0 a 3 aoQ 0 0 1 0 Q 0 M M M X s: cn CQ cn M

uzMJ «* O 01

Eh< O M > a M

cnzMOu

cnM 0\

EH "W

V I a I 10 I Z II >i I U I C I V I o» I <: I

-54-
M

0)

10c

la I 10 I s I

>i a> CO J3

u

rH (A E 0) cam -o O u -D JQ

CP D< 0) 3 c o •>-> (0 c 6 ^ o 0) (0 (i J -H 4J 0 a> o Q4 0^ (0 u iJ 00 6 C O '^

i-i -o o

(0 c 6(0

C

T3

O

01 n] ifi 4-' •H > O

_

H 0^ HI 10 10

M-l -H 10 (0 0) ^ 4J M (0 O -U o 0) cn u (0 (A a:t* Cue

(0

(0 .« -H

(0

u

M a> e w E

0)0c 1 (0 (V 1 a 1 10 ^!1

Q) iH0 • C 1 c 0 1 4J 0

•H 1 U -M U 1 0 -W m 1 a (0 u 1 0) e

•H 1 u

u

f-i 1 0

0. 1 0) a 1 £ c < 1 C J3 <L) 03 'O w 3 C 3 r?u Q d) c d) •

J-*

M

0) 'O

M (U

B 'U 3 E Jj 4J cr 'O QJ C C 4J d)

CO , fO vl AJ 'H

•H aJ ^ 0 M E 0

'O c 1—1 U4

u

Q) 'H 1 _ 0* B W c ^ c Q

(0 fO CJ» 0 0 1 (0 •H QJ C 3 (0 0) U) c w 4J 0

-H

D 0) 0) 0 u -QC

U 4JC U5 Q) 03 3 M C M c 01 10 0 (0 w 1—( ^ -H C (0 •n 1 fO +J

(0 t- •>(M >i U5

A Jj 0 ^ -P E-t i2 -H 0 1 4-' 1 4J <U Q) > Q> 4J 'O C

(0 -H

U (0 C 4J s: 0^ 'O ^ (0

lO •r^ 1 1 (iO ^ c C \ 0 B

Oi

C 1 (0 Oi (0 4J

(0N

C -H

U) •H >^ 0 'D U-l ^ r-H C * a> B • e iff B »« C c

CO d) c 'o • 0

4-f • •P (0

C (0 r-t -r-l 10 P m 4J >i >i c m c

(0 a»

U

U 03 JC 4J U C U OJ CO 4J (0 (AO) 0) CJ •H c a JJ C

J= -H 3 0 -H 0)

H 0 Eb. (0 >

-a I C ID • (0 a —

(1) ^J 4J

0) c

4J 0) T3 4J -r-l (U <0 u 6 O c0 -u cu •H U Q M 0) I 0 -n C 1 XI 0 CDC O (0 —

•HP >i (0 U XI 4J

(0 (0

U3 -H C TI >H

(0 (1) (0

Eh 3 O I0) -pc£

05S

<nc

0) cac

(0 • U 01

0)uc

0) (0 > c

0) I U I m I

VI I 10 s III T3 I C I 10 II W I S I ffl I Q I o

r-£coa< I10 COco

•HPO

ffl r»

ffl a£« nu w

On c

•P o

9>one

•O E 9 « a 4J «s

0) pu

>1

0)n3

4J

ffl P O

4J £

OJ CO •O3 C

OQ

O I U e o

•HP Co >M 0)

Q)u

W -H I > 3 U a 0) e w oU D> ^ CO

CM (0 fti O J= Q <O

QI SQ

0) I e I

ffl t z II >i I U I C I 0) I a> I < I p -p VP C V o a>6 -o V 0) 3 U 7<0Q

•H ffl <*-l C "O

U-l ffl c O £ ffl 1 9)

(U 0) 1 c C 4J c 0

0) c 0 < •H

OQ ffl -Hu

U -P (0 ffl

C ffl ffl

C 0 3 U ffl

p

•H 0 0 u (0

(0a 0)

H

C -P

u 4J c

0) -H 0 01 •H

CU U-l

u > E

-55
7.3 APPENDIX 3 - DBMS TERMINOLOGY FOR TG-24

ACCESS - The operation of seeking, reading, or writing data

on a storage unit. [MART 75]

ACCESS CONTROL - The mechanism in a data base system which

provides protection of the data base from both intentional destruction and improper disclosure. [DATE 75]

ACCESS METHOD - A technique for moving data between a computer and its peripheral devices, e.g. serial access,

random access, remote access, virtual sequential access

method (VSAM), hierarchical indexed sequential access

method (HISAM) . [MART 75]

AUDIT TRAIL - The process of keeping of records in both

events and data activities within a system to allow future examination and verification of what has transpired. [CODA 76]

AUTHENTICATION - The process of supplying information known

only to the person the user has claimed to be. [DATE

75]

AUTHORIZATION - The definition to the system of the operations each user is allowed to perform. [DATE 75]

BACK-UP - The process of generating a copy of a data base at

some point in time. [CODA 76]

CATEGORIES - Categories are groupings of database management

systems based on some technical criteria.

DATA ATTRIBUTE - A known characteristic of a data item,

(e.g., a numeric field, a date field, etc.)

DATABASE - A collection of interrelated data items processable by one or more programs.

DATABASE ADMINISTRATOR (DBA) - A person or persons given

the responsibility for the definition, organization,

protection and efficiency of the database for an enterprise.

DATA DICTIONARY (DD) - A software tool that is used to control the totality of data elements within an application. It is the central repository of all descriptive

information about each data element.

-56-
DATA DESCRIPTION LANGUAGE (DDL) - The language used to

describe the database, or that part of the database

known to a program.

DATA ELEMENT - A named collection of one or more items.

DATA INDEPENDENCE - The property of being able to change the

overall logical or physical structure of the data

without changing the application program's view of the

data. [MART 75]

DATA ITEM - The smallest unit of named data containing no

sub- structure ; the lowest level of addressable data in

which data value(s) are physically stored.

DATABASE MANAGEMENT SYSTEM - A software system is a database management system if it possesses all of the following properties:

It is an integrated set of computer procedures

It facilitates usage of data

It facilitates storage and maintenance of large

amounts of data

It provides frequently used shared functions

It potentially serves many functional purposes.

DATA MANIPULATION LANGUAGE (DML) - The language used to

cause data to be transferred between the application

program and the database.

DATA MODEL - See Data Structure.

DATABASE POPULATION - The process of placing occurrences of

data values into a defined data base. [CODA 76]

DATA SECURITY - The protection of the data in the data base

against unauthorized disclosure, alteration, or destruction. [DATE 75]

DATA STORAGE DESCRIPTION LANGUAGE (DSDL) - A language to define the representation of a data base in storage.

This term is used in [CODA 78].

DATA STRUCTURE - The logical relationships which exist

among the units of data in a database and which are

under control of a database management system.

DATA VOLATILITY - Refers to the rate of change of the values

of stored data. [CODA 76]

DEVICE MEDIA CONTROL LANGUAGE (DMCL) - A language used to

map the data onto physical storage media. It describes

the physical location and organization of the data.

-57-
DISTRIBUTED DATABASE - A database under the overall control

of a central database management system, but where the

devices on which it is stored are not all attached to

the same processor.

END USER - The end users are persons who perform the application functions. End users include parametric users

and generalized function users, but they are not system

support personnel. [CODA 76]

EXTRACTION - The process of obtaining data values on each

data structure level and identifying the disposition of

these values to an output media. [CODA 76]

FILE - A collection of all occurrences of a given type of

logical record.

HIERARCHY - A set of directed relationships between two or

more units of data, such that some units are considered

owners while others are members. This is distinguished

from a network in that in a hierarchy, each member can

have one and only one owner.

HOST LANGUAGE SYSTEM - A database management system that is

built upon the facilities of a programming language and

is identified to the application programmer for logical

and physical file manipulations. The tools are embedded in the host language (e.g., COBOL, PL/1) and are

accessed usually through CALL statements, but sometimes

by extensions in the language.

INDEX - A table used to determine the location of a record.

[MART 75]

INTERROGATION - The function of data selection and qualification, extraction, manipulation, and result presentation. [CODA 76]

INVERTED FILE - A file structure which permits fast spontaneous searching for previously unspecified information. Independent lists or indices are maintained in

records keys which are accessible according to the

values of specific fields. [MART 77]

LOGGING - The recording of actual changes to a data base as

updating occurs. [CODA 76]

NETWORK - A set of directed relationships between owner and

members such that a single member record may belong to

one or more owner relationships.

QUALIFICATION - The specification of selection criteria

-58-
during the formulation of a query, [CODA 76]

QUERY - same as interrogation.

QUERY LANGUAGE - Language which permits spontaneous queries

to be entered, or allows a non-programmer user to explore the data base and produce reports embodying its

data. [MART 75]

PARAMETRIC USERS - Parametric users deal with specific elements of data according to a predetermined procedure

and using a limited complement of commands. They are

basically unconcerned with data structure and flow except in terms of the relation of data items to identifiers. [CODA 76]

PRIVACY KEY - A facility specified as a literal, a data

item, or a procedure used to unlock an operation which

is locked. [DATE 75]

PRIVACY LOCK - A facility specified as a literal, a data

item, or a procedure used to prevent an operation from

proceeding unless the matching privacy key is presented. [DATE 75]

RECORD (logical) - A collection of related values treated

as a logical unit during any operation of the database

management system (e.g., during data collection, processing, or output).

RECORD (physical) - A unit of data to be placed on, or taken from, a storage device in a single operation.

RECOVERY - The regaining or the bringing back to an original

position or condition. [CODA 76]

RELATIONAL - A way of modelling data structures by relations. Relations are usually represented as a collection of tables where each table contains the occurrences of a particular relation. Each column of the

relation corresponds to an attribute and each row is an

instance of the relation.

SCHEMA (conceptual schema) - A complete description of the

database in terms of the characteristics of the data

and the implicit and explicit relationship between

data-units.

SELF-CONTAINED SYSTEM - A database management system, the

capabilities and language of which are intended primarily for the non-programmer. They are self-contained

in the sense that they usually have no connection with

-59-
any procedural language except that the system itself

may be written in a procedural language, or it may permit user-written code in a procedural language.

SUBSCHEMA (or external schema) - A description of those

data-units and relationships from a database of interest to a particular program.

UPDATE - The process of changing values in all or selected

entries, groups, or data items stored in a data base or

adding or deleting data occurrences. [CODA 76]

-60-
APPENDIX 4 - DATA DESCRIPTION LANGUAGE

WORKPLAN

Ob j ec t i V es

0 Recommend and justify need for Standards in the Data

Description Language area based on Federal government user needs.

0 Develop plan of standards activities to meet such

needs

.

Methodology

0 Define subcommittee scope and objectives

0 Develop definition of DDL

0 Define products of study

0 Define tasks required

0 Devel op work pi an

0 Impl ement plan

0 Analyze findings

0 Produce recommendations

Ta sks

0 Define "Data Description Language"

++Review existing definitions

++Review CODASYL proposal

++Define role of DMCL

++P reduce DDL definition

0 Review existing DDL implementations for different

data models

++Categorize attribute definitions

++Categorize structure definitions

-61-
0 Summarize and analyze results of previous tasks

++Review work of other DBMS standards groups

4. Develop conclusions and recommendations

++ Review of Data Descri pt i on Languages * A 1 imited number of

DDI definitions were examined. The purpose of the review

was to develop a working definition that reflected the scope

of the subcommittee area of responsibility.

The definitions reviewed were:

1. Principles of Data Base Management - J. Martin

2. CODASYL - Data Description Language, Journal of

Development, June 1973

3. Data Base System, A Practical Reference - Ian Palmer

4. TG-24 Data Base Management System Terminology

DDL DEFINITION

A Data Description Language (DDL) is a stand-alone language

that defines:

1. Attributes of data elements

2. Logical structure of the data base

3. Logical relationships among units of data (records)

4. Logical methods of access to data

THE DDL DEFINITION DOES NOT INCLUDE DMCL

The Device Media Control La nguage{DMCL ) is used to map the

data onto physical storage media. It describes the physical

location and physical organization of the data. As such, it

is the bridge between the DDL and the host DBMS or computer.

SEPARATION OF DDL INTO DATA ATTRIBUTES AND DATA STRUCTURES

Attribute Definition:

-62-
1. Identifies type of data category such as item,

record , file

2. Names items, records, files

3. Specifies sequence of items in records

4. Defines method of data encoding (numeric, binary,

ASCII, etc.)

5. Defines length of data items

6. Identifies repeating groups of items

7. Validation or range values for data items

Structure Definition:

0 Identifies key data items

0 Specifies which records are related

0 Specifies how records are related

0 Names data relationships

0 Specifies sequence of records, and files

0 Specifies method that will be used to access data

EVALUATION £F EXISTING IMPLEMENTATIONS

Network, hierarchical and relational DBMS implementations were analyzed for adaptability to DDL standardization.

The necessity for different methods of describing data attributes and structure was of special concern.

The CODASYL specification of COBOL type data attributes

descriptions was adequate, easy to use, and widely known.

Other methods of defining attributes gained nothing for the

price of their being different.

Specification of file size or placement of data into

physical storage units is dependent on hardware. Each DBMS

implementation is designed to its host computer. This area

was not considered a candidate for standardization, and removed from our definition of DDL.

-63-
Data structures, and associated access facilities, were

the most divergent areas. Each structure had its own advantages, depending on an application using the data base.

What is good for retrieval may not be good for update; what

is good in batch, may not be good on-line.

No single structure was best for all applications.

However, the thr^e structures together seem to meet the

needs of most applications.

-64-
7.5 APPENDIX 5 - DATA MANIPULATION LANGUAGE

INTRODUCTION

What is a data base management system? What functions

does it provide? These questions must be answered before a standard Data Management Lan-guage (DML) model can be

developed. After all the functions provided by the set of

software identified as data base management systems (DBMS)

are qualified, then the question "what can be standardized?"

can be answered. The amount of effort required to define

DBMS and survey the current market of available DBMS will be

considerable. However, it is recommended that data base

management be defined concisely and that every function provided by every system that meets the definition be identified. The data management function (DML) subcommittee of

Task Group 24 (DATABASE SYSTEMS STANDARDS) has chosen a subset of available DBMS to illustrate how the standards effort

could be applied to data base management language functions.

Twelve data management systems were arbitrarily selected for functional analysis. This subset will illustrate optional approaches that are possible with a given set of candidate DBMS. This paper only considers the standardization

of host dependent data management languages of the candidate

DBMS. The optional approaches leading to a standard DML for

data base management systems will be treated. The recommended approach will be emphasized. The following sections

of this appendix will cover the approach that was taken to

arrive at the recommendations presented in part II of this

DML subsection of this report.

METHOD AND SCOPE

There are many types of data management systems. Most

of them can be classified as one of the following types:

1. Data retrieval systems

2. File management systems

3. Complex file systems

4. Teleprocessing monitors

5. Data base management systems

-65-
6. On-line data management systems

7. Special purpose systems

There are subtle and marked differences as well as overlapping capabilities among the types of data management systems. But, each available data system can be categorized

into one of these types. TG-24 has been chartered to investigate standardization of data base management systems. The

DML subcommittee is limited to evaluating the possible options open to standardization of the data management functions that require the support of a host programming

language, such as Fortran, Cobol , etc. It has been found

that considering only the DML' in standardizing DBMS is not

practical. The DML is entwined with the rest of the data

base management parts: the DDL, the DMCL, and the host computer operating system. So, the first step the DML subcommittee decided to take was to collect all the data management systems that fit the type "data base management systems." This seems simple enough, except that there are no

formal well accepted definitions for any of the above types

of data management systems especially for DBMS. TG-24 had

two problems. First, there were no acceptable definitions.

Second, there are a large number of data management systems

available that need to be measured against a definition.

The DML subcommittee of TG-24 felt it necessary to limit the field in order to develop a standard model DML containing a representative set of the data management functions provided by the set of existing DBMS. In order to accomplish this subsetting to one level, a definition of a data base management system in terms of major functions provided was proposed. This definition is not intended to be

the final acceptable definition of data base management systems. Its purpose is to limit .the available DBMS candidates

for the first phase standardization effort. A broader definition that will include all data management systems in

the standards effort is recommended after a firm approach is

selected using a smaller set of DBMS. Also, for an acceptable definition to evolve, a preliminary one must be provided as a base. The definition for a data base management

system in terms of functions and facilities provided is as

foil ows

:

1. It is an integrated sharable set of computer programs that perform data access functions.

-66-
2. It separates data access (DML) and data definition

(DDL) from application programs in a uniform manner.

3. It facilitates and controls in a uniform manner

storage and retrieval of data in and from a data

base using random access storage devices.

4. It is generalized in the areas of file structure,

the number and types of physical files supported,

and in number and type of applications supported.

5. It supports and maintains the integrity of the data;

validity checking and file backup and recovery utilities.

Now that a definition exists, a survey of the market can begin, and all the data management systems that meet the definition can be selected as candidate DBMS for the DML standardization evaluation. It was found that the number of

data management systems that need to be surveyed was too

large for TG-24 to handle in the one year time frame given

to our initial study of DBMS standardization feasibility.

The DML subcommittee chose to select a small subset of systems that are commonly accepted as DBMS to illustrate the

options open to DML standardization.

The DML subcommittee chose twelve DBMS for evaluation.

The twelve systems are as follows:

1. COMPUTER CORPORATION OF AMERICA - MODEL 204

2. DIGITAL EQUIPMENT CORPORATION - DBMS/10

3. CULLINANE - IDMS

4. HONEYWELL INFORMATION SYSTEMS - IDS/II

5. MRI - SYSTEM 2000

6. SOFTWARE HOUSE, INC. - SYSTEM 1022

7. UNIVAC - DMS/1100

8. IBM - IMS

9. BURROUGHS - DMS/II

10. UNIVERSITY OF CALIFORNIA - INGRES

-67-
11. GENERAL MOTORS RESEARCH LABORATORY - ROMS

12. UNIVERSITY OF TORONTO - TORUS/ZETA

Using the twelve DBMS selected, a chart was built showing

the major DML commands of each DBMS. See Chart I. Each of

the DBMS has other commands for control and interface with

respective operating systems that were omitted for this

illustration. Examination of Chart I will show that at

least four possible categories of command/function sets can

be identified by selecting common command subsets. Also, if

the data structure models were made known, the categories

could be identified by data structure. This is not surprising because the DML commands directly relate to the data

structure model of a given DBMS. The four categories that

can be identified are network, hierarchical, relational, and

table structure. There may be more possible categories.

The area of DBMS classification and definition is complex

and controversial. To resolve this area satisfactorily may

require a separate committee and a year or two's time. A

network system is an extension of a hierarchical system. It

accommodates hierarchy but also allows complex networks.

Most CODASYL DBMS fall into this category. A hierarchical

system accommodates data hierarchy in the data structure

model, and supplies commands to manipulate hierarchical

data. The relational system defines a range of values

across a domain as a relation. Relations are defined as tuples involving one attribute and many values. Also, the

creation and destruction of relations is dynamic. The

self-contained system is one that does not need another

language to act as a host. However, many self-contained

systems offer host language capability. The difference is

in the physical data structure; a self-contained system usually has a static physical data structure, such as a table

structure. Regardless of the logical structure of the data

base, the physical structure is the same in most selfcontained systems . DBMS designs have different purposes; i.e., relational

systems allow dynamic changes to be made to sets and relationships to handle a moderate amount of volatile data. The

CODASYL approach allows very flexible data structure for

large amounts of data, but the structure is very static once

defined. The command sets that accompany the different

types of data base management systems are directly related

to the data models of the particular type. This is the reasoning behind categories of data base management systems

that are illustrated in Charts A, B, C, and D.

-68-
Both the common and unique commands are illustrated in

Charts A, B, C, and D. The DBMS were grouped by evaluating

common commands, unique commands, and data models. The

names given to the resulting categories are not important,

and this is another area that could be standardized. Some

systems could fit into more than one category, such as System 2000. System 2000 is a table structure system, but it

is also a hierarchical system. It was included in both

Charts B and D to illustrate dual category possibilities.

This also provides encouragement for the possibilities of

DBMS evolving to provide similar command/function capabilities. Network and hierarchical systems are similar enough

to evolve to one category in the near future. There is

probably one other category that will result if a more complete comparison and classification effort is undertaken.

It will be the special purpose data base management system

category. In some cases, sem i - genera 1 i zed data base management systems are developed for special purpose hardware

and/or applications. Due to the special purpose nature of

such a DBMS, it would be very difficult to standardize. One

special purpose system is usually not very similar to another. So, this category would hold a group of DBMs that are

dissimilar to themselves and the other categories and not

amenable to standardization.

PROCESS LEADING 10 DML RECOMMENDATIONS

Now that the DBMS are categorized into subsets, some

options for standards can be proposed. Three or four options are possible today. First, a standard DML interface

language for each category could be developed. Second, an

interface language could be developed to include all identified categories; one standard interface language with

preprocessors to generate individual DML's. Third, a set of

standard DML commands could be developed for each category

identified from the analysis of all candidate DBMS. Of

course, the option of no recommended standards at this time

is a possibility. The possibility of selecting an existing

DBMS from a standard appears unlikely because no single DBMS

will have a super set of commands/functions that would be

needed to provide all the capability now available by use of

a combination of available DBMS.

1 . Multiple I n terf ace Option

Most competitive DBMS will have the same major capabilities within the next five years. Of course, the syntax and

semantics of the interface languages (host language interfaces) will not be standard unless reasonable standards are

proposed and accepted. The standard interface approach for

categories of DBMS provides a flexible method for gaining

applications program DBM standardization. When, and as DBMS

-69-
begins to provide the same functions and capabilities, the

interface(s) can be modified to accommodate changes or additions to the standard DMLS. Eventually, a single standard

DML interface may evolve if the DBMS becomes similar enough.

Vendors of DBMS are already providing similar capabilities

to remain competitive. The users should begin to be concerned with standard methods of identifying capabilities before the vendors implement new capabilities.

2 • Single Interface Opt i on

The option of beginning with a single standard DML interface may be possible, but it would be very complex and

may not be acceptable to the end user. It would be necessary for the single interface to accommodate the full set of

DML commands of all the candidate DBMS selected. This would

result in command translations that would cause no operations in any DBMS that do not provide the command capability

desired. It is recommended that if the interface option to

standardization is selected, the first option chosen should

be one standard interface for each identified category. If

this approach is followed, then, as the DBMS categories provide the same command/functions, one standard interface may

evolve. One advantage to interface approach is that the

user can implement or have the interface implemented without

cooperation from the vendor of any or all the candidate

DBMS. However, vendor cooperation is desired if possible.

It is also recommended that the feasibility of developing a single DML standard for all host programming languages for a given category of DBMS be evaluated.

3, Standard DML Language Option

A set of DML commands could be specified for each category of DBMS. Again, it is wise to stay within the categories to avoid translations that would result in no

operations. Chart I gives an indication of the difficulties

that would be faced in developing a standard DML command set

for all available DBMS. This approach would not provide the

user with a working standard as readily as the interface approach, because after the standard language is specified,

the individual vendors of each DBMS in each category would

be responsible for implementing the standard DML, if indeed

they would be agreeable to do so. The standard DML would

not insulate the user from changes in individual DBMS as

well as in the interface option. Changes to the DML of a given DBMS could be handled in the standard interface instead of in each application program. If changes were made

to a standard DML system, each application that would be affected would require change. However, this option would allow an application program to access any DBMS of a given category in a computer network using one DML. For a given

-70-
category, see Charts A, B, G, and D, the major DML commands

are already similar. The problem with specifying a standard

DML, is that each vendor of each candidate DBMS for each category must implement the standard. This is a big problem

because of cost to the vendor and the fact that one or more

of his major capabilities may not be standard. This could

make vendors unwilling to agree to standardize their DML.

Anyway, it is recommended that a standard DML set be specified for each category of DBMS for two reasons. One, by

specifying the DML set, the data management functions for

each category are identified. Two, the DML sets for each

category are basic to whatever approach is taken to develop

a DML standard.

4. No Standard DML

No standard is always a possibility, but in the case of

data base management systems a lack of standards is costly

and is going to be more costly. Hardware advances in the

next decade will probably provide more speed to conventional

DBMS rather than new DBMS concepts. Standardization of

current conventional DBMS functions will not only help the

users within the next decade, but will help the designers of

future data base management systems by emphasizing the major

DML functions through standardization. Then only new system

capabilities will need standards attention.

BENEFITS EXPECTED

It would be very difficult to place a dollar value on DBMS standardization versus no standardization. It is a field of computer science that is still in infant stages.

Most installations have only recently implemented their

first production system using a DBMS. Consequently, there

is little data available for measuring conversion or training costs in regards to standard or non-standard DBMS. It

can only be speculated to be expensive to convert applications from one DBMS to another. Also, it can be speculated

that some conversions may not be necessary if the same application program could access data of two or more DBMS

without modifications. This implies benefits for standard

DBMS that cannot be proven as yet.

An important benefit to be gained from the standardization of DBMS will be related to the heterogeneous computer

network environment and distributed data bases. Currently,

the hardware and software exists to provide the communications capability for a heterogenous computer network. However, data bases under the control of different DBMS on the

various computer nodes of the network cannot be readily accessed in a uniform or standard manner. A standard DML interface or a standard DML would reduce the programming and

-71-
training effort necessary to access data controlled by different DBMS. It would be possible for a single application

program to access similar data under the control of different DBMS without the need to change or rewrite the program. Of course, other system software, such as operating

system interfaces, user protocols, etc. would also require

standardization to allow the DML standard to be fully and

effectively used. Changes to the system software could be

handled in the interfaces and free applications programmers

of any concern. Maintenance could be centrally handled by

updating and changing the interfaces a large precentage of

the time instead of updating each individual application

program. Life cycle support of applications systems could

be greatly reduced.

DEVELOPMENT AND IMPLEMENTATION FEASIBILITY

Development possibilities definitely exist for the

standard interface approach. The best thing the approach

has going for it is the fact that one vendor or large user

could design and develop the interfaces. Most other approaches rely on the individual vendors of each DBMS to implement a proposed standard. This is fine, but an automatic

method of sharing data between heterogenous systems is not

obtainable through a mult i -vendor standards effort. For instance, the CODASYL standard provides a standard specification for a data base management system; however, two different vendor implementations are not compatible for data

sharing purposes. The languages are compatible: the DDL

and the DML. An application program compiled with the DML

of one CODASYL system cannot access the data belonging to

another CODASYL system without being rewritten and recompiled. If the application program were to use a standard

DDL and DML interface, the interface could handle the translation to a different data management system. As previously

stated, an interface could be developed for each category of

DBMS identified. This is recommended as a first phase DBMS

standardization effort.

The proposed interface would consist of a precompiler

stage plus an execution time management routine. The

precompiler would generate a parametric call to a generic

data management routine. At execution time, depending upon

which DBMS is to be invoked, a specific linkage could be

made. The DDL methodology would also require a standard interface to handle dynamic linkage to specific data structures. This is anticipated to be a later phase of the interface standardization effort. The first level will be to

standardize the DDL and DML interfaces for each identified

category of DBMS. An application program written using one

of the standard sets of interfaces would be precompiled generating calls to a specific DBMS. Once an application

-72-
program is compiled, it would be locked into a specific data

base management system. However, it would only need to be

recompiled using a different precompiler to access a different DBMS of the same cateogory. This approach would provide the applications user with a standard DML set for each

category of DBMS in the near future, and very possibly

evolve to one set if the DBMS becomes similar enough in the

short range.

MAINTENANCE

The standard interface approach insulates the user from

vendor changes to the given category of DBMS he is concerned

with. If a data management c omma nd/ f unc t i on does not exist

in a particular DBMS, the interface could emulate the function or notify the user that the feature is not currently

available through the given DBMS he is trying to access.

When, and if, the function becomes available, the above procedure could be dropped, or if the function was never available in the interface, it could be added. The user would

not be required to modify existing DBMS host applications

programs every time a change occurred to a given DBMS.

The maintenance functions would be transferred from the

individual applications programmers to a central staff of

data base system administrators (DBSA). The time and personnel costs could possibly be reduced depending upon the

number of application areas supported by a given data base

management system. With a large number of unique applications supported by a given DBMS, a saving could be realized

by centralizing the support rather than dispersing the

maintenance activities over all the application areas to be

supported. In the case where only one special purpose application is to be supported, the savings would not occur.

CONCLUS IONS

Standardization of the data management function is definitely recommended. Many approaches are possible, but the

interface is probably the most viable one. It does not rely

on the efforts of each candidate DBMS vendor to be implemented and it guarantees not only syntactic compatibility

but compile and executiion time compatibility for at least a given category of DBMS. It is not very likely that individual vendors of various DBMS will ever reach the point where

they will offer systems that could provide the same level of

compatibility that a standard set of interfaces could.

Charts A, B, C, and D illustrate the elementary

command/function sets that would form the basis for the

standard interface languages for the four categories identified in this paper. There may be more categories identified

-73-
when a complete survey is done using a broader definition

for a DBMS. There will definitely be more commands and

functions identified for inclusion in the standard interface

languages for each category of DBMS that is identified.

This approach is not limited to commercially available DBMS.

An in-house system could be included by building an interface to it. Another sometimes important advantage to the

interface approach is that the existing data bases and applications can remain unchanged while new programs and data

bases are designed and written.

The goals of this proposed standardization effort

should be to provide the user with a standard and uniform

method to build and access data bases using any one of the

data base management systems from a given category. It

would be ideal to be able to provide only one access or interface language for all data base management systems. However, that is not practical today. The team or committee

that does the survey of data base management systems would

be wise to investigate the facilities and functions needed

by the generalized programming user and specify the characteristics of such an interface and measure the existing systems against it. Also, in an effort to develop one single

interface language for DBMS, it would be wise to investigate

the correspondence between the relational calculus function

of relational DBMS and the steps of the conventional inquiry

process (i.e., self-contained, CODASYL, hierarchical).

-74-
• • fri • a • e- • C3 •K • a • Ul • a. • Ui • H • •-S • 1-3 • C • c • c • C • 3 • c • l-H • 1-4 • o •X • Q • c • c • c • c •

>-> • • ti • X• at • l-l to • • f- • H • O• O C • C • c • o • >> • C • c • a. • C • c • • > • c • c • c • > » >^ • a •

«£ • f- • U • §-• •K • • It • 3 • H • > • >. • V • c • c • t? • • c • c • Q. • > • c •«« • >. • c • c • c

to • • Q • • a• ID C • t- • • 10 • > • O • J

Ui • • Si • a.

a: • c • c • t-i • c • c • c • u • c • c • w • > • c • c • c • > • >. • o • oc • CL • a

(-4 • • u • •£ • a,

:>. • • • * • • • • c • c • c • ^ • ^ • >i • c • • c • c • c • CO • • Q• !

>-i

i-t to * ^ * ^ * ^ r

r ^ • ^ r ^ • ^ • c • c • B • • Ul

*-* • • to

i-t • • 2 • z • to • a

to • t-( - > • c • > • >. • o • M • oc • >< • > • c • c • o • • U. • u • c • w 1 • • X• to • fa: lO • • l-i • • • • • * • to • c

tr ^ • c • • c • c • o • • t-l • c • a.

l-l • • b. • c • w • a: o ts • • X

to • • to • o • z • • l-l • U} • c • Ul Ci (o a. • > • 2 • >. • > • >• • >< • 2 • u • > • to • > • > • >. • c • c • 5 "t CO • • M • Z • to • <t u a. s: • • U. • o • »-* • ex. Cl • • u • Q • u u IQ o w w 5L • 03 U • • Ul w s: (-" to • • >

z: o to s: • > • >- • >< • c • > • >• • • • >. • > • > • >. • o • c • c • < CQ >1 cc m • s. to o • z

t-l t-* •J CN • n F-i fM •

«->

K

U • • u

«-< • > • > • >• • c • c • o • z • c • c • « X rf to • c • c • X • > • c • >. • c U O) • « • o U • C s. • • o • > • > • > • c • c • >. • c • c m 2 • >. • c • >. • c • c • c •

•1 X. • • X

<^ • u u«a 01 • E TJ • • >» O C • • Ul • >• • w • faj • H • Ul • c • u « • • b3 • X • u • sc • > • u. • f- • s<: • o. • in • x • E • to • Q • o • u • o • fl . u: • o - ua • •* • El • E • U) • o • 2 • o • to • :e • o • J • f-> • > • u • w • to • O • tt- • J • n • w • • Ul • c • u: • \li • z • u • X . bJ • L> • o • o • fau • ^ • to • t-^ • a. • c • to • »-i • «i • u • c •

75
• OI • "C • T • 11 • Li • Ii • E • 01 • Li • Lf • o • Ol • <D • w • o • 3 • u • • Li • u • *-> • o • L> • OJ • u • o • >< • 0; • Li • c • Li • U • L • o • c • o; • (T • G • O • £ • >- • a • t • c. • C • T! • M • 0) • Q • F • o • X • 01 • 4-1 • 01 • (fi • Li • c • Ol • t. • c • 4-1 • 1/; • 0; • *J • • o • ^ • ^ • C • c • ic • o • 1 • ^ • 4J • O • L • Li • Li • Li • c • t-t • E It • 3 • Li • O • o • O • o • O • 0; • ^ • Ol • O • o • *J • 4J • 41 • 4J • 41 • r • "O m 0! • 1-1 • u • o • IT. • £. • ^ • Li • c • 11 • (J • 4-1 • c • in • o; • <c • O • T • V • o • LI • L> • 4J • 4-1 • c • 01 • o • c • lA • C • Ol • u • in • 10 • in • in • tn • o; • (J • t1 • 44 • c • 0) • »-i • Li • 01 • 01 • o; • 0. • a.

ft/ • f—t • • Li • OJ • Li • o • 0) • c • c • 3 • 

• 4-1 • 4-1 • *-> • 4-1 • I- • 01 • 0) • Ii • a • Zl • Ii • o • ttl • in • •P z « «^ • E • c • »r • o • in • L. • «n • > • 3 • «' • (t • o • c • o • c • T • c • »-i • O • o • OJ • Z3 • £ • 4J • U • to • 4-J • 4-1 • 4-1 • C • 0; • "C • C • m • • O • K • o • O • o • 10 • o • - • (. & • IT • C • O' • o • u • in • .L> • Li • 01 • CT • c • c • c • c • c • (C • ^ • TJ • 3 • c • o • X3 • o • o • a • fc • C • o • o • o • o • L • X- • C • C * • »H • o • T3 • *J • Li • > • c • *j • ^ • ^ 4 la-f • • C • o • ^ • O • <0 • • o • n • Ol • • Li • 4J • o • *- • 4-1 • 4-* • <c • fr^ • 4-> • t) • > • i-1 • C • "C • o • T. • L. • > • E • (J • o • L> • u • u • o • o • ir. • *J • <( • 01 • 01 • «J • Ii • 0/ • i-l • O • It • c • Li • c • c • c • c • c

«-) • <c • • c • >i • m • • t; • o • 0.' • o • L> • 01 • O • p' • Li • 0/ • Li • 3 • V • 3 • 3 • 3 • 3 • "V • 10 • ^ • V • >- • Ii • o • ^ • Oj • D • Li • 01 • Li • c • 44 • 4-1 • ** • 4-1 • ^ c • -D • • u • o • ^ • 0) • c • Li - <c • O • o • <c • t: • o *-4 • u • c • <c • »J • L. • >! • o • c • c • C • C • a

-t-i • <0 • fti • T) • • O' • K • 0, • o> • c • u • D • O • <M • tJ • <0 • c • <s • V • X' *J • 0.' • X • u • ii • "^H • tl • Oi • 4) • > • o- • 4-> • U9 • iH • Li • Li • Ii • L. u • c • n. • a.' • £ • * • a. • «J • "O • CI ' o • c • Ol • Ol • V • T • U • if • It. • 4J • *J • tJ • • —4 c • o • T • in • c • o; • 4J • c • <c • -D • E • • w-i • u • c • Ol • o; • c • 0/ • L. • L. • L. • U • U • Cl • ^ • C • <c • • 3 • c • 0< • ^ • T • 01 • Ol • O • C • ^ • ii • O • O • O • o

u. • o k-^ • X • c • L3 • a. • < • a • 111 • o • < • w • 0. • u • L- • a. • t-i • o• 2 • tJ • >. • u •fI—I • >- • w • u • O •Il • Im: • c \ • c « l-( • c • M • ir> • in • M • n. • 2 • U • H4 • w • c • b;

to • «s • «^ • 0) • f-> • o • c • w • o • o • > • o • u • o • o • o • C • O • C • c c • u; • • >. • > • > • >. • Ui • c • F- • O • f-l * S • tt • c • CI • to • c • c • c • c • c • c • c • cr • U- • o • (0 • o • o • Ul • < • Ir" • O• Ui • 2 • X • z. • o • >> • >- • t/j • l-( • u • u • O •b. • Ui • a< w • c • »—1 • Cl • m • in • in • in • < • tt • 2 • o • • w • c • Ul • IT, • <. - 2. • OJ - o> • tl • o • 2 • w • «I • o • 2 • o • Ul • o • o • o • o • o • o • o- • a: • >. • > • >. • >. • u. • IE • 8-1 • o • O • a. • c • o • VZ * c • c • c • fc • c • t • • a. • U. • u. • o • O • W • o • c •U2 • X • < • E-i • U s • liJ ts • • 2 • • X • o • 2 • > • u • f-l • >- • in • X • u • u; • o • U.' • ^ • a

>v • c • • c- • » • in • la • in • o • a. • 2 • o • »-l • to • o • U' • n • WJ • *i • 2 • o» • Qt • o» • M • o • 2 • 10 • o • < • > • o • w • 01 • CI • c • c • o • o • o

s. • HH • I-* • • >. ' >. • >i • Li • W - H • C • o • o. • o • w • >. • >. • c • c • c • c • c c • a • • fc. • u . • K • o • c • 5. • c • . • < • r>

s. ; • f-l • bl • >< - u. • to • Ul • UJ • UJ • cc • > • bu • J—

• w • >c

05 • V. • c • a. • UJ • c • • Ul -u^ • o • u • bJ • o • 2 • «A • to • in • in • f-< • o • w • s • C • ij • «J • > • • u • m • in • in • n

(11 • a • <ll • 0) • o> • 0) • O • f-< • 2 • (ij • o • Ul • l-> • o • I/; • c • o » 01 * Oi • 01 • c o • o • o • u. • >. • >- • >< • > • u • c • (0 • l-l • • o • • *—1 • Si, • 3 • c m • >« • ^ • >f • • t- • o• U]

in • »J • f- • 2

•c • • t-i • »H • o • 2 • • to • • t- e t-i • (-1 •0£ • fr> C • >• • tc • u • * • 01 • o • I • u • u • o • U) • to • a. • a. • X. • X • Ul • sc. « • o * 9 • tl • c • SJ • o • a. • 2 • tj • »-t • tn • Ul • c • Ul • m • < • tH • cc • Ul • S • >« E • tS • 2 • «0 • «-l • s • «» • f-t • c-i • o • X • C • •* • u • > • u • Ul • a • a. • a. • 2; • 2 • a e • u: hH • o • c • o • a • u • U] • f-i • o * 2 • ct • o • 2 • o • to • u • s • Ul • 3t • bi • c o • a: • u. • bu « 15 • u. • w • u • c • U) • «I • »—1 • «i • »—( • c • Ul • s: • c • H • o c -76-
• • « •••• • a> • ti •

%-t • • -*j • • tr •• • c • • ^ • « <n • -.H • • X • • CI • • o •• • 4-> •

4^ • M • U) • 41 • in • 3 • m • <0 • • w • a; • m • 4-> • O • • > • 4J • tl • c • to • «< • M • ft) • 4-J •c • n • 1-4 • «c • O • * • k-l , o • * • • • n • *-> • IC • o • £. c " T? • « • t: • u • O o • »4 • M • T3 • o u • o • o • o • t) • o • "C • o • Q. • ft! • • • 01 c • w • t-a • • o • • • ^ • O • u 4) • o • 4-J • u • Qf • ft) • l-t • Oi • <y • O • l-l • i3 • Q • «n • £ u • 91

(J • Ifi • 01 • *-> • *J

IC • V • C • 10 • ft( • o;

4-i • c • 4) • o • ^ • «-!

4-> • -^ • a • »-l • ft) • 4» «t • • o • u • o • O•

s> • • • • w s • 10 • oc rv • • • «. • Z- • • s: • t5 • u fc-» • > • w • •-< • z. • to uu • o * IC • o * 1-3 • >« • u • to • a. • • W • a:

wa • «t • o • o • Ci ••*

«> •c • o ••• V ••

le »—f • CiJ • z • U]

c< 1—! • • o • u • (-< • > \ • c • 1—t • • u? • o

•—i

to • > • cc • u • o • 1-3 <6 z: • to • Ql, • ij • U3 c • •« • O • o • O

xz • u tn •

s. • bj

u fn •

10

>>

Xw •• • f-< • w • • u • Ul • o • o • o • o • <J • c • c • c • c • o • o•

flD ••• cc •• X •

(J •

cn • • P • z • u C • m - u • u • H • > c • o • »-l • z • to • U • O £ • bJ • *J E • z • «0 • o. • ij • u O • -» • «t • o • u • o

CI • « • c • «> • E • O' • ft) • ft) • c • M • ti • • o • u• 3 • ^ • U • m • 41 • a. • 4J • ft/ • fc • c • tfl • c • 41 • «H • ft) • »- • *J • c • o • X • -U • «-l • c • c • ^ • 4) • • o • c • 91 • 4) • ID • k< • • 01 • ^ • o • M • n • k- • TJ • 3 • • n • m • »s • « • T3 • ki • ft/ • *i • • "D • 4J • It • 3 • c • U • tl • •T3 • U • zy • O • t) • ^ • o • a • • 91 • O • \j • « • U • <kl • o • >< • • X • o • ft) • u • 91 • -(J • 4) • ftl • 4J • • 01 • 4) • X • c • • ftl • TI • u • to • • "O • U • 4) • "D . • lO • c • •-1 • « • 1-1 • c • • >M • *J • C • «f • li • o > 4J • • o • <r • wH • 3 • O • O • K • • t: • > • in • T) • • o • "C • c • ftl • T3 • c • -o • c • o • 41 • > • ki • —I • .H • <M • • ^ • ^ • >H • l-i • •^ • O • ft; • o • • tJ • 4J • t3 • O • « • •-1 ' V • C • 41 • «-i • *J • • 4-1. • T3 • 4J • <e • • b • « •3 • • c • 4) • k> • 41 • O • • ftl • X • u • *i. • 4) • 1^ • D • *J • • Z3 - 41 • 41 • ^ • 91 • • C • c • • c • • *J • H • O • *-> • <0 • <c • • • ftl • c • 4) • c • 4-1 • <-l • o • c • to • to • »-I • to • < •3 • u • a. • • u• < • < • u • e-i • i»j • • o • m • (E • • o • E- • >H • l-l • • v. • ec • b. • t£ • • o • o • bX • a • i-t • O • • E-" • f-1 • c • to • c • O • < •Q • to • • u: • IC • z • a • c • o • O • u; . • u -Ci • »-( - «t • J • s: •Q • • f-l • X • fa: • u • u • t-< • u • ii: • • H • fa} • >i • v. • o: • u. • bl • H • b. • Q • o • b: • b) • IX • < • »-l • z • z • z • to • o • t- •U • Q • O • • >-l • « • u • z • H • w • a • O • c • • fcu • o • •«0 • to • u • s. • a. • z • z • C3 • o • >s • H • l-> • ^ • -V • Z • CC • a • H • a

•3 • X • o • w • to • o • => • bJ • o • • U • 15 • c • *-4 • c • • cc • c •

•E- • >< • ua • u • • U • Ul • CD • • O • • t • • fa; • >• • l-t • • v. - a • K • bl • b. • tc • • Q • o • ba • u • OL • < • 11 • o • • Z • z • z • to • O • H • w • o • to • • *-f • M • u • z •H • fa: • K • o . u . • u. • b. • o • l-l • to • to • o •

-77-
A

T.O£

03in

a<uu • c

<e • o V • *J A ' c

x; • •-» • M c • * • « o • b c • o • ^ o • V • <c ^ • • > • c • o o • o • »J • 01 c • «w • —t * 4-1 • 01 m a

u. • K • t} • 3 • r^^ • *J

ft) • D. • 3 • • *J • rr n • c c • Ci • «

»-i • c • x: • • o• x « • b. CO • »-i ar • H • t-< • n o • s • c X • U • a. • s:

•t • H

U>

9i

N • X •V. • • fa; o tn •

z: ^ • • <

a. • H • H • O ^ o <• bZ • a.

to f- • C • a • 3 co

bi

10•H <o

«l >i o: 10 > • u w • c

hi • t-l • 2 • < • a: • b: • .J u • o. • a • u • Oo a u * fx • 01

uK

KCXu • bJ m • > • fa] T? • U • o C • 1—t • 2 • < « • cc • U) • t- • a. • a e • u - a • fai o • a: • < • cc •» c • C • o • « • --f • tJ • o • <c • •D • •-I • c • o> • o • Ut • »-. • •^ • o • 4J • 0; • « • le • a; • ki • ^ • a • k. • o • c • 4J • o • ki • <c • ti • >l-t • kl • SJ • « • u • X • «! • 01 • M • la • -c • O • ft • c • >*4 • c • C• o • IB • c • ^ • > • Ol • c • o • *> • • 3 • c • m-t • a • It • •-! • »H • "C • « • <c • «> • c • > • « • r-l • I' • o • 01 • o • <W • « • <W • 0) • O • o • « • 01 • *J • « • D • > • 3 • C • * • o • O • ftl • <c • »J • (-> • *J • • K • *> • c • • • 9i • w • 0) • 0/ a ti • 0) • l-> • u •£ • t) • o • o. •u • f- • >« • X

•fa] • o • «* •f- • a • •J • t. •Ci. •faJ • w • « • O • K • l>- •U • e • o • x • • o

•t- • a • A • H

•bl •10 • o • O • (K •K • c • (W • 2 • U • O• X • fa: • o • s^ • cc •X • fa: • «t • F- • fa] • u • fa] • 10 • C) • 2 • cc • fa] • o • z • < • o • e • c • >-i • oc • X •X • fa] • o • <: • H • a • J • X • fa] • •« •i-t • CL • fa] • o • fal • w • w • D • 2 • ac • fa] • -I • 2. • «S • i_> • a • Q • »H • a « • c • > o •• • 4-> •• ^ • • 0* ••• • C • v • • O • • • •H • > k> • • 4J • • o • • «; • > <«4 • • t-l • • • 0) • « • » u • • o • • 0. 'C • 01 • m • «o • • 4J • c • te • « • Ol • o • c • « • U • <H • » E • •^ • o • X; o O • • *J • »^ • • a • M • 10 • to • 4J • B • > 09 • —t • « • *J - w • 01 • • 0» • «) • ^ • « • T5 • 3 •

fj • k< • « • T3 • • > u • kl • • « • (B • > « • <c • > • • o> • • > > Ol • *-> • c • 0; • O • o • 0< • W • > • • c • »> • JC • « • *J • O • » IB • £ • E • 0.- • m • e • • x: • O • O • U • Ol • Ol • • o • w • u • • o • cc •

:*• • (L • oa • O • fa] • Q • X

•H • 2 • fa} • o • Ul • • fa: * §-4 • lr> • cc • fc* • • w • o: • < • t- • fa] • > o •CE • • fa] •10 • iJ • • c • 3 • o • O. • fa] • fa] • • ta • t> •U • Q • a • •• • sc

•> to • a • o • X

X • fa] • o . u • b. • H • a • (-. • • IH • < • H • fa] • > o • o • o • u • W • J • o • c • c • cc • fa: • fa] •

s. • o • c • o • •• • ta • cc. • c • o • X- X • fa^ • c . u: . • H • cc • fi •

l-l • < • f- . Ui . « o • fa] • Ui • .J • o • o • o • a: • fa] • fai . > z • c • c • u • c • o • •• • m

•03 • o • fa] • Q • X

X •El • 2 • fa] • o • fa] •

fa. • fa] • l-l • f-> • cc • E-< •

l-l • to • (Q • < • H • fa] • o • cc • s: • fa] • CO •J • o • 3 • o • K • fa) • u .

:e • «0 • «j • U • Q • o •

-78-
ft. • • > c • m • • ID • 1^

ID • £ • * • 4-* £ • %> • w • V* • • c

«-* • t-H c • T! • »w • * • w c • *H o • • IC X. • K • 4-> • Of • • c • • fl) • X u • c • lA • or • • S c • fl^ • O • T3 • fl3 • u • o. • • C • O • o • o • (-1 • J • to

CM • • u

fN • z • w • c • C S • u; • c • 'z • «t • o> • Ci. • • o • o • o • u. • *u • to >* • a. • IT • CO • or. ta • a • a • D • £- • Q cO

z.

i£ • • u:

o* • M • v> • a • c • u • tJ • 0> • w • «t • 41 >^ • >• • >> • X • C' • >i

to • • 3i • >J

«-> n

ws

•1 bi •H fXi

4) >" El ta • u• CO • C • Ci • O • z • O • • ».3 • »—

• • O • U • bu • U- • • bu • Ui • U. • O • »-l • f-» • t-H • »-4 • c OKX •

V) •• • z c • • u • u • to • Q • o • K E • Ci? • c • z • <tf • *ac E • a. • fH • o • l»3 O • c • t> • >J • to • T3 • f-H • «» • ^ • "C • kl • c • O • 3 • <u • o • ft> • 1*4 • ft) • VI • • m • jD • x* • T5 •Ci • «B • c • k> • 4J • o • o • •4-4 • o • o • m • o • Sh • *4 • * • TJ • * • ka • c • V • »W • C • o • o • ^ • O • ^ • 3 • o • 01 • 4.1 • fti • n • T • u • c • C • C • W) • o • ft/ • c • T3 • 3 • 0) • 3 • o • ft) • 4-> • C • O • 3 • ft.' • 4J • c • o • 3 • «w • c • • <B • 'M • O • • • n • c • ftj • o • %4 • Vi • > • T3 • <w • • D. • lA • T3 • k> • o • it • o • T3 • m • Ih • O • an • ft) • Ui • T3 • o • #H • O • a • ^< • o • • u • « • 3 • T3 • O • u • O • w • ^ • O • • o • <J • t> • t1 • i» • ft) • o • a> • i-t • QJ • » • W • V* • l-i • ftj • fti • ft) • eo • ft) • *-> • *J • c • c • « • ft) • 4.J • c • 4-> • Ol • c • k< • « • > • 3 • w> • ^ • <c • T3 • O • ft) • O • o • £ • T3 • C • ll • to • U •lO •Q • < • «a. • n • o • U) • u • H • oc • O • > • bJ • a • • ^ • C • o • iJ • >* • *^ • ac • o • b^ • X • Ci • c • .J • u • to • a • to • C • C) «* • •* • < • Sir • O- • (D • cc • CD • (£ • (E • ct • (E • CE • o •O • o • c • Q • C • Q •Q • c • bJ • U • O • t- • t-< • o • 2 • E • (0 • U • z. • U • to • > • 3 • 01 • iJ • <. • o • a. • O • ft: • < • O • >1 • u • X • c • Ck< • c • > • to • o • c • t> • • «t. • t- • bJ • u • 2 • t-l • a. • Q • J • 3 • b] • f- • o • C • v-^ • O • vc • • E-* • M • u. • o • c • Ol • lO • b. • Ui • b. • o • b. • b. • (i. • b. • o • O • l-l • i-^ • c • »-< • (-4 • l-l • J-l • c • C • >* • bl • U) • si • b) • u • o • < • 2 • \r* • H • I? • zt * u • 3 • Z • • U • z • bJ • o • Vl • > • 3 • J • •« • o • • •-3 • >> • o • c • b) • X • Q • a. • 1-3 • bl • to • o • to • C • «t • « • < • ft) • 1.1 • 3• •D • ft) • U • c • o • u • V* • 3 • £1 • 4J • ft) • • > • »-. • 10 • 4-* • > • ^ • "C • ft) • c •G • • e • o • <0 • k< • ft) • <D • c • ki • 4-> 4-> • in • 3 • in • O • ft) • m • O • E • VI • • > • ft) • 'M • % • V) • 3 • k. • ft) • in • ft) • m • C • k. • 3 • ft) • 3 •T3 • o • v: • 3 • O • C • c- • »- • k> m ;r • 4-1 • ^ • ^ • ft) • O • o • a. • o • ft; • > • 0) • i • n • o • c • 3 • r-l • 4J • c • "V • ft) • t • t-i • i3 • U • c • o • 0) • tl • ft.' • V. • o • 4.) • to • a • 3 • 4J • 'Z • 4-i • in • 4J • O • o • ft) • kl • in • c • E • a • 4J • 3 • o • > • a • V • « • > • O • D • +4 • Wl • c • 4J • ftj • U • o • V • C • o • « • <*J • ft) • c • In • Wl • ki • 4.> • • £ • •*-l • «> • 0) • ft) • ft) • U • .-1 • 01 • 3 • 11 • ^ • 4/ • > • 3 • 4J • —* • 4-> • c • 4-' • « • ^ • C • ftj • a • <c • <c • o • 15 • .-1 • E • ^ • .-1 • 3 • »^ • > • • «-4 • a • »H • 4J • XI • 4-> • ^ • 4J • 4-1 • C • • • 4J • ^ • 4-> • T • ^ • ^ • D • o • c • QJ • c • ft) • c • C • c • Ci • O • KJ •U) • to • l-l • O L' • U3 • 1- • o • J • b. • t- • E-> • J • o • s • z • a • Ul • <e • ^1 • «-< • l-l • o • o • o • O • o •15 •l; • U3 • u. • c • cc • c • c. • c • c • ct • IT • a • a. • c • c- • C • Q • c • aj • cc • X• fV • >^ • a. • IC • tM • u • «n • in • in • M • in • c • to • to • 0) • «> • «> • o • ft) • 0> • O • s; • t- • bj • >. • >. • >. • c • >. • >. • c • w • 10 • c

•H • bj • a • ij • >:3 • X • f-. • a. • ^ • «! • o • f- • .J • to • oc • c • X • •—i • z • b; • < • ^ • f- • 2. • o • Q • b.' • u • «_> • b. • to • o • O • u. • b. • b. • u • bl • b. • b. • u. • c • c • t-t • 1-4 • M • HI • l-l • 1-1 • 1-4 • b3 - Nl • a • E • »-l • bl • X • CC • X • H • C • to • H • o • l-l • Ul • a • J • >> • J • l-l • a • b. • H • (X • >i^ • •« • o •f- • >.3 • z • < • O- • o • X • l-l • 2 • W • «S • »-l • (-1 • o • s: • u • O • U] • U • b. • 03

79
7.6 APPENDIX 6 - DATA DICTIONARY/DIRECTORY

++Def inition .

A data element d i ct i ona ry/ di rectory (to be referred to

in short as data dictionary (DD)) is a software tool that is

used to control the totality of data elements within an application. It is viewed as the central repository of all

descriptive information about each data element contained

within an application data base. It lists, describes, and

locates each data- element in a data base. The dictionary

does not manage the actual content of the data, but it does

manage the descriptive characteristics of data.

The dictionary portion is a glossary of terms of data

elements representing their characteristics and logical relationships with data base components and application usage.

The dictionary describes what data are contained in the

organization's data base.

The directory portion contains object data definitions

as used by the computer, plus physical storage locations and

access strategies. The directory locates where data are

stored

.

++ Usage .

The DD serves the database administrator, systems

analyst, software designer, and programmer by providing a central repository for information about data resources. It

aids people in planning, controlling, and evaluating the

collection, storage, and use of the data resources.

As a documentation tool, it captures descriptive information and aids in establishing standards for data naming,

usage, and coding conventions. It identifies users or programs which may be affected by any changes, additions, or

deletions to the data.

If the DD is interfaced into the structure of a DBMS,

tiien it may be used for generating the data description

language of the DBMS, maintaining data descriptions and compiling or interpreting program references which use these

descriptions.

-80-
++ Functions ojf Data Pi ctionary . The primary function of a DD is to provide a method of

centralized control over data elements. The following are

some functions of existing DD. No one system performs them

al 1 .

Data attribute - Name, Length, Type

Data relationship - The structural properties among

data

Synonyms - Allow alias capability

Textual description

Access control specification

Edit and validation check rules - e.g., null and default values, ranges of value permitted, etc.

Output decoding specification - coded values to be

translated so that it is human- readabl e

.

Key/Non-key - Indicate whether the data element is

meant to be searchable or not.

Physical storage specification - logical and physical address, internal representation, compaction,

etc

.

Usage information - cross-references to users, application programs, and output reports.

Frequency of access - usually used for statistical

monitoring purposes.

++Ty pes and Commerc i al Dd '

s

. There are at present at least four broad groups of data

dictionary systems existing in the market that can be identified :

-81-
* Type A - The free-standing package which could be used

in a non-DBMS environment.

DD

Examples of commercial DD are:

DICTIONARY SUPPLIERS

DATA CATALOGUE Synergetics Corp.

DATAMANAGER Management Systems & Programming, Ltd.

LEXICON Arthur Anderson & Co,

* Type B - The free-standing package that optionally provides interfaces to one or more DBMS.

Examples of commercial DD are:

DICTIONARY SUPPLIERS DBMS INTERFACE

DATA CATALOGUE

DATAMANAGER

Synergetics Corp

Management Systems

and Programming, Ltd

IMS, TOTAL

ADABAS

IDMS, IMS, TOTAL

LEXICON Arthur Anderson & Co IDMS, IMS, TOTAL

-82-
* Type C_ - The single data dictionary package designed to

co-exist with a particular DBMS. This type of data dictionary is solely dependent on the DBMS and usually developed

and marketed by the same vendor.

Examples of commercial DD packages are

DICTIONARY SUPPLIER DBMS REQUIRED

Control 2000

DB/DC Dictionary

UCC TEN

Data Control System

Data D i c t i 0 n a ry

IDD

MRI Systems

IBM

University Computing

Haverly Systems

Ci ncom Systems

C u 1 1 i n a n e

System 2000

IMS or DL/1

IMS

DMS-1100

TOTAL

IDMS

* Type D - The data dictionary that is embedded within a DBMS. The data dictionary function usually is part of the

data definition function and the meta-data is stored as part

of the database for the DBMS.

Examples of commercial DD are:

DICTIONARY SUPPLIER DBMS REQUIRED

GIM II Dictionary TRW GIM II

-83-
++ I n f o^rmat 1 on I n _a Data Pi ctionary System .

A data dictionary captures information about data elements. Some of this information seems to be provided by all

data dictionary packages and deemed essential while others,

though desirable, may be omitted at the discretion of the

impl ementor

.

To concentrate on the information requirements of those

involved in data and database administration, several types

of information usage were identified. Certain information

is captured to be used by people for documentation and control purposes, while other information is necessary for the

generation of data definition language, data manipulation

language and application program processors. For illustrative purposes the following table shows the information captured in a data dictionary and its uses by various users.

-84-
•1!

II

II DDL

II

• 11

11

11 DML II Appl ication

II Processor

11

• 11 -

I n format i on

in DD

People

Name, Type

Length

Structure

Relationship

Synonyms

Textural Desc.

Access Control

Edit & Val idat ion

Key/Non-Key

Usage Info.

Freq. of Access

Physical Storage

Specification

-85-
7.7 APPENDIX 7 - END-USER/QUERY LANGUAGE

The following subjects were considered when preparing

the End User Facility recommendations.

++ L i St of End User F a c i 1 i t i e

s

.

1. Report Specification Language

2. Enquiry Specification Language

3. Update Specification Language

4. Parametric Interface

++Li_st £f Classes Of Users .

1. System Anal yst s/DBA ' s Staff

2. Application Programmers

3. On-line Job- trained User

4. Researcher

5. Casual User

++Measures of Query Languages .

1. Quantitative Measures

a . Level

b. Completeness

2. Qualitative Measures

a. Mathematical Sophistication

b . Learnab i 1 ity

c . Procedural ity

++ Li St of Variable Features In End User F a c i 1 i t i e

s

.

A. Procedural ity

1. Procedural

a . logic

b. navigation

2. Non- proced ural

a . form fill

b. question/answer

c . menu

B. Report formatting

a . flexible

b. pre-f ormatted

c. automated display of draft format

-86-
d . construction assistance

C. Request Analysis

a . monolithic

b. incremental

D. Level

a. % code reduction vs. COBOL (keystrokes)

b. % coding tim'e reduction vs. COBOL

E. Default treatment

F. Ratio of simplicity to functionality

G. Retrieval criteria permitted

a. mathematical operators

b. logical operators

c. string operators (begins, contains)

d. set functions (count, sum, mean, standard development,

maximum, minimum)

H. Cascading retrieval

I . Extensibil ity

J. Processing of conditionals

K. Update capabil ity

a. within queries

b. similar to query syntax

c. special syntax

d. transaction oriented

e. form-fill

L. Navigation

a. DBA intervention required to change access paths

b. fixed path chosen

c. multi-path ambiguity negotiated

M. Execution efficiency

N. Aggregation operations

a . sort f 1 exibil ity

b. sort efficiency

c. data clumping capability

0. Reusability of user constructs

a

.

s i m p 1 icity of retention

b. s i mpl ic i ty of t empora ry mod i f i c at i on

c

.

s i mpl icity of permanent modi f i cation

P. Data type support

-87-
a. different types handled

b. conversion support

c. ease of addition of special types

Q. Fog index

a. documentation

b. syntax

R. Benchmarking

-88-

ilrU^. GOVERNMENT PRINTINeomCE: 1S79 0—281-067 (173)
HBS-114A IREV. 9-78)

U.S. DEPT. OF COMM. BIBLIOGRAPHIC DATA

SHEET

1. PUBLICATION OR REPORT NO. NBS SP-5OO-5I

2, Gov't Accession

4. TITLE AND SUBTITLE

RECOMMENDATIONS FOR DATABASE MANAGEMENT SYSTEM STANDARDS

7. AUTHOR(S)

FTPS Task Group on Database Management Systems Standards,

J. Berg. Chairman

9. PERFORMING ORGANIZATION NAME AND ADDRESS

NATIONAL BUREAU OF STANDARDS

DEPARTMENT OF COMMERCE

WASHINGTON, DC 20234

5. Publication Date August 1979

$. Performing Organization Code

8. Performing Organ. Report No.

12. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City, state. ziP)

m. Projea/Task/Work Onit No.

11. Contract/Grant No.

13. Type of Report & Period Covered Final r—J7

15. SUPPLEMENTARY NOTES

Library of Congress Catalog Number: 79-600087

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

16. ABSTRACT (A 200-word or leaa (actual surmnary of moat significant information. If document includes a significant bibliography or

literature survey, mention it here,) In March 1911 , FTPS Task Group 2A initiated a study of the need for

database standards within the FedersLl government. The voluntary participants

from several Federal agencies considered the actions of other standards bodies;

reviewed the alternatives to Federal standards; examined the issues of standards

adoption, timing, and impact on technology; developed a method for justifying

standards, and attempted to anticipate likely database technology advancements.

TG-24 recommended standards in certain specific technical areas,

concluded that standards were premature in others, and emphasized the need

for certain guidelines.

This final report of TG-24 contains the recommendations for standards,

and guidelines as well as the assumptions, benefits, and costs considerations

used to justify the recommendations.

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 setnicolons) Database; DBMS; data-description; data-dictionary; data-directory; data-manipulation;

languages; query; standards.

18. AVAILABILITY [S Unlimited

I I For Official Distribution. Do Not Release to NTIS

[^]fOrder From Sup. of Doc, U.S. Government Printing Office, Washington, DC

20402, SD Stock No. SN003-003-0 20 9 5 - 8

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

19. SECURITY CLASS

(THIS REPORT)

21. NO. OF

PRINTED PAGES

UNCLASSIFIED 99

20. SECURITY CLASS

(THIS PAGE)

22. Price $3.75

UNCLASSIFIED

USCPMM-J3C

NBS TECHNICAL PUBLICATIONS

PERIODICALS

loURNAL OF RESEARCH—The Journal of Research

f the National Bureau of Standards reports NBS research nd development in those disciplines of the physical and

ngineering sciences in which the Bureau is active. These

iclude physics, chemistry, engineering, mathematics, and

omputer sciences. Papers cover a broad range of subjects,

/ith major emphasis on measurement methodology, and

le basic technology underlying standardization. Also in- luded from time to time are survey articles on topics closely

elated to the Bureau's technical and scientific programs. As

. special service to subscribers each issue contains complete

itations to all recent NBS publications in NBS and non- ^BS media. Issued six times a year. Annual subscription:

lomestic $17.00; foreign $21.25. Single copy, $3.00 domestic;

13.75 foreign. ^ote: The Journal was formerly published in two sections:

Section A "Physics and Chemistry" and Section B "Mathenatical Sciences." piMENSIONS/NBS

ifhis monthly magazine is published to inform scientists,

ijjngineers, businessmen, industry, teachers, students, and

consumers of the latest advances in science and technology,

jvith primary emphasis on the work at NBS. The magazine

lighlights and reviews such issues as energy research, fire |Drotection, building technology, metric conversion, pollution

ibatement, health and safety, and consumer product per- formance. In addition, it reports the results of Bureau pro- grams in measurement standards and techniques, properties

bf matter and materials, engineering standards and services, instrumentation, and automatic data processing.

Annual subscription; Domestic, $11.00; Foreign $13.75

NONPERIODICALS

I jlVIonographs—Major contributions to the technical liter-

[ iature on various subjects related to the Bureau's scientific

j jand technical activities.

[ iHandbooks—Recommended codes of engineering and indusitrial practice (including safety codes) developed in cooperajtion with interested industries, professional organizations,

land regulatory bodies.

^pecial Publications—Include proceedings of conferences pponsored by NBS, NBS annual reports, and other special

jipublications appropriate to this grouping such as wall charts, Ipccket cards, and bibliographies.

hiAppIied Mathematics Series—Mathematical tables, manj iuals, and studies of special interest to physicists, engineers,

!|;chemists, biologists, mathematicians, computer programmers,

jiand others engaged in scientific and technical work.

jNafional Standard Reference Data Series—Provides quantitative data on the physical and chemical properties of

j materials, compiled from the world's literature and critically

ij evaluated. Developed under a world-wide program coj ordinated by NBS. Program under authority of National

1' Standard Data Act (Public Law 90-396).

NOTE: At present the principal publication outlet for these data is the Journal of Physical and Chemical Reference Data (JPCRD) published quarterly for NBS by the American Chemical Society (ACS) and the American Institute of

Physics (AIP). Subscriptions, reprints, and supplements

available from ACS, 1155 Sixteenth St. N.W., Wash., D.C.

20056.

Building Science Series—Disseminates technical information developed at the Bureau on building materials, components,

systems, and whole structures. The series presents research

results, test methods, and performance criteria related to the structural and environmental functions and the durability

and safety characteristics of building elements and systems. Technical Notes—Studies or reports which are complete in themselves but restrictive in their treatment of a subject.

Analogous to monographs but not so comprehensive in scope or definitive in treatment of the subject area. Often

serve as a vehicle for final reports of work performed at NBS under the sponsorship of other government agencies.

Voluntary Product Standards—Developed under procedures

published by the Department of Commerce in Part 10, Title 15, of the Code of Federal Regulations. The purpose

of the standards is to establish nationally recognized require- ments for products, and to provide all concerned interests with a basis for common understanding of the characteristics of the products. NBS administers this program as a supple- ment to the activities of the private sector standardizing

organizations.

Consumer Information Series—Practical information, based on NBS research and experience, covering areas of interest

to the consumer. Easily understandable language and

illustrations provide useful background knowledge for shopping in today's technological marketplace.

Order above NBS publications from: Superintendent of Documents, Government Printing Office, Washington, D.C.

20402. Order following NBS publications—NBSIR's and FIPS from

the National Technical Information Services, Springfield, Va. 22161.

Federal Information Processing Standards Publications (FIPS PUB)—Publications in this series collectively constitute the Federal Information Processing Standards Register.

Register serves as the official source of information in the Federal Government regarding standards issued by NBS

pursuant to the Federal Property and Administrative Services Act of 1949 as amended. Public Law 89-306 (79 Stat. 1127), and as implemented by Executive Order 11717

(38 FR 12315, dated May 11, 1973) and Part 6 of Title 15 CFR (Code of Federal Regulations).

NBS Interagency Reports (NBSIR)—A special series of

interim or final reports on work performed by NBS for outside sponsors (both government and non-government).

In general, initial distribution is handled by the sponsor;

public distribution is by the National Technical Information

Services (Springfield, Va. 22161) in paper copy or microfiche form.

BIBLIOGRAPHIC SUBSCRIPTION SERVICES

I The following current-awareness and literature-survey bibliI ographies are issued periodically by the Bureau:

I Cryogenic Data Center Current Awareness Service. A litera- ture survey issued biweekly. Annual subscription: Domestic, $25.00; Foreign, $30.00.

Liquefied Natural Gas. A literature survey issued quarterly. Annual subscription: $20.00.

Superconducting Devices and Materials. A literature survey

issued quarterly. Annual subscription: $30.00. Send subscription orders and remittances for the preceding bibliographic

services to National Bureau of Standards, Cryogenic Data

Center (275.02) Boulder, Colorado 80302.
U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Washington, D C. 20234

OFFICIAL BUSINESS

Penalty for Private Use. S300

POSTAGE AND FEES PAID

U.S. DEPARTMENT OF COMMERCE COM-215

SPECIAL FOURTH-CLASS RATE

BOOK