In the configuration file for the OPA Batch Processor you have to define the primary key for all the csv-input-files. In our situation the primary key of some tables is a combination of some fields. For example we have a table "household" and a table "person". In the table "person" the primary key is a combination of the householdnumber and the personnumber (which is a serial number within the household).
When I try to use a combination of fields as primary-key a get an error regarding the amount of fields in the csv. Is it a point of principle that a primary-field only can contain 1 field?
Its not so much of a principle, as a current limitation that we can only have a single column as a primary key. A possible work around to this is to create a table view of your table with all the primary keys consolidated into a single field.
Actually, please let me expand on my answer some...
In our experience, if the OPA entity model matches the database entity model, then either your OPA model is far too normalized, or your database is not nearly normalized enough.
The general solution we use for batch is to create a logical layer between the database and OPA using SQL views. The SQL views match the OPA entity model as required.
IDs, both key and foreign key are simple produced from rowids in the SQL query.
For batch, we usually separate the input views for OPA from the output views (mostly because updateable views have some restrictions in Oracle.)
This approach not only lets us keep our database and OPA entities distinct, but allows us to play with the where clauses (to filter data) and perform some data transformations that are really best kept out of OPA.
I will comment that we are taking this one step farther to allow regression testing and "what-if analysis" for the business on a more ongoing basis.
We are architecting these views to allow the business to ask questions like "what is the impact of changing this policy on overall financials using our existing population?" We can simply change the output views to point to a temporary table and run the what-if. Then we can report back the impact of a rule change using Cognos, Excel, or what have you... It is really, really cool stuff when architects get to play.
Paul's approach with views is definitely an approach that we think is a good one. Its very difficult to get source data tables and a OPA Data model to work well when they are identically tied to each other.
Database views form a very useful layer when mapping data for OPA and can be used to overcome a lot of the standard data mapping type issues.
Although we are talking about CSV processing the principle can be the same.
If there can be some modification to the process which generates the CSV to create single col primary key (I am assuming that the CSV files are created from somewhere like an export from a database or system).