|
Claims  |
|
|
We claim:
1. A method of data conversion for use with a digital data processing
system of the type having
first file storage means for storing a first relational database, said
first relational database including a plurality of digital records
representing information used by a first selected version of a computer
program,
second file storage means capable of storing a second relational database,
said second relational database including a plurality of digital records
representing at least a portion of said information for use by a second
selected version of said computer program,
said data conversion apparatus comprising
A. a file management step for generating and storing in said second
relational database a plurality of digital records for use by said second
selected version of said computer program, wherein each such generated
digital record includes at least selected information from a corresponding
digital record of said first relational database,
B. said file management step including a conversion step for generating
said digital records for storage in said second relational database by
converting at least selected information contained in the corresponding
digital record of said first relational database, wherein said conversion
is a function of (i) the identity of said first selected version of said
computer program, and (ii) the identity of said second selected version of
said computer program
C. said conversion step includes the steps of
accessing a selected entry in a table of entries, each storing a
procedure-representative signal representative of procedure for converting
information contained in at least a component of a digital record of said
first relational database to information contained in at least one
corresponding component of a digital record of said second relational
database, said entry being selected as a function of the identities of
said selected versions of said computer program with which said first and
second relational databases are associated, and
ii) executing the procedure represented by the procedure-representative
signal stored in said selected entry to perform said conversion.
2. A data conversion method according to claim 1, including
A. a table-loading step for storing, in at least one said table entry, an
identity of a subroutine of steps for converting information contained in
at least a component of said digital record of said first relational
database to information contained in at least one corresponding component
of said digital record of said second relational database, and
B. said execution step comprises means for executing said subroutine for
executing said procedure to perform said conversion.
3. A data conversion method according to claim 2, wherein said execution
step further comprises the step of configuring a central processing unit
to execute a subroutine identified in one of said table entries to perform
a conversion.
4. Data conversion apparatus according to claim 1 wherein said first and
second file storage means are disposed remotely from one another, and
wherein said file management step comprises
A. a data transfer step for converting said plurality of digital records of
said first relational database to a standard file transfer format for
transfer to said conversion means,
B. said conversion step includes disassembler means responsive to receipt
of said plurality of digital records of said first relational database in
said standard file transfer format for identifying information contained
in at least selected components of said digital records thereof.
5. Data conversion apparatus for use with a digital data processing system
of the type having
first file storage means for storing a first relational database, said
first relational database including a plurality of digital records
representing information used by a first selected version of a computer
program,
second file storage means capable of storing a second relational database,
said second relational database including a plurality of digital records
representing at least a portion of said information for use by a second
selected version of said computer program,
said data conversion apparatus comprising
A. file management means, coupled to said first and second file storage
means, for generating and storing in said second relational database a
plurality of digital records for use by said second selected version of
said computer program, wherein each such generated digital record includes
at least selected information from a corresponding digital record of said
first relational database,
B. said file management means includes conversion means for generating said
digital records for storage in said second relational database by
converting at least selected information contained in the corresponding
digital record of said first relational database, wherein said conversion
is a function of (i) the identity of said first selected version of said
computer program, and (ii) the identity of said second selected version of
said computer program,
C. said conversion means comprising
i) a plurality of table entry means, each for storing a
procedure-representative signal representative of a procedure for
converting information contained in at least a component of a digital
record of said first relational database to information contained in at
least one corresponding component of a digital record of said second
relational database,
ii) execution means for accessing a selected said table entry means as a
function of the identities of said selected versions of said computer
program with which said first and second relational databases are
associated, and for executing the procedure represented by the
procedure-representative signal stored therein to perform said conversion.
6. Data conversion apparatus according to claim 5, wherein
A. at least one said table entry means comprises means for storing as said
procedure-representative signal an identity of a subroutine of steps for
converting information contained in at least a component of said digital
record of said first relational database to information contained in at
least one corresponding component of said digital record of said second
relational database, and
B. said execution means comprises means for executing said subroutine for
executing said procedure to perform said conversion.
7. Data conversion apparatus according to claim 6, wherein said execution
means further comprises means for configuring a central processing unit
coupled with said second file storage means to execute said subroutine for
executing said procedure to perform said conversion.
8. Data conversion apparatus according to claim 5 wherein said first and
second file storage means are disposed remotely from one another and
wherein said file management means comprises
A. data transfer means coupled to said first file storage means for
converting said plurality of digital records of said first relational
database to a standard file transfer format for transfer to said
conversion means,
B. said conversion means includes disassembler means responsive to receipt
of said plurality of digital records of said first relational database in
said standard file transfer format for identifying information contained
in at least selected components of said digital records thereof. |
|
|
|
|
Claims  |
|
|
Description  |
|
|
AUTHORIZATION
A portion of the disclosure of this patent document contains material which
is subject to copyright protection. The copyright owner has no objection
to facsimile reproduction by anyone of the patent document or the patent
disclosure, as it appears in the Patent and Trademark Office patent file
or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND
This invention relates to the conversion of digital data transferred
between relational databases and more particularly, for example, to the
conversion of data transferred between computer systems running different
versions of the same software.
A localized working environment with multiple computer systems typically
runs a single version of any given software package, thereby making simple
the transfer and sharing of data between the systems. Thus, for example, a
company that uses computers to monitor and control manufacturing
operations at a single site will generally run the very same
computer-aided manufacturing software package on each of its computers. In
the event data is transferred from one of those systems, it need not be
converted for use on another system.
In a non-localized environment, however, sharing of data between multiple
computer systems can be problematic. Companies having geographically
diverse facilities may run different versions of a given software package
at each site. For example, a multinational company may employ a first
version of a software package in connection with its operations in France,
while using a second version of that same package for its operations at a
sister facility in Germany. While it may be desirable to transfer data
between these facilities, differences in the structure of the underlying
data files may make such a transfer difficult if not virtually impossible.
According to one prior art solution, data transferred between computer
systems (e.g., between the French and German sites) would be printed at
one site and manually re-entered at the other. This results in time delay,
loss of man-hours and a corresponding loss in productivity. According to
another such solution, a programmer would be employed to write a
special-purpose computer to convert records used at one site to those used
at the other site. The difficulties in finding a programmer with
sufficient knowledge of the data structures and of the local system and
software may itself prove to be a daunting task.
In view of the foregoing, an object of the invention is to provide improved
methods and apparatus for sharing data and, more particularly, for sharing
data used by different software versions of a given software package.
Another object of the invention is to provide improved methods and
apparatus for converting data transferred between computer systems
employing different software versions.
Still another object of the invention is to provide such improved methods
and apparatus that are more cost effective, and that are compatible with
preexisting computer hardware.
Yet another object is to provide a system for convening data transferred
between relational databases.
Other general and more specific objects of this invention will in part be
obvious and will in pan be evident from the description and drawings which
follow.
SUMMARY OF THE INVENTION
The aforementioned and other objects are achieved by the invention which
provides a data conversion apparatus and method for translating
information stored in a first relational database to that stored in a
second relational database and, more particularly, for translating
information in a relational database used by a first selected version of a
computer program into information stored in a second relational database
for use by a second selected version of a computer program. The apparatus
and method thus allow the sharing of data by computer systems running
different versions of a given software package.
According to one aspect of the invention, a data conversion apparatus
includes a first file storage element for storing a first relational
database (i.e., a spreadsheet-like collection of information) having a
plurality of digital records (each constituting, typically, a collection
of fields of data relating to a single entity or transaction similar to a
row in a spreadsheet) representing information used by a first selected
version of a computer program, and a second file storage element capable
of storing a second relational database representing at least a portion of
the information from the first database for use by a second selected
version of the computer program. The apparatus further includes a file
management element that converts information from the first database for
storage in the second. That conversion is performed as a function of the
identities of the first and second selected versions of the computer
program (e.g., as a function of their names and respective version
numbers).
According to another aspect of the invention, the file management element
includes table entry elements that identify, in table-like form, the
procedures for translating individual records or fields of information
stored in the first relational database into a form compatible with the
second computer program version. For example, a record structure contained
within the first relational database contains information used by a first
version of a computer program, e.g., version 2.0. These version
2.0-compatible records are processed by the file management element for
translation into record structures that are compatible with a second
version of the computer program, e.g., version 3.0, and stored within the
second relational database.
In a related aspect of the invention, each file management table entry
stores the names of software subroutines, each of which executes steps
necessary for converting data between the respective formats.
In other related aspects of the invention, an execution element accesses a
given entry listed in a selected table entry element based on the
respective identities of the versions (e.g., the version numbers) of the
computer programs.
In yet another aspect of the invention, the first and second file storage
elements (along with their respective databases) reside remotely from one
another. The file management element includes a data transfer element and
a disassembler element. The data transfer element converts records in the
first database, prior to transfer to the remote database, into a standard
transfer file format. The disassembler element disassembles the records,
subsequent to transfer, component structures (e.g., fields) that are
subsequently processed by the conversion subroutine.
Still other aspects of the invention provide a method for data transfer and
conversion paralleling the operations described above.
These and other aspects of the invention will in part be obvious and
evident from the detailed description and the drawings which follow.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing and other aspects of the invention may be more fully
understood from the following description, when read together with the
accompanying drawings in which:
FIG. 1 illustrates data and control signal pathways utilized by a preferred
data conversion apparatus of the present invention;
FIG. 2 is a schematic block diagram of a preferred data conversion
apparatus according to the invention;
FIG. 3 depicts a still more detailed perspective of a preferred data
translator of FIG. 2 according to a preferred embodiment of the invention;
FIG. 4 depicts components of a record structure used in connection with a
preferred data transfer process in an apparatus according to the
invention;
FIGS. 5 through 7 depict a flowchart of a preferred data conversion process
according to the invention.
DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENT
FIG. 1 illustrates data and control signal pathways utilized by a preferred
data conversion apparatus of the present invention. The system 10 includes
a remote computer 12, a file management element 18 (referred to as an
"enterprise manager"), and a local computer 24, coupled as shown. Although
the illustration shows two computer systems, those skilled in the art will
appreciate that the teachings herein can be applied to the conversion of
information transferred between more computer systems, as well as the
conversion of information between differing versions of a selected program
residing on a single computer system.
Referring to the drawing, the remote computer 12 communicates to the
enterprise manager 18 a signal 13 representative of the name of a selected
program for which data is to be converted and the version of that program
used by the remote computer 12. The remote computer 12 also communicates
to the enterprise manager 18 at least selected data 14 to be converted.
The local computer 24 likewise communicates to the enterprise manager 18 a
signal 19 representative of the identity of the version of the program
being used by that computer 24.
The enterprise manager 18 responds to the information provided by signals
13 and 19 by converting the information represented by signal 14 into data
having a format for use by the second version of the program on the remote
computer. That converted data is communicated to the remote computer as
data signal 20.
Computers 12 and 24 preferably comprise conventional general-purpose
computers that are programmed, operated and adapted with an enterprise
manager 18 in accord with the teachings below. Those skilled in the art
will appreciate that, although the discussion of the illustrated
embodiment herein is directed to the conversion of data transferred
between two versions of a given program, those teachings are equally
applicable to the conversion of data transferred between any relational
databases, or the like, having known file structures.
FIG. 2 depicts a schematic representation of the data conversion apparatus
according to a preferred embodiment of the invention. The system 10
includes a remote computer 12 having a dedicated enterprise manager 28,
and a local computer 24 having a dedicated enterprise manager 36, as
shown. Remote computer 12 has a data storage unit 26 that includes a first
relational database for storing data used and generated by the first
version of the selected program. The first relational database is
constructed in a manner conventional to the art (as adapted in connection
with the teachings below) and comprises, e.g., a "flat" arrangement of
data items having a spreadsheet-like format. For example, the arrangement
can have a table-like configuration using record structures as the table
rows.
Data records contained within the relational database are preferably
transferred from the data store 26 to the dedicated enterprise manager 28
which prepares those records for transfer to the local computer system 24.
For this purpose, the enterprise manager 28 includes a packing element 30
for converting each record 27 from data store 26 to a generic data
transfer format. In a preferred embodiment, that conversion includes
padding each record with zero's, blanks, or other filler data, thereby
padding the record to a designated record length, e.g., 256 bytes. Such a
packed record 60 is depicted in FIG. 4. The record 60 includes n fields,
labeled FIELD 1, FIELD 2, . . . FIELD N, and further includes packing
space 62. Those skilled in the art will of course appreciate that other
conversions may include re-arrangement of fields within each data record,
or collation of like data fields from all records.
Moreover, enterprise manager 28 transfers packed records 32, along with the
signal 13 reflecting the name and version of the selected program, to the
dedicated enterprise manager 36 of the local computer 24. That transfer is
preferably performed electronically via network interconnect, bus or
modem, but can also be accomplished via exchange of diskettes, tapes or
other physical storage medium.
Illustrated local computer 24 includes a data storage unit 38, similar to
the data storage unit 26 of the remote computer 12, for storing a second
relational database containing a collection of data records in a format
usable by that version of the selected program running in the second
computer
The local enterprise manager 36 receives signal 13 from remote enterprise
manager 28 and uses the information presented to determine how to convert
data in records 32 for storage in data store 38. As further shown in the
illustration, a status signal 34 can be communicated between the remote
manager 28 and the local manager 36 for purposes of exchanging information
regarding the status of any given data transfer and conversion.
The local enterprise manager 36 includes a disassembler, or unpacker,
element 40 for stripping from records 32 extraneous information (e.g.,
filler) to reduce those records to their fundamental components, or fields
42, as described above.
A conversion element or translator 44 translates each such field 42 into a
format compatible with the version of the selected computer program
resident on the local computer. The fields, once converted, are collated
into records 46 and stored within the second relational database within
data storage unit 38. The conversion of record 32 into a record 46
compatible with the second computer program version, can be more fully
understood with reference to FIG. 3.
It will further be appreciated, that although FIG. 2 illustrates the local
manager 36 as having the disassembler 40 and the translator 44, and the
remote manager 28 as having the packer 30, each manager can include a
packer 30, disassembler 40 and translator 44--thus, facilitating
conversions in both directions.
FIG. 3 depicts the translator 44 of FIG. 2 according to a preferred
embodiment of the invention. The translator 44 includes a collection of
table elements 52A-52E. Each table corresponds to a selected program for
which transferred data is to be converted and includes entries that are
indexed by the FROM version signal 13 and the TO version signal 50. Each
entry stores the name (or address) of a procedure-representative signal
representative of a procedure that converts information stored within
field 42 sent to and received by the disassembler 40 into information
contained within field 54 that is compatible with the local version of the
computer program. With respect to the example given above, where the FROM
version signal 13 represents version 2.0 of a computer program and the TO
version signal represents version 3.0, the location within a selected
table element corresponds to table entry Z, as illustrated.
Referring to the drawing, entry Z preferably stores the name or address of
a selected conversion subroutine for converting each field 42 into field
54. Execution of subroutines via identification of their respective
software names or addresses is known in the art and need not be described
here. Such a conversion subroutine may, for example, convert a French
franc-based amount contained in a data field used by the first version of
the program (on remote computer system 28) to a German deutschemark-based
amount for use by the second version of the program (on the local computer
system 24).
FIGS. 5, 6 and 7 are flowcharts showing the transfer of information between
the local and remote computer systems (12, 24, FIG. 1), as well as the
invocation of individual processor programs, by a preferred system for
conversion of transferred data according to the invention.
Referring to FIG. 5, in step 74, applications program 72 executing on local
system 72 performs several steps, including checking whether the
application is "multi-site" 76, generating a communication entry (CE)
signal 78, and releasing a held CE 82. In step 76, the local system
processor invokes the application program 74 to determine whether the
application needs to transfer data between "sites" (e.g., between local or
remote databases). In one mode, if the application does not need to
transfer data, the processor discontinues executing the applications
program. However, if the processor determines that the application needs
to transfer data, it generates a CE number (see step 78) and returns to
the application program its identity. Step 80 stores the CE signal
generated in step 78 pending identification of the associated data to be
transferred. Once the processor identifies the data, the CE signal and the
corresponding data are "tied" together, e.g., the application associates
the generated CE number with the data.
With further reference to step 80, the local system 72 stores the generated
CE signal in a general communications file (GENCOM). The general GENCOM
file alerts the application that data is to be transferred from the local
system 72 to another yet undesignated site. Thus, once the system
identifies the specific site to which data is to be transferred, the
system generates a specific CE corresponding to that site. For example, if
the data transfer is to occur between remote databases, the system
generates a remote communications CE (REMCOM) for that transfer.
Conversely, if the data transfer is to occur between local databases, the
system generates a local communications CE (LOCCOM). Although the
illustrated flowcharts depict the transfer of data between a local and
remote system, the illustrated steps are similarly applicable to the
transfer of data between resident databases of a single system.
During the transfer of data to the remote system 102, the local system
generates a REMCOM CE corresponding to the transfer of data to the remote
site. The application attaches the CE to the data transferred between
sites. However, the data transferred with the REMCOM CE is a copy of the
data associated with the CE located in GENCOM, and not the original data
associated with the GENCOM CE.
In step 82, the CE generated in step 78 is released via a call to GENCOM
(see step 84). Then, in steps 86 and 88, the processing unit of the remote
system processor calls a selected initialization program, which checks the
various target systems located in the applications source history file to
identify all the "sites" involved in the data transfer.
Further in accord with the above description, steps 86 through 90 create
the CE's and mark or denote the data to be transferred with a
corresponding transfer number, as described above. Step 88 then actuates
step 90 by requesting step 90 to preferably write the CE's associated with
the data to the local communications processor and from the remote
communications processor. It will be appreciated that step 88 is
program/FROM/TO signal specific, and that the step is synonymous with the
data flow between the data storage unit 26 and the packer 30 of FIG. 2.
Once step 88 calls the data records, step 90 generates either a local or
remote CE and stores the CE as "held" (see step 80) during the initial
record call. The processor then creates a copy of the data and marks it
with the appropriate CE number. Subsequently, the CE is released upon any
subsequent call to the local processor. This sequence of steps ensures
that the system locates and marks the appropriate data with the correct CE
number, and that the data can be identified for transfer to the remote
system.
Preferably, step 90 performs the foregoing call functions. First, the
processor generates the remote CE and stores the CE as "held" (see step
80). Then, secondly, a subsequent call releases the held CE, signifying
that the corresponding transfer data has been located and marked. In step
90, the system generates a LOCCOM or REMCOM record (see steps 92,94)
depending upon whether data is being transferred between local databases
or remote databases. Those of ordinary skill will also understand that
since centralized distribution requires that the local processor generate
only remote CE's, the source data files are at system-level and, thus,
already exist locally.
FIG. 6 depicts a continuation of the flowchart of FIG. 5 detailing the
processing steps performed on a REMCOM record. Steps 92-100 represent the
transfer of data between the local and remote computers illustrated in
FIGS. 1 and 2. Further, the steps preferably depend upon the
program/FROM/TO signals 13,13,50. In step 94, the local system 72
processes the REMCOM record transferred from the data storage unit 26 to
the packer 30, and writes a LOCCOM record to the remote system 102. The
LOCCOM record sent by the local system 72 instructs the remote system to
convert and upload the data. Additionally, step 94 invokes the sending
transfer program 96 for transferring the LOCCOM record to a remote data
transfer file 100, where it is preferably stored in separately allocated
memory storage space.
The steps 102-106 of FIG. 7 illustrate the transfer and receipt of data by
the remote system 102. The remote system 102, once the LOCCOM record is
received, invokes the receiving transfer program 102 to update the data
transfer files 100 into system or entity files 106. Those of ordinary
skill will appreciate that this transfer corresponds to flow of data
between the translator 44 and the data storage unit 38 of FIG. 2.
It will also be appreciated that although the present invention has been
described with regard to the conversion of data transferred between two
remote systems, the principles described herein are similarly applicable
to the consolidation of data from multiple databases.
A still more complete understanding of the structure and operation of a
preferred system according to the invention may be attained by reference
to the software listings provided in the Appendices hereto. The software
communication tools referred to in the listings can be any of several
commercially available and commonly know such tools. Preferred such tools
are designed by the assignee hereof. Those skilled in the art will
appreciate that the listed programs are also used in conjunction with
other software and hardware tools (e.g., operating systems and modems)
commonly available and known to those of ordinary skill in the art.
The foregoing describes a preferred system for converting data for use by
two or more versions of a computer program. Those skilled in the art will
appreciate that the embodiment described above is by way of example only,
and that other embodiments incorporating modifications thereto fall within
the scope of the invention. Thus, as noted above, whereas the illustrated
embodiment herein is directed to the conversion of data transferred
between two versions of a given program, those teachings are equally
applicable to the conversion of data transferred between any relational
databases, or the like.
##SPC1##
* * * * *
|
|
|
|
|
Description  |
|