Download View/Open - Calhoun: The NPS
Transcript
UNCLASSIFIED SECURITY CLASSIFICATION OF THIS PAGE REPORT DOCUMENTATION PAGE 1a REP6RT SECURITY CLASSIFICATION 2a SECURITY CLASSIFICATION AUTHORITY 3 DISTRIBUTION/AVAILABILITY Approved DECLASSIFICATION DOWNGRADING SCHEDULE 2b RESTRICTIVE MARKINGS ib. UNCLASSIFIED distribution PERFORMING ORGANIZATION REPORT NUMBER(S) 4 6a. NAME OF PERFORMING ORGANIZATION (if ADDRESS Monterey, 8a. 8c. 1 1 . CA 7b. ADDRESS (City, State, and ZIP Code) Monterey, CA 93943-5000 93943-5000 NAME 6E FUNdINg/sPoNSorINg ORGANIZATION ADDRESS NAME OF MONITORING ORGANIZATION Naval Postgraduate School CS and ZIP Code) (City, State, 8b. OFFICE SYMBOL (if TITLE (Include Security PROCUREMENT INSTRUMENT 9 IDENTIFICATION NUMBER applicable) 10. SOURCE OF FUNDING NUMBERS PROGRAM PROJECT TASK ELEMENT NO NO. NO. and ZIP Code) (City, State, unlimited 7a. applicable) Naval Postgraduate School 6c. SYMBOL is MONITORING ORGANIZATION REPORT NUMBER(S) 5. 6b OFFICE Computer Science Dept. OF REPORT for public release; WORK 12. PERSONAL AUTHOR(S) Bourgeois, Paul A. 13a. TYPE OF REPORT Master's Thesis 16. supplementary notation (U) TIME COVERED 15. PAGE COUNT 14. DATE OF REPORT (Year, Month, Day) March 1993 from 04/90 to 03/93 The views expressed in this thesis are those of the author and do not reflect the policy or position of the Department of Defense or the United States Government. 13b. GROUP m. offici SUBJECT TERMS (Continue on reverse if necessary and identify by block number) Data model, data language, multibackend database system, multilingu 18. COSATI CODES FIELD r Classification) THE INSTRUMENTATION OF THE MULTIMODEL AND MULTILINGUAL USER INTERFACE 17. UNIT ACCESSION SUB-GROUP database system, multimodel database system, user interface design. 1 9. ABSTRACT The (Continue on reverse traditional single data of these if necessary and identify by block number) approach to database-management-system model and its corresponding data language tions to operate several different tabase-system design This approach is is the designs focuses upon the implementation of order to support applications for a given database task. Eac in monomodel and monolingual database systems data model-language can be supported on a single (DBMS) homogeneous database system, since only or database system. The application diversity forces many organiz represents a homogenous database systems to support its operations. A different approach to d development of a DBMS which supports multiple data models and their data language multimodel and multilingual database system (MM&MLDS) as implemented on th the focus of the Multibackend Database Supercomputer (MDBS). With the proliferation of new data model-languages to incorporate these in the database technology, the objective of MM&MLDS i: new data model-languages onto the same MDBS. The goal of this thesis is to develop procedure MM&MLDS as new interfaces. Three methods, and tools for the incorporation of new data model-languages into areas of research are critical to achieving this goal DISTRIBUTION/AVAILABILITY OF ABSTRACT SAME AS RPT. fj UNCLASSIFIED/UNLIMITED 22a. NAME OF RESPONSIBLE INDIVIDUAL 20. Q . 21. fj DTIC USERS 1473, 84 MAR APR 22b. edition All may.be used user's manual for familia ABSTRACT SECURITY CLASSIFICATION TELEPHONE (Include (408) 656-2253 83 MDBS UNCLASSIFIED David K. Hsiao DD FORM development of a First, the until exhausted other editions are obsolete Area Code) 22c. OFFICE SYMBOL CS/Hq SECURITY CLASSIFICATION OF THIS PAGE UNCLASSIFIED TOEGQ1 £ UNCLASSIFIED CURITY CLASSIFICATION OF THIS PAGE Continued: ization as well as instruction for system users. Second, the specification of generic processing lgorithms used as a foundation for each module of the new model-language interface. Third, our software meth19. dology considerations for new data model-language interface implementation. SECURITY CLASSIFICATION OF THIS PAGE u UNCLASSIFIED Approved for public release; distribution is unlimited THE INSTRUMENTATION OF THE MULTIMODEL AND MULTILINGUAL USER INTERFACE by Paul Alan Bourgeois Captain, United States Marine Corps B.S. Economics, United States Submitted Naval Academy, 1987 in partial fulfillment of the requirements for the degree of MASTER OF COMPUTER SCIENCE from the NAVAL POSTGRADUATE SCHOOL March 1993 Gary i^ugTiel^ Acting Chairman, Department of Computer Science in ABSTRACT The upon traditional approach to database-management-system the implementation of a single data model and its (DBMS) designs focuses corresponding data language in order to support applications for a given database task. Each of these monomodel and monolingual database systems represents a homogeneous database system, since only one data model-language can be supported on a single database system. diversity forces systems many A to support its operations. development of a approach This organizations to operate several different (MM&MLDS) With the objective of is DBMS the different approach to database-system design of the new the multimodel and multilingual database system (MDBS). data model-languages in the database technology, the MM&MLDS is to incorporate these new data model-languages onto the same MDBS. The goal of this thesis incorporation of new is to develop procedures, methods, and tools for the data model-languages into MM&MLDS as new interfaces. areas of research are critical to achieving this goal. First, the development of a user's is their data languages. as implemented on the Multibackend Database Supercomputer proliferation of application homogenous database which supports multiple data models and focus The manual for familiarization as well as instruction for interface. Third, our software data model-language interface implementation. IV MDBS system users. Second, the specification of generic processing algorithms used as a foundation for each new model-language Three module of the methodology considerations for new TABLE OF CONTENTS I. INTRODUCTION II. AN OVERVIEW B. OUR MOTIVATION AND GOALS THE ORGANIZATION OF THE THESIS C. THE MULTIBACKEND DATABASE SUPERCOMPUTER (MDBS) 1 A. A. ITS KERNEL DATA LANGUAGE THE MULTIMODEL AND MULTILINGUAL DATABASE C. SYSTEM PROCEDURES TO INTRODUCE NEW MODEL-LANGUAGE B. in. THE DESIGN THE KERNEL DATA MODEL AND INTERFACES A. B. C. THE CONTROLLER SOFTWARE NEW MODEL-LANGUAGE INTERFACE REQUIREMENTS a. c. d. 5 6 7 12 14 The The The The 14 Language Interface Layer Kernel Mapping System Kernel Formatting System 18 Kernel Controller 19 Among Module 14 16 22 2. Communications 3. Data- structure Requirements 25 4. The Makefile Development 27 VERSION CONTROL AND MANAGEMENT GENERAL STEPS TO A NEW MODEL-LANGUAGE INTERFACE A. THE MDBS USER INTERFACE D. 1. On 2. The User's Manual the Interface Familiarization OUR SOFTWARE METHODOLOGY 1. Models With A Formal Data Language 2. 3. Models With No Formal Data Language Kernel Model-Language Mapping Strategies THE CONCLUSION A. RESULTS OF OUR RESEARCH EFFORT B. FUTURE RESEARCH APPENDIX A. MDBS USER'S MANUAL V. 5 Considerations for the Language Interface Software Module b. B. 4 11 Design IV. 3 11 JUSTIFICATION 1. 1 27 29 29 29 30 32 33 34 35 37 37 38 39 APPENDIX APPENDIX APPENDIX B. C. D. MODEL-LANGUAGE INTERFACE GENERIC FUNCTION MAPPING MM&MLDS GENERIC MODEL-LANGUAGE DATA STRUCTURE GENERIC MAKEFILES FOR NEW MODEL-LANGUAGE INTERFACES 106 110 Ill REFERENCES 113 INITIAL DISTRIBUTION 115 VI LIST Figure 1 : Figure 2 : Figure 3 : The Multi-Backend Database Supercomputer The Multimodel and Multilingual Database System The Model-Language Interfaces as Implemented on Database System, Figure 4: Figure 5: Figure 6: Figure 7: Figure 8: Figure 9: Figure 10: Figure 11: Figure 12: Figure 13: OF FIGURES The 6 8 a Kernel MDBS File Organization 9 and Structure for Data Model-Language Interfaces within the Front-End Controller 13 The The The The Generic Algorithm for All Language Interface Layers 15 Generic Algorithm for All Kernel Mapping Systems 17 Generic Algorithm for All Kernel Formatting Systems 18 Schematic Diagram of Processing Steps of the Kernel Controller 21 The The The The The 22 Generic Algorithm for All Kernel Controllers Module Communication Path Module Communication Path Load 23 for Executing Transactions 24 for a Data-Definition 25 User_info Structure li_info Structure with the new_model_language_info 26 Included Figure 14: The Relationship Between Model/Language and the Test Interface Figure 15: The Lex and Yacc Parsing Processes vu Interfaces (ML/Is) 30 34 I. A. INTRODUCTION AN OVERVIEW Database systems have revolutionized the workplace by combining the advancements in today's information technology with the information governments. These organizations have come demands of to rely large corporations and heavily upon the efficiency of database systems to increase their productivity. Though the rapid growth that has taken place in the area of database research and development resulting in systems and increased productivities, has also presented it proliferation of different database systems, cannot communicate with each other. proliferation of heterogeneous In databases more a efficient database problem due to the heterogeneous database systems, that i.e. examining the factors and issues of the and systems, we must review first the conventional design of a database system. The design of a database system begins with the selection of a data model which characterizes the needs of data in order for the processing to be accomplished by the database system. Once an approriate data model has been selected, a corresponding data language and data languages include SQL (i.e relational, is chosen. network, or hierarchical) Some examples for the relational data model, of data models DML for the network data model, and DL/I for the hierarchical data model. Each database system can only support one specific pair of data model and data language are characterized as monomodel and monolingual. . These conventional database systems A user of such a database system must have thorough understanding of the underlying data model and data language supported by the system in order to use the system effectively. This restricts the user to the single data model and data language supported by the system. Any experience with another data model and data language will be useless, since the database system can not support that pair of data model and languag. A different approach to the database design is the incorporation of several data models and data languages into one database system [DEMU 87]. This more flexible database known design will result in a database system system (MM&MLDS). advantages not This approach found in as the to the database design provides several distinct approach conventional the multimodel and multlingual database to the database design. The consolidation of several data models and data languages on one system will defray the cost spent on procurring several different monomodel and monolingual database systems. The number of support personnel required consolidation of resources will also reduce the to maintain the different database systems. Replacement costs will be reduced since any system upgrade will only be necessary toa single database system instead of several. For example, if one conventional database system is upgraded, the other conventional database systems will not reap the benefits of the upgrade. With the models and data languages will benefit from the upgrade of the single database system. Re-training costs are also eliminated since a user MM&MLDS. models and data languages with a user who is MM&MLDS approach, all data is not required to learned a Through cross-modeling access inexperienced in using a certain new new data capability, data model-language can access a heterogeneous database with a transaction written in the data model-language more familiar to the user. For instance, a user SQL databases using the data language transactions, not The DL/I who is experienced in working with relational could access hierarchical databases using SQL (hierarchical) transactions. MM&MLDS concept is currently implemented at the Naval Postgraduate School's Laboratory for Database Systems Research on the Multi-Backend Database Supercomputer (MDBS). the characteristics MDBS associated is designed to support with a federated database transparent access to heterogenous databases, local database, and multimodel/multilingual capability. A MM&MLDS and together, to have system. They include the autonomy of each heterogeneous in-depth look into the database design approach to federated databases and systems can be found in [HSIA 92] and [HSIA 89]. B. OUR MOTIVATION AND (iOALS The MDBS currently implemented at the Naval Postgraduate School's Laboratory for Database Systems Research incorporates four data-model-and-data-language interfaces. These are (ABDL) the attribute- based-data-model interface, the (ABDM)-and-attribute-based-data-language relational-data-model-and-SQL-data-language network-data-model-and-CODASYL-data-language interface, interface, the and the hierarchical-data- model-and-DL/I-data-language interface. Four separate software modules are written for each model/language interface. The process of incorporating a new data model and data language into the current MDBS requires spending numerous man-hours deciphering the data structures and internal logic of previous model-language interfaces. The first goal of this thesis incorporation of a new new model-language data languages are developed, and efficient incorporation of to all interfaces looking at the therefore, to provide a pedagogical aid is, interface into the MDBS. As new data models and their we want to develop their interfaces. to procedures that will ensure accurate We will examine the internal logic common and highlight the necessary functions that a new interface must possess by four software modules that comprise each interface. Procedures will be presented which outline specific issues that must be addressed prior to any implemention of a new data model-language interface. The second goal of setting up set or user's manual for designed specifically as an introduction to MDBS for this thesis is to MDBS. The manual is develop an instructional first-time users, but will also function as a reference MDBS. Since no user's manual currently exists for the need for expert assistance for those manual will address topics request files, who manual for any further research on MDBS, this user's manual will alleviate desire to work on and methods such as starting and accessing each data model- language MDBS. The MDBS MDBS, interface. user's developing schemas and Sample databases given to assist the user in the understanding of each data model and its will be data language. THE ORGANIZATION OF THE THESIS C. Since of MDBS all is research efforts in this thesis have been accomplished for necessary which is presented in Chapter we focus upon the system structure, the kernel II. More MDBS, specifically, in an outline Chapter II, data model and the kernel data language, and the multimodel-mulitlingual database system design. procedures and methods for the introduction a new In Chapter III, we outline the data model-language interface. Issues such as program and data structure modifications, makefile development, as well as functionality requirements for each Chapter IV, we module within the model-language management address the various interface model-language interface is MDBS. incorporated into strategies when In Chapter V, we a new database enviroment, and design implementation data present our concluding thoughts concerning the interface management in the multimodel multilingual In interface. decisions for and the implemention of a new data model-language interface, and future work. Appendix A is the first volume of MDBS areas concerning the front-end software of file User's Manual. This manual details those MDBS to include the execution of MDBS itself, development, and the utilization of the data model-language interfaces. Appendix provides the generic mapping of functions required by as well as specifications for the each software all B data model-language interfaces module of the language interface. II. THE MUL TIBACKEND DATABASE SUPERCOMPUTER (MDBS) THE DESIGN A. The known heart of MDBS is the configuration of the database stores and database processors as database backends. MDBS relies upon these database backends to provide the storage and processing functions. Each backend consists of a microprocessor and three data disk drives; a smaller Winchester-type for paging and another smaller one for metadata and a larger disk drive for base data. in parallel via an ethernet MDBS architecture allows these backends to be connected LAN using point-to-point communication for one-to-one communications between separate backends and broadcast communication from one backend to many. A front-end microcomputer known as the controller, which is separate from the backends, controls the interface between the user and the backends and also provides for backup and recovery. In Figure 1, we illustrate MDBS architecture [HSIA 91]. Each database backend contains a portion of a stored database through a process called clustering. In clustering, the base data sets. The is spread across the backends in mutually exclusive distribution of the database records through clustering permits parallel access to the data and is integral to the high-performance of MDBS. When a transaction is broadcasted from the controller, each backend can execute the transaction in parallel with the other backends. The MDBS architecture allows for increases in performance and capacity through the addition of backends. Unlike the traditional database system which required an extensive and costly modification or replacement to achieve a decrease in the response time or a greater capacity without any degradation of the response time, addition of one or more backends performance gains achieved by to achieve MDBS MDBS such decrease or capacity growth. These through the addition of more backends are as the response-time reduction and the response-time invariance MDBS provides greater flexibility, since no modification which runs on MDBS. The number requires only the is [HALL known 89] required to the software of backends the system can support is not limited by connection ports of either the controller or a backend. Therefore, required for the incorporation of a new backend to the MDBS "down-time" little is configuration. At one time, there can be eight backends configured in the Laboratory for Database System Research Meta data disk Base data disks Paging disk Tape Drive Base data disks Controller - Paging disk The User Meta data disk Base data disks Paging disk Figure B. 1 : The Multi-Backend Database Supercomputer THE KERNEL DATA MODEL AND ITS KERNEL DATA LANGUAGE One of the requirements of a federated database system is to and their data support languages on the same, single system. Such a system multimodel and multilingual. MDBS is a database system many data models is known as being which uses a mapping function (1) to support amongst multimodel/multilingual capability and (2) to enhance data sharing its different heterogeneous databases. the different data models and their data language or kernel data model and sharing and kernel data language. its based data model (ABDM) its MDBS languages into a single data model and mapping algorithms can be found This kernel data model and have led The mapping function used by in (HSIA An maps its data in-depth discussion of data 92]. MDBS kernel data language used by is the attribute- and attribute-based data language (ABDL). Several factors to the selection of the ABDM; these include: the separate modeling of base data and meta data,the clustering of base data into mutually exclusive sets for storage on the backends, and the allowance of parallel accesses to the clustered base data. The semantic richness of ABDL SQL, DL/I, and Schema their allows for the translation of other traditional data languages, such as DML into ABDL for processing on MDBS. definitions and transaction requests developed for traditional data models and languages are either transformed or translated into equivalent schemas of the kernel data model or equivalent transactions in the kernel data language for processing in the kernel database system. Using the multiple- models/languages to the single-model- language mapping function, MDBS requires only (n-1) transaction translators, were n represents the and C. their languages to be supported in number of schema transformers and (n-1) different heterogeneous databases MDBS. THE MULTIMODEL AND MULTILINGUAL DATABASE SYSTEM In Figure 2, we illustrate multilingual database system (UDM) the general system structure of the multimodel (MM&MLDS). and Transactionswritten in the user's data model and user's data language (UDL) are transformed and translated into the kernel data model (KDM) and kernel data language (KDL) equivalent via interface. the Four software modules comprise the model/language MDBS model/ language interface. These are the language interface layer (LIL), the kernel mapping system (KMS), the kernel formatting system (KFS), and the kernel controller (KC). The following paragraphs with the language interface as well as UDL must first be processed by LIL. these transactions transactions. created, it Two KMS may KDM and KDL LIL forwards database-definition KMS. transactions Upon KDM-database definition to database system This transformation process successful transformation of KC. (KDS) where KDS when the passes UDM-database KDM-database new database is finally a LIL UDM UDL : : LIL KMS KFS KC M/LI KDS KDM KDL : : : : : : : : UDM/ Notice that query-request new database is called data-definition definition, KMS sends definition to the kernel defined on that the database definition has UDL UDM and transforms MDBS. The KC the database definition has successfully processed notifies the user through Figure 2 KC is KMS. or when First, takes the database-definition (or database schema) of KDM. and .Each transaction issued in these transactions to major tasks are accomplished by transformation. notified by be either into a database definition of UDM outline the general interaction between and been loaded. User Data Model User Data Language Language Interface Layer Kernel Mapping System Kernel Formatting System Kernel Controller Model/Language Interface Kernel Database System Kernel Data Model Kernel Data Language The Multimodel and Multilingual Database System KC is in turn Secondly, KMS transactions through a process these transactions to KC transaction execution, transactions translates known reformats KDM to sends the results results from KDS to interface. In other words, KC. The for execution. KC in KDM KDS interface supported forwards Upon completion of the format. Through LIL, the MDBS by own its has its set of LIL, own language KMS, KFS, and and consistency of each data model-language must be incorporated within the language interface modules. implementation of the KMS KDL UDM form. each language interface has functionality, integrity, equivalent format. In order to display the UDM into the correct results of the queries are displayed to the user in Each data model-language into UDM format, KC passes the results from KDS to KFS. results of a transaction in the proper KFS UDL in as the data-language translation. which passes them KDS written MM&MLDS structure in In, Figure 3, we represent the MDBS. (The index indicates i-th model-language i the interface) Figure 3 :The Model-Language Interfaces as Implemented on a Kernel Database System, MDBS Using its capability to model different data languages on one system, transactions experiment with different data MDBS models and models and affords their different prolierating stand-alone database systems. Further, a user pair which is best suited for the user's needs. incorporated into models and MDBS their data is the to user the data may choose Most importantly, translate the different opportunity to language without the model-language MM&MLDS concept an invaluable paradigm for the understanding the various data languages without having to use a separate database system for each data model-language. 10 III. PROCEDURES TO INTRODUCE NEW MODEL-LANGUAGE INTERFACES JUSTIFICATION A. As the database system continues to new education, and industry, grow in use and size within government, data model-languages will be developed to support the constantly changing requirements placed upon existing data model-language interfaces. At the Naval Postgraduate School's Laboratory for Database Research, able to incorporate these new design and programming teams must MDBS through hands-on exposure designing a new user interface model-language interface MDBS. The data model-languages into additional data model-language interfaces into the first become to the current is to MDBS we would is introduction of not a small task. First, the familiar with the idiosyncrasies of MDBS system. Since a primary focus of maintain consistency throughout each application (or in the case of MDBS) [SHN1 92], it is essential that designers and programmers understand the design of previous data model-language interfaces. Second, once these teams become familiar with the current version of thorough understanding of the general architecture of is like to be MDBS is MDBS, an required. This requirement generally satisfied by reading various papers written on the MDBS. Topics such as federated databases, database architecture, and multimodel/multilingual database design should be covered. Third, a review of previously designed and implemented data model-language interfaces must be accomplished. Each data model-language approximately ten to twenty thousand lines of programming code written Lex and Yacc. Few students Unix tools interface are familiar with the Lex and Yacc. Now, they must in programming language C, consists of C, and with let alone the learn these languages and tools in order to understand the internal logic of these previously designed interfaces. This review represents a majority of the of work that must be accomplished C code for the new data model-language interface. 11 prior to writing the first line Previous research has been conducted in the development of traditional data modellanguages; however, no research has been done in the area of data model-language interface management on MDBS. Too much time is spent on trying to complete the tasks previously mentioned. The development of an effective tool will alleviate the efficient is therefore necessary, so that the tools burden placed upon designers and programmers and is integral for an and accurate data model-language incorporation. Currently, no such tool The scope of First, a user this data-model-language-interface management strategy manual must be developed that introduces first-time user to functional as a quick reference for experienced users. Second, for each software the language interface contains procedures that are interfaces, an awareness of these features common to designers to all data and programmers threefold. is MDBS exists. and is also module of model-language is accomplished by the introduction of generic software module algorithms. Third, general steps must be provided for incorporating the fulfillment of this new data model-language interfaces into strategy that we are able to MDBS. It is through provide the paradigm for the instrumentation of the multimodel and multilingual user interface. B. THE CONTROLLER SOFTWARE The MDBS software. All version of the configuration MDBS MDBS software is separates the controller loaded under in a directory software. Currently that version is software from the named most current VerE.6. Subdirectories under the VerE.6 directory contain the software for each particular aspect of CNTRL after the backend MDBS execution. The directory contains the software for the data model-language interfaces as well as the software for the communications between the front-end controller and the backends. Our research focus is placed upon the software which comprises the data model-language interfaces. This software is located in the TI (for Test Interface) directory and subsequent subdirectories of TI. Figure 4 illustrates the file organization of the test interface directory and its relationship with the data model-language interface. 12 c N T R L CONTROLLER TO BACKEND COMMUNICATION SOFTWARE CNTRL Tl: Figure : Controller LI: 4: The Language Interface DMLI: Data Model Language Interface Test Interface File Organization and Structure for Data Model-Language Interfaces within the Front-End Controller Within the TI directory resides the program module which drives the user interface for MDBS. This program, ti.c, determines the number of backends the system has currently configured for execution, loads the schemas for existing database schemas, and displays the MDBS system menu. Implementors of new data model-language interfaces must include an option in the main (argc, argv) procedure of ti.c for the selection of the new language interface. This includes adding the appropriate case statement allow continued processing of the new model-language interface. Appendix B provides the test interface directory structure as The TI pertains to the MDBS a detailed outline of user interface. directory also contains the procedures for executing the kernel data model- language interface, a it to data model- i.e., new model-language attribute- based data interface. The introduction of interface does not require any modification of the in the test interface directory In order to alleviate the software modules, model-language MDBS with the exception of ti.c programs residing as mentioned above. burden of data passing among functions residing relies upon global data structures to in different communicate between software modules within the language interface. Within the TI directory, global datastructures and variables are stored in a header file 13 named licommdata.h. Part 4 of Section C outlines the data structures required relationship to the licommdata.h relationship required by C. all file. by all Appendix new model-language model-language interfaces and C their diagrams the generic data- structure interfaces. NEW MODEL-LANGUAGE INTERFACE REQUIREMENTS 1. Considerations for the Language Interface Software Module Design As previously noted, the language interface consists of four software modules: the language interface layer, kernel controller. mapping system, kernel formatting system, and kernel Each new data model-language introduced language interface modules; specifically, its own into LIL, each data model-language interface implemented on MDBS must include KMS, KFS, MDBS has It is its MDBS. This is new set all set of model-language must be data model-language interface on accomplished by examining the language interfaces of existing data model- languages and identifying the commonality that a. own unique these required functions and corresponding internal logic that addressed when designing and implementing a own and KC. Even though language interface software modules, certain functions must exist in interfaces. its is present in each module. The Language Interface Layer The language interface layer (LIL) of the MDBS between the user and the controlling software which drives model-language interface communicate with implemented the user via LIL. on MDBS, all Communications with functions as the bridge MDBS. Regardless of the model-languages the kernel interfaces mapping system, kernel controller, and kernel formatting system are also the responsibility of LIL. Since all model-language interfaces interact with the user be some form of consistency interface design for among the different user interfaces. in LIL, there must The goal of the user MDBS is to develop a user interface that is common for each different data model-language interface. Achieving this goal reduces the time required by the user to familiarize the user with the functionality of a different user interface with each data model- language present on MDBS. For instance, a user familiar with the relational/SQL user 14 interface does not have to learn a completely different user interface in order to use the hierarchical/Dl/1 interface. Each data model-language possesses LIL a similar pattern of processing for the We require that LIL is to adhere to a generic algorithm for the interaction with the user KMS, KC, as well as generic algorithm into the generic New and KFS. its model-language interfaces must incorporate own language interface layer. Figure 5 outlines the structure of LIL processing algorithm. Allocate and Process new If new initialize memory for data-structures. or old database? database... - Enter and store database name into the database catalog. - - Load schema input from the terminal or file. Load the file into linked-list. - Create template and descriptor files, index attributes - Send schema - - (in linked-list Display errors from Prompt to data structure) to KMS for parsing. KMS during parsing (if any). continue to process as old database or exit. If old database... - Check database name against the catalog. If not found check other model-language catalogs (this is for use with cross-model accessing only). if found in other data model-language, transform schema. Determine the mode of the input request. - - - Store requests in a linked-list data structure. - Display numbered queries - Option - Send the - Display errors from - Send the parsed request to the user. to redisplay queries or process a request. list of requests to KMS for parsing. KMS (if any). to KC for processing against a database KDS. - Display results from - De-allocate the Exit to Figure KFS to user. dynamic memory. main menu and repeat above steps or 5: this The Generic Algorithm for All 15 exit system Language Interface Layers in Notice that this algorithm applies directly to any data model-language interface implemented on MDBS. The language interface layer Much develop from a programmers stand point. is by far the easiest layer to of the code already developed from new previous model-language interfaces can be modified to suit the requirements of the model-language interface. The application of the generic algorithm guarantees consistency amongst the various model-language the LIL interfaces as well as the basic framework by which functions. The Kernel Mapping System b. The kernel mapping system is responsible for the parsing of the model- language based transactions for further processing in the kernel controller. This parsing involving the transformation and translation of transactions written in the user's data model-language into the data model-language of the kernel database system. Though transformation and translation of UDM-L takes place in KMS, transformation and translation being conducted. This is is is the user known is unaware that this as the transparency and one of the requirements of a federated database system. Designers and programmers of new model-language interfaces must ensure that KMS does not interface directly with the user but instead interfaces with the user through LIL. Again, this is to maintain consistency and transparency throughout the model-language interfaces. A majority of KMS is comprised of mapping and formatting algorithms that are specific to the model-language implemented. KMS must read input streams from LIL containing either data-definition or request transactions. In order for the input streams to be readable by KDS, KMS uses the grammar and semantics of or translate the input stream into tokens recognizable by UDM and UDL to transform KDS. Functions written in KMS must accommodate the semantics, syntax, and grammar of the model-language being introduced. translation translation By analyzing the semantics, syntax, and grammar of and transformation into and transformation, but is KDM and KDL, the parser UDM is and UDL not only capable also capable of detecting errors in the transaction 16 for Even though the UDM grammar and semantics of and A KMS generic algorithm which outlines the basic functions required of model-languages for all is proposed. Implementation and algorithm will alleviate the burden of determining what the other modules of dictate the KMS in all model- transformation and translation process, certain functions are required by language interfaces. UDL the new language MDBS. model-language interface on which KMS called by LIL required by adherence KMS to this in relation to interface. KMS Figure 5 outlines the generic model-language interfaces on is strict it is processing algorithm required in Notice that this algorithm is all independent of the implemented. to process transactions Begin parse of the input stream. error found in parsing If - memory allocated for the data-definition or request memory is generally the memory allocated by model-language kmsjnfo data-structure. deallocate the input streams. This the - If issue the error message. no errors found -if - a data-definition transaction to load a database schema if KC - send transformed schema to - send LIL the confirmation of schema load. to load onto KDS. a request transaction for querying. UDM request to KC. UDM request in KDM format via LIL - send the translated - display the translated End processing Figure 6: The Generic Algorithm Because language interface, we KMS for All Kernel represent over half the suggest for a Mapping Systems programming requirement new model-language design of the kernel mapping system. We also focus interface, three steps in the on the mapping and formatting process. These steps function as a guideline for the design of KMS prior to grammar and semantics of the new model-language 1. Outline the 2. Determine the mapping algorithm UDL into KDM to programming. interface. mapping grammar and semantics of and KDL. 17 for the UDM and 3. Incorporate the mapping and formatting functions into the generic algorithm. The Kernel Formatting System c. The primary function of the kernel formatting system KDM-formatted transactions received from the kernel controller UDM are only format. Communications with KFS completion of a RETRIEVE transactions issued to results to the user or (KFS) (KC) is to reformat into the proper established after the successful RETRIEVE-COMMON transaction in KC. Other KC only require notification to the user of successful or unsuccessful execution. However, the in KMS RETRIEVE and RETRIEVE-COMMON transaction display data and therefore must be transformed into a format familiar to the user (i.e., UDM). Each model language has a unique representation of an regards to the syntax and structure of the data model. Therefore, result data stream (or response) in the from KC in attribute-based KFS ABDL request in simply parses the form and displays it to the user UDM form. Of the four modules, KFS provides only one simple task to the MDBS transaction execution process and thus comprises the least coding required to implement. Though simple the in coding, specific steps must be found in every KFS. This does not prevent new model-language been output by designer from creating a complex display screen for data having MDBS. With this in mind, we propose a generic kernel controller algorithm for the implementation in all KFS modules. Figure 7 illustrates the generic Receive an output stream from KC. Correlate ABDL Display results Return to request data with UDM attributes. to the user. LIL Figure 7: The Generic Algorithm for All Kernel Formatting Systems 18 KC algorithm. . d. The Kernel Controller The at the intersection of the language interface and the back-ends of kernel controller (KC). Without a thorough understanding of KC 's MDBS meet internal logic coupled with the utilization of a generic algorithm outlining the functional requirements of KC, the implementation of a Once translated new model-language interface would be a user's data definition or request transaction has been transformed or by the kernel mapping system (KMS), the control controller for the loading of this (or these) transaction(s) onto to issue it the transactions that 1 of semantic correctness, 2. of syntactic correctness, 3. in proper meet the following new_model_language_info data KC structure. kernel controller. First, the introduction of a flag to is MDBS. KC relies upon KMS criteria: CreateDB. This sends a signal are based Two upon the operation flag within situations present themselves to the new database into MDBS UDM data definition into KDM form and new database, template file is KMS LIL has created template and KC must now load the template file onto MDBS required by KDS in sets the operation to the kernel controller indicating that a data definition has not been loaded for this particular database. Since the passed to the kernel KDM format. The operations performed by the virtually impossible. order to conduct the has transformed descriptor files for backends. The database initial database load. In the attribute-based data model-language, the template file represents the data definition used by the supported data-model language to establish a As previously mentioned, model-language reside Interface provides the the controller. Other to the controller new database on the system. functions which comprise the attribute- based data in the Test Interface section of the controller software. communication link from the language modules with the controller and vice versa. 19 aid in the The Test interface to the backends via communication of the backends KC must dbl_template() function in the program dbl.c in the Test call the Interface. This function copies the template file into the UserFiles directory the process of loading the template file onto the during the load of the template dynamic memory file will MDBS back-ends. and then Any errors be displayed to the user and all starts encountered corresponding will be de-allocated. The second situation involves translated transactions from KMS awaiting processing by KC. Each request transaction has an associated operation flag assigned upon KMS completion of parsing function. this flag It is which determines what processing functions must be performed by the kernel controller. Operation flags are model-language specific, but must incorporate the five basic operations of the attribute-based data language RETRIEVE-COMMON, DELETE, INSERT, (ABDL): RETRIEVE, Depending on the operation specified within KC will than one be called. ABDL If in the operation flag, the appropriate the request transaction required an statement, a requestJiandler function UPDATE. and request_handler ABDL translation must be invoked to of more ensure UDM requests from which they were parsed. This will prevent an incomplete execution or the original UDM request. continuity between the multiple Aside from the this scenario, new jnodelJangauge_execute The ABDL requests and the the single request handler will pass to the makes the control function. new modelJangauge_execute function within KC necessary function calls with the Test Interface section for subsequent execution on the MDBS processors. The translated UDM format for execution by changing exception of the loaded to the first MDBS all request modified into the proper ABDL characters in the request to lower case with the character of the request. for execution is first Upon completion, the modified request by calling the TI_$$TrafUnit() function is in the Test Interface. After loading the request, KC checks for responses from contain the results from previously loaded queries. This is KDS which may accomplished by invoking the nml_chk_response_left () function within KC. Maintaining a count of the number of ABDL 20 — requests needed for a single messages KDS (or responses) UDM from KDS nml chk response JeftQ function receives request, the and ensures all ABDL results have been received from prior to sending the results to the kernel formatting system (KFS). completion of all of each query as through the forwarded to the requests or transactions, a file it finishes its maintained that appends the results execution. Errors in processing will be addressed to the user TI_ErrRes_Output() function. KFS is Pending the Successfully for display to the user. Figure 8 processed requests will be shows a schematic diagram of the kernel controller processing steps. nmlkernelcontrol ler ( ^^-^" CreateDB load template \ check operation ^ flag J~ ^ Request Transaction request handler files modify Return to LIL ABDL request load request errors TI_$$TrafUnit() TI_ErrRes_OutputO correct request pending _, ' nml chk_response_left done Store_in_buffer_file Figure 8: Forward To KFS The Schematic Diagram of Processing Steps of the Kernel Controller Data model-language specifics do not have a major impact upon the design of the KDM KC because model-language transactions reach KC have already been translated into form. Therefore, translated all KCs must have a similar algorithm which processes the UDM transaction and extracts the results from KDS. We propose a generic KC 21 algorithm required model-language interfaces. This algorithm provides the basic in all foundation by which KCs all should be developed. Figure 9 illustrates this algorithm. KMS via LIL. - Receive the parsed transaction from - Determine the subsequent action based on the operation flag. if operation Jag = CreateDB - dbljemplatei) /* in Test Interface to load template file. - if operation Jlag - return to LIL. = a request transaction - requestJiandlerO /* based on the operation Jlag set in - nml_execute() ABDL request to proper format. ABDL request to MDBS. - fix_ABDL_req() /* - TI_$$TrafUnit() /* loads the - nml_chk_response_left() /* have - TI_R$Message() message from TI_R$Type() /* is the message correct? switch (TI_R$Type) - - KMS. modify the all /* receive requests processed? MDBS. case correct response: - TI_R$ReqRes() /* receive the results. check_last_response() f* are there results pending? case RETRIEVE or RETRIEVE - COMMON: - if results pending, store results in the buffer loop - case till all and request results are completed. KFSO I* forward results to KFS. INSERT or UPDATE or DELETE: - print the query-completion notification. - return to LIL case Errors Figure 2. 9: - TI_R$ErrorMessage() - TI_ErrRes_Output() - return to LIL. I* finds the error type. I* display the error to user. The Generic Algorithm for All Kernel Controllers Communications Among Modules Figure 2 illustrated the basic relationship between the software modules comprising the language interface. For the design and implementation of language interfaces, this figure must be expanded 22 to new model- provide a more in-depth view of the communication paths Interface must be included Language Interface for The path new database between modules. Additionally, the role of the Test that exist all to show the relationship the Test Interface has with the data model-languages. selection is based upon whether a user is to be loaded, the following intercommunication takes place between the modules and the Test definition via LIL; Interface. First, the user issues a LIL then queries request for the data-definition file. completed, the control loading of the KDM is data-definition to LIL LIL data-definition to MDBS KDS name and KDM (step 2.) format (see step 1. which then makes a LIL file, in name calls to KMS KC (step 3.)for call to calls the Test Interface to & 5.). After KDS data- Figure 10). Once KC (steps 4. new uses the KDS. perform the has successfully loaded the and notified the Test Interface (steps (step 8.). This to load a After receiving the data-definition returned to actual loading of the data to command the user for the database to parse the data-definition file into the illustrates the loading a data-definition for a or loading request transactions for processing against an existing database. If a data-definition control to is 6. & 7.), KC completes the loading of the data-definition returns the file. Figure 10 aforementioned communication sequence with sequence numbers. ^ KMS /* a. KC LIL 8. Figure 10: The Module Communication Path for a Data-Definition Load. Notice that KFS is not involved when loading a data-definition file. KFS is not required in the communication process, since there are no (request) transactions to be 23 displayed to the user. communication The omission of KFS is distinguishing the path. Our second communication path involves KDS. the execution in the issuing of (request) transactions for After the user has responded to the prompt by loading (request/ query) transactions via LIL, those transactions are sent to the KDM form which in turn (step 1. in Figure 11). KMS sends the transactions to the Test Interface (step Test Interface (step 5.) in processed. Figure transactions in 1 1 LIL for parsing into the on 3.) for (step 8.) illustrates the user in the where the process KC (step 2.) execution on KDS MDBS, results are forwarded order to further communicate the results to KC forwards the results to KFS for display to the are then finally returned to KMS passes the parsed transaction(s) to (step 4.). After processing against the appropriate database to the of this feature KC (step 6.). UDM form (step 7.). Controls is repeated if more requests are communication path for the execution of (request) MDBS. 1. ^f KMS \ 2. y' KC LIL 8. Figure 11: KFS 7. The Module Communication Path In both cases, errors resulted in to any module for Executing Transactions. will cause the control to be returned LIL. Error messages will be displayed to the user by the module where the error was detected. 24 3. Data-structure Requirements The data-structure design for the representation of a data model-language MDBS. To must incorporate features of both the model-language and propose a generic data-structure which new accomplish and allows expansion for features of the new model-language interface. with data-structure representation Any types in the data- structure in the fits into development on design for MDBS. MDBS, In order to one must become familiar programming language C. MDBS programming language C. Two derived in the data- structure we requirements of the language interface satisfies the understand where the generic data-structure this, requires an understanding of derived types, structure and union, are essential Structures aggregate data of different types (derived types included) into a single data type. Unions allow alternative values to be stored in a single shared portion of the memory. types are useful in representing the Integrated into new complex data model-language. these derived types, with examples, can be found in The structure structure userjnfo, data- structures, these derived shown in A detailed explanation of [KELL] Figure 12, the building block of the data- is network which comprises each model-language interface. This structure contains a variable of the type union, lijnfo, which stores the data structure of the model-language interface selected for execution. into MDBS The implementation of new model-language requires the modification of lijnfo to include a model-language interface as shown data- structure for in Figure 13. This new model-language new new structure structure for the is userjnfo { char union ui_uid[UIDI_ength +1]; lijnfo ui_li_type; struct user *ui Figure 12: The User_info info next user; } 25 Structure new our proposed generic interfaces. struct interfaces union IMnfc { struct sqijnfo I struct dlijnfo I struct _dml; dmljnfo dapjnfo _dap; new_model_language_info _sql; _dli; I struct I struct Figure 13: The li_nml; li_info Structure with the new_model_language_info Included The generic data-structure for new model-language interfaces is a C structure called newjnodel_langauge_info. This structure contains all the pertinent information required by MDBS, including: KMS, KC, KFS, 1. Unions for the new model-language 2. Operation flags to indicate user requests, operations, and errors. 3. Structures for storing filenames, transactions, and data-definitions. Specifics of the new new modelJangauge Jnfo model-language structure. The unions should for C illustrates the generic data structure relationship to other data structures within be also KMS, KC, and included KFS in the as well as the model-language are stored therein. structure types specific to the features of the selected Appendix and LIL. newjnodelJangaugeJnfo and its MDBS. All language-interface data-structures reside in the header file licommdata.h in the Test Interface portion of this file and use the interface. Using a especially useful C MDBS. New model-languages must store construct include in common file all programs of the new model-language for the declaration of when designing their data- structures in model-language data-structures is a cross-model access capability into a model-language interface since each model-language has the access to the data- structures of the other model-languages. 26 The Makefile Development 4. As with to all programs written compile several related programs programming language C, a makefile in the in one step. The words, LIL, KMS, KFS, and its KC own of the for the KMS, KC, resulting in order to compile all the modules indicate the appropriate directory to store must also be recompiled due to at one include a makefile for each module object code all from the compilation process. After compiling the new model-language the Test Interface new and KFS, a single makefile should be new model-language should new model-language and language interface of a should each have a separate makefile. developed for the new model-language interface The makefile in the makefile for separate modular compilation. In other After the development of LIL, time. used programs which comprise a new model-language interface are no exception. Each module model-language should contain is changes made to the program interface, ti.c. These changes are a result of adding a new selection option for the new model-language interface to the MDBS main menu. Appendix D illustrates a generic makefile for a new model- language interface. D. THE VERSION CONTROL AND CONFIGURATION MANAGEMENT With the proliferation of new model-languages, present an area of concern to introduced to the and managed. A MDBS the need of the version control will system managers. As new model-languages are MM&MLDS, new versions of the MM&MLDS software must be created strategy must be developed to ensure the proper documentation and maintenance of its software when new versions of the Coupled with the version control is MM&MLDS software is developed. the configuration management which must also be addressed. The implementation of a new model-language version of the MM&MLDS software. The interface results in the creation of a latest version of the MM&MLDS should be the only version residing on the system after testing and evaluation 27 is new software completed. Utilizing the tape drive on the front-end controller, back-up copies of the old version and new version should be The version software. made control is in case of a catastrophic system failure. not limited to changes or additions to the MM&MLDS System upgrades may require the modification of the existing backend software. Therefore, the following steps must be followed when a modification occurs to MDBS software. 1. Back-up old and new versions to a tape. Ensure only new version is resident on the system. 2. Properly label tapes and maintain a logbook indicating what modifications were made and why. 3. Ensure all Through specific data the MDBS systems receive the updated version of the the version control and configuration new software. management, systems requiring only model-language interfaces can modify the new version of the MM&MLDS software so that only those interfaces needed will be available for the selection. This can be accomplished by deleting the statements and respective case statements for the unwanted model-language interface in program ti.c of Test Interface. The system manager can then recompile Test Interface and delete any references to the unwanted model-languages from the makefile. This simple process allows system languages required managers to offer only those model- at his specific site. Any mismanagement of the MM&MLDS software can be costly. Slight modifications (especially to Test Interface) can result in minor errors to a system failure. aforementioned version control and configuration management strategy, these problems. 28 we Following the will minimize IV. GENERAL STEPS TO A NEW MODEL-LANGUAGE INTERFACE A. THE MDBS USER INTERFACE On 1. the Interface Familiarization The menus current version of the for user interactions with MM&MLDS MDBS. software utilizes Prior to the design and model-language interface, a period of familiarization MDBS idiosyncrasies of the among shells a new understand the development of needed to their in interfaces will exist on own unique MDBS. An absence fashion. This will force users to have understand and learn the processing steps of several different user interfaces, the semantics, syntax, and grammar of the new data model-languages. problem, standardization of the user interface is standard and maintaining a level of consistency Our new model-language development. Menus appearing we among interface with to the user in user in the other model-language interfaces. encounter of is the in addition to because of this is adhering to that the different model-language a guide for the interface; however, this is user interface one data model-languages must appear Of course, some variation the specifics of the model-language. For example, references to sets focus to familiarization with previous model-language interfaces will provide the designers of the network/DML It is of a must. After establishing a standard, the problem interfaces. and scrolling user interface. Without such experience, future model- language interfaces will be constructed standardization is C to the must be allowed is for appropriate for an not the case for an object-oriented interface. Our placed on the general framework of the model-language interface with the specifics model-language incorporated into this framework. Maintaining a level of consistency amongst the different model-language interfaces will reduce both errors and the confusion on the part of the user interfaces. Unique model-language when alternating between different model-language interfaces will detract from the concepts of multimodel and multilingual interfaces instead of enhancing the users understanding of the overall 29 concept of MDBS. In Appendix D, we illustrate a basic framework for model-language interface design. When we discuss standardization of model-language interfaces, user interface associated with the attribute- based data model-language. The we exclude the attribute-based data model-language interface software resides outside the model/language interface portion of MM&MLDS. Since all model-language interfaces are either transformed or translated into the attribute- based data model-language, those functions specific to this kernel data model-language should be separate from those model-language interfaces. The attribute-based data model-language interface contains the functions that allow direct communication with the backends communicate with the backends via 14, we show unlike other model-language interfaces that the attribute- based model-language interface. In Figure the interface relationship between the model-language interfaces and the attribute-based model-language interface in regards to backend communication. Test Interface Figure 14: The Relationship Between Model/Language Interfaces (ML/Is) and the Test Interface 2. The User's Manual MDBS addressed the concept of federated databases and solutions problems presented by heterogeneous databases. Therefore, 30 in a to the classroom or research environment, MDBS offers an excellent opportunity to (1) familiarize students with the various data model-languages supported on which to further study the federated MDBS and (2) allow researchers a vehicle by and heterogenous database concepts. Unfortunately, in MDBS. the past, potential users required the expert assistance in order to properly operate This placed a tremendous burden upon the user. The user had no written documentation of how to operate the system and therefore was forced This greatly diminished the learning objectives of on figuring out how the system operated through to learn the MDBS, trial and system by since the user error. trial and error. was more focused This lead to frustration and confusion on the part of the user. In order to alleviate these problems, we propose manual which outlines every possible aspect of were intentions to set or user's the user interaction with MDBS. Our design a manual that would be beneficial to both first-time users as well as experienced users. Since the user's an instructional manual is MDBS is such a valuable resource for instructional purposes, also designed as a teaching aide for advanced database topics. Therefore, a practical vice theoretical lab would be possible, giving the students a more dynamic indoctrination into advanced database topics students in the advanced database course further their CS4312 to the MDBS is this time, User's Manual to new model- language interface on new model-languages. Topics covered are: 1. Multimodel and multilingual 2. System overview. 3. Starting the system 4. Data-definition and request file development. 5. Kernel data model-language interface capabilities. 31 in the is the first MDBS. an excellent tool for familiarizing oneself with the idiosyncrasies of required in the design of Manual MDBS User's Manual, found in Appendix A, step in the design and implementation of a is are using the At knowledge of database concepts. The introduction manual in addition to lectures. MDBS MDBS This that User's DML, 6. Execution of SQL, 7. Execution of the cross-modeling access capabilities. 8. UNIX 9. Sample databases aliases and C and DL/I interfaces. shells. for the user familiarization. As new model-languages and new functions introduced to effect makes MDBS, the to existing additions and deletions to the user's manual model-languages are must be made. This in MDBS User's Manual a living document that can be updated as the system grows. Furthermore, as students use the manual as a part of their classroom instruction, clarifications and modifications can be made Through proper maintenance, instructing B. MDBS the to further enhance the learning process. MDBS User's Manual is the most effective paradigm for users. OUR SOFTWARE METHODOLOGY The design and implementation of software design decisions that must be introduction into MDBS. a new model-language made to ensure effective model-language interface These decisions are a result of strategy needed for incorporating the idiosyncrasies of syntax, interface involves several developing the best possible MM&MLDS with the grammar, and semantics of the new model-language interface. Of the four modules comprising the Model/Language Interface, the development of amount of planning and preparation since it is in this KMS modules where involves the greatest the grammar, syntax, and semantics of the new model-language interface must be addressed. The other three modules in mind, rely we upon the design of KMS as a building block for their own introduce our software methodology for the design of a interface. In order to understand our methodology, three areas models with no formal data language, With this new model-language critical to the model-language interface software must be addressed. These are interface for data design. (1) (2) designing a design of the designing a new new interface for data models with a formal data language, (3) mapping strategies using the kernel model- language. 32 Models With 1. The A Formal introduction Data Language model-languages of standardized data MM&MLDS into requires the development of an implementation strategy that encompasses constraints of the model-language. Since there is all specified the documentation which specifies the programmers are not required to constraints of the model-language, the designers and develop the constraints for new model-language. Instead, they have the opportunity themselves a useful programming tools to parse the data model and ensure complete coverage of all These programming new data language to possible constraint violations. tools, Lex and Yacc, allow parsing of an input stream in the data model-language for future conversion into the kernel data model-language. Lex and Yacc are useful, since language is its to avail their modules can be incorporated C and thus be included in the directly into the programming KMS portion of the Model/Language Interface. Lex a lexical analyzer which parses the input stream into recognizable tokens, these tokens are then input into a compiler create by Yacc. Yacc, which stands for Yet Another Compiler-Compiler, creates a compiler which accepts the tokens from Lex and processes them in a finite-state standardized, all automaton. Since the data model-language constructs are possible accepting states of a valid string are identified and thus can be incorporated into the finite-state automaton generated by Yacc. Further explanation of the implementation and design of Lex and Yacc can be found By utilizing model-language that Lex and Yacc, we may have is to be introduced into a would allow and (2) its (1) the addition [LESK and [YACC ] more complete MM&MLDS. becomes standardized since being implemented on should be converted from in If a C description of the data model-language interface MM&MLDS, existing parser written in ]. the parser within KMS with a Lex and Yacc parser. This and modification of constraints not found in the original parser produce a parser that covers the constraints of the standardized model-language. In Figure 15 we illustrate the role of Lex and Yacc in the parsing process of 33 KMS. Lexical specifications in regular expressions. i input stream Lexical Analyzer _^Y ~ LEX gSKon. parse d tokens | inite-State based acceptable states with valid tokenized stream of data. BNF in AutomatonA YACC grammar and/or syntax errors Figure 15: 2. The Lex and Yacc Parsing Processes. Models With No Formal Data Language With the model-languages proliferation of may become an new data model-languages, the standardization of these when no formally accepted involved process especially standard for the model-language has become available. Such the case of the Object- is Oriented Data Model and Data Language. The object-oriented data model-language concept has been addressed throughout the database community; however, no acceptable standard has been declared. is By standard, we mean a data model and universally accepted and implemented; e.g. relational and its data language that SQL are a standard data model and a data language. At the Laboratory for Database System Research, model-languages into our system whether a data model and its we intend to introduce data language have new become standardized or not. Without a standardized data model-language to incorporate into the MDBS system, the designers and programmers must develop their proposed data model-language. It is this representation that 34 own representation of a must be developed prior to any programming efforts to ensure compatibility standardized data model and its between the model and its language. data language generally evolve from extensive research and testing to ensure all possible integrity constraints are addressed. In the case of data and models languages that are not standardized, extensive testing has not yet been their data conducted and thus the testing requirement the A new model-language standardized data model-languages efficient parser to parse the data language as addressed upon the designers intending MDBS. The documentation on interface falls is to implement of integrity violations in a tremendous aid in developing an accurate and model and in the next section. language into the kernel data model- its This aid is not available to the designers of a model-language with no formal data model-language. Because of this, the development of a parser for a model-language interface with no formal data model-language must be written in a lower-level form without the benefit of higher-level, program-development tools. Another method of parser development programming language model-language. C Since programmers much More third specifically, the BNF we can use method KMS is [LESK be developing much easier than using higher-level 78] and [JOHN for the and the model-language programming tools 78]. This affords the designers and new model-language data is to write formal specifications for the write the regular expressions for specifications for LEX and request of the new will spent parser that uses the parsing process. method we KMS time the opportunity to incorporate the design of the structures into the The design a to effectively parse the data-definitions representation, this approach such as Lex and Yacc is to its syntatic structures YACC to development of code. 35 legitemate tokens. We also write and grammar. With these specifications, generate the parser for KMS its new model-language. KMS readily. We recommend this 3. Kernel Model-Language Mapping Strategies In the case of a data development of a language model-language that has yet to incorporate suggest the third method mentioned in the previous section. the effort expressions and for the MM&MLDS, will be able to properly address considerations that will save the design is of course new model-language. software methodology for the programming of the new model-language programming The overhead developing the formal specifications, both regular BNF specifications, By following our programmers to be standardized, the with the data model can be an involved process. We and time devoted to interface. designers and must be made prior to the Focusing on these issues prior to and program teams valuable man-hours developing a software methodology which in incompatible with 36 MM&MLDS. V. A. THE CONCLUSION RESULTS OF OUR RESEARCH EFFORT In this thesis, we have developed MDBS. By language interfaces on introduction into MDBS, a paradigm for the introduction of detailing a three-step process to a a noticeable reduction in new model- new model-language development time spent on new model- language interface incorporation will be realized. This paradigm will result effective use of MDBS for both first-time user's and therefore important for us to As summarize the MDBS of introducing a User's Manual is new model-language in the educational advanced database developers. It is multimodel and multilingual database the first step that designers interface. must take in the process This manual has also proven instrumental environment as a supplement students a vehicle with which to operate more efforts of our research. a pedagogical aid for the instruction on the system, the new model-language in a MDBS to the classroom lectures by providing and thus further their understanding of topics. The understanding of the procedures, methods, and model-languages into MM&MLDS is vital tools required for introducing for designers of a new new model-language. From our generic development algorithms for each software module of the Model/Language Interface, designers will be provided with a model-languages will be implemented. The framework and foundation from which new strict smooth introduction of the new model-language adherence into to these algorithms will ensure MM&MLDS. Our development of the generic data structure also provides the needed foundation from which the specifics of a new model-language may be implemented on MM&MLDS. Our explanation and outline of the relationship between the Test Interface and the Model/Language Interface sections of MM&MLDS allows designers to focus upon the interaction which must take place between the new model-language and the kernel database system. This MM&MLDS process. 37 is the heart of the Our software methodology a new model-language of outlines considerations that interface for MDBS. Addressing key issues that will face designers new model-languages, our methodology provides interface design We must be made when designing options for more effective model- and incorporation. believe our paradigm is MDBS. The model-language interfaces into new instrumental to the successful incorporation of problems associated with heterogeneous databases are facing organizations world-wide and especially in the Department of Defense. The multibackend, multimodel, and multilingual approach to the database system design B. is an effective solution to these problems FUTURE RESEARCH The rapid growth of computer technology MDBS. Conversion of the current Laboratory of Database System Research RISC architecture will soon be realized. Research backend configuration on this new architecture With the successful incorporation of Windows will TAE the in the area of the Plus, a new generates code written in new Sun4 developers of architecture, user interface for this interface new to new tools will Using a programming MDBS, MDBS MDBS tools such as since TAE Xbe tool Plus software readily. The TAE The written in Plus. would be an excellent research opportunity and allow new model-languages language by not having MDBS. and can thus be incorporated into author has developed a prototype user interface for implementation of Sun4 must be addressed. user interface could be designed for C to the software portability and be available for users and programmers. These instrumental in the design of the such as have a tremendous impact upon will develop a to focus new more on interface. 38 the structure of the new model- APPENDIX A. MDBS USER'S MANUAL LABORATORY FOR DATABASE SYSTEM RESEARCH Naval Postgraduate School Monterey, California The Multibackend Database System (MDBS) The Multimodel and Multilingual Database System User's Manual Volume 1 by Paul Alan Bourgeois 17 MDBS Advisor: Approved December 1992 Dr. David K. Hsiao for public release; distribution is unlimited. TABLE OF CONTENTS I. II. IE. INTRODUCTION A. BACKGROUND 42 B. SCOPE 42 SYSTEM OVERVIEW A. GENERAL B. MULTIMODEL/MULTILINGUAL CAPABILITIES MDBS LANGUAGE INTERFACE SOFTWARE MODULES C. SCHEMA AND REQUEST FILES A. OVERVIEW B. C. IV. V. VI. VII. VIE. 42 SCHEMA FILES REQUEST FILES B. 44 44 46 48 48 48 50 GETTING STARTED AND RUNNING MDBS A. MDBS PROCESSES B. META-DISK MAINTENANCE C. SETTING UP THE USER'S SCREEN THE RELATIONAL/SQL INTERFACE A. INTRODUCTION B. LOADING A NEW DATABASE C. PROCESSING AN EXISTING DATABASE D. THE MASS LOAD FUNCTION E. LOADING RECORDS USING SQL INSERT AND PROCESSING OTHER TRANSACTIONS THE NETWORK/CODAS YL INTERFACE A. INTRODUCTION B. LOADING A NEW DATABASE C. PROCESSING AN EXISTING DATABASE D. LOADING AND EXECUTING CODASYL TRANSACTIONS VIA REQUEST FILES THE HIERARCHICAL/DL/1 INTERFACE A. INTRODUCTION B. LOADING A NEW DATABASE C. PROCESSING AN EXISTING DATABASE D. REQUEST FILE ORGANIZATION FOR LOADING DL/1 TRANSACTIONS THE CROSS-MODELING ACCESS CAPABILITY A. 44 OVERVIEW SCHEMA TRANSFORMATION 40 53 53 55 56 59 59 60 62 62 63 67 67 67 70 71 73 73 74 76 77 80 80 80 EXECUTING THE HIERARCHICAL TO RELATIONAL CROSS-MODELING CAPABILITY THE ATTRIBUTE-BASED DATA MODEL-LANGUAGE INTERFACE C. IX. A. B. C. OVERVIEW DATABASE CONSTRUCTS THE ATTRIBUTE-BASE DATA MODEL INTERFACE 2. The Template and Descriptor The Mass Load File 3. Executing the 1. UM APPENDIX A: A. B. 3. 84 84 84 85 85 87 89 95 95 95 96 Shell The stop.cmd C The run C Shell README FILE 97 Shell 98 THE APPENDIX B: DEMO DATABASE EXECUTIONS OVERVIEW A. B. THE RELATIONAL/SQL INTERFACE THE NETWORK/CODASYL INTERFACE C. THE HIERARCHIC AL/DL/1 INTERFACE D. THE CROSS MODEL CAPABILITY E. F. THE ATTRIBUTE-BASED/ABDL INTERFACE C. UM ABDM interface USEFUL UNIX AND MDBS COMMANDS THE .alias FILE C SHELLS 1. The zero C 2. Files 81 41 99 101 101 101 102 103 104 104 I. INTRODUCTION BACKGROUND A. The Multi-backend Database System (MDBS) at NPS. Under the direction of Professor is the research database laboratory David K. Hsiao, this system provides a research testbed for solutions to the problems of heterogeneous databases and design concepts required for the development of a federated database system. data language capability of MDBS The multiple data model and allows the user to implement a wide variety of database models and data languages on a single system. Through its cross-model access capability, MDBS permits a user experienced in relational databases and the relational language SQL to access a hierarchical database by transforming the hierarchical schema into a relational schema and thus allowing transactions written Though a transformation of schema takes in SQL to access the hierarchical database. place, this transformation is transparent to the user. B. SCOPE The scope of MDBS. this user's Sections will include database as well as how to manual how to will be to explain all user interface aspects of the load and run a relational, hierarchical, and network use the cross-model capabilities of the system. Because the system uses the data sharing method of multiple data model/language mapping (or kernel) data model/language, instructions are provided execution of an Attribute Based Database (ABDM) (ABD) models and data languages are provided throughout overview of the system is files this user's Examples of manual Two Model certain data as well as formats necessary to build a database. discussed in Chapter hardware and software of MDBS. Appendix on the development and using the Attribute Based Data and the Attribute Based Data Language (ABDL). used to construct the schema and request to a single A brief to familiarize the user with the A provides a glossary of key terms and UNIX functions necessary for database implementation are also provided. Appendix 42 B is the step- by-step instructions required to load, process, and execute the four user interfaces on the MDBS. 43 II. A. SYSTEM OVERVIEW GENERAL The Multibackend Database System (MDBS) currently consists of six backend computers and one controller computer. Each backend a database processor with is its own micro-processor and database store. The backends are arranged in parallel in order to maximize performance through invariance. response-time reduction, and response-time scalability, Both paging and meta-data are stored are stored Winchester type disk drives while the base data Megabyte moving-head standard-type Local Area Network. The controller is access to the meta-data and base data. and recovery of the backends. drives. from the backends in much at the larger via an Ethernet does not require is to provide backup Naval Postgraduate School, DB8 8) with the front tape drive, is the controller. Figure 2-1 illustrates the relationship the forward controller and the of the MDBS. The number number of connection B. slots 500 it that main function controller's On the MDBS maintained on The backends communicate different The is on separate 96 Megabyte (ISIV between backend processors as well as the structure and organization of backends the system can support is limited only by the provided for the backend processors by the controller. MULTIMODEL/MULTILINGUAL CAPABILITIES In order to support MDBS unlike traditional data language. claim of being multi- model/multi-lingual, models and data languages as well as traditional data language. its its own MDBS supports four kernel data model and data supports these data models and data languages on the same system homogeneous database machines which support only one data model/ The four data models/data languages supported by network/CODASYL, MDBS: relational/SQL, hierarchical/DL/1, and functional/DAPLEX (Author's note: at the time of this user's manual, the functional data model was in the process of being completed on MDBS), are is this all mapped to a kernel data model/data language on the mapping process of the user's data model and data language model and data language that represent the heart of the 44 MDBS. MDBS system. It into the kernel data The kernel data model used its for MDBS is the attribute-based data corresponding attribute-based data language (ABDL). primary database operations: and DELETE. Through RETRIEVE, RETRIEVE clustering, the ABDM The model ABDM COMMON, (ABDM) with supports the five INSERT, UPDATE, allows the base data to be partitioned into mutually exclusive sets and these sets of clusters to be distributed to the backends permitting parallel access to the base data. Meta data disk Base data disks "•-•' YiYi'i Tape Drive mm i i i i Paging disk Meta data disk Base data disks Meta data disk Base data disks Paging disk Figure 2-1 Structure and Organization of 45 MDBS C. MDBS LANGUAGE INTERFACE SOFTWARE MODULES Each data model/data language supported by MDBS has four language interface software modules that perform the translation of the data model and data language into the kernel data model and data language. These four modules (LIL), Kernel Language Interface Layer Mapping System (KMS), Kernel Formatting System (KFS), and Kernel Controller (KC). A detailed description of each strategies for loading new databases to the MDBS interface management system how each data model/data language models linked are the to the for is module as well MDBS as interface management system, and a prototype for a can be found in [BOUR 93]. Figure 2-2 shows composed of the four software modules, with Kernel Database System (KDS) and eventually to the Figure 2-2 Multiple database interfaces linked to single kernel database 46 MDBS all data Kernel Data Model (KDM) and Kernel Data Language (KDL). system on new A demonstration/class account cs4322 is set password can be obtained from Professor Hsiao. that comprises the MDBS system as well as up An MDBS befoundin|HSIA91|. 47 to execute the MDBS from DB3. The in-depth description of the hardware performance studies and statistics can SCHEMA AND REQUEST FILES III. OVERVIEW A. Each of file the databases developed and the option to use a request schema by file subdirectory of UserFiles but when the user or request file, the user must system requires the use of a schema schema and request All file. the UserFiles directory in order to be used that directory to verify if the MDBS on the MDBS since MDBS is the name of the is MUST be resident in hard - coded to check actually exists. Files can be resident in a is prompted by the system include the path name CREATE/QUERY to input the schema starting with the subdirectory followed by a forward slash, and then the schema or request What files file — > name file name (Figure 3-1). /DEMO/COURSEsqldb Figure 3-1 Request B. for SQL schema file SCHEMA FILES The schema query language, file i.e. that the descriptor outlines the SQL, schema of the user's desired database CODAS YL, and template DL1, or ABDL. (the ".d and It is .t" files) in its respective from the loading of are generated this file by the Language Interface Layer. For clarity, all <database files should be named in the namexthe acronym of the interface For example, should be schema if a relational database COURSEsqldb. There is no name is language COURSE, file (ie. sql, then restriction to this rule, but have been developed, finding the corresponding schema be lead to using the wrong schema following convention: and having a dollar sign "$" on the last line of the file to mark 48 file schema filename once several databases when executing to start over. All the its dml, dli)>db schema a database can files must have end of file. Otherwise, the parser will not find and in EOF mark and not process the schema Figure 3-2 through 3-4 and can also be found Sample schema file. in the cs4322 account DEMO directory. create table employee: Iname (char(8)), fname (char(8)), ssn (char(9)), sex (char(1)) @ create table job: essn (char(9)), position (char(10)) @ create table pay: essn (char(9)), salary (int(6)) $ Figure 3-2 SQL schema file EMPRECsqldb name= sqd segm name= co field name= (sno, seq), bytes= 2 field name= sname, bytes= 2 segm name= maint parent= co field name= (mdn, seq), type= int, bytes= 2 field name= mname, type= char, bytes= 2 segm name= ops, parent= co field name= (odn, seq, m), type= int, bytes= field name= oname, type= char, bytes= 2 segm name= acft, parent= ops field name= (ano, seq), type= int, bytes=2 field name= aname, type= char, bytes= 2 dbd , $ Figure 3-3 DL1 schema file 49 SQDdlidb 2 files are in the shown UserFiles/ ; SCHEMA NAME RECORD NAME IS NET1 IS Supp; DUPLICATES ARE NOT ALLOWED FOR SNO; SNO CHARACTER 10. SNAME CHARACTER 10. CITY; CHARACTER 10. RECORD NAME IS Parts; DUPLICATES ARE NOT ALLOWED FOR PNO; PNO CHARACTER 10. PNAME CHARACTER 10. CITY; CHARACTER 10. RECORD NAME IS Purch; SNO; CHARACTER 10. PNO CHARACTER 10. ; ; ; ; ; QTY; FIXED 4. SET NAME IS SuppPurc; OWNER IS Supp; MEMBER IS Purch; IS AUTOMATIC RETENTION IS FIXED; SET SELECTION IS BY VALUE OF SNO SET NAME IS PartPurc; INSERTION IN Supp; OWNER IS Parts; MEMBER IS Purch; INSERTION IS AUTOMATIC RETENTION IS FIXED; SET SELECTION IS BY VALUE OF PNO IN Parts; $ Figure 3-4 CODASYL schema file SQDdlidb C. REQUEST FILES The request file contains transactions the users wishes to process against a certain database. These transactions are written in the appropriate data data model of the database. The format for each request file is similar in that files contain multiple transactions must have an must have an end of file model language given "@" which sign in between each transaction. All files marker (denoted by the dollar sign) on the 50 the last line of the file. Sample request files are cs4322 account in the shown in Figures 3-5 UserFiles/DEMO through 3-7 and can also be found directory. select * from employee @ select * from job @ select * from pay @ select * from employee where sex = 'M' @ ssnjname from employee where sex = 'F' select $ Figure 3-5 Figure Portion of SQL request file EMPRECreq MOVE Sup1 TO SNO IN Supp MOVE DEC TO SNAME IN Supp MOVE MONT TO CITY IN Supp STORE Supp @ MOVE Parti TO PNO IN Parts MOVE NUT TO PNAME IN Parts MOVE MONT TO CITY IN Parts STORE Parts @ MOVE FIND Sup1 TO SNO IN Supp ANY Supp USING SNO IN Supp GET Supp $ Portion of Figure 3-6 request CODASYL/DML 51 file NETIreq in the build (sno, sname) : ('AiyV2') co isrt @ build (mdn, isrt mname) co (sno = maint : (10, 'pr') 'A1') @ build (odn, isrt oname) co (sno = : (55, 'tp') 'A2') ops @ gu co @ gu co (sno='A2') ops @ gnpops $ Figure 3-7 Portion of DL1 request SQDreq 52 file GETTING STARTED AND RUNNING MDBS IV. Once now all schema begin running the mdbs MDBS A system. files have been constructed, the user can directories can use either the used primarily for thesis research and therefore has numerous is from which the number of backends application. Due to MDBS system that the user may run from and options exists to predetermine wishes to use while running a particular database constant manipulation and changes that occur from thesis research, our focus will be placed on using the cs4322 account on the key MDBS user logging into the or the cs4322 account. Both accounts will log into their respective default directory. The mdbs account the and optional request files UNIX commands Logging into and C shells used to setup the db3 with the cs4322 account of db3/usr/work/cs4322. db3 file for Appendix A covers MDBS. will take the user into the default directory The subdirectory UserFiles should contain the schema and request terminal. (or a subdirectory of UserFiles) the database to be processed. If this has not been done, the user must transfer his schema and request files the UserFiles into subdirectory (or a subdirectory of UserFiles). Once all schema and request files are change directories from the default path the following files exist: stop.cmd*, zero* Within the to the subdirectory test. test directory, README, run*, stop.cmd*, zero*. The README file outlines name the limits for file located in the proper directory, the user will length, characters per attribute commands do. A copy of the name as well as what the run*, README file is provided in Appendix A along with a listing of the run* stop.cmd* and zero* commands. A. MDBS PROCESSES Prior to executing the run still running the MDBS command system. The processes on your terminal whether you run of the the user must verify UNIX command own that there are no processes ps ax will display all active those processes or not. Because an aborted MDBS system can leave MDBS processes still running, the ps ax command will 53 : help locate these processes and by using the lingering processes. Look any process for PID TT STAT TIME 26590 26757 26758 26822 26827 26828 26829 26830 26831 26832 26833 26834 26835 26836 26837 26839 26844 26845 UNIX command like those highlighted in typing 1 COMMAND I I I I I I I I I I I p1 p1 kill kill those I S 0:00 S 0:00 rlogind -csh (/bin/csh) command and the process number, you can terminate the extraneous processes. kill the extraneous processes the shell file running and Figure 4- kill ? IW 0:00 desktop -d console (/etc/getty) pO 0:02 rlogind pO IW 0:02 -csh (/bin/csh) pO IW 0:00 /bin/csh run pO 0:00 /usr/work/cs4322/VerE.6/CNTRL/scntgpcl.out pO 0:00 /usr/work/cs4322/VerE.6/BE/sbegpcl.out pO 0:00 /usr/work/cs4322/VerE.6/CNTRL/scntppcl.out pO 0:00 /usr/work/cs4322/VerE.6/CNTRL/pp.out pO 0:00 /usr/work/cs4322/VerE.6/CNTRL/iig.out pO 0:00 /usr/work/cs4322/VerE.6/CNTRL/reqprep.out pO 0:00 /usr/work/cs4322/VerE.6/BE/dirman.out pO 0:00 /usr/work/cs4322/VerE.6/BE/cc.out pO 0:00 /usr/work/cs4322/VerE.6/BE/recproc.out pO IW 0:00 /usr/work/cs4322/VerE.6/BE/dio.out pO 0:00/usr/work/cs4322/VerE.6/BE/sbeppcl.out pO 0:01 /usr/work/cs4322/VerE.6/CNTRL/dblti.out second method of command; you can - Figure 4-1 Result of executing the ps ax By kill, them as is listed in shown is to Appendix A, use the stop.cmd A command. This will find all the extraneous processes in Figure 4-2. If the stop.cmd command is issued and no MDBS processes are running on the system, the user will be notified that there are no MDBS processes to kill as shown in Figure 4-3. 54 db3/usr/work/cs4322/test--38>stop.cmd Stopping MBDS processes killing 26827 26828 26829 26830 26831 26832 26833 26834 26835 26836 26839 Figure 4-2 Result of the stop.cmd command db3/usr/work/cs4322/test--4> stop.cmd Stopping MBDS processes killing kill: Too few arguments. Figure 4-3 Executing the stop.cmd command with no MDBS processes running B. META-DISK MAINTENANCE Upon there is verification that no extraneous processes are running, the user must ensure no existing database currently loaded the alias pry, this pry command command will display 4-4, then the data disk is 0000000 will to the system. check the disk what data is to on the disk, make if This is that accomplished by using sure there is no data on it. The the line displays zeroes, as in Figure clean and you are ready to execute the MDBS system. \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * Figure 4-4 Clean meta-disk However, there may be an existing database stored on the pry command will look similar to Figure 4-5. 55 disk, and the result of the 000000 0000016 003 \0 \0 E M R P C E \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * Figure 4-5 Meta-disk with existing data The zero command loading a new will let the user clean the meta-disk of any existing database to the system must ensure that the meta-disk is Users data. clean or the execution of the database will crash. Figure 4-6 displays what the user will see after executing the zero command. Provided the user has either clean the meta-disk or plans to process an existing now ready to execute the database, the user is user will type the command takes place after the run run to start the command described in this manual is is strictly MDBS MDBS system. From the test directory, the interface. Figure 4-7 illustrates entered. (Author's note: The execution of the what MDBS for use with the class account cs4322. Execution of the MDBS using the thesis research account mdbs is accomplished in various ways with options to select the number of backends the user wishes to use. Since current thesis research is being conducted in the area of user selection of backends, a future appendixes appear in the next edition of the MDBS C. MDBS User's Manual, will outline the steps necessary to execute the using the thesis research account mdbs.). SETTING UP THE USER'S SCREEN It is advisable that the user use two C shells while operating the MDBS system. shell will be used strictly for database execution while the other shell will be checking the UserFiles directory for ensuring that that the user can verify that all class account, the user will necessary database all processes are running. have six When running the backend (BE) processes running and (CNTRL) processes running. These processes are highlighted in Figure 4-1. not have kill all these processes running, then the user must exit the and so from the six control If the user does system using Control-c, any extraneous processes with the stop.cmd command, double check 56 used for files exist MDBS One to ensure no extraneous processes are running using the ps ax zeroed, and then restart the MDBS command, ensure system using the run the data disk has been command db3/usr/work/cs4322/test- 39>zero No match. No match. File to zero = /dev/sd1c File size = 105638400 Bytes to zero = 8000000 Bytes written... 819200 1638400 2457600 3276800 4096000 4915200 5734400 6553600 7372800 8000000 Figure 4-6 Result of the zero command As seen in Figure 4-7, The Multi-Lingual/Multi-Backend Database System Menu own unique offers an assortment of database models to choose. Since each interface has idiosyncrasies, the next section four sections will Hierarchical, and ABDM the Relational, database models and respective user interfaces. the database the user desires to implement, the execute the examine commands and Network, Regardless of steps used to prepare and MDBS pertain to all data models implemented on the MDBS 57 its system. db3/usr/work/cs4322/test--42> run 2] 29569 29570 3] 29571 1] 4] 29572 5] 29573 6] 29574 7] 29575 8] 29576 9] 29577 10] 29578 11] 29579 The Multi-Lingual/Multi-Backend Database System Select an operation: (a) - (r) - (h) - (n) - (f) - (x) - Execute Execute Execute Execute Execute the attribute-based/ABDL interface the relational/SQL interface the hierarchical/DL/l interface the network/CODASYL interface the functional/DAPLEX interface Exit to the operating system Select-> Figure 4-7 Result of executing the run 58 command V. A. THE RELATIONAL/SQL INTERFACE INTRODUCTION The Hence, relational interface all on the MDBS interface will resemble Figure 3-2 using the basic The user must ensure At as the data model language. request files developed in conjunction with the relational interface will use The schema statements to manipulate the relational database. MDBS SQL system uses the request and schema SQL for the relational/SQL file SQL constructs to create the schema file. created prior to execution of the files are system. this point, the user command and has entered the run Lingual/Multi-Backend Database System Menu as shown is looking at the Multi- in Figure 4-7. Select r for the relational/SQL interface and the system will prompt the user for the operation desired (Figure 5-1). Select option(l) to load a new database, (p) to process a database currently Enter type of operation desired Action (I) - (p) - (x) - new database process existing database load MLDS/MBDS return to the system menu —> Figure 5-1 System prompt to load a new or process an existing database resident on the systems data disk, or (x) to return to the Multi-Lingual/Multi-Backend Database System Menu. After selecting option database name (Figure 5-2). If the user is (l) loading a or (p) the user will be new database, the should (for clarity) give an idea of what the database represents schedules could be called base, it is SCHEDULE). If the prompted for the name (i.e. of the database a database of class user desires to process an existing data- imperative that the database exist or the system will endlessly loop asking for the database name. If this situation presents itself, enter 59 Control-c to abort the system and start again as described in the Getting Started section. The database in all capital letters or small case letters, there is Enter name of no name may be written restriction. database — -> Figure 5-2 Enter database B. name prompt LOADING A NEW DATABASE Loading a new database schema differs from processing an existing database (Figure 5-3). developed (this is the terminal. The mode user must either select option of input desired to load the schema and have a schema (f) highly recommended) or select the option Option (x) will take the user instructions are provided if back mode (t) from a read in a group read in creates from the terminal Action return to the of creates file main menu —> Figure 5-3 Loading of the schema After selecting option menu. Unscrewing of input desired (t) - already (t). (f) - (x) file of loading the schema from to the type of operation the user selects option Enter file. If new for the database has yet to be loaded to the system. After the user has entered the database name, the user will be prompted as to the file in that the (f) the user will be file prompted to enter the the file resides in a subdirectory of UserFiles, the user directory that the file resides as shown in Figure 60 5-4. name of the schema must provide the path of the As covered in the Schema and Request File section of this (the.t and manual, the schema create the template and descriptor files file will .d files). What is the name of the CREATE/QUERY file — -> DEMO/EMPRECsqldb Figure 5-4 Enter The MDBS file system will parse the schema name prompt file model language, ABDL. The parse the kernel data schema schema and transform the relational schema into will determine what the relations of the are and a screen will appear displaying the relations and a opportunity to index attributes in the relation if so desired. Figure 5-5 illustrates this action. The following are the Relations in the EMPREC Database: EMPLOYEE JOB PAY Beginning with the first Relation, You we will present each be prompted as to whether as an Indexing Attribute, and, if so, whether it is to be indexed based on strict EQUALITY, or based on a RANGE OF VALUES. If you do not want to enter any indexes for your database, type an 'n' when the Action -> prompt appears Attribute of the relation. you wish Strike RETURN Action will to include that Attribute —> or 'n' when ready to continue. Figure 5-5 Relations from a relational If the user desires to indexing is desired. In file and attribute indexing index attributes, onscreen instructions will direct the user properly index the attributes. if schema The user most will traverse through all relations cases, the indexing is not used. 61 and every how to attribute The user has now completed loading system. to Once the new database schema onto the MDBS the user has either finished indexing the appropriate attributes or desired not index attributes, the user will be prompted by Figure 5-1 and will select option (p) to process an existing database C. PROCESSING AN EXISTING DATABASE In order to process an existing database, the user will select and will be prompted schema now exists to enter the MDBS on the database name system, the user option (p) as in Figure 5-2. may now in Figure 5-1 Since the database input records into the system. After inputting the database name, the user will receive the screen display in Figure 5-6. Options two use (f), (t), and (m) all SQL transactions to provide a means to input records into the database. The insert records into the database (as well as other transactions) while the third option allows the user to input several records into the database from a This option is the first mass load function and mode Enter read read it is only offered with the relational interface. of input desired in a group in queries from the terminal of queries from a (f) - (t) - (m) - mass (d) - display the current database (x) - return to the previous Action file. load a file file schema menu —> Figure 5-6 Record input menu D. THE MASS LOAD FUNCTION The mass load function is a unique method of loading records database. Without having to write several numerous records INSERT into the database using the transactions in mass load option, the user will be prompted 62 SQL, the user can load mass load function. All mass load contain the suffix ".r" and should be prefaced by the database selecting the into each relation of the for the name files for clarity. After mass load file as in Figure Figure 5-8 5-7. an example of a mass load is file. The system will not read the space file must be maintained in the Enter a TAB file, the and not the produce by the spacebar and assume one large As with attribute value or crash the system. developing a mass load must be separated by space in between attribute values along a tuple spacebar. When the schema and request files, the mass load UserFiles directory or a subdirectory of UserFiles name of record file — -> DEMO/EMPREC.r Figure 5-7 Prompt After indicating the mass load to input file mass name, a load file ABDL series of appear. If this does not happen then there has been an error in the A system will crash. the mass load load option does not replace the traditional faster method of initializing INSERT command mass load file and the period of inactivity greater than 20 seconds indicates problems with and the necessity for the user file insert statements will to abort the SQL INSERT command a database with base data. to load the database is system and still The traditional a viable option on restart. The mass but merely offers a method of using SQL MDBS. LOADING RECORDS USING SQL INSERT AND PROCESSING OTHER E. TRANSACTIONS user desires to insert records into the relational database via the traditional If the SQL INSERT commands method of using and/or wishes to process against data currently residing on the database, option maintain a a list file of the prompt will be chosen. transactions The user must within the UserFiles directory (or a subdirectory of UserFiles) that contains SQL transactions to be processed against the relational database. This file commonly known A (f) SQL as the request file and the file name is always contains the suffix "req". will appear after option (f) is selected requesting the user to input the the request file (Figure 5-9). Figure 3-5 shows an example of a request 63 is file name of developed for the EMPREC database. An explanation of request file format is covered in the Schema and Request File section. EMPREC @ EMPLOYEE JOHN JONES BETTY HART PETE SMITH THOMAS TINA JUDY KEWIN 111111111 222222222 333333333 444444444 555555555 M F M F M @ JOB MANAGER 222222222 MANAGER 333333333 ACCOUNTANT 111111111 444444444 SECRETARY @ PAY 111111111 50000 222222222 60000 333333333 45000 444444444 30000 $ Figure 5-8 Mass load file What is the name of the CREATE/QUERY file Figure 5-9 Prompt for request After inputting the request multiple transactions on one file is left will MDBS file will scan the request file and, in the case of number each transaction. If the display of the request longer than the screen display, the -more- prompt will be displayed in the bottom- comer of the of the file, file, — >EMPRECreq file. active For longer window. Pressing the return key will display the remaining contents files, this process may be repeated several times before reaching the 64 end of file. Once the transactions in the request have been displayed file to the user, a menu selection, as seen in Figure 5-10, will appear requesting the user to either execute a transaction, redisplay the contents of the request Note that the first two options will execute or exit back to the previous menu. and then return the user decides to use another request file or to the must enter menu entering option (x) will send the user to the The file, in menu in Figure 5-10. It a transaction via the terminal, Figure 5-6 user will process transactions against the database by simply entering the number of the transaction after the Action prompt in Figure 5-10. The for semantic and syntactic correctness and, an appropriate message will be displayed. A if in error, serious error violating the conventions of the data language could result in a catastrophic error causing a bus error (core number Pick the (num) - dump) and the need to restart the system. or letter of the action desired execute one of the preceding queries of queries (d) - redisplay the (x) - return to the previous Action file menu -- Figure 5-10 Transaction execution If menu a transaction processes correctly, a display of the transaction will be given and, in the case of a the query. transaction will be checked This is illustrated in translation of the SQL RETRIEVE operation, the data resulting from Figure 5-11. Appendix B outlines the steps necessary relational database ABDL EMPREC on the MDBS 65 to load and process the demonstration [ RETRIEVE (TEMP = Employee)(LNAME, FNAME, SSN, SEX) LNAME |FNAME |SSN |SEX|| SMITH |JOHN |BETTY |PETE 1111111111 |M JONES HART THOMAS JUDY 222222222 IF |333333333 |444444444 |M JTINA IKEWIN I555555555 IM IF Figure 5-11 Result of a SQL retrieve operation with 66 ABDL translation ] VI. A. INTRODUCTION The network all THE NETWORK/CODASYL INTERFACE interface network data models. on the MDBS system uses schema and request All CODASYL as the data language for files require order to construct and manipulate the network databases on network/CODASYL interface will resemble Figure constructs to create the schema file. are created prior to execution of the At this point, the user that the request CODASYL and schema files system. has entered the run Lingual/Multi-Backend Database System statements in MDBS. The schema file for the 3-4 using the basic The user must ensure MDBS CODASYL Menu command and as shown is looking at the Multi- in Figure 4-7. Select n for the network/CODASYL interface and the system will prompt the user for the operation desired (Figure 6-1). Select option (I) to load a new database, option (p) to process a database Enter type of operation desired load (I) - Action (p) - (x) - new database process existing database return to the operating system —> Figure 6-1 System prompt to load a new or process an existing database currently resident on the systems data disk, or option (x) to return to the Multi-Lingual/ Multi-Backend Database System Menu. After selecting option prompted name for the database name (Figure 6-2). If the user is (l) or (p) the user will be loading a new database, the of the database should (for clarity) give an idea of what the database represents a database of parts records could be called ing database, it is PARTS). If the start user desires to process an exist- imperative that the database exist or the system will endlessly loop ask- ing for the database name. If this situation presents system and (i.e. itself, enter Control-c to abort the again as described in the Getting Started section. The database 67 name may be written in all capital letters or small case letters, there Enter name of is no restriction. — -> database Figure 6-2 Enter database B. name prompt LOADING A NEW DATABASE Loading a new database schema differs from processing an existing database new for the database has yet to be loaded to the system. After the user has entered the database name, the user will be prompted as to the file in that the mode of input desired to load the schema (Figure 6-3). Notice the difference between input options presented in the network interface and the relational interface (Figure the option to input a file exists prior to The network the terminal. Therefore it is interface does not provide imperative that the schema executing the network interface since further processing will not be schema possible without a menu schema from 6-3). Selecting option (x) will take the user back to the previous file. (Figure 6-1). Enter mode (f) - (x) Action - of input desired database description from a return to the to main menu read in —> Figure 6-3 Loading the schema After selecting option file. If (f) the user will be file prompted to enter the the file resides in a subdirectory of UserFiles, the user directory that the file resides as Request shown File section of this manual, the files (the.t and file in Figure 6-4. schema .d files). 68 file will name of the schema must provide the path of the As covered in the Schema and create the template and descriptor What is the name of the DBD/REQUEST file — ->DEMO/NET1 dmldb Figure 6-4 Prompt The to enter network schema file name MDBS system will parse the schema file and transform the network schema in the kernel data model. Attribute Based Data Attribute Based Data Model (ABDM), and kernel data language, Language (ABDL). The parse will determine the records that comprise the network database schema. The next screen will database as a result of reading the network schema file list the records of the (Figure 6-5). Also available opportunity to index attributes for selected records in the database. The following are the Records in the network If is the the user desires to NET1 Database: SUPP PARTS PURCH Beginning with the first Record, we will present each Attribute of that Record. You will be prompted as to whether you wish to include that Attribute as an Indexing Attribute, whether it is to be indexed based on strict or based on a RANGE OF VALUES. If you do not want to enter any indexes for your database, type an 'n' when the Action -> prompt appears and, if so, EQUALITY, Strike RETURN Action —> or 'n' when ready to continue. Figure 6-5 Records from a network schema and attribute indexing index attributes, a prompt will appear for every attribute in every record as to whether index values for that attribute are desired. In most cases, indexing of attributes The user has now completed loading a new network database schema onto system. Once is not used. the MDBS the user has either finished indexing the appropriate attributes or desired not 69 to index attributes, the user will be prompted by Figure 6- 1 and will select option ( p) to process an existing database. C. PROCESSING AN EXISTING DATABASE In order to process an existing database, the user will select and will be prompted to enter the database database schema on the MDBS, the user should CODASYL make in a as in Figure 6-2. may now execute no records stored the database. Since there are schema had been loaded the user name option (p) in the Now in Figure 6-1 that the network CODASYL transactions against database at this time (unless the previous session and records were added during that session) the first group of transactions in the request file MOVE and STORE transactions, in order to load the database with data prior to processing any query transactions. The record input menu, Figure name. Options request file (f) and (t) 6-6, will appear after inputting the correct database provide the user the opportunity or through the terminal respectively. If option unsure that the request mode Enter (t) - Action file CODASYL in a group in CODASYL of requests from a requests from the terminal (d) - display the current database (x) - return to the previous file schema menu —> the request and "req" as a chosen, the user must resides in the UserFiles directory or a subdirectory of UserFiles. Figure 6-6 CODASYL record input The name of (f) is of input desired read read (f) - file should use the suffix, thus the PARTSreq. Additional request identify to either input transaction via a how many request name of files name menu of the database the request file for the (i.e. PARTS can have an additional numerical files exist for PARTS) as a prefix database would be suffix after "req" to a database. Figure 3-6 illustrates a sample CODASYL request file. An explanation of the format used for request files is found in the 70 Schema and Request Hie I). section of this manual. LOADING AND EXECUTING CODASYL TRANSACTIONS VIA REQUEST FILES After select option name a the list the user will be The user will as in Figure 6-7. numbered (f), prompted to enter the enter the appropriate of transactions will appear on the screen. CODASYL request file name and If the -more- message appears bottom lefthand corner of the screen, simply press Return request file. selection as After shown all in CODASYL request file review the to in rest of the transaction have been displayed, the user will be displayed a menu Figure 6-8. What is the name DBD/REQUEST file of the — -> Figure 6-7 Prompt Pick the number (num) Action - for CODASYL execute one Attribute preceding of the CODASYL (d) - redisplay the (x) - return to the previous file of CODASYL requests requests menu —> Figure 6-8 transaction execution CODASYL The user may now begin executing Figure 6-8. file or letter of the action desired CODASYL entering the request number corresponding If a transactions against the database by to the transaction desired at the CODASYL STORE transaction Based Data Language (ABDL) return to Figure 6-8 for further processing. ABDL translation menu is Action — > prompt in executed, the system will display the translation of the CODASYL request and then A CODASYL GET transaction will generate an followed by the display of data from the query and then Figure 6-8 for further processing. If the user executes a CODASYL ERASE or MODIFY transaction, the 71 system will only display the ABDL translation of the CODAS YL request and will return to Figure 6-8 upon completion. In order to ensure transaction accomplished request file that Any all STORE, ERASE, and MODIFY what was desired, the user should include transactions verify the correctness of these three transactions errors that may result from violations of integrity constraints will be displayed to the user Catastrophic errors violating the conventions of the data language system crashing and (x) up to the in the restart of the system necessary. The user Multi-Lingual/Multi-Backend Database System CODASYL database. Appendix B provides may may result in the simply follow the option menu when finished with the a quick reference for executing the network/ CODASYL interface 72 THE HIERARCHICAL/DL/1 INTERFACE VII. A. INTRODUCTION The hierarchical interface on the Schema and hierarchical data models. MDBS uses DL/1 as the data language for request files used in the hierarchical interface must MDBS. use DL/1 statements in order to manipulate the hierarchical database on 3 is an example of a DL/1 schema schema file must be created prior file. to all As in the case of the execution of the MDBS Figure 3- network database, the DL/1 since schema creation is not possible through terminal input. The user has executed the the run command from the UNIX prompt and should now have Multi-Lingual/Multi-Backend Database System Menu, as shown displayed. To begin operations menu will appear (Figure Figure 4-7, in the hierarchical/DL/1 interface, select option (h) and the desired menu. Whether the user 7-1). selects option (I) Option (x) will return the user or (p), the next prompt back to the MDBS will request the user to Enter type of operation desired load (I) - Action new database (p) - process existing database (x) - return to the operating system —> Figure 7-1 System prompt to load a new or process an existing database input the database name as shown in Figure 7-2. If processing an existing database, the user should check the metadisk with the pry that the database name schema is command prior to running MDBS to ensure resident on the system. If the user does not correctly input the of an existing database, Figure 7-2 will infinitely loop until the user inputs an exist- ing database name. system. Control-c will exit the user from the If this situation occurs, the user must kill 73 all infinite loop and also the MDBS processes using the stop.cmd com- mand and There restart the system. the database name, it is strictly B. restriction as to the case of the letters name prompt of database — -> Figure 7-2 to enter database name LOADING A NEW DATABASE Loading a new database schema differs from processing an existing database in that the new for the database has yet to be loaded to the system. After the user has entered the database name, the user will be prompted as to the file comprising the users preference. Enter MDBS no is mode of input desired to load the schema (Figure 7-3). Notice the difference between input options presented in the hierarchical interface and the relational interface (Figure the option to input a file exists The network the terminal. Therefore it is interface does not provide imperative that the schema prior to executing the network interface since further processing will not be possible without a menu schema from 5-3). schema file. Selecting option (x) will take the user back to the previous (Figure 7-1). mode Enter (f) - (x) Action of input desired database description from a return to the to main menu read - in file —> Figure 7-3 Loading the hierarchical schema After selecting option file. If (f) the user will be prompted to enter the the file resides in a subdirectory of UserFiles, the user directory that the file resides as Request files (the shown File section of this manual, the .t and in Figure 7-4. schema .d files). 74 file will file name of the schema must provide the path of the As covered in the Schema and create the template and descriptor What is the name of the DBD/REQUEST file — ->DEMO/SQDdlidb Figure 7-4 schema filename Entering the hierarchical The MDBS system will parse the schema data model. Attribute Based Data in the kernel file and transform the hierarchical schema Model (ABDM), and Attribute Based Data Language (ABDL). The parse compose the hierarchical database schema. will described in Figure 7-5, the user segment is determine the segments that The next screen hierarchical database as a result of reading the hierarchical kernel data language, will list schema the records of the file (Figure 7-5). As given the opportunity to index specific attributes of each in the hierarchical database. Indexing the user does opt to use attribute indexing, all is not a required function of attributes in every segment MDBS and if will be screened for possible indexing. The Segments following are the in the SQD Database: CO MAINT OPS ACFT first Segment, we will present each Segment. You will be prompted as to whether you wish to include that Field as an Indexing Field, and, if so, whether is to be indexed based on strict EQUALITY, or based on a RANGE OF VALUES. If you do not want to enter any indexes for your database, type an 'n' when the Action --> prompt appears Beginning with the Field of that it Strike RETURN Action —> or 'n' when ready to continue. Figure 7-5 Segments from a hierarchical schema and attribute indexing After completing the action in Figure 7-5, the user has hierarchical schema to the MDBS system and is 75 ready to now successfully loaded the process DL/1 transactions against the database. The user prompted by Figure 7-1 and will be will select option (p) an existing database. Figure 7-2 will appear prompting the user for the database process. Enter the name of the database process to name to whose schema was just loaded. PROCESSING AN EXISTING DATABASE C. In order to process an existing database, the user been loaded the schema to the file MDBS. If the schema file must ensure that the schema has not been loaded, select option When as described in the previous section. (I) file has and load processing an existing database, the user has the opportunity to load data into the database, execute queries, as well as modify and delete existing records. If the schema file has just been loaded to the system, the user should ensure the first group of transaction processed against the database are used to load initial data into the appropriate As segments. with the other data models, the user will have the option of executing DL/1 transactions using a request file with transactions or creating transactions at the terminal as illustrated in Figure 7-6. If the user the same convention chooses option as outlined in the other data Database section for Network interface). user opts for terminal input of DL/1 A (f), mode the request file should be named in sections (see Processing an Existing DL/1 request file is listed in Figure 3-3. transactions, onscreen instructions will explain If the how to properly enter and format the transactions. Enter mode (f) (t) - (x) Action - of input desired read read a group in DL/1 requests from the terminal of DL/1 requests return to the previous menu Figure 7-6 of input for DL/1 transactions REQUEST FILE ORGANIZATION FOR LOADING With file —> Mode D. from a in DL/1 TRANSACTIONS the hierarchical database, any records loaded to the database hierarchical order with those records belonging to the root 76 must be done segment loaded first, in a children segments second and so 1 BUILD commands When forth. creating your request beginning of the at the file file, it is and ordered easier to put the in a hierarchical DL/ fashion in regards to the hierarchy of the segments. After choosing option (f) or (t), the user will be given a numerical listing on the screen of the DL/1 transactions either entered via a request the -more- message appears Return review the to Network/CODASYL file or through direct terminal input. If bottom lefthand corner of the screen, simply press Note, after selecting option rest of the request file. be prompt to input the request name in the same manner (f ) the user will as discussed on page 28 in the interface section and illustrated in Figure 6-7. Upon completion transactions in the file of the transaction from the menu in the user will be ready to execute those list, Figure 7-7. Unlike the relational and network interface, the hierarchical interface has a currency pointer transaction that uses a DL/1 BUILD command which starts must begin at the root at the root segment. segment Any in order to load data onto the database. Therefore, option (r) must precede the selection of option ( num ) for every BUILD transaction issued so that the data in the transaction can follow the Pick the number (num) (d) (r) (x) Action or letter of the action desired execute one preceding DL/1 requests - redisplay the file of DL/1 requests - reset the currency pointer to the root - return to the previous menu - of the —> Figure 7-7 DL/1 transaction execution path down the hierarchy to the segment where the data menu is to be stored. Figure 7-8 shows a sequence of resetting the currency pointer and executing a transaction. Note that a cation message using is given upon any GU, GHU, GNP tions will BUILD, IRST, and REPL will display the data requested and have the equivalent ABDL translation displayed 77 transaction and all verifi- queries no message. All DL/1 transacon screen after successful exe- cution. The user can see from ABDL translation how the the database hierarchy in order to reach GU After executing a its the transaction is traced through destination segment. transaction (Get Unique), if the next transaction is a Next Pointer) within the same segment, then the currency pointer does not need number Pick the (num) (d) (r) —> (d) (x) Action of DL/I requests menu r number (num) (r) preceding DL/I requests of the file return to the previous - Pick the or letter of the action desired execute one preceding DL/I requests - redisplay the file of DL/I requests - reset the currency pointer to the root - return to the previous menu - of the —>8 [RETRIEVE ((TEMP = Co) and (SNO = (SNO) BY A2)) SNO RETRIEVE ((TEMP = Ops) and (SNO = A2) and (ODN = [ to be reset reset the currency pointer to the root - (x) Action redisplay the - (Get or letter of the action desired execute one - GNP (ODN) BY ODN ] 55)) ] INSERT (<TEMP, <ANAME, Bd>) [ <SNO, A2>, <ODN, Acft>, 55>, <ANO, 07>, ] Insert accomplished Figure 7-8 Sequence of selection ABDL translation and when message. Note ABDL statedatabase in order to insert the proper segment. verification ments follow the hierarchy the data If the currency pointer is reset rency pointer first, in and the Figure 7-9 will be displayed. If an resetting currency pointer with of the GNP ISRT transaction is executed, the error message in transaction is executed without resetting the cur- the user will be displayed the error 78 message shown in Figure 7-10. These examples are derived from the in the SQD hierarchical DEMO subdirectory of UserFiles. interface is provided A quick reference for executing the hierarchical Appendix B. This quick reference in demonstration hierarchical database Action Error DM schema and request files found will step the user through the SQD. — > 12 in GN - You have specified no previous Operations. or specify a First return to the root comftete-p^/i transaction number Figure 7-9 Error resulting when resetting the currency pointer is not required Action — > 3 ^^ DL/1 transaction Error - number an ISRT must occur from the root of the Figure 7-10 Failure to reset currency pointer for a DL/1 ISRT 79 database command VIII. CROSS MODEL ACCESS CAPABILITY RELATIONAL TO HIERARCHICAL - OVERVIEW A. The benefit of throughout to MDBS as a multi-model/multi-lingual system has been shown manual. Large corporations using several separate homogeneous database this form one large heterogeneous database can benefit from the single system design of MDBS. With several different data models mapped model/data language to a kernel data on the same system, the sharing of data between two different data models amount saved through as well as the vast is now possible the consolidation of these several resources into MDBS offers the capability for a relational user to access a hierarchical database using one. SQL transactions. This transaction translation. relational is possible through the use of schema transformation and Instead of copying the existing hierarchical database into a database (and thus having to maintain two different databases), schema transformation permits the schema of the hierarchical database to be transformed into a relational B. schema so that SQL transactions may be processed SCHEMA TRANSFORMATION Figure 8-1 illustrates the concept of schema transformation of the hierarchical schema into a relational can now schema. The hierarchical database is transparent to the relational user access the hierarchical database using the relational interface. transactions map directly into the hierarchical data language. ABDL However, who SQL SELECT language and require no translations into the SQL INSERT, SELECT, require a translation into the hierarchical data language DL/1 and DELETE in order to transactions maintain the parent/child relationships of the hierarchical database. Because the relational cannot detect the parent/child relationships of the hierarchical schema schema, the SQL transactions cannot guarantee the parent/child relationship between segments will be violated. The translated into transaction translator realizes that certain DL/1 SQL transactions must be in order to maintain the integrity of the hierarchical database. 80 The work of the user who transaction translator and schema transformer is all transparent to the relational can access the hierarchical database as though the database was still strictly relational. Hierarchical Data Model Model and Data Language Relational Data and Data Language Schema I I Transformer HLI RLI KDS Kernal Data Model and Data Language Figure 8-1 Schema Transformation Process C. EXECUTING THE HIERARCHICAL TO RELATIONAL CROSS MODELING CAP ABILITY Now is familiar with the concept behind the cross ready to use this capability. The first step model capability of the user must take is to MDBS, the user load a hierarchical database as described in the Hierarchical/DL/1 Interface section. Only the schema has be loaded to the hierarchical database. It is to not necessary to load the hierarchical database with data using DL/1 transactions. Once the schema 81 is loaded, the user should back out to the Multi-Lingual/Multi-Backend Database The user relational/SQL interface the name The System Menu and will then request option (p) in select option (r) for the Figure 8-2 and then enter of the hierarchical database just loaded. user will now be requested Figure 8-3. Even though the user database, the user Transparency is is to select the of transaction input as shown in accessing and processing records against a hierarchical given the same prompts as to the user is mode maintained if the database was strictly relational. at all times. Enter type of operation desired (p) - (x) - Action Enter new database process existing database load (I) - return to the MLDS/MBDS system menu —>p name database of — -> sqd Figure 8-2 Processing an existing hierarchical database using the relational interface mode Enter read in (t) - read in (m) - (f) - mass of input desired a group of queries from a queries from the terminal load a file (d) - display the current database (x) - return to the previous Action file schema menu —> Figure 8-3 Relational/SQL interface mode of transaction input screen As with the other models, the user may choose a prepared input or type transactions from the terminal. file of The mass load function 82 SQL transactions for will not function with the cross-model capability covered in the and thus should not be chosen. The remaining steps mirror those Relational/SQL Interface One important note: when interface, there is hierarchical/DL/1 no need interface. section. is executing transactions within the relational/SQL to reset the currency pointer as required when using the the user The schema transformation and transaction alleviates the relational user of having to maintain the currency pointer SQL transaction. A Currency pointer manipulation is translation when executing transparent to the relational user. quick reference and an example of the execution of the cross-model access capability is provided (also created in in Appendix B. This appendix Appendix B) will use the hierarchical database SQD as the hierarchical database to be transformed into a relational schema. 83 THE ATTRIBUTE-BASED DATA MODEL-LANGUAGE IX. INTERFACE A. OVERVIEW The attribute- base data model (ABDM) system. Coupled with the attribute- based data language language (ABDL), for the this data MDBS model/data the key to the multiple data model/data language to single data model/data is MDBS language mapping that makes kernel data model the kernel data is model based because it a federated database. stores the The ABDM was chosen as the meta data and base data separately, introduces equivalence relations which partitions the base data into mutually exclusive sets called clusters, and allows these clusters to be distributed across the backends inducing parallel access to the base data. ABDL was chosen as the kernel data language because complete language such that transactions written or CODASYL, can be translated into ABDL. it is in a traditional It is a semantically rich and language like SQL, DL/1, this translation capability that makes the MDBS mapping process a multiple data model/data language (i.e. relational/SQL, network/ CODASYL, hierarchical/DL/1) to a single data model/data language ABDL mapping. also ABDM/ABDL) supports the five basic database operations of RETRIEVE COMMON, INSERT, MODIFY, B. (i.e. and RETRIEVE, DELETE. DATABASE CONSTRUCTS Data in the ABDM is stored as an attribute-value pair. This attribute-value pair is the simple building blocks of the kernel database. The attribute-value pair consist of the attribute name and its corresponding value. When displayed, an attribute-value pair will be enclosed by a pair of angled brackets with the attribute for that attribute. An example would be <Vehicle, and Car would be A its first, followed by the value Car>, were Vehicle is the attribute name corresponding value. set of attribute-value pairs constitutes a record. value pairs name may have the same attribute-value name and 84 Within a record, no two at least attribute- one of the attributes in the record is a key. These that the record parenthesis two rules ensure that each attribute-value pair can be identified by one attribute which with attribute-value pairs within is these A a key. is single valued and record is enclosed by (<Vehicle, parenthesis: Car>, Manufacturer, Ford>, <Model, Explorers <Year, 1992>, <VIN, 1234567890>, <Owner, John Doe>). A a collection of records that share unique set of attributes. If a record belongs file is to a certain file, then the first attribute-value pair of the record will contain the attribute File and the corresponding first attribute-value file name. All records belonging For pair. example, same to the file will RegisteredCars>, (<File, have the same <Vehicle, Car>, Manufacturer, Ford>, Model, Explorer>, <Year, 1992>, <VIN, 1234567890>, <Owner, John Doe>), would indicate that the record belonged to the file RegisteredCars. and [HSIA 91] contain a detailed description of the is C. encourage ABDM and ABDL and the user to read these prior to executing the attributed-based interface. THE ATTRIBUTE-BASE DATA MODEL INTERFACE The user interface for the interfaces discussed earlier. ABDM differs slightly from the three traditional data model The ABDM interface does not require the use of a schema file or request file but instead uses template and descriptor models, the schema file (with or without indexing) descriptor files necessary for mapping files. was used In the three traditional data to generate the template and into the kernel data model/data language. In the ABDM interface the user must create the template and descriptor file prior to execution. A facility exists to generate a therefore it is recommended template and descriptor 1. database but there are bugs in creating the descriptor that the user use a text editor (i.e. emacs or file and vi) to create the files. The Template and Descriptor The template and Files descriptor files (the .d and structure of the attribute-based database. It is .t files) are these files which tell used to describe the the kernel database system what the template names are and the attributes within a template. Furthermore, the 85 and any constraints on these attribute type attributes will be noted in these files. A template can be thought of as a name of relation in a relational database. The template file contains the name of the database, followed by the number of templates within the database. After the number of templates, the next number number of attributes in the attributes in that template following template. The template and their respective type attributes for a template are listed, the number of have been database called listed. Figure 9- 1 is is listed the followed by the string, integer, etc.). Once all attributes in the next template is listed, followed by the next template's name. This process attributes (i.e. name is is all the templates and file for the demonstration repeated until an example of a template SALES. SALES 3 3 Item TEMPs PARTNO s PARTNAME s 3 Customer TEMPs CUSTIDs CUSTNAME s 4 Order TEMPs CUSTIDs PARTNO PRICE s i Figure 9-1 Template ' upon the The descriptor file File SALES.t contains information with regards to constraints placed attributes within the template. In order to achieve the MDBS, there are three descriptor types attribute which has a disjointed range of values which an (i.e. 86 attribute scores mutual exclusivity of the may >0 <= take on. Type a 100). Type b is is an an attribute of distinct value determined at (i.e. color = Type c black). is an attribute that has a dynamic range that run time. In figure 9-2, attribute values are the template names whose value range is in the from P0001 are also type a attributes to database. TEMP The is a type b attribute attribute P9999. The attributes whose value range goes from PARTNO is whose is distinct a type a attribute PARTNAME and CUSTNAME the letter A to Z. SALES TEMPbs Item Customer Order @ PARTNO a s P0001 P9999 @ PARTNAME as AF Gl JP QT UZ @ CUSTNAME as AF Gl JP QT UZ @ $ Figure 9-2 Descriptor File 2. The Mass Load SALES.d File Like the relational/SQL interface, the mass load option database to load records to the database. name with a.r suffix. The mass load 87 ABDL The mass load file interface also supports the file will format used in the be named after the ABDM interface is exactly like the mass load file mass load file format used resembles a template template name. The database name symbol. After each template, an End of file is marked by system looks for TABS file in the relational/SQL interface. In a sense, the with data instead of attribute names underneath the will appear at the top of the file followed @ @ symbol must be used as a separator between templates. a $ symbol. between An important note when creating a mass load file, the attribute values in a record (or tuple). If the spacebar is used between attributes, the system will not read the space as the and will erroneously read the mass load demonstration database by an file. of a new Figure 9-3 illustrates the mass load SALES. SALES @ Item P8845 P3985 P9002 P1233 Widget Bucket Jack P4501 Hammer Rake P4423 Ibeam P7269 Vice @ Customer C101 Bradley C1 02 Andrews C103Kreed C1 04 Ridley C105Zaxxon C1 06 Gibson @ Order C102P9002 29 C103P4501 19 C104P8845 14 C106P7269 79 C105 P4423 99 $ Figure 9-3 Mass Load start File 88 SALES.r attribute file for the Once the MDBS the user these files have been created, the user ABDM system using the must ensure interface. that the meta-disk has As with is ready to begin execution of the previous data model interfaces, been cleared and that no extraneous MDBS processes are executing. 3. Executing the ABDM interface After entering the run account like the select option (a) one command from the test directory of the cs4322 from The Multi-Lingual/Multi-Backend Database System menu in Figure 4-7. The next menu to appear will look like Figure 9-4. Selecting option (g) will take the user through the steps needed to create template and descriptor Due to a bug in the option to create a descriptor file, this required to create a template file through the manual files. will only outline the steps ABDL interface. The attribute-based/ABDL interface: (g) - (I) - (r) - Generate a database Load a database Request interface (x) - Exit to the previous menu Select-> Figure 9-4 ABDM interface menu If the a list user selects option (g), a of options in regards to file creation. menu will appear similar to Figure 9-5 with Select option (t) - Generate record template. The user will then be prompted for the name of the template file. Remember to use the same name of the database and add the suffix. t. The user will then be prompted to enter the database ID; which is simply the database name. The filenames similar to the manner in which ABDL interface is case sensitive to UNIX is case sensitive. The user will then be lead through a series of questions in regards to the number of templates in the database and the 89 A B number of will have attributes within to each template. Figure 9-5 shows the sequence of steps the user go through using an example template Enter the template called TEST.t name: TEST.t file ENTER DATABASE file ID: TEST ENTER THE NUMBER OF TEMPLATES FOR DATABASE TEST: 2 ENTER THE NUMBER OF ATTRIBUTES FOR TEMPLATE ENTER THE NAME OF TEMPLATE ENTER ATTRIBUTE #1 ENTER VALUE TYPE (s #1 : string, i = (s = string, i Templatel ATT1 : Templatel : ATT2A = integer): s ENTER THE NUMBER OF ATTRIBUTES FOR TEMPLATE ENTER THE NAME OF TEMPLATE ENTER ATTRIBUTE #1 ENTER VALUE TYPE (s string, i = (s = string, i = (s = string, i = Template2: ATT2B integer): s ENTER ATTRIBUTE #3 FOR TEMPLATE ENTER VALUE TYPE Template2: ATT1 integer): s ENTER ATTRIBUTE #2 FOR TEMPLATE ENTER VALUE TYPE Template2: integer): ATT3B i Figure 9-5 Sequence of steps in creating template file 90 #2: 3 #2: Template2 FOR TEMPLATE = 2 integer): s ENTER ATTRIBUTE #2 FOR TEMPLATE ENTER VALUE TYPE : Templatel FOR TEMPLATE = #1 Once to the the template file is completed exit the menu in Figure 9-4 and return attribute-based/ABDL interface menu. Figure 9-3. The user should have already created a descriptor file with the same name as the template file with a ".d" vice ".t" suffix, refer to Section 2 of this chapter if this has not The user now is ready to load the database to the from Figure 9-3 and then choose option requesting the sensitivity) name of and press the meta-disk of the illustrates this been done. sequence of name and the user A will now is prompt (1) appear of the database (don't forget case The database template and MDBS Select option from the next menu. (u) the database. Enter the return. MDBS. descriptor files are now loaded to ready to mass load data. Figure 9-6 steps. The attribute-based/ABDL interface: (g) - (I) - (r) - Generate a database Load a database Request interface (x) - Exit to the previous menu Select-> Select an operation: (u) - (r) - Use a database Mass load a file (x) - Exit, return to of records previous menu Select-> u Enter the name of the database: SALES Figure 9-6 menu Sequence steps to The next menu appear in Figure 9-6. Select requesting the name of to option the (r) use an attribute-based database - mass load is a select operation Mass load a file. file of records. The mass load 91 menu file similar to the second A prompt will appear must reside within the r UserFiles subdirectory of the cs4322 class account. Since the mass load to the database, normal. If the it may require a mass load file little was more time to execute. A delay file is loading data of up to 20 seconds successful, the user will return to the previous select option (x) to return to the attribute-based/ABDL interface is menu and menu. Figure 9-7 shows the screen display for the sequence of steps outlined above. Select an operation: Select-> (u) - (r) - (x) - Use a database Mass load a file Exit, return to of records previous menu r Enter the record name: SALES. file Select an operation: (u) - (r) - Use a database Mass load a file (x) - Exit, return to of records previous menu Select-> x The attribute-based/ABDL interface: (g) - (I) - (r) - Generate a database Load a database Request interface (x) - Exit to the previous menu Select-> Figure 9-7 Steps At interface. in processing the mass load the attribute-based/ABDL interface The next menu to menu, appear will be the subsession 92 file select option (r) menu - Request that appears in Figure 9- 8. The beginning user should only be concerned with option subsession menu. Option (p) is (s), and (d) of the (n), used primarily for setting the internal and external clock to gauge system performance when increasing/decreasing the number of backends. Option (r) ABDL allows the user to choose where the output from the routed. The choice of routes (o) are self-explanatory with are printer, option (m) being a or removing traffic units from a transactions. A list other three data of traffic units model CRT (or monitor), file. is interfaces and is Options (m) and both, or none. menu driven Note: traffic units normally stored transactions should be process of adding, modifying, is the name given in a file similar to a sometimes referred for request ABDL file in the to as a traffic unit file. Select a subsession: SELECT: select traffic units from an existing (or give new traffic units) for execution NEW LIST: create a new list of traffic units NEW DATABASE: choose a new database (s) (n) (d) list PERFORMANCE TESTING (p) * (r) * (m) * REDIRECT OUTPUT: select output for answers MODIFY: modify an existing list of traffic units (o) * OLD LIST: execute existing all EXIT: return to previous (x) the traffic units in an list menu Refer to the MLDS/MBDS user manual before choosing subsessions marked with an asterisk (*) Select-> Figure 9-8 Subsession menu Option (n) allows the user to create a process against an existing database. This switch to a the user new database is also new menu (or file) of traffic units to driven. (provided template and descriptor may execute traffic list Option files exist). (n) lets the user Option (s) is were units against the attribute-based database. Select option (s) 93 and a prompt name of the will appear requesting the must contain traffic unit file example, the database second version a '#' SALES entered, the screen will display a will appear, see Figure 9-9, symbol before the has a traffic unit file is traffic unit file to first numbered file called SALES#1, so forth. After the traffic unit of the traffic units to be processed. list prompting the user version number. For traffic unit file version traffic unit SALES#2, and be processed. Note: the to execute a traffic unit, create a the file is A menu new traffic subsession menu. unit, redisplay traffic units, or return to Select Options: (d) redisplay the (n) enter a traffic units in new traffic unit to the list be executed (num) execute the traffic unit at [num] from the above list (x) exit from this SELECT subsession Option -> Figure 9-9 Traffic unit At to the Option-> prompt, enter the be processed. After build a new database. processing all traffic units number corresponding have been processed the user attribute- based database, or process a Appendix B provides a step-by-step attribute-based database menu SALES. 94 new to the traffic unit may exit the MDBS, traffic unit file against the original outline of executing the demonstration UM APPENDIX A: USEFUL UNIX AND MDBS COMMANDS THE .ALIAS FILE (ABRIDGE) A. TABLE 1 : Common System Commands Used ALIAS UNIX COMMAND MDBS Prior to Execution EXPLANATION P ps X shows test cd -/test change X exit logs user out of db3. user cd -/UserFiles change directory to UserFiles. data cd -/UserFiles change directory to UserFiles. disk cd -/RunData/Disks change directory to Disks. is od -c/dev/sd1c pry all running processes. directory to test. stored here. octal display of the meta-disk. indicate meta-disk -/test/stop, cmd burn These aliases are the cs4322 default directory, a stop all current most commonly used on the list Base data is clean. MDBS MDBS. Zeroes processes. In the file .alias in the of more aliases can be found. These aliases deal primarily with accessing the directories which contain the code for the user interface as well as the backend software. C SHELLS B. MDBS uses three remembering several when the C C shells to ready the system for execution. The burden of UNIX commands in a specific shells are used. These C shells are order found is no longer placed upon the user in the test directory of the account and are zero*, stop.cmd, and run*. Figures A-l through A-3 used by the MDBS software and a brief explanation of each provided. 95 C list the three cs4322 C shells shell function is also 1. The zero C Shell The zero C executing the zero the remove file shell command, command UNIX awk commands the user specify the be echoed with file it "No Match". This was supposed to file). The number of bytes files rm rm rm rm rm rm a result of MDBS resulted in were never removed from the system. The "cp /dev/ copy line will last line , null bytes into the file were the base data is u /usr/work/cs4322/.z /dev/sdlc 8000000", will that will be copied over. In Figure A-l, be nulled. #file: is After remove. Most of these are issued in case the previous execution of the ~/RunData/Disks/diskO" stored (the diskO may not finding the abnormal termination and these null will clean the meta-disk of all previous data. /usr/work/cs4322/test/zero -f ~/test/.*cat -f ~/test/.sql.dbl -f ~/test/.hie.dbl -f ~/UserFiles/.R* -f ~/UserFiles/*.iig.at -f ~/UserFiles/*.cinbt cp/dev/null -/RunData/Disks/diskO /usr/work/cs4322/.z /dev/sd1 c Figure A-1 The zero* C shell 96 8000000 8000000 bytes are to 2. The stop.cmd C Shell The stop.cmd C Figure A-2, shell. any kills MDBS process running on the system. The process numbers killed will be listed across the screen. contains the parameters by which the UNIX awk command are found, they are copied to a file list2.stop. numbers of the jobs as any data existing # to will search. If G_CPCLC and G_G_BPCLB echo 'Stopping | awk -f MBDS processes' .test.awk >! list2.stop set noclob set a='cat list2.stop' echo killing kill # rm rm rm $a $a list2.stop -f -f ##rm /usr/work/cs4322/RunData/G_BPCLB /usr/work/cs4322/RunData/G_CPCLC -f \tr core .b* Figure A-2 The stop.cmd C 97 .test.awk any parameters shell file is sockets of the /usr/work/cs4322/test/stop.cmd file: file list2.stop file contains the process be killed. After the jobs are killed, the list2.stop in the ps -x The The erased as well RunData directory. The run C 3. Shell The run C executable files that shell, Figure A-3, starts the MDBS file: The commented -f -f /usr/work/cs4322/test/run /usr/work/cs4322/RunData/G_BPCLB /usr/work/cs4322/RunData/G_CPCLC /usr/work/cs4322/VerE.6/CNTRL/scntgpcl.out >&! /dev/null /usr/work/cs4322/VerE.6/BE/sbegpcl.out >&! /dev/null & & /usr/work/cs4322/VerE.6/CNTRL/scntppcl.out >&! /dev/null & /usr/work/cs4322/VerE.6/CNTRLVpp.out >&! /dev/null & #/usr/work/cs4322/VerE.6/CNTRUpp.out >&! /usr/work/cs4322/test/pp.tr & /usr/work/cs4322/VerE.6/CNTRL/iig.out >&! /dev/null & /usr/work/cs4322/VerE.6/CNTRLVreqprep.out >&! /dev/null & #/usr/work/cs4322/VerE.6/CNTRL/reqprep.out >&! /usr/work/cs4322/test/reqp.tr & # /usr/work/cs4322/VerE.6/BE/dirman.out >&! /dev/null & #/usr/work/cs4322/VerE.6/BE/dirman.out >&! /usr/work/cs4322/test/dm.tr & /usr/work/cs4322/VerE.6/BE/cc.out >&! /dev/null & /usr/work/cs4322/VerE.6/BE/recproc.out >&! /dev/null & #/usr/work/cs4322/VerE.6/BE/recproc.out >&! /usr/work/cs4322/test/recp.tr /usr/work/cs4322/VerE.6/BE/dio.out >&! /dev/null # must the lines (those pre- # rm rm all drive the backends and controller. Tracer files can be used to track places were the system failed during a particular session. # system by calling NOT start until cntgpcl is & listening (sleep 10 ;\ /usr/work/cs4322/VerE.6/BE/sbeppcl.out >&! /dev/null /usr/work/cs4322/VerE.6/CNTRL/dblti.out1 #chmod g+w *.tr #rm *.trcore .b* Figure A-3 The run C shell 98 ) & & ceded by a #) that are used in calling an executable user desires to use tracer files, then the executable tile, are setup to use tracer files set up with a tracer tiles. file (i.e. If the #/usr/ work/cs4322/VerE.6/CNTRL/pp.out >&! /usr/work/cs4322/test/pp.tr &) must comment out the matching line containing the same executable mation to null (i.e. file name which sends tracer infor- /usr/work/cs4322/VerE.6/CNTRL/pp.out >&! /dev/null &). 99 README FILE C. The in README file can be found in the test directory of the cs4322 account. Figure A-4, the README file contains a list of system constraints place upon file size, attribute length case sensitivity, etc. file As shown when developing a new The user should always have a copy of the README database in order to have a quick reference to the system constraints. LIMITS max OF YOUR SINGLE USER SYSTEM length of unix file name for the template & descriptor 10 chars. max retrieves per transaction 5 is max chars for attribute name is 10 max for attribute value is 30 chars max # of attributes max # of descriptors max # of clusters max # of records per cluster max # of templates per max # of traffic you can have per template you can have you can have db is 1 150 per 50 attribute 00 200 is 1 query units per is is is file is 25 the largest integer value you can use to join on a retrieve common is 2147483647. Figure A-4 The README file 100 file is UM APPENDIX B: EXECUTION OF DEMONSTRATION DATABASES A. OVERVIEW The purpose of this executing the demo stored in the DEMO appendix the provide the user with step-by-step reference to will aid the user in is MDBS developing new databases on the MDBS interface. processes running (use the clear (using the that are MDBS system and giving the user a hands-on opportunity must ensure Prior to executing the interfaces, the user MDBS and cross model databases directory of the UserFiles directory in the cs4322 class account. by familiarizing the user with the work with to hierarchical, relational, network, These step-by-step instructions to is UNIX ps ax command that there are to verify) no extraneous and that the meta-disk pry command). Note: the meta-disk must have data from the hierarchical database in order to execute the cross-model accessing capability. B. THE RELATIONAL/SQL INTERFACE Type run from From the the mdb3/usr/work/cs4322/test directory. MDBS menu select option Select option load (I) - name Select option read desirec - - Execute the relational/SQL interface. new database from Enter the database (f) (r) EMPREC in a the type of operation menu. (caps not required). group of creates from a file from the mode of input menu. What is the name of the CREATE/QUERY hie prompt, enter the schema file name DEMO/EMPRECsqldb. At the If prompted to use the existing descriptor file, EMPREC.d, enter n for no. After the relations of the database are displayed, enter n for no indexing. Select option (p) - Enter the database For mode Enter process existing database for the name EMPREC at the of operation. (caps not required). of input desired, enter option (m) DEMO/EMPREC.r mode name - mass load a file. of record file— > prompt After the records from the mass load have been displayed, select option a group of queries from a file at the mode 101 of input menu. (f) - read in • What is the name of the CREATE/QUERY file prompt, enter the request file At the name DEMO/EMPRECreq. • The SQL transactions in the request numbered. Hit the return key hand corner • EMPRECreq prompt the -more- in order to finish scrolling 1, let SQL will be displayed and displayed in the bottom right is SQL through the At the action prompt enter the number of the Enter transactions. transaction you wish to process. the transaction process and observe the results, then execute transaction 2 and so forth • if file until all the transactions in the request file Once completed, number or enter option (x) - return to the previous letter of the action desired • Keep • Type zero from selecting option (x) until have been processed. menu at the Pick the menu. MDBS you have exited the system. the mdb3/usr/work/cs4322/test to clean the meta-disk in order to execute the next interface. C. THE NETWORK/CODASYL INTERFACE Type run from From the the mdb3/usr/work/cs4322/test directory. MDBS menu select option (n) - Execute the network/CODASYL interface. Select option load (1) - new database from Enter the database name NET1 Select option read desirec (f) - in the type of operation (caps not required). a group of creates from a file from the mode of input menu. What is the name of the DBD/REQUEST name DEMO/NETldmldb. At the If menu. prompted use the existing descriptor to file, file prompt, enter the schema NETl.d, file enter n for no. After the records of the database are displayed, enter n for no indexing. Select option (p) - Enter the database Select option (f) - process existing database for the name NET1 What is the name name DEMO/NETlreq The of the of operation. file at the (caps not required). read in a group of queries from a At the mode DBD/REQUEST file mode of input menu. prompt, enter the request file CODASYL transactions in the request file NETlreq will be displayed and numbered. Hit the return key if the -more- prompt is displayed in the bottom right CODASYL transactions. At the action prompt enter the number of the CODASYL transaction you wish to hand corner in order to finish scrolling process. Enter transaction 2 1 , let the and so through the transaction process and observe the results, then execute forth until all the transactions in the request file processed. 102 have been • Once completed, enter option (x) - return to the previous menu number or letter of the action desired menu. • Keep • Type zero from selecting option (x) until you have exited the MDBS at the Pick the system. the mdb3/usr/work/cs4322/test to clean the meta-disk in order to execute the next interface. THE HIERARCHICAL/DL/1 INTERFACE D. Type run from From the the mdb3/usr/work/cs4322/test directory. MDBS menu select option (h) Select option load (I) - name Select option read desirec At the - Execute the hierarchical/DL/I interface. new database from Enter the database (f) - SQD in the type of operation menu. (caps not required). a group of creates from a file from the mode of input menu. What is name the of the DBD/REQUEST file prompt, enter the schema file name DEMO/SQDdlidb. If prompted to use the existing descriptor file, SQD.d, enter n for no. After the segments of the database are displayed, enter n for no indexing. Select option (p) Enter the database Select option At the What (f) - is process existing database for the - name SQD name of operation. file at the (caps not required). read in a group of queries from a the mode of the DBD/REQUEST file mode of input menu. prompt, enter the request file name DEMO/SQDreq The DL/1 transactions in the request Hit the return key if the SQDreq file -more- prompt is will be displayed and numbered. displayed in the bottom right hand corner in order to finish scrolling through the DL/1 transactions. In order to execute the first ten option(r) Since the - DL/1 transactions, the user must first select reset the currency pointer to the root, then the transaction number. irst transactions that are being loaded to the hierarchical database a hierarchical order (i.e. data loaded to the root segment first, must be in then children segments, etc.), the root pointer must be reset after each transaction to ensure a complete path from the root • to the children segments. Reset the currency pointer prior to transaction 11 but do not reset the currency pointer for transaction 12. This is because the currency pointer is already at the from which the • seqment GET operation is being executed. Reset the currency pointer prior to transaction 13 and then execute transaction 14 since the currency pointer does not need to be reset prior to the execution of transaction 14. • The currency pointer must be reset prior to executing both transactions 15 103 and 16. menu • Once completed, • number • Keep selecting option (x) till you reach The Multi-Lingual/Multi-Backend Database System menu. Do not exit the MDBS system if you wish to use the cross model capability of the MDBS. Go to Section E for the steps need to execute the cross model interface. enter option (x) - return to the previous or letter of the action desired at the Pick the menu. THE CROSS MODEL CAPABILITY E. • MDBS system, the user should have the hierarchical database MDBS and be at The Multi-Lingual/Multi-Backend Database Without exiting the SQD loaded to System menu. • From MDBS the menu select option (r) - Execute the relational/SQL interface. • Select option (p) • Enter the database name • Select option read in a group of queries from a • • - - (f) process existing database for the SQD of operation. file at the (caps not required). mode of input menu. What is the name of the CREATE/QUERY file prompt, enter the request file name DEMO/SQDRTHreq. This file contains SQL transactions to be processed against a hierarchical database already loaded to MDBS. At the The SQL transactions in the request numbered. Hit the return key hand corner • mode if the file SQDRTHreq will -more- prompt in order to finish scrolling through the is be displayed and displayed in the bottom right SQL transactions. At the action prompt enter the number of the SQL transaction you wish to process. Enter 1, let the transaction process and observe the results, then execute transaction 2 and so forth until all the transactions in the request file have been processed. Notice that there is no longer a need for a currency pointer as in the hierarchical database interface. • Once completed, enter option (x) - return to the previous menu number or letter of the action desired menu. • Keep • Type zero from selecting option (x) until you have exited the MDBS at the Pick the system. the mdb3/usr/work/cs4322/test directory to clean the meta-disk in order to execute the next interface. THE ATTRIBUTE-BASED/ ABDL INTERFACE F. • From the MDBS menu select option (a) Execute the attribute-based/ABDL - interface. • Select option • Select option (u) • Enter Load a database from (I) - SALES - the attribute-based/ABDL interface menu.. Use a database. as the name of the database 104 name of the database to be processed. Remember that the ABDL interface is case sensitive. Also, there must be template and descriptor files already created for the database to be processes. If not, exit and create a new template be created using a Generate a database. The descriptor emacs or vi. using option (g) file test editor like - After entering the database name, select option (m) Enter SALES. r as the mass load file to - Mass load a tile file must of records. be processed. Select option (x) to return to the attribute-based/ABDL interface menu. Select option (r) From Request interface. - the subsession existing list (or give Enter the filename menu, new SELECT: select option (s) SALES#1 as the traffic unit file to be processed. unit file will be displayed. From processed. There are only 1 1 at all all traffic menu units by using the the menu, Be sure zero command. to clean the 105 list select the traffic units to of all traffic units in the traffic number of the traffic unit to be be executed. have processed, exit the that appear. from an traffic units) for execution. After entering the traffic unit filename, a numbered After select traffic units MDBS system by selecting option (x) meta-data disk after exitting the system ) APPENDIX ) B. ) )) ) ) ) ) MODEL-LANGUAGE INTERFACE GENERIC FUNCTION MAPPING Language Interface Layer tl.C I newuser.c new_model_language_user( nmlmain.c nml_main( " lil.c To nml_kemel_controller() nml_language_interfacejayer( n_load_new( n_process_old( lilcommon.c nmldbd_to_KMS( ) readrtnes.c nmlfree_requests( n_read_transactiion_file( nmlreq_to_KMS( n_read_file( ) list_nmlreqs( n_read_terminal( morenmlreqs(fname) n_read_file( ) find_nmlreq(num) To nml_kernel_mapping_system{) new user by granting user 1. Establish 2. Call to 3. Whether processing an 4. Call is to allow made user access to existing or to either load a id (for kmsgenerals.c use with a mult-user system). new model-language interface. new database, determine mode new database to of input (terminal or file) MDBS or process an existing database KMS to parse the schema KMS to parse a request transaction selected by the user. Call to KC to execute a transaction or load a schema parsed by KMS onto MDBS. 5. Call to 6. Call to 7. LIL in file. 106 in nml_kc.c ) ) ) Kernel Mapping System Loading a Schema File From nmldbd_to_KMS ( j in lilcommon.c From nml_load_new( ) in lil.C 1. ~l imsgeneral.s.c _^~— 2- nml.c — nml_parser() nml_yyparser() free_duplicatesjist() 7T error(t) nml.v YACC_CODE 3. yy_error() nml.l LEX_CODE buildnmldesc.c buildndl.c nml_build_desc_file() n_build_ddl_files() 6. print_record() build_nml_template_files() nml_traverse() 1. Function call from LIL to KMS to load the schema file. 2. KMS 3. Call - calls the parsing function. LEX and YACC code Loading a Request to validate input 4. Control returned to kmsgenerals.c 5. Build the template 6. Build the descriptor file. file. stream File From find_nmlreq_to_KMS ( ) in lilcommon.c 1 I D.C lilTKd kmsgenerals.c dml_kernel_mapping_system( nml_parser() free_duplicates_list( nml_yy parse () error(t) nml_schema_cleanup( nml_yy_error() nml_kmsjnfo_cleanup() 4. nml_reset_ variables?) To LEX and YACC code in nml.y and nml.l Return control to 1. Function call from LIL to KMS to load the request 2. KMS call the 3. Call 4. Transaction execution complete, return to LIL. file. parsing function. LEX and YACC code to validate 107 request transaction. LIL c Kernel Controller From lil.c 1 mill RC.C nml load la. tl.C dbl_template() nml requestliandler.c 6b.\ \ 2. lb> N. 6a. tables. nml_ load_ tables () nml_kemel_controller() nml 3. \ f exec.c nml_execute() nml_request_handler() 4. 1 r tisr.c Return to LIL Reformat results in K.FS TI_S$TrafUnit(dbid, trafunit) TI_Finish() new schema, template la. If loading a lb. If loading a request, call appropriate request handler based on transaction calls the function to load file. type. 2. Call the Test Interface to load the template 3. Execute the transaction on 4. Call the Test Interface to 5a. Schema is loaded to file. MDBS. send transaction MDBS, to KDS. control returned to LIL. 5b. Transaction completes execution and must be reformatted by the KFS Kernel Formatting System From nml kc.c 1. X nmlkts.c - nml_kfs() Return control to LIL with reformatted result for display to the user. 1. Receive control from KC; reformat ABDL 108 result into UDM format . APPENDIX C. MM&MLDS GENERIC MODEL-LANGUAGE DATA STRUCTURE CCO. o l. JJ O . — OOO eo — CD c£2 i 0- C_T3 en 5 , CO — *l b * oo o 0> c c c "O T3 * cd 1) * U. H u D. C. c_ cd cU [•< .E CQ B i> >- c/> C <u 31 cr CU u. <u E B oo "O * § O) oo * o c * § * § * cr w C cr cr cU c 1 H i •o cU JS u- I e § * *— s c •c © c * 1 •o J2 •o I a" cr J J J ,1 S c — .- coo G o ° i1 e _3 = « 0-7 cdcj-cj CL, « x: t- C D. cU BO 00 q * 4D E C # CU i— 1 JS •a a * u- * 1 1 er T3 O C o c 1 T3 "3 •a c b o T3 -C -C o a __l D La JS aj e o o B cu 1_ « ex TT JS •a a> CU CD "g "8 "8 "g E a B c j — J rt eB .1 3 B U C3 u. .E c c b £ — Q E cr 1 cr cr cr OJ u. In 1 cr cU 1 _l cd TD cr CD cu In 1 0) E "3 « i> & E cd B X & •a •a ,© «— i i •o c o cr cr H cU 25 CjC "°i -a o o c t' y= a o •a a —o (4-1 u. i i-i o « cr <0 u. rt «J ao do •o o b o E <^> A o 1 1 c u 1 cfl i- 3 0) O E Tl o E 1 T3 X! "O % o JS •fc- T3 a> (J ci a> TD O E 3 o — ^ OiJ cd E J _E o E cr cr CU 1— cU G , , E f ai cr CA 3 •a ^^ & i T3 T3 <™H ^^ c2 S.2 s c o.S a> CU 60 00 a SC3 v ' so CS O 3 O O0 0JD C3 3 C 3-' 1-s Oo T3 O .2 — E .5 =3 T3 E 1 c z 109 to . u E '3 d<2 j CU 00 0) 2 C 00 b<0 u 3 S 2 c o = O T3 CO 2_ « ut2 C-O «J o2« E-o u c 1c —V3 — •Si | J= C ^ O O | CD ^ ^ MO M * * * * <*- 3 3 s * * O 4*! J <D J* # O M c C/3 •— (/J o c E, a, u * O c «* fi 2 c-o o 2 3 E-o a CO •V.TJ to ol a- t-i C_ n 3 CU h C/l — ? BH ° '5 O V W 00 a) 0) « 3 £ ~ °°S «B 1 1 ."^ <*- E ^ o c E O C o C <4- c 1 1 1 c a CD .^ ,w 3 a — 2 ^O c/] c/3 / \ O. S CD "D T3 ya i d e 1 # ya O c «*- c 0 a 1 <L> CB I 3 60 *' 0) c E 2 1 4) 00 00 eo ca 00 00 3 S O E 1 1 4> 8P 1 ,0 tS .2 C/2 •O ^ S •O •O 1 ya 1 3 4> (U "O T3 o E * a> c E o Eh tu «9 1 § S3 ya O E i<2 1 1 — •s V c E o s tu 2 E E £ .s 0! E 00 CO 3 C 1 * 00 c CO |(M s is? 1 = £ Cos A, e.2 I fj 1 110 j O C <4-l c U £ Sc 1 I <y i T3 c 1 c o3 -C —O —O £5 (4-1 1 s J4 ya O -^ ^j 1 | S CD MO APPENDIX D. GENERIC MAKEFILES FOR NEW MODEL LANGUAGE INTERFACES ###################################################################################### # Title Generic Makefile for a new model-language interface. # # : hie: Makefile # # path: db3 /usr/work/mdbs/NewVersion/CNTRL/TI/LangIF/src/NML/Makefile # ###############################^fli#################################################### LIB= $(HOME)/lib/nml.a HOME=/usr/work/mdbs/NewVersion/CNTRLAn/LangIF LPR= lpr LPRFLAGS= -p AR=ar ARFLAGS= cr Replace NewVersion with the most current version RANLIB=ranlib of MDBS software will be stored. name of MDBS S(LIB): objects rm -f $(LIB) $(AR) S(ARFLAGS) S(RANLIB) $@ $@ */*.o quick: rm-f$(LIB) $(AR) S(ARFLAGS) $(LIB) */*.o $(RANLIB) $(LIB) objects: cd Alloc; make cd Kc; make cd Kfs; make cd Kms; make cd Lil; make clean: cd Alloc; make clean cd Kc; make clean cd Kfs; make clean cd Kms; make clean cd Lil; make clean print: cd Alloc; make print cd Kc; make print cd Kfs; make print cd Kms; make print cd Lil; make print 111 software. This is where the new version ######################### #############M####M######################################## # Tide : # makefile tile: Generic Makefile for compiling all model-language interfaces. # # # path: db3 /usr/work/mdbs/NewVersion/CNTRL/TI/LanglF/makefile # ###################################################################################### SRC = /usr/work/mdbs/NewVersion/CNTRL/TI/LangIF/src/ quick: # cd $(SRC)Com; make make # cd $(SRC)Dli; # cd $(SRC)Dml; make # make cd $(SRC)Dap; make cd $(SRC)Obj; make cd $(SRC)NML; make # # To compile specific mode I- language interfaces, remove the cd $(SRC)Sql; # from of the model-language to be compiled. To model-language interfaces, remove the # in front compile all all the commands under quick: . clean: # cd $(SRC)Com; make clean # cd $(SRC)Dli: make clean # cd $(SRC)Dml: make clean # cd $(SRC)Sql; # cd $(SRC)Dap; make clean # cd $(SRC)Obj; # cd make clean make clean $(SRC)NML; make clean; To delete all object files after compilation, remove the # in print: front of the clean:.. model-language desired under the To print out the source code for a model-lan- # cd $(SRC)Com; make print guage, remove the # cd $(SRC)Dli; make print print: # cd $(SRC)Dml: make print # cd $(SRC)Sql; make print # cd $(SRC)Dap; make print # cd $(SRC)Obj; make print # cd $(SRC)NML; make print 112 . it in front of the commands below REFERENCES [BENS 85] Benson, T. P., and Wentz, G. The Design and Implementation of a L., Hierarchical Interface for the Multilingual Database System, Master's Thesis, Naval Postgraduate School, Monterey, California, June 1985. [BROD89] Brodie, J., and Plauger, Series, Microsoft Press, |DEMU87] Standard C: Programmer's Quick Reference P.J., 1989. The Multi-Lingual Database System - A Paradigm and Test-Bed for the Investigation of Data-Model Transformations, Datalanguage Translations and Data-Model Semantics, Ph.D. Dissertation, The Ohio State University, 1987. Demurjian, S. J., The Implementation of a Network CODASYL - DML Interface for the Multilingual Database System, Master's Thesis, Naval Postgraduate School, Monterey, California, December 1985. EMDI 85] Edmi, [HALL 89] James E., Performance Evaluations of a Parallel and Expandable Database Computer - The Multi-Backend Database Computer, Master's Thesis, Naval Postgraduate School, Monterey, California, June 1989. f [HSIA 89] B., Hall, Hsaio, D. K., and Kamel, Issues, and Solutions", Engineering, Vol. [HSIA 91] Hsiao, D. K., 1, "A No. M. N., IEEE 1, "Heterogeneous Databases: Proliferations, Transactions March Parallel, on Knowledge and Data 1989. Microprocessor-Based Scalable, Database Computer for Performance Gains and Capacity Growth", IEEE Micro, December 1991. [HSIA 92] Hsiao, D. K., "Federated Databases and Systems: Their Data Sharing", [JOHN 78] Johnson, Murray S. C, Hills, VLDB Journal, Part I - A Tutorial on 1992. Yacc: Yet Another Compiler-Compiler, Bell Laboratories, New Jersey, July 1978. [KELL 84] Kelly, A., and Pohl, I., A Book on C - An Introduction to Programming The Benjamin/Cummings Publishing Company, Inc., 1984. [KLOE 85] Kloepping, G. R., and Mack, J. in C, E, The Design and Implementation of a Relational Interface for the Multilingual Database System, Master's Thesis, Naval Postgraduate School, Monterey, California, June 1985. [LESK78] Lesk, H. E., and Schmidt, E., Lex Laboratories, Murray Hills, - A New Jersey, 113 Lexical Analyzer Generator, Bell July 1978. [SCNI 92] Shneiderman, B., Designing the User Interface: Strategies for Effective Human-Computer Interaction, 2nd Company, Inc., 1992. 114 ed., pp. 11, Addison-Wesley Publishing 3 INITIAL DISTRIBUTION LIST Defense Technical Information Center Cameron Station Alexandria, Virginia 22304-6145 Dudley Knox Library Code 052 Naval Postgraduate School Monterey, California 93943 Chairman, Code CS Computer Science Department Naval Postgraduate School Monterey, California 93943 Director Training and Education MCCDC Code C46 1019 Elliot Road Quantico, Virginia 22134-5027 Professor David K. Hsiao Computer Science Department Naval Postgraduate School Monterey, California 93943 Captain Paul A. Bourgeois, USMC 103 Adventure Trail Cary, North Carolina 275 1 115 DEMCO