Skip to content
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

Open
jh-RLI opened this issue Nov 5, 2021 · 5 comments
Open

Support reuse of data in multiple scenarios #46

jh-RLI opened this issue Nov 5, 2021 · 5 comments
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@jh-RLI
Copy link
Collaborator

jh-RLI commented Nov 5, 2021

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.

@jh-RLI jh-RLI added enhancement New feature or request help wanted Extra attention is needed labels Nov 5, 2021
@jh-RLI
Copy link
Collaborator Author

jh-RLI commented May 3, 2022

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.

@henhuy
Copy link

henhuy commented May 3, 2022

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?

@jh-RLI
Copy link
Collaborator Author

jh-RLI commented May 3, 2022

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).

@henhuy
Copy link

henhuy commented May 3, 2022

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.

@jh-RLI
Copy link
Collaborator Author

jh-RLI commented May 3, 2022

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

5 participants