Patent Grant
6980995
This application is related to the following commonly assigned patent application:
The application, entitled “METHOD, COMPUTER PROGRAM PRODUCT, AND SYSTEM FOR AUTOMATIC CLASS GENERATION WITH SIMULTANEOUS CUSTOMIZATION AND INTERCHANGE CAPABILITY”, filed on Jun. 14, 2002 by Hembry et al., Ser. No. 10/173,521 is incorporated by reference herein. This application will be hereinafter referred to as the “Automatic Class Generation” application.
The present invention relates generally to accessing databases, and in particular, to writing application code to access one or more hierarchical databases.
Hierarchical databases, such as IBM's IMS (Information Management System), are well known in the art. (IMS is a trademark of International Business Machines Corporation in the United States, other countries, or both.) IMS is a hierarchical database management system (HDBMS) with wide spread usage in many large enterprises where high transaction volume, reliability, availability and scalability are of the utmost importance. IMS provides software and interfaces for running the businesses of many of the world's largest corporations. However, companies incorporating LMS databases into their business models typically make significant investments in IMS application programs in order to have IMS perform meaningful data processing particularly tailored to the needs of their respective enterprises. IMS application programs are typically coded in COBOL, PL/I, C, PASCAL, Assembly Language, or Java and are created by programmers with critical skill sets in a programming environment that may be time consuming, inefficient and error prone. (Java is a trademark of Sun Microsystems, Inc. in the United States and/or other countries.)
Physical IMS databases are hierarchic. Each database has a schema defined as a hierarchy or tree of segment types, each of which is defined, in turn, as a collection of fields. This definition of a physical database schema is contained in an IMS control block called a “Database Description” (DBD). A physical IMS database is a simple hierarchy, but multiple physical databases (i.e., hierarchies), may be linked by one or more associations called “logical relationships” which allow new “logical hierarchies” to he defined. A logical hierarchy typically traverses multiple physical hierarchies by crossing one or more logical relationships, and incorporates segments from several databases. Logical hierarchies are defined in “Logical Database Descriptions” (Logical DBDs), and may he processed, for the most part, as if they were simple physical databases. They are somewhat analogous to relational database “views” that are defined on joins of a number of database tables. In addition, “secondary indexes” may be defined for a database, which provide alternate search paths to any segment type in the database hierarchy (logical or physical), and affect the application's view of its data.
Each IMS application program is defined to process one or more physical DBDs or logical DBDs. This definition is contained in another IMS control block called a Program Specification Block (PSB). For each DBD that the program processes, the PSB specifies the subset of the DBD hierarchy that the application is authorized to process, and optionally its authorized level of processing (e.g., Get, Replace, Insert, Delete) for each segment in the subset. This information for each DBD is contained is a structure called a “Program Control Block” (PCB) within the PSB. If the application processes more than one database hierarchy (logical or physical) there will be multiple PCBs in its PSB.
To write an application program, the application developer must understand the application's view of its databases. Access to a database from an IMS application program is performed by calling the IMS call interface and specifying which PCB (i.e., which hierarchy) the call is intended to operate on. The IMS interface defines a number of operations to search and navigate through a hierarchy, and to update, insert and delete segments. The call also specifies the target segment or segments and search arguments that specify positioning in the hierarchy. Search arguments typically contain field name/value pairs or the target segments.
To code the database calls in the application program, the developer needs to know:
Traditionally, when coding an application, the developer gets this information by referring to the source copies of the PSB and DBDs, which are in the form of Assembler Language macros. The PSB source contains macros for each PCB, which names the database (logical or physical). Each PCB contains macros for the segments in that PCB which specify the hierarchic arrangement of the segments, but additional details of each segment and its fields must be obtained from the DBD source. The application developer locates the corresponding source file for that DBD from the DBD name in the PCB The segment macros in the PCB also name then corresponding segment in the DBD's hierarchy, so the developer can locate segment definitions in the DBD. Segment definitions in physical DBD hierarchies contain macros describing at least some of the fields in the segment, with their lengths and offsets. A parameter on the field macro gives an indication of the data type of the field.
If the PCB refers to a logical hierarchy there is another level of indirection. The segment macros in the logical DBDs d(o not contain information on length, offset, and type, but rather refer by name to segment macros in one or more physical DBDs. Thus the developer must follow the name links to the physical DBDs to obtain the needed information.
Another complication arises in that DBDs generally do not contain information about all the fields in a segment. Typically, field macros are only included in physical DBDs for fields that can be used as “search fields” when accessing the database. These are fields that may be referenced in “segment search arguments” of database calls. If the application needs to process other fields in the segments (as it generally will need to do) the developer must get the information from some other source. Often, layouts of fields within segments can be captured from language structures of existing applications, such as COBOL copybooks, and can be included into new application programs.
The net result of all this is that in order to get a complete picture of the data, application developers must refer to and merge information from several sources: the PSB, possibly one or more logical DBDs, physical DBDs, and existing language source for the segments being processed. This process is skill intensive, complex and error prone, especially for large databases with logical relationships.
IMS applications written in the Java language involve even more complexities. IMS Java applications access IMS databases using a limited subset of the SQL92 query language and JDBC (Java Database Connectivity), the standard Java APIs for accessing relational databases. This contrasts with applications written in other languages, which must use the IMS defined call interface. When coding an IMS Java application, the application developer needs all the same information listed above for developers in other languages. In addition, however IMS Java allows an application to refer to PSBs, PCBs, Segments, and Fields, using Java-style identifiers rather than the 8-character names used by the PSB, PCB, Segment and Field, macros. The developer must know these Java alias names for each entity. IMS Java presents data to the application using the broad range of standard JDBC data types, and to process a field the developer must also know its JDBC data type.
Neither the Java-style aliases nor the JDBC data type are present in the PSB or DBD. For its internal operation IMS Java requires a “metadata class” to be created by the Java programmer which summarizes all of the information about database hierarchies, segments and fields normally found in the PSB, DBDs, as well as the Java alias names and data types, and details of additional fields (not defined in the DBD).
A developer of an IMS Java application could in theory use this metadata class (or its java source file) as a comprehensive reference source for understanding the data view of the application. However, this metadata class is optimized in its organization for consumption by the IMS Java system code and, accordingly, is greatly lacking in its suitability for use by a human developer.
Accordingly, there is a great need for an automated and integrative approach to collecting pertinent information from disparate sources and presenting the information to an application programmer in a form suitable for humans and conducive to efficient development of application source code for accessing hierarchical databases. Furthermore, this information should be comprehensive to the extent that it obviates the need to consult any other database source materials for information required to build the hierarchical database access code.
To overcome these limitations in the prior art briefly described above, the present invention provides a method, program product and apparatus for automatically generating a hierarchical database schema report to facilitate writing application code for accessing a hierarchical database. A database definition, logical database view, extended field definition and control statement information are accessed to build an in-memory representation of selective information contained therein. Utilizing this in-memory representation, a hierarchical database schema report is automatically generated wherein this hierarchical database schema report may be used to write application code to access the hierarchical database without further need to utilize the database definition, the extended field definition, the logical database view or any combination thereof. A utility program performing the above computer implemented steps is hereinafter referred to in this specification as an “integrated hierarchical schema constructor”.
In another embodiment of the present invention, the above-described integrated hierarchical schema constructor may be provided as a computer system. The present invention may also be tangibly embodied in and/or readable from a computer-readable medium containing program code (or alternatively, computer instructions.) Program code, when read and executed by a computer system, causes the computer system to perform the above-described method.
A novel method for writing application code for accessing a hierarchical database on a computer system is also disclosed. An integrated hierarchical schema constructor is invoked to automatically generate a hierarchical database schema report wherein the hierarchical database schema report comprises information from at least one database definition, at least one logical database view, at least one extended field definition and at least one control statement. The hierarchical database schema report is utilized to write the application code without further utilizing the database definition, without further utilizing the extended field definition and without further utilizing the logical database view, whereby the application code may be used to access the hierarchical database.
In this way, the arcane, time-consuming and error prone process of reading legacy data structures formatted for machine consumption can be eliminated dulling the process of building application program code for accessing hierarchical databases. Utilizing, a single invocation of an integrated hierarchical schema constructor, a hierarchical database schema report may be generated to present an organized and comprehensive report for enhancing the efficiency of application program development where hierarchical database access is required.
Various advantages and features of novelty, which characterize the present invention, are pointed out with particularity in the claims annexed hereto and form a part hereof. However, for a better understanding of the invention and its advantages, reference should be made to the accompanying descriptive matter, together with the corresponding drawings which form a further part hereof, in which there is described and illustrated specific examples in accordance with the present invention.
The present invention is described in conjunction with the appended drawings, where like reference numbers denote the same element throughout the set of drawings:
The present invention overcomes the problems associated with the prior art by teaching a system, computer program product, and method for) the automatic generation of a hierarchical database schema report to facilitate hierarchical database application program development. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. Those skilled in the art will recognize, however, that the teaching contained herein may be applied to other embodiments and that the present invention may be practiced apart from these specific details. Accordingly, the present invention should not be limited to the embodiments shown but is to be accorded the widest scope consistent with the principles and features described and claimed herein. The following description is presented to enable one of ordinary skill in the art to make and use the present invention and is provided in the context of a patent application and its requirements.
Referring now to
Database definition 220 represents a physical description of a hierarchical database, such as a DBD (Database Description) in the case of an IMS database. This information typically comprises descriptions of the hierarchical segments, their hierarchical relationships, and searchable fields within the segments.
Database logical view 210 represents a logical view of one or more hierarchical databases, as required for a particular application using the database. This information typically comprises segments within the physical database that the application is authorized to process and the hierarchical relationship of those segments. In the case of IMS, this logical view of information is contained within a PSB, which is in turn comprised of one or more PCBs, each of which encompasses one or more logical views applied to single or multiple IMS databases.
Since the database definition typically contains field information for just the searchable fields, extended field definitions 230 are also input to integrated hierarchical schema constructor 290. These extended field definitions provide additional segment mapping detail and are typically contained with high-level language constructs, such as COBOL copybooks.
Optional control statements 240 may also input to integrated hierarchical schema constructor 290. These control statements direct the processing flow according to the desired features and functions to be performed. Optionally, these control statements may also be used, in conjunction with generating object classes 260, to customize an object class to take advantage of features within Java, or other object oriented programming environment, that are not available within the legacy environment. For example, Java alias names may be established for any segment or field; and the name can be any length, as required, to enable the name to convey information about the named entity. Reasonable naming conventions improve programmer efficiency and reduce programmer errors. Additionally, a generated report and object class can be customized with new field names to accommodate new features or application extensions.
Integrated hierarchical schema constructor 290, utilizing selected information from inputs 210, 220, 230 and 240 outputs an hierarchical database schema report 270 in a structured and user friendly format to be utilized by an application programmer to efficiently and easily access the information required to write code that accesses hierarchical data. Furthermore, this information is comprehensive in that it obviates the need to consult other database source materials in collecting the information required to write code that accesses hierarchical data In conjunction with the generation of hierarchical database schema report 270, integrated hierarchical schema constructor 290 may optionally generate object classes, 260, as more fully disclosed in the related “automatic class generation” application identified supra.
Additionally, integrated hierarchical schema constructor 290 may optionally generate an XMI output stream 280, representative of all metadata encapsulated within object classes 260, as more fully disclosed in the related “automatic class generation” application identified supra. The XMI output stream 280 may be utilized by other applications and tools to regenerate object classes 260 into an alternative form appropriate for a particular application's usage. Furthermore, integrated hierarchical schema constructor 290 optionally outputs trace data 250. This information may be utilized for status and debugging purposes, as well as for facilitating additional application development.
Generally, the novel methods disclosed herein may be tangibly embodied in and/or readable from a computer-readable medium containing the program code (or alternatively, computer instructions), which when read and executed by computer system 100 causes computer system 100 to perform the steps necessary to implement and/or use the present invention. Thus, the present invention may be implemented as a method, an apparatus, or an article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. The term “article of manufacture” (or alternatively, “computer program product”) as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. Examples of a computer readable device, carrier or media include, but are not limited to, palpable physical media such as a CD ROM, diskette, hard drive and the like, as well as other non-palpable physical media such as a carrier signal, whether over wires or wireless, when the program is distributed electronically.
Referring now to
Dealers carry car types, each of which has a corresponding Car Model segment 320. A Car Model segment may contain fields such as the car model (e.g. Nissan Maxima), and a model description. Other segments include Order 330, Sales 340 and Stock 350 representing information pertaining to orders, sales and inventory, respectively, for each car model, with additional fields defined appropriate to their usage within an application.
Referring now to
An automatically generated Java Class corresponding to the data depicted in
This stands in stark contrast to hierarchical database schema report 1500,
Continuing with
Next, in step 815, a PSB source file is read. The PSB is the IMS data structure that represents the logical view of the hierarchical database The control statement specifies the name of the PSB to be read and processed, and may also optionally specify a Java name to be associated with this PSB. Continuing with step 820, the PSB source macro statements are parsed and selected information accumulated into the in-memory model representing the hierarchical database metadata.
In step 825, the source file of a referenced DBD is read and in step 830 the DBD source macro statements are parsed and selected information accumulated into the in-memory model representing the hierarchical database metadata. The in-memory model captures all information related to segments and fields and their hierarchical relationships. In step 835, a test is made to determine if additional DBDs are referenced by the PSB. If so, control passes back to step 825 where processing continues as discussed supra. Otherwise, in step 840, a test is made to determine if additional PSBs are associated with the PSB control statement currently being processed. This may occur where the PSB control statement incorporates a generic name, such as a “wild card” naming convention, wherein all PSBs matching the name form are to be processed. If one or more PSBs remain to be processed, control passes back to step 815 where processing continues as discussed supra.
Returning now to step 840, if there are no more PSBs to process for this PSB control statement, then processing continues with step 845, where a test is made to determine if additional PSB control statements exist. If so, control returns to step 810 and processing continues as discussed supra. Otherwise, in step 850 control passes to the beginning of flow diagram 900 of FIG. 9. Each PSB is reflected individually in the model, with its segments and fields; but if the PSBs share logical or physical databases, only a single instance of each database is added to the in-memory model and shared by the referencing PSBs.
Referring now to
First, step 910 receives control from step 850 of flow diagram 800, FIG. 8. Processing continues with step 915, where a test is made to determine if extended field definitions are present, such as COBOL copybooks. Those of ordinary skill in the art will recognize that this information may be provided in a transformed form produced by an importer, such as an XMI data stream conforming to the HLL language metamodel, or any other intermediary data form. If extended field definitions are present then, in step 920, this additional field information is merged into the in-memory model before proceeding to the test at step 925. An extended field definition is related to a particular DBD and physical segment through a segment control statement. Fields found in the extended field definition that are not yet in the model are added to the segment with their field name, offset, length and dart type. It, however, a field in the extended field definition coincides (same starting offset and length) with an existing field in the model, then a new field is not added to the model. Instead, the Java name and the data type in the existing model field are set to the name and data type of the field in the extended field definition. Those of ordinary skill in the art will recognize that many detailed design decisions are possible within the framework of the teachings contained herein. For example, in another embodiment, an error could be generated when extended field definitions coincide with existing fields within the in-memory model.
Returning now to step 915, if extended field definitions are not present, processing continues with step 925 where a test is made to determine the presence of additional control statements. If additional unprocessed control statements exist, the processing continues with step 930, otherwise control passes to step 935. Step 930 merges additional control statement information into the in-memory model.
A ‘PSB’ control statement type allows the user to specify an alias name for a PSB, which determines the name of the generated IMS Java class. A ‘PCB’ control statement type allows the user to specify an alias name for an existing PCB within a PSB. A ‘SEGM’ control statement type allows the user to specify an alias Java name for an existing logical or physical segment. A ‘field’ control statement type allows the user to specify a field in a specified DBD and/or a physical segment, either by its starting offset and length, or by its 8-character IMS name. A new field object is created in the model if not already present. If the field is coincident with an existing field (same 8-character name, or same starting offset and length) then the information in the existing field is overridden by the control statement information. An ‘XDFLD’ statement allows an alias to be provided for an IMS secondary index field already specified within the DBD. A ‘field’ type control statement takes precedence over extended field definitions where conflicts occur.
Processing continues from step 930 to step 935, where a Model Adjustment Report is generated summarizing status information accumulated during the building of the in-memory model (the Model Adjustment Report is not shown). In step 940, control passes to the beginning of flow diagram 1000, FIG. 10.
Referring now to
Referring now to
Those of ordinary skill in the art will recognize that the generation of a report may be accomplished in a variety of ways, including building a report in memory and writing it out upon completion, or writing the report as pieces are completed. Furthermore, it is also recognized by those of ordinary skill in the art that the writing of a report may be accomplished by displaying the report on a screen, writing the report to a file, or printing a hardcopy report. These and other known methods of generating reports are anticipated by the present disclosure.
In step 1160, PCB processing occurs for those PCBs associated with the current PSB, as shown in more detail in flow diagram 1200,
Referring now to
Referring now to
Referring now to
Integrated hierarchical schema constructor 290 automatically determines field layouts for segments in logical hierarchies that may be “concatenated segments” (i.e., segments containing the data from two or more underlying physical segments in physical hierarchies). It also allows for hierarchy inversion resulting from the use of secondary indexes. In fact the report reflects all options available to Database Administrators when defining IMS databases, including the following situations (among others):
1) Concatenated segments, involving real or virtual logical children
2) Noncontiguous key fields in virtual logical children
3) Segments with secondary indexing field descriptions (i.e., XDFLD macros)
4) System related fields (e.g., /SX and /CK fields)
5) PSBs specifying secondary processing sequence
6) Secondary indices processed as stand-alone databases
7) PSBs specifying field-level sensitivity
Continuing with step 1425, a test is made to determine if an alias was specified for the current field. If so, in step 1420, the alias name is selected to represent the current field; otherwise, in step 1430, the IMS field name is used.
Continuing with step 1435, a test is made to determine if the current field is defined within the DBD. If the current field is not defined in the DBD, then this field is generated in step 1437 without any annotations reflecting, special field use (e.g. as a primary key, secondary key or search field) and processing continues with step 1465. Otherwise, the current field is defined in a DBD and, accordingly, processing continues with step 1445 where a test is made to determine if the current field is defined in an XDFLD macro. If so, in step 1440, the current field is generated with an annotation designating the field as a “secondary key field” and processing continues with step 1465. Otherwise, at step 1455 a test is made to determine if the current field is a primary key. If so, in step 1460 the current field is generated with an annotation designating the field as a “primary key field”; otherwise, in step 1450, the current field is generated with an annotation designating the field as a “search field”.
Continuing with step 1465, a test is made to determine if there is another field to process for this segment. If so, control returns to step 1405, discussed supra. Otherwise, all fields for the current segment have been processed and control returns, at step 1470, to step 1365 of flow diagram 1300, FIG. 13.
In the first instance, field 1521 is generated and in turn, with each field iteration, fields 1522 and 1523 are likewise generated. On subsequent calls to the field processing routine, the fields for segments 1530 through 1560 are likewise generated.
Taken in combination flow diagram 800, 900, 1000, 1100, 1200, 1300 and 1400 in conjunction with supporting diagrams and detailed descriptions provide for enhanced programmer productivity and improved code quality by automatically generating a hierarchical database schema report. This report may be used by application programmers in place of complex IMS source macros and object classes with arcane syntax to obtain essential information required to write code that accesses hierarchical data. Although flow diagrams 800 through 1400 use IMS and Java as exemplary platforms, those of ordinary skill in the art will appreciate that the teachings contained herein apply to any hierarchical database and any programming language environment. References in the claims to an element in the singular is not intended to mean “one and only” unless explicitly so stated, but rather “one or more.” All structural and functional equivalents to the elements of the above-described exemplary embodiment that are currently known or later come to be known to those of ordinary skill in the art are intended to be encompassed by the present claims. No claim element herein is to be construed under the provisions of 35 U.S.C. § 112, sixth paragraph, unless the element is expressly recited using the phrase “means for” or “step for.”
While the preferred embodiment of the present invention has been described in detail, it will be understood that modifications and adaptations to the embodiment(s) shown may occur to one of ordinary skill in the art without departing from the scope of the present invention as set forth in the following claims. Thus, the scope of this invention is to be construed according to the appended claims and not limited by the specific details disclosed in the exemplary embodiments.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4873625 | Archer et al. | Oct 1989 | A |
| 5737597 | Blackman et al. | Apr 1998 | A |
| 5799313 | Blackman et al. | Aug 1998 | A |
| 5924101 | Bach et al. | Jul 1999 | A |
| 6026408 | Srinivasan et al. | Feb 2000 | A |
| 6044217 | Brealey et al. | Mar 2000 | A |
| 6049655 | Vazirani | Apr 2000 | A |
| 6085188 | Bachmann et al. | Jul 2000 | A |
| 6085198 | Skinner et al. | Jul 2000 | A |
| 6128611 | Doan et al. | Oct 2000 | A |
| 6202069 | Blackman et al. | Mar 2001 | B1 |
| 6236994 | Swartz et al. | May 2001 | B1 |
| 6341288 | Yach et al. | Jan 2002 | B1 |
| 6345256 | Milsted et al. | Feb 2002 | B1 |
| 6529914 | Doan et al. | Mar 2003 | B1 |
| 6665677 | Wotring et al. | Dec 2003 | B1 |
| 6754671 | Hrebejk et al. | Jun 2004 | B2 |
| 6845376 | Johnson | Jan 2005 | B1 |
| 20010016843 | Olson et al. | Aug 2001 | A1 |
| 20020029375 | Mlynarczyk et al. | Mar 2002 | A1 |
| 20020038335 | Dong et al. | Mar 2002 | A1 |
| 20020038450 | Kloppmann et al. | Mar 2002 | A1 |
| Number | Date | Country |
|---|---|---|
| 1122653 | Oct 1993 | EP |
| Number | Date | Country | |
|---|---|---|---|
| 20040019600 A1 | Jan 2004 | US |
