Continuing discussion about JDBC architecture and complex feature model.
I have investigated various documentation (from GeoTools and GeoServer
confluences, also source code, interfaces , etc.).
Complex feature model and complex datastore needs very good formalization
and use cases analysis.
Try to analyze what I found out.
The data model in DB has two tables: Road, RoadPart.
Road - a feature type without geometry whereas RoadPart is a feature type
with linear geometry and there is a relationship one-to-many - Road consists
from 1..* of RoadParts. Relational model is based on PK-FK, where Road_ID
is an attribute type of RoadPart feature type (primary key in Road, foreign
key in RoadPart). Here I use direct mapping based on SFM: a table matches to
the feature type, column matches to the attribute type, only simple
attribute types are used to build up a feature type.
In application we may handle this model as a simple feature model. Having
Road feature we may request list of RoadPart features constituting it
because Road FID is an attribute of its child RoadParts. Having RoadPart
feature we may request Road feature because RoadPart has an attribute that
is a FID of its corresponding parent Road. Binding of feature instances to
data model is based on FeatureType information. Full description of the
table is a schema. For every table there is a FeatureType instance that is a
SCHEMA. From this schema sub- feature types may be created when only part
of attributes of the schema are needed to create a Feature instances.
Whether it is full FeatureType (schema) or sub-type (FeatureType that is a
sub-type of the schema) - binding is simple and only actual FeatureType
information of the feature is needed.
First complex case: hierarchical FeatureType where some of AttributeTypes
are so called "complex" and imply nested FeatureTypes. The relationship is
based on relational PK-FK interaction in the DB data model.
Road may have complex attribute (multi-valued probably is a right term):
Road:
.....
RoadPart [] roadParts;
RoadPart
.....
Road road;
that reflects PK-FK relationship in the data model. In this case simple
attributes of the "complex" feature are still bound to the one database
table, but instead of representation of the complex relationships to other
feature types by simple attribute type (PK-FK values) "complex" feature type
models a "complex" feature as a hierarchy of nested simple FeatureTypes.
This is not really complex feature model from my point of view - it is more
hibernate-like way to load feature instances and their hierarchies with
complex relationships. Binding in this case to data model is also based on
the FeatureType: the difference that we have to handle "complex" attributes
in a special way to model PK-FK relationships and recursively bind nested
"complex" attributes (features). Tree-based binding from "complex" parent
feature type to the simple child feature types in leaves of the tree.
Is this case an issue at all for GIS practice, wide-spread application and
community schemas and feature types?
In our project SFM was enough to deal with complex hierarchy of feature
types in a way described in the beginning: representing relationships as
simple attribute type values.
Second complex case is well-reflected in confluence in various examples:
remapping of attribute types from different feature types and even different
datastores to the one complex feature type. Ideally it would be
ComplexDataStore charging with some configuration where this mapping is
well-described and ComplexDataStore knows how to request surrogated
datastores to load necessary attributes and map them into attributes of the
derivated feature types. Something is done in the geoserver branch.
An example: DerivatedRoadPart that contains not only simple attribute type -
FK of its parent Road - but also some other values from the Road. Database
"Joins"? Or when some attribute of the derivated feature type is a result of
the operation over some other attributes of the actual simple feature type
(simple - means no "complex" things - table goes to simple feature type
without modeling relationships through hierarchy of feature types).
>From this I would like to call such attributes as virtual. They are
calculated on the fly and do not match to any simple attribute type of the
data model. No way to talk about modifications of such attributes. Only
"read" mode makes sense for these virtual attribute types of the derivated
feature type produced by complex datastore.
An issue here: what part of feature type produced by arbitrary complex
datastore is modifiable, what is a criteria of that? Hot to define various
operations (like provided by FeatureStore) for virtual feature types? Or
complex datastore and its derivated feature types are considered only in
"read" context right now? Reading of features is much more simple than
propagating modifications back to the datastore(s). We provide
configuration, datastore implementation that knows how to interpret the
configuration to build complex feature type and fill feature instances of
this feature type by required attributes. One-way-interpretation (for
reading only) simplifies the task. Configuration-based feature creation
process, no need to fight with complex feature to data model binding. In
most cases as described it is impossible and even does not make any sense.
Turning back to JDBC datastore. What should be taken into consideration.
Binding in both directions works well in case of simple feature model,
FeatureType is enough to build SQL queries automatically for any feature
type, no additional configuration. Schemas are built from database model or
may be somehow tuned by specifying custom implementation of
JDBCFeatyreTypeBuilder.
ComplexDataStore may use JDBCDataStore in a standard way when some
attributes of some simple feature types are loaded. More customization is
needed to extend the framework of building of various SQL queries (WHERE
part ).
As usual, I am coming up with ideas and thoughts... just for my own
understanding and probably somebody's also. Writing things help to formalize
the thinking process and concentrate on essential.
Starting to look Hibernate codebase - may be to take some patterns or
ideas.
Vitali.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
