Case: 1:20-cv-02032-DCN Doc #: 1-2 Filed: 09/10/20 1 of 16. PageID #: 31
`
`
`
`
`
`
`
`EXHIBIT B
`
`

`

`T
`
`Case: 1:20-cv-02032-DCN Doc #: 1-2 Filed: 09/10/20 2 of 16. PageID #: 32
`
`Method for enforcing a set of constraints that governs the integrity of
`information stored in a database system, the constraints being stored in a
`conceptual rules module in the form of rules for prescribing permitted
`states and transitions that the database can undertake, the method
`comprising the steps of
`
`delaying constraint checks until the end of a transaction by creating a check
`stack during the course of the transaction and executing entries on the check
`stack at the end of the transaction,
`
`by a stack maker module operatively connected to a runtime module in said
`database system: receiving data from said runtime module, and
`
`creating and updating said check stack, and retrieving constraints from said
`conceptual rules module,
`
`wherein the check stack contains a list of functions that have to be executed at
`the end of the transaction, said functions originating from Insert, Delete and
`Update Data Manipulation Language (DML) operations calling up the stack
`maker module,
`
`the Insert DML operation calling up the stack maker module leading to an insert
`process being performed on the check stack,
`the insert process involving placing all checks that have to be executed as a
`result of an occurrence of a table type being inserted and corresponding
`conceptual rules being identified for the table type being inserted,
`
`the Delete DML operation calling up the stack maker module leading to a delete
`process being performed on the check stack,
`the delete process involving removing previously inserted entries on the check
`stack for the occurrence to be deleted and placing all checks that have to be
`executed as a result of a table type being deleted and corresponding conceptual
`rules being identified for the table type being deleted, and
`
`the Update DML operation calling up the stack maker module leading to said
`delete process followed by said insert process being performed on the check
`stack, and
`
`by an enforcer module: receiving check data from the check stack, processing
`the check data received from the check stack, and providing resulting data to the
`runtime module,
`
`Data Quality with ODI:
`With an approach based on declarative rules, Oracle Data Integrator is the most
`appropriate tool to help you build a data quality framework to track data
`inconsistencies. Oracle Data Integrator uses declarative data integrity rules defined
`in its centralized metadata repository. These rules are applied to application data to
`guarantee the integrity and consistency of enterprise information. The Data Integrity
`benefits add to the overall Data Quality initiative and facilitate integration with existing and
`future business processes addressing this particular need.
`Oracle Data Integrator automatically retrieves existing rules defined at the data level
`(such as database constraints) by a reverse-engineering process. ODI also allows
`developers to define additional, user-defined declarative rules that may be inferred from
`data discovery and profiling within ODI, and immediately checked.
`Oracle Data Integrator provides a built-in framework to check the quality of your data in two
`ways:
`■ Check data in your data servers, to validate that this data does not violate any of the
`rules declared on the datastores in Oracle Data Integrator. This data quality check is called
`a static check and is performed on data models and datastores. This type of check allows
`you to profile the quality of the data against rules that are not enforced by their storage
`technology.
`■ Check data while it is moved and transformed by a mapping, in a flow check that
`checks the data flow against the rules defined on the target datastore. With such a
`check, correct data can be integrated into the target datastore while incorrect data is
`automatically moved into error tables.
`
`Source: https://docs.oracle.com/middleware/1212/odi/ODIDG.pdf
`
`wherein said constraints are constraints executed within the transaction which
`allow conceptual rules to be broken during the transaction, but allow the
`database system to be in a consistent state at the beginning and end of the
`transaction.
`Analyst Note: Evidence demonstrates that Oracle Data Integrator (target product) includes a data integrity framework for ensuring the quality of a data model (database system). Target product
`uses data integrity rules (set of constraints) defined in its centralized metadata repository. These rules are applied to application data to guarantee the integrity and consistency of the database
`system. Based on the constraints rules check on data, the correct data can be integrated into target datastore (permitted state) while incorrect data is moved into error tables (transition state).
`
`US7502791 – Claim 4 as applied to Oracle® Fusion Middleware – Oracle Data Integrator
`
`
`
`

`

`
`
`Case: 1:20-cv-02032-DCN Doc #: 1-2 Filed: 09/10/20 3 of 16. PageID #: 33
`
`Introduction to Mappings
`A mapping is an Oracle Data Integrator object stored that enables the loading of target
`datastores with data transformed from source datastores, based on declarative rules
`implemented as joins, filters and constraints.
`A constraint is an object that defines the rules enforced on data sets' data. A
`constraint ensures the validity of the data in a given data set and the integrity of the
`data of a model. Constraints on the target are used to check the validity of the data
`before integration in the target.
`
`Method for enforcing a set of constraints that governs the integrity of
`information stored in a database system, the constraints being stored in a
`conceptual rules module in the form of rules for prescribing permitted
`states and transitions that the database can undertake, the method
`comprising the steps of
`
`delaying constraint checks until the end of a transaction by creating a check
`stack during the course of the transaction and executing entries on the check
`stack at the end of the transaction,
`
`by a stack maker module operatively connected to a runtime module in said
`database system: receiving data from said runtime module, and
`
`creating and updating said check stack, and retrieving constraints from said
`conceptual rules module,
`
`wherein the check stack contains a list of functions that have to be executed at
`the end of the transaction, said functions originating from Insert, Delete and
`Update Data Manipulation Language (DML) operations calling up the stack
`maker module,
`
`the Insert DML operation calling up the stack maker module leading to an insert
`process being performed on the check stack,
`the insert process involving placing all checks that have to be executed as a
`result of an occurrence of a table type being inserted and corresponding
`conceptual rules being identified for the table type being inserted,
`
`the Delete DML operation calling up the stack maker module leading to a delete
`process being performed on the check stack,
`the delete process involving removing previously inserted entries on the check
`stack for the occurrence to be deleted and placing all checks that have to be
`executed as a result of a table type being deleted and corresponding conceptual
`rules being identified for the table type being deleted, and
`
`the Update DML operation calling up the stack maker module leading to said
`delete process followed by said insert process being performed on the check
`stack, and
`
`by an enforcer module: receiving check data from the check stack, processing
`the check data received from the check stack, and providing resulting data to
`the runtime module,
`wherein said constraints are constraints executed within the transaction which
`allow conceptual rules to be broken during the transaction, but allow the
`database system to be in a consistent state at the beginning and end of the
`transaction.
`Analyst Note: Evidence demonstrates the implementation using Oracle Data Integrator uses a set of constraints (rules) to check the validity (integrity) of database system.
`
`US7502791 – Claim 4 as applied to Oracle® Fusion Middleware – Oracle Data Integrator
`
`
`
`Source:
`https://doc
`s.oracle.c
`om/middle
`ware/1212
`/odi/ODID
`G.pdf
`
`

`

`
`
`Case: 1:20-cv-02032-DCN Doc #: 1-2 Filed: 09/10/20 4 of 16. PageID #: 34
`
`Method for enforcing a set of constraints that governs the integrity of information
`stored in a database system, the constraints being stored in a conceptual rules
`module in the form of rules for prescribing permitted states and transitions that
`the database can undertake, the method comprising the steps of
`
`delaying constraint checks until the end of a transaction by creating a
`check stack during the course of the transaction and executing entries on
`the check stack at the end of the transaction,
`
`by a stack maker module operatively connected to a runtime module in said
`database system: receiving data from said runtime module, and
`
`creating and updating said check stack, and retrieving constraints from said
`conceptual rules module,
`
`wherein the check stack contains a list of functions that have to be executed at
`the end of the transaction, said functions originating from Insert, Delete and
`Update Data Manipulation Language (DML) operations calling up the stack
`maker module,
`
`the Insert DML operation calling up the stack maker module leading to an insert
`process being performed on the check stack,
`the insert process involving placing all checks that have to be executed as a
`result of an occurrence of a table type being inserted and corresponding
`conceptual rules being identified for the table type being inserted,
`
`the Delete DML operation calling up the stack maker module leading to a delete
`process being performed on the check stack,
`the delete process involving removing previously inserted entries on the check
`stack for the occurrence to be deleted and placing all checks that have to be
`executed as a result of a table type being deleted and corresponding conceptual
`rules being identified for the table type being deleted, and
`
`the Update DML operation calling up the stack maker module leading to said
`delete process followed by said insert process being performed on the check
`stack, and
`
`Check Knowledge Modules (CKM)
`The CKM is in charge of checking that records of a data set are consistent with
`defined constraints. The CKM is used to maintain data integrity and participates in the
`overall data quality initiative. The CKM can be used in 2 ways:
`■ To check the consistency of existing data. This can be done on any datastore or within
`interfaces, by setting the STATIC_CONTROL option to "Yes". In the first case, the data
`checked is the data currently in the datastore. In the second case, data in the target
`datastore is checked after it is loaded.
`■ To check consistency of the incoming data before loading the records to a target
`datastore. This is done by using the FLOW_CONTROL option. In this case, the CKM
`simulates the constraints of the target datastore on the resulting flow prior to
`writing to the target.
`The CKM accepts a set of constraints and the name of the table to check. It creates
`an "E$" error table which it writes all the rejected records to. The CKM can also remove
`the erroneous records from the checked result set.
`
`Source: https://docs.oracle.com/cd/E17904_01/integrate.1111/e12645.pdf
`
`Source/Target Transaction: Transaction where the command will be executed.
`
`Source: https://docs.oracle.com/middleware/1212/odi/ODIDG.pdf
`
`by an enforcer module: receiving check data from the check stack, processing
`the check data received from the check stack, and providing resulting data to
`the runtime module,
`wherein said constraints are constraints executed within the transaction which
`allow conceptual rules to be broken during the transaction, but allow the
`database system to be in a consistent state at the beginning and end of the
`transaction.
`Analyst Note: Evidence demonstrates that target product uses check knowledge modules (CKM) to check the consistency of data stored in the database. Before checking the data (means
`constraint check process is delayed) against constraints (rules), target product first creates the I$" flow table (check stack) and then CKM accepts a set of constraints to check against the I$"
`flow table (check stack) at the end of a transaction. This further illustrates that delaying constraint checks against the data after creating the table as demonstrated by the screenshot on the
`next slide.
`
`US7502791 – Claim 4 as applied to Oracle® Fusion Middleware – Oracle Data Integrator
`
`
`
`

`

`
`
`Case: 1:20-cv-02032-DCN Doc #: 1-2 Filed: 09/10/20 5 of 16. PageID #: 35
`
`Method for enforcing a set of constraints that governs the integrity of information
`stored in a database system, the constraints being stored in a conceptual rules
`module in the form of rules for prescribing permitted states and transitions that
`the database can undertake, the method comprising the steps of
`
`delaying constraint checks until the end of a transaction by creating a
`check stack during the course of the transaction and executing entries on
`the check stack at the end of the transaction,
`
`by a stack maker module operatively connected to a runtime module in said
`database system: receiving data from said runtime module, and
`
`creating and updating said check stack, and retrieving constraints from said
`conceptual rules module,
`
`wherein the check stack contains a list of functions that have to be executed at
`the end of the transaction, said functions originating from Insert, Delete and
`Update Data Manipulation Language (DML) operations calling up the stack
`maker module,
`
`the Insert DML operation calling up the stack maker module leading to an insert
`process being performed on the check stack,
`the insert process involving placing all checks that have to be executed as a
`result of an occurrence of a table type being inserted and corresponding
`conceptual rules being identified for the table type being inserted,
`
`the Delete DML operation calling up the stack maker module leading to a delete
`process being performed on the check stack,
`the delete process involving removing previously inserted entries on the check
`stack for the occurrence to be deleted and placing all checks that have to be
`executed as a result of a table type being deleted and corresponding conceptual
`rules being identified for the table type being deleted, and
`
`the Update DML operation calling up the stack maker module leading to said
`delete process followed by said insert process being performed on the check
`stack, and
`
`by an enforcer module: receiving check data from the check stack, processing
`the check data received from the check stack, and providing resulting data to
`the runtime module,
`
`The following figures show how a CKM operates in both STATIC_CONTROL and
`FLOW_CONTROL modes.
`In FLOW_CONTROL mode, the CKM reads the constraints of the target table of the
`Interface. It checks these constraints against the data contained in the "I$" flow table of
`the staging area. Records that violate these constraints are written to the "E$" table of the
`staging area.
`
`Check stack
`
`Constraints
`
`Source: https://docs.oracle.com/cd/E17904_01/integrate.1111/e12645.pdf
`
`wherein said constraints are constraints executed within the transaction which
`allow conceptual rules to be broken during the transaction, but allow the
`database system to be in a consistent state at the beginning and end of the
`transaction.
`Analyst Note: The screenshot demonstrates the check knowledge module uses constraint rules against the "I$" flow table (check stack) that governs the integrity of data stored in the
`database system.
`
`US7502791 – Claim 4 as applied to Oracle® Fusion Middleware – Oracle Data Integrator
`
`
`
`

`

`
`
`Case: 1:20-cv-02032-DCN Doc #: 1-2 Filed: 09/10/20 6 of 16. PageID #: 36
`
`Method for enforcing a set of constraints that governs the integrity of information
`stored in a database system, the constraints being stored in a conceptual rules
`module in the form of rules for prescribing permitted states and transitions that
`the database can undertake, the method comprising the steps of
`
`delaying constraint checks until the end of a transaction by creating a check
`stack during the course of the transaction and executing entries on the check
`stack at the end of the transaction,
`
`by a stack maker module operatively connected to a runtime module in
`said database system: receiving data from said runtime module, and
`
`creating and updating said check stack, and retrieving constraints from said
`conceptual rules module,
`
`wherein the check stack contains a list of functions that have to be executed at
`the end of the transaction, said functions originating from Insert, Delete and
`Update Data Manipulation Language (DML) operations calling up the stack
`maker module,
`
`the Insert DML operation calling up the stack maker module leading to an insert
`process being performed on the check stack,
`the insert process involving placing all checks that have to be executed as a
`result of an occurrence of a table type being inserted and corresponding
`conceptual rules being identified for the table type being inserted,
`
`the Delete DML operation calling up the stack maker module leading to a delete
`process being performed on the check stack,
`the delete process involving removing previously inserted entries on the check
`stack for the occurrence to be deleted and placing all checks that have to be
`executed as a result of a table type being deleted and corresponding conceptual
`rules being identified for the table type being deleted, and
`
`the Update DML operation calling up the stack maker module leading to said
`delete process followed by said insert process being performed on the check
`stack, and
`
`by an enforcer module: receiving check data from the check stack, processing
`the check data received from the check stack, and providing resulting data to
`the runtime module,
`
`A Knowledge Module is a code template for a given integration task. This code is
`independent of the Declarative Rules that need to be processed. At design-time, a
`developer creates the Declarative Rules describing integration processes. These
`Declarative Rules are merged with the Knowledge Module to generate code ready for
`runtime. At runtime, Oracle Data Integrator sends this code for execution to the
`source and target systems it leverages in the E-LT architecture for running the
`process.
`
`Figure 1–4 shows the data flow automatically generated by Oracle Data Integrator to load
`the final SALES table. The business rules will be transformed into code by the
`Knowledge Modules (KM). The code produced will generate several steps. Some of these
`steps will extract and load the data from the sources to the staging area (Loading
`Knowledge Modules - LKM). Others will transform and integrate the data from the staging
`area to the target table (Integration Knowledge Module - IKM). To ensure data quality, the
`Check Knowledge Module (CKM) will apply the user defined constraints to the staging data
`to isolate erroneous records in the Errors table.
`
`Source: https://docs.oracle.com/middleware/1212/odi/ODIDG.pdf
`
`wherein said constraints are constraints executed within the transaction which
`allow conceptual rules to be broken during the transaction, but allow the
`database system to be in a consistent state at the beginning and end of the
`transaction.
`Analyst Note: Evidence demonstrates that Oracle Data Integrator knowledge modules (stack maker module) extracts and loads the data from the sources to the staging area (runtime module)
`as shown by the screenshot on the next slide.
`
`US7502791 – Claim 4 as applied to Oracle® Fusion Middleware – Oracle Data Integrator
`
`
`
`

`

`
`
`Case: 1:20-cv-02032-DCN Doc #: 1-2 Filed: 09/10/20 7 of 16. PageID #: 37
`
`Method for enforcing a set of constraints that governs the integrity of information
`stored in a database system, the constraints being stored in a conceptual rules
`module in the form of rules for prescribing permitted states and transitions that
`the database can undertake, the method comprising the steps of
`
`delaying constraint checks until the end of a transaction by creating a check
`stack during the course of the transaction and executing entries on the check
`stack at the end of the transaction,
`
`by a stack maker module operatively connected to a runtime module in
`said database system: receiving data from said runtime module, and
`
`creating and updating said check stack, and retrieving constraints from said
`conceptual rules module,
`
`wherein the check stack contains a list of functions that have to be executed at
`the end of the transaction, said functions originating from Insert, Delete and
`Update Data Manipulation Language (DML) operations calling up the stack
`maker module,
`
`the Insert DML operation calling up the stack maker module leading to an insert
`process being performed on the check stack,
`the insert process involving placing all checks that have to be executed as a
`result of an occurrence of a table type being inserted and corresponding
`conceptual rules being identified for the table type being inserted,
`
`the Delete DML operation calling up the stack maker module leading to a delete
`process being performed on the check stack,
`the delete process involving removing previously inserted entries on the check
`stack for the occurrence to be deleted and placing all checks that have to be
`executed as a result of a table type being deleted and corresponding conceptual
`rules being identified for the table type being deleted, and
`
`the Update DML operation calling up the stack maker module leading to said
`delete process followed by said insert process being performed on the check
`stack, and
`
`by an enforcer module: receiving check data from the check stack, processing
`the check data received from the check stack, and providing resulting data to
`the runtime module,
`
`Source: https://docs.oracle.com/middleware/1212/odi/ODIDG.pdf
`
`wherein said constraints are constraints executed within the transaction which
`allow conceptual rules to be broken during the transaction, but allow the
`database system to be in a consistent state at the beginning and end of the
`transaction.
`Analyst Note: Evidence demonstrates the Oracle Data Integrator Knowledge Modules extracts and load the data from source MSSQL to the staging area to check the data integrity against a
`set of constraints.
`
`US7502791 – Claim 4 as applied to Oracle® Fusion Middleware – Oracle Data Integrator
`
`
`
`

`

`
`
`Case: 1:20-cv-02032-DCN Doc #: 1-2 Filed: 09/10/20 8 of 16. PageID #: 38
`
`Method for enforcing a set of constraints that governs the integrity of information
`stored in a database system, the constraints being stored in a conceptual rules
`module in the form of rules for prescribing permitted states and transitions that
`the database can undertake, the method comprising the steps of
`
`delaying constraint checks until the end of a transaction by creating a check
`stack during the course of the transaction and executing entries on the check
`stack at the end of the transaction,
`
`by a stack maker module operatively connected to a runtime module in said
`database system: receiving data from said runtime module, and
`
`creating and updating said check stack, and retrieving constraints from
`said conceptual rules module,
`
`wherein the check stack contains a list of functions that have to be executed at
`the end of the transaction, said functions originating from Insert, Delete and
`Update Data Manipulation Language (DML) operations calling up the stack
`maker module,
`
`the Insert DML operation calling up the stack maker module leading to an insert
`process being performed on the check stack,
`the insert process involving placing all checks that have to be executed as a
`result of an occurrence of a table type being inserted and corresponding
`conceptual rules being identified for the table type being inserted,
`
`the Delete DML operation calling up the stack maker module leading to a delete
`process being performed on the check stack,
`the delete process involving removing previously inserted entries on the check
`stack for the occurrence to be deleted and placing all checks that have to be
`executed as a result of a table type being deleted and corresponding conceptual
`rules being identified for the table type being deleted, and
`
`the Update DML operation calling up the stack maker module leading to said
`delete process followed by said insert process being performed on the check
`stack, and
`
`by an enforcer module: receiving check data from the check stack, processing
`the check data received from the check stack, and providing resulting data to
`the runtime module,
`
`Other use cases of this type of integration might require capturing changes at the database
`level. Oracle Data Integrator Changed Data Capture (CDC) capability identifies and
`captures inserted, updated, or deleted data from the source and makes it available for
`integration processes.
`The CDC framework used to manage changes, based on Knowledge Modules, is generic
`and open, so the change-tracking method can be customized. Any third-party change
`provider can be used to load the framework with changes.
`Changes frequently involve several data sources at the same time. For example, when an
`order is created, updated, or deleted, both the orders table and the order lines table are
`involved. When processing a new order line, it is important that the new order, to which the
`line is related, is taken into account too. ODI provides a mode of change tracking called
`Consistent Set CDC. This mode allows for processing sets of changes for which data
`consistency is guaranteed.
`Oracle Data Integrator automatically retrieves existing rules defined at the data level
`(such as database constraints) by a reverse-engineering process. ODI also allows
`developers to define additional, user-defined declarative rules that may be inferred from
`data discovery and profiling within ODI, and immediately checked.
`
`Figure 1–4 shows the data flow automatically generated by Oracle Data Integrator to load
`the final SALES table. The business rules will be transformed into code by the
`Knowledge Modules (KM). The code produced will generate several steps. Some of
`these steps will extract and load the data from the sources to the staging area
`(Loading Knowledge Modules - LKM). Others will transform and integrate the data from
`the staging area to the target table (Integration Knowledge Module - IKM). To ensure data
`quality, the Check Knowledge Module (CKM) will apply the user defined constraints
`to the staging data to isolate erroneous records in the Errors table.
`
`wherein said constraints are constraints executed within the transaction which
`allow conceptual rules to be broken during the transaction, but allow the
`database system to be in a consistent state at the beginning and end of the
`transaction.
`Analyst Note: Evidence demonstrates that before checking the data against constraints, first extract and load the data from the sources to the staging area and create the TEMP_SALES table
`("I$" flow table, check stack). To ensure data quality, the Check Knowledge Module (CKM) will apply the constraints to the staging data (check stack).
`
`Source: https://docs.oracle.com/middleware/1212/odi/ODIDG.pdf
`
`US7502791 – Claim 4 as applied to Oracle® Fusion Middleware – Oracle Data Integrator
`
`
`
`

`

`
`
`Case: 1:20-cv-02032-DCN Doc #: 1-2 Filed: 09/10/20 9 of 16. PageID #: 39
`
`Method for enforcing a set of constraints that governs the integrity of information
`stored in a database system, the constraints being stored in a conceptual rules
`module in the form of rules for prescribing permitted states and transitions that
`the database can undertake, the method comprising the steps of
`
`delaying constraint checks until the end of a transaction by creating a check
`stack during the course of the transaction and executing entries on the check
`stack at the end of the transaction,
`
`by a stack maker module operatively connected to a runtime module in said
`database system: receiving data from said runtime module, and
`
`creating and updating said check stack, and retrieving constraints from
`said conceptual rules module,
`
`wherein the check stack contains a list of functions that have to be executed at
`the end of the transaction, said functions originating from Insert, Delete and
`Update Data Manipulation Language (DML) operations calling up the stack
`maker module,
`
`the Insert DML operation calling up the stack maker module leading to an insert
`process being performed on the check stack,
`the insert process involving placing all checks that have to be executed as a
`result of an occurrence of a table type being inserted and corresponding
`conceptual rules being identified for the table type being inserted,
`
`the Delete DML operation calling up the stack maker module leading to a delete
`process being performed on the check stack,
`the delete process involving removing previously inserted entries on the check
`stack for the occurrence to be deleted and placing all checks that have to be
`executed as a result of a table type being deleted and corresponding conceptual
`rules being identified for the table type being deleted, and
`
`the Update DML operation calling up the stack maker module leading to said
`delete process followed by said insert process being performed on the check
`stack, and
`
`by an enforcer module: receiving check data from the check stack, processing
`the check data received from the check stack, and providing resulting data to
`the runtime module,
`
`Source: https://docs.oracle.com/middleware/1212/odi/ODIDG.pdf
`
`wherein said constraints are constraints executed within the transaction which
`allow conceptual rules to be broken during the transaction, but allow the
`database system to be in a consistent state at the beginning and end of the
`transaction.
`Analyst Note: Evidence demonstrates that TEMP_SALES (check stack) is checked against constraints to ensure data integrity.
`
`US7502791 – Claim 4 as applied to Oracle® Fusion Middleware – Oracle Data Integrator
`
`

`

`
`
`Case: 1:20-cv-02032-DCN Doc #: 1-2 Filed: 09/10/20 10 of 16. PageID #: 40
`
`Method for enforcing a set of constraints that governs the integrity of information
`stored in a database system, the constraints being stored in a conceptual rules
`module in the form of rules for prescribing permitted states and transitions that
`the database can undertake, the method comprising the steps of
`
`delaying constraint checks until the end of a transaction by creating a check
`stack during the course of the transaction and executing entries on the check
`stack at the end of the transaction,
`
`by a stack maker module operatively connected to a runtime module in said
`database system: receiving data from said runtime module, and
`
`creating and updating said check stack, and retrieving constraints from said
`conceptual rules module,
`
`wherein the check stack contains a list of functions that have to be
`executed at the end of the transaction, said functions originating from
`Insert, Delete and Update Data Manipulation Language (DML) operations
`calling up the stack maker module,
`
`the Insert DML operation calling up the stack maker module leading to an insert
`process being performed on the check stack,
`the insert process involving placing all checks that have to be executed as a
`result of an occurrence of a table type being inserted and corresponding
`conceptual rules being identified for the table type being inserted,
`
`the Delete DML operation calling up the stack maker module leading to a delete
`process being performed on the check stack,
`the delete process involving removing previously inserted entries on the check
`stack for the occurrence to be deleted and placing all checks that have to be
`executed as a result of a table type being deleted and corresponding conceptual
`rules being identified for the table type being deleted, and
`
`the Update DML operation calling up the stack maker module leading to said
`delete process followed by said insert process being performed on the check
`stack, and
`
`by an enforcer module: receiving check data from the check stack, processing
`the check data received from the check stack, and providing resulting data to
`the runtime module,
`
`Data Quality with ODI:
`With an approach based o