Contextual Data Store
The Contextual Data Store is used to load features from Oracle within a spatial extent, but also to include additional features that are related to them.
Note: The Contextual Data Store can only load data from a spatial extent and cannot be used to load all data.
It is used instead of the standard Oracle Data Store to ensure that all of the relevant referenced features required to validate the data are present, particularly for features with no geometry.
Examples of the Contextual Data Store in use would be:
-
If you are checking that a pipe has a logical connection to a valve and the pipe is in the spatial extent, the valve will also be loaded if there is a foreign key or join table reference between them, even if the valve is outside the extent.
-
If a building is referenced by a non-spatial 'building group', which is a collection of other buildings whose membership is defined via a join table, then the referencing 'building group' and all the other members of that group can be loaded if only a single building is within the extent.
Prerequisites
Temporary Tables
The contextual Data Store requires global temporary tables to temporarily record information when the data is being loaded for efficiency. These do not persist any data but are used during the open data task.
You will need to create temporary tables for each table in your schema by using the SQL below, e.g. TID0, TID1, TID2 etc:
CREATE GLOBAL TEMPORARY TABLE TID<table index>(FID VARCHAR2(38));
Load Policy
The Contextual Data Store provides a reader and a writer for loading the features using more complex relationships from an Oracle schema.
It is configured using an XML file called the "load policy" which defines which tables to load and which references to follow in order to load this data.
Load Policy Definitions
primitive-table-hint
primitive-table-hint represents the standard way to load tables, if more complex loading is required then other table-hints may be appropriate. Primitive-table-hint represents the simplest possible file to load data from a single table when no special processing is required:
<schema-hint>
<primitive-table-hint>
<name>EXAMPLE_TABLE_NAME</name>
</primitive-table-hint>
</schema-hint>
Note: A table should not be marked as both primitive and grouped, if this happens duplicate features will be loaded into the session .If you want to load features as primitives and form a group, or load features as primitives via a reference, then add the table only as primitive-with-grouping-table or primitive-with-reference-table to the load policy.
dependent-table-hint
A spatially indexed table that has a reference to another table. Rows in the target table are loaded as separate features when they are referenced from the primitive table.
In the following example, when an object is created from the spatially indexed SPATIALLY_INDEXED_TABLE, the referenced row from OTHER_TABLE will also be loaded and stored in a separate object.
<dependent-table-hint>
<name>OTHER_TABLE</name>
<geometry-table-name>SPATIALLY_INDEXED_TABLE</geometry-table-name>
</dependent-table-hint>
simple-join-table-hint
This specifies a join table used to represent a many-to-many relationship with no attributes. These become references with multiple cardinality (lists of objects). In the example below, EXAMPLE_TABLE has two columns referencing the primary key of two other tables, the Data Store works out which tables are implicated automatically.
<simple-join-table-hint>
<name>EXAMPLE_TABLE</name>
</simple-join-table-hint>
attributed-join-table-hint
Specifies a join table used to represent a many-to-many relationship where each instance of the relationship has its own attributes.
<attributed-join-table-hint>
<name>EXAMPLE_TABLE/name>
</attributed-join-table-hint>
grouping-table-hint
Features grouping other features. These are not loaded spatially but by reference, i.e. groups including any loaded features are automatically loaded. Also, if any features in a group is loaded then all features in that group are loaded. The example below ensures that all referenced features by EXAMPLE_TABLE in the session extent are loaded, even if they are outside the session extent.
Note: A grouped table must not also be specified as a primitive table or duplicate features will be loaded. If you want to load features as primitives and form a group, then add the table only as primitive-with-grouping-table to the load policy.
<grouping-table-hint>
<name>GROUPING_EXAMPLE_TABLE</name>
<join-table>EXAMPLE_JOIN_TABLE</join-table>
</grouping-table-hint>
primitive-with-grouping-table-hint
The example below is similar to grouping-table-hint but will also ensure all features in PRIMITIVE_EXAMPLE_TABLE inside the extent are loaded.
A primitive-with-grouping table must not also be specified as a primitive table or duplicate features will be loaded.
<primitive-with-grouping-table-hint>
<name>PRIMITIVE_GROUPING_EXAMPLE_TABLE</name>
<join-table>EXAMPLE_JOIN_TABLE</join-table>
</primitive-with-grouping-table-hint>
referenced-table-hint
Features referenced by other features. The referenced features are not loaded spatially but by reference i.e. where feature A inside the session extent has a reference to feature B outside the extent it should still load B (as B is being referenced by A). This behaviour is similar to grouping-table-hint but it will NOT load any other features of the same class as A that are referenced from B. The example below ensures that all REFERENCED_EXAMPLE_TABLEs referenced are loaded, even if they are outside the session extent.
Note: A referenced table must not be specified as a primitive table or duplicate features will be loaded. If you want to load features as primitives via a reference, then add the table only as primitive-with-reference-table to the load policy.
<referenced-table-hint>
<name>REFERENCED_EXAMPLE_TABLE</name>
<join-table>EXAMPLE_JOIN_TABLE</join-table>
</referenced-table-hint>
primitive-with-reference-table-hint
The example is similar to referenced-table-hint, and will ensure all features in PRIMITIVE_WITH_REF_EXAMPLE_TABLEs inside the extent are loaded.
Note: A primitive-with-reference table must not be specified as a primitive table or duplicate features will be loaded.
<primitive-with-reference-table-hint>
<name>PRIMITIVE_WITH_REF_EXAMPLE_TABLE</name>
<join-table>EXAMPLE_JOIN_TABLE</join-table>
</primitive-with-reference-table-hint>
out-of-line-table-hint
A feature that adds attributes to another table through a left join. The out-of-line table contains the geometry through which features should be loaded. The following example adds columns from OUT_OF_LINE_EXAMPLE_TABLE to the object created for each feature referenced in the join.
<out-of-line-table-hint>
<name>OUT_OF_LINE_EXAMPLE_TABLE</name>
</out-of-line-table-hint>
extend-load-by-ref
This will ensure that any referenced features are loaded, even if they fall outside of the extent or any buffers applied. This parameter can be particularly useful if a job fails due to incorrectly missing references.
<primitive-table-hint>
<name>ROAD_FEATURES</name>
<extend-load-by-ref>
<name>ROAD</name>
</extend-load-by-ref>
<extend-load-by-ref>
<name>ROAD_MOTORWAY</name>
</extend-load-by-ref>
</primitive-with-reference-table-hint>
Example Load Policy
The following simple load policy will load data required for pipes, points of interest, flood zones and other connected features.
<schema-hint>
<simple-join-table-hint>
<name>JUNCTIONS_TO_PIPES_JOIN_TABLES</name>
</simple-join-table-hint>
<grouping-table-hint>
<name>SITES</name>
<join-table>JUNCTIONS_TO_PIPES_JOIN_TABLES</join-table>
</grouping-table-hint>
<primitive-table-hint>
<name>POINT_OF_INTEREST</name>
</primitive-table-hint>
<primitive-table-hint>
<name>FLOOD_ZONE</name>
</primitive-table-hint>
<primitive-table-hint>
<name>STREETS</name>
</primitive-table-hint>
</schema-hint>
Read and Write Support
Parameters
Read and Commit
|
Data Store Schema Name
|
The name of the schema from which data should be read.
|
|
Datasource JNDI Location
|
A data source containing temporary tables with read access rights to the schema through which the data will be read.
|
|
Load Policy URL
|
A URL to a file defining how the data should be loaded e.g:
file:///C:/1Spatial/validation_load_policy.xml
Note: The URL must be to a local file accessible to the 1Integrate interface machine(s).
An example contents of a Load Policy file can be found above. See Example Load Policy for more.
Note: 1Integrate will need to be able to call this file each time the schema is refreshed. Once refreshed, the config file does not need to be accessed at runtime because it is stored in the Data Store.
|
Copy To
|
Data Store Schema Name
|
The name of the schema from which data should be read.
|
|
Datasource JNDI Location
|
A data source containing temporary tables with read access rights to the schema through which the data will be read.
|
|
Load Policy URL
|
A URL to a file defining how the data should be loaded e.g:
file:///C:/1Spatial/validation_load_policy.xml
Note: The URL must be to a local file accessible to the 1Integrate interface machine(s).
An example contents of a Load Policy file can be found above. See Example Load Policy for more.
Note: 1Integrate will need to be able to call this file each time the schema is refreshed. Once refreshed, the config file does not need to be accessed at runtime because it is stored in the Data Store.
|
