Open jh-RLI opened 2 years ago
For the m:n relationship between scenarios and data there is only one solution for the normalized version of the oedatamodel. There we will insert a new table "scenario_data" with two columns "scenario_id" and "data_id" between the scenario and data table.
Concerning the concrete version, it is still being considered whether to simply say that only data for one scenario can be entered there or whether the entire data model should be rebuilt. There it would bring then two new tables, which restricts the usability again a little bit. The concrete version should be kept simple.
As concrete version is used for ES setup, support for multiple scenarios is not needed IMO. But uploading concrete version is different and may cause incoherence - maybe this shouldn't be possible anymore?
I agree, multiple scenarios for concrete is not needed. I'm not sure if I follow your concern about the upload, as the concrete version can be mapped to the normalization version. Maybe I'm just not aware of the problem. If one uploads data (provided in the structure of concrete), then they upload data for a single scenario. To me, this seems like a rather organized way of uploading data to the oedatamodel normalization tables (same as adding a new dataset to the database).
If one uploads data (provided in the structure of concrete), then they upload data for a single scenario.
this is correct for a scenario which consists of new scalars and timeseries. But in this case you would not be able to upload a scenario which also reuses already existing scalars and timeseries (only new ones). If you wanted to do this you would have to upload it in normalized version.
That's right, I overlooked that. That means we only use the concrete version for such a use case (new scenario, new scalar/ts values)? Or would we drop the concrete version since it was developed to improve the usability of the upload process for people who are not familiar with data normalization and can no longer be used for such a use case?
At the moment, data is always assigned to one scenario (1:n). To make it possible to reuse data in different scenarios, an m:n relationship for data and sceanrio tables should be built into the oedata model.
A solution for the normalization variation of the oedata model is to insert a new table between the data and scenario table that has 2 columns (scenario_id and data_id). For the concreate variation of the oedatamodel it is more difficult to find a solution that also keeps the usability. Here the data tables are split into 2 tables to make it easier for the user to fill them out, so 2 new tables would have to be inserted between the data tables and the scenario table. Another solution would be to make the concrete variation explicit only for data belonging to a single scenario.
It would be useful to find a solution for the concrete variation as well, lets discuss it here.