recommendations for database management system standards

i

i

i

A111D3 OTDMfib

:NCE & TECHNOLOGY:"PSTaskG™loI°^090486

C.2 NBS-PUB

National Bureau of Standards

Library, E-01 Admin. Bldg.

OCT 1

o -j n c: Qw -L L' D U

RECOMMENDATIONSFOR DATABASEMANAGEMENT SYSTEMSTANDARDS

NBS Special Publication 500-51

U.S. DEPARTMENT OF COMMERCENational 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 DATABASEMANAGEMENT SYSTEM STANDARDS

FIPS Task Group on Database Management System Standards

Center for Programming Science and TechnologyInstitute for Computer Sciences and TechnologyNational 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 ADPstandards, 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-51Nat. 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, 102.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 133.1.3 General Assumptions 13

- i i i -

3.1.4 General Benefits 143.1.5 General Cost Considerations 14

3.2 TERMINOLOGY 16

3.2.1 Background 163.2.2 Recommendations 163.2.3 Justification 16

3.3 DATA DESCRIPTION LANGUAGE 17


3.4 DATA MANIPULATION LANGUAGE 21


3.5 DATA DICTIONARY/DIRECTORY FACILITY 26


3.6 QUERY LANGUAGE/END USER FACILITIES 28


4. RECOMMENDATIONS FOR GUIDELINES 30

4.1 BACKGROUND 30

4.2 RECOMMENDATIONS 31

4.3 JUSTIFICATION 33

4.3.1 Assumptions 334.3.2 Benefits and Cost Avoidance 334.3.3 Costs 33

5. MISCELLANEOUS RECOMMENDATIONS 34

5.1 REDUCING STANDARD ADOPTION COSTS 34


- i V-

5.2 DATABASE STANDARDS IN OTHER MAJOR AREAS 35

5.2.1 Background 355.2.2 Recommendation 355.2.3 Justification 35

5.3 TRANSITIONAL STANDARDS ACTIONS 36

5.3.1 Backg round 365.3.2 Recommendations 36

5.4 PRIORITIES WITHIN THE RECOMMENDATIONS 37

5.4.1 Background 375.4.2 Phasing Recommendations 375.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 NationalBureau of Standards (Institute for Computer Sciences andTechnology) has responsibilities to develop Federal Informa-tion Processing Standards (FIPS). Three major goals aresought in Federal standards: improved competition amongvendors providing computer systems or services to thegovernment, improved procurement procedures, and improvedinterchange of data and programs within the Federal govern-ment. FIPS publications may be either standards or guide-lines. A standard is a precise statement of required func-tions or actions, while a guideline advises and suggests ac-tions. Examples of standards range from the data codes forstate abbreviations to the complex COBOL language specifica-tions. Examples of guidelines include the published recom-mendations for physical computer security and privacy pro-tection.

To assist the National Bureau of Standards in its con-sideration of FIPS standards. Task Groups are sometimes es-tablished to address specific subject areas. These TaskGroups are advisory bodies made up of volunteer participantsfrom Federal agencies. Task Group 24 on Data Base Manage-ment Systems is such a group. TG-24 purpose, scope, and pro-gram of work are contained in its charter. Appendix 1 ofthis report.

The issues addressed by Task Group 24 are important,complex, and highly technical. The recommendations of theTask Group are valued contributions to our work as represen-tative statements of requirements. They are not necessarilythe technical judgments or current positions of NBS. Theseviews provide a concrete reference point for others to addtheir comments and recommendations. In each area addressedby the Task Group, NBS has underway a thorough study, in-cluding a cost-benefit analysis, leading towards a proposedFederal standard if warranted by the conclusions of continu-ing study. Our analyses coupled with continuing input fromFederal agencies will guide the final decisions on Federaldata base standardization. Consequently, we publish thisreport to invite additional comment. We will continue toseek comment as we proceed through the various steps towardstandard i zat i on

.

S. Jeffery, DirectorCenter for Programming-

Science and Technology

VT-

ACKNOWLEDGEMENTS

The National Bureau of Standards acknowledges its gra-titude to the following TG-24 participants and their spon-soring organizations for their important contributions tothe work of the Task Group.

Robert Ambrose, National Security AgencyChristopher Avery, Department of AgricultureAnn Bandurski , Naval Ship Research CenterJohn Berg, NBS, ChairmanEdward M. Carter, USAFJohn Cooley, Federal Energy AdministrationMichael Corrigan, Defense Communications AgencyDonald R. Deutsch, NBSElizabeth Fong, NBS, Executive SecretaryHarry Fujiwara, Department of Housing, Education and WelfareDave Gurtner, Veterans AdministrationRick Holt, National Library of MedicineWassil Lagoey, US ArmyLois Morin, Office of Management and BudgetHoward Nathanson, Federal Home Loan Bank BoardJanet Nathanson, Pension Benefit Guaranty Corp.Richard W. Pelc, General Services AdministrationChristy Pino, Central Intelligence AgencyOren P. Phipps, Defense Communication AgencyRalph Rutherford Jr., Defense Intelligence AgencyRobert Schmid, US ArmyEd Thomas, General Services Administration

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

Julian Adler, State DepartmentWalter Frederic, Health, Education, and WelfareR. Michael Gall, Civil Service CommissionFrank Manola, Naval Research LabsPaul Oliver, US Na vyNeal Seago, Government Accounting OfficeEdgar Sibley, University of MarylandDave Weinstein, Central Intelligence AgencyRoxanne Williams, Department of Agriculture

- V i i

EXECUTIVE SUMMARY

The need for standardization in database managementresults from the increased usage of database software andthe increased demand for data interchange within the Federalgovernment. To meet this need. Task Group 24 recommends thefollowing actions:

++Te rmi nol ogy

.

1. A standard set of data base oriented terms should beestablished, should be coordinated with the work ofISO, and should be included in the current ANSIstandard data processing glossary.

2. Guidelines should be established which encourageDBMS developers to use this glossary when describingdatabase concepts.

3. Guidelines should be established whereby vendors areencouraged 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 requiredthat contains the common description of the dataelement (attributes) and the facility to describemultiple data structure classes.

2. The specification of the standard description ofdata attributes should be similar to the attributesin the PICTURE and TYPE clauses of the CODASYL DDL.

3. The specification of the standard description ofdata structures should be required to encompasscurrent data models such as the hierarchical, net-work, and relational.

4. Consistent with recommendation 1, the standarddescription of the network data structure within theDDL should be based on the CODASYL DDL.

5. Consistent with recommendation 1, companion datastructure descriptions for the hierarchical and re-lational data models should be developed.

- V i i i -

1. Develop multiple Datadards specifications.

Manipulation Language stan-

2, [Develop a data manipulation language standardspecification:]

(a) For each standard host programming language(e.g., COBOL, FORTRAN), develop immediately a stan-dard DML specification for each category identifiedby TG-24.

(b) As a short range goal, develop a single standardDML specification for a given category that inter-faces with all standard host programming languages.

(c) As a long range goal, develop a single standardDML specification containing the functionality ofall categories.

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

1. Data dictionaries used by Federal agencies must beable to produce the standard DDL attribute descrip-tion as recommended in Section 3.3.2 by the DDL Sub-committee of TG-24. (TG-24 took no position on thestandardization of data dictionaries but addressedonly those data dictionaries with an interfacebetween the data dictionaries and the DBMS whichmust be standardized.)

2. The design of data dictionary must be capable ofcombining standard data attribute descriptions withdata structure descriptions to generate the DDL forone or more DBMS.

3. Establish guidelines on the data dictionary usage.

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

s

1.

2.

Standardi zationfac i 1 i t i es iseasily learned,dent, and there"styl es."

of syntax and semantics of end-usernot required. Such facilities areproblem and subject-matter depen-are a diversity of end-user facility

Guidelines should be developed to aid the specifica-tion of requirements of end-user facilities forFederal procurement purposes.

++ $tandards Adoption.

1. The standards recommended should not be mandatoryuntil other factors determine a change to therelevant systems.

2. Standards can be required for new applications orsystems without requiring existing systems to

also conform to the standard.

++ Other Major Areas.

1. TG-24 recommends that the database standards actionsdescribed above apply to database facilities pro-vided by computer services, distributed systems, andmini computers

.

-X-

RECOMMENDATIONS FORDATABASE MANAGEMENT SYSTEM STANDARDS

The Federal Information Processing StandardsTask 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 withinthe Federal government. The voluntary partici-pants from several Federal agencies considered theactions of other standards bodies; reviewed thealternatives to Federal standards; examined theissues of standards adoption, timing, and impacton technology; developed a method for justifyingstandards, and attempted to anticipate likely da-tabase technology advancements.

TG-24 recommended standards in certainspecific technical areas, concluded that standardswere premature in others, and emphasized the needfor certain guidelines.

This final report of TG-24 contains therecommendations for standards and guidelines aswell as the assumptions, benefits, and costs con-siderations 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, likethe rapid growth noted in private industry, increases year-ly. Each database system differs from the others and inhi-bits the interchange of skilled personnel, programs or dataamong these different systems. Even similar systems haveslight differences that prevent quick interchange.

-1-

The resultant growth in the number of diverse databasesystem undermines Federal goals sought by the standardiza-tion of programming languages and other software components.In view of the predicted hardware conversions within theFederal government, and the even greater likelihood ofoperating system and peripheral device changes over the nextten years, database technology will not meet its potentialof facilitating conversion and may even worsen the conver-sion problem.

Current standards work is being performed in severalareas of database technology but many other areas are beingoverlooked. While voluntary DBMS standards actions in theAmerican National Standards Insti tute(ANSI ) are underway,these actions require close, cooperative monitoring to in-sure that they will meet Federal needs and time frames.

1.2 BRIEF STATEMENT OF RECOMMENDED SOLUTIONS

This report contains a specific recommendation todevelop a family of database standards for the Federalgovernment. The Task Group recommends the following ac-tions:

++Terminol ogy .



3. Guidelines should be established whereby vendors areencouraged to utilize DBMS language syntax which iscompatible with this glossary.

++Da ta Descri pt i on .


2. The specification of the standard description, ofdata attributes should be similar to the attributesin the PICTURE and TYPE clauses of the CODASYL DDL.

-2




++Data Manipulation .

1. Develop multiple [Data Manipulation Language] stan-dards specifications.

2. [Develop a data manipulation language standardspecification:]

(a) For each standard host programming language(e.g., COBOL, FORTRAN), develop immediately a stan-dard DML specification for each category identifiedby TG-24.


(c) As a long range goal, develop a single standardDML specification containing the functionality ofal 1 categori es

.

++Data Dictionary .

1. Data dictionaries used by Federal agencies must beable to produce the standard DDL attribute descrip-tion as recommended in Section 3.3.2 by the DDL Sub-committee of TG-24. (TG-24 took no position on thestandardization of data dictionaries but addressedonly those data dictionaries with an interfacebetween the data dictionaries and the DBMS whichmust be standardized.)

2. The design of data dictionary must be capable ofcombining standard data attribute descriptions withdata structure descriptions to generate the DDL forone or more DBMS.

-3-


++End-user/query Facilities .

1. Standardization of syntax and semantics of end-userfacilities is not required. Such facilities areeasily learned, problem and subject-matter depen-dent, and there are a diversity of end-user facility"styl es."

2. Guidelines should be developed to aid the specifica-tion of requirements of end-user facilities forFederal procurement purposes.

++Standards Adoption .

1. he standards recommended should not be mandatoryuntil other factors determine a change to therel evant systems

.

2. Standards can be required for new applications orsystems without requiring existing systems to alsoconform to the standard.

++Other Major Areas .

1. TG-24 recommends that the database standards actionsdescribed above apply to data base facilities pro-vided by computer services, distributed systems, andminicomputers.

1.3 PURPOSE AND METHOD OF FIPS TG-24

The work of FIPS TG-24 followed its charter which ap-pears in Appendix 1 of this report. This charter containsFIPS TG-24's purpose, scope and program of work. NineteenFederal agencies contributed to this report over the courseof one year. Several sub-Task Groups addressed specific sub-jects and reported their findings to the committee.Viewpoints from experts in the field. Federal governmentagency managers facing database decisions, and published ma-terial on database technology assisted the Task Group inmeeting its goals. Subcommittees were formed to investigateand propose standards for each component. The final overallrecommendations were reviewed so that each component'srecommendations are consistent.

In addition to describing specific functional capabili-ties, each subcommittee considered and addressed issues sucha s

:

-4-

1. A single standard or multiple standards.

2. To standardize at the syntax level or functionallevel.

3. The nature of the interface between the componentsand the DBMS as a whole software system, and the in-terface between components.

4. The impact of the proposed standards on the futureDBMS technology.

5. The cost and benefit of the proposed standardswithin each component.

6. An assessment of the cost of implementing and main-taining the proposed standards.

7. A plan for the achievement of the proposed stan-dards.

These issues are individually addressed in the "Justifica-tion" subsections within the Chapter "Recommendations forStandards."

1.4 ACTIONS OF OTHER STANDARDS BODIES

1.4.1 American National Standards Institute. In autumn,1972 , the American National Standards insti tute (ANSI) com-mittee on Computers and Information Processing committee(X3) through its Standards Planning and Requirements Commit-tee (SPARC) established a Study Group on Data Base Manage-ment Systems with a charter "to investigate the potentialfor standards." The Study Group issued an interim report in1975 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 forstandardization of any existing products or specifications.The report does contain a "framework" which can be used toconsider future standards actions.

After accepting the report, SPARC initiated three per-tinent actions: referred actions for subschema data descrip-tion language specifications and data manipulation languagespecifications to the COBOL committee, referred actions fora Subschema data description language specification and datamanipulation language specification to the FORTRAN commit-tee, and initiated a committee for data description languagespeci f i cat i ons

.

-5-

1.4.2 International Standards Organization* Within theInternational Standards Organization (ISO), Technical Com-mittee 97/Study Committee 5/Working Group 3 on DBMS meetssemiannually and has a very ambitious program of work. ItsScope of Work includes:

1. Define concepts for conceptual schema languages

2. Define or monitor definition of conceptual schema1 angua ge

3. Develop a methodology for assessing proposals forconceptual schema languages.

4. Assess candidate proposals for conceptual schemalanguages

5. Define concepts for conceptual level end user facil-ities

6. Define conceptual level end user facilities

7. Take cognizance of and react to other data basedevelopments as appropriate

8. Develop vocabulary for Data Base Management Systems

1.4.3 Specification Work of Other Bodies . The Conference onData Systems Languages ( CODAS YL ) is a voluntary body thatdeveloped the Common Business Oriented Language (COBOL) andguided that language's evolutionary development. CODASYLdeveloped detailed language specifications for a FORTRANData Manipulation Language and Subschema Data DescriptionLanguage, a COBOL Data Manipulation Language and SubschemaData Description Language, a host-language independent DataDescription Language, and a draft Data Storage DescriptionLanguage. The FORTRAN specifications were published in Janu-ary 1977 and the latter three will be published in April1 978.

Though not a standards body the impact of CODASYL workon languages is well known, and their work in the DBMS areashas had significant impact already. The various specifica-tion developing committees of CODASYL meet at intervalsvarying from every six weeks to three or four months. Ap-proximately 25 different vendors and users are representedin the developmental committees. Proposals for improvementsto the specifications arrive from world-wide sources, in-cluding the European Computer Manufacturing Association, theInternational Federation of Information Processing So-cieties, and several vendor user bodies. CODASYL specifica-tions 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 be-come standards through CODASYL actions alone.

1.4.4 Individual Federal Agency Standards Bodies . Among the1 a rger Federal agencies participating in T G - 2 4 , it was notedthat several had their own standards-making function andsome were currently considering DBMS standards. For exam-ple, the Department of Agriculture has already established a

policy to use exclusively one proprietary DBMS for most ap-plications. Similarly, the Army reviewed various optionsrelated 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 sur-veyed DBMS usage of those Federal agencies participating inTG-24 in order to understand to some degree the actual usageof DBMS within the Federal agencies. The survey was not a

"rigorous" one but it is useful in indicating the likelihoodof significant trends in the Federal agencies. Details ofthe survey and its findings are in Appendix 2.

The informal results support the assumption thatFederal agency usage of database systems parallels thegrowth of such systems in private industry. Within the 14

agencies surveyed, 57 distinct DBMS were found. A few yearsago, only large, special purpose database systems were re-ported and these were primarily in the Department of De-fense. Therefore, TG-24 inferred a significant growth inFederal DBMS usage in recent years. Detailed determinationof the quantities of program code and data now committed toDBMS systems awaits a more comprehensive and carefullydeveloped survey.

Contributing to the difficulty of finding informationon Federal use of DBMS is the lack of a central repositoryof such information. TG-24 lacked the resources to conducta formal user survey. Even when data may exist it is not ina form that permits ready synthesis of the information need-ed. TG-24 recognized the value such information would havefor Federal planning and encouraged the development of suchstatistics 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 surveyoT iJFMS usage at 360/370 sites [IDC 77], International DataCorporation found that "of 861 sites in sample, 312 users(36.2%) reported usage of a DBMS at yearend 1976, and thefigure climbed to 433 sites [planned] by yearend 1978(50.3%)." If the same percentages hold true for the FederalGovernment's 8649 computers (1975), 3131 sites now use DBMSand 4350 will in 1978.

2.1.3 Current Problems In Data Base Usage. Several Federalagency managers of data processing shared with TG-24 the is-sues that concerned them. These were identified as:

1. Need for a common functional requirements specifica-tion checklist to aid in the procurement of databasesystems

.

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

3. Fear of a single, universal standard that preventseffective use of databases because of that agency'sparticular 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 changeand promotes user control of changes to productspecifications rather than vendor control.

2.2 IS NOW THE TIME FOR DBMS STANDARDS?

2.2.1 Standards Impact On Database Technology. The TaskGroup considered specifically the possiblity that standardi-zation at this time might have a harmful effect on databasetechnology. The result of this consideration was to notehow 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 direct-ly, the recommendations of the Task Group require justifica-tion of cost savings or cost avoidance for the Federalgovernment as a whole. Such considerations of future DBMS

-8-

technology impacts could properly be considered under poten-tial or future costs but may be secondary to immediate costsor benefits.

TG-24 reviewed various scenarios in which "premature"database standards might inhibit new technology. The TaskGroup determined that difficulties arose immediately upontrying 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 theselected standard is promulgated, and the extent to which itis accepted. Different combinations of these factors willaffect different stages of program development cycle withdiffering impact on technology.

TG-24 looked for precedents in past standards activi-ties. It reviewed the ASCII, COBOL, and MUMPS standardshistory and found no obvious instance where standards haveinhibited or adversely affected technological growth.

2.2.2 Current Inventory of Standards Candidates. The size ofthe inventory of potential candidates for standardizationdepends on the degree of detail required for the statementor specification of the candidate. For example, the variousCODASYL specifications are quite detailed statements of syn-tax and semantics presented in a very formal manner. On theother 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 availabilityof the specifications for use by all interested implemen-t ors

.

^.2.3 Sources of DBMS Standard Candidates. Identifiablesources of standard candidates do exist and should be exam-ined. To aid its work, TG-24 reviewed the followingsources

:

0 Existing computer vendor software

0 Existing proprietary packages

0 Existing specifications from volunteer developmentalgroups

0 Existing Federally "owned" software

0 NBS developed specifications

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

-9-

0 A clear and precise specification that permits anyvendor to implement it

0 The general availability of such a specification

0 A concrete method to validate the specification andmediate disputes

0 A body that reviews and updates the specification

0 A method to validate implementations of the specifi-cation and mediate different interpretations of it

0 The need to deal with the impact on those systemsnot s el ect ed

2.2.4 Timeframe For Standards. Significant time requirementsenter in the consideration of standards and especially sofor DBMS standards. The Task Group concluded that a tenyear life-cycle was the proper timeframe in which to con-sider DBMS standards. One to two years may be required forthe development of the standard specifications. This timeis not included in the ten year period. Another importanttime consideration is the time from the availaility of thespecifications to the availability of the first implementa-tion. This period may also be one to two years. The tenyear period will include periodic reviews.

Development of totally new DBMS specifications wouldrequire significantly longer periods before the preparationof specifications and the availability of useful products.

2.3 WHAT ARE THE ALTERNATIVES?

In deciding which approach to take in standardizingDBMS, consideration must be given to existing products, thefeasibility of developing totally new products, and the workof other standards bodies. At the same time, the feasibili-ty of implementation, the timeframe of the standard'sdevelopment, the possible longevity of the standard, and themanner in which this rather large subject, DBMS, is dividedinto discrete components will also affect the decision.

2.3.1 Alternatives To Any DBMS Standards . Several alterna-tives to standards do exist:

1. Effective conversion tools would reduce the need forstandards. However, "Data Base Directions II--theConversion Problem" [BERG 78] reported the findingsof a group of experts which stated that conversiontechnology has a need for standards in the area of

-10-

data interchange formats. Given such a standard, a

translator that quickly and cheaply converted anydatabase to any other database might eliminate theneed for standards.

2. Data Dictionary/Directory standards may result inlessening the need for DBMS standards by providingcommon descri pti ons f or all DBMS to use.

3. The Data Description Language used to provide,bridge, or interface with several Data ManipulationLanguages may permit a multiplicity of DML's whileproviding many of the standard's objectives.

4. For smaller agencies, the availability of a singletime-sharing DBMS may be used to satisfy the stan-darization objectives for Federal applications re-quiring the interchange of data and programs.

2.3.2 Standards Other Than Federal. The Federal governmentcould adopt standards from other bo dies or take advantage ofexisting de facto standards. These include:

0 ANSI Standards

0 De Facto Vendor Standards -- in the absence of otherstandards, the vendor's practice of making the sameproduct available to all of its customers simplifiesits task of maintaining and correcting the softwareit supports. This leads to a general compatibilitybetween users of the same vendor systems. General-ly, users groups have developed to exploit this com-patibility through the interchange of informationamong the users. However, such de facto vendorstandards are under the control of the vendor andsubject to changes needed to meet vendor goals.While vendors are sensitive to customer needs, ex-perience has shown that such changes have occurred.

0 Proprietary system issues -- Owners of proprietarysystems may not wish to give up ownership or be un-able to provide precise specifications of existingsystems. At the same time, the competitive natureof the computer industry may result in a gradualdevelopment of proprietary systems toward the stan-dard [BROC 76].

0 International Standards

-11-

0 Individual Government Agency Standards

0 Functional Application Area Standards For example:Law enforcement, health, library, air transporta-tion, etc.

2.4 FUTURE OF DBMS TECHNOLOGY

TG-24 concluded after a review of pertinent referencesthat database technology would continue to be characterizedby significant and important work. The Task Group agreedwith those who see change as inevitable over the next tenyears. However, the Task Group concluded that change wouldbe evolutionary and assumes that no "breakthroughs" willprobably occur in that time period. Further, TG-24 conclud-ed that proper standards planning will enhance the abilityof Federal agencies to cope with breakthroughs if theyshoul 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. Thenext step is to justify the commitment of resources todevelop the specification. TG-24 used a combination ofquantitative and qualitative analysis to justify its recom-mendations. The Task Group began by systematically identi-fying the costs and benefits of DBMS standardization and do-cumenting the underlying assumptions. This work assistedTG-24 in developing aset of priorities that led to the con-sideration of an interrelated set of DBMS components whichit identified as a "family of standards."

The work will also assist those developing the specifi-cations to compare actual experience against the assumptionsin order to guide the specification development effort.

The difficulty in finding quantifiable costs led theTask Group to a method depending primarily on qualitativeassessments. Therefore, the justification in the Recommen-dation 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 moduleswhich together would meet the diverse needs of the Federalagencies provided the basis for organizing the TG-24 stan-dards investigation and recommendations. The componentsthat 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 componentsconsidered is presented in a form indicated by the followingoutl 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, maintenanceand usage)

(d) Di scussions

All technical details and figures will appear in the ap-pendices.

3.1.3 General Assumptions. In listing the assumptions tojustify each of its recommendations for each component,TG-24 found that some assumptions were common to all or tomany of them. Therefore, a list of general assumptions thatare applicable to the Federal DBMS standardization effort asa 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 com-plexity within the next ten years.

0 Changes in h'ardware and software over the next tenyears will have little effect on the basic functionsperformed by data base systems.

0 Present DBMS architectures will be useful even inemerging new system environments (such as distribut-ed systems) and changes to the DBMS architectureswill be evolutionary over the next ten years.

0 There will be more DBMS conversions within each ofthe Federal organizations.

0 Transfer of data among Federal agencies within leg-islated guidelines will be increasing. Cost andbenefits considered will be limited to those ofFederal agencies.

3.1.4 General Benefits. The general benefits that can bei d ent i f i ed for DBMS standardization as a whole are as fol-1 ows

:

1. Easier data conversion.

2. Easier program conversion.

3. Improved personnel transferability.

4. Improved data sharing among different computer in-stal 1 at i ons .

5. Improved DBMS competition among vendors.

6. Improved selection and evaluation of DBMS products

7. Improved DBMS procurement process through largervendor choice and competition.

3.1.5 General Cost Considerations . The general cost con-siderations pa ral lei the set of common standards require-ments discussed in the section dealing with the purpose andapproach of TG-24. These are the costs of:

-14-

1. Developing a standard specification. Such a specif-ication can be obtained from volunteer organiza-tions, a government agency, vendors releasing theirproprietary rights, or from a body established toprovide the specifications.

2. Publishing the specification and analyzing the com-ments received.

3. Validating the specifications and mediating thediffering interpretations.

4. Validating the implementations for conformance tothe specifications.

5. Maintaining specifications over standards' lifespa n

.

While some of these costs are one-time costs, several areon-going costs over the life cycle of the DBMS standard. In

addition to the costs associated with developing the stan-dard specification, some costs can be identified with in-stalling the standard DBMS component.

Note that costs associated with converting to a stan-dard can be avoided by requiring use of the standard onlywhen another form of change forces a conversion. Then theconversion to the standard has no direct costs. For exam-ple, first time users selecting a data dictionary systemwould probably pay no more for a data dictionary that pro-duces output compatible with standard database systems thenthey would for a non-standard dictionary system.

Similarly, costs resulting from the conversion to im-proved hardware or software capabilities may be timed to in-clude changes to standard practices. Agencies may shift tostandard practices in a piecemeal fashion as existing non-standard practices require significant changes.

Costs associated with installing a standard DBMS com-ponent when the above considerations are ignored include:

0 Personnel -trai ni ng and temporary loss of productivi-ty

0 Conversion of data

0 Translation costs of programs

Cost will vary with the degree of difference between thenon-standard system and the standard.

-15-

3.2 TERMINOLOGY

3.2.1 Background . The Federal government currently uses manydifferent data base management systems. Each of these sys-tems is unique in that its developer has adopted terms torepresent syntactic and semantic entities which fit his ownenvironment. For this reason, many similar data managementfunctions are described in terms which are quite dissimilar.In the same fashion, many terms which are shared betweenseveral DBMS may have quite different meanings.

TG-24 recognized that its members used DBMS terms in a

dissimilar manner. Consequently, the terminology appearingin Appendix 3 of this report was developed to help TG-24members in their written and oral communications. This ter-minology definition is not intended to be a standard.

Work to date by ANSI has established a standard glos-sary of data processing terms [ANSI 77]. The absence ofdata base terms, however, is quite pronounced. The Interna-tional Standards Organization/Technical Committee 97 is

currently involved in establishing such a glossary.

3.2.2 Recommendations .



3. Guidelines should be established whereby vendors areencouraged to utilize DBMS language syntax which iscompatiblewith 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 ofunique DBMS terms for similiar concepts.

2. Terminology standards will continue to be developedby ANSI and ISO.

++Benefits and Cost Avoidance . Benefits to be derived fromestablishing a common set of database oriented terms can beseen mainly in the areas of training and information

-16-

interchange. A terminology standard would permit prelim-inary training, (e.g. university, technical school) to ad-dress general knowledge of database concepts, these conceptsbeing embodied in the database glossary. Training at morespecific levels could therefore be shorter in duration andmore productive.

In the same fashion, interchange of information betweenindividuals using different database systems can be facili-tated. Different features can be related to the glossary ofterms, thereby providing a. mapping of information about onesystem onto another.

++Co St

s

. The cost involved in establishing and maintaininga terminology standard is relatively small since Federalagencies would rely on voluntary development. The pay-backfor this effort would begin immediately and would easilyjustify the expense in establishing the standard.

3.3 DATA DESCRIPTION LANGUAGE

3.3.1 Background . The data description language (DDL) is de-fined 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 physicalstorage media.

The Federal Government currently uses a large number ofdatabase management systems. Often a single agency supportsmore than one DBMS in order to satisfy varying user needs.Each DBMS has its own language for describing the attributesand relationships of the stored data. This variety of datadescriptions makes it impossible for agencies, or even dif-ferent units within an agency, to easily interchange data.The people who are interested in using the data are forcedto learn the specific DDL which describes it. When data is

exchanged, a new description of data for the target systemmust be written and tested before the data can safely beused

.

-17-

The current situation is both costly and time consum-ing. Therefore, the recommendations are aimed at reducingboth the time and cost required to exchange data betweendifferent users.

3.3.2 Recommendations.


2. The specification of the standard description ofdata attributes should be similar to the attributesin the PICTURE and TYPE clauses of the CODASYL DDL.




++Expl anat i on . The separation of the description of dataelement attributes from the description of data structurehas been recommended because a single standard for both willnot serve the needs of the Federal community. Separation ofdata element descriptions from data structure descriptionsallows maximum flexibility while benefiting from the advan-tages of standardization. It would provide a single stan-dard for data element descriptions and multiple standardsfor data structure descriptions. The concept of separationhas been advanced by such noted authorities in the field asE.F. Codd, M.E. Senko, and James Martin. [CODD 71, SENK 73,MART 77]

The attributes required to describe data elements byany DBMS are similar, although the syntax and semantics usedare often very different. A single standard in this areawould simplify the user's task in describing the data ele-ments contained in the data base; it was felt that thechoice of syntax used to describe data element attributeswas irrelevant. The attributes of the CODASYL DDL were sug-gested because:

-18-

1. They are well documented with a formal specifica-tion.

2. They are supported by a maintenance group.

3. They are an extension of COBOL, a widely used com-puter language.

4. There are currently several DDL implementationsbased on the CODASYL proposal

.

In the data structure area, both the characteristicsand the seman t i c s/ synt ax required to describe it are dif-ferent. Three discrete data models have been identified,i.e., hierarchical, network, and relational. Each of thesemodels has unique characteristics that require a uniquestructure description. A single standard would impose oneof the above models on all Federal agencies regardless ofuser requirements. For example, a user with an ad-hoc re-trieval requirement who may best be served by a relationaldata model would be needlessly constrained if a network wereadopted as the single standard.

3.3.3 Justification .

++As sumpt i on s .

0 The amount of data description in the FederalGovernment will continue to grow.

0 The amount and complexity of data stored in databasestructures by the Federal Government will grow sig-nificantly.

0 The increase in DBMS usage will cause an increase inDDL training requirement.

0 The demand for interchanging of data between DBMSwill grow.

++Benefit and Cost Avoi dance. Savings will be mainly in thearea of:

0 Personnel - After the initial investment of re-educating all personnel in the use of the standard,DBMS retraining costs would be minimized. Addition-al costs would be avoided by reducing cost of newtraining, and reducing the cost of low productivitycoupled with high error rates during the period ofdeveloping expertise in the use of the new DBMS.

-19-

0 Transfer of Data Descriptions - Cost of transfer ofDDL between source and target DBMS would be minim-ized because the DDL of the source DBMS could bedirectly compiled on the target DBMS. Opportunitywill exist for more automated means of convertingbetween different DBMS.

0 Transfer of Data - Transfer of data would be simpli-fied because the use of the standard DDL would allowa two step conversion. The source data would beconverted to an intermediate file. The intermediatefile would be loaded on the target DBMS using thesame DDL. Target users would have no difficulty inut i 1 i zi ng the dat a

.

There are other equally important considerations thatare not easily quantifiable. These are timeliness and qual-ity of data. The disruption felt by end users duringconversion is difficult to measure but is a real factor.

The standardization of DDL would encourage transfer ofdata between users. Currently, the time and cost involvedin data transfer forces users to do without needed data, orto duplicate collection and maintenance of data existingelsewhere. The report of the Federal Paper Commission citedduplicate collection of data as a serious government-wideprobl em

.

Standardization of DDL would also encourage wide use ofDBMS in the Federal Government. Many agencies are hesitantto get "locked in" to a non-standard DBMS causing them touse far less efficient means of storing and accessing data.

Standardization of DDL, as recommended, would contri-bute both quantifiable and non-quantifiable cost savings inthe Federal Government. In addition, efficient informationprocessing methods would be fostered.

++Co St

s

. The Federal government should encourage and parti-cipate in voluntary standard action. However, in order toeffect the intended goals the Federal government should beprepared to accept the costs of developing and maintainingthe Data Description Language specification. The costs willbe initially the development of the specification, whetherin voluntary standards groups or as a Federal effort, andthe subsequent maintenance of the specification.

-20-

3.4 DATA MANIPULATION LANGUAGE

3.4.1 Background. Data Manipulation Language (DML) is the1 anguage which a programmer uses to cause data to betransferred between a program and the database. The DML maynot be a complete language by itself. It may rely on a hostprogramming language to provide the procedural capabilitiesrequired to manipulate data. A user application program iswritten using a mixture of host programming language state-ments and the DML commands. The DML provides the ability tointeract with the database by giving commands to cause anaction and by providing a means to receive responses fromthe database or the processors involved. The DML consistsof several data manipulation commands or functions which mayinclude the following: data retrieval, data addition, datamodification, data deletion and modifications of data rela-tionships.

The diversity of data manipulation functions andlanguages causes many problem areas which would benefit fromstandardization. The following problems occur with currentDBMS technology when users must contend with two or moreDBMS.

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

0 The data manipulation functions of each DML differin syntax and semantics.

0 The data manipulation functions also differ in syn-tax and semantics between the various host program-ming languages for a given DBMS. Specifically, theDML for the FORTRAN language interface is differentfrom the COBOL language interface.

0 The functional capabilities provided by DML are dif-ferent across the set of available DBMS. This causesproblems in conversion and procurement.

TG-24 evaluated the DML of twelve of the more commonlyused DBMS and discovered four groupings. Chart I in Appendix5 shows the twelve DBMS and their DML. Charts A, B, C, and D

show the four categories of DBMS identified, and examples ofthe DML for each category.

TG-24 developed the concept "category" to help itanalyze potential standards. The term "category" is an ad-hoc concept used merely for the purposes of our analysis.Categories are groupings of DBMS based on some technicalcriteria. The criteria used by TG-24 to categorize DBMS were

-21-

the commonality of data manipulation functions and datastructures. Categories should not be equated to data models,although data structures are used as a major criterion tocategorize data base systems. The term "data model" refersto the type of data structuring permitted by a DBMS (e.g.,network, hierarchical, relational, ..) and various datamodels appearing in the literatures may have only slightdifferences. See for example [MART 77] and [KERS 76] for a

discussion of different data models.

Though the concept of "categories" has special utilityfor TG-24's analysis, the idea behind this method may be ofuse to those who will be performing the follow-on detailedwork. A more comprehensive analysis to categorize DBMS mayrequire additional criteria. TG-24 does not wish to restrictthe methodology used to categorize DBMS, but the intent ofthe analysis should be to support the goal of standardiza-tion by eliminating smaller differences, combining similarfunctionality, and producing the smallest number of ca-tegories.

The following recommendations assume four categories ofDBMS with at most one standard DML for each host programminglanguage for each category of DBMS and a potential of onestandard DML for al 1 DBMS.


1. Develop multiple DML standards specifications,

2. (a) For each standard host programming language(e.g., COBOL, FORTRAN), develop immediately a stan-dard DML specification for each category identifiedby TG-24.


(c) As a long range goal, develop a single standardDML specification containing the functionality ofall categories.


++As sumpti on

s

.

1 Databaseti f i abl e

tures

.

manag emen

t

categori essystems fall into limited iden-reflecting different data struc-

-22-

2. Increasing numbers of application programs will bewritten using the DML.

3. The present interrelationships between data defini-tion languages and data manipulation languages willremain the same in the next ten years.

4. The existing differences present in the host pro-gramming language interfaces are not necessary toprovide the needed data manipulation functionality.

5. The increasing number of computer conversions anti-cipated within the Federal government will requirereprogrammi ng a large number of application programsusing DML.

6. Data manipulation functions and data structures arevalid criteria for categorizing DBMS.

++Benefits and Cost Avoidance .

0 A greater return from (or a reduction of) requiredresources for programmer training, program conver-sion, data transfer, and application system transferwill occur with standard DML.

0 Limiting the number of standard syntactic and seman-tic definitions for data manipulation functions willsimplify the terminology differences and make it

possible to evaluate the capabilities of DBMS.

0 The evaluation, selection, and procurement of DBMSwill be simplified by the standardization of a lim-ited number of data manipulation languages.

0 The proposed standard DML interface will simplifydata sharing in computer networks, community databases, and distributed databases.

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

0 Increasing the number of categories and the numberof host programming language interfaces will signi-ficantly increase the cost of specifying anddeveloping the family of standard DML.

0 Conversion cost. A cost will be associated with con-verting existing DML to standard DML. The cost willvary with the differences between existing DML andthe 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 conversionis required by other factors.

++D i sc uss i on . The first of the recommendations posed abovea 1 1 ows for the development of multiple DML standards. TG-24seeks to permit flexibility in DBMS standards by providing a

family of standards. Such an approach will allow an overalldatabase architecture to exist that will provide usefulfunctions and data structures that are not currently provid-ed by any single DBMS using a single DML standard.

The second recommendation is a gradual movement towardsa desirable end goal. It would be very beneficial to theDBMS end-user community if one standard DML was possible andpractical. TG-24 felt that the standardization effort couldnot begin with the single DML standard route, but the effortmay evolve to that end. There are major differences betweenthe data structures and DML provided by various DBMS today.For this reason, if the DBMS continue to evolve, it is verypossible that the major differences between DBMS will disap-pear 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 rchyII

HOST PROGRAMMING LANGUAGE

CATEGORY COBOL FORTRAN PL/1 other Al 1

Network

II

II Relational11 = = = = = = = = = = =

II

II

II-

A1

1

DM FunctionSuperset

Figure 1 - Relationship of Host Language Standardsto DML standards

The matrix in figure 1 illustrates the DML recommenda-tions. Each of the categories listed down the left handedge of the matrix provides the user with a useful viewpointof the database. Across the top of the matrix appear exam-ples of existing standard languages. As indicated by thematrix, each intersection of row and column provides an op-portunity for a specific DML. For example, the CODASYL da-tabase specifications would be a candidate for the intersec-tion of COBOL and the network category but, of course, wouldnot satisfy the COBOL /rel at i onal intersection. Similarly,CODASYL has proposed a FORTRAN DML which is a candidate forfilling the network category and FORTRAN intersection.

The DML recommendation identified each of the intersec-tions as a potential standard. However, TG-24 also noted theinherent commonalities that would exist in all DML for anyparticular category. Save for differences of syntax re-flecting the specific host language, the functions performedessentially remain the same over all the languages. One DMLindependent of any particular language could satisfy all thehost languages for any particular category. The matrix in-dicates this with final right hand column which contains a

DML for each category.

-25-

Finally, TG-24 considered the fact that all the dif-ferent categories were treating the same important data.The concept of a superset of data manipulation functionscommon to all the categories but bundled to eliminatedifferences of syntax, data structures, or a particularviewpoint is not new. Several technical papers have treatedthe subject of "reconciling" various data models into a com-mon language for the' user. This lead to the conceptual pos-sibility of "summing" the host language independent DML inthe right hand column into the one common DML found at thebottom of the column.

The process of abstracting the various DML into a

category-common DML and then, further, into a single, commonDML is admittedly speculative and requires demonstrations offeasibility. However, such an approach would supportdirectly the goals of standardization and TG-24 recommendedits 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 bereferred to in short as data dictionary (DD)) is a softwaretool that is used to identify and interrelate data elementswithin an application or enterprise. It is viewed as thecentral repository of all descriptive information about eachdata element contained within an application database.

The scope of the standardization recommendations ex-cludes data dictionaries that are manual tools for dataresource management. In Appendix 6, the various types ofdata dictionaries, the various features that a typical datadictionary would provide, and some commercial package namesare mentioned for illustrative purposes.


1. Data dictionaries used by Federal agencies must beable to produce the standard DDL attribute descrip-tion as recommended in Section 3.3.2 by the DDL Sub-committee of TG-24. (TG-24 took no position on thestandardization of data dictionaries but addressedonly those data dictionaries with an interfacebetween the data dictionaries 'and the DBMS whichmust be standardized.)

2, The design of data dictionary must be capable ofcombining standard data attribute descriptions withdata structure descriptions to generate the DDL forone or more DBMS.

-26-


3.5.3 Justification.

++As sumpt i on

s

.

0 As databases continue to grow, the need to controldata elements descriptions will increase.

0 Data dictionary usage in the Federal agencies willincrease at a greater rate than the usage of DBMSwithin the next 10 years.

0 DD will be a critically important tool used by database administrators for the central control of data-bases.

0 Distributed database management will enhance theneed of data dictionaries.

++Benefits and Cost Avoidance .

0 A data dictionary which produces standard DDL willreduce the cost of converting to the standard DDL.

0 The standard DDL produced by the DD to be interfacedto DBMS will reduce the need for manual coding whichin turn will reduce errors.

0 There will be significant cost savings for tran-sporting data for data interchange and for conver-sion purposes because a standard DDL would be gen-erated from the data dictionary.

0 Data dictionaries will provide bridges to multipleDBMS.

++Co_st_. The cost of implementing this recommendation willbe no more than the cost of implementing a data dictionarythat does not produce a non-standard DDL.

++Di scussions . Note that the recommendation proposed forthe data dictionary is to standardize the interface betweenthe DD and the DBMS. Compliance with this standard will per-mit the users of DBMS to use any data dictionary that hasimplemented 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 userfacilities for DBMS, and a substantial variety of taxonomiesfor these facilities. [LOUG 77]. Since many of these facil-ities are quickly learned, and many of them are designed forad hoc activity, standardization of syntax and semantics ap-pears unwarranted. Substantial costs may be incurred by a

poor match between the facilities needed, and those providedby a procured DBMS. To avoid this, a match should beachieved prior to procurement.


1. Standardization of syntax and semantics of end-userfacilities is not required. Such facilities areeasily learned, problem and subject-matter depen-dent, and there are a diversity of end-user facility"styles".

2. Guidelines should be developed to aid the specifica-tion of requirements of end-user facilities forFederal procurement purposes.


++As sumpt i ons .

1. End-user facilities will be the subject of intensiveinvestigation and rapid technical development, e.g.,the role of intelligent terminals, is just begin-ning to emerge.

2. A variety of end-user facilities will be needed toaccommodate the different needs and user popula-tions.

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

4. Programming effort will continue to be expanded toimprove end-user facilities where facilities areinadequate or inconvenient for the user group.

-28-

++Benefits and Cost Avoidance.

1. The major benefit of the procurement guideline wouldbe improved utility of DBMS resulting from procure-ment of end-user facilities which best fit the needsand abilities of all user groups which are to usethem

.

2. The major cost avoidance resulting from the guide-lines is due to the decreased need for "customizing"the end-user facilities, e.g., by programming newfacilities using host languages and the data manipu-lation language, or by enhancing existing facili-ties.

3. Usage of the guideline will aid the user primarilyduring the procurement process. While not even anapproximate estimate of the number of likely DBMSprocurements can be made without a survey, one pro-curement error is likely to waste easily severalmonths time. Additional uses of the guideline wouldbe to guarantee retention of all existing functionsduring conversions, to provide guidance in upgradingexisting facilities, and to assist database adminis-trators in providing the appropriate tools to dif-ferent user groups.

++Costs .

0 Development of the guideline should be relativelyinexpensive. Maximum use should be made of existingstudies and taxonomies of end-user facilities, andalso of past procurement efforts where lists ofspecific requirements were used. A major part ofthe development effort should be a follow-up on themajor procurements to check areas where experienceafter procurement indicates facilities were lacking.

•i-+Di sc us si on .

0 General comments. There are many examples of multi-ple DBMS in use by single organizations. A plausi-ble explanation for this phenomenon is that the dif-ferent DBMS provide different sets of end-user fa-cilities which are so attractive to different usergroups that the costs of multiple DBMS areoutweighed by user convenience. It may well be thatmultiple end-user facilities are in fact required.It does not follow, of course, that multiple datadictionaries, data definition languages, and datamanipulation functions are required - ideally dif-ferent end-user facilities would make use of commonsystem parts. The guideline should therefore clear-ly indicate that procurement officers may best

-29-

satisfy their requirements by purchasing severalend-user facilities, from one or several vendors,plus possibly developing in-house facilities if ap-propriate, all of which use the same interface toother DBMS f acil ities.

Comments on first and second assumptions: A neces-sary and sufficient set of end-user facilities mayeventually be defined as a result of currentresearch. At that point, a standard for end-userfacilities should be developed. These do not appearto be surveyable assumptions. The consensus ofTG-24 is that the assumptions will remain valid forseveral years.

Comments on third and fourth assumptions: These as-sumptions have been informally verified by surveyingthe experience of TG-24 members. A formal surveymight be appropriate to demonstrate more generalval i d i ty

.

Comments onnomies ofpresented i

approachesline. Th eyherent inIt is worthquery facilone half wahalf wa s po

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

n Appendix 7. They demonstrate possiblewhich might form the basis of a guide-also demonstrate theattempting to classifynoting that when TG-24ities should contain updates positive they should not,sitive they should.

d i f f i cul ti es in-such a rich area,was asked whether

capabil ities,and the other

4. RECOMMENDATIONS FOR GUIDELINES

4.1 BACKGROUND

Several areas or activities associated with databasemanagement systems do not easily lend themselves to strictstandardization. These activities are concerned with suchfunctions as the documentation of data base designs and im-plementations, ancillary operations performed in the data-base environment, and the establishment of database adminis-tration functions. This indicates the need for guidelines inaddition to whatever standards may be necessary. Thesequidelines will treat subject matter that are, perhaps,premature for standardization, or offer too diverse a choiceselection to permit hard and fast direction imposed

-30-

externally, or permit several equally good choices with noparticular 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 thespecific subject areas above, TG-24 concluded that guide-lines recommending standards of good practice were needed inthe following areas:

1. Computer security and privacy protection in databasesystems

.

2. Procedures for database recovery, reorganization andaudit. At this time, no Federal guidelines exist. Aworking panel report on database auditing [BERG 75]suggests the need for such a guideline. A group ofaudit experts [RUTH 77], supports this point, anddiscusses general audit administration, methodologyand tools. While database recovery and reorganiza-tion procedures may be too DBMS-specific for inclu-sion into Federal guidelines, development of generalguidelines or checklists may be possible.

3. Documentation - Currently FIPS Pub 38, "Guidelinesfor Documentation of Computer Programs and Automat-ed Data Systems" contains guidelines for thedescription of database specifications. These guide-lines describe the database specification for a da-tabase to be developed during the design stage ofthe development phase of the software life cycle.Guidelines will also be necessary for the documenta-tion of the implemented database, i.e., after it is

developed, tested, and loaded. This would be analo-gous to the separate guidelines that exist for theprogram specification and the program maintenancemanual. The "Database Management Manual" mightdescribe the database in its final, implementedform, and all common validation routines, recoveryutilities, reorganization criteria and utilities,database administration support software, etc.

4. Performance monitoring - An important start has beenmade in this area with the issue of FIPS PUB 49,"Guideline on Computer Performance Management," inMay 1977. In the context of database management.

-31-

guidelines could be developed for the monitoring ofdatabase growth and performance, general criteriafor reorganization, database (re)design hints, etc.

DBMS evaluation and selection - FIPS guidelines onseveral activities in theanalysis/evaluation/selection cycle would greatlyassist Federal DP managers considering the databaseapproach

:

a. Analysis of existing ("conventional") data pro-cessing applications or potential applications (notyet automated) for implementation under databaset echnol ogy

;

b. Methods for the comparison of available DBMSpackages against application requirements and selec-tion of best candid at e(s);

c. Documentation practices for these activities,

d. Preparation of Request for Procurements - a needparticularly noted by several managers that offeredtheir comments to the Task Group, and;

e. Methods for benchmarking DBMS as a means to aidin evaluation of the responses to the Request forProcurement

.

Database administration functions - Several existingpublications from various sources could provide thebasis for a FIPS guideline for the determination ofthe functional duties of Federal database adminis-tration staffs.

Requirements analysis - Little guidance now existsto assist Federal managers in preparing a -goodstatement of their needs prior to seeking tools tomeet these needs. Federal managers, particularly inthe numerous smaller agencies, need such help.

-32-

4.3 JUSTIFICATION

4. 3. 1 Assumpti ons.

0 Useful guidelines can be compiled from existing ma-terial on good information practices.

4.3.2 Benefits and Cost Avoidance.

0 Guidelines can provide Federal agencies with ap-proved practices drawn from industry experience andtailored to the special needs of Federal agencies.Examples of the special needs of Federal agenciesinclude: procurement practices determined by regula-tions, statutory constraints of data processing ac-tion, and affirmative action programs with regard toi nf ormat i on pol i cy

.

0 Guidelines can be maintained and modified to reflectFederal experience with them so that each agency canprofit from the collective experience.

4.3.3 Costs . Costs associated with guidelines are the directcost of compiling and reporting recommended standards ofpractice as well as that work needed to develop and testpractices not available from industry sources. In addition,cost will be experienced in follow-up and verification ofpublished guidelines.

-33-

5. MISCELLANEOUS RECOMMENDATIONS

5.1 REDUCING STANDARD ADOPTION COSTS

5.1.1 Background

.

To force the adoption of the standardsrecommended in this report universally and on a certain datecould result in unnecessary expense to Federal agencies.Under such a requirement, conversion costs would occur in

the training of personnel, the conversion of existing data-bases, and the translation of existing application programs.A less concrete cost would be the loss of productivity ex-perienced by the agency during this period. These costs canbe reduced and even eliminated by judicious timing of stan-dard installation.


1. The standards recommended should not be mandatoryuntil other factors determine a change to therel evant systems

.

2. Standards can be required for new applications orsystems without requiring existing systems to alsoconform to the standard.


++As sumpt i on

s

.

1. During a conversion to new systems requiring changesto programs and data, the use of standard productsadds no additional costs to the conversion process.

2. New applications can be written in the standard pro-duct at little or no additional costs. Costs associ-ated with maintaining two concurrent systems will below and offset by reduction in conversion costs tomove to the standard system when other systemchanges result in rewriting the existing programs

-34-

and converting the existing databases.

3. Incremental installation of standards will be feasible.

++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 wheredatabase systems were major considerations. These were data-base systems provided by computer processing services(whether in batch or in the time sharing environment), dis-tributed data processing or distributed data bases, and themini/micro computer. TG-24 treated these issues only to theextent that it could conclude that the basic recommendationswould apply to these systems as well.

5.2.2 Recommendation. TG-24 recommends that the databasestandards actions described above apply to data base facili-ties provided by computer services, distributed systems, andmi n i computers

.


++As sumpt i on s . The assumptions for these recommendationsflow from the recommendations of each of the detailed stan-dard recommendations. TG-24 assumes no significant differ-ences will be required for each of the subject areas.

++Benefits and Cost Avoidance . Applying the same standardsdescribed previously to the database systems provided bycomputer processing services, to distributed systems, or tominicomputers will enhance the database work done in any ofthe other areas. It will insure the broadest possible shar-ing of people, programs, and data. Expanding the area ofstandards application will provide a greater payback for thecosts expended in developing standards. Minicomputers, par-ticularly, will benefit from the central discipline exertedby standards in view of their anticipated growth, diversityof vendors , and the lack of a common operating system dis-cipline. Distributed systems, especially combining hetero-geneous systems, will still have the conversion problem

-35-

between different systems but eased somewhat by the commonstandards shared by all the different systems.

++Co St s , Cost associated with standard systems will not bed i f f e rent than that of non-standard systems. Conversioncosts 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 manyactions i m p 1 i e d by its recommendations and recommends ac-tions for transitional periods. Development of standardspecifications may take as long as two years with anotheryear after that for the implementation of a standard pro-duct. Standard products will remain merely an assertion ofthe vendor until validation procedures are available. Whatactions should Federal agencies take until a fully validatedstandard product is available?

The question suggests the existence of three timepe r i od s

:

1. Until a specification is published.

2. From publication of the specification to its commer-cial avai 1 abi 1 i ty .

3. From commercial availability to validation.

These periods of time will hold for each specificationresulting from these recommendations. For example, the net-work DML and relational DML will have two distinct develop-ment paths which need not necessarily be concurrent. In ad-dition, vendors may choose to combine step 2 and 3 by with-holding a product until it has been validated.

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

1. Prior to the development of standard specificationsfor a Data Description Language, Federal agenciescan prepare for standardization within their own or-ganization by using systems having a Data

-36-

Description Language similar to the CODASYL1 anguage.

2. In time period 1, select DBMS systems having in-dependent Data Description Languages which describedata attributes similar to the CODASYL specifica-tions.

3. In time period 2, require database systems underprocurement to meet the standard specification ofthe Data Description Language and those standardData Manipulation Language specifications which areappropriate for its application. For existing data-base systems, solicit translators from the existingsystem to the standard systems. Document existingsystems using the standard specifications. RequireData Dictionary Systems and End User Facilities tomeet the standard interface requirements.

4. In time period 3, require all new applications andprocurements to use the standard systems.

5.4 PRIORITIES WITHIN THE RECOMMENDATIONS

5. 4. 1 Background

.

Technical interrelations of the recommend-ed family of database standards and payback considerationsargue for establishing priorities in the development of therecommended standards. These priorities are reflected bythe phasing recommended below.

5.4.2 Phasing Recommendations.

+ +Phase 1

.

Develop specification for the common attributepart of the two part data description language standard asdescribed in Section 3.3.2.

++ Phase 2. Develop specification of the structural descrip-tion for data structure classes as described in Section3 • 3 • 3 •

-37-

++ Phase 3.

0 Develop specification for each data manipulationlanguage.

0 Develop guidelines for using the data descriptionlanguage specification.

0 Specify interface requirements for data dictionariesand end-user facilities.


++Di scussi on . In preparing these phasing recommendationsJ(j^ notes that the network category has progressed furtherthrough these phases than the others. However, the recom-mendations are stated to avoid implying a preference for, orthe 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 Acquisi-tion of DBMS," available from ACM, 1133 Avenue of theAmericas, New York, New York, 10036, March 1976.

[CODD 71] Codd, E.F., "A Data Base Sublanguage Founded onthe Relational Calculus," IBM Research Report, July,1971, pp. 48.

[CODD 71b] Codd, E.F., "Further Normalization of the DataBase Relational Model," IBM Research Report, August1971, pp.33.

[CODD 72] Codd, E.F., "Relational Completeness of Data BaseSublanguage," IBM Research Report, March 1972, pp.36.

[COMM 77] The Commission on Federal Paper Work, "The FederalInformation Locator Systems," July 1977, U.S. Govern-ment 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 SavingsPossible in Converting Programs From One Computer toAnother," Report to the Congress, Sept 15, 1977.

[IDC 77] International Data Corp., "360/370 Migration -

1977" A research report prepared by International DataCorporation, 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, NewJersey, 1977.

[RUTH 77] Ruthberg, Z. G. & R. G. McKenzie (Eds.) " Aud it andEvaluation 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 Structuresand Accessing in Data-Base Systems," IBM System Jour-nal, 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 onData Base Management Systems," Feb. 1975.

[BERG 75] Berg, John L. (Editor), "Data Base Directions -

The Next Step" Proceedings of the Workshop of NBS andACM held at Ft. Lauderdale, Florida, Oct. 29-31, 1975,National Bureau of Standards, ICST Special PublicationNo. 451.

[BERG 78] Berg, John L. (Editor), "Data Base Directions -

The Conversion Problems" to be published as NationalBureau 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" April1971, Available from ACM, 1133 Avenue of the Americas,New York, N.Y. 10036.

[SIBL 77] Sibley, Edgar H. "Standardization and DatabaseSystems," IFSM TR No. 23, University of Maryland, alsopublished in Proceedings of the Th i rd InternationalConference on Very La rge Data Bases , Oct. 1 977 .

[TSIC 77] Tsichritzis, D. & Klug, A. " ANS I /X 3/S PARC DBMSFramework" University of Toronto, Computer SystemsResearch Group, Technical Note 12, July 1977.

COST BENEFIT

[TG-5 77] Task Group 5 members, "Quantitative Methodologyfor Assessing the Economic Impact of Federal Informa-tion Processing Standards" Task Team Recommendations,March 21, 1977.

[TG23 77] Task Group 23 members, "Preliminary Report of theEconomic Analysis Study Group for MUMPS" Task Group 23,

-40-

July 26, 1977.

TERMINOLOGY

[ANSI 77] American National Standards Committee X3 - Comput-ers and Information Processing, " Ameri can Nat i onalDictionary 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 SystemsWorking Party Report," available from The British Com-puter Society, 29, Portland Place, London, WIN 4HU, Un-ited Kingdom, March 1977.

[CANN 74] Canning, Richard G., "The DataDictionary/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, "TechnicalProfile of Seven Data Element Dictionary/Directory Sys-tems" National Bureau of Standards Special Publication500-3, February 1977.

[PLAG 72] Plagman, B. K. & G. P. Altschuler, "A DataDictionary/Directory System Within the Context of anIntegrated Corporate Data Base" Fall Joint ComputerConference Proceedings, 1972, pp. 1133-1140.

[PLAG 77a] Plagman, B. K. "Data Dictionary/Directory System:A Tool for Data Administration and Control" AuerbachI n format i on Ma na gement Series - Data Base Management ,

No. 22-01-02 , Auerbach Publ i sherTTnc . , 6560 North ParkDrive, Pennsauken, N. J. 08109, 1977.

[PLAG 77] Plagman, B. K. "Criteria for the Selection of DataDictionary/Directory Systems," distributed at the Sym-posium on Management of Data Elements in InformationProcessing at National Bureau of Standards, September1 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 Develop-ment," National Bureau of Standards Handbook, 113, Jan.1974.

[CODA 78] CODASYL Data Description Language Committee, "CO-DASYL Data Description Language Journal of Develop-ment," January 1978.

[CCA 76] Computer Corporation of America, "Data DescriptorStudy," Final Report Contract DAAB-3-75-C-0464, August16, 1976.

DATA MANIPULATION FACILITIES

[KERS 76] Kerschberg, L., Klug, A., & Tsichritzis, D. , "ATaxonomy of Data Models." University of Toronto Techni-cal Report CSRG-70, May 1976.

[THUR 77] Thurber, Kenneth J. & Patton, Peter J., "DataStructures and Computer Architecture" Lexington Books,DC Heath & Company, Lexington, Mass. copyright 1977.

END-USER FACILITIES

[LOUG 77] Lough, Dennis Elliot and Burns, Allen Dale, "AnAnalysis 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 NBSand the FIPS Coordinating and Advisory Committee on the needfor Federal database management system standards and any ap-propriate standards activities to meet such needs.

++Scope . The task group will consider all areas withincurrent data base technology with a view towards definingrelationships between DBMS and existing FIPS activities anda more precise statement of the scope for recommended stan-dards activities. The area of study will include: distri-buted processing and databases, networking, data descriptionlanguages, data manipulation languages, datad i ct i onary/ d i rectory functions, DBMS support functions, andthe role of mini-micro computers in DBMS.

++Program of Work .

1. Determine the Federal need for DBMS standards. Con-sider Federal DBMS standards in such technical areasas DDL-DML, minicomputers and networking.

2. Survey existing DBMS models, determine the relativemerits to the Federal agencies of the variousmodels, and collect formal specifications.

3. Prioritize the various model specifications for de-tailed St udy

.

For such model specification selected for detailedstudy, survey existing implementations and review towhat extent each model specification feature was, in

fact, implemented.

For each model specification selected for detailedstudy, make a formal recommendation for Federal ac-tion.

-43-

7.2 APPENDIX 2 - DBMS USAGE SURVEY FOR TG 24

BACKGROUND

An informal survey of DBMS usage was initiated at thefirst TG 24 meeting on March 15, 1977. All participants ofTG 24 were asked to survey their own agency in the use ofDBMS. The purpose of this informal survey was to gatherpreliminary data to substantiate the need for DBMS stan-dards. In particular, the survey attempted to find out:

0 Whether Federal agencies are heavily committedto the use of DBMS.

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

0 Whether TG 24 should conduct a formal surveyon DBMS usage in order to assess the effect ofa DBMS standard with respect to current operations.

The requested information for the informal survey follows:

0 Names of DBMS used within the agency. For eachDBMS the following should be addressed:

0 Type of application0 Type of usage0 Kind of user0 Type of support of central facility0 Data interchange

It was also agreed that a software system is a Data BaseManagement System if it possesses all of the following pro-pert i es

:

0 It is an integrated set of computer procedures0 It facilitates usage of data0 It facilitates storage and maintenance of

large amounts of data0 It provides frequently used shared functions0 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. Agriculture2 . Air Fo rce3. Army4. Central Intelligence Agency5. Defense Intelligence Agency6. Federal Energy Administration7. Federal Home Loan Bank Board8. General Services Administration9. Health, Education, and Welfare

10. National Bureau of Standards11. National Security Agency12. Office of Management and Budget13. Pension Benefit Guarantee Corporation14. Veterans Administration

Detailed data collected from each Agency is tabulatedin 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 conclusionfrom this fact is that most of the agencies are using DBMSand 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 AirForce, 5 were developed by NSA. Roughly 75% of DBMS in usewere commercial package.

Characteristics of In - House Written DBMS

Two in-house written systems are used for document re-trieval. The remaining in-house written DBMS are built forintelligence military applications. Real-time processingwith 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 Codasyl-like systems but not necessarily Codasyl syntax. Systemsinclude 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 systemsare used among the survey

(f) Hardware supporting only one DBMS system - 2 DBMS canbe 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, Agri-culture) use the CSC Infonet Time-sharing service which hasSystem 2000, DML and Aladin. The Pension Benefit GuaranteeCorporation uses Compu-Serv time-sharing service which hasSystem 1022.

(h) Early generation DBMS systems - 5 early generationsystems are used among the survey population. These areFFS, NIPS, IDS-I, MARS and MARK III. Users were system pro-grammers and the usage is batch for report generation pur-poses.

(i) Research systems - 1 system INGRESS which is a rela-tional DBMS developed by University of California, Berkeley,is used by 2 agencies (NBS, NSA). Usage is experimentalresearch oriented and no production applications have beendeveloped. The Army is using UNIBASE written in ANS Cobol74 for research in DBMS portability.

Usage and Users

(a) For Host-language and CODASYL-like systems, the usageis predominantly batch, transaction-oriented and used mostlyto produce reports. Users were either subject-matter spe-cialist or clerks for invoking a pre-defined transaction andsystem programmers for coding transactions.

-46-

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

(c) The majority of the users of DBMS are reported to besubject-matter specialists with programmers doing the systeminterface type of task.

(d) Agriculture has an experience with self-imposed stan-dards. System 2000 at Agriculture has about 28 applica-tions. Some are small applications with less than 100records. The other DBMS in use at Agriculture are IM-AGE-3000, Infonet DML and in-house written ones. Forestryuses FS-GIM. This might be due to the agency imposed stan-dard DBMS practice to define all applications using oneDBMS.

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

-47-

, • 0) o (0 onj XI (fl 4J u 'O a

0) jJ (0 a a 3•o • 3

m 1 <o a Ul Ul >1ij 1 10 > 1) r-l 3 0) >, rH c<D 1 3 4) W <0 4J rH M -Hin 1 -H 3 -H >i n> (0 <u 4JD 1 u o r-i O 0) 

1 u 1 1 JJ JJ 4J jj 1 jj JJ JJU) 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 COiH ro Ul •H g •H >1 •

a s <o 10 ;j •a • Ul Ul

Cu in m rH • o 01

<G O e e «0) c •o JJ jJ

>1 *j •H c JJ c wUl )-l (0 >1 Ul 10 Ul 01 >13 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 ca 1 IB (0 0) c u 04 c JJ 0)

^!> e g D •r4 <0 3 <u JJ go •H C 0) u B 10 01 0

in Ul • 4J -H Ul (0 0) 01 rlC 1 cs Ul o 0) 01 cn 10 W0 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

8O 1 4J C JQ •r-( rH e 4J 4J c c 0 JJ 01 »J 0•H 1 O u 01 (U 01 u 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 rHa 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 I

I

>1

1

U I

C I

0> I

Di I

 > M CO 00 00 Ms rH c 0 M * 0 0 0CO 0 0 z Z rH iH rJ 00Q >tH ro Z) rH rH rH

0) 1 c < c c M a< c c c 0 CO u c10 1 M X 0 0 0 M < 0 0

rH 3 1 00 > r-Tl 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) JJC 1 CO n 0 00 c c U 00 u 0 c H CO rH10 i E VD g M M 3 \£) ^ s 0 •H

1 01 z u w eu \ Jj<1 ro M M ^< 3

to 1 2< JJ 5 0 00 CO u C5 0 z jQS 1 Ul 0 01 < cs 0 J 0 J 0 0) 0 0) £ 1 HI Ul 0ca 1 >i C 0 r- 01 t~ Ul OQ CO CO CO < (0 r- 0)

Q 1 W m 10 0 IH U, m Q rH Q rH 0 ro D M Cli u W ro 01-1

o

I

c

m0)4J

u•H

c

-48-

d) to M H 1 'O 'O 1 Vj

V Ul r ) rtt r" «VI/ 0 0) 0)

CO "H io ^ > < /ft rA rnn m UJ (Q wj fO to JJ

3 »H 0 D 4J D to JJAt

rn ^ Bto ^ to 03 (0

'»% W ^ B 'D 4_ UJ 'r-l to g\J d^ ^ d) ^ 0 Jj '"H rHQl 4J d) (0 fO J_l Li (11 m c 0

(0 C 4-} 3 'H "1 iTT rtl B •^JJ lU UJ B d) •

0 u 0 -Q JJ G CJ"^J4J • 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 J31

*}^ 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 14J 0) d) rH C 1 JJ 4J (0 to •H

<0 1Qj ni m 1

1

y l-M U/ UJ U g JJ rH1 (0 J3 Q C 3 nt u 0 ^ g to to

d* 1f— <—

>

0) 3 rtiW w 1

1 u c 10 cT* 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» di "v. ""iy Lri ~J >1-H 0t—

'

/-VJU E-t ja — JJ to to UJ 'U .U UJ « JJ X} u to

CO B rH 1 U 1k-i 1 1 1 1

1 nil c 1 1 11 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

>1 G Cu S to u d) r t u_i (Ti r 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 u0/ • e 0 0 U J-" C ^ w QJ '"^ JJ 0 u

-

1 (1) C «-l 0) c r\ IjU w 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 (0A. 1 (0 C) JJ - 0 e ^

rnTj0 dJ 0 ""H C 'rH (\i

It 1

>i c c U 0) ^ ^ jjtr" 1

4J D 0 jj 0 4J 0 to U 01

1 •f-i >^ >J 0 -H D rHC 1 10 cn 0) 0 -u - u 0 d) -H 4J to fO d) D^-rH to 0 a0 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} Cu1 r-1 ^ CO (iiH CO

In

r\ C c ^ r /tl B /TlU r-1 UJ B 'O Cr 1 1 (0 D d) 0 J—w•H 1 Jj "H c u c " ?*t ^ dJ 0 rHrH 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 JJO. 1 H u o> U C Q) Q) rtt ni fll'U »U w fl C fll frt^ W UJ 'U d) 0 H

Cli Oh (tJ 10 6 to (0 B 1B *^ UJ ~ 1 1 (J B E-t

GO w 1 c •D C uJ t <£< 1

1

JJ crtw C 0 4-) 0 d) u cu r* c 0

,0 M M d) ^3 0) (0< 0 ^ U fO BB w e ^ 0d) 0) W -H

d) £ to1

CP g IJfli 1li' 1 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 >nOrn 1U 1 M H J m r 1 "E* w Q w 0Li 1 _j 1

1 Q 0(Q 1 c M GO -H u s 0 JJ ^ 0 c\oX 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 rHC 1 M « Q e 1 (0 0)

fO 1 M w 0 * 0) s * na B w e1 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 COQ 1 fa -H 1 S 10 0 M 01 ^ >1 S s C 0O 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

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 •'^ i44J 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) 3U 0) 0 1-1 10 to

<D -n •H u U) QJ 3 Z rHa i3 4J cm 1 (0 to CJ c e 0 to CPEh c cU 1 U w 4J -r* 6 •H D C 05 •n 0q; I O >i c 4J -no 4-> to

W 1 J3 • fO XI XI c U g tt, u uD 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 on 1 (1) D rH •rl -rl 0 U 4J 4-)

1 C fO c w c c M c0) 1

•H .» -H •H C (0 0 x: QJ Oi QJ • x: 0 gcn 1 rH 0) O rH QJ Ti x; -H U SJ -rH to U d 0(0 1 1 4J QJ 1 -U QJ U 4J 4J Q) 3 >J >H 4J ai4JW 1 c to a. c X W Q) to fO QJ QJ QJ to 3 3D 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 oU 0) iH • r-l 10

c Uo u

jJ •r^ •H <u-MM 4J rH c4J U m rH 0C D 4.) 0 -H0) 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 3C 1 u - • 0) •H0 1 o to-H 1 u Cue c >1 >1jj 1 0 -H a) IB U rH QJ tjl

(Q 1 4J 4-1 ij g c P (0 o cU 1 (C U U 0) 0) 0) c

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

r-l 1 0 -r-i C nj c OJ 0 cCu 1 i3 0 <0 C •H rH -O to 3

nj >-i u iTJ (0 OJ c QJ 0< J a 4J g s: Eh 10 CC U

1 - c c c , I4H 0} 01 4J ac3 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 'H1 ^ 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 OS 1 z a> s to C £ CO to CO 0 Om 1 U U QjCQ s (0 CO Q -U OQ 1 > ttD M M S M b CO M CO VO

QJ I

g I

to 1

z I

I

>. I

u I

C I

OJ I

cn I

 CP cnOJ to 10 10 (0 104J (0 to u (0to 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 jaQJ to

3 +J a •D to •n -ocr 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 cH to • •H -iH rH •HrH to rH rH

1rH rH

1 4J1 1 c« 1 1

C >i to c c o c co ja o o o o

1 1 1 >1 1 rH .H 1 T3ro 0) -H 4J C 0 OJ • Sj C 0O CJi to OJ . -rH U • C ID QJ to

•H (0 -rH 4H to 4J rH C g arH C 3 10 c c to 0 m rH >1a ro cr to O to 0 > to u - to ^4

a g •H QJ U QJ U cn 4J -H 0ro to 4J a rl QJ o C Sh -U

4J - (0 u a u QJ QJ CU -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 c0 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 TJlO 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 Cto 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 CO0 X3 0 4J rH o < Q•r4 OJ 0) rH > u4J c rH M

Z T310 QJ rH 0g a to MH u S Cu 0 u c c o 10

0 rH 4J H 0 o >ItH OJ C s M C OC > QJ (3S Z 0M QJ CJ 0) o" -D CP r-l Hro ^ C (0 c O

10 c 0 QJ u 0 O S- 4J ro O •H O QQ

•H ^ (0 u c o CM MZ rH Q o \> * QJ 0 otd ID t~- C M CO CO rH gU U U CO r-H QJ ^

O 4-1 -a S U O M 1 4J CO Ob C ro S ro S O CO CO to o oz 0 01 m rH C 2 O < >.rH VOM U S M < o ^ VO WrH VO

>tg

-50-

• •

V•

0)

•

iH D> C7>

C 10 to to

0 10 to to

3 3 301

CT> JS .Cflj o u u

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 cQ) 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 cD 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 p0 3 (0 -H -rH c •

•H CT 3 -P 01 cP O rH CT to e 010 (0 O E 01 •H

1 E C 10 to Vh CI P(U 1 u C (0 0 to to

1 0 o o tp c o1^ !

y-t •D (0 c c to •rH

6-1 1 c c M -H -O -H1 •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

>1 r-H 4) •H to(0 1 E (0 • a> u to 6 P uU 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

or~- c

00 (0

or-H

r—

1

rH o0) 1 rHU 1 o \ o o(0 1 ? o o r~? 1 >1 ro nD 1 0) M roV4 1 X(0 1 o S in (9 (0S 1 93 03 in M M•O 1 C

uon c c

C 1 0 c c o o o10 1 o CO 0

1 M a >-} Qcn 1 CO < w <: <S 1 U) OSm 1 Q < M M ffia 1 M s: s Z M

0) I

g I

to i

Z I

I

>. I

u I

• 1 1 >i (/] C -U rH 1

C C j3 -tJ 0^ c (0

to 0•H a

* 'O rH (D pw (1> fO c CO

0 W 'H 0 •rH >i •

(0 ^ 0 D U •H p en

U3 p to p3 'DO Qi 0 (0 p to

CO >i•C Q) 0) rHo 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 £ • PfO 'D U a; c cto C i-i fO V) £ ftJ C to 0 to

tO 4j "D ^ a 3 •Ha. 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 erH rH U rH U 6

1 C C fO .Q T3 'U P 1 rH (0

c c -H -H ^ 3 C C <0 c ID Uo 2 0^ to fO to CQ 0 U C7>

>C 1 1 1 cy 1 * 1 1 1 p P10 Q4 > C U U 10 to c U>i 0 •r-t Q CJ G u CJ D -r-i D 0 u

C (D 4-J Cli ^ Cil 0 a0 "TD to * T3

"•^ to 4J

C >i i-i C "-H to

^ fO 13 C -H CU >1 00 E -C C to rH pW 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 a0 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 i U c to c u to

o ^ c U K C •rt 4^ M CO 0 0 (0 cC Q) fO 

n 0'D (V r-C C 0 m(0 •rH \

•C 0rH vo

fH (0 ro

B QQM Sc CQ

u C M°o

C U ffl c0 w 0 M 0

< 0 MCO ffi toS O M CO £O P- z z M MM m 5 < 0 z

I

C VM Uc

rH 0)

10 >iu uP rH CC rH 0)

0) 0)

O -P <

-51-

CO

1 0) >, 0) 1 0 1 >, >1-p0 0* in i3 u c 4> SI 10

^ in c c u g 3 4J •HOi 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 UjQ 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 -i n] (0 C U 4) c c -P c u

1 -t 6 •H O <0 (0 DiJ-l (0 x: in •H 4) 0 13C 1 1 tn C (0 y -H e s IM rH(0 1 C )-< -P 1 •H (0 13 W •H •H U •H u u >! 4> UH1 >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 11—1 4) 0 0 QJ J3 T3

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

i

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-> Su (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 C1 0) u c (0 Qj <D in d) c -iH

V 1 U 10 -H c a) iH (0 g .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 cH 1 0) •H !u C -D in (0 >-( u •rH (0 4»•U 1 CP 4J >i • •H (1) 1 > (0 c 1

rH ytj 1 ecu H nj (0 in ^ iH 0) •H C 4) rH 6 u cU 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 UH U>H 1 o u 3 in 0) Oi 0 Q) <D 1 E <D 1—1

••-1 u XJi 4) 3Cu 1 n) 10 S 4J u C £ 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 0o 0 Nr~ (0 no

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

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

t

to S; 4) CU 1 •H M (Q n •P 0 jg(0 1 19 3 t-i 4* 10 (0S 1 M J3 c jj 5; '>\* M

1 0 C 10 0 CQ CO C7<O 1 c 0) 0 M c cC 1 0 0) u CO f—1 -rH 010 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 EhCQ 1 c z 3 0 JE •H 0 0Q 1 M H < Q 1 > U

0) 1

1

1 c 1 1 C1 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 4JZ 1 c c c •O (0 C 4) U >i to

1

>t 1

0) 0) f-l •H C rH nj r-( to rH 0 -P Uin 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 10C 1 0) —1 c (1) <C 4J OJ c OJ 4) -H rH -rH <4H - 4J » 3 •Ha> 1 rH 0) 'O (0 Ti nj (0 cue (D -P -H sue sueD> 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 iHCO (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 c1 '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 >iU 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 dJ U 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 0CO 1 O Q) fO 3 C CO ^ 0 D C 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 COft3 d) c c 'O^ U) Q) 04-5 (TJ > u 0w 0 >1 C C 0H i>J •H • "'^

C 0 C^ 4J rH C•H C Jj H d> OJ -H

Q) 1 6 fO C (u >{X 1 d) 4J d) dJ c s

!

m d) > dJ 4J OJ • H 0 CQb*' 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 Um 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 uM 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 CO0 CQ f\u 0i-i rH 00 0 rHr-i 0 rH 0 rH rH

fH 0 t 1

c CO CJ rH cu Q4

<D 1 w CQ rH ro 0 (HU 1 CJ Cli

t5 1 CQ H 1

^ 1 It n »> CQ CJ CJ'O 1 •J *^ M u M uW 1 Q Q^ 1 c s c uX 1 M 0 c 0 c

1c 0 0 (J

"u 1 0 0 0 0 0C 1 0 > 0 CN 0 CO 0 rHfO 1 M CO CO

1 rH 0 CO T T03 1 us <D -r < M CO CO

1 CO CO 0 'D CQ c^ CO 'S,

CQ 1 0 g M < CO CQU 1 Q n M s M CQ Q

'O 1

1 C C (0HI

i-H 'O 0 c 0£ 1 0 0 cfO 1 'H ^ H dJ dJ y-< to

Z 1 0 >i (T3 J-* 4-* 4J 4-* 0 c iH 0 rH >i0 W ro 3 fO 3 0 'O c OJ 4J

>. 1 W -H 2 4J £ 2 4J J= < 0 C D 03 c -H >iU 1 }^ CO •H 4J •H AJ •H 0 03 0 UC 1 ^ 4-> r-i 4-J H OJ c -H cOJ 1 :s 0 c S CO m S CO ro 0 (0 4J OJ 4J U 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 JJ1 u

XI • i3 u (U u 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 ajjrH • "a M • • c g U g u ja jQ (0

1 <y -H 0) w (0 (0 Q) <0 Q> 3 3 gc tn iH I/) tJl >j a. c tn to >i0 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 (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 rO U (0 U (0 J= 10 XI g 01 Vj rH01 1 XI XI 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 rH1 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 <0 c >, (0 (0 0) UD o O 10 o o O (0 -H CQ 10 --1 « X) g OXl g CQ Cii (3^ to

D 1•

1 1 UJC C -H jj c 0) . 0(0 (0 *w c a) >J

rH >§'§ JJ g c

c 0) •H rHCr-H g <D a> c •0 (0 •

C JJ g (0 •H c > cH 3 JJ a c C (0 10 0) 0rH XI C 0 (0 (0 (0 •H -H3 -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) gOi t to a> x: to H 0) in 0 9) u iH to u u

^1tn U •H 3 o (0 •H fU a to 00) in "o cr JJ >1 • U (0 C 0: - jj 0) a rHJJ 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) uU 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 crH 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 ua 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 c0 rH 0 0r-H

JJ 0 I-H <S)

rH rH V£)

•H 0 0r- It

u 3 V£> rH cu a> ro « 00) 1 < XI 1 Q c a>

U 1 > cn (U 0 S 0) to -r(0 1 M M X CQ in 3» 1 0) X Q U M 3 0 0 Q-D 1 to u 0 0 J=)J 1 3 rH Q c JS f 1

10 1 c 0 rH u 0 1 c US 1 0 jC CN Di 0 c(0 1 r-t — c 0 cn 0 3 H r- 0

1 0 u fsl \0 cn 0 01 tn X cn ai 1 1 Cd •H XJ U (M

S 1 Cfl H s U cn cn Q rH U a> s: CMOQ 1 z: ^ c Q z Q M 0 a 3 aoQ 00 1 0 Q 0 M M M X s: cn CQ cn M

uzMJ «*

O 01Eh

< OM >a M

cnzMOucn

M 0\EH "W

V I

a I

10 I

Z I

I

>i I

U I

C I

V I

o» I

<: I

-54-

M0)

10

c

la I

10 I

s I

>i a> CO J3 urH (A E 0)cam -oO u -D JQ

CP D< 0) 3c o •>-> (0

c 6 ^o 0) (0

(iJ -H 4J

0 a> o Q4 0^ (0u iJ 00 6C O '^i-i -o o(0 c6(0 C

T3 O

01 n] ifi4-'

•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 uM a>

e wE

0)

0c

1 (0

(V 1

a 1 10

^!1

Q)

iH0 •

C 1 c0 1 4J 0•H 1 U -MU 1 0 -Wm 1 a (0

u 1 0) e•H 1 u uf-i 1 00. 1 0)

a 1 £ c<

1

C J3 <L)

03 'O w3 C 3 r?u

Q d) c d) •

J-* M0) 'O

M (U B 'U3 E Jj 4J

cr 'O QJ CC 4J d)

CO,fO vl AJ 'H

•H aJ ^ 0M E 0

'O c 1—1 U4 uQ) 'H 1

_

0* B W c ^ c Q(0 fO CJ» 0 0 1

(0 •H QJ C3 (0 0) U) c w 4J 0

-H D 0) 0) 0 u -Q CU 4J C 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 Q>4J

'O C(0 -H

U (0

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

lO •r^1 1

(iO ^ c C \0 BOi C 1 (0

Oi (0 4J(0 N C -H

U) •H >^ 0 'D U-l

^ r-H C * a>

B • e iffB »« C cCO 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 CJ= -H 3 0 -H 0)

H 0 Eb. (0 >

-a I

C ID •

(0 a—(1)

^J 4J

0) c4J 0)

T3 4J -r-l

(U <0

u 6 Oc0 -u cu•H U QM 0) I

0 -n C1 XI 0CDCO (0 —•HP >i (0

U XI 4J

(0 (0

U3 -HC TI >H(0 (1) (0

Eh 3 O

I

0)

-p

c

£05

S<n

c0)

ca

c(0 •

U 01

0) uc

0) (0

> c

0) I

U I

m I

VI I

10

sI

I

I

T3 I

C I

10 I

I

W I

S I

ffl I

Q I

or-

£

co

aone•O E9 «a 4J

«s0)pu>10)

n34Jffl

P O

4J £OJ CO

•O3 COQ O

I Ue o•HP C

o

>M 0)

Q) uW -HI >3 Ua 0)

e woU D>^ CO

CM (0 ftiO J= Q<O

Q

I

SQ

0) I

e I

ffl t

z I

I

>i I

U I

C I

0) I

a> I



6 -oV 0) 3U 7<0Q•H ffl

<*-l C "OU-l ffl cO £ ffl

1 9)

(U 0) 1 cC 4J c 00) c 0 < •HOQ ffl -H u

U -P (0 ffl

C ffl ffl C0 3 U ffl p•H 0 0 u (0

(0 a 0) HC -P u 4J c0) -H 0 01 •HCU U-l u > E

-55

7.3 APPENDIX 3 - DBMS TERMINOLOGY FOR TG-24

ACCESS - The operation of seeking, reading, or writing dataon a storage unit. [MART 75]

ACCESS CONTROL - The mechanism in a data base system whichprovides protection of the data base from both inten-tional destruction and improper disclosure. [DATE 75]

ACCESS METHOD - A technique for moving data between a com-puter and its peripheral devices, e.g. serial access,random access, remote access, virtual sequential accessmethod (VSAM), hierarchical indexed sequential accessmethod (HISAM) . [MART 75]

AUDIT TRAIL - The process of keeping of records in bothevents and data activities within a system to allow fu-ture examination and verification of what has tran-spired. [CODA 76]

AUTHENTICATION - The process of supplying information knownonly to the person the user has claimed to be. [DATE75]

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

BACK-UP - The process of generating a copy of a data base atsome point in time. [CODA 76]

CATEGORIES - Categories are groupings of database managementsystems 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 process-able by one or more programs.

DATABASE ADMINISTRATOR (DBA) - A person or persons giventhe responsibility for the definition, organization,protection and efficiency of the database for an enter-prise.

DATA DICTIONARY (DD) - A software tool that is used to con-trol the totality of data elements within an applica-tion. It is the central repository of all descriptiveinformation about each data element.

-56-

DATA DESCRIPTION LANGUAGE (DDL) - The language used todescribe the database, or that part of the databaseknown to a program.

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

DATA INDEPENDENCE - The property of being able to change theoverall logical or physical structure of the datawithout changing the application program's view of thedata. [MART 75]

DATA ITEM - The smallest unit of named data containing nosub- structure ; the lowest level of addressable data inwhich data value(s) are physically stored.

DATABASE MANAGEMENT SYSTEM - A software system is a data-base management system if it possesses all of the fol-lowing properties:

It is an integrated set of computer proceduresIt facilitates usage of dataIt facilitates storage and maintenance of largeamounts of dataIt provides frequently used shared functionsIt potentially serves many functional purposes.

DATA MANIPULATION LANGUAGE (DML) - The language used tocause data to be transferred between the applicationprogram and the database.

DATA MODEL - See Data Structure.

DATABASE POPULATION - The process of placing occurrences ofdata values into a defined data base. [CODA 76]

DATA SECURITY - The protection of the data in the data baseagainst unauthorized disclosure, alteration, or des-truction. [DATE 75]

DATA STORAGE DESCRIPTION LANGUAGE (DSDL) - A language to de-fine the representation of a data base in storage.This term is used in [CODA 78].

DATA STRUCTURE - The logical relationships which existamong the units of data in a database and which areunder control of a database management system.

DATA VOLATILITY - Refers to the rate of change of the valuesof stored data. [CODA 76]

DEVICE MEDIA CONTROL LANGUAGE (DMCL) - A language used tomap the data onto physical storage media. It describesthe physical location and organization of the data.

-57-

DISTRIBUTED DATABASE - A database under the overall controlof a central database management system, but where thedevices on which it is stored are not all attached tothe same processor.

END USER - The end users are persons who perform the appli-cation functions. End users include parametric usersand generalized function users, but they are not systemsupport personnel. [CODA 76]

EXTRACTION - The process of obtaining data values on eachdata structure level and identifying the disposition ofthese values to an output media. [CODA 76]

FILE - A collection of all occurrences of a given type oflogical record.

HIERARCHY - A set of directed relationships between two ormore units of data, such that some units are consideredowners while others are members. This is distinguishedfrom a network in that in a hierarchy, each member canhave one and only one owner.

HOST LANGUAGE SYSTEM - A database management system that isbuilt upon the facilities of a programming language andis identified to the application programmer for logicaland physical file manipulations. The tools are embed-ded in the host language (e.g., COBOL, PL/1) and areaccessed usually through CALL statements, but sometimesby extensions in the language.

INDEX - A table used to determine the location of a record.[MART 75]

INTERROGATION - The function of data selection and qualifi-cation, extraction, manipulation, and result presenta-tion. [CODA 76]

INVERTED FILE - A file structure which permits fast spon-taneous searching for previously unspecified informa-tion. Independent lists or indices are maintained in

records keys which are accessible according to thevalues of specific fields. [MART 77]

LOGGING - The recording of actual changes to a data base asupdating occurs. [CODA 76]

NETWORK - A set of directed relationships between owner andmembers such that a single member record may belong toone 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 queriesto be entered, or allows a non-programmer user to ex-plore the data base and produce reports embodying itsdata. [MART 75]

PARAMETRIC USERS - Parametric users deal with specific ele-ments of data according to a predetermined procedureand using a limited complement of commands. They arebasically unconcerned with data structure and flow ex-cept in terms of the relation of data items to identif-iers. [CODA 76]

PRIVACY KEY - A facility specified as a literal, a dataitem, or a procedure used to unlock an operation whichis locked. [DATE 75]

PRIVACY LOCK - A facility specified as a literal, a dataitem, or a procedure used to prevent an operation fromproceeding unless the matching privacy key is present-ed. [DATE 75]

RECORD (logical) - A collection of related values treatedas a logical unit during any operation of the databasemanagement system (e.g., during data collection, pro-cessing, or output).

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

RECOVERY - The regaining or the bringing back to an originalposition or condition. [CODA 76]

RELATIONAL - A way of modelling data structures by rela-tions. Relations are usually represented as a collec-tion of tables where each table contains the oc-currences of a particular relation. Each column of therelation corresponds to an attribute and each row is aninstance of the relation.

SCHEMA (conceptual schema) - A complete description of thedatabase in terms of the characteristics of the dataand the implicit and explicit relationship betweendata-units.

SELF-CONTAINED SYSTEM - A database management system, thecapabilities and language of which are intended pri-marily for the non-programmer. They are self-containedin the sense that they usually have no connection with

-59-

any procedural language except that the system itselfmay be written in a procedural language, or it may per-mit user-written code in a procedural language.

SUBSCHEMA (or external schema) - A description of thosedata-units and relationships from a database of in-terest to a particular program.

UPDATE - The process of changing values in all or selectedentries, groups, or data items stored in a data base oradding 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 DataDescription Language area based on Federal govern-ment user needs.

0 Develop plan of standards activities to meet suchneeds

.

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 differentdata 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 ofDDI definitions were examined. The purpose of the reviewwas to develop a working definition that reflected the scopeof the subcommittee area of responsibility.

The definitions reviewed were:

1. Principles of Data Base Management - J. Martin

2. CODASYL - Data Description Language, Journal ofDevelopment, 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 languagethat 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 thedata onto physical storage media. It describes the physicallocation and physical organization of the data. As such, itis 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 implementa-tions were analyzed for adaptability to DDL standardization.The necessity for different methods of describing data at-tributes and structure was of special concern.

The CODASYL specification of COBOL type data attributesdescriptions was adequate, easy to use, and widely known.Other methods of defining attributes gained nothing for theprice of their being different.

Specification of file size or placement of data intophysical storage units is dependent on hardware. Each DBMSimplementation is designed to its host computer. This areawas not considered a candidate for standardization, and re-moved from our definition of DDL.

-63-

Data structures, and associated access facilities, werethe most divergent areas. Each structure had its own advan-tages, depending on an application using the data base.What is good for retrieval may not be good for update; whatis 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 theneeds of most applications.

-64-

7.5 APPENDIX 5 - DATA MANIPULATION LANGUAGE

INTRODUCTION

What is a data base management system? What functionsdoes it provide? These questions must be answered before a

standard Data Management Lan-guage (DML) model can bedeveloped. After all the functions provided by the set ofsoftware 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 defineDBMS and survey the current market of available DBMS will beconsiderable. However, it is recommended that data basemanagement be defined concisely and that every function pro-vided by every system that meets the definition be identi-fied. The data management function (DML) subcommittee ofTask Group 24 (DATABASE SYSTEMS STANDARDS) has chosen a sub-set of available DBMS to illustrate how the standards effortcould be applied to data base management language functions.

Twelve data management systems were arbitrarily select-ed for functional analysis. This subset will illustrate op-tional approaches that are possible with a given set of can-didate DBMS. This paper only considers the standardizationof host dependent data management languages of the candidateDBMS. The optional approaches leading to a standard DML fordata base management systems will be treated. The recom-mended approach will be emphasized. The following sectionsof this appendix will cover the approach that was taken toarrive at the recommendations presented in part II of thisDML subsection of this report.

METHOD AND SCOPE

There are many types of data management systems. Mostof 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 overlap-ping capabilities among the types of data management sys-tems. But, each available data system can be categorizedinto one of these types. TG-24 has been chartered to inves-tigate standardization of data base management systems. TheDML subcommittee is limited to evaluating the possible op-tions open to standardization of the data management func-tions that require the support of a host programminglanguage, such as Fortran, Cobol , etc. It has been foundthat considering only the DML' in standardizing DBMS is notpractical. The DML is entwined with the rest of the database management parts: the DDL, the DMCL, and the host com-puter operating system. So, the first step the DML subcom-mittee decided to take was to collect all the data manage-ment systems that fit the type "data base management sys-tems." This seems simple enough, except that there are noformal well accepted definitions for any of the above typesof data management systems especially for DBMS. TG-24 hadtwo problems. First, there were no acceptable definitions.Second, there are a large number of data management systemsavailable that need to be measured against a definition.

The DML subcommittee of TG-24 felt it necessary to lim-it the field in order to develop a standard model DML con-taining a representative set of the data management func-tions provided by the set of existing DBMS. In order to ac-complish this subsetting to one level, a definition of a

data base management system in terms of major functions pro-vided was proposed. This definition is not intended to bethe final acceptable definition of data base management sys-tems. Its purpose is to limit .the available DBMS candidatesfor the first phase standardization effort. A broader de-finition that will include all data management systems inthe standards effort is recommended after a firm approach isselected using a smaller set of DBMS. Also, for an accept-able definition to evolve, a preliminary one must be provid-ed as a base. The definition for a data base managementsystem in terms of functions and facilities provided is asfoil ows

:

1. It is an integrated sharable set of computer pro-grams 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 mannerstorage and retrieval of data in and from a database 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 util-ities.

Now that a definition exists, a survey of the market can be-gin, and all the data management systems that meet the de-finition can be selected as candidate DBMS for the DML stan-dardization evaluation. It was found that the number ofdata management systems that need to be surveyed was toolarge for TG-24 to handle in the one year time frame givento our initial study of DBMS standardization feasibility.The DML subcommittee chose to select a small subset of sys-tems that are commonly accepted as DBMS to illustrate theoptions 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 showingthe major DML commands of each DBMS. See Chart I. Each ofthe DBMS has other commands for control and interface withrespective operating systems that were omitted for thisillustration. Examination of Chart I will show that atleast four possible categories of command/function sets canbe identified by selecting common command subsets. Also, ifthe data structure models were made known, the categoriescould be identified by data structure. This is not surpris-ing because the DML commands directly relate to the datastructure model of a given DBMS. The four categories thatcan be identified are network, hierarchical, relational, andtable structure. There may be more possible categories.The area of DBMS classification and definition is complexand controversial. To resolve this area satisfactorily mayrequire a separate committee and a year or two's time. Anetwork system is an extension of a hierarchical system. It

accommodates hierarchy but also allows complex networks.Most CODASYL DBMS fall into this category. A hierarchicalsystem accommodates data hierarchy in the data structuremodel, and supplies commands to manipulate hierarchicaldata. The relational system defines a range of valuesacross a domain as a relation. Relations are defined as tu-ples involving one attribute and many values. Also, thecreation and destruction of relations is dynamic. Theself-contained system is one that does not need anotherlanguage to act as a host. However, many self-containedsystems offer host language capability. The difference isin the physical data structure; a self-contained system usu-ally has a static physical data structure, such as a tablestructure. Regardless of the logical structure of the database, the physical structure is the same in most self-contained systems .

DBMS designs have different purposes; i.e., relationalsystems allow dynamic changes to be made to sets and rela-tionships to handle a moderate amount of volatile data. TheCODASYL approach allows very flexible data structure forlarge amounts of data, but the structure is very static oncedefined. The command sets that accompany the differenttypes of data base management systems are directly relatedto the data models of the particular type. This is the rea-soning behind categories of data base management systemsthat are illustrated in Charts A, B, C, and D.

-68-

Both the common and unique commands are illustrated inCharts A, B, C, and D. The DBMS were grouped by evaluatingcommon commands, unique commands, and data models. Thenames given to the resulting categories are not important,and this is another area that could be standardized. Somesystems could fit into more than one category, such as Sys-tem 2000. System 2000 is a table structure system, but itis also a hierarchical system. It was included in bothCharts B and D to illustrate dual category possibilities.This also provides encouragement for the possibilities ofDBMS evolving to provide similar command/function capabili-ties. Network and hierarchical systems are similar enoughto evolve to one category in the near future. There isprobably one other category that will result if a more com-plete comparison and classification effort is undertaken.It will be the special purpose data base management systemcategory. In some cases, sem i

- genera 1 i zed data base manage-ment systems are developed for special purpose hardwareand/or applications. Due to the special purpose nature ofsuch a DBMS, it would be very difficult to standardize. Onespecial purpose system is usually not very similar to anoth-er. So, this category would hold a group of DBMs that aredissimilar to themselves and the other categories and notamenable to standardization.

PROCESS LEADING 10 DML RECOMMENDATIONS

Now that the DBMS are categorized into subsets, someoptions for standards can be proposed. Three or four op-tions are possible today. First, a standard DML interfacelanguage for each category could be developed. Second, aninterface language could be developed to include all identi-fied categories; one standard interface language withpreprocessors to generate individual DML's. Third, a set ofstandard DML commands could be developed for each categoryidentified from the analysis of all candidate DBMS. Ofcourse, the option of no recommended standards at this timeis a possibility. The possibility of selecting an existingDBMS from a standard appears unlikely because no single DBMSwill have a super set of commands/functions that would beneeded to provide all the capability now available by use ofa combination of available DBMS.

1 . Multiple I n terface Option

Most competitive DBMS will have the same major capabil-ities within the next five years. Of course, the syntax andsemantics of the interface languages (host language inter-faces) will not be standard unless reasonable standards areproposed and accepted. The standard interface approach forcategories of DBMS provides a flexible method for gainingapplications program DBM standardization. When, and as DBMS

-69-

begins to provide the same functions and capabilities, theinterface(s) can be modified to accommodate changes or addi-tions to the standard DMLS. Eventually, a single standardDML interface may evolve if the DBMS becomes similar enough.Vendors of DBMS are already providing similar capabilitiesto remain competitive. The users should begin to be con-cerned with standard methods of identifying capabilities be-fore the vendors implement new capabilities.

2 • Single Interface Opt i on

The option of beginning with a single standard DML in-terface may be possible, but it would be very complex andmay not be acceptable to the end user. It would be neces-sary for the single interface to accommodate the full set ofDML commands of all the candidate DBMS selected. This wouldresult in command translations that would cause no opera-tions in any DBMS that do not provide the command capabilitydesired. It is recommended that if the interface option tostandardization is selected, the first option chosen shouldbe one standard interface for each identified category. If

this approach is followed, then, as the DBMS categories pro-vide the same command/functions, one standard interface mayevolve. One advantage to interface approach is that theuser can implement or have the interface implemented withoutcooperation from the vendor of any or all the candidateDBMS. 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 ca-tegory of DBMS. Again, it is wise to stay within the ca-tegories to avoid translations that would result in nooperations. Chart I gives an indication of the difficultiesthat would be faced in developing a standard DML command setfor all available DBMS. This approach would not provide theuser with a working standard as readily as the interface ap-proach, because after the standard language is specified,the individual vendors of each DBMS in each category wouldbe responsible for implementing the standard DML, if indeedthey would be agreeable to do so. The standard DML wouldnot insulate the user from changes in individual DBMS aswell as in the interface option. Changes to the DML of a

given DBMS could be handled in the standard interface in-stead of in each application program. If changes were madeto a standard DML system, each application that would be af-fected would require change. However, this option would al-low an application program to access any DBMS of a given ca-tegory in a computer network using one DML. For a given

-70-

category, see Charts A, B, G, and D, the major DML commandsare already similar. The problem with specifying a standardDML, is that each vendor of each candidate DBMS for each ca-tegory must implement the standard. This is a big problembecause of cost to the vendor and the fact that one or moreof his major capabilities may not be standard. This couldmake vendors unwilling to agree to standardize their DML.Anyway, it is recommended that a standard DML set be speci-fied for each category of DBMS for two reasons. One, byspecifying the DML set, the data management functions foreach category are identified. Two, the DML sets for eachcategory are basic to whatever approach is taken to developa DML standard.

4. No Standard DML

No standard is always a possibility, but in the case ofdata base management systems a lack of standards is costlyand is going to be more costly. Hardware advances in thenext decade will probably provide more speed to conventionalDBMS rather than new DBMS concepts. Standardization ofcurrent conventional DBMS functions will not only help theusers within the next decade, but will help the designers offuture data base management systems by emphasizing the majorDML functions through standardization. Then only new systemcapabilities will need standards attention.

BENEFITS EXPECTED

It would be very difficult to place a dollar value onDBMS standardization versus no standardization. It is a

field of computer science that is still in infant stages.Most installations have only recently implemented theirfirst production system using a DBMS. Consequently, thereis little data available for measuring conversion or train-ing costs in regards to standard or non-standard DBMS. It

can only be speculated to be expensive to convert applica-tions from one DBMS to another. Also, it can be speculatedthat some conversions may not be necessary if the same ap-plication program could access data of two or more DBMSwithout modifications. This implies benefits for standardDBMS that cannot be proven as yet.

An important benefit to be gained from the standardiza-tion of DBMS will be related to the heterogeneous computernetwork environment and distributed data bases. Currently,the hardware and software exists to provide the communica-tions capability for a heterogenous computer network. How-ever, data bases under the control of different DBMS on thevarious computer nodes of the network cannot be readily ac-cessed in a uniform or standard manner. A standard DML in-terface or a standard DML would reduce the programming and

-71-

training effort necessary to access data controlled by dif-ferent DBMS. It would be possible for a single applicationprogram to access similar data under the control of dif-ferent DBMS without the need to change or rewrite the pro-gram. Of course, other system software, such as operatingsystem interfaces, user protocols, etc. would also requirestandardization to allow the DML standard to be fully andeffectively used. Changes to the system software could behandled in the interfaces and free applications programmersof any concern. Maintenance could be centrally handled byupdating and changing the interfaces a large precentage ofthe time instead of updating each individual applicationprogram. Life cycle support of applications systems couldbe greatly reduced.

DEVELOPMENT AND IMPLEMENTATION FEASIBILITY

Development possibilities definitely exist for thestandard interface approach. The best thing the approachhas going for it is the fact that one vendor or large usercould design and develop the interfaces. Most other ap-proaches rely on the individual vendors of each DBMS to im-plement a proposed standard. This is fine, but an automaticmethod of sharing data between heterogenous systems is notobtainable through a mult i -vendor standards effort. For in-stance, the CODASYL standard provides a standard specifica-tion for a data base management system; however, two dif-ferent vendor implementations are not compatible for datasharing purposes. The languages are compatible: the DDLand the DML. An application program compiled with the DMLof one CODASYL system cannot access the data belonging toanother CODASYL system without being rewritten and recom-piled. If the application program were to use a standardDDL and DML interface, the interface could handle the trans-lation to a different data management system. As previouslystated, an interface could be developed for each category ofDBMS identified. This is recommended as a first phase DBMSstandardization effort.

The proposed interface would consist of a precompilerstage plus an execution time management routine. Theprecompiler would generate a parametric call to a genericdata management routine. At execution time, depending uponwhich DBMS is to be invoked, a specific linkage could bemade. The DDL methodology would also require a standard in-terface to handle dynamic linkage to specific data struc-tures. This is anticipated to be a later phase of the in-terface standardization effort. The first level will be tostandardize the DDL and DML interfaces for each identifiedcategory of DBMS. An application program written using oneof the standard sets of interfaces would be precompiled gen-erating calls to a specific DBMS. Once an application

-72-

program is compiled, it would be locked into a specific database management system. However, it would only need to berecompiled using a different precompiler to access a dif-ferent DBMS of the same cateogory. This approach would pro-vide the applications user with a standard DML set for eachcategory of DBMS in the near future, and very possiblyevolve to one set if the DBMS becomes similar enough in theshort range.

MAINTENANCE

The standard interface approach insulates the user fromvendor changes to the given category of DBMS he is concernedwith. If a data management c omma nd/ f unc t i on does not existin a particular DBMS, the interface could emulate the func-tion or notify the user that the feature is not currentlyavailable through the given DBMS he is trying to access.When, and if, the function becomes available, the above pro-cedure could be dropped, or if the function was never avail-able in the interface, it could be added. The user wouldnot be required to modify existing DBMS host applicationsprograms every time a change occurred to a given DBMS.

The maintenance functions would be transferred from theindividual applications programmers to a central staff ofdata base system administrators (DBSA). The time and per-sonnel costs could possibly be reduced depending upon thenumber of application areas supported by a given data basemanagement system. With a large number of unique applica-tions supported by a given DBMS, a saving could be realizedby centralizing the support rather than dispersing themaintenance activities over all the application areas to besupported. In the case where only one special purpose ap-plication is to be supported, the savings would not occur.

CONCLUS IONS

Standardization of the data management function is de-finitely recommended. Many approaches are possible, but theinterface is probably the most viable one. It does not relyon the efforts of each candidate DBMS vendor to be imple-mented and it guarantees not only syntactic compatibilitybut compile and executiion time compatibility for at least a

given category of DBMS. It is not very likely that indivi-dual vendors of various DBMS will ever reach the point wherethey will offer systems that could provide the same level ofcompatibility that a standard set of interfaces could.

Charts A, B, C, and D illustrate the elementarycommand/function sets that would form the basis for thestandard interface languages for the four categories identi-fied in this paper. There may be more categories identified

-73-

when a complete survey is done using a broader definitionfor a DBMS. There will definitely be more commands andfunctions identified for inclusion in the standard interfacelanguages 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 inter-face to it. Another sometimes important advantage to theinterface approach is that the existing data bases and ap-plications can remain unchanged while new programs and databases are designed and written.

The goals of this proposed standardization effortshould be to provide the user with a standard and uniformmethod to build and access data bases using any one of thedata base management systems from a given category. Itwould be ideal to be able to provide only one access or in-terface language for all data base management systems. How-ever, that is not practical today. The team or committeethat does the survey of data base management systems wouldbe wise to investigate the facilities and functions neededby the generalized programming user and specify the charac-teristics of such an interface and measure the existing sys-tems against it. Also, in an effort to develop one singleinterface language for DBMS, it would be wise to investigatethe correspondence between the relational calculus functionof relational DBMS and the steps of the conventional inquiryprocess (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 • cto • • Q

• • a• ID

C •

t- •

•

10 • > • O • JUi • • 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*-* • • toi-t • • 2 • z • to • ato • t-( - > • c • > • >. • o • M • oc • >< • > • c • c •

o • • U. • u • c • w1 •• 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 • • Xto • • to • o • z

• • l-l • U} • c • UlCi (o a. • > • 2 • >. • > • >• • >< • 2 • u • > • to • > • > • >. • c • c •

5 "t CO • • M • Z • to • <tu a. s: • • U. • o • »-* • ex.

Cl • • u • Q • uu IQ o

ww 5L •

03 U • • Ulw s: (-" to • • >z: o to s: • > • >- • >< • c • > • >• • • • >. • > • > • >. • o • c • c •

< CQ >1 cc m • s.to o •

zt-l t-*

•J CN •

n F-i fM •

«-> K U • • u«-< • > • > • >• • c • c • o • z • c • c •

« X rf to • c • c • X • > • c • >. • cU O) • « • o

U•

C s. • •o • > • > • > • c • c • >. • c • c m 2 • >. • c • >. • c • c • c ••1 X. • • X<^ • uu«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 •f-I—

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 • cc • 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

• Us • 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 • os. • HH • I-* • • >. ' >. • >i • Li • W - H • C • o • o. • o • w • >. • >. • c • c • c • c • cc • a • • fc. • u . • K • o • c • 5. • c •

. • < • r>

s.; • f-l • bl • >< - u. • to • Ul

• UJ • UJ • cc • > • bu • J—

'

• w • >c05 • 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 • co • 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 • ae • u: hH • o • c • o • a • u • U] • f-i • o * 2 • ct • o • 2 • o • to • u • s • Ul • 3t • bi • co • a: • u. • bu « 15 • u. • w • u • c • U) • «I • »—

1

• «i • »—

(

• c • Ul • s: • c • H • oc

-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 • Oo • »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 • *-> • *JIC • V • C • 10 • ft( • o;4-i • c • 4) • o • ^ • «-!

4-> • -^ • a • »-l • ft) • 4»

«t • • o • u • o • O

•

s> •

•

• • ws • 10 • ocrv

• •

• «. • 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 • U3c • •« • O • o • O

xz •

u tn •

s. •

bju fn •

10>>

X w •

•

• f-<

•

w • • u • Ul• o • o • o • o • <J• c • c • c • c • o • o

•

flD •••

cc ••

X •

(J •cn • •

P • z • uC • m - u • u • H • >c • o • »-l • z • to • U • O£ • bJ • *JE • z • «0 • o. • ij • uO • -» • «t • o • u • oCI

• «

• 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-

AT.O£

03

in

a<

uu • c<e • oV

• *JA ' cx; • •-» • Mc • * • «o • b

c • o • ^o • V • <c^ • • >

• c • oo • o • »J • 01

c • «w • —t* 4-1 • 01 m a

u. • K • t} • 3• r^^ • *J

ft) • D.• 3 •

• *J • rrn • cc • Ci • «»-i • c • x:

• • o

• x« • b.

CO • »-i

ar • H • t-< • no • s • cX • U • a. • s:

•t •

HU>

9i N •

X •V. • • fa;

o tn •

z: ^ • • <a. • H • H • O^ o <• bZ • a.

to f- • C • a • 3co

bi10

•H <o«l >i

o: 10

> • uw • chi • t-l • 2 • <

• a: • b: • .Ju • o. • a

• u • Oo a u* fx • 01

u

KKCXu • bJ

m • > • fa]

T? • U • oC • 1—

t

• 2 • <« • cc • U)

• t- • a. • ae • 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 • XX •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 • * • wc • *Ho • • IC X. • K • 4->

• Of • • c• • fl) • X

u • c • lA • or • • Sc • fl^ • O • T3 • fl3 • u

• o. • • C • O • o• o • (-1 • J • to

CM • • ufN • z • w • c • CS • u; • c • 'z • «t • o>

• Ci. • • o• o • o • u. • *u • to

>* • a. • IT • CO • or.

ta • a • a • D • £- • Q

c

Oz.

i£ • • u:o* • M • v> • a • c •

u • tJ • 0> • w • «t • 41>^ • >• • >> • X • C' • >ito • • 3i • >J

«->

n ws

•1 bi•H f-Xi4) >"El ta

• u• CO • C • Ci• O • z • O

• • ».3 • »—

*

•• O • U • bu • U-• • bu • Ui • U. • O• »-l • f-» • t-H • »-4 • c

O

KX

•

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 • • • 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 toin short as data dictionary (DD)) is a software tool that is

used to control the totality of data elements within an ap-plication. It is viewed as the central repository of alldescriptive information about each data element containedwithin an application data base. It lists, describes, andlocates each dataelement in a data base. The dictionarydoes not manage the actual content of the data, but it doesmanage the descriptive characteristics of data.

The dictionary portion is a glossary of terms of dataelements representing their characteristics and logical re-lationships with data base components and application usage.The dictionary describes what data are contained in theorganization's data base.

The directory portion contains object data definitionsas used by the computer, plus physical storage locations andaccess strategies. The directory locates where data arestored

.

++Usage .

The DD serves the database administrator, systemsanalyst, software designer, and programmer by providing a

central repository for information about data resources. Itaids people in planning, controlling, and evaluating thecollection, storage, and use of the data resources.

As a documentation tool, it captures descriptive infor-mation and aids in establishing standards for data naming,usage, and coding conventions. It identifies users or pro-grams which may be affected by any changes, additions, ordeletions to the data.

If the DD is interfaced into the structure of a DBMS,tiien it may be used for generating the data descriptionlanguage of the DBMS, maintaining data descriptions and com-piling or interpreting program references which use thesedescriptions.

-80-

++Functions ojf Data Pi ctionary .

The primary function of a DD is to provide a method ofcentralized control over data elements. The following aresome functions of existing DD. No one system performs themal 1 .

Data attribute - Name, Length, Type

Data relationship - The structural properties amongdata

Synonyms - Allow alias capability

Textual description

Access control specification

Edit and validation check rules - e.g., null and de-fault values, ranges of value permitted, etc.

Output decoding specification - coded values to betranslated so that it is human- readabl e

.

Key/Non-key - Indicate whether the data element ismeant to be searchable or not.

Physical storage specification - logical and physi-cal address, internal representation, compaction,etc

.

Usage information - cross-references to users, ap-plication programs, and output reports.

Frequency of access - usually used for statisticalmonitoring purposes.

++Ty pes and Commerc i al Dd '

s

.

There are at present at least four broad groups of datadictionary systems existing in the market that can be iden-tified :

-81-

* Type A - The free-standing package which could be usedin 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 pro-vides interfaces to one or more DBMS.


DICTIONARY SUPPLIERS DBMS INTERFACE

DATA CATALOGUE

DATAMANAGER

Synergetics Corp

Management Systemsand Programming, Ltd

IMS, TOTAL

ADABASIDMS, IMS, TOTAL

LEXICON Arthur Anderson & Co IDMS, IMS, TOTAL

-82-

* Type C_ - The single data dictionary package designed toco-exist with a particular DBMS. This type of data diction-ary is solely dependent on the DBMS and usually developedand marketed by the same vendor.

Examples of commercial DD packages are

DICTIONARY SUPPLIER DBMS REQUIRED

Control 2000DB/DC DictionaryUCC TENData Control SystemData D i c t i 0 n a ryIDD

MRI SystemsIBMUniversity ComputingHaverly SystemsCi ncom SystemsC u 1 1 i n a n e

System 2000IMS or DL/1IMSDMS-1100TOTALIDMS

* Type D - The data dictionary that is embedded within a

DBMS. The data dictionary function usually is part of thedata definition function and the meta-data is stored as partof the database for the DBMS.


DICTIONARY SUPPLIER DBMS REQUIRED

GIM II Dictionary TRW GIM II

-83-

++ I n fo^rmat 1 on I n _a Data Pi ctionary System .

A data dictionary captures information about data ele-ments. Some of this information seems to be provided by alldata dictionary packages and deemed essential while others,though desirable, may be omitted at the discretion of theimpl ementor

.

To concentrate on the information requirements of thoseinvolved in data and database administration, several typesof information usage were identified. Certain informationis captured to be used by people for documentation and con-trol purposes, while other information is necessary for thegeneration of data definition language, data manipulationlanguage and application program processors. For illustra-tive purposes the following table shows the information cap-tured in a data dictionary and its uses by various users.

-84-

•1!

II

II DDL

II

• 11

11

11

DML II Appl icationII Processor11

• 11 -

I n format i onin DD

People

Name, TypeLength

StructureRelationship

Synonyms

Textural Desc.

Access Control

Edit & Val idat ion

Key/Non-Key

Usage Info.

Freq. of Access

Physical StorageSpecification

-85-

7.7 APPENDIX 7 - END-USER/QUERY LANGUAGE

The following subjects were considered when preparingthe End User Facility recommendations.

++ L i St of End User F a c i 1 i t i e

s

.

1. Report Specification Language2. Enquiry Specification Language3. Update Specification Language4. Parametric Interface

++Li_st £f Classes Of Users .

1. System Anal yst s/DBA ' s Staff2. Application Programmers3. On-line Job- trained User4. Researcher5. Casual User

++Measures of Query Languages .

1. Quantitative Measuresa . Levelb. Completeness

2. Qualitative Measuresa. Mathematical Sophisticationb . Learnab i 1 ityc . Procedural ity

++ Li St of Variable Features In End User F a c i 1 i t i e

s

.

A. Procedural ity1. Procedural

a . logicb. navigation

2. Non- proced urala . form fillb. question/answerc . menu

B. Report formattinga . flexibleb. pre-formattedc. automated display of draft format

-86-

d . construction assistance

C. Request Analysisa . monolithicb. incremental

D. Levela. % code reduction vs. COBOL (keystrokes)b. % coding tim'e reduction vs. COBOL

E. Default treatment

F. Ratio of simplicity to functionality

G. Retrieval criteria permitteda. mathematical operatorsb. logical operatorsc. 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 itya. within queriesb. similar to query syntaxc. special syntaxd. transaction orientede. form-fill

L. Navigationa. DBA intervention required to change access pathsb. fixed path chosenc. multi-path ambiguity negotiated

M. Execution efficiency

N. Aggregation operationsa . sort f 1 exibil ityb. sort efficiencyc. data clumping capability

0. Reusability of user constructsa

.

s i m p 1 icity of retentionb. s i mpl ic i ty of t empora ry mod i f i c at i onc

.

s i mpl icity of permanent modi f i cation

P. Data type support

-87-

a. different types handledb. conversion supportc. ease of addition of special types

Q. Fog indexa. documentationb. syntax

R. Benchmarking

-88-

ilrU^. GOVERNMENT PRINTINeomCE: 1S79 0—281-067 (173)

HBS-114A IREV. 9-78)

U.S. DEPT. OF COMM.

BIBLIOGRAPHIC DATASHEET

1. PUBLICATION OR REPORT NO.

NBS SP-5OO-5I2,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 STANDARDSDEPARTMENT OF COMMERCEWASHINGTON, 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-600087I 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 fordatabase standards within the FedersLl government. The voluntary participantsfrom several Federal agencies considered the actions of other standards bodies;reviewed the alternatives to Federal standards; examined the issues of standardsadoption, timing, and impact on technology; developed a method for justifyingstandards, 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 needfor certain guidelines.

This final report of TG-24 contains the recommendations for standards,

and guidelines as well as the assumptions, benefits, and costs considerationsused 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 IFor Official Distribution. Do Not Release to NTIS

[^]fOrder From Sup. of Doc, U.S. Government Printing Office, Washington, DC20402, SD Stock No. SN003-003-0209 5 -8

I IOrder From National Technical Information Service (NTIS), Springfield,

VA. 22161

19. SECURITY CLASS(THIS REPORT)

21. NO. OFPRINTED 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 "Mathe-

natical Sciences."

piMENSIONS/NBSifhis monthly magazine is published to inform scientists,

ijjngineers, businessmen, industry, teachers, students, andconsumers of the latest advances in science and technology,

jvith primary emphasis on the work at NBS. The magazinelighlights 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 indus-

itrial practice (including safety codes) developed in coopera-

jtion 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, man-

j

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 quanti-

tative data on the physical and chemical properties of

jmaterials, compiled from the world's literature and critically

ij evaluated. Developed under a world-wide program co-

j

ordinated by NBS. Program under authority of National1' Standard Data Act (Public Law 90-396).

NOTE: At present the principal publication outlet for these

data is the Journal of Physical and Chemical ReferenceData (JPCRD) published quarterly for NBS by the Ameri-can Chemical Society (ACS) and the American Institute ofPhysics (AIP). Subscriptions, reprints, and supplementsavailable 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. Oftenserve 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 shop-

ping 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 fromthe National Technical Information Services, Springfield,

Va. 22161.

Federal Information Processing Standards Publications

(FIPS PUB)—Publications in this series collectively consti-

tute the Federal Information Processing Standards Register.

Register serves as the official source of information in the

Federal Government regarding standards issued by NBSpursuant to the Federal Property and Administrative Serv-

ices 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

IThe following current-awareness and literature-survey bibli-

I ographies are issued periodically by the Bureau:I Cryogenic Data Center Current Awareness Service. A litera-

ture survey issued biweekly. Annual subscription: Domes-tic, $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 subscrip-

tion 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 COMMERCENational Bureau of StandardsWashington, D C. 20234

OFFICIAL BUSINESS

Penalty for Private Use. S300

POSTAGE AND FEES PAIDU.S. DEPARTMENT OF COMMERCE

COM-215

SPECIAL FOURTH-CLASS RATEBOOK