 |
Description  |
|
|
FIELD OF THE INVENTION
This invention relates generally to electronic data interchange ("EDI")
and, more particularly, to a template mapping system for dynamic and
flexible dataset translation between different computer systems and data
stores.
BACKGROUND OF THE INVENTION
Electronic data interchange (EDI) is the electronic exchange of business
documents, such as purchase orders and invoices. EDI is widely used to
facilitate business processes. For instance, documents can be sent and
received immediately, and mailing costs are reduced. In addition, there is
less paperwork, and improved accuracy as the result of avoiding manual
data entry.
Conventional EDI is accomplished over existing communication lines between
trading partners' computers. The transfer can be direct if the computers
are linked directly, or asynchronously if the connection is a transient
one. However, direct networks are difficult to maintain with larger
numbers of trading partners. More commonly, a third-party "value-added
network" (VAN) is used. VANs maintain an electronic mailbox for each
trading partner that can be accessed by each other partner.
In order to ensure both the sender and recipient format data in a common
mutually agreed way EDI takes place pursuant to a variety of established
EDI standards. Examples of such standards (and their maintenance
organizations) are the ANSI X12 standard (developed by the American
National Standards Institute's Accredited Standards Committee's X12
group), the UN-EDIFACT standard (Electronic Data Interchange for
Administration, Commerce, and Transport, a United Nations standard based
on ANSI X12 and the Trade Data Interchange standards used in Europe), the
Uniform Communications Standards ("UCS"), and TDCC (developed by the
Transportation Data Coordinating Committee).
Regardless of the particular standard, all are designed around an
electronic representation of a paper business document. A unique
identifier code is assigned for each type of business document. For
example, in the ANSI X12 standard an invoice is referred to as document
number X12.2, with a transaction set identification code of 810.
The basic unit of information on the electronic document is the "data
element." For the invoice, each item being invoiced would be represented
by a data element. Data elements can be grouped into compound data
elements, and data elements and/or compound data elements may be grouped
into data segments. Data segments can be grouped into loops; and loops
and/or data segments form the business document.
The standards define whether data segments are mandatory, optional, or
conditional and indicate whether, how many times, and in what order a
particular data segment can be repeated. For each electronic document, a
field definition table exists. For each data segment, the field definition
table includes a key field identifier string to indicate the data elements
to be included in the data segment, the sequence of the elements, whether
each element is mandatory, optional, or conditional, and the form of each
element in terms of the number of characters and whether the characters
are numeric or alphabetic. Similarly, field definition tables include data
element identifier strings to describe individual data elements. Element
identifier strings define an element's name, a reference designator, a
data dictionary reference number specifying the location in a data
dictionary where information on the data element can be found, a
requirement designator (either mandatory, optional, or conditional), a
type (such as numeric, decimal, or alphanumeric), and a length (minimum
and maximum number of characters). A data element dictionary gives the
content and meaning for each data element.
In general, trading partners seldom employ the same database programs and
computers, and accessing and storage formats differ significantly. A
structured query language (ANSI SQL) has evolved to unify the accessing
method. SQL provides a standard method of data accessing independent of
specific database storage formats, but this does not address structure and
data differences. SQL provides a useful mechanism to illustrate the
functionality of the invention and a common point of reference and
understanding. FIG. 14 is a high level schematic of the steps involved in
SQL processing. SQL begins with a human operator 1 or automated process
creating a script of SQL instructions 2 intended to retrieve or store
information in database 7. The script is executed by a conventional SQL
interpreter engine 3, which in turn initiates a series of database access
requests 4. The database system 5 receives and processes the requests and
physically accesses the data 6 from database 7. The data is fed back to
the SQL interpreter engine 3 which builds a response 8 to the SQL
instructions. The resultant output is properly formatted in SQL format 10
or is input to an application 9, depending on the intended usage. It is
presumed for purposes of the present patent application that the reader is
familiar with the ANSI SQL programming standards and language, and its
several popular commercial implementations. To help illustrate these
mechanisms, FIG. 15 is a chart showing the SQL language syntax components
(at top), as well as an example of a simple SQL language script for
inserting data into a table.
Accessing of data via SQL methods does not address remote transfers of data
from one computer to another. More is needed before the data becomes
useful in this context. The data must be translated from the format of one
computer system to the other so that the latter can process it accurately.
Originally, translation software was developed to support a variety of
private system formats. The private systems were employed by larger
companies and were custom written to allow them to exchange electronic
documents with selected trading partners.
Eventually, more general translation programs were developed such as TDCC
(used in the transportation industry) and UCS (used in the grocery
industry). These programs adapted a more flexible approach to translating
documents from a variety of different systems into recognizable form. Such
translators operate by extracting fixed data files from the original
dataset. They manipulate the data twice, once to extract the necessary
incoming data, and once to create the outgoing information and place it in
the recipient data system. In extracting the inbound data, the translators
converted the variable length data elements and segments in the dataset to
a fixed length format that could be processed by traditional batch
applications. Of course, there was no flexibility to manipulate data,
rearrange data, or make up for errors in the placement of data. Often data
structure clashes would occur between the data formats (a structure clash
occurs when the way that the information has been distributed within the
local system does not match the way it is earmarked for eventual use.
These programs also required highly specific transmission standards
limiting the formats by which datasets are transmitted. Most often, the
sender and receiver were required to contract in advance for a tailored
software program that would be dedicated to mapping between their two
types of datasets. For instance, typical modern computer systems use a
combination of SQL, xBase, and Btree based database storage systems. To
exchange data between these systems used to require using various flatfile
formats. There are four types commonly used, flatfile records, a comma
delimited file, EDI formats, and SQL syntax statements (the latter incurs
a very high overhead in terms of message size, and so is usually
restricted to local transfers and backing up of data only). In any of the
four cases, each time a new sender or receiver was added to the client
list, a new translation program would need to be added to the arsenal. Of
course, this becomes expensive.
Previous attempts at improving the translation process have resulted in
solutions that are still cumbersome, use inefficient computer programming
language syntax and structures, and still require programming staff to
implement. For instance, U.S. Pat. No. 5,202,977 discloses a language
based EDI translation system that receives data, executes a script to
translate the data, and then transmits the data. The translation is
accomplished by a script which creates two separate trees, or linked lists
of storage nodes (see column 22, lines 18-26). The script populates one
tree with the input data. Then, a series of assignment statements are
executed to populate the second tree with the desired output data and
according to the desired output format. For the reasons explained above,
the fixed scripts can be cumbersome, especially for complex looping
datasets. Moreover, there is no flexibility to accommodate a new data
structure. In the current state of the art, existing translation systems
will abort when they encounter unfamiliar data conditions. Therefore, if a
new trading partner comes along a new script must be custom written prior
to EDI.
It would be greatly advantageous to streamline the translation system, and
to reduce it to a flexible and efficient form capable of handling diverse
datasets and incongruities in the data without custom programming support,
and with built-in ability to handle unfamiliar conditions.
SUMMARY OF THE INVENTION
Accordingly, it is an object of the invention to provide an improved method
and architecture for mapping data between fixed structure datasets defined
by different computer formats.
It is another object to provide a data translation architecture and method
which employs a simple intuitive mapping template which operates from an
embedded knowledge of the structure rules for the data being exchanged.
It is a further object to provide a template mapping system which allows
the details of the data manipulation required for translation to be
expressed and prepared by a layperson, and without the requirement that
they define the entire message structure in every detail. Said layperson
will manually express and prepare said mapping templates and store them to
control and define the template processing required.
It is another object to provide a template mapping system in which the
mapping templates themselves can be transmitted along with the datasets to
facilitate dynamic conversion between data formats.
It is still another object to facilitate EDI data exchange without the need
for convoluted computer language syntax.
It is a further object to allow single step (in memory) implementations
that allow direct conversions between database and EDI formats.
It is still another object to allow a user to take an EDI message structure
and create either a flatfile record format, a comma delimited format, or
explicit dynamic SQL statements with embedded data.
It is a still further object to construct a system that lends itself to
implementation with a graphical user interface (GUI) for an intuitive
spreadsheet-like metaphor for the end-user. In a spreadsheet cells and
functions are used to manipulate mathematical data, whereas it is
envisioned that a similar type mechanism in which cells point to data
elements and functions will remove the need for complex programming.
These and other objects are accomplished by a template mapping system for
translating data between a first data structure and a second data
structure.
The system is especially suited for electronic data interchange (EDI)
between a first computer system operating with data structured according
to its particular protocol, and a second computer system operating with
data structured according to a second protocol. The EDI is accomplished
with a mapping template incorporating commands for extracting a dataset
from the first computer system (formatted in the first protocol), and for
restructuring the information according to the second protocol of the
second dataset. The system architecture also includes a communication line
between the computer systems over which the EDI transactions take place.
The method of using the above-described architecture includes the steps of
loading a mapping template that incorporates one or more table field
layouts that collectively describe the first data structure and second
data structure. The mapping template also includes mapping template rules
that define how data is mapped between the two structures. The mapping
template is applied by loading a dataset formatted according to the first
data structure. Then by identifying and tagging key data elements in said
first data structure, and by storing the tagged key data elements in a
structureless format. The mapping template is then applied to the
structureless data to map the tagged key data elements from the
structureless format into the second data structure. Finally, the mapped
data is assembled into the second data structure.
BRIEF DESCRIPTION OF DRAWINGS
FIG. 1 is a block diagram of the inbound mapping system of the present
invention which allows data to be freely received from a host computer and
reformatted for use in a host computer system.
FIG. 2 is a block diagram of the outbound mapping system of the present
invention which allows data to be freely reformatted for transmission and
use in a remote computer system. Like components and devices explained
above with regard to FIG. 1 are similarly designated.
FIG. 3 shows an exemplary table field layout for a manifest history and
manifest summary dataset which describes the names and maximum sizes of
the various fields (in bytes) for each table.
FIG. 4A is an example mapping template for an inbound dataset including a
manifest history and a manifest summary.
FIG. 4B is a continuation of FIG. 4A.
FIG. 5 is a flow chart of the three basic types of EDI message structure.
FIG. 6 shows an EDI message example of structure rules for a simple one to
many relationship.
FIG. 7 shows an example of structure rules for an EDI message with implied
looping.
FIG. 8A is an example mapping template for the EDI message dataset of FIG.
7.
FIG. 8B is a continuation of FIG. 8A.
FIG. 9 shows an example of an EDI message with complex looping.
FIG. 10 is an example mapping template for the complex looping inbound
dataset of FIG. 9.
FIG. 11 is an example SQL output for the manifest history and summary of
FIG. 2 mapped according to the mapping template of FIG. 10.
FIG. 12 shows an example flatfile output and field definition.
FIG. 13 is an example of the tagged inbound data assembled into a
structureless format.
FIG. 14 is a high level schematic of the steps involved in conventional SQL
processing.
FIG. 15 is a chart showing conventional SQL language syntax components (at
top), as well as an example of a simple SQL language script for inserting
data into a table.
FIG. 16 is an example template derived output structure showing the precise
details on the format of the resulting output structure definitions.
FIG. 17 is an example mapping template for the simple inbound dataset of
FIG. 6.
FIG. 18 is a top level overview of all components that make up the mapping
template of the present invention (cross-referenced to more detailed
figures).
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
The system described below provides a flexible and concise way of mapping
between a computer dataset with positionally significant data, and an
arbitrary new format required by the user of the method. The new format
can include data re-structuring and formatting, or embedding data into
dynamic database commands such as SQL or xBase data standards.
The system also allows this mapping to be performed despite only partial
information regarding the structure of the original data. The system
therefore is ideally suited for, but not restricted to, use in such
applications as Electronic Data Interchange (EDI). The following
description of the system will be in the context of EDI. However, it
should be noted that the system can be used for other purposes, for
example, in discontinuous processing associated with Email, forms, data
collection systems, etc. The system also provides a mechanism to
facilitate the melding of both current major EDI standards (e.g. ASC X12
and EDIFACT), and also combining SQL and EDI syntactical information
together. Typical modern computer systems use a combination of SQL, xBase,
and Btree based database storage systems. To exchange data between these
systems entails using various flatfile formats. There are four types
commonly used, flatfile records, a comma delimited file, EDI formats, and
SQL syntax statements. (The latter incurs a very high overhead in terms of
message size, and so is usually restricted to local transfers and backing
up of data only).
The template mapping system of the present invention performs data
translation of inbound datasets sent to the host computer from a remote
computer system, as well as translation of outbound datasets to be sent
from the host to a remote computer system. The invention allows the user
to take an EDI message structure and create either a flatfile record
format, a comma delimited format, or explicit dynamic SQL statements with
embedded data. The latter is the preferred format since these can then be
directly passed to the native database system for immediate transfer of
the data required. (Other non-SQL database systems such as Btrieve or
dBase syntax can be easily substituted). The other two forms are suitable
for use with existing data import processes (typical in a mainframe
system), while comma delimited formats are specific to xBase database
systems import facilities. The invention can also be applied directly for
object oriented style schema databases, where the TABLE and COLUMN items
within a SQL based data storage can be directly equated to the CLASS and
WITH items used in an object oriented data storage system.
To provide a familiar interface to the end-user the template mapping system
can be implemented using a metaphor analogous to a spreadsheet, where the
user describes the data storage tables, fields, and data elements in a
simple and intuitive way. This can be viewed as similar to entering
information and formulae into the cells in a spreadsheet. Associated with
this is the use of @functions within the mapping template to provide
processing decisions and calculation capabilities. (The use of the `@`
symbol is merely a unique character delimiter to signal the beginning of a
special function name to the mapping template parser). Each @function can
optionally have parameters associated with it, or can return an assignment
value, and each has a unique computational capability. For instance @IF()
provides decision making, @D returns a date, @MAP() reformats a data item
, @NEXTVAL retrieves the next value from a table, and so on. It is
intended that implementers of the present invention will extend the
available @functions to meet new and specialized needs within the domain
of their own product environments.
The fault tolerant data translation of inbound datasets (inbound mapping)
sent to the host computer from a remote computer system, and translation
of outbound datasets (outbound mapping) to be sent from the host to a
remote computer system will now be described.
1. Inbound Mapping
FIG. 1 illustrates the inbound mapping system of the present invention
which allows data to be freely exchanged and reformatted between different
computer systems. The flexible reformatting is accomplished by decomposing
the data elements, tagging key ones, and then reconstructing an outbound
dataset based on indexed and tagged key elements. This avoids the
torturous prior art system of translating the data into flatfile format,
offloading data into a flatfile database, and then translating again into
the outbound dataset.
In FIG. 1, the inbound computer dataset 2 represents the incoming
information from a remote sending computer's database that is to be
received and processed by the host computer. The information may, for
instance, include data from purchase orders, invoices and the like,
arranged in a structured, application-processable form. The inbound
dataset 2 is received directly over a standard communication line.
The inbound dataset 2 is processed by the template mapping system 10 of the
present invention, and is thereby restructured and reformatted to be
compatible with a receiving computer's database. The receiving computer
may be the host computer (in which case the data can be directly
downloaded into a computer database store 20 with the help of the existing
database direct access software 20 provided by the database vendor), or
alternatively, the receiving computer can be another remote computer (in
this case, once reformatted in the host, the data can be output in the
form of a computer output dataset 4 for transmission to the remote
computer).
In order to properly translate the inbound dataset 2, the template mapping
system 10 uses two other input components: the mapping template rules 45
and table field layouts 40.
The table field layouts 40 are typically supplied by the sending computer
and are dynamically input to the template mapping system 10 for use in
processing the input dataset. The table field layouts 40 describe the
names and maximum sizes of the various fields (in bytes) for each table.
FIG. 3 is a diagram showing the general components of a table field layout
(at left) mapped to an actual exemplary table field layout (at right). The
table field layout is for a manifest history and manifest summary dataset.
The table definition 150 comprises three components: 1) comments and notes
200 (optional); 2) a table description 300; and 3) field descriptions 400
which provide details of fields within that table. The table definition
150 can be repeated for as many tables as required.
The free-form comments and notes 200 are for documentation purposes. These
are ignored by the mapping system.
The table description 300 includes a label identifying the item as a table
(see example to right, column 1), a logical table name (column 2), and the
coded table name (column 3). The physical table name relates back to the
same name used in the mapping template. The logical table name allows a
description of the table.
The field descriptions 400 include the field identifier (column 1), the
field names (column 2), size (column 3), data format (column 4), and
justification parameters (column 5) which may be needed by the mapping
process to determine the physical format of the table.
Turning back to FIG. 1, the mapping template rules 45 govern the overall
data translation process. These may include field-to-field assignments,
and other data manipulations (examples of @ functions used to facilitate
such other data exchanges are shown to the right hand side of the
template). The mapping template rules form the operating core of the
template mapping system 10. They can be provided as an integral part of
the template mapping system 10, or they may be imported prior to the
translation process. For example, to increase the flexibility of the
template mapping system 10 the template mapping rules 45 may be
transmitted by the remote sending computer as a precursor to the inbound
dataset 2.
The table field layout 40 and mapping template rules 45 are used to build a
mapping template, which is then applied to the incoming dataset in the
mapping system 10.
FIGS. 4A and 4B are an example mapping template for an inbound dataset
including a manifest history and a manifest summary. The template is
subdivided into sections each directed to a different item to be
translated.
Again, the mapping rules may be prefaced by a series of explanatory
comments that generally explain what is to be mapped and how. In the
example, the comment block at the head of the template identifies the EDI
856 as the message type, then gives some general examples of function and
assignment operation usage within the template. The comments are designed
to aid the human reader in interpreting the actions denoted in the
subsequent template body and rules.
The mapping rules may be set forth in columns as shown. The illustrated
columns include an "item" label to denote the particular item upon which
the rules operate, and a "details" column setting forth the rule itself.
The items are arranged in succession and include a table identifier that
designates the type of table, an index number to uniquely designate the
particular table, and key identifiers. The key identifiers denote fields
within the data structure that indicate a change of record or level (see
FIG. 5 and accompanying explanation). Such key fields can be further
subdivided into natural keys within the data structure, and artificial
keys that indicate repeated structure elements. For ANSI X12 EDI message
standards these include natural keys, (usually found in the very first
message segment), and keys within message control segments such as the HL,
and LS/LE segments that are added to a message to specifically denote
where data loops begin and end. In the message template the EDI.sub.-- KEY
key field(s) are those elements within the message structure that indicate
that a new record has occurred when its value changes. This allows the
structure of the inbound message to be recursively identified, even if
partial or incomplete table field layout 40 is provided. The HL.sub.-- KEY
keys are specific to EDI messages which may contain HL segments, and these
(when present) indicate the change of HL level, or record group, within
the data structure. It should be noted that the order in which table
definitions are added into the template itself can be used to determine
the sequential significance of the actual mapped data output in a fault
tolerant way. In other words, when performing the processing the natural
order of the data occurrences within the data to be mapped will mean that
the inner most key value changes will trigger first. This may be the
desired result in the output sequencing. However, if not, the data must be
cached on the basis of the table definition sequence. Therefore, instead
of implementing the last part of a `write stored data values` operation
immediately, these should be deferred by storing the resulting data based
on the simple sequence of the table definitions (labelled as 1, 2, 3,
etc.). Once mapping at this first pass is complete, a second pass is then
necessary to process the actual data in the sequence 1, 2, 3, etc. This
two level processing is only required where sequence is critical.
Normally, this is not the case, and the extra complication can be avoided.
The regular key ordering can be used to guarantee that referential
integrity of one to many relationships within the data is not compromised
by processing the `many` items before the `one` item.
The particular fields of the table are then set forth by label, and the
field reassignments or operators immediately follow. Various types of
assignments can be indicated. A simple example is shown by the
`mnfst.sub.-- no` field, into which is assigned the value from the BSN02
EDI element. Another example is the `ts.sub.-- date` field which is
assigned the value from the date function @DYYMMDD. The latter is a direct
value not related to any incoming message element. A complex example is
shown by the field rule for `generator.sub.-- id` which uses an @IF
function and shows how a conditional assignment is implemented. In this
case, the N101 EDI element is compared to the value `SF`. If it matches,
then the value from N104 EDI element is assigned into the field
`generator.sub.--id `. The "S" element used as prefixes indicates the rule
applies to the HL "S" segment to be processed. Field `Reject.sub.-- flag`
is assigned from the &&edi.sub.-- valid.sub.-- flag which is in a memory
storage area which indicates the status of the translation process.
In addition to the two input components (the mapping template rules 45 and
table field layouts 40), the template mapping system 10 uses a number of
resident components that are maintained in the receiving computer system
to help accomplish the dataset translation procedure. As shown in FIG. 1,
these include data structure algorithm rules 50, dynamic SQL syntax rules
60, other database-specific syntax rules 70, and local exchange values 80.
The data structure process rules 50 consist of rules within the template
mapping system that determine how specific data structure elements are
handled by the mapping process. These known rules define how to handle the
structures of the data, and how to recursively recognize and process the
specific structures contained in it; this is intrinsically fault tolerant.
FIG. 5 is a flow chart of the three basic types of EDI message structure.
These include simple structure (top) wherein each message includes a
number of direct data elements.
FIG. 6 shows an EDI message example of structure rules for a simple one to
many relationship (between the V1 segment and the R4/NV9 segment pairs).
FIG. 17 is an example mapping template for a simple inbound dataset.
The EDI message may also include implied looping (see FIG. 5, middle). FIG.
7 shows an example of structure rules for an EDI message with implied
looping. A data element representing a top level of detail may have
multiple detail segments associated with it in loops, and each of these
may also map to other data elements containing deeper levels of detail,
and so on (compare to the simple looping in FIG. 6 notice the multiple N3
and N10 segments can occur multiple times in implied loops). FIG. 8A and
8B are an example mapping template for an implied looping dataset.
Finally, the EDI message may include complex looping (see FIG. 5, bottom).
FIG. 9 shows an example of structure rules for an EDI message with complex
looping. This is a hybrid of the previous two EDI message types. The
previously discussed mapping template of FIGS. 4A and 4B are an example
mapping template for an inbound dataset including complex looping (in
FIGS. 4A and 4B are, HL segments provide complex looping structures, c.f.,
FIG. 9 where the VID/N10 segments provide an implied loop example).
Referring back to FIG. 1, the template mapping system 10 also uses dynamic
SQL syntax rules 60. The American National Standards Institute maintains a
standard language for accessing databases. This is called structured query
language (SQL). Software programs may access SQL compliant databases by
use of dynamic SQL statements embedded in the memory of the computer.
Dynamic SQL allows real time accessing. The template mapping system 10 of
the present invention can take advantage of widely available SQL
integration tools kits such as those based on the industry wide ODBC (Open
DataBase Connectivity) standard originally adopted by Microsoft and IBM.
These make available a complete set of dynamic SQL statements and syntax
rules 60. Alternately the template mapping system 10 could be optimized to
work specifically with a select set of database types, such as the xBase
standard, a widely used PC based standard, by building the structure rules
that apply to accessing data within an xBase database. (xBase database
standard defines the content of the header record within the database, and
the data records and their field elements, and how to access the data,
add, delete, and update records).
The template mapping system 10 also uses other database-specific syntax
rules. These are miscellaneous syntax rules that are specific to
particular database formats, such as dBase (Borland's database standard).
Finally, the template mapping system 10 employs local exchange values that
are defined locally to equate to different external values. For example,
the local exchange value K may be assigned to designate kilograms, whereas
the external designation is KG.
Given the above-described inputs and infrastructure, the template mapping
system 10 is capable of performing a robust, flexible translation of a
fixed-structure inbound dataset into a different outbound dataset in the
following manner.
2. The Method of Inbound Translation
The method of using the architecture described above includes two general
steps: 1) decomposing the inbound data into discrete data elements and
tagging the key elements; and 2) deducing the outbound structure of the
data based on index key elements and assembling the final data product
accordingly. The detailed steps for accomplishing this are explained
below:
i. Open the inbound dataset (to be mapped), identify the type of document
and verify that a mapping template exists for this type of document so
that it can be processed.
ii. Load mapping template
The appropriate mapping template is loaded into memory and memory -storage
locations are defined and reserved for the following information:
______________________________________
key.sub.-- value
(number, key, value)
loop trigger keys
(these indicate to the
process that a level
trigger value has been
detected).
data.sub.-- values
(key, value) tagged data values
line.sub.-- values
(key, value) used for embedded
data outputs (this
stores the raw `Field`
line read from the
mapping template 10
file).
line.sub.-- element
(value, number)
used for embedded
data outputs (this
locates the position of
the element in the
output record format)
current.sub.-- table.sub.-- name
(value) holds the name of the
table that data is
currently for.
table.sub.-- store
(name, table, type,
Holds details of the
index, sequence)
tables within the
mapping template.
table.sub.-- defs.sub.-- store
(table, field, size,
used for none database
format, justify, sequence)
tables
table.sub.-- key.sub.-- store
(table, element, loop.sub.-- id,
Tables key elements
key value)
mapping.sub.-- rules
(table, column name,
element, loop.sub.-- id, rule,
rule.sub.-- type, position)
table.sub.-- mode.sub.-- rule
(table, mode, element,
Update/Append
value) indicator
table.sub.-- data
(element, loop.sub.-- id, table,
retains incoming data
column name, data)
for a table.
______________________________________
iii. Then for each record within the incoming dataset, read each one, one
at a time, and do the following:
a. Load each data element into the data values store (data values), and tag
it with its associated data tag, table and field address from the mapping
template rules 45 described above.
b. Next determine if a control key value changed (by cross-referencing by
element ID name into the key.sub.-- value store), or if an end of data set
marker has been encountered. If so, determine which tables are affected by
either event by checking the index elements (held in the key.sub.-- value
store) against the control key value that changed (an end of data set
marker triggers all tables for processing, a key change, only those tables
| | |
