-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support reuse of data in multiple scenarios #46
Comments
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. |
I agree, multiple scenarios for concrete is not needed. |
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). |
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)? |
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.
The text was updated successfully, but these errors were encountered: