.

288 Briefira cs

1. icrtsoduction

The concept of Information Resource ulallilge- ;nett (IRIM) is that information is a vital ass4 0 ’ an orga.mzation; information should be invested in, ll:on- trolled and valued like other resources. finag::ment’s ability to measure performance, to create boxhis Gth the consumer:, to gauge competitors’ actions aml to

adapt to the marketplace depends on accurate timely and understandable data. Because data are expensive, they must be handled in such a way that they are i.:or- rect and are available to produce needed informatmn. Aspects of data handling include measurement, Sol- lection, transcription, validation, organization, s1 or- age, ,rggregation, update, retrieval and protection.

In recognition of the IRM concept and the diffi- sultjes of properly managing data, many firms have acquired data management software, such as Data Base Management Systems (DBMS), and have created data administration functions [9 ] . The ultimate ob jec- tive of these efforts is to make the informat Ion resource resilient, flexible and adaptable to supplJrt deciuon-making activities. The following guideli tes faciilir:ate achieving this objective: #Data must be represented and stored so that tl!ey

are preserved for later access. a Data must be protected and managed so that tl ey

retain their value. @ Data must be massaged and presented in forms tl tat

sup:~N users’ decision-m,aking styles. The focus of this paper is the utility and structure of ,Dicknary/Directory (D/D) Systems. Readers who want additional background on aspects of DfD $ys- terns that are not included here, e.g., the selectilon a.ad evaluatioti of a D/D System, should consult [J’,8,12,13,15J. A D/D System is one of the most lo- tent toois avClabIe to support the DBMS and de.ta a4mirtisti~ator in achievement of these data manage- ment guidelines. Use of a D/D System can mean accomplishing a major step toward gaining contl,ol sf the information resource.

2. D/U System Objectives

The! fundamental responsibility of a D/D System is ‘to manage meta-c’tata, which is the name given to data

zat describe other data. A D/D System thus maua-

ges a description of an organization’s information resource.

There are three ways that use of a D/D System can help an organization gain control over its data. (1) hventory management. The D/D System provides an inventory of the data that comprise the resource and of the programs, transactions and screens used to access the resource. The inventory includes names, defmitions, locations, storage formats, sizes and other characteristics. With this repository of information, standards for names, access, storage, security and vali- dation can be implemented and enforced more easily. (2) Cbst control. A D/D System helps to control the costs of developing and maintaining computer-based applications. A D/D System can provide an accurate and complete library of data definitions for use both in application programs and in canned program gene- tators such as report writers and query processors. Maintenance efforts can also be facilitated through use of reports generated by the D/D System that help to predict the effects of change in one part of an information system on other parts of the system. (3) Resiliency. A D/D System improves the resiliency of the data resource to changes in the data processing environment. Achievement of data independence from the characteristics of a particular hardware and soft ware environment allows the information resource to adapt to changing requirements [ 181.

At the heart of a D/U System is a database, called the D/D, that contains the actual meta-data that des- cribe data, processes, interfaces, users and hardware. Note that the D/D does not contain actual object occurrences. For example, for the data element SOC- SEC-NO, the D/D might contain attributes such as leugth, type and value range, but it would not con- tain any actual social security number values.

As indicated by its name, a D/D functions as both a dictionary and as a directory. The dictionary use of a D/D facilitates the global use of data definitions in applications, For example, a terminal user can use a -D/D to ascertain the names, meanings, headings, cade descriptions and display formats of all elements within his domain. The D/D can provide descriptions of user data to a DBMS. The directory use of a D/D permits applications to access stored data without concern for their physical locations or characteristics. Applications programmers can rely on D/D System support to ensure proper access authorization, to con-

M.E. Loomis et al. /Integrated Directory Systems 289

vert nonprocedural requests into physical access calls and to return data in appropriate formats.

Originally, D/D Systems emphasized only the dicti- onary utility of a D/D. These D/D Systems featured extensive reporting capabilities that expedited the design, maintenance and use of applications. For example, the typical D/D System provided a listing of all programs that referenced a specified element. Thus an analyst quickly knew which programs to recompile if a format change occurred. Because of this emphasis, the term “Data Dictionary System” was applied. More recently, the integration of the D/D with other software packages has been empha- sized. An integrated D/D System permits other sys- tems directly or indirectly to access the D/D and automatically converts the metadata of these systems into the format of the D/D System.

As distributed database systems become more pre- valent, the directory role of the D/D will continue to expand. The D/D can play a significant role in the management of transactions to a distributed database. Its contents can be used to determine where data are located, to plan transaction execution strategies, to coordinate multiple-site updates and to ensure adhe- rence to validity and security controls. In the distri- buted environment, the D/D itself becomes a specia- lized distributed database.

Six groups of users can benefit directly from use of a D/D System: (1) -Data admini .lrators, who use the system as a major tool for inventorying the data resource, imple- menting standards, and ck&ning, monitoring and restructuring databases; (2) Application personnel, such as analysts and programmers, who use the sys- tern to reduce program coding efforts, to store the designs of evolving systems and to support analysis of system changes; (3) Operations staff, who retrieve information about jobs from the D/D; (4) Data pro- cessing management, who receive high-level impact and summary reports about data usage from the D/D; (5) End-users, who obtain descriptions of their data views from the D/D; and (6) Auditors, who examine and obtain data descriptions for use in auditing soft- ware.

3. D/D System Components

A D/D System can be viewed as a computer-based information system with four basic components: l A meta-data database (the D/D), also called a meta-

base, that describes the data, processes, users, and processors of an organization;

@ Retrieval and analysis capabilities that assist a wide range of user groups in application development;

@Functional intet$aces that permit other software modules to access the D/D and that convert meta- data from other software systems into the formats required by the D/D System;

l Data management tools that help ensure :le secu- rity, validity, recoverability, integrity and shared accessability of the D/D.

3.1. The D/D C&tent

A typical D/D contains data that describe the fol- lowing aspects of an organization’s information resource: (1) Internal data, including data elements, logically related groups of data elements, recc, files, databases and sub-sets of databases; (2) Inpul- Output, including user transactions, screens and reports; (3) Equipment, including computers, com- munications facilities and terminals; (4) fiocesses, including programs, modules, systems and manual procedures; (5) Users.

Some systems provide as many as 500 different attributes to describe the above-listed entities. Many of these attributes (especially those applicable to internal data and input-output) correspond to clau- ses found in data definition languages (DDTs) of DBMSs and in programming languages such as COBOL.

A turn-key D/D System may not meet the specific requirements of a particular organization, so an ex- tensibility feat wre is often available from the vendor. This feature Aows an organization to tailor its D/D structure by defining additional entities, relationships and attributts. Extensibility can be provided in twro ways. In the simpler approach, the vendor supplies qtionul setr of objects, e.g., those required to des- cribe a structured design methodology or a message- formatting environment. In the more dynatic approach to extensibility, the D/D System accom- modates user-defined entities, relationships and attri-

b&s. Uslerdefmed entities are generally subject to constraints; for instance, a new entity may havt to be special case of a predefmed entity [15]. Clearly the second approach gives the user organizati.>n more flexibility of expression in the D/D, but results in a more complex D.&I System.

Another important characteristic of a D/D is the ability for entity occurrences to exist in different states. For example, test status can be used to docu- ment evobing I;ystsms and uncompleted changes to reductional systems. The file descriptions for a new

program of an existing system have test status until the progra’n is thoroughly tested. Production status occurrence:; in the D/D reflect operational systems.

cause the security of productional status informa- t k9m can be of concern, update access is usually reser- ved for the data administrator. Xstwic status reflects superseded meta-data, providing an audit trail of changes to the D/D. Version numbers may be used to allow multiple occurrences of one entity to exist in the D/D with the same status.

3.2. Retrieurl and Antarysis Gzpabilities

A typi4 D/D System includes two types of retrie- val and analysis capabilities. The Report bocessor function pro-tides predefiied reports, the ability to customize there reports and a user-defined reporting apability. Commonly predefimed report types inclu- e: (I I) .Narx lickings such as keyword-in-context

(KWJC) and keyword-out-of=context (KWOC), (2) Relationship reports, e.g., names of all the record

contained in a database, (3) Detail reports, e.g., ns for all elements with a common key- Summary reports such as the compilation

change description, nuimber of source lines and responsible programmer for all programs in a

recent version lllf a subsystem, (5) Matrix reports such pe of access (input, output, input-output) to all

i&in a program, and (6) Graphical reports, e.g., wing the hierarchical structure of a program’s c. The vendor often provides a method to custo- e report B~mats. Sometimes the user can define

reports, commonly using the vendor’s report writer. For exam users of CuBinane’s Integrated

[3] = define new reports report writer, wlich was written

as .m interface to IDMS, the DBMS on

which IDD is implemented. The Query Processor function of a D/D System

allows natural-language-like (e.g., English, French, German) queries of the D/D. This query function for the D/D is analogous to the corresponding function in DBMSs for access to databases and is used for low- volume, interactive retrieval of information from the D/D.

3.3. Functional Interfaces

The benefits of a D/D System for controlling the information resource can be maximized if the D/D is the sole source of metadata for the information sys- tem. A Software Interface function of a D/D System provides a formatted pathway enabling the D/D to provide meta-data to other software systems, such as compilers and DBMS DDL processors, and enabling these systems to retrieve and update information in the D/D. A software interface amponent might gene- rate file descriptions for a program library; another might accept a Ilser’s identification code and then generate a copy of that user’s database view from the D/D. Interface with a compiler might include genera- ting file and record definitions that the compiler accepts via a copy statement.

Many software packages use their own, built-in metadata fues. The Convert Function of a D/D System reads application programs, libraries and schemas and generates input transactions that des- cribe the detected meta-data. These transactions are then used to load data into the D/D. This automated conversion facility alleviates some of the problems of initially loading a D/D from the variety of sources of meta-data that may exist in an organization.

Clearly inconsistencies arise if changes are made to the D/D without changing the meta-data con- trolled directly by other software packages and vice versa. The better the D/D System is integrated with other software packages, the better is the potential for control of the. information resource.

3.4. Data Management Tools

The D/D System has a variety of functions for pur- poses of managing the D/D. These functions, like the retrieval and analysis cay;~bilities, actually may be provided by a DBMS that manages the D/D as well as

ME. Loomis et al. /Integrated Directory Systems 291

-

(A) Keyword driven language

ADD ELEMENT Customer-Number PASSWORD IS 'XVZA'; COBOL-NAME CUSTNUM; TVPE numeric; LENGTH 10; KEV OF custrecord; DISPLAV-FORMAT '99-999-99999'; USAGE packed-decimal; DESCRIPTION;

Customer-Number uniquely identifies each account holder. The first two digits identify the district, the next three the local branch, and the final five digits specify the customer;

(B) Fixed-format input

+ADD )b ELEMENT, Customer-Number 1001 16 PSWD = 'XYZA', CNAM = CUSTNUM, TYPE = num, LNGT = 10, 1002 16 DEKV = 'custrecord', DFRM = '99~gg9-ggggg', USGE = p&c; 1003 16 TEXT;

Customer-Number uniquely identifies each account holder. The first two digits identify the district, the next three the local branch, and the final five digits specify the customer.

1003 I ENDT

(C) Prompted input

GIVE FUNC (FUNCTION = NAME) $ ADD ELE = Customer-Number GIVE PASSWORD 3 'XVZA' GIVE COBOL-NAME

CUSTNUM h/E TYPE .

&VE :L'$!;; 3 10 ---

Fig. 1,Examples of D/D Maintens -ice Interfaces.

user databases. Alternatively, the D/D System may provida its own data management support for the DP.

The D/D Maintenance function interprets and pro- cesses requests to add, modify or delete contents of the D/D. The prevalent maintenance functions pro- vide a variety of languages to enable a data admini- strator to specify changes to the D/D. These inter- faces include : (1) keyword-driven languages, (2) fixed-format transactions, (3) interactive, prompted input, and (4) interactive, preformatted screens or menus [7]. Fig. 1 illustrates the first three types of input.

The D/D Management function performs the usual database management tasks such as security, integri- ty, concurrency control and internal access for the D/D. Again, many D/D Systems utilize the servic 3 of an existing DBMS to provide aspects of this function.

The Extensibility function of a D/D System enables the D/D structure to be extended by the deli- nition of additional entities, relationships and attri- butes. For example, a *‘clone” transaction could be used to add a new type of entity that has attributes identical to an existing entity type [15]. Other types of extensions may require more elaborate specifica- tion. For example, to add a totally new type of enti-

292 Sriefings

ty. it may Iw necessary to: (1) create the specification for i’. new transaction type, (2) create a file ot‘occur- Rena of the new entity and (3) create specifications for additional relationships to be included in the D/D.

The Licit Facility of a D/D System enables exten- sion of the vendor-supplied routines for processing the D/D. For example, the user organization might code additional validation constraints to be applied prior to d,:letion of an occurrence of a particular entity type from the D/D, or a new security check might be coded for use upon access to an attribute. An %it Facility is not available in all D/D Systems because oti the possible harmful side-effects that its clSe may introduce.

Elnvironmental Dependence

The environmental dependence characteristic of D/D System Describes its reliance on a specific

h&ware cojlfiguration, an operating sysfcm, a DBMS and/or a teleprocessing monitor. Cledriy the environmental dependence of a particular Df9 Sys- tem k a major factor in determining whether or not it will function in a particular organization.

Most interesting is environmental dependence of a D/D System on a DBMS. The extent of this depew- dence is determined by the degree to which the D/D ‘System relies on the DBMS for data management services and on the source of meta-data used by the DBMS for access to user databases. The DBMS can obtain metadata from either the D/D or its own directory or schema files.

There are three basic forms of environmental dependence between a D/D System and a DBMS (Fig. 2) 17,141. (1) The systems may be independent. The O/D System is freestanding and does not rely on any particular DBMS. The DBMS maintains its own WMICC+ of metadata; the D/D System uses none of the DBMS utilities for data jmanagement. One benefit of this zpproach is that one D/D System may provide datQ control support in a variety of environments with dif%rent DBMSs. An example independent D/D System is DATAMANAGER, from MSP, Ltd. [lo]. (2) The systems may be dependent, with the D/D appe:aring to the DBMS as just another database. The DBMS maintains its own meta-data, separate from the D/D. The DBMS utilities provide most of the D/D

(A) Independent Approach

I

0 D/D

DDL

(6) Dependent Approach n

(C) Embedded Approach

DBMS

1 D/D SYSTEM . ]

Fig. 2. D/D System-DBMS Relationship.

management functions, but meta-data are defined separately for the DBMS and for the D/D System. In this approach, the Q/D System interfaces primarily with one DBMS gnd its related components, but may pass meta-data !.3 other DBMSs that operate on the same machine. An example dependent D/D Sys- tem is DATADICTIONARY, from Applied Data Research, Inc. [ 11, (3) The D/D System may be embedded in the DBMS, The DBMS utilities provide the D/D management faciliti. ,s and the DBMS uses the D/D to direct access to user databases. No other internal directories exist for the DBMS; the DBMS and its related components rely completely on the D/D for meta-data. For example, a query processor extracts user views from the D/D and the DBMS applies integrity constraints specified in the D/D before storing a data element. Because the D/D Sys- tem is actually a component of the DBMS, it clearly can be used only with that DBMS. An example embedded D/D System is DIRECTORY, from Cin- corn, which is the controlling element for Total Information Systems (TIS) [2].

M. E. Loomis et al. / Integrated Directory Systems 293

5. Interfafcing the D/D to other Software

The D/D System that is integrated with other soft- ware in an information system is better able to pro- vide effective data control than one which is not. A D/D can provide meta-data to other software either statically or dynamically.

A sta& inferface links the D/D with another sys- tem indirectly via the extraction of files of formatted metadata. There is no run-time connection between the D/D and the other system. For example, a data administrator might enter into the D/D System all pertinent transactions to describe a database. After reviewing the accuracy of this database description, the data administrator could activate a D/D System command, e.g., GENERATE, that would use this des- cription to produce a fife containing DDL. The DBMS’s DDL Processor then would translate this generated DDL into a schema file that the DBMS later could access.

Static interfaces differ somewhat depending upon whether they interface the D/D System with user- written programs or with vendor-supplied software packages. Static: interfaces for user-written programs produce flile, record and database descriptions in COBOL or PL/I terms for copy into user programs. These interfaces sometimes feature edit capabilities, format options and various other functions to make the interface A lore flexible.

Static inter+‘aces fov :oftware packages, e.g., DDL processors, communicatrqn monitors and query pro- cessors, produce formatted statements for those pack- ages or create specially encoded control files for their use. For example, a software interface of UCC’s D/D System, UCC TEN [ 171, generates message and termi- nal description statements from its D/D for use by IBM’s Message Format Service, while Cullinane’s IDD [3] creates from its D/D the control file utilized by the IDMS-DC communications monitor. The options for customizing the D/D interface with these types of software packages are more limited than are the options provided for interface with user-written pro- grams; the packages generally have more rigid lan- guage formats and the interface statements are gener- ally used only by the datg administrator.

A dynamic interface provides software modules with direct access to a D/D, commonly via high-level interface commands that shield the software pack-

age from the physical details of the D/D. The com- mands activate standard D/D System functions, e.g., to select all entity occurrences that satisfy a condi- tion. Dynamic interfaces provide greater potential for data consistency control than do static interfaces. Changes to the D/D are reflected automatically in the next execution of any software packages to which the D/D is interfaced; no intervening procedures are required as are with static interfaces. A software package can directly retrieve and update meta-data stored in the D/D. All requests by software packages for meta-data are routed through the D/D System by a dynamic interface function. Thus the security and validity checks of the D/D System are always applied. A drawback of a dynamic interface is the perfor- mance degradation that may be caused by frequent access to a large D/D.

6. Convertkg to a D/Q System

A typical organization that acquires a D/D System has hundreds or thousands of programs, reports and files to manage. Converting to a D/D System and loa- ding the D/D with the meta-data to describe the information resource can be a formidable task if approached in a brute-force way by coding mainte- nance transactions to capture all the metadata. Many D/D Systems provide convert functions that scan source programs, database descriptions and telepro- cessing environment descriptions and automatical!y produce many of these transactions, thus sparing the data administrator many hours of manual effort. Actually, the data administrator must scrutinize these generated transactions for redundant and non- standard entries. For example, if the naming con- ventions used in source programs were previously uncontrolled, then the data administrator will find it necessary to change naming details in many of the generated transactions in order to impose standardi- zation before leading the D/D.

Like the software interfaces provided to extract meta-data from a D/D, the convert functions are offered to load a D/D from both user-written pro- grams and canned packages. For example, a D/D System may furnish conversion facilities for several programming languages (e.g., COBOL, PL/I, assem-

294 Briefings

bler), as well as for the DDlL Processor and r?port writer of a given DBMS.

The input file to a convert function can be a soa~ce program or a library file. If the input is a source program, then the convert function can cap ture infformation about data usage by the progra,‘! (e.g., the way a file is opened). If the input is d Wary file, then only the data descriptions that actually reside in the h%rary file can be convertb.$d to the D/D format. Options for a convert function may include the ability to change names, to select line to scan, to select types of transactions to create and to override generation of some types of

eta&Ha [lO,lS]. Sourz program analysis for input of meta-data

10 the D/D involves intra-program 3nd inter-program usage of data. Intra-program analysis detects the types of reference (e.g., input only, update) to data elements. InteraVprogram analysis ~~3x1s code for adherence to standards and discloses inconsistencies in the Iflgmes, formats and descriptions (e.g., initial values) of the data defmitions used in sever31 pro- grams and the corresponding deftitions in the D/D. Both types of amlysis could be used to make the D/D in part self-generating; however the convert func- tions of commercial D/D Systems rarely examine pro- cedure Irarts of source programs and therefore today perform only limited intra- and inter-program anlaiy- SlS.

7. chutirons

Over the last live years, D/D Systems have evolved . to a tremendous tool foa systems development.

ever, the effective use of a D/D System depends strl3ng data administration commitment . TJrpic-

dEy, a data administration group needs several years of experience before being able to use 3 D/D System

ctively- The data administration group must have supI~~rt of top management *h the form of a cor-

porate c%rter, as well as high visibility in the orgyni- zatiolm. This support is difficult to obtain in many organtitions. Application of a D/D System is facili-

ien standards are already fully in pl,ace, e.g., s pertaininlg to names, change control, pro-

am logic, and system design. Even with a strong organizational commitment,

3n organization faces difficulties beca.use of the limi- tations of commercially available D/D Systems. The command languages of most D/D Systems are not suitable interfaces for most users. Many organizations are clamoring for interfaces that a naive user can easily grasp. Organizations also are requesting more support from D/D Systems for system development methodologies (51. Few D/D Systems today provide the reports, consistency checks and graphics capabili- ty required by the commonly used methodologies for systems design and development.

A related problem is created by the lack of sup- port for an independenr view of the information resource. Most D/D Systems ;support one or more DBMSs, communication inonitors and p:ogramtning languages, but do not support an enterprise model and the concept of an independent logical view. An enterprise model is a corporate-wide view of the busi- ness functions and infonnation required to conduct those functions. The logical view describes the detailed application requirements, independent of any software products such 3s DBMSs or communica- tion monitors [ 11). The D/D System should facilitate the validation of an enterprise model against an orga- nisation’s logical data and application views.

Pn organization that is converting to a D/D Sys- tem must face the difficult question of how extensi- vely the D/D will pervade the data processing environ- ment. Rather than retrofitting the D/D to include all applications areas, most organizations choose to apply their D/D Systems only to new application areas, letting the older systems run their co’uses to eventual replacement before entering the D/D. Other organizations tackle the job of converting all systems to D/D System support, thus providing better integra- tion of the entire information resource. The tradeoff to be considered is the cost of retrofitting the D/D to old systems versus the problems of inconsistency and lack of control that may arise if the old systems are not converted.

A final problem is the control of multiple D/Ds. Ideally the D/D should be the tigle repository for describing the information resource, but many orga= nizations operate with multiple D/Ds due to the ina- dequate performance of a single D/D and for politi- cal reasons. Few if any D/D Systems manage the access to and control of multiple D/Ds. Some firms have an even greater prajblem because of multiple

M.E. Loomis et al. /Integrated Directory Systems 295

D/D Systems. Firms acquire multiple DJD Systems due to vendor pressures (e.g., the D/D System is included with the DBMS), for political reasons and to take advantage of product features. Peaceful co-exis- tence of multiple D/‘O Systems is a not easily achieved goal in these heterogeneous environments.

8. Conclusions

The demand and supply of D/D Systems today are indicative of their growing significance in IRM. The fifteen largest D/D System vendors have installed approximately two-thousand systems, primarily in large organizations. Many other organizations utilize D/D Systems that were developed in-house; many even use manual systems. The potential demand for commercial D/D Systems seems vast because many of these home-grown systems are rudimentary in compa- rison to the commercially available D/D Systems. Many vendors have entered the D/D System market in the last few years and several additional D/D Sys- tern offerings are planned. Today’s D/D Systems are used primarily in fairly large configurations; tomor- row’s also will invade the small computer market.

Integrated D/D Systems thus have important roles in controlling both centralized and distributed information resources. The benefits of a D/D System include increas 3 control over the data, reduced cost and time requirements fc-r application development and enhanced indepenc\:nce of meta-data across computing environments.

In the near future, development in eight related areas seems likely. (1) Vendors will release distributed DBMSs that are connected to their 0/D Systems. Independent vendors will upgrade their O/D Systems to interface statically with other vendors’ DDBMSs. (2) D/D Systems will support the prevalent systems development methodologies via graphics and enhanced reporting and control features. (3) lm- proved interfaces will be developed to accommodate naive users, (4) D/D Systems will evolve to support an enterprise model and DBMS-independent view of the information resource. (5) Design aids and peformance evaluation software will interface with D/D Systems. (6) Standards for D/D Systems will emerge by 1984.

(7) D/D Systems will have the ability to manage mul- tiple D/Ds. (8) Vendors will develop D/D Systems for use on small computers U/D System functions will migrate into operating systems of some of the small machines.

D/D Systems will play increasingly important roles in IRM. Use of a D/D System is a necessary first step toward achieving control of the data resource.

References

(1 ] Applied Data Research, Inc. DATADICTIONARY User Reference h”anual, 1979.

(21 Cincom Systems, Inc. TIS: A Technical Overview, 1980.

[ 31 Cullinane Carp. IDD User’s Guide, 1978. [4] R. Curtice and E. Dieckman, A survey of data dictiona-

ries, Datamation, Vol. 27,3, 1981, pp. 135-158. [S] R. Curtice, Data Dictionaries: an assessment of current

practice and problems, Proc. 7th Intl. Conf. on Very Large Data Bases, Cannes, France, 198 1.

16) DDSWP The British Computer Society Data Dictionary Systems Working Party Report, Data Base, Vol. 9, 2, 1977;‘ACM SIGBDP and SIGMOD Record, Vol. 9, 4, 1977.

[7] H. Letkovits, Data Dictionary Systems, QED Informa- tion Sciences, 1977.

[8] J. Lomax, Data Dictionaries, National Computing Centre, Manchester, England, 1977.

19) J. Lyon, The Database Administrator, John Wiley and Sons, 1976.

[lo] MSP, Ltd. DATAMANAGER User’s Guide, MSP Tech- nical Documentation, 1980.

[ 11) H. Patel, How to upgrade a DBMS, Datamation, Sept. 1981, pp. 127-132.

[ i2) 13. Plagman, Data dictionary/directory system: a tool for data administration arid control, Auerbach Series on DBMS, Vol. 22-01-02,1977.

[ 131 13. Plagman and Moss, C. ‘alternative architectures for active data dictionary/directory systems, Auerbnch Series on DBMS, 22-0442, 1978.

[ 141 E.H. Sibley, et al. The software configuration manage- ment database, Proc. Nat’l. Computer Conf., 1981. pp. 249-25s.

[ 151 Synergetics Corp. DATA CATALOGUE 2 System Stan- dard Facilities Manual, 1980.

[ 161 13. Uhrowczik, Data dictionary/directories, IBM Syst. J. vol. 12,4,1973, pp. 332-350.

[ 171 University Computing Company, UCC TEN Concepts and Facilities, 1979.

[ 18 ] Wilson, T. (ea.) ANSI/X3/SPARC Database Systems Study Group - Standing Paper 1, Version 1.1, 1980.